Menu de navegação

[raulcsnetoParticipante]

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)’);

[CleitonHanzenParticipante]

Opá….

System I/O geralmente está relacionado a contenção em control files, redo logs, archives ou coisas do gênero.

Tire um relatório do AWR e poste pra gente dar uma olhada.

abs.

[hudsonaParticipante]

Exatamente, tira um AWR lá é possivel verificar as principais waits events de i/o que o sistema esta tendo, além de outras info importantes.
Também é interessante verificar com os utilitarios do unix (iotsat,vmstat) o status do S.O no pico de uso do teu sistema.

Abs

[raulcsnetoParticipante]

Boa tarde, gerei o AWR não sei se dá p/ anexa-lo no forum então coloquei no megaupload, segue o link http://www.megaupload.com/?d=IJFD2QRD

[CleitonHanzenParticipante]

Opá….

Esse teu AWR tá com uma faixa muito grande de horário. O ideal é reduzir para 1 hora. Como vc está com problemas de performance, até modifique para ser coletado de 30 em 30 minutos. E poste um AWR desses 30 minutos de quando o problema estiver acontecendo…..

😉

[hudsonaParticipante]

Não consigo acessar o megaupload, mas se puder postar as 10 principais wait events e Latch Activity da última hora.

[Sousa04Participante]

para alterar o snapshot

Exec dbms_workload_repository.modify_snapshot_settings (retention=>20160, interval=>30)

[vieriParticipante]

de cara eu vi que 40% dos seus Wait’s são db_file_scaterread_read,

isso significa que vc não está fazendo leiturta sequencial,
certamente está com alguns full_table_scans em tabelas grandes,
pegue as querys com maior % do AWR e roda o plano de execução nelas.

consegue fazer isso..

[raulcsnetoParticipante]

Bom dia, finalmente consegui fazer o AWR de um periodo critico, segue o link http://www.megaupload.com/?d=DYRNKXTH

Ja rodei todos os advisors de segmentos e de SQL possiveis, e não obtive resultado positivo, investigando, descobri uma bendita de uma query que faz um full table scan em uma tabela de 16gb, acho que ela está causando grande parte da minha dor de cabeça mas como o sistema é de terceiros, não tenho como mexer na instrução, vocês conhecem algo que eu possa fazer para otimizar isso?

Obrigado

[rmanParticipante]

[quote=”raulcsneto”:e5k8jibc]Bom dia, finalmente consegui fazer o AWR de um periodo critico, segue o link http://www.megaupload.com/?d=DYRNKXTH

Ja rodei todos os advisors de segmentos e de SQL possiveis, e não obtive resultado positivo, investigando, descobri uma bendita de uma query que faz um full table scan em uma tabela de 16gb, acho que ela está causando grande parte da minha dor de cabeça mas como o sistema é de terceiros, não tenho como mexer na instrução, vocês conhecem algo que eu possa fazer para otimizar isso?

Obrigado[/quote]

Pode ser criado um indice para essa query, evitando o FULL TABLE SCAN.

[vieriParticipante]

entra no sqlplus,
rode o comando.

set autot on exp stats

e em seguida rode a query.

não pode depender apenas dos advisors.

faça isso e coloca aqui o plano de execução.

[hudsonaParticipante]

[quote=”rman”:21jt73g2]

Pode ser criado um indice para essa query, evitando o FULL TABLE SCAN.[/quote]

Se é uma query que faz um Fulll table scan em uma tabela de 16GB é melhor ter cuidado com um indice, porque se ele nao for muito seletivo, o indice não vai ser uma boa idéia.

Abs

[raulcsnetoParticipante]

tentei rodar o comando ele diz que nao pode setar o autot

Cannot SET AUTOT

[vieriParticipante]

este é o comando:

SQL> set autot on exp stat

Não tenha medo de ter indices, tenha medo de não te-lós.

Pode usar o indice virtual se quiser apenas visualizar o plano de execução.

se estou tendo Muitass Waits para scaterred read, significa que tenho full table scan com baixa performance, e precisa sim ter indices testados,
e inicialmente quem irá avaliar isso é o CBO, e em seguida você analisando o plano.

rode o comando que citei acima e depois rode a query e dai continuamos a conversa com o plano de execução exibido.

[raulcsnetoParticipante]

boa tarde, segue o resultado da operação:

SQL> set autot on exp stat;
SQL> set linesize 9999;
SQL> select (SYSDATE – AU.HRENVIO_PTU)243600 DURACAO, AU.NRAUTORIZACAO, AU.AOMEIO_SOLICITACAO, AU.NOARQUIVO_RESPOSTA, AU.AOAPROVACAO_REMOTA from PRODUCAo.AUTORIZACAO AU, PRODUCAo.CONTROLE_INTERCAMBIO_ONLINE C where AU.NRAUTORIZACAO(+) = C.NRAUTORIZACAO and AU.CDSITUACAO = ‘AB’ and AU.HRENVIO_PTU is not null and AU.HRRESPOSTA_PTU is null and AU.CDMOTIVO_CANCELAMENTO is null and C.NRAUTORIZACAO > 1 order by AU.NRAUTORIZACAO ;

DURACAO NRAUTORIZACAO A NOARQUIVO_RESPOSTA A

---

    60      12883786 A \10.0.12.100localposretorno32451983.1in                                                                                          S

Execution Plan

Plan hash value: 2430761173

---

| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |

| 0 | SELECT STATEMENT | | 161K| 9320K| | 185K (3)| 00:04:07 |
| 1 | SORT ORDER BY | | 161K| 9320K| 21M| 185K (3)| 00:04:07 |
| 2 | NESTED LOOPS | | 161K| 9320K| | 183K (3)| 00:04:03 |
|* 3 | TABLE ACCESS FULL| AUTORIZACAO | 309K| 15M| | 183K (3)| 00:04:03 |

|* 4 | INDEX UNIQUE SCAN| PK_CONTROLE_INTERCAMBIO_ONLINE | 1 | 5 | | 0 (0)| 00:00:01 |

Predicate Information (identified by operation id):

3 – filter(“AU”.”HRENVIO_PTU” IS NOT NULL AND “AU”.”CDSITUACAO”=’AB’ AND “AU”
NULL AND “AU”.”CDMOTIVO_CANCELAMENTO” IS NULL AND “AU”.”NRAUTORIZA
4 – access(“AU”.”NRAUTORIZACAO”=”C”.”NRAUTORIZACAO”)
filter(“C”.”NRAUTORIZACAO”>1)

Statistics

    431  recursive calls
      1  db block gets
 477934  consistent gets
 127996  physical reads
    144  redo size
    886  bytes sent via SQL*Net to client
    492  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
     20  sorts (memory)
      0  sorts (disk)
      1  rows processed

SQL>

[Autor]

Posts