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 <raulf...@gmail.com>: > 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 <raulcsn...@yahoo.com> 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 <gerson.vasconcelos@...> >> 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 <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,'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)'); >> > > >> > > >> > > >> > >> > >> > [As partes desta mensagem que não continham texto foram removidas] >> > >> >> >> > > > [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 > > > -- Ivan Ricardo Schuster OCP 10g/11g OCE RAC 10g/Linux
