Re: [oracle_br] Dúvida sobre parallel

[jlchia...@yahoo.com.br [oracle_br]]

ok.. Só ** reitero ** que isso Absolutamente Não É um comportamento padrão e 
esperado, então tem sim a chance de OU ser bug OU então algo específico do seu 
ambiente (digamos, talvez acesso ao dicionário de dados mais lento do que o 
normal) - sendo asim, eu Recomendo Fortemente que vc faça os traces indicados E 
que acione o Suporte Oracle pra ter CERTEZA do que está acontecendo aí, okdoc ??

 []s
 
   Chiappa

Re: [oracle_br] Dúvida sobre parallel

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Valeu Chiappa. Como sempre sua atenção aos membros do grupo é digna de
várias rodadas de Cerveja (embora eu acho que eu seja o único dba no mundo
que não bebe.. rss)

Eu estava pensando nisso mesmo que você falou e, para ser sincero, depois
que mandei o e-mail encontrei os bugs, mas como ele dizia acontecer até o
11.2.0.3, não dei tanta importância. Pode mesmo ser uma reapresentação.

Fabio, foi exatamente isso que eu disse ao topeir... errr... developer :o)
.. Eu achei o comportamento curioso e por isso postei aqui na lista, pois
outros podem já ter passado por isso e ter uma solução... ou mesmo serve de
"heads up" para os que ainda não viram esse comportamento.

Amanhã eu devo coletar os traces, embora eu tenha que mudar malandramente a
tabela para auto dop novamente... pois já pedi para o developer voltar as
tabelas para noparallel.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 2 de agosto de 2016 19:53, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Não sei não : numa outra mensagem depois desta que vc respondeu, o colega
> mostrou que a má-performance só acontece se ele usar AUTO-DOP , se ele
> indica o degree of parallelism manualmente a performance é normal - se
> fosse questão de falta de cpu, gerenciamento de fila longuíssima de slaves
> ou coisa assim em tese deveria acontecer TAMBÉM quando ele usa o auto-dop,
> acho... .  Eu ainda penso que o que tá parecendo é bug no auto-dop e/ou
> acesso ao dicionário comprometido (pois o AUTO-DOP tem que consultar e
> analisar muita coisa)  Mas só quando ele fazer o teste de trace que
> indiquei numa outra msg E confirmar com o SUporte a chance de bugs é que
> vamos saber a real...
>
>  []s
>
>   Chiappa
> 
>

Re: [oracle_br] Dúvida sobre parallel

[jlchia...@yahoo.com.br [oracle_br]]

Não sei não : numa outra mensagem depois desta que vc respondeu, o colega 
mostrou que a má-performance só acontece se ele usar AUTO-DOP , se ele indica o 
degree of parallelism manualmente a performance é normal - se fosse questão de 
falta de cpu, gerenciamento de fila longuíssima de slaves ou coisa assim em 
tese deveria acontecer TAMBÉM quando ele usa o auto-dop, acho... .  Eu ainda 
penso que o que tá parecendo é bug no auto-dop e/ou acesso ao dicionário 
comprometido (pois o AUTO-DOP tem que consultar e analisar muita coisa)  
Mas só quando ele fazer o teste de trace que indiquei numa outra msg E 
confirmar com o SUporte a chance de bugs é que vamos saber a real...

 []s

  Chiappa

Re: [oracle_br] Dúvida sobre parallel

[Fabio Prado fbifa...@gmail.com [oracle_br]]

Evandro, paralelismo só deve ser usado em SQLs longos (utilize como
referência 30s ou mais). Altere já todos os objetos para NOPARALLEL
novamente.

Para pequenos SQLs não vale a pena sobrecarregar o BD com o gerenciamento
dos processos escravos para executar o SQL. Além do mais, a causa maior da
demora aí deve ser o enfileiramento de instruções paralelas, pois não há
CPU suficiente para atender tudo o que está sendo executado. Para mais
informações sugiro a leitura do artigo:
http://www.fabioprado.net/2013/02/paralelismo-automatico-no-oracle.html.


[]s


*Fábio Prado*

www.fabioprado.net
"Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
Oracle"


Em 2 de agosto de 2016 14:30, Evandro Giachetto evandrogiache...@gmail.com
[oracle_br]  escreveu:

