[oracle_br] Re: Demora para Gerar AWR

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

Um possível complemento : como sempre quando falamos em Query, uma outra 
possibilidade para explicar acesso a dados com delay além do sempre possível 
ponto das estatísticas de CBO defasadas é simplesmente que alguma tabela foi 
pensada/desenhada para ter relativamente POUCOS registros (então por isso não 
se criou índices pra aceerar consultas) mas com o passar do tempo os dados 
foram crescendo e crescendo e o scan já não é performático - como TODAS as 
tabelas envolvidas (ie, tanto as do AWR quanto as internas) pertencem ao RDBMS 
Oracle, o analista de Suporte vai poder dar melhores indicações, mas um teste 
que vc pode fazer pra adiantar o caso é simplesmente mandar um SELECT COUNT(*) 
FROM tabelasgranbdesdoAWR ou SELECT MIN(snapshot_id), MAX(snapshot_id), 
principalmente a tabela de snapshots : se vc ver um delay Significativo (OU 
encontrar snapshots muito antigos , ou qtdade de snapshots extrememente 
grandes) isso Pode Ser a fonte da sua lentidão

 []s
 
   Chiappa

[oracle_br] Re: SELECT com COUNT(*) demorando para retornar

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

Ops, corrige meu typo aí : troca o "= between" por apenas "between", claro...

[]s

  Chiappa

[oracle_br] Re: SELECT com COUNT(*) demorando para retornar

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

Blz ? Então, a primeira explicação que me vêm à mente é baseada no ** FATO ** 
de que, ao contrário do que os novatos pensam, ** NEM SEMPRE ** o acesso via 
índice é melhor / mais rápido / mais performático para TODOS os casos 
(https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:6749454952894
 tem um caso Clássico disso), E ao colocar um HINT vc ** ENGESSA **, vc ** 
FORÇA ** o CBO a usar o índice se possível, INDEPENDENTE de isso ser Bom ou 
Ruim... A minha Suposição é que nessa tabela com esse índice forçado o COUNT(*) 
é obrigado a ler todos (ou quase todos) os blocos do Índice (o que não acontece 
com o SQL SEM o COUNT), e devido ao FATO de que essa leitura é feita 
bloco-a-bloco, seria muito mais performático se obter os blocos todos de uma 
vez via FULL TABLE SCAN, cujo I/O é MULTIBLOCK, lendo Múltiplos Blocos de uma 
tacada só Essa diferença de performance entre ler uma larga porção de 
blocos via index (em single-block) VERSUS se ler essa mesma larga porção de 
blocos via TABLE SCAN (em multiblock) é o que estava por trás da diferença de 
performance no caso que indiquei e Suponho que é o que está por trás da sua 
situação, também : para PROVAR ou DESPROVAR, faça um trace+tkprof de uma sessão 
fazendo COUNT com o tal hint, de uma outra fazendo o mesmo COUNT ** sem ** o 
HINT e veja o que vc vai ver
 
 Não é o que vc perguntou mas ** tenho ** que dizer, também : se as minhas 
