- Este tópico contém 0 resposta, 1 voz e foi atualizado pela última vez 11 anos, 2 meses atrás por Brancolino.
-
AutorPosts
-
30 de agosto de 2013 às 6:01 pm #105836BrancolinoParticipante
Amigos,
Tenho ambiente com a seguinte configuração:
Oracle RAC Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bit. SO: AIX
O cliente está questionando o tamanho da UNDO, que atualmente está em 106 Gb. Levantei o tamanho pela querie:
SELECT size_allocated.tablespace_name,
size_allocated.size_allocated_mb,
size_used.size_used_mb,
ROUND (size_used.size_used_mb / size_allocated.size_allocated_mb * 100, 2) pct_size_used_mb
FROM (SELECT due.tablespace_name,
SUM (due.BYTES) / 1024 / 1024 AS size_used_mb
FROM dba_undo_extents due GROUP BY due.tablespace_name) size_used,
(SELECT dt.tablespace_name,
SUM(ddf.BYTES)/1024/1024 size_allocated_mb
FROM dba_tablespaces dt, dba_data_files ddf
WHERE dt.tablespace_name = ddf.tablespace_name
AND dt.CONTENTS = 'UNDO'
GROUP BY dt.tablespace_name) size_allocated
WHERE size_allocated.tablespace_name = size_used.tablespace_name(+)
ORDER BY tablespace_name;
Resultado:
TABLESPACE_NAME SIZE_ALLOCATED_MB SIZE_USED_MB PCT_SIZE_USED_MB
UNDOTBS1 71680 59490,8125 82,99
UNDOTBS2 70335 46978,1875 66,79Fiz o calculo sugerido pela Oracle para determinar o tamanho da UNDO, diminui o tempo de retensão, obtive o valor de 30 Gb.
Segue a querie:
select ((ur * (ups * dbs)) + (dbs * 24)/1024)/1024 as total
from (select value as ur
from v$parameter
where name = 'undo_retention'),
(select (sum(undoblks)/sum(((end_time - begin_time)*86400))) as ups
from v$undostat),
(select block_size as dbs
from dba_tablespaces
where tablespace_name= (select value from v$parameter where name = 'undo_tablespace'));
Com a alteração do tempo de retensão, o tamanho da UNDO não diminuiu para o tamanho esperado está em 95 Gb aproximadamente.
A aplicação, está usando aproximadamente 9 Gb deste total:
select s.sid, s.username, s.PROGRAM, (v.rssize)/1024/1024 uso_mb
from gv$rollstat v,
dba_rollback_segs d,
gv$transaction t,
gv$session s
where v.usn = d.segment_id
and t.ses_addr = s.saddr
and t.xidusn = d.segment_id;
Pesquisei, sobre esta diferença dos 86 Gb que estaria “sobrando” e cheguei a querie:
select v.usn, (v.rssize)/1024/1024 uso_mb, d.owner, d.tablespace_name, d.status, d.segment_name, s.segment_type, s.owner
from gv$rollstat v,
dba_rollback_segs d,
dba_segments s
where v.usn = d.segment_id
and d.segment_name = s.segment_name;
Resultado:
[size=3]USN USO_MB OWNER TABLESPACE_NAME STATUS SEGMENT_NAME SEGMENT_TYPE OWNER
83 335,984375 PUBLIC UNDOTBS2 ONLINE _SYSSMU83$ TYPE2 UNDO SYS
73 1220,17188 PUBLIC UNDOTBS2 ONLINE _SYSSMU73$ TYPE2 UNDO SYS
72 820,109375 PUBLIC UNDOTBS2 ONLINE _SYSSMU72$ TYPE2 UNDO SYS
71 956,109375 PUBLIC UNDOTBS2 ONLINE _SYSSMU71$ TYPE2 UNDO SYS
70 760,421875 PUBLIC UNDOTBS2 ONLINE _SYSSMU70$ TYPE2 UNDO SYS
69 865,109375 PUBLIC UNDOTBS2 ONLINE _SYSSMU69$ TYPE2 UNDO SYS
…
[/size]Onde conclui que os segmentos de tipo 2 (TYPE2 UNDO – Gerados automaticamente pelo Oracle) são os que estão “consumindo” esta diferença.
Gostaria da ajuda dos amigos para saber se estou correto na analise, e se tem como diminuir o espaço utilizado pelos segmentos TYPE2.
Muito Obrigado!
-
AutorPosts
- Você deve fazer login para responder a este tópico.