Re: [oracle_br] Re: Cursor: pin S wait on X - Apó s migração para novo ambiente

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

Chiappa, tenho que confessar que sou seu fã.:)
 

Em Terça-feira, 9 de Agosto de 2016 13:54, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Tudo jóia ? Bom, vc não diz mas eu vou ** SUPOR ** aqui que vc tem provas 
Diretas que esse wait é problemático no seu ambinete , ie, vc mediu NÂO SÓ UMA 
VEZ mas Múltiplas vezes no seu ambiente, usando intervalos de coleta ** CURTOS 
** (talvez 15 minutos entre cada coleta, ou até pouco menos), e esse wait tava 
sempre entre os TOPs e ** SEMPRE ** o percentual dele em relação à lista toda 
de waits era significativo, ie, tava sempre acima dos 20 e tantos percento, ou 
coisa assim, ** E ** as suas medições consecutivas SEMPRE mostram que a qtdade 
desses WAITs tem sempre aumentado entre as medições Medir só uma vez, ou 
medir com um intervalor de HORAS e HORAS entre as coletas  OBVIAMENTE não prova 
Coisa Alguma, né??? Igualmente, desconhecer que as estatísticas de wait são 
CUMULATIVAS pode te levar a engano, vc vê um número lá grande enorme, se não 
ver que a DIFERENÇA entre as coletas tá crescendo vc não sabe dizer se esse 
"acumulado" tão grande é algo ocorrendo no momento ou não...

Isso posto, vamos por partes aí : antes de tudo, para enterder o problema, veja 
na nota metalink 'Resolving Issues of "Library Cache Pin" or "Cursor Pin S wait 
on X"' (Doc ID 1476663.1) que esse evento mostra o resultado dos mecanismos de 
proteção ao acesso concorrente às estruturas do library cache/cache de SQLs, 
então NÂO, por princípio NÂO TEM A VER com alterações de tabelas, estamos 
falando de processamento de SQL aqui, então a sua resposta para  :

"...A principio, este evento só poderia ocorrer se a tabela sofresse alguma 
alteração em modo exclusivo correto ? ..."

é NÃO, essa suposição Não Está Correta PROVAVELMENTE vc se confundiu aí : 
esse modo "exclusivo" (X) do evento indica que o LATCH está sendo usado em modo 
exclusivo, e NÂO A TABELA, ok ?? Via de regra, para que alguém use um latch 
relacionado a Cursor em modo eXclusivo, isso indica que por qquer motivo OU o 
SQL em preparo para ser executado não pôde reusar a versão que estava no cache 
OU o SQL não existia/não foi encontrado no cache SQL, e não "tabela" okdoc 
??

 Adicionalmente, até podem haver Outros processamentos internos no database que 
causem isso - exemplo típico é o gerenciamento automático de memória, pois 
(obviamente) resize de memória potencialmente IMPLICA/PODE IMPLICAR em resize 
de TODAs as estruturas que residem em memória, o que inclui o cache de 
SQLs/library cache , como indicado na nota metalink "High 'Cursor: Pin S Wait 
On X', 'Library Cache Lock' And "Latch: Shared Pool" Waits due to Shared 
Pool/Buffer Cache Resize Activity" (Doc ID 742599.1)... SERÁ que não pode ser 
algo nesse estilo a sua issue ?? Talvez...
  A mesma nota indica que até houveram alguns bugs que causavam aumento em 
processamento interno/resize de memória sob AMM mas em tese eles já deveriam 
ter sido corrigidos : ok, o software do Exadata não segue ao pé de letra o 
mesmo agendamento de patches mas bugs tão antigos quanto os indicados na nota 
em questão já corrigidos no RDBMS já deveriam ter sido portados/corrigidos no 
software Exadata há muito Confira no Suporte Oracle mas não tem muita 
chance de ser isso, não... Falando em Ações com o Suporte Oracle, o que vc 
deveria checar são casos mais próximos, como os das notas "High Waits On 
'cursor: pin S wait on X' Or 'library cache lock' When Remote Functions Are 
Called" (Doc ID 1146428.1) e "Cursor Pin S Wait On X High During Select With 
Parallel" (Doc ID 1915053.1)...

