Re: [oracle_br] Re: Cursor: pin S wait on X - Apó s migração para novo ambiente
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
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
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
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
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
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?