Re: [oracle_br] Problema em compilação

2016-08-02 Por tôpico Evandro Giachetto evandrogiache...@gmail.com [oracle_br] 
Olá Rafael.

Realmente, o argumento do Developer foi bem fraco.

Na certa ele deve ter sacado que você não manja de Java e jogou esse verde
para você não ficar enchendo o saco dele.

Na certa o cara usa o objeto do tipo Statement no código java para executar
a query... daí monta aquela string salsicha, dando vários concats para
montar os wheres.

A única coisa que mudaria para ele usar Bind seria utilizar o objeto do
tipo PreparedStatement. Na query que ele vai rodar, utiliza o caracter '?'
onde quer que haja um bind.

Depois, para cada ?, usa-se a substituição com um setInt, setString,
setDate, etc.

tipo assim:

String query = "select ename from emp where empid=?";

PreparedStatement stmt=con.prepareStatement(query);

stmt.setInt(1,empno);

O primeiro parâmetro de setInt (1) quer dizer que é o primeiro ? que
aparece na query.

Assim, se tivesse mais, vc iria setando os valores assim: setInt(2, valor)
setInt(3,valor) etc.

Espero ter sido claro...

Agora você já tem argumento par brigar com o seu developer.

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


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

>
>
> É ** mais que fraco **, é Risível o 'argumento' do teu desenvolver :
> pesquisa em http://asktom.oracle.com por JAVA BIND que vc vai achar PELO
> MENOS uma dúzia de artigos que discutem algumas opções/best practices de
> como implementar BINDING em java/jdbc e demonstram os graves problemas que
> podem advir de não usar, E além disso ainda educam sobre a Recomendação e
> as Palpáveis Vantagens de usar PREPARED STATEMENT 
>  Nós sabemos que desenvolvedor é aquela água, neguim não quer saber de
> usar o banco de dados da maneira correta mas sim da maneira que ELE acha
> ser mais fácil, depois quando a coisa chega no ventilador a culpa é do DBA,
> ele VAI dar as maiores desculpas pra não aprender a usar a tecnologia de
> maneira correta, sim sim, mas pelo menos vc tem que deixar Claro (não só
> pra ele MAS pro gerente e pros Superiores de vcs) os Riscos (de
> performance, de mal-uso da capacidade de hardware, até de Segurança) a que
> estão sujeitos por não usar BIND VARIABLES e não acessar/trabalhar com o
> RDBMS da maneira correta e adequada...
>
> ´[]s
>
>Chiappa
> 
>

Re: [oracle_br] Dúvida sobre parallel

2016-08-02 Por tôpico 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] Problema em compilação

2016-08-02 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
É ** mais que fraco **, é Risível o 'argumento' do teu desenvolver : pesquisa 
em http://asktom.oracle.com por JAVA BIND que vc vai achar PELO MENOS uma dúzia 
de artigos que discutem algumas opções/best practices de como implementar 
BINDING em java/jdbc e demonstram os graves problemas que podem advir de não 
usar, E além disso ainda educam sobre a Recomendação e as Palpáveis Vantagens 
de usar PREPARED STATEMENT 
 Nós sabemos que desenvolvedor é aquela água, neguim não quer saber de usar o 
banco de dados da maneira correta mas sim da maneira que ELE acha ser mais 
fácil, depois quando a coisa chega no ventilador a culpa é do DBA, ele VAI dar 
as maiores desculpas pra não aprender a usar a tecnologia de maneira correta, 
sim sim, mas pelo menos vc tem que deixar Claro (não só pra ele MAS pro gerente 
e pros Superiores de vcs) os Riscos (de performance, de mal-uso da capacidade 
de hardware, até de Segurança) a que estão sujeitos por não usar BIND VARIABLES 
e não acessar/trabalhar com o RDBMS da maneira correta e adequada... 
 
´[]s

   Chiappa

Re: [oracle_br] Dúvida sobre parallel

2016-08-02 Por tôpico 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] Problema em compilação

2016-08-02 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:
latch: row cache objectscursor: pin S wait on X

