Boa tarde, estou enviando o relatório gerado pelo AWR.
De: Hevandro Veiga <hevandr...@gmail.com>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quarta-feira, 8 de Junho de 2011 11:44
Assunto: 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 <jljlsi...@yahoo.com.br>
>
>
> 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 <jljlsilva@...> 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,'yyyy-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 99999999
> >>> COLUMN misses FORMAT 999999
> >>> COLUMN immediate_gets FORMAT 99999999 HEADING 'IMM_GETS'
> >>> COLUMN immediate_misses FORMAT 99999999 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 99999990
> >>>
> >>> SELECT name, value FROM v$sysstat
> >>> WHERE name IN ('sorts (memory)', 'sorts (disk)');
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> ----------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > ----------------------------------------------------------
> >> 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
> >
> >
>
>
>
--
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
[As partes desta mensagem que não continham texto foram removidas]