suposições de que a coluna DTA_EXTRACAO é do tipo DATE ** E ** que há índice 
considerando essa coluna estão corretas, esse SQL apresenta uma ** Péssima 
Qualidade **, ele faz a proeza de numa só vez ele violar pelo menos DUAS best 
practices : ele permite CONVERSÂO IMPLÍCITA, ao comparar a string '03-aug-2016' 
com a coluna do tipo DATE dta_extracao, ** e ** como cereja do bolo ao mesmo 
tempo ele Também mete uma função na coluna indexada - AMBAS as caquinhas podem 
fazer um índice não ser usado/levado em conta, imagino que foi daí que veio o 
HINT, inclusive - aquela historinha, ao invés de consertar o SQL lixento neguim 
sai metendo HINTs... 
 
 SE for isso mesmo, a correção desse SQL é simples :

 SELECT COUNT(*)
  from stg_catalogo_status v 
 WHERE v.dta_extracao = between TO_DATE('03/08/2016 00:00:00', 'dd/mm/ 
hh24:mi:ss')
and TO_DATE('03/08/2016 23:59:59', 'dd/mm/ 
hh24:mi:ss');

==> Essas simples alterações tanto eliminam a necessidade de função na coluna 
indexada(a TRUNC no caso, que suponho estava aqui para 'eliminar' a porção HORA 
da coluna DATE), quanto Também permite comparação de coluna DATE com valores 
DATE, yep ??

 []s
 
   Chiappa

Re: [oracle_br] Re: Refresh materialized view

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado mais uma vez Chiappa. 
irei seguir as recomendações e qualquer retorno passo as informações por aqui
:) 

Em Segunda-feira, 8 de Agosto de 2016 13:32, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Oi : o "artigo do Tom Kyte" a que vc se refere é o 
https://asktom.oracle.com/pls/asktom/f%3Fp%3D100:11:0P11_QUESTION_ID:4399099500346197085
 , correto ? Esse artigo mostra que (como também Documentado na nota metalink 
"Materialized View Refresh is Hanging With JI Contention" (Doc ID 1358453.1) , 
esse enqueue JI é o enqueue que serializa o refresh/recriação de uma view 
materializada - NÂO HÁ 'problema' algum por parte do RDBMS em princípio, é uma 
questão de concorrência, em tese... Esse enqueue  tanto pode aparecer em 
situações onde duas sessões estão tentando fazer o refresh simultaneamente 
(https://dbhk.wordpress.com/2009/12/08/refresh-materialized-view-hung/ 
exemplifica) quanto em situações onde há uma OUTRA sessão fora a do refresh 
fazendo ALTERAÇÂO DE ESTRUTURA na view e/ou na(s) tabela(s) que a compõem , Ou 
está havendo algum aceso interno aos dados (por exemplo Replicações cfrme 
http://www.orafaq.com/forum/t/127829/) nas tabelas OU mesmo há SQLs recursivos 
(como por exemplo os derivados de CONSTRAINTS) que ainda estão rolando e 
segurando o refresh 
(http://rwijk.blogspot.com.br/2010/01/enq-ji-contention.html dá um exemplo)... 
Até houveram BUGs sobre isso, como o     Deadlock On Commit Materialized View 
(Doc ID 1312379.1) mas isso há muuuito tempo lá na época do 10g, certamente não 
deve ser nada disso... 
 A minha Recomendação é dupla :
 
 a) abra um Chamado no Suporte apenas pára estar certo de que não há re-raise 
desses bugs antigos, a chance é pequena mas faça de qquer maneira
 
 e
 
 b) tenha ** CERTEZA ** de que não está havendo múltiplas ocorrências de 
REFRESH - como vc diz que é REFRESH ON DEMAND e NÂO VEJO vc indicar START nem 
nada assim eu ** IMAGINO ** que está por sua conta os refreshs bem como o 
Controle das sessões que o fazem

e

 c)  INVESTIGUE as Atividades de banco envolvidas (tanto no banco local quanto 
no banco remoto que o @databaselink COM CERTEZA indica, embora vc não nos diga 
isso claramente) : isso vai envolver desde consulta aos Locks e Transações 
ativas (vide os scripts indicados na nota metalink inicialmente citada), 
monitoração das views de WAITs, eventual TRACE, é por aí
 
 []s
 
   Chiappa  #yiv3505003201 #yiv3505003201 -- #yiv3505003201ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3505003201 
#yiv3505003201ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3505003201 
#yiv3505003201ygrp-mkp #yiv3505003201hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3505003201 #yiv3505003201ygrp-mkp #yiv3505003201ads 
{margin-bottom:10px;}#yiv3505003201 #yiv3505003201ygrp-mkp .yiv3505003201ad 
{padding:0 0;}#yiv3505003201 #yiv3505003201ygrp-mkp .yiv3505003201ad p 
{margin:0;}#yiv3505003201 #yiv3505003201ygrp-mkp .yiv3505003201ad a 
{color:#ff;text-decoration:none;}#yiv3505003201 #yiv3505003201ygrp-sponsor 
#yiv3505003201ygrp-lc {font-family:Arial;}#yiv3505003201 
#yiv3505003201ygrp-sponsor #yiv3505003201ygrp-lc #yiv3505003201hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3505003201 
#yiv3505003201ygrp-sponsor #yiv3505003201ygrp-lc .yiv3505003201ad 
{margin-bottom:10px;padding:0 0;}#yiv3505003201 #yiv3505003201actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3505003201 
#yiv3505003201activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3505003201
 #yiv3505003201activity span {font-weight:700;}#yiv3505003201 
#yiv3505003201activity span:first-child 
{text-transform:uppercase;}#yiv3505003201 #yiv3505003201activity span a 
{color:#5085b6;text-decoration:none;}#yiv3505003201 #yiv3505003201activity span 
span {color:#ff7900;}#yiv3505003201 #yiv3505003201activity span 
.yiv3505003201underline {text-decoration:underline;}#yiv3505003201 
.yiv3505003201attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3505003201 .yiv3505003201attach div a 
{text-decoration:none;}#yiv3505003201 .yiv3505003201attach img 
{border:none;padding-right:5px;}#yiv3505003201 .yiv3505003201attach label 
{display:block;margin-bottom:5px;}#yiv3505003201 .yiv3505003201attach label a 
{text-decoration:none;}#yiv3505003201 blockquote {margin:0 0 0 
4px;}#yiv3505003201 .yiv3505003201bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3505003201 
.yiv3505003201bold a {text-decoration:none;}#yiv3505003201 dd.yiv3505003201last 
p a {font-family:Verdana;font-weight:700;}#yiv3505003201 dd.yiv3505003201last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3505003201 
dd.yiv3505003201last p span.yiv3505003201yshortcuts 
{margin-right:0;}#yiv3505003201 div.yiv3505003201attach-table div div a 

[oracle_br] Re: Refresh materialized view

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

Oi : o "artigo do Tom Kyte" a que vc se refere é o 
https://asktom.oracle.com/pls/asktom/f%3Fp%3D100:11:0P11_QUESTION_ID:4399099500346197085
 , correto ? Esse artigo mostra que (como também Documentado na nota metalink 
"Materialized View Refresh is Hanging With JI Contention" (Doc ID 1358453.1) , 
esse enqueue JI é o enqueue que serializa o refresh/recriação de uma view 
materializada - NÂO HÁ 'problema' algum por parte do RDBMS em princípio, é uma 
questão de concorrência, em tese... Esse enqueue  tanto pode aparecer em 
situações onde duas sessões estão tentando fazer o refresh simultaneamente 
(https://dbhk.wordpress.com/2009/12/08/refresh-materialized-view-hung/ 
exemplifica) quanto em situações onde há uma OUTRA sessão fora a do refresh 
fazendo ALTERAÇÂO DE ESTRUTURA na view e/ou na(s) tabela(s) que a compõem , Ou 
está havendo algum aceso interno aos dados (por exemplo Replicações cfrme 
http://www.orafaq.com/forum/t/127829/) nas tabelas OU mesmo há SQLs recursivos 
(como por exemplo os derivados de CONSTRAINTS) que ainda estão rolando e 
segurando o refresh 
(http://rwijk.blogspot.com.br/2010/01/enq-ji-contention.html dá um exemplo)... 
Até houveram BUGs sobre isso, como o Deadlock On Commit Materialized View 
(Doc ID 1312379.1) mas isso há muuuito tempo lá na época do 10g, certamente não 
deve ser nada disso... 
 A minha Recomendação é dupla :
 
 a) abra um Chamado no Suporte apenas pára estar certo de que não há re-raise 
desses bugs antigos, a chance é pequena mas faça de qquer maneira
 
 e
 
 b) tenha ** CERTEZA ** de que não está havendo múltiplas ocorrências de 
REFRESH - como vc diz que é REFRESH ON DEMAND e NÂO VEJO vc indicar START nem 
nada assim eu ** IMAGINO ** que está por sua conta os refreshs bem como o 
Controle das sessões que o fazem

e

 c)  INVESTIGUE as Atividades de banco envolvidas (tanto no banco local quanto 
no banco remoto que o @databaselink COM CERTEZA indica, embora vc não nos diga 
isso claramente) : isso vai envolver desde consulta aos Locks e Transações 
ativas (vide os scripts indicados na nota metalink inicialmente citada), 
monitoração das views de WAITs, eventual TRACE, é por aí
 
 []s
 
   Chiappa