Chiappa, bom dia! Concordo com você, quando eu abro chamados na Oracle procuro postar o máximo de informações possível.
Apenas para conhecimento de todos, como até o momento nem a Oracle e nem nós, conseguimos resolver o problema de performance foi feito um novo ambiente com a versão 10.2.0.4 e tudo voltou como era antes da atualização. Como o ambiente 10.2.0.5 foi mantido, vamos continuar trabalhando com a Oracle para achar a solução para o problema. Abs. -- R.P. DBA Oracle Oracle Database 11g Administrator Certified Professional Oracle Database 10g Real Applications Clusters AdministratorCertified Expert Oracle Enterprise Linux Certified Implementation Specialist Oracle Database 11g Administrator Certified Associate From: José Laurindo <jlchia...@yahoo.com.br> Reply-To: <oracle_br@yahoogrupos.com.br> Date: Wed, 13 Jul 2011 21:39:53 -0000 To: <oracle_br@yahoogrupos.com.br> Subject: [oracle_br] Trabalhando com o Suporte - ref.Problemas Após aplicação do Patch 10.2.0.5 Colega, provavelmente (dada a urgência) vc já deve ter tomado ações do tipo, pro seu caso o que vou dizer não serve, mas se vc não se importa, vou usar o teu caso pra dar umas dicas de trabalho mais eficiente/efetivo com o Suporte da Oracle, principalmente quando se investiga performance e/ou possibilidade de bugs - fica de Registro para outros eventuais leitores desta thread.... O primeiro ponto é , mais de uma vez já escutei opiniões do tipo : "ah, eu já pago uma baba pro Suporte da Oracle, então eles que se virem pra me responder, se precisarem de algo que peçam, não vou fazer a Menor análise pra eles, não vou ´mastigar' nada, E se não responderem de bate-pronto escalo & chamo o gerente da conta..." - ok, é uma opinião e um procedimento perfeitamente aceitável / compreensível em vista das circunstâncias, Mas na minha experiência eu tenho notado que de modo geral uma abordagem proativa e de trabalho Conjunto funciona muitíssimo melhor : assim, ao abrir o Chamado, já passar os resultados de um RDA , um oswatcher, dos reports disponíveis (como AWR, ASH, ADDM, StatsPack), já passar os logs todos (além do alert.log o INVENTÁRIO e o DBA_REGISTRY, pro Analista saber o que está ou não Aplicado, e quando) , quando identificado um SQL culposo já passar o Plano real e completo (não o estimado via EXPLAIN PLAN, mas o REAL, tirado das V$SQL ou dum trace+tkprof - e dos DOIS cenários no seu caso, do SQL "rápido" acessando diretamente e do "lento" via view, e com e sem o ANSI join também), já ter Pesquisado os bugs possíveis e os apontar pro Analista, tudo isso são coisas que Aceleram muito o Service Request na Oracle... Inclusive, usando um pouco de cinismo, um efeito interessante dessa linha de ação é que vc "tira" do analista júnior que está Atendendo o teu chamado a chance de ficar pedindo por log ou pelo que for só pra ganhar tempo.... É aquele negócio, ao vc tentar adiantar um pouco o lado do analista, não só vc poupa o longo fluxo de solicitações (que consomem tempo), como Também é muito , mas Muito mais fácil de vc escalar o chamado, vc bate neles com razão, vc mete um update lá no SR tipo "vide Notas e informações anteriores não-respondidas... Outras dicas que me ajudam em muito : a. SRs bem-feitos (ie, criados na área correta (e Não usando a opção 'General Issues", com um histórico Preciso, evidenciando exatamente quando e onde o problema começou, citando as versões Exatas e Completas não só do banco mas de softwares outros que vc tenha - tipo ASM, CRS -, e versões certinhas do SO, do hardware e do software de Storage, citando sempre Pelo Nome o servidor Oracle , o SID, o PATH, a ORACLE_HOME ) já são meio caminho andado b. sempre, sempre, sempre que Minimamente possível abrir o SR em Inglês : o pessoal de tradução na Oracle até que trabalha bem, mas Tradução sempre representa um delay c. ao fazer o Upload de arquivos, sempre coloque na descrição uma especificação completa pro analista , tipo : este Arquivo é um relatório AWR englobando os snapshots x até y , do perído tal hora tal até o período tal2, hora tal2, quando a Issue estava Acontecendo ==> Na minha colocação atual, como DBA de Produção, eu uso bastante o Suporte e posso realmente confirmar que essas coisas acima consomem tempo (tanto que eu levo pelo menos meia hora pra completar a abertura de um SR, o que meu chefe sempre Abomina) , MAS o resultado dos SRs via de regra é muitíssimo Superior ao que outros colegas da minha célula obtém ... []s Chiappa --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , José Laurindo <jlchiappa@...> escreveu > > Colega, PRIMEIRA COISA : vc foi AUTORIZADO pela Oracle a habilitar o tal param, foi CONFIRMADO o tal bug ??? Mexer nos params internos SEM uma indicação Precisa e Direta do Suporte não é, De Forma Alguma, algo Recomendado / Recomendável... > > Sobre a pergunta, na verdade eu já peguei, num cliente do interior de SP há uns anos (com 10.2.0.4 na ocasião) situação aonde os tempos/execução/planos eram diferentes ao se executar a query diretamente e/ou num bloco anônimo versus executar via view, não é tão estranho assim : o que ocorre é que quando vc faz um SELECT colunas FROM VIEW , Automaticamente o que o banco de dados vai receber e interpretar/otimizar é um SELECT com sub-query tipo : > > SELECT * FROM (select colunas from query da view); > > e haviam na ocasião uns tantoss quantos bugs referentes à sub-query, basicamente o que havia é que quando vc tem sub-query o otimizador pode optar por otimizar a query interna OU a externa primeiro, ou mesmo fazer um MERGE das duas, e ele estava fazendo escolhas inapropriadas.... Na ocasião pra um caso a gente tinha one-off patch, e pra outro a gente contornou com parâmetros que indicavam pro Otimizador uma ordem ao trabalhar com subqueries, tal como o _UNNEST_SUBQUERY e o _COMPLEX_VIEW_MERGING , mas vc está Absolutamente certo em pedir Escalonamento, troca de Analista e o que puder, pra receber uma análise antes de sair mexendo em params internos... > > Outra possibilidade, tal como eu falei, é testar os mesmos itens sem ANSI JOINs : talvez se tentar criar uma view com outro nome mas com Exatamente o mesmo SQL original, apenas usando sintaxe Oracle ao invés de ANSI, isso seria uma Clara indicação se é mesmo bug do ANSI ou bug de inner query causada pelo acesso via view... > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , RP <pradelarf@> escreveu > > > > Chiappa, boa tarde! > > > > Grato pelas informações, o bug 9236988 eu já habilitei o o _FIX_CONTROL que > > contorna ele, o ambiente melhorou, mas ainda continua ruim. > > Até o momento o atendente da Oracle está apenas solicitando informações, se > > até as 15 horas não houver resposta vou escalonar o chamado, pois a situação > > está critica. > > A view utilizada tem vários hints colocados pelo programador, fiz vários > > testes, e estranhamente quando eu rodo um bloco PL/SQL Anônimo, com o select > > executado pelo usuário, a resposta é instantânea. Segue hints: > > /*+ FIRST_ROWS index > > (ix_profisatend_atendreg,ix_atend_dataatend,ix_pacatend_atendreg) */ > > > > Fiz um teste tirando os hints e e tentando alguns diferentes, mas o > > resultado foi pior. > > Bom vou ficar no aguardo da Oracle, e assim que tiver resposta irei > > compartilhar com a comunidade. > > > > Caso alguém tenha enfrentado algo parecido, a informação será bem vinda. > > > > ABS. > > -- > > R.P. > > DBA Oracle > > Oracle Database 11g Administrator Certified Professional > > Oracle Database 10g Real Applications Clusters AdministratorCertified Expert > > Oracle Enterprise Linux Certified Implementation Specialist > > Oracle Database 11g Administrator Certified Associate > > > > From: José Laurindo <jlchiappa@> > > Reply-To: <oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > > Date: Wed, 13 Jul 2011 14:45:33 -0000 > > To: <oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > > Subject: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { > > Urgente } > > > > > > > > > > > > > > Ah sim, agora tá melhor explicado : uma coisa é dizer que tá mal > > genericamente, que o problema é um consumo de I/O geral maior, outra é ter > > cercado e localizado o problema... > > > > okdoc, se vc cercou/localizou e se refere à view com ANSI join, não deixe de > > verificar bugs e issues sobre isso : na verdade há diversas situações de > > diferença de otimização ao se usar ANSI join - em tese deveria ser > > rigorosamente o mesmo que usar a sintaxe antiga mas nem sempre isso ocorre , > > como mostrado em http://www.dbaportal.eu/?q=node/183 e > > http://hoopercharles.wordpress.com/2010/12/30/ansi-full-outer-join-ready-or- > > not/ ... Não deixe de sinalizar isso para o Analista que está te atendendo, > > pois já são de conhecimento alguns bugs com ANSI joins só resolvidos no 11g, > > como o Bug 9395765 - ORA-907 / wrong plan from query with ANSI FULL OUTER > > join [ID 9395765.8] e o Bug 9236988 Suboptimal execution plans with ANSI > > joins, views and fix for bug 7345484 enabled, por exemplo.... > > > > Outro ponto que o Analista que está te atendendo tem TOTAL OBRIGAÇÃO de > > dizer se cabe ou não é que há Diversos parâmetros que podem ser usados como > > work-around (tal como o _PUSH_JOIN_PREDICATE , > > _OPTIMIZER_COST_BASED_TRANSFORMATION, _OPTIMIZER_NATIVE_FULL_OUTER_JOIN, > > _OPTIMIZER_JOIN_ELIMINATION_ENABLED , _COMPLEX_VIEW_MERGING _FIX_CONTROL e > > outros) , e HINTs... > > > > penso que está Claro então o seu plano de Ação , vc tem que : > > > > 1. obter do Analista Oracle a resposta se qquer dos bugs acima está > > envolvido : inclusive, Notar que isso o SQLT *** absolutamente *** não vai > > dizer, então (repito) cobre essa análise do Analista Oracle, se for preciso > > Escale o chamado, acione o Gerente de conta, vc Tem Que obter essa resposta > > > > 2. se 1. identificou algum bug, fatalmente deve haver work-around de > > parâmetro e/ou hint, isso tem que ser verificado > > > > 3. como TESTE (evidentemente num ambiente de homologação), experimentar > > re-escrever a view usando JOIN na sintaxe Oracle ao invés de ANSI. > > > > []s > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> <mailto:oracle_br%40yahoogrupos.com.br> > > , RP <pradelarf@> escreveu > > > > > > Chiappa, bom dia! Grato pelas informações. > > > > > > Eu me expressei mal, realmente o plano de execução mudou, com algumas > > > parametrizações que fiz ontem o problema foi amenizado, porem não resolvido. > > > O problema se concentra basicamente em um select, o mesmo faz acesso a uma > > > view com ANSI Join, notei que o mesmo utiliza algumas variáveis bind e > > > algumas literais, não sei bem o motivo. Apenas para entendimento eu não > > > trabalho na empresa em questão, minha consultoria tem um contrato de hora > > > mensais para eventuais problemas, porem eu não atuo neste ambiente somente > > > em caso de problemas, por este motivo tenho pouco conhecimento das > > > aplicações. > > > Antes da aplicação do patch eu verifiquei o doc 1087991.1, não encontrei > > > nenhum problema que se encaixasse no ambiente. > > > > > > Neste momento estou com um chamado na Oracle, prioridade 1, eles solicitaram > > > a execução do SQLT para verificar as informações do select problemático. > > > > > > Grato pela ajuda, assim que tiver alguma resposta da Oracle, posto para > > > ficar documentado. > > > ABS. > > > -- > > > R.P. > > > DBA Oracle > > > Oracle Database 11g Administrator Certified Professional > > > Oracle Database 10g Real Applications Clusters AdministratorCertified Expert > > > Oracle Enterprise Linux Certified Implementation Specialist > > > Oracle Database 11g Administrator Certified Associate > > > > > > From: José Laurindo <jlchiappa@> > > > Reply-To: <oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > <mailto:oracle_br%40yahoogrupos.com.br> > > > > Date: Tue, 12 Jul 2011 23:47:41 -0000 > > > To: <oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> <mailto:oracle_br%40yahoogrupos.com.br> > > > > Subject: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { > > > Urgente } > > > > > > > > > > > > > > > > > > > > > "..., acredito que tenham alterado os planos de execução dos SQLs." > > > > > > ESTA é a parte que deve estar te complicando : vc DEVERIA ser totalmente > > > capaz de responder isso, é Mais que recomendado se manter arquivado os > > > Planos de execução (dos principais SQLs ao menos) , não só antes de Qualquer > > > patch mas Rotineiramente... Não o tendo feito, vc vai estar no escuro, não é > > > de forma alguma um procedimento recomendado/recomendável.... > > > > > > O que vc pode tentar fazer nesta situação atual é : > > > > > > a. (** SE ** vc tem AWR ativado e ** SE ** vc tem acesso/licença pra isso, e > > > ** SE ** o upgrade foi recente e vc ainda tem os snapshots presentes ) é > > > buscar nas tabelas do histórico do AWR (ie, DBA_HIST_SQLTEXT e > > > DBA_HIST_SQL_PLAN) e ver se encontra pra ao menos alguns casos principais / > > > importantes os planos de antes do upgrade e comparar com os planos atuais > > > > > > b. tentar buscar nas tabs/views do ASH (ie, > > > v$active_sess_hist/dba_hist_active_sess_history , dba_hist_sys_time_model, > > > v$event_histogram, v$active_sess_hist view, wrh$active_session_history) um > > > histórico de estatísticas do sistema e de sessões, pra comparar com o que vc > > > tem hoje, assim confirmando ou negando teu diagnóstico de I/O excessivo > > > > > > c. consultar no metalink a nota "10.2.0.5 Patch Set - Availability and Known > > > Issues" (Doc ID 1087991.1) e ver se vc est´[a caindo num dos casos > > > conhecidos > > > > > > d. analisar pela V$SQL os SQLs mais consumidores de recursos e ver se eles > > > tem alguma característica em comum (por exemplo, na maioria dos casos usam > > > ANSI JOIN, não usam BIND variables, etc, etc) : a idéia aqui é tentar cercar > > > a causa de comportamento dos SQLs > > > > > > []s > > > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> <mailto:oracle_br%40yahoogrupos.com.br> > > <mailto:oracle_br%40yahoogrupos.com.br> > > > , "R P" <pradelarf@> escreveu > > > > > > > > Senhores, boa noite! > > > > > > > > Este final de semana atualizei um o patch e um CPU de um banco de dados, > > após > > > isto estou enfrentando sérios problemas de performance, segue descrição do > > > ambiente: > > > > SO: Oracle Enterprise Linux 5.3 64bit > > > > RBMS: 10.2.0.5 + PSU Abril 2011 Anteriormente era 10.2.0.4 PSU October > > > 2009. > > > > Single Instance. Standand Edition. > > > > > > > > Após a aplicação destes Patches o I/O do servidor aumentou muito, acredito > > que > > > tenham alterado os planos de execução dos SQLs. > > > > Durante a aplicação do patch o único parâmetro alterado foi o COMPATIBLE de > > > 10.2.0.4 para 10.2.0.5. > > > > Devido a estes problemas, hoje e ontem durante o dia fiz testes com vários > > > parâmetros, porem nenhum apresentou o resultado esperado. Segue o que foi > > > alterado: > > > > "_GBY_Hash_Aggregation_Enabled"=FALSE ID:7612454.8 > > > > "_fix_control"='7345484:off' - ID: 567171.1 > > > > optimizer_features_enable estava em 10.2.0.4, tentei setar para 9.2.0.8 e > > > 10.2.0.5, porem não resolveu meu problema, então voltei para 10.2.0.4. > > > > > > > > > > > > No aguardo de alguma ajuda. > > > > > > > > > > > > -- > > > > R.P. > > > > DBA Oracle > > > > Oracle Database 11g Administrator Certified Professional > > > > Oracle Database 10g Real Applications Clusters AdministratorCertified Expert > > > > Oracle Enterprise Linux Certified Implementation Specialist > > > > Oracle Database 11g Administrator Certified Associate > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas]