Re: [oracle_br] Library Cache Pin - Ajustando Shared_Pool
Aproveitando o tópico, vou repassar uma explicação sobre latches que eu redigi para meu TCC sobre redução de hard parses. É menos técnica/detalhista do que já foi enviado, mas acredito que dá uma boa idéia para quem não conhece e quer entender o conceito. Depois é só se aprofundar no assunto. Vai que é útil pra alguém aí... /*2.1 Latches*/ /**/ /**/ /Latché um mecanismo de alocação de estruturas na memória SGA serializado e desenhado para que sejam alocados por curtos períodos de tempo. Ele controla os vários processos que desejam acessar áreas compartilhadas da SGA, permitindo que somente um processo de cada vez acesse a estrutura requisitada, evitando corrupção da memória, ou seja, mantendo a integridade./ // /Latchnão implementa fila de espera, como acontece com outros tipos de locks (travas). Se, ao tentar obter um latch, é identificado que outro processo já o obteve, sua sessão irá aguardar algum tempo e, depois, tentará novamente obter o latch. Quando o latch for liberado pelo processo que o obtinha, se houver vários processos que precisam do mesmo latch, o primeiro processo que solicitá-lo após a liberação terá sucesso, os demais continuarão tentando aleatoriamente até conseguir ou até esgotar o tempo de tentativas./ // /Atente-se que não houve fila de espera, pode ser que o primeiro processo que chegou para obter o latch bloqueado não seja o primeiro a consegui-lo após a liberação do latch./ // /Quando um processo fica em loop tentando obter o latch e há várias sessões tentando a mesma coisa, tal processo ficará um tempo ocupando CPU na esperança que o latch seja liberado logo (como o latch foi desenhado para durar curtos períodos, presume-se que a chance de ser liberado em breve é alta). Somente após algum tempo em CPU tentando obter o latch e falhando, o processo liberará a CPU e tentará de novo mais tarde. Isso indica, normalmente, um cenário em que há várias sessões tentando obter o mesmo latch, ao invés de uma sessão única alocando o latch por um longo tempo, como acontece com outros tipos de locks./ // /Tanto essa espera na CPU quanto a saída e a volta para a CPU para tentar novamente são gastos com recursos primários devem ser evitados, se possível./ / Hard parse é uma operação que utiliza latches para ser completada. Portanto temos a seguinte relação: quanto mais hard parses, mais latches. Aumentar o número de latches significa ter mais processos alocando as estruturas compartilhadas da memória (alta concorrência) e, consequentemente, aumenta a chance de que outro processo tenha que aguardar para obter seu latch ao invés de obtê-lo instantaneamente./ / Portanto, quanto menos hard parses, menos latches, maior a chance de um processo obter seu latch instantaneamente (baixa concorrência), menor a chance de espera, mais rápido será o fluxo através dos mecanismos internos e mais rápido será o término da operação executada (no caso, o processamento do comando SQL)./ / / On 08/06/2011 12:23, ammorrimm wrote: > > Amigos, > > Estou iniciando algumas analise na minha Shared_Poll, mais > precisamente na Library Cache pois tenho verificado alguns pequenos > latchs e gostaria de uma ajuda... > > Pelo que entendo e andei lendo, este lacth esta relacionado a execução > ou compilação de PL / SQL e a interpretação destes, ficam armazenados > nesta área de memória. > > Qual seria a melhor maneira de analisar esta questão e saber quais são > os objetos que precisariam ser revistos ? > > Este latch esta sempre relacionado a performance do objetos a nível de > parse? Ou seja, quanto mais reparsing pior será o cenário ? > > -- Atenciosamente, - Paulo Henrique P. da Silva [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Library Cache Pin - Ajustando Shared_Pool
ammorrimm , vou aproveitar o seu e-mail e dar umas dicas, que aí já serve não só pra vc como pra outros que estejam com dúvidas similares. Primeiro, quando vc pede por um "procedimento", por um "aprendizado" de como proceder em relação à latches, eu vou repetir algo que já disse muitas vezes mas continua Verdadeiro a mais não poder, que é : SEJA o que for no rdbms Oracle que vc quer tunar, o setp ZERO, o pré-requisito, é conhecer os Conceitos do tópico em questão, okdoc ? Com isso em mãos E com o conhecimento da Aplicação que vc quer melhorar (tudo que vc puder saber dela : como ela se conecta no banco, se é OLTP ou BATCH, quantos usuários simultãneos, se há objetos mais usados que outros, como os objetos são usados tipicamente, como se faz limpeza de dados, como os dados entram, retenção, enfim, TUDO o que puder) aí sim vc pode começar a avaliar as opções... Vamos então dar um vapt-vupt sobre LATCHES em primeiro lugar : a documentação (e no metalink as notas What are Latches and What Causes Latch Contention (Doc ID 22908.1) - esta uma Crucial no assunto imho - além da Solutions for possible AWR Library Cache Latch Contention Issues in Oracle 10g (Doc ID 296765.1) e a Understanding and Tuning the Shared Pool and Tuning Library Cache Latch Contention (Doc ID 62143.1) aprofundam as refs e dão excelentes sugestões e definições mas vamos dar um geralzinha. No caso vamos falar de bloco, que é o recurso mais comum protegido por latch, E ainda há pontos como o tipo de request do latch (se willing-to-waiting ou não), há bem mais aí nesse angú, mas vamos falar mais basicamente... Seguinte, como o rdbms Oracle é multi-usuário (foi PENSADO para permitir múltiplas sessões simultâneas E com integridade - nada de leitura suja, de dados que podem ter sido alterados !!) , é absolutamente crítico que nos milisegundos enquanto um bloco estiver sendo lido ninguém o altere (quem quiser alterar TEM que esperar a leitura acabar pra não alterar o que está sendo lido, E que nos milisegundos enquanto o bloco estiver sendo gravado quem quiser ler o bloco tem que esperar a gravação acabar : o mecanismo que o rdbms Oracle implementa pra isso é o LATCH, que nada mais é do que um FLAG, um Indicador em memória (uma variável se vc quiser pensar assim) que quando vazia indica que o recurso está livre, quando não vazia indica que está em uso - e isso (com as execções óbvias, tipo GTT) vale *** PARA PRATICAMENTE QUALQUER I/O , seja para I/O de bloco vindo do disco, seja pra I/O de bloco já em cache... Assim, TODAS as sub-rotinas no rdbms Oracle foram programadas de modo que antes que um I/O seja feito num bloco qquer, pesquisa-se se o LATCH que aponta para/protege o recurso tá disponível, se estiver vazio, disponível, a sessão obtém o latch (marca-o como Em uso) e aí sim faz o I/O , e enquanto isso todas as sessões que quiserem usar esse bloco nesses milisegundos em que o bloco está em uso pot outrem vão tentar obter o latch (marcá-lo com em uso), não vão conseguir , aí vão entrar no que se chama SPIN : vão "dormir" por uns milisegundos, tentam de novo, se ainda não tá livre o latch vão dormir de novo, assim por diante, por um número pré-definido de vezes (normalmente entre 10 a 16 vezes , isso varia de acordo com a versão do banco, e pode ser alterado via params ocultos) : e se após passar por todos os SPINS possíveis ainda assim a sessão não obteve o latch, aí ela passa pra espera Passiva mesmo, ie : fica pendurada esperando até o latch ser liberado . Muito bem : com esses pontos em vista algumas conclusões devem começar a cair nos seus lugares. Por exemplo, sobre aumento de cache - a idéia do cache é que o I/O seja feito da RAM ao invés do disco, o que via de regra é muito mais rápido, aí a sessão que tem o latch mais rapidamente o libera pros outros usar A teoria é boa, MAS sabemos nós que a teoria de caching é implacável : caches não são mágicos, eles funcionam muito bem SE vc está lendo a mesma informação repetidas vezes : SE, como é comum por exemplo em aplicações DW, vc faz scans frequentes, a cada vez vc normalmente está acessando dados diferentes , Com Certeza nesse ambiente o cache não vai te comprar lá grande coisa Sacou porque realmente DEPENDE MUITO do seu ambiente, do SEU caso particular se vai ser efetivo ou não vc aumentar caches ?/ Então bote Sempre um grão de sal nessas recomendações genéricas, okdoc ?? E TESTE, TESE e TESTE, sempre... Segundo : como eu falei e REPITO, praticamente TODOS os I/Os (e acessos a outros recursos, mas I/O principalmente é o caso + comum) Necessariamente Tem que ser protegido por latch, Então temos que : a. óbvio ululante, para diminuir latches, dimunua os I/Os, simples assim Isso se faz com Tuning de SQL (alterando-se o SQL pra ser o mais eficiente possível, retornando os dados com o menor número de blocos acessados), E/OU com Tuning de estruturas físicas (assegurando-se que onde possível/viável
Re: [oracle_br] Re: Library Cache Pin - Ajustando Shared_Pool
Dá uma lida no Performance Guide. "7.3.1 Shared Pool Concepts" em diante http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/memory.htm#i30970 2011/6/8 ammorrimm > > > Tenho um banco 11G...na verdade nem queria nada rapido...só aprender mesmo > a analisar este lacth > > Fico meio na dúvida da analise pois ja li documentações onde diziam que a > mesma é atribuída a PL/ SQL mal formatados e que precisavam sofrer reparze e > outros que diziam que aumentando a shared_pool já surtira um efeito > desejado... > > Tudo muito nuito achismoentão, nao sei por onde começo a analise... > > --- Em oracle_br@yahoogrupos.com.br, Rafael Trevisan escreveu > > > > > Seu banco é 10g ou superior? Se for, voce pode baixar o Mandela (www > mandela > > org) e identificar através do Wait Event Breakdown os comandos SQL > > impactados pelo latch e os objetos ofensores (candidatos a otimização). > > > > É a forma mais rápida que eu conheço. > > > > Abraços! > > > > -- > > Rafael Trevisan > > > > On 08/06/2011, at 12:24, ammorrimm wrote: > > > > > > > > Amigos, > > > > Estou iniciando algumas analise na minha Shared_Poll, mais precisamente > na > > Library Cache pois tenho verificado alguns pequenos latchs e gostaria de > uma > > ajuda... > > > > Pelo que entendo e andei lendo, este lacth esta relacionado a execução ou > > compilação de PL / SQL e a interpretação destes, ficam armazenados nesta > > área de memória. > > > > Qual seria a melhor maneira de analisar esta questão e saber quais são os > > objetos que precisariam ser revistos ? > > > > Este latch esta sempre relacionado a performance do objetos a nível de > > parse? Ou seja, quanto mais reparsing pior será o cenário ? > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- Hevandro Veiga Oracle Certified Professional 11g OCE RAC 10g [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Antes de indisponibilizar o ambiente, verifique como está a utilização: grep Swap /proc/meminfo grep Total /proc/meminfo 2011/6/8 raulcsneto : > Ivan, > > Com o alerta que o colega JL deu sobre a SWAP, dei uma pesquisada e parece > mesmo que faz muito sentido, hoje a noite irei parar o banco para fazer as > alterações de memória que vocês me recomendaram e amanhã estarei monitorando > o comportamento do banco e espero poder postar aqui um resultado positivo, > quanto ao RAID 0 só utilizo para REDO e ARCHIVES que ja são redundancias, > dados e indices estão com RAID 10, vou dar uma olhada nos links que voce me > passou, muito obrigado pelas dicas!!! > > Abraço > > Raul > > --- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster > escreveu >> >> Raul, >> >> Primeiramente: Não abra mão de segurança para compensar o problema de >> I/O. RAID 0 não é opção para bancos de dados! >> >> Sim, swap é uma grande suspeita, o problema de IO parece não ser >> somente "System", mas geral. >> >> Considere as recomendações dos colegas para ajustar os parametros de >> memória, em geral recomendo a configuração de valores fixos de >> memória, ou ao menos definir valores mínimos para cada item. >> >> Acredito que este Linux seja 64 bits, certo? >> De qualquer forma, você pode considerar a utilização de hugepages em >> seu servidor: >> http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/ >> >> Recomendo ainda que você verifique as dicas em: >> http://www.puschitz.com/TuningLinuxForOracle.shtml >> >> Principalmente no que se refere a ativar Asynchronous I/O, caso o >> ajuste de memória não resolva. >> >> Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela >> Oracle trimestralmente e que corrigem bugs de segurança no seu banco >> de dados. Apesar de não serem patches especificos de desempenho, podem >> corrigir algum problema relacionado. >> >> >> 2011/6/8 Raul Francisco Costa F. de Andrade, DBA : >> > Eu também apostaria em diminuir um pouco a quantidade de memória que está >> > sendo dedicada ao Oracle. >> > A questão do SO estar fazendo SWAP é pertinente... >> > >> > Raul >> > --- >> > *Raul Francisco da Costa Ferreira de Andrade* >> > *DBA - OCP - Oracle Certified Professional* >> > *COBIT Foundation 4.1 >> > Celular:(41)8855-8874 Claro >> > *email: raulfdba@... >> > Skype: raul.andrade >> > msn:raulandrade@... >> > www.clickdba.com >> > >> > *"A adversidade leva alguns a serem vencidos >> > e outros a baterem recordes." * >> > William Arthur Ward >> > >> > >> > >> > Em 8 de junho de 2011 10:46, raulcsneto escreveu: >> > >> >> >> >> >> >> Bom dia Gerson, >> >> Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos >> >> de 143Gb 15.000RPM um para dados e outro para índices (o problema já >> >> ocorria >> >> nesta ocasião) então após ler algumas coisas e conversar com um amigo, que >> >> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 >> >> discos, assim eu teria o dobro de discos para a controladora fazer >> >> Striping >> >> no momento de leitura/gravação talvez, melhorando o problema de I/O, porém >> >> parece que tudo permaneceu como estava (ou seja acho que o problema não >> >> era >> >> disco) >> >> >> >> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior >> >> escreveu >> >> > >> >> > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? >> >> > >> >> > Não seria viável separar? >> >> > >> >> > >> >> > >> >> > >> >> > Gerson S. de Vasconcelos Júnior >> >> > OCA DBA - Oracle Certified Associate >> >> > Fone: (81) 9816-0236 >> >> > Msn: gerson.vasconcelos@ >> >> > Skype: gersonvjunior >> >> > http://www.diaadiaoracle.com.br/ >> >> > >> >> > >> >> > Em 8 de junho de 2011 09:06, raulcsneto escreveu: >> >> >> >> > >> >> > > >> >> > > >> >> > > Bom dia >> >> > > >> >> > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de >> >> > > System I/O, será que alguem poderia me ajudar a verificar a causa >> >> > > deste >> >> > > problema, segue abaixo um resumo do meu cenário e das ações que já >> >> tomei: >> >> > > >> >> > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores >> >> Quad-core >> >> > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o >> >> oracle. >> >> > > >> >> > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID >> >> 10, >> >> > > totalizando 544Gb para Dados e Indices; >> >> > > >> >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID >> >> 0, >> >> > > totalizando 272Gb para Redo; >> >> > > >> >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID >> >> 0, >> >> > > totalizando 272Gb para Archives; >> >> > > >> >> > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados >> >> em >> >> > > Stripes de 512k; >> >> > > >> >> > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação >
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Ivan, Com o alerta que o colega JL deu sobre a SWAP, dei uma pesquisada e parece mesmo que faz muito sentido, hoje a noite irei parar o banco para fazer as alterações de memória que vocês me recomendaram e amanhã estarei monitorando o comportamento do banco e espero poder postar aqui um resultado positivo, quanto ao RAID 0 só utilizo para REDO e ARCHIVES que ja são redundancias, dados e indices estão com RAID 10, vou dar uma olhada nos links que voce me passou, muito obrigado pelas dicas!!! Abraço Raul --- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster escreveu > > Raul, > > Primeiramente: Não abra mão de segurança para compensar o problema de > I/O. RAID 0 não é opção para bancos de dados! > > Sim, swap é uma grande suspeita, o problema de IO parece não ser > somente "System", mas geral. > > Considere as recomendações dos colegas para ajustar os parametros de > memória, em geral recomendo a configuração de valores fixos de > memória, ou ao menos definir valores mínimos para cada item. > > Acredito que este Linux seja 64 bits, certo? > De qualquer forma, você pode considerar a utilização de hugepages em > seu servidor: > http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/ > > Recomendo ainda que você verifique as dicas em: > http://www.puschitz.com/TuningLinuxForOracle.shtml > > Principalmente no que se refere a ativar Asynchronous I/O, caso o > ajuste de memória não resolva. > > Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela > Oracle trimestralmente e que corrigem bugs de segurança no seu banco > de dados. Apesar de não serem patches especificos de desempenho, podem > corrigir algum problema relacionado. > > > 2011/6/8 Raul Francisco Costa F. de Andrade, DBA : > > Eu também apostaria em diminuir um pouco a quantidade de memória que está > > sendo dedicada ao Oracle. > > A questão do SO estar fazendo SWAP é pertinente... > > > > Raul > > --- > > *Raul Francisco da Costa Ferreira de Andrade* > > *DBA - OCP - Oracle Certified Professional* > > *COBIT Foundation 4.1 > > Celular:(41)8855-8874 Claro > > *email: raulfdba@... > > Skype: raul.andrade > > msn:raulandrade@... > > www.clickdba.com > > > > *"A adversidade leva alguns a serem vencidos > > e outros a baterem recordes." * > > William Arthur Ward > > > > > > > > Em 8 de junho de 2011 10:46, raulcsneto escreveu: > > > >> > >> > >> Bom dia Gerson, > >> Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos > >> de 143Gb 15.000RPM um para dados e outro para índices (o problema já > >> ocorria > >> nesta ocasião) então após ler algumas coisas e conversar com um amigo, que > >> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 > >> discos, assim eu teria o dobro de discos para a controladora fazer Striping > >> no momento de leitura/gravação talvez, melhorando o problema de I/O, porém > >> parece que tudo permaneceu como estava (ou seja acho que o problema não era > >> disco) > >> > >> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior > >> escreveu > >> > > >> > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? > >> > > >> > Não seria viável separar? > >> > > >> > > >> > > >> > > >> > Gerson S. de Vasconcelos Júnior > >> > OCA DBA - Oracle Certified Associate > >> > Fone: (81) 9816-0236 > >> > Msn: gerson.vasconcelos@ > >> > Skype: gersonvjunior > >> > http://www.diaadiaoracle.com.br/ > >> > > >> > > >> > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > >> > >> > > >> > > > >> > > > >> > > Bom dia > >> > > > >> > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > >> > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > >> > > problema, segue abaixo um resumo do meu cenário e das ações que já > >> tomei: > >> > > > >> > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores > >> Quad-core > >> > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o > >> oracle. > >> > > > >> > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID > >> 10, > >> > > totalizando 544Gb para Dados e Indices; > >> > > > >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > >> 0, > >> > > totalizando 272Gb para Redo; > >> > > > >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > >> 0, > >> > > totalizando 272Gb para Archives; > >> > > > >> > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados > >> em > >> > > Stripes de 512k; > >> > > > >> > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > >> > > uniforme de 512k com datafiles de 2Gb; > >> > > > >> > > Recentemente movi todas as tabelas e indices para tablespaces novas > >> para > >> > > eliminar a fragmentação; > >> > > > >> > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde > >> está > >> > > o problema, seria de g
Re: [oracle_br] Library Cache Pin - Ajustando Shared_Pool
Seu banco é 10g ou superior? Se for, voce pode baixar o Mandela (www mandela org) e identificar através do Wait Event Breakdown os comandos SQL impactados pelo latch e os objetos ofensores (candidatos a otimização). É a forma mais rápida que eu conheço. Abraços! -- Rafael Trevisan On 08/06/2011, at 12:24, ammorrimm wrote: Amigos, Estou iniciando algumas analise na minha Shared_Poll, mais precisamente na Library Cache pois tenho verificado alguns pequenos latchs e gostaria de uma ajuda... Pelo que entendo e andei lendo, este lacth esta relacionado a execução ou compilação de PL / SQL e a interpretação destes, ficam armazenados nesta área de memória. Qual seria a melhor maneira de analisar esta questão e saber quais são os objetos que precisariam ser revistos ? Este latch esta sempre relacionado a performance do objetos a nível de parse? Ou seja, quanto mais reparsing pior será o cenário ? [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Hevandro, eu ja rodei todos os advisors que o oracle recomendou, tanto os de
SQL quanto os de segmentos. Obrigado!
--- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga escreveu
>
> Raul,
>
> FINDING 1: 73% impact (1355 seconds)
>
> SQL statements consuming significant database time were found.
>
> Problemas com SQLs, já rodou o SQL tuning advisor em cima dessas queries ou
> o SQL Access Advisor no workload?
>
> FINDING 2: 50% impact (934 seconds)
> ---
> The SGA was inadequately sized, causing additional I/O or hard parses.
>
> RECOMMENDATION 1: DB Configuration, 47% benefit (881 seconds)
> ACTION: Increase the size of the SGA by setting the parameter
> "sga_target" to 27648 M.
>
> O Oracle tá te pedindo para aumentar a memória da SGA. Concordo com os
> demais colegas com relação ao SWAP, você deveria reduzir e não aumentar como
> o Oracle tá pedindo. No entanto existe um problema aqui. O optimizer parece
> não conseguir compartilhar os cursores, pode ser falta de variáveis bind,
> excesso de ddl...
>
> SELECT PLAN_HASH_VALUE,COUNT(*)
> FROM V$SQL
> WHERE PARSING_SCHEMA_NAME NOT IN
> ('SYS',
>
>
> 2011/6/8 Ivan Ricardo Schuster
>
> >
> >
> > Raul,
> >
> > Primeiramente: Não abra mão de segurança para compensar o problema de
> > I/O. RAID 0 não é opção para bancos de dados!
> >
> > Sim, swap é uma grande suspeita, o problema de IO parece não ser
> > somente "System", mas geral.
> >
> > Considere as recomendações dos colegas para ajustar os parametros de
> > memória, em geral recomendo a configuração de valores fixos de
> > memória, ou ao menos definir valores mínimos para cada item.
> >
> > Acredito que este Linux seja 64 bits, certo?
> > De qualquer forma, você pode considerar a utilização de hugepages em
> > seu servidor:
> > http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/
> >
> > Recomendo ainda que você verifique as dicas em:
> > http://www.puschitz.com/TuningLinuxForOracle.shtml
> >
> > Principalmente no que se refere a ativar Asynchronous I/O, caso o
> > ajuste de memória não resolva.
> >
> > Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela
> > Oracle trimestralmente e que corrigem bugs de segurança no seu banco
> > de dados. Apesar de não serem patches especificos de desempenho, podem
> > corrigir algum problema relacionado.
> >
> > 2011/6/8 Raul Francisco Costa F. de Andrade, DBA :
> >
> > > Eu também apostaria em diminuir um pouco a quantidade de memória que está
> > > sendo dedicada ao Oracle.
> > > A questão do SO estar fazendo SWAP é pertinente...
> > >
> > > Raul
> > > --
> > > *Raul Francisco da Costa Ferreira de Andrade*
> > > *DBA - OCP - Oracle Certified Professional*
> > > *COBIT Foundation 4.1
> > > Celular:(41)8855-8874 Claro
> > > *email: raulfdba@...
> > > Skype: raul.andrade
> > > msn:raulandrade@...
> > > www.clickdba.com
> > >
> > > *"A adversidade leva alguns a serem vencidos
> > > e outros a baterem recordes." *
> > > William Arthur Ward
> > >
> > >
> > >
> > > Em 8 de junho de 2011 10:46, raulcsneto escreveu:
> > >
> > >>
> > >>
> > >> Bom dia Gerson,
> > >> Até semana passada eu tinha dois volumes separados de RAID 10 com 4
> > discos
> > >> de 143Gb 15.000RPM um para dados e outro para índices (o problema já
> > ocorria
> > >> nesta ocasião) então após ler algumas coisas e conversar com um amigo,
> > que
> > >> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os
> > 8
> > >> discos, assim eu teria o dobro de discos para a controladora fazer
> > Striping
> > >> no momento de leitura/gravação talvez, melhorando o problema de I/O,
> > porém
> > >> parece que tudo permaneceu como estava (ou seja acho que o problema não
> > era
> > >> disco)
> > >>
> > >> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior > ...>
> > >> escreveu
> > >> >
> > >> > Pelo que vi, dados e indices estão no mesmo range de discos, é isso?
> > >> >
> > >> > Não seria viável separar?
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Gerson S. de Vasconcelos Júnior
> > >> > OCA DBA - Oracle Certified Associate
> > >> > Fone: (81) 9816-0236
> > >> > Msn: gerson.vasconcelos@
> > >> > Skype: gersonvjunior
> > >> > http://www.diaadiaoracle.com.br/
> > >> >
> > >> >
> > >> > Em 8 de junho de 2011 09:06, raulcsneto escreveu:
> > >>
> > >> >
> > >> > >
> > >> > >
> > >> > > Bom dia
> > >> > >
> > >> > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas
> > de
> > >> > > System I/O, será que alguem poderia me ajudar a verificar a causa
> > deste
> > >> > > problema, segue abaixo um resumo do meu cenário e das ações que já
> > >> tomei:
> > >> > >
> > >> > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores
> > >> Quad-core
> > >> > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o
> > >> oracle.
> > >> > >
> > >> > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 14
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Desculpe JL, eu realmente não comentei, mas tenho o redo multiplexado tres grupos na area destinada a eles e tres grupos junto com os archives, só os archives que eu mantenho em um unico destino em um RAID 0, quanto aos archives posso adicionar mais um destino em outro volume de discos que tenho disponivel, vou dar uma estudada neste assunto assim que conseguir resolver o problema do I/O, muito obrigado pela dicas!!! --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu > > raul, > ratificando o que o ivan citou, raid 0 para áreas de redolog online e > archives é um risco super alto. > se um desses discos parar de funcionar, no caso da área de redolog, vc > perderá redologs online. > isto significa que o redolog mais recentes, que pode estar não arquivado, > será perdido, consequentemente perderá transações que podem já ter sofrido > commit. > recomendo vc multiplexar os redologs online, utilizando as duas áreas de raid > 0 q vc tem: a de redologs e a de archives. > recomendo também vc colocar 2 destinos de archives, um em cada área novamente. > mas, isto é outro assunto, além desse referente à performance. > boa sorte. > > On Jun 08, 2011, at 11:24 , Ivan Ricardo Schuster wrote: > > > Raul, > > > > Primeiramente: Não abra mão de segurança para compensar o problema de > > I/O. RAID 0 não é opção para bancos de dados! > > > > Sim, swap é uma grande suspeita, o problema de IO parece não ser > > somente "System", mas geral. > > > > Considere as recomendações dos colegas para ajustar os parametros de > > memória, em geral recomendo a configuração de valores fixos de > > memória, ou ao menos definir valores mínimos para cada item. > > > > Acredito que este Linux seja 64 bits, certo? > > De qualquer forma, você pode considerar a utilização de hugepages em > > seu servidor: > > http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/ > > > > Recomendo ainda que você verifique as dicas em: > > http://www.puschitz.com/TuningLinuxForOracle.shtml > > > > Principalmente no que se refere a ativar Asynchronous I/O, caso o > > ajuste de memória não resolva. > > > > Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela > > Oracle trimestralmente e que corrigem bugs de segurança no seu banco > > de dados. Apesar de não serem patches especificos de desempenho, podem > > corrigir algum problema relacionado. > > > > > > 2011/6/8 Raul Francisco Costa F. de Andrade, DBA : > >> Eu também apostaria em diminuir um pouco a quantidade de memória que está > >> sendo dedicada ao Oracle. > >> A questão do SO estar fazendo SWAP é pertinente... > >> > >> Raul > >> --- > >> *Raul Francisco da Costa Ferreira de Andrade* > >> *DBA - OCP - Oracle Certified Professional* > >> *COBIT Foundation 4.1 > >> Celular:(41)8855-8874 Claro > >> *email: raulfdba@... > >> Skype: raul.andrade > >> msn:raulandrade@... > >> www.clickdba.com > >> > >> *"A adversidade leva alguns a serem vencidos > >> e outros a baterem recordes." * > >> William Arthur Ward > >> > >> > >> > >> Em 8 de junho de 2011 10:46, raulcsneto escreveu: > >> > >>> > >>> > >>> Bom dia Gerson, > >>> Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos > >>> de 143Gb 15.000RPM um para dados e outro para índices (o problema já > >>> ocorria > >>> nesta ocasião) então após ler algumas coisas e conversar com um amigo, que > >>> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 > >>> discos, assim eu teria o dobro de discos para a controladora fazer > >>> Striping > >>> no momento de leitura/gravação talvez, melhorando o problema de I/O, porém > >>> parece que tudo permaneceu como estava (ou seja acho que o problema não > >>> era > >>> disco) > >>> > >>> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior > >>> escreveu > > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? > > Não seria viável separar? > > > > > Gerson S. de Vasconcelos Júnior > OCA DBA - Oracle Certified Associate > Fone: (81) 9816-0236 > Msn: gerson.vasconcelos@ > Skype: gersonvjunior > http://www.diaadiaoracle.com.br/ > > > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > >>> > > > > > > > Bom dia > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > problema, segue abaixo um resumo do meu cenário e das ações que já > >>> tomei: > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores > >>> Quad-core > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o > >>> oracle. > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID > >>> 10, > > totalizando 544Gb para Dados e Indices; > > > > Possuo um Disco Virtual
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Hevandro, estarei diminunido a memoria hoje a noite, conforme os colegas
orientaram, espero ter boa noticias amanha, o query que voce me mandou retornou
umas 1000 linhas, em mais da metade delas o count estava maior que 1, que
medida devo tomar?? quato ao AWR, desculpe-me, achei que fosse a mesma coisa
que o ADDM, vou rodar o AWR e envio, muito obrigado pelas dicas e pela ajuda!!!
--- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga escreveu
>
> Raul,
>
> O e-mail anterior saiu cortado. Deu tilt aqui.
>
> FINDING 1: 73% impact (1355 seconds)
>
> SQL statements consuming significant database time were found.
>
> Problemas com SQLs, já rodou o SQL tuning advisor em cima dessas queries ou
> o SQL Access Advisor no workload?
>
> FINDING 2: 50% impact (934 seconds)
> ---
> The SGA was inadequately sized, causing additional I/O or hard parses.
>
> RECOMMENDATION 1: DB Configuration, 47% benefit (881 seconds)
> ACTION: Increase the size of the SGA by setting the parameter
> "sga_target" to 27648 M.
>
> O Oracle tá te pedindo para aumentar a memória da SGA. Concordo com os
> demais colegas com relação ao SWAP, você deveria reduzir e não aumentar como
> o Oracle tá pedindo. No entanto existe um problema aqui. O optimizer parece
> não conseguir compartilhar os cursores, pode ser falta de variáveis bind,
> excesso de ddl...
>
> A query abaixo te dá um contagem de querys com o mesmo hash. Querys com o
> mesmo hash plan tem grandes chances de serem similares, e podem ser
> comparilhadas.
>
> SELECT PLAN_HASH_VALUE,COUNT(*)
> FROM V$SQL
> WHERE PARSING_SCHEMA_NAME NOT IN
> ('SYS','DBSNMP','SYSMAN')
> GROUP BY PLAN_HASH_VALUE ORDER BY 2;
>
> FINDING 3: 48% impact (896 seconds)
> ---
> Individual database segments responsible for significant user I/O wait were
> found.
>
> Você disse que já fez um reorg.
>
>
> Pelo ADDM já é um bom começo.
> Como eu havia te pedido antes, roda um report do AWR no período em que você
> sabe que teve o problema e envia em anexo.
> Olhar o report do AWR pode indicar um caminho mais preciso a seguir.
>
> Usa o $ORACLE_HOME/rdbms/admin/awrrpt.sql ou faz pelo enterprise manager:
>
>
> 2011/6/8 JLSilva
>
> >
> >
> > raul, sim, pode editar os valores manualmente (aqueles individuais).
> > a lógica é a seguinte: quando vc configura valores individuais para os
> > parâmetros da sga e também configura um valor para o sga_target, os valores
> > individuais passam a ser considerados como valor mínimo para as áreas
> > individuais.
> > ou seja, seguido minha sugestão, o cache de dados nunca será menor do que
> > 6gb.
> >
> > essas dicas eu coloquei considerando que os parâmetros de linux já estejam
> > configurados conforme as recomendações da Oracle, ou seja, os parâmetros
> > como:
> > /etc/sysctl.conf:
> > fs.file-max = 6815744
> > fs.aio-max-nr = 1048576
> > kernel.shmmax = 8589934590
> > kernel.shmall = 8388608
> > kernel.shmmni = 4096
> > kernel.msgmni = 1024
> > kernel.msgmax = 65536
> > kernel.msgmnb = 65536
> > kernel.threads-max = 131072
> > kernel.sem = 250 32000 100 128
> > net.ipv4.ip_local_port_range = 9000 65500
> > net.core.rmem_default = 1048576
> > net.core.rmem_max = 16777216
> > net.core.wmem_default = 262144
> > net.core.wmem_max = 16777216
> > net.ipv4.tcp_rmem = 4096 87380 16777216
> > net.ipv4.tcp_wmem = 4096 65536 16777216
> > vm.swappiness = 10
> > vm.nr_hugepages = 7682
> >
> > no caso do hugepages, o valor 7682 deverá suportar sua sga de 12gb mais sua
> > pga.
> >
> > /etc/pam.d/login
> > session required pam_limits.so
> >
> > /etc/security/limits.conf
> > oracle soft nproc 2047
> > oracle hard nproc 16384
> > oracle soft nofile 1024
> > oracle hard nofile 65536
> >
> >
> > On Jun 08, 2011, at 10:51 , raulcsneto wrote:
> >
> > > Bom dia JL,
> > > Vou investigar a questão do SWAP, não havia pensado nisso. Perdoe-me se
> > eu estiver falando uma grande besteira, mas eu realmente tenho pouca
> > experiência, mas caso meu servidor esteja usando muito SWAP, isso poderia
> > causar um problema de I/O no banco? Tendo em vista que o sistema operacional
> > e o SWAP estão em um volume separado dos discos do banco, até a controladora
> > é separada. Só mais uma dúvida, quanto a indicar valores individuais, mesmo
> > a Oracle recomendando a utilização do gerenciamento automático da memória,
> > você considera viável editar os valores manualmente?
> > >
> > >
> > > --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu
> > >>
> > >> raul,
> > >> pelo que entendi, vc tem 20GB de memória física e está usando 18GB para
> > o Oracle.
> > >> imagino que seu servidor deve estar usando bastante swap, e o load
> > average acaba subindo bastante.
> > >> minha análise é bastante superficial, mas recomendo vc reduzir a
> > quantidade de memória alocada para o banco.
> > >> se vc estiver usando "automatic memory management" (sga_target), procure
> > reduzir o valor desse parâme
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
JL, estarei alterando os valores da memória hoje a noite, veremos como o banco vai se comportar amanha, espero ter boas noticias, muito obrigado pelas dicas!!! --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu > > raul, sim, pode editar os valores manualmente (aqueles individuais). > a lógica é a seguinte: quando vc configura valores individuais para os > parâmetros da sga e também configura um valor para o sga_target, os valores > individuais passam a ser considerados como valor mínimo para as áreas > individuais. > ou seja, seguido minha sugestão, o cache de dados nunca será menor do que 6gb. > > essas dicas eu coloquei considerando que os parâmetros de linux já estejam > configurados conforme as recomendações da Oracle, ou seja, os parâmetros como: > /etc/sysctl.conf: > fs.file-max = 6815744 > fs.aio-max-nr = 1048576 > kernel.shmmax = 8589934590 > kernel.shmall = 8388608 > kernel.shmmni = 4096 > kernel.msgmni = 1024 > kernel.msgmax = 65536 > kernel.msgmnb = 65536 > kernel.threads-max = 131072 > kernel.sem = 250 32000 100 128 > net.ipv4.ip_local_port_range = 9000 65500 > net.core.rmem_default = 1048576 > net.core.rmem_max = 16777216 > net.core.wmem_default = 262144 > net.core.wmem_max = 16777216 > net.ipv4.tcp_rmem = 4096 87380 16777216 > net.ipv4.tcp_wmem = 4096 65536 16777216 > vm.swappiness = 10 > vm.nr_hugepages = 7682 > > no caso do hugepages, o valor 7682 deverá suportar sua sga de 12gb mais sua > pga. > > /etc/pam.d/login > sessionrequired pam_limits.so > > /etc/security/limits.conf > oracle softnproc 2047 > oracle hardnproc 16384 > oracle softnofile 1024 > oracle hardnofile 65536 > > > On Jun 08, 2011, at 10:51 , raulcsneto wrote: > > > Bom dia JL, > > Vou investigar a questão do SWAP, não havia pensado nisso. Perdoe-me se eu > > estiver falando uma grande besteira, mas eu realmente tenho pouca > > experiência, mas caso meu servidor esteja usando muito SWAP, isso poderia > > causar um problema de I/O no banco? Tendo em vista que o sistema > > operacional e o SWAP estão em um volume separado dos discos do banco, até a > > controladora é separada. Só mais uma dúvida, quanto a indicar valores > > individuais, mesmo a Oracle recomendando a utilização do gerenciamento > > automático da memória, você considera viável editar os valores manualmente? > > > > > > --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu > >> > >> raul, > >> pelo que entendi, vc tem 20GB de memória física e está usando 18GB para o > >> Oracle. > >> imagino que seu servidor deve estar usando bastante swap, e o load average > >> acaba subindo bastante. > >> minha análise é bastante superficial, mas recomendo vc reduzir a > >> quantidade de memória alocada para o banco. > >> se vc estiver usando "automatic memory management" (sga_target), procure > >> reduzir o valor desse parâmetro e indicar valores para os parâmetros > >> individuais. > >> exemplo: > >> sga_target=12GB > >> db_cache_size=6GB > >> shared_pool_size=4GB > >> (folga=2GB para o AMM realocar conforme necessário, além das outras áreas > >> de memória menores, como shared_pool_reserved_size, stream_pool_size etc.). > >> pga_aggregate_target=3GB (esta memória não é considerada no sga_target) > >> > >> faça os ajustes e nos avise do resultado, para sabermos se a sugestão foi > >> boa. > >> boa sorte. > >> > >> > >> On Jun 08, 2011, at 9:06 , raulcsneto wrote: > >> > >>> Bom dia > >>> > >>> Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > >>> System I/O, será que alguem poderia me ajudar a verificar a causa deste > >>> problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > >>> > >>> O Oracle 10G roda em um servidor Redhat 5 com dois processadores > >>> Quad-core Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas > >>> para o oracle. > >>> > >>> Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > >>> totalizando 544Gb para Dados e Indices; > >>> > >>> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > >>> totalizando 272Gb para Redo; > >>> > >>> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > >>> totalizando 272Gb para Archives; > >>> > >>> Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > >>> Stripes de 512k; > >>> > >>> Possuo Tablespaces separadas para Dados e Indices criadas com alocação > >>> uniforme de 512k com datafiles de 2Gb; > >>> > >>> Recentemente movi todas as tabelas e indices para tablespaces novas para > >>> eliminar a fragmentação; > >>> > >>> Caso alguem conheça algo que eu possa fazer para tentar descobrir onde > >>> está o problema, seria de grande valor par mim, pois já esgotei todas as > >>> minhas possibilidades, e a várias noites já não sei o que é dormir > >>> direito. > >>> > >>> Seguem abaixo algumas querys que fiz, meus resultado
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Raul, Estarei fazendo isso hoje a noite, vou diminuir a quantidade de memória, espero ter boas notícias amanhã, muito obrigado pelas dicas! --- Em oracle_br@yahoogrupos.com.br, "Raul Francisco Costa F. de Andrade, DBA" escreveu > > Eu também apostaria em diminuir um pouco a quantidade de memória que está > sendo dedicada ao Oracle. > A questão do SO estar fazendo SWAP é pertinente... > > Raul > --- > *Raul Francisco da Costa Ferreira de Andrade* > *DBA - OCP - Oracle Certified Professional* > *COBIT Foundation 4.1 > Celular:(41)8855-8874 Claro > *email: raulfdba@... > Skype: raul.andrade > msn:raulandrade@... > www.clickdba.com > > *"A adversidade leva alguns a serem vencidos > e outros a baterem recordes." * > William Arthur Ward > > > > Em 8 de junho de 2011 10:46, raulcsneto escreveu: > > > > > > > Bom dia Gerson, > > Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos > > de 143Gb 15.000RPM um para dados e outro para índices (o problema já ocorria > > nesta ocasião) então após ler algumas coisas e conversar com um amigo, que > > já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 > > discos, assim eu teria o dobro de discos para a controladora fazer Striping > > no momento de leitura/gravação talvez, melhorando o problema de I/O, porém > > parece que tudo permaneceu como estava (ou seja acho que o problema não era > > disco) > > > > --- Em oracle_br@yahoogrupos.com.br, Gerson Junior > > escreveu > > > > > > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? > > > > > > Não seria viável separar? > > > > > > > > > > > > > > > Gerson S. de Vasconcelos Júnior > > > OCA DBA - Oracle Certified Associate > > > Fone: (81) 9816-0236 > > > Msn: gerson.vasconcelos@ > > > Skype: gersonvjunior > > > http://www.diaadiaoracle.com.br/ > > > > > > > > > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > > > > > > > > > > > > > > > > > Bom dia > > > > > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > > > problema, segue abaixo um resumo do meu cenário e das ações que já > > tomei: > > > > > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores > > Quad-core > > > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o > > oracle. > > > > > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID > > 10, > > > > totalizando 544Gb para Dados e Indices; > > > > > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > > 0, > > > > totalizando 272Gb para Redo; > > > > > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > > 0, > > > > totalizando 272Gb para Archives; > > > > > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados > > em > > > > Stripes de 512k; > > > > > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > > > uniforme de 512k com datafiles de 2Gb; > > > > > > > > Recentemente movi todas as tabelas e indices para tablespaces novas > > para > > > > eliminar a fragmentação; > > > > > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde > > está > > > > o problema, seria de grande valor par mim, pois já esgotei todas as > > minhas > > > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo > > em > > > > todas elas: > > > > > > > > ÍNDICE DE ACERTOS NO CACHE > > > > == > > > > (quanto mais BHR próximo a 1, melhor) > > > > > > > > column bhr format 9.99 > > > > column mydate heading 'Ano Me Di Hora' > > > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > > > new.name "Buffer Pool", > > > > (((new.consistent_gets-old.consistent_gets)+ > > > > (new.db_block_gets-old.db_block_gets))- > > > > (new.physical_reads-old.physical_reads)) / > > > > ((new.consistent_gets-old.consistent_gets)+ > > > > (new.db_block_gets-old.db_block_gets)) bhr > > > > from > > > > dba_hist_buffer_pool_stat old, > > > > dba_hist_buffer_pool_stat new, > > > > dba_hist_snapshot sn > > > > where > > > > (((new.consistent_gets-old.consistent_gets)+ > > > > (new.db_block_gets-old.db_block_gets))- > > > > (new.physical_reads-old.physical_reads)) / > > > > ((new.consistent_gets-old.consistent_gets)+ > > > > (new.db_block_gets-old.db_block_gets)) > 0 > > > > and > > > > new.name = old.name > > > > and > > > > new.snap_id = sn.snap_id > > > > and > > > > old.snap_id = sn.snap_id-1 > > > > order by mydate; > > > > > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > > > == > > > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > > > objetos, como sequences) > > > > > > > > select
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Raul,
FINDING 1: 73% impact (1355 seconds)
SQL statements consuming significant database time were found.
Problemas com SQLs, já rodou o SQL tuning advisor em cima dessas queries ou
o SQL Access Advisor no workload?
FINDING 2: 50% impact (934 seconds)
---
The SGA was inadequately sized, causing additional I/O or hard parses.
RECOMMENDATION 1: DB Configuration, 47% benefit (881 seconds)
ACTION: Increase the size of the SGA by setting the parameter
"sga_target" to 27648 M.
O Oracle tá te pedindo para aumentar a memória da SGA. Concordo com os
demais colegas com relação ao SWAP, você deveria reduzir e não aumentar como
o Oracle tá pedindo. No entanto existe um problema aqui. O optimizer parece
não conseguir compartilhar os cursores, pode ser falta de variáveis bind,
excesso de ddl...
SELECT PLAN_HASH_VALUE,COUNT(*)
FROM V$SQL
WHERE PARSING_SCHEMA_NAME NOT IN
('SYS',
2011/6/8 Ivan Ricardo Schuster
>
>
> Raul,
>
> Primeiramente: Não abra mão de segurança para compensar o problema de
> I/O. RAID 0 não é opção para bancos de dados!
>
> Sim, swap é uma grande suspeita, o problema de IO parece não ser
> somente "System", mas geral.
>
> Considere as recomendações dos colegas para ajustar os parametros de
> memória, em geral recomendo a configuração de valores fixos de
> memória, ou ao menos definir valores mínimos para cada item.
>
> Acredito que este Linux seja 64 bits, certo?
> De qualquer forma, você pode considerar a utilização de hugepages em
> seu servidor:
> http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/
>
> Recomendo ainda que você verifique as dicas em:
> http://www.puschitz.com/TuningLinuxForOracle.shtml
>
> Principalmente no que se refere a ativar Asynchronous I/O, caso o
> ajuste de memória não resolva.
>
> Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela
> Oracle trimestralmente e que corrigem bugs de segurança no seu banco
> de dados. Apesar de não serem patches especificos de desempenho, podem
> corrigir algum problema relacionado.
>
> 2011/6/8 Raul Francisco Costa F. de Andrade, DBA :
>
> > Eu também apostaria em diminuir um pouco a quantidade de memória que está
> > sendo dedicada ao Oracle.
> > A questão do SO estar fazendo SWAP é pertinente...
> >
> > Raul
> > --
> > *Raul Francisco da Costa Ferreira de Andrade*
> > *DBA - OCP - Oracle Certified Professional*
> > *COBIT Foundation 4.1
> > Celular:(41)8855-8874 Claro
> > *email: raulf...@gmail.com
> > Skype: raul.andrade
> > msn:raulandr...@ibest.com.br
> > www.clickdba.com
> >
> > *"A adversidade leva alguns a serem vencidos
> > e outros a baterem recordes." *
> > William Arthur Ward
> >
> >
> >
> > Em 8 de junho de 2011 10:46, raulcsneto escreveu:
> >
> >>
> >>
> >> Bom dia Gerson,
> >> Até semana passada eu tinha dois volumes separados de RAID 10 com 4
> discos
> >> de 143Gb 15.000RPM um para dados e outro para índices (o problema já
> ocorria
> >> nesta ocasião) então após ler algumas coisas e conversar com um amigo,
> que
> >> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os
> 8
> >> discos, assim eu teria o dobro de discos para a controladora fazer
> Striping
> >> no momento de leitura/gravação talvez, melhorando o problema de I/O,
> porém
> >> parece que tudo permaneceu como estava (ou seja acho que o problema não
> era
> >> disco)
> >>
> >> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior ...>
> >> escreveu
> >> >
> >> > Pelo que vi, dados e indices estão no mesmo range de discos, é isso?
> >> >
> >> > Não seria viável separar?
> >> >
> >> >
> >> >
> >> >
> >> > Gerson S. de Vasconcelos Júnior
> >> > OCA DBA - Oracle Certified Associate
> >> > Fone: (81) 9816-0236
> >> > Msn: gerson.vasconcelos@...
> >> > Skype: gersonvjunior
> >> > http://www.diaadiaoracle.com.br/
> >> >
> >> >
> >> > Em 8 de junho de 2011 09:06, raulcsneto escreveu:
> >>
> >> >
> >> > >
> >> > >
> >> > > Bom dia
> >> > >
> >> > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas
> de
> >> > > System I/O, será que alguem poderia me ajudar a verificar a causa
> deste
> >> > > problema, segue abaixo um resumo do meu cenário e das ações que já
> >> tomei:
> >> > >
> >> > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores
> >> Quad-core
> >> > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o
> >> oracle.
> >> > >
> >> > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em
> RAID
> >> 10,
> >> > > totalizando 544Gb para Dados e Indices;
> >> > >
> >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em
> RAID
> >> 0,
> >> > > totalizando 272Gb para Redo;
> >> > >
> >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em
> RAID
> >> 0,
> >> > > totalizando 272Gb para Archives;
> >> > >
> >> > > Estes tres volumes estão em uma controladora PERC6/E todos
> segmentados
> >> em
> >>
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
raul, ratificando o que o ivan citou, raid 0 para áreas de redolog online e archives é um risco super alto. se um desses discos parar de funcionar, no caso da área de redolog, vc perderá redologs online. isto significa que o redolog mais recentes, que pode estar não arquivado, será perdido, consequentemente perderá transações que podem já ter sofrido commit. recomendo vc multiplexar os redologs online, utilizando as duas áreas de raid 0 q vc tem: a de redologs e a de archives. recomendo também vc colocar 2 destinos de archives, um em cada área novamente. mas, isto é outro assunto, além desse referente à performance. boa sorte. On Jun 08, 2011, at 11:24 , Ivan Ricardo Schuster wrote: > Raul, > > Primeiramente: Não abra mão de segurança para compensar o problema de > I/O. RAID 0 não é opção para bancos de dados! > > Sim, swap é uma grande suspeita, o problema de IO parece não ser > somente "System", mas geral. > > Considere as recomendações dos colegas para ajustar os parametros de > memória, em geral recomendo a configuração de valores fixos de > memória, ou ao menos definir valores mínimos para cada item. > > Acredito que este Linux seja 64 bits, certo? > De qualquer forma, você pode considerar a utilização de hugepages em > seu servidor: > http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/ > > Recomendo ainda que você verifique as dicas em: > http://www.puschitz.com/TuningLinuxForOracle.shtml > > Principalmente no que se refere a ativar Asynchronous I/O, caso o > ajuste de memória não resolva. > > Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela > Oracle trimestralmente e que corrigem bugs de segurança no seu banco > de dados. Apesar de não serem patches especificos de desempenho, podem > corrigir algum problema relacionado. > > > 2011/6/8 Raul Francisco Costa F. de Andrade, DBA : >> Eu também apostaria em diminuir um pouco a quantidade de memória que está >> sendo dedicada ao Oracle. >> A questão do SO estar fazendo SWAP é pertinente... >> >> Raul >> --- >> *Raul Francisco da Costa Ferreira de Andrade* >> *DBA - OCP - Oracle Certified Professional* >> *COBIT Foundation 4.1 >> Celular:(41)8855-8874 Claro >> *email: raulf...@gmail.com >> Skype: raul.andrade >> msn:raulandr...@ibest.com.br >> www.clickdba.com >> >> *"A adversidade leva alguns a serem vencidos >> e outros a baterem recordes." * >> William Arthur Ward >> >> >> >> Em 8 de junho de 2011 10:46, raulcsneto escreveu: >> >>> >>> >>> Bom dia Gerson, >>> Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos >>> de 143Gb 15.000RPM um para dados e outro para índices (o problema já ocorria >>> nesta ocasião) então após ler algumas coisas e conversar com um amigo, que >>> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 >>> discos, assim eu teria o dobro de discos para a controladora fazer Striping >>> no momento de leitura/gravação talvez, melhorando o problema de I/O, porém >>> parece que tudo permaneceu como estava (ou seja acho que o problema não era >>> disco) >>> >>> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior >>> escreveu Pelo que vi, dados e indices estão no mesmo range de discos, é isso? Não seria viável separar? Gerson S. de Vasconcelos Júnior OCA DBA - Oracle Certified Associate Fone: (81) 9816-0236 Msn: gerson.vasconcelos@... Skype: gersonvjunior http://www.diaadiaoracle.com.br/ Em 8 de junho de 2011 09:06, raulcsneto escreveu: >>> > > > Bom dia > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > System I/O, será que alguem poderia me ajudar a verificar a causa deste > problema, segue abaixo um resumo do meu cenário e das ações que já >>> tomei: > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores >>> Quad-core > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o >>> oracle. > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID >>> 10, > totalizando 544Gb para Dados e Indices; > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID >>> 0, > totalizando 272Gb para Redo; > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID >>> 0, > totalizando 272Gb para Archives; > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados >>> em > Stripes de 512k; > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > uniforme de 512k com datafiles de 2Gb; > > Recentemente movi todas as tabelas e indices para tablespaces novas >>> para > eliminar a fragmentação; > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde >>> está > o problema, seria de grande valor par mim, pois já
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Raul, pelo log aparentimente é I/O mesmo na sua aplicação, qual é o usuario que se conecta ao banco?? é apenas 1 usuario né??(usuario de banco) se for pega o SID dele e faz esse select SELECT EVENT, AVERAGE_WAIT, TOTAL_TIMEOUTS FROM V$SESSION_EVENT WHERE SID = ORDER BY AVERAGE_WAIT; vai te retornar os waits que estao acontecendo na sua base. posta ai o resultado Em 8 de junho de 2011 10:51, raulcsneto escreveu: > > > Bom dia JL, > Vou investigar a questão do SWAP, não havia pensado nisso. Perdoe-me se eu > estiver falando uma grande besteira, mas eu realmente tenho pouca > experiência, mas caso meu servidor esteja usando muito SWAP, isso poderia > causar um problema de I/O no banco? Tendo em vista que o sistema operacional > e o SWAP estão em um volume separado dos discos do banco, até a controladora > é separada. Só mais uma dúvida, quanto a indicar valores individuais, mesmo > a Oracle recomendando a utilização do gerenciamento automático da memória, > você considera viável editar os valores manualmente? > > --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu > > > > > raul, > > pelo que entendi, vc tem 20GB de memória física e está usando 18GB para o > Oracle. > > imagino que seu servidor deve estar usando bastante swap, e o load > average acaba subindo bastante. > > minha análise é bastante superficial, mas recomendo vc reduzir a > quantidade de memória alocada para o banco. > > se vc estiver usando "automatic memory management" (sga_target), procure > reduzir o valor desse parâmetro e indicar valores para os parâmetros > individuais. > > exemplo: > > sga_target=12GB > > db_cache_size=6GB > > shared_pool_size=4GB > > (folga=2GB para o AMM realocar conforme necessário, além das outras áreas > de memória menores, como shared_pool_reserved_size, stream_pool_size etc.). > > pga_aggregate_target=3GB (esta memória não é considerada no sga_target) > > > > faça os ajustes e nos avise do resultado, para sabermos se a sugestão foi > boa. > > boa sorte. > > > > > > On Jun 08, 2011, at 9:06 , raulcsneto wrote: > > > > > Bom dia > > > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > System I/O, será que alguem poderia me ajudar a verificar a causa deste > problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > > > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores > Quad-core Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para > o oracle. > > > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID > 10, totalizando 544Gb para Dados e Indices; > > > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > 0, totalizando 272Gb para Redo; > > > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > 0, totalizando 272Gb para Archives; > > > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados > em Stripes de 512k; > > > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > uniforme de 512k com datafiles de 2Gb; > > > > > > Recentemente movi todas as tabelas e indices para tablespaces novas > para eliminar a fragmentação; > > > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde > está o problema, seria de grande valor par mim, pois já esgotei todas as > minhas possibilidades, e a várias noites já não sei o que é dormir direito. > > > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo > em todas elas: > > > > > > ÍNDICE DE ACERTOS NO CACHE > > > == > > > (quanto mais BHR próximo a 1, melhor) > > > > > > column bhr format 9.99 > > > column mydate heading 'Ano Me Di Hora' > > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > > new.name "Buffer Pool", > > > (((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets))- > > > (new.physical_reads-old.physical_reads)) / > > > ((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets)) bhr > > > from > > > dba_hist_buffer_pool_stat old, > > > dba_hist_buffer_pool_stat new, > > > dba_hist_snapshot sn > > > where > > > (((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets))- > > > (new.physical_reads-old.physical_reads)) / > > > ((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets)) > 0 > > > and > > > new.name = old.name > > > and > > > new.snap_id = sn.snap_id > > > and > > > old.snap_id = sn.snap_id-1 > > > order by mydate; > > > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > > == > > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > objetos, como sequences) > > > > > > select > > > parameter "Parametro", > > > gets, > > > Getmisses , > > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Tax
[oracle_br] Library Cache Pin - Ajustando Shared_Pool
Amigos, Estou iniciando algumas analise na minha Shared_Poll, mais precisamente na Library Cache pois tenho verificado alguns pequenos latchs e gostaria de uma ajuda... Pelo que entendo e andei lendo, este lacth esta relacionado a execução ou compilação de PL / SQL e a interpretação destes, ficam armazenados nesta área de memória. Qual seria a melhor maneira de analisar esta questão e saber quais são os objetos que precisariam ser revistos ? Este latch esta sempre relacionado a performance do objetos a nível de parse? Ou seja, quanto mais reparsing pior será o cenário ?
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Raul,
O e-mail anterior saiu cortado. Deu tilt aqui.
FINDING 1: 73% impact (1355 seconds)
SQL statements consuming significant database time were found.
Problemas com SQLs, já rodou o SQL tuning advisor em cima dessas queries ou
o SQL Access Advisor no workload?
FINDING 2: 50% impact (934 seconds)
---
The SGA was inadequately sized, causing additional I/O or hard parses.
RECOMMENDATION 1: DB Configuration, 47% benefit (881 seconds)
ACTION: Increase the size of the SGA by setting the parameter
"sga_target" to 27648 M.
O Oracle tá te pedindo para aumentar a memória da SGA. Concordo com os
demais colegas com relação ao SWAP, você deveria reduzir e não aumentar como
o Oracle tá pedindo. No entanto existe um problema aqui. O optimizer parece
não conseguir compartilhar os cursores, pode ser falta de variáveis bind,
excesso de ddl...
A query abaixo te dá um contagem de querys com o mesmo hash. Querys com o
mesmo hash plan tem grandes chances de serem similares, e podem ser
comparilhadas.
SELECT PLAN_HASH_VALUE,COUNT(*)
FROM V$SQL
WHERE PARSING_SCHEMA_NAME NOT IN
('SYS','DBSNMP','SYSMAN')
GROUP BY PLAN_HASH_VALUE ORDER BY 2;
FINDING 3: 48% impact (896 seconds)
---
Individual database segments responsible for significant user I/O wait were
found.
Você disse que já fez um reorg.
Pelo ADDM já é um bom começo.
Como eu havia te pedido antes, roda um report do AWR no período em que você
sabe que teve o problema e envia em anexo.
Olhar o report do AWR pode indicar um caminho mais preciso a seguir.
Usa o $ORACLE_HOME/rdbms/admin/awrrpt.sql ou faz pelo enterprise manager:
2011/6/8 JLSilva
>
>
> raul, sim, pode editar os valores manualmente (aqueles individuais).
> a lógica é a seguinte: quando vc configura valores individuais para os
> parâmetros da sga e também configura um valor para o sga_target, os valores
> individuais passam a ser considerados como valor mínimo para as áreas
> individuais.
> ou seja, seguido minha sugestão, o cache de dados nunca será menor do que
> 6gb.
>
> essas dicas eu coloquei considerando que os parâmetros de linux já estejam
> configurados conforme as recomendações da Oracle, ou seja, os parâmetros
> como:
> /etc/sysctl.conf:
> fs.file-max = 6815744
> fs.aio-max-nr = 1048576
> kernel.shmmax = 8589934590
> kernel.shmall = 8388608
> kernel.shmmni = 4096
> kernel.msgmni = 1024
> kernel.msgmax = 65536
> kernel.msgmnb = 65536
> kernel.threads-max = 131072
> kernel.sem = 250 32000 100 128
> net.ipv4.ip_local_port_range = 9000 65500
> net.core.rmem_default = 1048576
> net.core.rmem_max = 16777216
> net.core.wmem_default = 262144
> net.core.wmem_max = 16777216
> net.ipv4.tcp_rmem = 4096 87380 16777216
> net.ipv4.tcp_wmem = 4096 65536 16777216
> vm.swappiness = 10
> vm.nr_hugepages = 7682
>
> no caso do hugepages, o valor 7682 deverá suportar sua sga de 12gb mais sua
> pga.
>
> /etc/pam.d/login
> session required pam_limits.so
>
> /etc/security/limits.conf
> oracle soft nproc 2047
> oracle hard nproc 16384
> oracle soft nofile 1024
> oracle hard nofile 65536
>
>
> On Jun 08, 2011, at 10:51 , raulcsneto wrote:
>
> > Bom dia JL,
> > Vou investigar a questão do SWAP, não havia pensado nisso. Perdoe-me se
> eu estiver falando uma grande besteira, mas eu realmente tenho pouca
> experiência, mas caso meu servidor esteja usando muito SWAP, isso poderia
> causar um problema de I/O no banco? Tendo em vista que o sistema operacional
> e o SWAP estão em um volume separado dos discos do banco, até a controladora
> é separada. Só mais uma dúvida, quanto a indicar valores individuais, mesmo
> a Oracle recomendando a utilização do gerenciamento automático da memória,
> você considera viável editar os valores manualmente?
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu
> >>
> >> raul,
> >> pelo que entendi, vc tem 20GB de memória física e está usando 18GB para
> o Oracle.
> >> imagino que seu servidor deve estar usando bastante swap, e o load
> average acaba subindo bastante.
> >> minha análise é bastante superficial, mas recomendo vc reduzir a
> quantidade de memória alocada para o banco.
> >> se vc estiver usando "automatic memory management" (sga_target), procure
> reduzir o valor desse parâmetro e indicar valores para os parâmetros
> individuais.
> >> exemplo:
> >> sga_target=12GB
> >> db_cache_size=6GB
> >> shared_pool_size=4GB
> >> (folga=2GB para o AMM realocar conforme necessário, além das outras
> áreas de memória menores, como shared_pool_reserved_size, stream_pool_size
> etc.).
> >> pga_aggregate_target=3GB (esta memória não é considerada no sga_target)
> >>
> >> faça os ajustes e nos avise do resultado, para sabermos se a sugestão
> foi boa.
> >> boa sorte.
> >>
> >>
> >> On Jun 08, 2011, at 9:06 , raulcsneto wrote:
> >>
> >>> Bom dia
> >>>
> >>> Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de
> System I/O, será que alguem poderia me ajudar a verifi
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
raul, sim, pode editar os valores manualmente (aqueles individuais). a lógica é a seguinte: quando vc configura valores individuais para os parâmetros da sga e também configura um valor para o sga_target, os valores individuais passam a ser considerados como valor mínimo para as áreas individuais. ou seja, seguido minha sugestão, o cache de dados nunca será menor do que 6gb. essas dicas eu coloquei considerando que os parâmetros de linux já estejam configurados conforme as recomendações da Oracle, ou seja, os parâmetros como: /etc/sysctl.conf: fs.file-max = 6815744 fs.aio-max-nr = 1048576 kernel.shmmax = 8589934590 kernel.shmall = 8388608 kernel.shmmni = 4096 kernel.msgmni = 1024 kernel.msgmax = 65536 kernel.msgmnb = 65536 kernel.threads-max = 131072 kernel.sem = 250 32000 100 128 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 1048576 net.core.rmem_max = 16777216 net.core.wmem_default = 262144 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 vm.swappiness = 10 vm.nr_hugepages = 7682 no caso do hugepages, o valor 7682 deverá suportar sua sga de 12gb mais sua pga. /etc/pam.d/login sessionrequired pam_limits.so /etc/security/limits.conf oracle softnproc 2047 oracle hardnproc 16384 oracle softnofile 1024 oracle hardnofile 65536 On Jun 08, 2011, at 10:51 , raulcsneto wrote: > Bom dia JL, > Vou investigar a questão do SWAP, não havia pensado nisso. Perdoe-me se eu > estiver falando uma grande besteira, mas eu realmente tenho pouca > experiência, mas caso meu servidor esteja usando muito SWAP, isso poderia > causar um problema de I/O no banco? Tendo em vista que o sistema operacional > e o SWAP estão em um volume separado dos discos do banco, até a controladora > é separada. Só mais uma dúvida, quanto a indicar valores individuais, mesmo a > Oracle recomendando a utilização do gerenciamento automático da memória, você > considera viável editar os valores manualmente? > > > --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu >> >> raul, >> pelo que entendi, vc tem 20GB de memória física e está usando 18GB para o >> Oracle. >> imagino que seu servidor deve estar usando bastante swap, e o load average >> acaba subindo bastante. >> minha análise é bastante superficial, mas recomendo vc reduzir a quantidade >> de memória alocada para o banco. >> se vc estiver usando "automatic memory management" (sga_target), procure >> reduzir o valor desse parâmetro e indicar valores para os parâmetros >> individuais. >> exemplo: >> sga_target=12GB >> db_cache_size=6GB >> shared_pool_size=4GB >> (folga=2GB para o AMM realocar conforme necessário, além das outras áreas de >> memória menores, como shared_pool_reserved_size, stream_pool_size etc.). >> pga_aggregate_target=3GB (esta memória não é considerada no sga_target) >> >> faça os ajustes e nos avise do resultado, para sabermos se a sugestão foi >> boa. >> boa sorte. >> >> >> On Jun 08, 2011, at 9:06 , raulcsneto wrote: >> >>> Bom dia >>> >>> Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de >>> System I/O, será que alguem poderia me ajudar a verificar a causa deste >>> problema, segue abaixo um resumo do meu cenário e das ações que já tomei: >>> >>> O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core >>> Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle. >>> >>> Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, >>> totalizando 544Gb para Dados e Indices; >>> >>> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, >>> totalizando 272Gb para Redo; >>> >>> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, >>> totalizando 272Gb para Archives; >>> >>> Estes tres volumes estão em uma controladora PERC6/E todos segmentados em >>> Stripes de 512k; >>> >>> Possuo Tablespaces separadas para Dados e Indices criadas com alocação >>> uniforme de 512k com datafiles de 2Gb; >>> >>> Recentemente movi todas as tabelas e indices para tablespaces novas para >>> eliminar a fragmentação; >>> >>> Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está >>> o problema, seria de grande valor par mim, pois já esgotei todas as minhas >>> possibilidades, e a várias noites já não sei o que é dormir direito. >>> >>> Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em >>> todas elas: >>> >>> ÍNDICE DE ACERTOS NO CACHE >>> == >>> (quanto mais BHR próximo a 1, melhor) >>> >>> column bhr format 9.99 >>> column mydate heading 'Ano Me Di Hora' >>> select to_char(end_interval_time,'-mm-dd HH24') mydate, >>> new.name "Buffer Pool", >>> (((new.consistent_gets-old.consistent_gets)+ >>> (new.db_block_gets-old.db_block_gets))- >>> (new.physi
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Raul, Primeiramente: Não abra mão de segurança para compensar o problema de I/O. RAID 0 não é opção para bancos de dados! Sim, swap é uma grande suspeita, o problema de IO parece não ser somente "System", mas geral. Considere as recomendações dos colegas para ajustar os parametros de memória, em geral recomendo a configuração de valores fixos de memória, ou ao menos definir valores mínimos para cada item. Acredito que este Linux seja 64 bits, certo? De qualquer forma, você pode considerar a utilização de hugepages em seu servidor: http://ivanschuster.wordpress.com/category/gerenciamento-de-memoria/ Recomendo ainda que você verifique as dicas em: http://www.puschitz.com/TuningLinuxForOracle.shtml Principalmente no que se refere a ativar Asynchronous I/O, caso o ajuste de memória não resolva. Sobre Patch Set Updates (PSU), são pacotes de patches liberados pela Oracle trimestralmente e que corrigem bugs de segurança no seu banco de dados. Apesar de não serem patches especificos de desempenho, podem corrigir algum problema relacionado. 2011/6/8 Raul Francisco Costa F. de Andrade, DBA : > Eu também apostaria em diminuir um pouco a quantidade de memória que está > sendo dedicada ao Oracle. > A questão do SO estar fazendo SWAP é pertinente... > > Raul > --- > *Raul Francisco da Costa Ferreira de Andrade* > *DBA - OCP - Oracle Certified Professional* > *COBIT Foundation 4.1 > Celular:(41)8855-8874 Claro > *email: raulf...@gmail.com > Skype: raul.andrade > msn:raulandr...@ibest.com.br > www.clickdba.com > > *"A adversidade leva alguns a serem vencidos > e outros a baterem recordes." * > William Arthur Ward > > > > Em 8 de junho de 2011 10:46, raulcsneto escreveu: > >> >> >> Bom dia Gerson, >> Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos >> de 143Gb 15.000RPM um para dados e outro para índices (o problema já ocorria >> nesta ocasião) então após ler algumas coisas e conversar com um amigo, que >> já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 >> discos, assim eu teria o dobro de discos para a controladora fazer Striping >> no momento de leitura/gravação talvez, melhorando o problema de I/O, porém >> parece que tudo permaneceu como estava (ou seja acho que o problema não era >> disco) >> >> --- Em oracle_br@yahoogrupos.com.br, Gerson Junior >> escreveu >> > >> > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? >> > >> > Não seria viável separar? >> > >> > >> > >> > >> > Gerson S. de Vasconcelos Júnior >> > OCA DBA - Oracle Certified Associate >> > Fone: (81) 9816-0236 >> > Msn: gerson.vasconcelos@... >> > Skype: gersonvjunior >> > http://www.diaadiaoracle.com.br/ >> > >> > >> > Em 8 de junho de 2011 09:06, raulcsneto escreveu: >> >> > >> > > >> > > >> > > Bom dia >> > > >> > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de >> > > System I/O, será que alguem poderia me ajudar a verificar a causa deste >> > > problema, segue abaixo um resumo do meu cenário e das ações que já >> tomei: >> > > >> > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores >> Quad-core >> > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o >> oracle. >> > > >> > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID >> 10, >> > > totalizando 544Gb para Dados e Indices; >> > > >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID >> 0, >> > > totalizando 272Gb para Redo; >> > > >> > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID >> 0, >> > > totalizando 272Gb para Archives; >> > > >> > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados >> em >> > > Stripes de 512k; >> > > >> > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação >> > > uniforme de 512k com datafiles de 2Gb; >> > > >> > > Recentemente movi todas as tabelas e indices para tablespaces novas >> para >> > > eliminar a fragmentação; >> > > >> > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde >> está >> > > o problema, seria de grande valor par mim, pois já esgotei todas as >> minhas >> > > possibilidades, e a várias noites já não sei o que é dormir direito. >> > > >> > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo >> em >> > > todas elas: >> > > >> > > ÍNDICE DE ACERTOS NO CACHE >> > > == >> > > (quanto mais BHR próximo a 1, melhor) >> > > >> > > column bhr format 9.99 >> > > column mydate heading 'Ano Me Di Hora' >> > > select to_char(end_interval_time,'-mm-dd HH24') mydate, >> > > new.name "Buffer Pool", >> > > (((new.consistent_gets-old.consistent_gets)+ >> > > (new.db_block_gets-old.db_block_gets))- >> > > (new.physical_reads-old.physical_reads)) / >> > > ((new.consistent_gets-old.consistent_gets)+ >> > > (new.db_block_gets-old.db_block_gets)) bhr >> > > from >> > > dba_hist_buffer_pool_
Re: [oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Eu também apostaria em diminuir um pouco a quantidade de memória que está sendo dedicada ao Oracle. A questão do SO estar fazendo SWAP é pertinente... Raul --- *Raul Francisco da Costa Ferreira de Andrade* *DBA - OCP - Oracle Certified Professional* *COBIT Foundation 4.1 Celular:(41)8855-8874 Claro *email: raulf...@gmail.com Skype: raul.andrade msn:raulandr...@ibest.com.br www.clickdba.com *"A adversidade leva alguns a serem vencidos e outros a baterem recordes." * William Arthur Ward Em 8 de junho de 2011 10:46, raulcsneto escreveu: > > > Bom dia Gerson, > Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos > de 143Gb 15.000RPM um para dados e outro para índices (o problema já ocorria > nesta ocasião) então após ler algumas coisas e conversar com um amigo, que > já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 > discos, assim eu teria o dobro de discos para a controladora fazer Striping > no momento de leitura/gravação talvez, melhorando o problema de I/O, porém > parece que tudo permaneceu como estava (ou seja acho que o problema não era > disco) > > --- Em oracle_br@yahoogrupos.com.br, Gerson Junior > escreveu > > > > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? > > > > Não seria viável separar? > > > > > > > > > > Gerson S. de Vasconcelos Júnior > > OCA DBA - Oracle Certified Associate > > Fone: (81) 9816-0236 > > Msn: gerson.vasconcelos@... > > Skype: gersonvjunior > > http://www.diaadiaoracle.com.br/ > > > > > > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > > > > > > > > > > > > Bom dia > > > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > > problema, segue abaixo um resumo do meu cenário e das ações que já > tomei: > > > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores > Quad-core > > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o > oracle. > > > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID > 10, > > > totalizando 544Gb para Dados e Indices; > > > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > 0, > > > totalizando 272Gb para Redo; > > > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID > 0, > > > totalizando 272Gb para Archives; > > > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados > em > > > Stripes de 512k; > > > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > > uniforme de 512k com datafiles de 2Gb; > > > > > > Recentemente movi todas as tabelas e indices para tablespaces novas > para > > > eliminar a fragmentação; > > > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde > está > > > o problema, seria de grande valor par mim, pois já esgotei todas as > minhas > > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo > em > > > todas elas: > > > > > > ÍNDICE DE ACERTOS NO CACHE > > > == > > > (quanto mais BHR próximo a 1, melhor) > > > > > > column bhr format 9.99 > > > column mydate heading 'Ano Me Di Hora' > > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > > new.name "Buffer Pool", > > > (((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets))- > > > (new.physical_reads-old.physical_reads)) / > > > ((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets)) bhr > > > from > > > dba_hist_buffer_pool_stat old, > > > dba_hist_buffer_pool_stat new, > > > dba_hist_snapshot sn > > > where > > > (((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets))- > > > (new.physical_reads-old.physical_reads)) / > > > ((new.consistent_gets-old.consistent_gets)+ > > > (new.db_block_gets-old.db_block_gets)) > 0 > > > and > > > new.name = old.name > > > and > > > new.snap_id = sn.snap_id > > > and > > > old.snap_id = sn.snap_id-1 > > > order by mydate; > > > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > > == > > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > > objetos, como sequences) > > > > > > select > > > parameter "Parametro", > > > gets, > > > Getmisses , > > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > > > from v$rowcache > > > where gets+getmisses <>0 > > > group by parameter, gets, getmisses ; > > > > > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > > = > > > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > > > > > select Username, > > > OSUSER, > > >
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Bom dia JL, Vou investigar a questão do SWAP, não havia pensado nisso. Perdoe-me se eu estiver falando uma grande besteira, mas eu realmente tenho pouca experiência, mas caso meu servidor esteja usando muito SWAP, isso poderia causar um problema de I/O no banco? Tendo em vista que o sistema operacional e o SWAP estão em um volume separado dos discos do banco, até a controladora é separada. Só mais uma dúvida, quanto a indicar valores individuais, mesmo a Oracle recomendando a utilização do gerenciamento automático da memória, você considera viável editar os valores manualmente? --- Em oracle_br@yahoogrupos.com.br, JLSilva escreveu > > raul, > pelo que entendi, vc tem 20GB de memória física e está usando 18GB para o > Oracle. > imagino que seu servidor deve estar usando bastante swap, e o load average > acaba subindo bastante. > minha análise é bastante superficial, mas recomendo vc reduzir a quantidade > de memória alocada para o banco. > se vc estiver usando "automatic memory management" (sga_target), procure > reduzir o valor desse parâmetro e indicar valores para os parâmetros > individuais. > exemplo: > sga_target=12GB > db_cache_size=6GB > shared_pool_size=4GB > (folga=2GB para o AMM realocar conforme necessário, além das outras áreas de > memória menores, como shared_pool_reserved_size, stream_pool_size etc.). > pga_aggregate_target=3GB (esta memória não é considerada no sga_target) > > faça os ajustes e nos avise do resultado, para sabermos se a sugestão foi boa. > boa sorte. > > > On Jun 08, 2011, at 9:06 , raulcsneto wrote: > > > Bom dia > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle. > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > > totalizando 544Gb para Dados e Indices; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Redo; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Archives; > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > > Stripes de 512k; > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > uniforme de 512k com datafiles de 2Gb; > > > > Recentemente movi todas as tabelas e indices para tablespaces novas para > > eliminar a fragmentação; > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está > > o problema, seria de grande valor par mim, pois já esgotei todas as minhas > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em > > todas elas: > > > > ÍNDICE DE ACERTOS NO CACHE > > == > > (quanto mais BHR próximo a 1, melhor) > > > > column bhr format 9.99 > > column mydate heading 'Ano Me Di Hora' > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > new.name "Buffer Pool", > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))bhr > > from > > dba_hist_buffer_pool_stat old, > > dba_hist_buffer_pool_stat new, > > dba_hist_snapshot sn > > where > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) > 0 > > and > > new.name = old.name > > and > > new.snap_id = sn.snap_id > > and > > old.snap_id = sn.snap_id-1 > > order by mydate; > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > == > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > objetos, como sequences) > > > > select > > parameter "Parametro", > > gets, > > Getmisses , > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > > from v$rowcache > > where gets+getmisses <>0 > > group by parameter, gets, getmisses ; > > > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > = > > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > > > select Username, > > OSUSER, > > Consistent_Gets, > > Block_Gets, > > Physical_Reads, > > 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > > ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > > fro
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Bom dia Ivan Então, - Meu banco é 10G 10.2.0.4.0; - Desculpe a minha ignorância, mas o que seria atualizar os CPUs/PSUs? - Quanto ao que me levou a descobrir o problema, em alguns momentos do dia, quando a carga de processos é maior, tenho uma lentidão grande no banco, e o tempo de execução de alguns processos aumenta muito, quando isso acontece, na visualização gráfica da principal atividade do monitor de desempenho do Interprise Manager o System I/O atinge níveis estratos féricos; - A desfragmentação foi com a intenção de resolver, inclusive era uma das recomendações do advisor de segmento; - Nenhum erro no alert log. --- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster escreveu > > Bom dia Raul > > Olha, tem bastante coisa pra analisar, dificil dizer assim, mas pra > ajudar, responda a algumas perguntas: > > - Que 10g é este teu banco? 10.2.0.1? 10.2.0.5? > - Você tem os CPUs/PSUs atualizados? > - O que levou você a descobrir que seu problema é System I/O? > - A desfragmentação dos objetos foi uma tentativa de resolver o > problema ou um possível causador? > - Algum erro no alert log? > > > 2011/6/8 raulcsneto : > > Bom dia > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle. > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > > totalizando 544Gb para Dados e Indices; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Redo; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Archives; > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > > Stripes de 512k; > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > uniforme de 512k com datafiles de 2Gb; > > > > Recentemente movi todas as tabelas e indices para tablespaces novas para > > eliminar a fragmentação; > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está > > o problema, seria de grande valor par mim, pois já esgotei todas as minhas > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em > > todas elas: > > > > ÍNDICE DE ACERTOS NO CACHE > > == > > (quanto mais BHR próximo a 1, melhor) > > > > column bhr format 9.99 > > column mydate heading 'Ano Me Di Hora' > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > new.name "Buffer Pool", > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) bhr > > from > > dba_hist_buffer_pool_stat old, > > dba_hist_buffer_pool_stat new, > > dba_hist_snapshot sn > > where > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) > 0 > > and > > new.name = old.name > > and > > new.snap_id = sn.snap_id > > and > > old.snap_id = sn.snap_id-1 > > order by mydate; > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > == > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > objetos, como sequences) > > > > select > > parameter "Parametro", > > gets, > > Getmisses , > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > > from v$rowcache > > where gets+getmisses <>0 > > group by parameter, gets, getmisses ; > > > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > = > > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > > > select Username, > > OSUSER, > > Consistent_Gets, > > Block_Gets, > > Physical_Reads, > > 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > > ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > > from V$SESSION,V$SESS_IO > > where V$SESSION.SID = V$SESS_IO.SID > > and ( Consistent_Gets + Block_Gets )>0 > > and username is not null > > order by Username,"Hit Ratio %"; > > > > ÍNDICES DE CONTENÇÃO DE LATCH DE REDO > > = > > (quanto mais abaixo de 1 os ratios, melhor) > > > > SET feedback OFF > > COLUMN name FORMAT a15 > > COLUMN gets FORMAT > > COLUMN misses FORMAT 99 > > COLUMN immediate_
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Bom dia Raul, Em alguns momentos do dia, quando a carga de processos é maior, tenho uma lentidão grande no banco, e o tempo de execução de alguns processos aumenta muito, quando isso acontece, na visualização gráfica da principal atividade do monitor de desempenho do Interprise Manager o System I/O atinge níveis estratos féricos. --- Em oracle_br@yahoogrupos.com.br, "Raul Francisco Costa F. de Andrade, DBA" escreveu > > Bom dia meu amigo o que te faz perceber que está tendo muito I/O? como > está monitorando isso? > > --- > *Raul Francisco da Costa Ferreira de Andrade* > *DBA - OCP - Oracle Certified Professional* > *COBIT Foundation 4.1 > Celular:(41)8855-8874 Claro > *email: raulfdba@... > Skype: raul.andrade > msn:raulandrade@... > www.clickdba.com > > *"A adversidade leva alguns a serem vencidos > e outros a baterem recordes." * > William Arthur Ward > > > > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > > > > > > > Bom dia > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle. > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > > totalizando 544Gb para Dados e Indices; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Redo; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Archives; > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > > Stripes de 512k; > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > uniforme de 512k com datafiles de 2Gb; > > > > Recentemente movi todas as tabelas e indices para tablespaces novas para > > eliminar a fragmentação; > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está > > o problema, seria de grande valor par mim, pois já esgotei todas as minhas > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em > > todas elas: > > > > ÍNDICE DE ACERTOS NO CACHE > > == > > (quanto mais BHR próximo a 1, melhor) > > > > column bhr format 9.99 > > column mydate heading 'Ano Me Di Hora' > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > new.name "Buffer Pool", > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) bhr > > from > > dba_hist_buffer_pool_stat old, > > dba_hist_buffer_pool_stat new, > > dba_hist_snapshot sn > > where > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) > 0 > > and > > new.name = old.name > > and > > new.snap_id = sn.snap_id > > and > > old.snap_id = sn.snap_id-1 > > order by mydate; > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > == > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > objetos, como sequences) > > > > select > > parameter "Parametro", > > gets, > > Getmisses , > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > > from v$rowcache > > where gets+getmisses <>0 > > group by parameter, gets, getmisses ; > > > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > = > > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > > > select Username, > > OSUSER, > > Consistent_Gets, > > Block_Gets, > > Physical_Reads, > > 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > > ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > > from V$SESSION,V$SESS_IO > > where V$SESSION.SID = V$SESS_IO.SID > > and ( Consistent_Gets + Block_Gets )>0 > > and username is not null > > order by Username,"Hit Ratio %"; > > > > ÍNDICES DE CONTENÇÃO DE LATCH DE REDO > > = > > (quanto mais abaixo de 1 os ratios, melhor) > > > > SET feedback OFF > > COLUMN name FORMAT a15 > > COLUMN gets FORMAT > > COLUMN misses FORMAT 99 > > COLUMN immediate_gets FORMAT HEADING 'IMM_GETS' > > COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES' > > PROMPT Examining Contention for Redo Log Buffer Latches... > > PROMPT
[oracle_br] Re: Problemas com System I/O (Estou Desesperado)
Bom dia Gerson, Até semana passada eu tinha dois volumes separados de RAID 10 com 4 discos de 143Gb 15.000RPM um para dados e outro para índices (o problema já ocorria nesta ocasião) então após ler algumas coisas e conversar com um amigo, que já fez isso e obteve sucesso, decidi criar um volume maior, juntando os 8 discos, assim eu teria o dobro de discos para a controladora fazer Striping no momento de leitura/gravação talvez, melhorando o problema de I/O, porém parece que tudo permaneceu como estava (ou seja acho que o problema não era disco) --- Em oracle_br@yahoogrupos.com.br, Gerson Junior escreveu > > Pelo que vi, dados e indices estão no mesmo range de discos, é isso? > > Não seria viável separar? > > > > > Gerson S. de Vasconcelos Júnior > OCA DBA - Oracle Certified Associate > Fone: (81) 9816-0236 > Msn: gerson.vasconcelos@... > Skype: gersonvjunior > http://www.diaadiaoracle.com.br/ > > > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > > > > > > > Bom dia > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle. > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > > totalizando 544Gb para Dados e Indices; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Redo; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Archives; > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > > Stripes de 512k; > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > uniforme de 512k com datafiles de 2Gb; > > > > Recentemente movi todas as tabelas e indices para tablespaces novas para > > eliminar a fragmentação; > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está > > o problema, seria de grande valor par mim, pois já esgotei todas as minhas > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em > > todas elas: > > > > ÍNDICE DE ACERTOS NO CACHE > > == > > (quanto mais BHR próximo a 1, melhor) > > > > column bhr format 9.99 > > column mydate heading 'Ano Me Di Hora' > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > new.name "Buffer Pool", > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) bhr > > from > > dba_hist_buffer_pool_stat old, > > dba_hist_buffer_pool_stat new, > > dba_hist_snapshot sn > > where > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) > 0 > > and > > new.name = old.name > > and > > new.snap_id = sn.snap_id > > and > > old.snap_id = sn.snap_id-1 > > order by mydate; > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > == > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > objetos, como sequences) > > > > select > > parameter "Parametro", > > gets, > > Getmisses , > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > > from v$rowcache > > where gets+getmisses <>0 > > group by parameter, gets, getmisses ; > > > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > = > > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > > > select Username, > > OSUSER, > > Consistent_Gets, > > Block_Gets, > > Physical_Reads, > > 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > > ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > > from V$SESSION,V$SESS_IO > > where V$SESSION.SID = V$SESS_IO.SID > > and ( Consistent_Gets + Block_Gets )>0 > > and username is not null > > order by Username,"Hit Ratio %"; > > > > ÍNDICES DE CONTENÇÃO DE LATCH DE REDO > > = > > (quanto mais abaixo de 1 os ratios, melhor) > > > > SET feedback OFF > > COLUMN name FORMAT a15 > > COLUMN gets FORMAT > > COLUMN misses FORMAT 99 > > COLUMN immediate_gets FORMAT HEADING 'IMM_GETS' > > COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES' > > PROMPT Examining Contention for Redo Log Buffer Latches... > > PROMPT > > > > SELECT nam
Re: [oracle_br] Problemas com System I/O (Estou Desesperado)
raul, pelo que entendi, vc tem 20GB de memória física e está usando 18GB para o Oracle. imagino que seu servidor deve estar usando bastante swap, e o load average acaba subindo bastante. minha análise é bastante superficial, mas recomendo vc reduzir a quantidade de memória alocada para o banco. se vc estiver usando "automatic memory management" (sga_target), procure reduzir o valor desse parâmetro e indicar valores para os parâmetros individuais. exemplo: sga_target=12GB db_cache_size=6GB shared_pool_size=4GB (folga=2GB para o AMM realocar conforme necessário, além das outras áreas de memória menores, como shared_pool_reserved_size, stream_pool_size etc.). pga_aggregate_target=3GB (esta memória não é considerada no sga_target) faça os ajustes e nos avise do resultado, para sabermos se a sugestão foi boa. boa sorte. On Jun 08, 2011, at 9:06 , raulcsneto wrote: > Bom dia > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de System > I/O, será que alguem poderia me ajudar a verificar a causa deste problema, > segue abaixo um resumo do meu cenário e das ações que já tomei: > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle. > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > totalizando 544Gb para Dados e Indices; > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > totalizando 272Gb para Redo; > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > totalizando 272Gb para Archives; > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > Stripes de 512k; > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > uniforme de 512k com datafiles de 2Gb; > > Recentemente movi todas as tabelas e indices para tablespaces novas para > eliminar a fragmentação; > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está o > problema, seria de grande valor par mim, pois já esgotei todas as minhas > possibilidades, e a várias noites já não sei o que é dormir direito. > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em > todas elas: > > ÍNDICE DE ACERTOS NO CACHE > == > (quanto mais BHR próximo a 1, melhor) > > column bhr format 9.99 > column mydate heading 'Ano Me Di Hora' > select to_char(end_interval_time,'-mm-dd HH24') mydate, > new.name "Buffer Pool", > (((new.consistent_gets-old.consistent_gets)+ > (new.db_block_gets-old.db_block_gets))- > (new.physical_reads-old.physical_reads)) / > ((new.consistent_gets-old.consistent_gets)+ > (new.db_block_gets-old.db_block_gets))bhr > from > dba_hist_buffer_pool_stat old, > dba_hist_buffer_pool_stat new, > dba_hist_snapshot sn > where > (((new.consistent_gets-old.consistent_gets)+ > (new.db_block_gets-old.db_block_gets))- > (new.physical_reads-old.physical_reads)) / > ((new.consistent_gets-old.consistent_gets)+ > (new.db_block_gets-old.db_block_gets)) > 0 > and > new.name = old.name > and > new.snap_id = sn.snap_id > and > old.snap_id = sn.snap_id-1 > order by mydate; > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > == > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > objetos, como sequences) > > select > parameter "Parametro", > gets, > Getmisses , > getmisses/(gets+getmisses)*100 "Taxa de erro", > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > from v$rowcache > where gets+getmisses <>0 > group by parameter, gets, getmisses ; > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > = > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > select Username, > OSUSER, > Consistent_Gets, > Block_Gets, > Physical_Reads, > 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > from V$SESSION,V$SESS_IO > where V$SESSION.SID = V$SESS_IO.SID > and ( Consistent_Gets + Block_Gets )>0 > and username is not null > order by Username,"Hit Ratio %"; > > ÍNDICES DE CONTENÇÃO DE LATCH DE REDO > = > (quanto mais abaixo de 1 os ratios, melhor) > > SET feedback OFF > COLUMN name FORMAT a15 > COLUMN gets FORMAT > COLUMN misses FORMAT 99 > COLUMN immediate_gets FORMAT HEADING 'IMM_GETS' > COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES' > PROMPT Examining Contention for Redo Log Buffer Latches... > PROMPT > > SELECT name, gets, misses, immediate_gets, immediate_misses, > Decode(gets,0,0,misses/gets*100) ratio1, > Decode(immediate_gets+immediate_misses,0,0, > immediate_misses/(immediate_gets+immediate_misses)*100) ratio2 > FROM v$latch WHER
Re: [oracle_br] Problemas com System I/O (Estou Desesperado)
Bom dia Raul
Olha, tem bastante coisa pra analisar, dificil dizer assim, mas pra
ajudar, responda a algumas perguntas:
- Que 10g é este teu banco? 10.2.0.1? 10.2.0.5?
- Você tem os CPUs/PSUs atualizados?
- O que levou você a descobrir que seu problema é System I/O?
- A desfragmentação dos objetos foi uma tentativa de resolver o
problema ou um possível causador?
- Algum erro no alert log?
2011/6/8 raulcsneto :
> Bom dia
>
> Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de System
> I/O, será que alguem poderia me ajudar a verificar a causa deste problema,
> segue abaixo um resumo do meu cenário e das ações que já tomei:
>
> O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core
> Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle.
>
> Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10,
> totalizando 544Gb para Dados e Indices;
>
> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
> totalizando 272Gb para Redo;
>
> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
> totalizando 272Gb para Archives;
>
> Estes tres volumes estão em uma controladora PERC6/E todos segmentados em
> Stripes de 512k;
>
> Possuo Tablespaces separadas para Dados e Indices criadas com alocação
> uniforme de 512k com datafiles de 2Gb;
>
> Recentemente movi todas as tabelas e indices para tablespaces novas para
> eliminar a fragmentação;
>
> Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está o
> problema, seria de grande valor par mim, pois já esgotei todas as minhas
> possibilidades, e a várias noites já não sei o que é dormir direito.
>
> Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em
> todas elas:
>
> ÍNDICE DE ACERTOS NO CACHE
> ==
> (quanto mais BHR próximo a 1, melhor)
>
> column bhr format 9.99
> column mydate heading 'Ano Me Di Hora'
> select to_char(end_interval_time,'-mm-dd HH24') mydate,
> new.name "Buffer Pool",
> (((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets))-
> (new.physical_reads-old.physical_reads)) /
> ((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets)) bhr
> from
> dba_hist_buffer_pool_stat old,
> dba_hist_buffer_pool_stat new,
> dba_hist_snapshot sn
> where
> (((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets))-
> (new.physical_reads-old.physical_reads)) /
> ((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets)) > 0
> and
> new.name = old.name
> and
> new.snap_id = sn.snap_id
> and
> old.snap_id = sn.snap_id-1
> order by mydate;
>
> ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS
> ==
> (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns
> objetos, como sequences)
>
> select
> parameter "Parametro",
> gets,
> Getmisses ,
> getmisses/(gets+getmisses)*100 "Taxa de erro",
> (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto"
> from v$rowcache
> where gets+getmisses <>0
> group by parameter, gets, getmisses ;
>
> ÍNDICE DE ACERTOS NO CACHE POR SESSÃO
> =
> (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável)
>
> select Username,
> OSUSER,
> Consistent_Gets,
> Block_Gets,
> Physical_Reads,
> 100*( Consistent_Gets + Block_Gets - Physical_Reads)/
> ( Consistent_Gets + Block_Gets ) "Hit Ratio %"
> from V$SESSION,V$SESS_IO
> where V$SESSION.SID = V$SESS_IO.SID
> and ( Consistent_Gets + Block_Gets )>0
> and username is not null
> order by Username,"Hit Ratio %";
>
> ÍNDICES DE CONTENÇÃO DE LATCH DE REDO
> =
> (quanto mais abaixo de 1 os ratios, melhor)
>
> SET feedback OFF
> COLUMN name FORMAT a15
> COLUMN gets FORMAT
> COLUMN misses FORMAT 99
> COLUMN immediate_gets FORMAT HEADING 'IMM_GETS'
> COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES'
> PROMPT Examining Contention for Redo Log Buffer Latches...
> PROMPT
>
> SELECT name, gets, misses, immediate_gets, immediate_misses,
> Decode(gets,0,0,misses/gets*100) ratio1,
> Decode(immediate_gets+immediate_misses,0,0,
> immediate_misses/(immediate_gets+immediate_misses)*100) ratio2
> FROM v$latch WHERE name IN ('redo allocation', 'redo copy');
>
> ORDENAÇÕES EM MEMÓRIA/DISCO
> ===
> (quanto mais memória e menos disco, melhor)
>
> SET HEADING OFF
> SET FEEDBACK OFF
> COLUMN name FORMAT a30
> COLUMN value FORMAT 9990
>
> SELECT name, value FROM v$sysstat
> WHERE name IN ('sorts (memory)', 'sorts (disk)');
>
>
>
>
>
>
>
Re: [oracle_br] Problemas com System I/O (Estou Desesperado)
Bom dia, Gera um relatório AWR do período em que acontece o problema e anexa. Vai ajudar bastante. 2011/6/8 Raul Francisco Costa F. de Andrade, DBA > Bom dia meu amigo o que te faz perceber que está tendo muito I/O? como > está monitorando isso? > > --- > *Raul Francisco da Costa Ferreira de Andrade* > *DBA - OCP - Oracle Certified Professional* > *COBIT Foundation 4.1 > Celular:(41)8855-8874 Claro > *email: raulf...@gmail.com > Skype: raul.andrade > msn:raulandr...@ibest.com.br > www.clickdba.com > > *"A adversidade leva alguns a serem vencidos > e outros a baterem recordes." * > William Arthur Ward > > > > Em 8 de junho de 2011 09:06, raulcsneto escreveu: > > > > > > > Bom dia > > > > Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de > > System I/O, será que alguem poderia me ajudar a verificar a causa deste > > problema, segue abaixo um resumo do meu cenário e das ações que já tomei: > > > > O Oracle 10G roda em um servidor Redhat 5 com dois processadores > Quad-core > > Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o > oracle. > > > > Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10, > > totalizando 544Gb para Dados e Indices; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Redo; > > > > Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0, > > totalizando 272Gb para Archives; > > > > Estes tres volumes estão em uma controladora PERC6/E todos segmentados em > > Stripes de 512k; > > > > Possuo Tablespaces separadas para Dados e Indices criadas com alocação > > uniforme de 512k com datafiles de 2Gb; > > > > Recentemente movi todas as tabelas e indices para tablespaces novas para > > eliminar a fragmentação; > > > > Caso alguem conheça algo que eu possa fazer para tentar descobrir onde > está > > o problema, seria de grande valor par mim, pois já esgotei todas as > minhas > > possibilidades, e a várias noites já não sei o que é dormir direito. > > > > Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em > > todas elas: > > > > ÍNDICE DE ACERTOS NO CACHE > > == > > (quanto mais BHR próximo a 1, melhor) > > > > column bhr format 9.99 > > column mydate heading 'Ano Me Di Hora' > > select to_char(end_interval_time,'-mm-dd HH24') mydate, > > new.name "Buffer Pool", > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) bhr > > from > > dba_hist_buffer_pool_stat old, > > dba_hist_buffer_pool_stat new, > > dba_hist_snapshot sn > > where > > (((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets))- > > (new.physical_reads-old.physical_reads)) / > > ((new.consistent_gets-old.consistent_gets)+ > > (new.db_block_gets-old.db_block_gets)) > 0 > > and > > new.name = old.name > > and > > new.snap_id = sn.snap_id > > and > > old.snap_id = sn.snap_id-1 > > order by mydate; > > > > ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS > > == > > (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns > > objetos, como sequences) > > > > select > > parameter "Parametro", > > gets, > > Getmisses , > > getmisses/(gets+getmisses)*100 "Taxa de erro", > > (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto" > > from v$rowcache > > where gets+getmisses <>0 > > group by parameter, gets, getmisses ; > > > > ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > = > > (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável) > > > > select Username, > > OSUSER, > > Consistent_Gets, > > Block_Gets, > > Physical_Reads, > > 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > > ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > > from V$SESSION,V$SESS_IO > > where V$SESSION.SID = V$SESS_IO.SID > > and ( Consistent_Gets + Block_Gets )>0 > > and username is not null > > order by Username,"Hit Ratio %"; > > > > ÍNDICES DE CONTENÇÃO DE LATCH DE REDO > > = > > (quanto mais abaixo de 1 os ratios, melhor) > > > > SET feedback OFF > > COLUMN name FORMAT a15 > > COLUMN gets FORMAT > > COLUMN misses FORMAT 99 > > COLUMN immediate_gets FORMAT HEADING 'IMM_GETS' > > COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES' > > PROMPT Examining Contention for Redo Log Buffer Latches... > > PROMPT > > > > SELECT name, gets, misses, immediate_gets, immediate_misses, > > Decode(gets,0,0,misses/gets*100) ratio1, > > Decode(immediate_gets+immediate_misses,0,0, > > immediate_misses/(immediate_gets+immediate_misses)*100) ratio2 > > FROM v$latch WH
Re: [oracle_br] Problemas com System I/O (Estou Desesperado)
Bom dia meu amigo o que te faz perceber que está tendo muito I/O? como
está monitorando isso?
---
*Raul Francisco da Costa Ferreira de Andrade*
*DBA - OCP - Oracle Certified Professional*
*COBIT Foundation 4.1
Celular:(41)8855-8874 Claro
*email: raulf...@gmail.com
Skype: raul.andrade
msn:raulandr...@ibest.com.br
www.clickdba.com
*"A adversidade leva alguns a serem vencidos
e outros a baterem recordes." *
William Arthur Ward
Em 8 de junho de 2011 09:06, raulcsneto escreveu:
>
>
> Bom dia
>
> Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de
> System I/O, será que alguem poderia me ajudar a verificar a causa deste
> problema, segue abaixo um resumo do meu cenário e das ações que já tomei:
>
> O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core
> Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle.
>
> Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10,
> totalizando 544Gb para Dados e Indices;
>
> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
> totalizando 272Gb para Redo;
>
> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
> totalizando 272Gb para Archives;
>
> Estes tres volumes estão em uma controladora PERC6/E todos segmentados em
> Stripes de 512k;
>
> Possuo Tablespaces separadas para Dados e Indices criadas com alocação
> uniforme de 512k com datafiles de 2Gb;
>
> Recentemente movi todas as tabelas e indices para tablespaces novas para
> eliminar a fragmentação;
>
> Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está
> o problema, seria de grande valor par mim, pois já esgotei todas as minhas
> possibilidades, e a várias noites já não sei o que é dormir direito.
>
> Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em
> todas elas:
>
> ÍNDICE DE ACERTOS NO CACHE
> ==
> (quanto mais BHR próximo a 1, melhor)
>
> column bhr format 9.99
> column mydate heading 'Ano Me Di Hora'
> select to_char(end_interval_time,'-mm-dd HH24') mydate,
> new.name "Buffer Pool",
> (((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets))-
> (new.physical_reads-old.physical_reads)) /
> ((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets)) bhr
> from
> dba_hist_buffer_pool_stat old,
> dba_hist_buffer_pool_stat new,
> dba_hist_snapshot sn
> where
> (((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets))-
> (new.physical_reads-old.physical_reads)) /
> ((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets)) > 0
> and
> new.name = old.name
> and
> new.snap_id = sn.snap_id
> and
> old.snap_id = sn.snap_id-1
> order by mydate;
>
> ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS
> ==
> (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns
> objetos, como sequences)
>
> select
> parameter "Parametro",
> gets,
> Getmisses ,
> getmisses/(gets+getmisses)*100 "Taxa de erro",
> (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto"
> from v$rowcache
> where gets+getmisses <>0
> group by parameter, gets, getmisses ;
>
> ÍNDICE DE ACERTOS NO CACHE POR SESSÃO
> =
> (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável)
>
> select Username,
> OSUSER,
> Consistent_Gets,
> Block_Gets,
> Physical_Reads,
> 100*( Consistent_Gets + Block_Gets - Physical_Reads)/
> ( Consistent_Gets + Block_Gets ) "Hit Ratio %"
> from V$SESSION,V$SESS_IO
> where V$SESSION.SID = V$SESS_IO.SID
> and ( Consistent_Gets + Block_Gets )>0
> and username is not null
> order by Username,"Hit Ratio %";
>
> ÍNDICES DE CONTENÇÃO DE LATCH DE REDO
> =
> (quanto mais abaixo de 1 os ratios, melhor)
>
> SET feedback OFF
> COLUMN name FORMAT a15
> COLUMN gets FORMAT
> COLUMN misses FORMAT 99
> COLUMN immediate_gets FORMAT HEADING 'IMM_GETS'
> COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES'
> PROMPT Examining Contention for Redo Log Buffer Latches...
> PROMPT
>
> SELECT name, gets, misses, immediate_gets, immediate_misses,
> Decode(gets,0,0,misses/gets*100) ratio1,
> Decode(immediate_gets+immediate_misses,0,0,
> immediate_misses/(immediate_gets+immediate_misses)*100) ratio2
> FROM v$latch WHERE name IN ('redo allocation', 'redo copy');
>
> ORDENAÇÕES EM MEMÓRIA/DISCO
> ===
> (quanto mais memória e menos disco, melhor)
>
> SET HEADING OFF
> SET FEEDBACK OFF
> COLUMN name FORMAT a30
> COLUMN value FORMAT 9990
>
> SELECT name, value FROM v$sysstat
> WHERE name IN ('sorts (memory)', 'sorts (disk)');
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Problemas com System I/O (Estou Desesperado)
Pelo que vi, dados e indices estão no mesmo range de discos, é isso?
Não seria viável separar?
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 8 de junho de 2011 09:06, raulcsneto escreveu:
>
>
> Bom dia
>
> Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de
> System I/O, será que alguem poderia me ajudar a verificar a causa deste
> problema, segue abaixo um resumo do meu cenário e das ações que já tomei:
>
> O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core
> Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle.
>
> Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10,
> totalizando 544Gb para Dados e Indices;
>
> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
> totalizando 272Gb para Redo;
>
> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
> totalizando 272Gb para Archives;
>
> Estes tres volumes estão em uma controladora PERC6/E todos segmentados em
> Stripes de 512k;
>
> Possuo Tablespaces separadas para Dados e Indices criadas com alocação
> uniforme de 512k com datafiles de 2Gb;
>
> Recentemente movi todas as tabelas e indices para tablespaces novas para
> eliminar a fragmentação;
>
> Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está
> o problema, seria de grande valor par mim, pois já esgotei todas as minhas
> possibilidades, e a várias noites já não sei o que é dormir direito.
>
> Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em
> todas elas:
>
> ÍNDICE DE ACERTOS NO CACHE
> ==
> (quanto mais BHR próximo a 1, melhor)
>
> column bhr format 9.99
> column mydate heading 'Ano Me Di Hora'
> select to_char(end_interval_time,'-mm-dd HH24') mydate,
> new.name "Buffer Pool",
> (((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets))-
> (new.physical_reads-old.physical_reads)) /
> ((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets)) bhr
> from
> dba_hist_buffer_pool_stat old,
> dba_hist_buffer_pool_stat new,
> dba_hist_snapshot sn
> where
> (((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets))-
> (new.physical_reads-old.physical_reads)) /
> ((new.consistent_gets-old.consistent_gets)+
> (new.db_block_gets-old.db_block_gets)) > 0
> and
> new.name = old.name
> and
> new.snap_id = sn.snap_id
> and
> old.snap_id = sn.snap_id-1
> order by mydate;
>
> ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS
> ==
> (hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns
> objetos, como sequences)
>
> select
> parameter "Parametro",
> gets,
> Getmisses ,
> getmisses/(gets+getmisses)*100 "Taxa de erro",
> (1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto"
> from v$rowcache
> where gets+getmisses <>0
> group by parameter, gets, getmisses ;
>
> ÍNDICE DE ACERTOS NO CACHE POR SESSÃO
> =
> (hit ratio deve estar próximo a 1 - apesar de 1 ser improvável)
>
> select Username,
> OSUSER,
> Consistent_Gets,
> Block_Gets,
> Physical_Reads,
> 100*( Consistent_Gets + Block_Gets - Physical_Reads)/
> ( Consistent_Gets + Block_Gets ) "Hit Ratio %"
> from V$SESSION,V$SESS_IO
> where V$SESSION.SID = V$SESS_IO.SID
> and ( Consistent_Gets + Block_Gets )>0
> and username is not null
> order by Username,"Hit Ratio %";
>
> ÍNDICES DE CONTENÇÃO DE LATCH DE REDO
> =
> (quanto mais abaixo de 1 os ratios, melhor)
>
> SET feedback OFF
> COLUMN name FORMAT a15
> COLUMN gets FORMAT
> COLUMN misses FORMAT 99
> COLUMN immediate_gets FORMAT HEADING 'IMM_GETS'
> COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES'
> PROMPT Examining Contention for Redo Log Buffer Latches...
> PROMPT
>
> SELECT name, gets, misses, immediate_gets, immediate_misses,
> Decode(gets,0,0,misses/gets*100) ratio1,
> Decode(immediate_gets+immediate_misses,0,0,
> immediate_misses/(immediate_gets+immediate_misses)*100) ratio2
> FROM v$latch WHERE name IN ('redo allocation', 'redo copy');
>
> ORDENAÇÕES EM MEMÓRIA/DISCO
> ===
> (quanto mais memória e menos disco, melhor)
>
> SET HEADING OFF
> SET FEEDBACK OFF
> COLUMN name FORMAT a30
> COLUMN value FORMAT 9990
>
> SELECT name, value FROM v$sysstat
> WHERE name IN ('sorts (memory)', 'sorts (disk)');
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
--
>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira
[oracle_br] Problemas com System I/O (Estou Desesperado)
Bom dia
Tenho um banco de 230Gb rodando no 10G estou tendo muitos problemas de System
I/O, será que alguem poderia me ajudar a verificar a causa deste problema,
segue abaixo um resumo do meu cenário e das ações que já tomei:
O Oracle 10G roda em um servidor Redhat 5 com dois processadores Quad-core Xeon
2.66Ghz, 20Gb de memória, dos quais 18Gb estão alocadas para o oracle.
Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb em RAID 10,
totalizando 544Gb para Dados e Indices;
Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
totalizando 272Gb para Redo;
Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb em RAID 0,
totalizando 272Gb para Archives;
Estes tres volumes estão em uma controladora PERC6/E todos segmentados em
Stripes de 512k;
Possuo Tablespaces separadas para Dados e Indices criadas com alocação uniforme
de 512k com datafiles de 2Gb;
Recentemente movi todas as tabelas e indices para tablespaces novas para
eliminar a fragmentação;
Caso alguem conheça algo que eu possa fazer para tentar descobrir onde está o
problema, seria de grande valor par mim, pois já esgotei todas as minhas
possibilidades, e a várias noites já não sei o que é dormir direito.
Seguem abaixo algumas querys que fiz, meus resultados estão de acordo em todas
elas:
ÍNDICE DE ACERTOS NO CACHE
==
(quanto mais BHR próximo a 1, melhor)
column bhr format 9.99
column mydate heading 'Ano Me Di Hora'
select to_char(end_interval_time,'-mm-dd HH24') mydate,
new.name "Buffer Pool",
(((new.consistent_gets-old.consistent_gets)+
(new.db_block_gets-old.db_block_gets))-
(new.physical_reads-old.physical_reads)) /
((new.consistent_gets-old.consistent_gets)+
(new.db_block_gets-old.db_block_gets))bhr
from
dba_hist_buffer_pool_stat old,
dba_hist_buffer_pool_stat new,
dba_hist_snapshot sn
where
(((new.consistent_gets-old.consistent_gets)+
(new.db_block_gets-old.db_block_gets))-
(new.physical_reads-old.physical_reads)) /
((new.consistent_gets-old.consistent_gets)+
(new.db_block_gets-old.db_block_gets)) > 0
and
new.name = old.name
and
new.snap_id = sn.snap_id
and
old.snap_id = sn.snap_id-1
order by mydate;
ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE DADOS
==
(hit ratio deve estar próximo a 1 - apesar de ser inviável para alguns objetos,
como sequences)
select
parameter "Parametro",
gets,
Getmisses ,
getmisses/(gets+getmisses)*100 "Taxa de erro",
(1-(sum(getmisses)/ (sum(gets)+sum(getmisses*100 "Taxa de acerto"
from v$rowcache
where gets+getmisses <>0
group by parameter, gets, getmisses ;
ÍNDICE DE ACERTOS NO CACHE POR SESSÃO
=
(hit ratio deve estar próximo a 1 - apesar de 1 ser improvável)
select Username,
OSUSER,
Consistent_Gets,
Block_Gets,
Physical_Reads,
100*( Consistent_Gets + Block_Gets - Physical_Reads)/
( Consistent_Gets + Block_Gets ) "Hit Ratio %"
from V$SESSION,V$SESS_IO
where V$SESSION.SID = V$SESS_IO.SID
and ( Consistent_Gets + Block_Gets )>0
and username is not null
order by Username,"Hit Ratio %";
ÍNDICES DE CONTENÇÃO DE LATCH DE REDO
=
(quanto mais abaixo de 1 os ratios, melhor)
SET feedback OFF
COLUMN name FORMAT a15
COLUMN gets FORMAT
COLUMN misses FORMAT 99
COLUMN immediate_gets FORMAT HEADING 'IMM_GETS'
COLUMN immediate_misses FORMAT HEADING 'IMM_MISSES'
PROMPT Examining Contention for Redo Log Buffer Latches...
PROMPT
SELECT name, gets, misses, immediate_gets, immediate_misses,
Decode(gets,0,0,misses/gets*100) ratio1,
Decode(immediate_gets+immediate_misses,0,0,
immediate_misses/(immediate_gets+immediate_misses)*100) ratio2
FROM v$latch WHERE name IN ('redo allocation', 'redo copy');
ORDENAÇÕES EM MEMÓRIA/DISCO
===
(quanto mais memória e menos disco, melhor)
SET HEADING OFF
SET FEEDBACK OFF
COLUMN name FORMAT a30
COLUMN value FORMAT 9990
SELECT name, value FROM v$sysstat
WHERE name IN ('sorts (memory)', 'sorts (disk)');
