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