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