>
>
> Olá pessoal, estou com uma dúvida sobre um comportamento que tenho
> observado.
>
> Um dos retard eerr.. quer dizer, developers... alterou todas as
> tabelas de um schema para PARALLEL. (alter table  parallel )
>
> Dessa forma o Oracle define o degree como "default"... porém, uma coisa me
> chamou a atenção.
>
> Para uma tabela com apenas 280 linhas, um select * levou em torno de 28s
> para ser processado, tendo a cláusula de parallel setada.
>
> Se eu altero a tabela para noparallel (ou mesmo rodo o mesmo select com a
> hint de noparallel), ela me entrega todos os dados em menos de 1s (quase
> instantâneo), mesmo após limpar o cache.
>
> Minha dúvida é: Será que isso pode ser algum bug? Não acredito que o
> oracle precise de todo esse tempo para montar todos os slaves e começar a
> processar a query em paralelo.
>
> Versão: 11.2.0.4
> RAC com 4 nós
>
> Fiz o rebalanceamento de IO recentemente.
>
> SQL> select * from gdw_adm.d_country;
>
> 288 rows selected.
>
> Elapsed: 00:00:28.43
>
> Execution Plan
> --
> Plan hash value: 2802851973
>
>
> ---
> | Id  | Operation| Name  | Rows  | Bytes | Cost (%CPU)|
> Time |TQ  |IN-OUT| PQ Distrib |
>
> ---
> |   0 | SELECT STATEMENT |   |   288 | 21600 | 2   (0)|
> 00:00:01 ||  ||
> |   1 |  PX COORDINATOR  |   |   |   ||
>||  ||
> |   2 |   PX SEND QC (RANDOM)| :TQ1  |   288 | 21600 | 2   (0)|
> 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
> |   3 |PX BLOCK ITERATOR |   |   288 | 21600 | 2   (0)|
> 00:00:01 |  Q1,00 | PCWC ||
> |   4 | TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 2   (0)|
> 00:00:01 |  Q1,00 | PCWP ||
>
> ---
>
>
> Statistics
> --
>1280  recursive calls
>   0  db block gets
>  13  consistent gets
>   0  physical reads
>   0  redo size
>   23867  bytes sent via SQL*Net to client
> 733  bytes received via SQL*Net from client
>  21  SQL*Net roundtrips to/from client
>   0  sorts (memory)
>   0  sorts (disk)
> 288  rows processed
>
>
> SQL> select /*+ noparallel */ * from gdw_adm.d_country;
>
> 288 rows selected.
>
> Elapsed: 00:00:00.06
>
> Execution Plan
> --
> Plan hash value: 3256989411
>
>
> ---
> | Id  | Operation | Name  | Rows  | Bytes | Cost (%CPU)| Time
> |
>
> ---
> |   0 | SELECT STATEMENT  |   |   288 | 21600 | 3   (0)|
> 00:00:01 |
> |   1 |  TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 3   (0)|
> 00:00:01 |
>
> ---
>
>
> Statistics
> --
>   1  recursive calls
>   0  db block gets
>  26  consistent gets
>   0  physical reads
>   0  redo size
>   28788  bytes sent via SQL*Net to client
> 733  bytes received via SQL*Net from client
>  21  SQL*Net roundtrips to/from client
>   0  sorts (memory)
>   0  sorts (disk)
> 288  rows processed
>
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
> http://bancotunado.blogspot.com.br/
>
> 
>

[oracle_br] Dúvida sobre parallel

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá pessoal, estou com uma dúvida sobre um comportamento que tenho
observado.

Um dos retard eerr.. quer dizer, developers... alterou todas as tabelas
de um schema para PARALLEL. (alter table  parallel )

Dessa forma o Oracle define o degree como "default"... porém, uma coisa me
chamou a atenção.

Para uma tabela com apenas 280 linhas, um select * levou em torno de 28s
para ser processado, tendo a cláusula de parallel setada.

Se eu altero a tabela para noparallel (ou mesmo rodo o mesmo select com a
hint de noparallel), ela me entrega todos os dados em menos de 1s (quase
instantâneo), mesmo após limpar o cache.

Minha dúvida é: Será que isso pode ser algum bug? Não acredito que o oracle
precise de todo esse tempo para montar todos os slaves e começar a
processar a query em paralelo.

Versão: 11.2.0.4
RAC com 4 nós

Fiz o rebalanceamento de IO recentemente.

SQL> select * from gdw_adm.d_country;

288 rows selected.

Elapsed: 00:00:28.43

Execution Plan
--
Plan hash value: 2802851973

---
| Id  | Operation| Name  | Rows  | Bytes | Cost (%CPU)|
Time |TQ  |IN-OUT| PQ Distrib |
---
|   0 | SELECT STATEMENT |   |   288 | 21600 | 2   (0)|
00:00:01 ||  ||
|   1 |  PX COORDINATOR  |   |   |   ||
 ||  ||
|   2 |   PX SEND QC (RANDOM)| :TQ1  |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |PX BLOCK ITERATOR |   |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWC ||
|   4 | TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWP ||
---


Statistics
--
   1280  recursive calls
  0  db block gets
 13  consistent gets
  0  physical reads
  0  redo size
  23867  bytes sent via SQL*Net to client
733  bytes received via SQL*Net from client
 21  SQL*Net roundtrips to/from client
  0  sorts (memory)
  0  sorts (disk)
288  rows processed


SQL> select /*+ noparallel */ * from gdw_adm.d_country;

288 rows selected.

Elapsed: 00:00:00.06

Execution Plan
--
Plan hash value: 3256989411

---
| Id  | Operation | Name  | Rows  | Bytes | Cost (%CPU)| Time
  |
---
|   0 | SELECT STATEMENT  |   |   288 | 21600 | 3   (0)|
00:00:01 |
|   1 |  TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 3   (0)|
00:00:01 |
---


Statistics
--
  1  recursive calls
  0  db block gets
 26  consistent gets
  0  physical reads
  0  redo size
  28788  bytes sent via SQL*Net to client
733  bytes received via SQL*Net from client
 21  SQL*Net roundtrips to/from client
  0  sorts (memory)
  0  sorts (disk)
288  rows processed



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/