Menu de navegação

[AnakimParticipante]

Temos um Oracle Standart Edition que tinha um desempenho considerável, por que rodava em uma máquina octa-core e 5 discos ssds e 15Gigas de ram.
Hoje quando começamos a fazer a leitura de alguns dados de algumas tabelas, para transferir para outro schema ele simplesmente leva mais de 10 horas para executar a query, sendo que estas queries já tinham sido testadas antes e a maior delas rodava em 1 hora e meia, o resto era tudo em minutos. O que poderia estar acontecendo?
Nós também tivemos que fazer um restore de um banco neste servidor, poderia ter sido isso? Porque nós jogamos todos os dados nos datafiles existentes.
E olhando no EM vimos que tinha um wait considerável por causa de IO seria este o problema? Este wait parecia porque o oracle estava tentando alocar mais espaço em disco para o datafile.

[MauroLacerdaParticipante]

Anakim.
Boa noite,

Voce pode fazer o seguinte:

1o) Fazer a atualizacao das estatisticas dos indices.
2o) Efetuar uma desfragmentacao, tipo SKRINK Space.
3o) Se o banco estive em modo Archive, verifique o tamanho dos seus redos logs.

Espero poder ter te ajudado,

abs,

[AnakimParticipante]

Fazendo uma análise profunda vimos que o problema era um tablespace que não era autoextend. Não sabíamos disso por esse banco ser um banco legado.
Mudamos as tablespaces tudo pareceu está normal, até a nossa leitura em disco ficar muito alta e vários inserts ficarem lentos novamente.
Uma das mesagens do oralce:
Hard parsing SQL statements that encountered parse errors was consuming significant database time.[code]

[vieriParticipante]

Você pode nos passar exatamente o nome
do wait que vc verificou no Enterprise Manager?

Se for o problema que eu estou pensando sigue esse passos.

Da uma olhada no espaço em disco no servidor.

comando:
df -h

E de uma olhada ,
se tem alguma tablespace com 100%.

query:

break on report
compute sum of tbs_size_mb on report
compute sum of used on report
compute sum of avail on report

column tsname format a20 heading ‘Tablespace Name’
column tbs_size_mb format 999,999 heading ‘Size|(MB)’
column used format 999,999 heading ‘Used|(MB)’
column avail format 999,999 heading ‘Free|(MB)’
column used_visual format a11 heading ‘Used’
column pct_used format 999 heading ‘% Used’
column flname format a50 heading ‘Filename’
column siz format 999,999,990 heading ‘File Size|(MB)’
column maxsiz format 999,999,990 heading ‘Max Size|(MB)’
column pctmax format 990 heading ‘Pct|Max’

set linesize 1000
set trimspool on
set pagesize 32000
set verify off
set feedback off

PROMPT
PROMPT *************************
PROMPT *** TABLESPACE STATUS ***
PROMPT *************************

SELECT df.tablespace_name tsname
, sum(df.bytes)/1024/1024 tbs_size_mb
, nvl(sum(e.used_bytes)/1024/1024,0) used
, nvl(sum(f.free_bytes)/1024/1024,0) avail
, rpad(‘ ‘||rpad(‘X’,round(sum(e.used_bytes)
10/sum(df.bytes),0), ‘X’),11,’-‘) used_visual
, nvl((sum(e.used_bytes)100)/sum(df.bytes),0) pct_used
FROM sys.dba_data_files df
, (SELECT file_id
, sum(nvl(bytes,0)) used_bytes
FROM sys.dba_extents
GROUP BY file_id) e
, (SELECT max(bytes) free_bytes
, file_id
FROM dba_free_space
GROUP BY file_id) f
WHERE e.file_id(+) = df.file_id
AND df.file_id = f.file_id(+)
GROUP BY df.tablespace_name
ORDER BY 6
/

desconfio que tem uma tablespace
com 100% de utilização, porêm com autoextend
ligado, porêm com um valor de incremento
baixo, deixando o processo lentissímo.

Se for realmente isso,
rode a query abaixo para ver a config
dos datafiles desta tablespace.

select AUTOEXTENSIBLE,INCREMENT_BY from dba_data_files where tablespace_name=’TBPS_ESTOURADA’ ;

Sugiro vc aumenta-lá para um valor considerável caso tenha espaço em disco.

[Autor]

Posts