==> EM PARALELO, enquanto vc checa essas possibilidades internas (digamos 
assim), vc ** VAI ** levantar e descobrir QUEM está causando o wait, ie, QUEM 
está segurando o latch por muito mais tempo do que devia... Note que eu estou 
apontando uma ANOMALIA : um SQL que está sendo re-executado PELO CACHE, 
bonitinho, sem PARSES, sem ESTRUTURAS físicas (como colunas) e/ou estruturas 
lógicas (como CONSTRAINTs) sendo frequementemente alteradas, deveria obter e 
liberar esse latch em microsegundos, coisa EXTREMAMENTE Rápida  - assim mesmo 
que hajam " milhares de consultas" às tais tabelas que vc identificou serem 
muito acessadas, SE ESSES SQLs TODOS estivessem sendo reusados via cache, sem 
parse, E sem gerenciamento do cache (ie, não há LEAKING de cursores que forcem 
o RDBMS a ficar limpando entradas no array de cursores, digamos), vc 
ABSOLUTAMENTE NÂO DEVERIA ver esperas Significativas por esse evento
 Para vc LEVANTAR quem está usando e abusando tanto desse latch, siga os 
procedimentos da nota "How to Determine the Blocking Session for Event: 
'cursor: pin S wait on X' " (Doc ID 786507.1) - basicamente consultar na 
V$SESSION (GV$SESSION no seu caso já que vc está em RAC) pelas colunas de 
P1/P2/P3 quem é o "bloqueador" (não gosto de falar em bloqueador/bloqueado 
quando discutimos LATCH, tecnicamente isso não é correto mas enfim) 

Re: [oracle_br] Re: passos para certificação

[Paulo Chesini p.ches...@gmail.com [oracle_br]]

Olá Rosivaldo, Andre, José e Chiappa (e todo mundo da lista)

Num primeiro momento não esperava respostas tão esclarecedoras.
Vou pegar tudo que falaram, analisar e começar a estudar por mim, ver os
livros que comentaram, criar umas bases testes aqui e ir fuçando.

Verei os links da oracle pra entender melhor o que significa(e o que é
esperado de quem possui a certificação) cada sigla e ver como se encaixa
naquilo que quero fazer.

Quanto ao backup em expdp, vou tentar entender melhor o rman, pq o dba
quando instalou o banco configurou tbm pra gerar os backups pelo rman, mas
eu não sei usar ele, deixo gerando pois "vai que um dia da um BO grande".

Obrigado pelas respostas e esclarecimentos.

Abraços
Paulo Chesini

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

>
>
> Tudo jóia ? Então, a primeira coisa que vc tem que ter em mente é que
> Certificação é um processo para (em tese) tentar validar / avaliar o
> Conhecimento e a Experiência que a pessoa já tem , e ** não ** para
> Proporcionar  esse conhecimento / experiência pra quem não tem, ok ?
>   No seu caso, portanto, se vc tem tão pouco conhecimento / experiência
> quanto relata, em minha Opinião valeria MUITO MAIS A PENA vc primeiro Obter
> esse conhecimento (estudando a Documentação, fazendo bons Treinamentos,
> lendo bons livros, e fazendo Muito estudo por si mesmo) , para só DEPOIS ir
> atrás de Certificação, sim ?? Se certificar antes de ter uma boa
> experiência via de regra vai ser Mito Mais Difícil do que o normal, e
> além disso não é lá muito efetivo Tem gente que acha que só o fato de
> vc estudar pras provas de Certificação já te dá conhecimento mas eu não
> penso assim, não...
>
>  Isso posto : se/quando vc for querer se Certificar, a primeira coisa é
> saber no que se certificar : se vc for basicamente Desenvolvedor pode ser
> interessante uma certificação de PL/SQL, se vc for DBA uma de
> Administração No site http://technet.oracle.com (o acesso é gratuito,
> basta vc se Cadastrar nele) no opção  "Training" do menu suspenso escolha o
> item "Become certified" e vc vai encontrar detalhamento para Todas as
> certificações possíveis
>
>  Apenas como informação, pra vc ter uma idéia : se vc for escolher o
> caminho de certificação para DBAs, por exemplo, o primeiro nível , mais
> básico, que em tese certifica que vc tem um conhecimento básico do básico
> sobre Administração, é o OCA : Oracle Certified Associate... Para vc ganhar
> essa Certificação vc tem que fazer uma Prova de conhecimentos básicos de
> linguagem SQL e a Prova "Oracle Database 11g: Administration I 1Z0-052",
> que tem testes sobre alguns itens básicos de Administração de banco Oracle.
>   Uma vez obtido o OCA, se vc quiser obter a Certificação de DBA acima do
> nível básico (essa é a que as Empresas normalmente te cobram) - a chamada
> OCP, Oracle Certified Professional -, além de ter OCA vc vai ter que fazer
> a Prova "Oracle Database 11g: Administration II 1Z0-053" e vai ter que
> fazer um dos Cursos oficiais da Oracle que são homologados para isso, no
> site tem a lista deles.
>   As provas tanto para o OCA quanto para o OCP são Presenciais (exceto o
> de SQL básico, que por vezes  pode ser feito online), múltipla-escolha, são
> aplicadas em determinadas empresas parceiras da Oracle (normalmente nas
> grandes Capitais do Brasil, nem toda Cidade tem local de provas) e via de
> regra são pagas em dólar (normalmente isso dá algo por volta de uns R$
> 500,00 por prova, mas pode variar de acordo com a cotação do dólar). Blz ?
> Espero ter te dado uma boa idéia geral...
>
>   []s
>
> Chiappa
>
>  OBS :
>
>   a) vc acha bastante info adicional (e totalmente em pt-br na maioria dos
> casos) no site http://certificacaobd.com.br/ , dá uma passada por lá
>
>   b) no caso do Oracle, além da OCA (a Certificação mais xulé, basicona,
> que normalmente não é a que as Empresas querem) e da OCP (a Certificação de
> uso Profissional, que normalmente é o que as Empresas pedem), temos também
> a OCM (Oracle Certified Master) : essa é uma Certificação de nível
> Extremamente mais alto, cujas Provas não são múltipla escolha e normalmente
> devem ser feitas no Exterior, há apenas um punhado de profissionais no
> Brasil que a possuem
>
>
> 
>

[oracle_br] Re: Cursor: pin S wait on X - Apó s migração para novo ambiente

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

Tudo jóia ? Bom, vc não diz mas eu vou ** SUPOR ** aqui que vc tem provas 
Diretas que esse wait é problemático no seu ambinete , ie, vc mediu NÂO SÓ UMA 
VEZ mas Múltiplas vezes no seu ambiente, usando intervalos de coleta ** CURTOS 
** (talvez 15 minutos entre cada coleta, ou até pouco menos), e esse wait tava 
sempre entre os TOPs e ** SEMPRE ** o percentual dele em relação à lista toda 
de waits era significativo, ie, tava sempre acima dos 20 e tantos percento, ou 
coisa assim, ** E ** as suas medições consecutivas SEMPRE mostram que a qtdade 
desses WAITs tem sempre aumentado entre as medições Medir só uma vez, ou 
medir com um intervalor de HORAS e HORAS entre as coletas  OBVIAMENTE não prova 
Coisa Alguma, né??? Igualmente, desconhecer que as estatísticas de wait são 
CUMULATIVAS pode te levar a engano, vc vê um número lá grande enorme, se não 
ver que a DIFERENÇA entre as coletas tá crescendo vc não sabe dizer se esse 
"acumulado" tão grande é algo ocorrendo no momento ou não...

Isso posto, vamos por partes aí : antes de tudo, para enterder o problema, veja 
na nota metalink 'Resolving Issues of "Library Cache Pin" or "Cursor Pin S wait 
on X"' (Doc ID 1476663.1) que esse evento mostra o resultado dos mecanismos de 
proteção ao acesso concorrente às estruturas do library cache/cache de SQLs, 
então NÂO, por princípio NÂO TEM A VER com alterações de tabelas, estamos 
falando de processamento de SQL aqui, então a sua resposta para  :

"...A principio, este evento só poderia ocorrer se a tabela sofresse alguma 
alteração em modo exclusivo correto ? ..."

é NÃO, essa suposição Não Está Correta PROVAVELMENTE vc se confundiu aí : 
esse modo "exclusivo" (X) do evento indica que o LATCH está sendo usado em modo 
exclusivo, e NÂO A TABELA, ok ?? Via de regra, para que alguém use um latch 
relacionado a Cursor em modo eXclusivo, isso indica que por qquer motivo OU o 
SQL em preparo para ser executado não pôde reusar a versão que estava no cache 
OU o SQL não existia/não foi encontrado no cache SQL, e não "tabela" okdoc 
??

 Adicionalmente, até podem haver Outros processamentos internos no database que 
causem isso - exemplo típico é o gerenciamento automático de memória, pois 
(obviamente) resize de memória potencialmente IMPLICA/PODE IMPLICAR em resize 
de TODAs as estruturas que residem em memória, o que inclui o cache de 
SQLs/library cache , como indicado na nota metalink "High 'Cursor: Pin S Wait 
On X', 'Library Cache Lock' And "Latch: Shared Pool" Waits due to Shared 
Pool/Buffer Cache Resize Activity" (Doc ID 742599.1)... SERÁ que não pode ser 
algo nesse estilo a sua issue ?? Talvez...
  A mesma nota indica que até houveram alguns bugs que causavam aumento em 
processamento interno/resize de memória sob AMM mas em tese eles já deveriam 
ter sido corrigidos : ok, o software do Exadata não segue ao pé de letra o 
mesmo agendamento de patches mas bugs tão antigos quanto os indicados na nota 
em questão já corrigidos no RDBMS já deveriam ter sido portados/corrigidos no 
software Exadata há muito Confira no Suporte Oracle mas não tem muita 
chance de ser isso, não... Falando em Ações com o Suporte Oracle, o que vc 
deveria checar são casos mais próximos, como os das notas "High Waits On 
'cursor: pin S wait on X' Or 'library cache lock' When Remote Functions Are 
Called" (Doc ID 1146428.1) e "Cursor Pin S Wait On X High During Select With 
Parallel" (Doc ID 1915053.1)...

==> EM PARALELO, enquanto vc checa essas possibilidades internas (digamos 
assim), vc ** VAI ** levantar e descobrir QUEM está causando o wait, ie, QUEM 
está segurando o latch por muito mais tempo do que devia... Note que eu estou 
apontando uma ANOMALIA : um SQL que está sendo re-executado PELO CACHE, 
bonitinho, sem PARSES, sem ESTRUTURAS físicas (como colunas) e/ou estruturas 
lógicas (como CONSTRAINTs) sendo frequementemente alteradas, deveria obter e 
liberar esse latch em microsegundos, coisa EXTREMAMENTE Rápida  - assim mesmo 
que hajam " milhares de consultas" às tais tabelas que vc identificou serem 
muito acessadas, SE ESSES SQLs TODOS estivessem sendo reusados via cache, sem 
parse, E sem gerenciamento do cache (ie, não há LEAKING de cursores que forcem 
o RDBMS a ficar limpando entradas no array de cursores, digamos), vc 
ABSOLUTAMENTE NÂO DEVERIA ver esperas Significativas por esse evento
 Para vc LEVANTAR quem está usando e abusando tanto desse latch, siga os 
procedimentos da nota "How to Determine the Blocking Session for Event: 
'cursor: pin S wait on X' " (Doc ID 786507.1) - basicamente consultar na 
V$SESSION (GV$SESSION no seu caso já que vc está em RAC) pelas colunas de 
P1/P2/P3 quem é o "bloqueador" (não gosto de falar em bloqueador/bloqueado 
quando discutimos LATCH, tecnicamente isso não é correto mas enfim) e pelo 
SQL_ID ver quem é o SQL tanto no "bloqueado" quano no "bloqueador", e depois 
tentar obter pela (G)V$SQL as estats de execução desses SQLs, ao Rowid  em veja 
que...
 Outro 

[oracle_br] Re: Duvida calculo de performance de query

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

Oi, tudo jóia ? Então, a resposta só pode ser NEGATIVA : veja vc, se fosse 
possível obter através de um cálculo uma metodologia  ** precisa e Ótima ** 
para qualquer SQL, OBVIAMENTE a Oracle colocaria esse mesmo cálculo no 
otimizador e aí não estaríamos tendo esta conversa, pois Qualquer desvio da 
fórmula teria que ser reportado como falha ...
 O que vc pode fazer são duas coisas :
 
 a) fazer um BENCHMARK no seu banco, mostrando que os elementos básicos de 
performance pra execução de um SQL (ie, IOPS, tempo de acesso a um bloco em 
disco, qtdade de blocos lidos num só acesso multiblock, etc) estão mais ou 
menos COmpatíveis com o que vc espera obter do seu hardware , E também 
demonstrando que os tempos de espera por recursos internos do sistema (ie, 
latches, locks internos, estruturas físicas como block header, estruturas de 
controle como controlfile, tabelas e views internas, etc) não estão 
anormalmente altos Isso vc pode fazer tanto com recursos internos do RDBMS 
(como AWR/ASH, trace, instrumentação interna refletida nas V$, etc) Quanto com 
tools externas, como o SLOB, o Orin, Swingbench, etc :  
https://www.pythian.com/blog/oracle-database-appliance-storage-performance-part-1/
 ,  
https://kevinclosson.net/2012/02/06/introducing-slob-the-silly-little-oracle-benchmark/
 ,  
https://oracle-base.com/articles/misc/measuring-storage-performance-for-oracle-systems
 e 
http://www.oracle.com/technetwork/database/database-appliance/documentation/oda-eval-comparing-performance-1895230.pdf
 são alguns Exemplos
 
 e
 
 b) vc pode analisar a Eficiência dos seus SQLs : há diversos indicadores 
(NENHUMA fórmula precisa, insisto, mas sim alguns Indicadores) que vc pode 
usar, como por exemplo volume de linhas retornadas versus qtdade de LIOs - 
obviamente um SQL que retorna dezenas de linhas acessando centenas de milhares 
de blocos tá ** LONGE ** de ser eficiente... Idem para PARSES constantes, tempo 
de execução do SQL elevado para pequeno retorno, total de espera por  CPU  
percentualmente significativo no cômputo geral, grande consumo de temp space,  
por aí...

  O ponto é que , Demosntrado que o banco está trabalhando normalmente, cabe ao 
DBA (junto com o Desenvolvedores, óbvio) descobrir a CAUSA da ineficiência e 
implantar uma solução para cada SQL demonstrado Ineficiente, que pode ser 
Física (adição ou remoção de indíce, reorganização de espaço interno em disco, 
implementação de estruturas físicas como Clusters nas tabelas, mudanças de 
datatype), Lógica (ie, re-escrever o SQL ineficiente com novas condições e 
cláusulas, novas sintaxes, o que for) ou MODELARES (ie, alterar o Modelo de 
dados, que não está Ótimo)...

 []s

   Chiappa

[oracle_br] Cursor: pin S wait on X - Após migração para novo ambiente

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

Bom dia colegas,
 

 Poderiam me ajudar ?
 

 Estou encontrando muitos problemas relacionados a este evento (Cursor: pin S 
wait on X) e os mesmos não ocorriam, no meu antigo ambiente (Oracle RAC STD 
11.2.0.4 com 02 nodes).
 

 Recentemente fizemos uma migração para um Exadata e desde então, tenho sido 
impactado negativamente por este evento.
 

 Fiz algumas verificações nas sessões que estariam com este wait e a principio, 
todas fazem referencia ao Rowid de 02 tabelas, que sofrem muitos acessos 
durante o dia. 
 

 A principio, este evento só poderia ocorrer se a tabela sofresse alguma 
alteração em modo exclusivo correto ? 
 

 Será que as milhares de consultas ao Rowid poderia desencadear isso ?
 

 Verifiquei também a quantidade de cursores, que neste caso estão estourando 
também mas já estamos conversando com o time de DEV para melhorar isso, 
trabalhando com pool de conexões e analisando porque os alguns não estão sendo 
fechados.
 

 Vocês teriam alguma dica ?
 

 Muito obrigado
 

 

 

[oracle_br] Duvida calculo de performance de query

[Carlos Cesar Aparecido Da Silva carlos.sil...@jbsfoods.com.br [oracle_br]]

Bom dia!
 Existe algum calculo de performance de query, que eu consiga realizar para 
saber se o problema esta na minha instrução Sql ou no banco?

Att?