Re: [oracle_br] Trabalhando com o Suporte - ref.Problemas Após aplicação do Patch 10.2.0.5
Tivemos um problema semelhante em um cliente. A aplicação rodava perfeitamente na versão 10.2.0.3, só que quando migramos para 10.2.0.5 algumas rotinas ficaram impraticávelmente lentas, depois de uma análise descobrimos que a versão estava na 10.2.0.3, mas o otimizador estava setado para 9.2.0.8, aí a aplicação funcionava ok. Quando fomos para 10.2.0.5, o otimizador foi para 10.2.0.5 junto. Abrimos chamado com a Oracle também, mas... para resolver o problema em vez de montar um novo ambiente, apenas voltamos o otimizador para 9.2.0.8, e a aplicação ficava normal. Pode ser que te ajude também, enquanto você resolve com a Oracle, é mais simples que ter mais de 1 ambiente. alter system set optimizer_features_enable='9.2.0.8'; alter system set optimizer_features_enable='10.2.0.5'; Abraços. Gerson S. de Vasconcelos Júnior OCA DBA - Oracle Certified Associate Fone: (81) 9816-0236 Msn: gerson.vasconce...@gmail.com Skype: gersonvjunior http://www.diaadiaoracle.com.br/ Em 15 de julho de 2011 09:10, RP escreveu: > ** > > > 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 > Reply-To: > Date: Wed, 13 Jul 2011 21:39:53 - > To: > 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
Re: [oracle_br] Trabalhando com o Suporte - ref.Problemas Após aplicação do Patch 10.2.0.5
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 Reply-To: Date: Wed, 13 Jul 2011 21:39:53 - To: 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 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/pl
[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, José Laurindo 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 > pude
