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, 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, 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>
> > Date: Wed, 13 Jul 2011 14:45:33 -0000
> > To: <oracle_br@yahoogrupos.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>
> > , 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> >
> > > Date: Tue, 12 Jul 2011 23:47:41 -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 }
> > >
> > >
> > >
> > >
> > >
> > >
> > > "..., 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>
> > > , "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]
> >
>
