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

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

Bom, primeira coisa eu *** DUVIDO *** que esse evento não acontecia no ambiente 
anterior SE todo o código envolvido e o modo de uso era o mesmo que hoje - 
minha Suposição é que isso acontecia antes em pequena escala, aí vc não notava 
já que o wait não entrava nos TOP WAITs, mas que devia estar acontecendo SIM, 
devia... 
 Inclusive, quando eu vejo situações em que um ambiente com um poder 
computacional aumentado traz comportamentos/eventos de espera diferentes 
(podendo até ter PIORA DE PERFORMANCE num caso agudo que (imagino) não é o 
seu), o que eu penso é que o sistema anterior tinha capacidade de atender x 
sessões ao mesmo tempo, e como x não era um número grande as sessões esperavam 
muito pouco pelo latch em questão - com a maior capacidade de CPU e 
processamento geral do Exadata, x*N sessões passaram a ser processadas 
simultâneamente, aí por mais rápido que seja a capacidade do sistema, ele não 
teve capacidade para atender a tantas requisições simultâneas Pense no caso 
Clássico de trânsito num grande capital, não é incomum vc ver uma série de vias 
auxiliares medianamente engarrafadas aí o poder público cria uma grande avenida 
que é capaz de escoar  muito mais veículos de uma vez do que uma via auxiliar e 
assim as fecha/dedica a trãnsito local - o resultado é que todo mundo passa a 
ir pra avenida principal ao mesmo tempo que por mais larga que seja não 
comporta... Isso é ** mega-comum **, ao vc aumentar a capacidade do hardware 
(ie, mais CPU, mais memória, mais banda de rede, etc) ele vai permitir mais 
sessões simultãneas que vão pedir por mais recursos, na hora que chega num 
recurso não-compartilhável (locks, latches, memória) a coisa degringola : veja 
http://pt.slideshare.net/SolarWinds/why-new-hardware-may-not-make-oracle-databases-faster
 para uma Apresentação a respeito

 E não parece ser o caso, mas ** não esqueçamos ** que embora o Exadata no 
quesito RDBMS ** ainda ** seja basicamente o mesmo RDBMS que conhecemos e 
amamos, ele traz consigo diferenças ** FUNDAMENTAIS ** no quesito Tuning : por 
exemplo, recursos de I/O preditivo como o SmartScan fazem com que MUITAS VEZES 
o acesso via full table scan seja ENORMEMENTE MAIS PERFORMÁTICO do que acesso 
via índice - de repente, se o teu aplicativo tinha sido desenvolvido para 
não-Exadata, quem nos garante que (digamos) não tenha um HINTs "forçando" uso 
de índice e assim não se aproveitando das melhorias enormes do Exadata ??? 
http://cdn.swcdn.net/creative/pdf/Whitepapers/Oracle_Exadata_Performance_WP_Confio_May2014.pdf
 , http://kerryosborne.oracle-guy.com/papers/Tuning%20Exadata.pdf , 
http://blog.tanelpoder.com/files/Tanel_Poder_Drilling_Deep_Into_Exadata_Performance.pdf
 e 
https://www.doag.org/formes/pubfiles/5217229/docs/Konferenz/2013/vortraege/Oracle%20Datenbank/2013-DB-Joze_Senegacnik-Does_Exadata_Need_Performance_Tuning_-Manuskript.pdf
 falam um pouco sobre esse (pra quem é veterano em outros ambientes) estranho 
conceito de no caso do Exadata vc PREFERIR acessos via table scan mas com os 
recursos do Exa ativos
 
 []s
 
   Chiappa
  

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

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

Grande Chiappa...estava doente e retornei as atividades somente hoje...por isso 
não respondi antes :-( 

 Começarei a fazer uma analise mais precisa, de acordo com a suas recomendações.
 

 Relmente fiquei um pouco confuso sobre este evento, imaginando que a tabela 
poderia estar com algum lock X quantidades de acessos a ela.
 

 O estranho é que no ambiente antigo (antes do Exadata), este evento não 
aparecia.
 

 Bom, seguirei aqui suas recomendações...ficarei focado hoje para resolver isso.

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) 

[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