Verifiquei os principais agressores, consultando as consultas que não utilizam 
variáveis BIND com as consultas abaixo:
SELECT COUNT(SQL_TEXT), SUBSTR(SQL_TEXT,1,200) SUB_SQL_TEXT 
  FROM V$SQL 
HAVING (COUNT(SQL_TEXT) > 1000) 
GROUP BY SUBSTR(SQL_TEXT,1,200)   
ORDER BY 1;

  
SELECT   parsing_schema_name AS user_name, module,
 SUBSTR (sql_text, 1, 40) sql_text, COUNT (0) cnt,
 SUM (executions) executions
    FROM v$sqlarea
   WHERE executions < 5 AND kept_versions = 0
GROUP BY parsing_schema_name, module, SUBSTR (sql_text, 1, 40)
  HAVING COUNT (0) > 10
ORDER BY COUNT (0) DESC
/


Com a ajuda das consultas acima, mandei algumas consultas para os 
desenvolvedores deixarem de usarem variáveis literais, e passar a usar 
variáveis do tipo BIND.
O problema é que o desenvolvedor veio me falar que as consultas ficam na 
aplicação (JAVA) e que eles utilizam parâmetros, mas que esses parâmetros são 
carregados e que são enviados para o database já com as variáveis carregadas e 
que por isso, não teria como trocar por variáveis BIND.
Eu particularmente não entendo absolutamente NADA de JAVA. Achei o argumento do 
desenvolvedor muito fraco e sem muita segurança. Gostaria da opinião de vocês, 
como faço para convencer/ajudar o desenvolvedor a utilizar variáveis BIND na 
aplicação JAVA.

 

Em Terça-feira, 2 de Agosto de 2016 16:20, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  escreveu:
 

     Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:

  #yiv4826885975 #yiv4826885975 -- #yiv4826885975ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4826885975 
