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]" <oracle_br@yahoogrupos.com.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) 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 caminho ** muito possível ** , já que estamos falando de latch
controlado por default via MUTEXes no 11g em diante, é usar a
GV$MUTEX_SLEEP_HISTORY , mais ou menos cfrme
http://oracledbascriptsfromajith.blogspot.com.br/2015/09/oracle-cursor-pin-s-wait-on-x-wait-event.html
mostra...
[]s
Chiappa #yiv2539423796 #yiv2539423796 -- #yiv2539423796ygrp-mkp
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0
10px;}#yiv2539423796 #yiv2539423796ygrp-mkp hr {border:1px solid
#d8d8d8;}#yiv2539423796 #yiv2539423796ygrp-mkp #yiv2539423796hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv2539423796 #yiv2539423796ygrp-mkp #yiv2539423796ads
{margin-bottom:10px;}#yiv2539423796 #yiv2539423796ygrp-mkp .yiv2539423796ad
{padding:0 0;}#yiv2539423796 #yiv2539423796ygrp-mkp .yiv2539423796ad p
{margin:0;}#yiv2539423796 #yiv2539423796ygrp-mkp .yiv2539423796ad a
{color:#0000ff;text-decoration:none;}#yiv2539423796 #yiv2539423796ygrp-sponsor
#yiv2539423796ygrp-lc {font-family:Arial;}#yiv2539423796
#yiv2539423796ygrp-sponsor #yiv2539423796ygrp-lc #yiv2539423796hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2539423796
#yiv2539423796ygrp-sponsor #yiv2539423796ygrp-lc .yiv2539423796ad
{margin-bottom:10px;padding:0 0;}#yiv2539423796 #yiv2539423796actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2539423796
#yiv2539423796activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2539423796
#yiv2539423796activity span {font-weight:700;}#yiv2539423796
#yiv2539423796activity span:first-child
{text-transform:uppercase;}#yiv2539423796 #yiv2539423796activity span a
{color:#5085b6;text-decoration:none;}#yiv2539423796 #yiv2539423796activity span
span {color:#ff7900;}#yiv2539423796 #yiv2539423796activity span
.yiv2539423796underline {text-decoration:underline;}#yiv2539423796
.yiv2539423796attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv2539423796 .yiv2539423796attach div a
{text-decoration:none;}#yiv2539423796 .yiv2539423796attach img
{border:none;padding-right:5px;}#yiv2539423796 .yiv2539423796attach label
{display:block;margin-bottom:5px;}#yiv2539423796 .yiv2539423796attach label a
{text-decoration:none;}#yiv2539423796 blockquote {margin:0 0 0
4px;}#yiv2539423796 .yiv2539423796bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2539423796
.yiv2539423796bold a {text-decoration:none;}#yiv2539423796 dd.yiv2539423796last
p a {font-family:Verdana;font-weight:700;}#yiv2539423796 dd.yiv2539423796last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2539423796
dd.yiv2539423796last p span.yiv2539423796yshortcuts
{margin-right:0;}#yiv2539423796 div.yiv2539423796attach-table div div a
{text-decoration:none;}#yiv2539423796 div.yiv2539423796attach-table
{width:400px;}#yiv2539423796 div.yiv2539423796file-title a, #yiv2539423796
div.yiv2539423796file-title a:active, #yiv2539423796
div.yiv2539423796file-title a:hover, #yiv2539423796 div.yiv2539423796file-title
a:visited {text-decoration:none;}#yiv2539423796 div.yiv2539423796photo-title a,
#yiv2539423796 div.yiv2539423796photo-title a:active, #yiv2539423796
div.yiv2539423796photo-title a:hover, #yiv2539423796
div.yiv2539423796photo-title a:visited {text-decoration:none;}#yiv2539423796
div#yiv2539423796ygrp-mlmsg #yiv2539423796ygrp-msg p a
span.yiv2539423796yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv2539423796
.yiv2539423796green {color:#628c2a;}#yiv2539423796 .yiv2539423796MsoNormal
{margin:0 0 0 0;}#yiv2539423796 o {font-size:0;}#yiv2539423796
#yiv2539423796photos div {float:left;width:72px;}#yiv2539423796
#yiv2539423796photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv2539423796
#yiv2539423796photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv2539423796
#yiv2539423796reco-category {font-size:77%;}#yiv2539423796
#yiv2539423796reco-desc {font-size:77%;}#yiv2539423796 .yiv2539423796replbq
{margin:4px;}#yiv2539423796 #yiv2539423796ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv2539423796 #yiv2539423796ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv2539423796
#yiv2539423796ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv2539423796
#yiv2539423796ygrp-mlmsg select, #yiv2539423796 input, #yiv2539423796 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv2539423796
#yiv2539423796ygrp-mlmsg pre, #yiv2539423796 code {font:115%
monospace;}#yiv2539423796 #yiv2539423796ygrp-mlmsg *
{line-height:1.22em;}#yiv2539423796 #yiv2539423796ygrp-mlmsg #yiv2539423796logo
{padding-bottom:10px;}#yiv2539423796 #yiv2539423796ygrp-msg p a
{font-family:Verdana;}#yiv2539423796 #yiv2539423796ygrp-msg
p#yiv2539423796attach-count span {color:#1E66AE;font-weight:700;}#yiv2539423796
#yiv2539423796ygrp-reco #yiv2539423796reco-head
{color:#ff7900;font-weight:700;}#yiv2539423796 #yiv2539423796ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv2539423796 #yiv2539423796ygrp-sponsor
#yiv2539423796ov li a {font-size:130%;text-decoration:none;}#yiv2539423796
#yiv2539423796ygrp-sponsor #yiv2539423796ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv2539423796
#yiv2539423796ygrp-sponsor #yiv2539423796ov ul {margin:0;padding:0 0 0
8px;}#yiv2539423796 #yiv2539423796ygrp-text
{font-family:Georgia;}#yiv2539423796 #yiv2539423796ygrp-text p {margin:0 0 1em
0;}#yiv2539423796 #yiv2539423796ygrp-text tt {font-size:120%;}#yiv2539423796
#yiv2539423796ygrp-vital ul li:last-child {border-right:none
!important;}#yiv2539423796
