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]
>