#yiv4826885975ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4826885975 
#yiv4826885975ygrp-mkp #yiv4826885975hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4826885975 #yiv4826885975ygrp-mkp #yiv4826885975ads 
{margin-bottom:10px;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad 
{padding:0 0;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad p 
{margin:0;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad a 
{color:#ff;text-decoration:none;}#yiv4826885975 #yiv4826885975ygrp-sponsor 
#yiv4826885975ygrp-lc {font-family:Arial;}#yiv4826885975 
#yiv4826885975ygrp-sponsor #yiv4826885975ygrp-lc #yiv4826885975hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4826885975 
#yiv4826885975ygrp-sponsor #yiv4826885975ygrp-lc .yiv4826885975ad 
{margin-bottom:10px;padding:0 0;}#yiv4826885975 #yiv4826885975actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4826885975 
#yiv4826885975activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4826885975
 #yiv4826885975activity span {font-weight:700;}#yiv4826885975 
#yiv4826885975activity span:first-child 
{text-transform:uppercase;}#yiv4826885975 #yiv4826885975activity span a 
{color:#5085b6;text-decoration:none;}#yiv4826885975 #yiv4826885975activity span 
span {color:#ff7900;}#yiv4826885975 #yiv4826885975activity span 
.yiv4826885975underline {text-decoration:underline;}#yiv4826885975 
.yiv4826885975attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4826885975 .yiv4826885975attach div a 
{text-decoration:none;}#yiv4826885975 .yiv4826885975attach img 
{border:none;padding-right:5px;}#yiv4826885975 .yiv4826885975attach label 
{display:block;margin-bottom:5px;}#yiv4826885975 .yiv4826885975attach label a 
{text-decoration:none;}#yiv4826885975 blockquote {margin:0 0 0 
4px;}#yiv4826885975 .yiv4826885975bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4826885975 
.yiv4826885975bold a {text-decoration:none;}#yiv4826885975 dd.yiv4826885975last 
p a {font-family:Verdana;font-weight:700;}#yiv4826885975 dd.yiv4826885975last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4826885975 
dd.yiv4826885975last p span.yiv4826885975yshortcuts 
{margin-right:0;}#yiv4826885975 div.yiv4826885975attach-table div div a 
{text-decoration:none;}#yiv4826885975 div.yiv4826885975attach-table 
{width:400px;}#yiv4826885975 div.yiv4826885975file-title a, #yiv4826885975 
div.yiv4826885975file-title

[oracle_br] Problema em compilação

2016-08-02 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:

Re: [oracle_br] Dúvida sobre parallel

2016-08-02 Por tôpico 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] Re: Dúvida sobre parallel

2016-08-02 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Hmmm, agora que eu vi esse complemento, e ele parece ser importante : 
má-performance com AUTO-DOP não repetida com parallel degree fixo pode indicar 
re-raise de bugs anteriores (como por exemplo o Bug 16921832 - Very high 
"ksim generic wait event" from parallel query in a RAC environment (Doc ID 
16921832.8), OU então demora no acesso aos objetos internos do dicionário de 
dados que são consultados/processados para o PQ identificar o consumo e setar 
um DOP 

 Recomendo de novo tanto o chamado na Oracle quanto o trace nas sessões - no 
caso seria Muito interessante vc obter um trace da sessão sem PQ, um de outra 
sessão com PQ mas sem AUTo-DOP e outro de uma sessão com PQ e AUTO-DOP, pra 
comparação...
 
  
 []s
 
   Chiappa
   
OBS : como vc diz que está em RAC, certifique-se de conectar sempre no ** mesmo 
** nó, para evitar casos em que um nó está com mais processamento que outro...

[oracle_br] Re: Dúvida sobre parallel

2016-08-02 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bem, até houveram alguns bugs de performance no PQ (como por exemplo Bug 
9471330 - Poor performance for parallel access to small LOBs - superseded (Doc 
ID 9471330.8, Bug 8965223 - Parallel query with many partitions slow to start 
(Doc ID 8965223.8) e Bug 6643259 - Intermittent hang for inter-instance 
parallel query using rds over infiniband (Doc ID 6643259.8) , mas TODOS eles já 
deveriam estar corrigidos no 11.2.0.4 - abra um Chamado e verifique, mas acho 
que é pequena a possibilidade...
 Pra vc ter uma noção mais precisa das diferenças entre a execução com e sem 
PQ, o caminho é um só : TRACE com evento 10046 e level máximo (INCLUSIVE waits) 
 de uma execução com PQ (Provavelmente tomando os cuidados indicados na nota 
"How to Get 10046 Trace for Parallel Query" (Doc ID 1102801.1), um outro TRACE 
equivalente de uma Outra sessão executando sem PQ (com o HINT de noparallel, 
que é teu exemplo), e depois COMPARANDO DETALHADAMENTE os planos de execução 
REAIS, os WAITs, a performance observada (de I/O e de acesso aos recursos 
internos) e dos objetos sendo acessados - PRINCIPALMENTE se vc está com 
AUTO-DOP ativado, não é impossível que a demora com PQ seja com o RDBMS 
acessando seus controles internos/dicionário de dados, por exemplo...
 
 []s
 
   Chiappa

[oracle_br] Re: Dúvida sobre parallel

2016-08-02 Por tôpico Evandro Giachetto evandrogiache...@gmail.com [oracle_br] 
Apenas adicionando um dado.

Se eu rodar a query dessa forma ela termina rápido.

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

288 rows selected.

Elapsed: 00:00:00.21

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 ||
---

Note
-
   - automatic DOP: Computed Degree of Parallelism is 2


Statistics
--
  6  recursive calls
  0  db block gets
 13  consistent gets
  0  physical reads
  0  redo size
  23875  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


Mas, sem especificar nenhum hint, apenas aceitando o que está no atributo
parallel da tabela, ela leva 28s.

select * from gdw_adm.d_country

288 rows selected.

Elapsed: 00:00:28.42

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
--
   1277  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

Alguém aí já observou esse comportamento? Será um bug?

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


Em 2 de agosto de 2016 14:30, Evandro Giachetto 
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  |

[oracle_br] Dúvida sobre parallel

2016-08-02 Por tôpico 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/