Gilson, o que vc diz não faz sentido : veja vc, se realmente é
tablespace de UNDO (ie, vc tem undo_management=AUTO e
undo_tablespace=nomedessasuatablespace ), então NECESSARIAMENTE essa
tablespace é LMT, e tablespaces LMT por definição NUNCA FRAGMENTAM,
pois FRAGMENTAÇÃO="espaço livre que não pode ser re-usado por causa
de extents de tamanhos diferentes e não múltiplos entre si", e LMT **
sempre ** tem segmentos de mesmo tamanho ou no máximo múltiplos
diretos...
O reuso de espaço é AUTOMÁTICO também numa tablespace de undo,
provavelmente o que vc deve estar fazendo de ERRADO é consultar o
espaço LIVRE na tablespace , isso é ERRADO, tanto pra tablespaces
TEMP quanto pra tablespaces UNDO o controle é feito pelo bd de forma
DIFERENTE, vc não pode usar uma simples consulta de espaço, tem que
usar as views apropriadas.
   Um teste pra vc , banco 9i, com undo automático, no momento sem
nenhuma trans aberta :
  

==> consulto as views de undo, nada :

[EMAIL PROTECTED]:SQL>@used_rollback_blocks

=> consulto o espaço livre, ele diz que no total de 33720.00 Mbs
tenho 29429.88 Mbs livres :

[EMAIL PROTECTED]:SQL>@tablespaces_free_%_v2
Tablespace(s) a Incluir, já contém %%, [ENTER] = todas:UNDO_TABLESPACE

                                                                     
                                 Total      Free    Free
Tablespace      data File                                         
Space     Space       %
--------------- ----------------------------------------------- ------
-- --------- -------
UNDO_TABLESPACE /u2/oradata/PRDDBOR/undo/undo_tablespace_01.dbf 
2048.00   1768.94   86.37
                /u2/oradata/PRDDBOR/undo/undo_tablespace_02.dbf 
2048.00   1760.94   85.98
                /u2/oradata/PRDDBOR/undo/undo_tablespace_03.dbf 
2048.00   1789.94   87.40
                /u2/oradata/PRDDBOR/undo/undo_tablespace_04.dbf 
2048.00   1781.94   87.01
                /u2/oradata/PRDDBOR/undo/undo_tablespace_05.dbf 
2048.00   1787.25   87.27
                /u2/oradata/PRDDBOR/undo/undo_tablespace_06.dbf 
2048.00   1780.81   86.95
                /u2/oradata/PRDDBOR/undo/undo_tablespace_07.dbf 
2048.00   1797.56   87.77
                /u2/oradata/PRDDBOR/undo/undo_tablespace_08.dbf 
2048.00   1789.56   87.38
                /u2/oradata/PRDDBOR/undo/undo_tablespace_09.dbf 
2048.00   1788.94   87.35
                /u2/oradata/PRDDBOR/undo/undo_tablespace_10.dbf 
2048.00   1788.75   87.34
                /u2/oradata/PRDDBOR/undo/undo_tablespace_11.dbf 
2048.00   1797.75   87.78
                /u2/oradata/PRDDBOR/undo/undo_tablespace_12.dbf 
2048.00   1783.94   87.11
                /u2/oradata/PRDDBOR/undo/undo_tablespace_13.dbf 
2048.00   1793.81   87.59
                /u2/oradata/PRDDBOR/undo/undo_tablespace_14.dbf 
2048.00   1724.88   84.22
                /u2/oradata/PRDDBOR/undo/undo_tablespace_15.dbf 
2048.00   1774.94   86.67
                /u2/oradata/PRDDBOR/undo/undo_tablespace_16.dbf 
3000.00   2719.94   90.66
***************                                                 ------
-- ---------
sum                                                            
33720.00  29429.88

                                                                ------
-- ---------
sum                                                            
33720.00  29429.88

==> agora inicio uma transação :

[EMAIL PROTECTED]:SQL>update t1 set owner='ABC';

11618 linhas atualizadas.

==> vamos consultar de novo, primeiro com o script correto :

[EMAIL PROTECTED]:SQL>@used_rollback_blocks

SEGMENT_NAME    USERNAME          SID SERIAL#         
USED_UBLK          USED_UREC       START_UBAFIL      
START_UBABLK       START_UBAREC STATUS          
TABLESPACE_NAME                        SEGMENT_ID           
FILE_ID           BLOCK_ID
--------------- ---------------- ---- ------- ------------------ -----
------------- ------------------ ------------------ ------------------
---------------- ------------------------------ ------------------ --
---------------- ------------------
_SYSSMU1$       SCOTT             101    2204               
154              11618                214             
31275                 59 ONLINE          
UNDO_TABLESPACE                                 1               
208                  9

==> agora com o script que só consulta free space :

[EMAIL PROTECTED]:SQL>@tablespaces_free_%_v2
Tablespace(s) a Incluir, já contém %%, [ENTER] = todas:UNDO_TABLESPACE

                                                                     
                                 Total      Free    Free
Tablespace      data File                                         
Space    Space       %
--------------- ----------------------------------------------- ------
-- -------- -------
UNDO_TABLESPACE /u2/oradata/PRDDBOR/undo/undo_tablespace_01.dbf 
2048.00  1768.94   86.37
                /u2/oradata/PRDDBOR/undo/undo_tablespace_02.dbf 
2048.00  1760.94   85.98
                /u2/oradata/PRDDBOR/undo/undo_tablespace_03.dbf 
2048.00  1789.94   87.40
                /u2/oradata/PRDDBOR/undo/undo_tablespace_04.dbf 
2048.00  1781.94   87.01
                /u2/oradata/PRDDBOR/undo/undo_tablespace_05.dbf 
2048.00  1787.25   87.27
                /u2/oradata/PRDDBOR/undo/undo_tablespace_06.dbf 
2048.00  1780.81   86.95
                /u2/oradata/PRDDBOR/undo/undo_tablespace_07.dbf 
2048.00  1797.56   87.77
                /u2/oradata/PRDDBOR/undo/undo_tablespace_08.dbf 
2048.00  1789.56   87.38
                /u2/oradata/PRDDBOR/undo/undo_tablespace_09.dbf 
2048.00  1788.94   87.35
                /u2/oradata/PRDDBOR/undo/undo_tablespace_10.dbf 
2048.00  1788.75   87.34
                /u2/oradata/PRDDBOR/undo/undo_tablespace_11.dbf 
2048.00  1797.75   87.78
                /u2/oradata/PRDDBOR/undo/undo_tablespace_12.dbf 
2048.00  1783.94   87.11
                /u2/oradata/PRDDBOR/undo/undo_tablespace_13.dbf 
2048.00  1793.81   87.59
                /u2/oradata/PRDDBOR/undo/undo_tablespace_14.dbf 
2048.00  1724.88   84.22
                /u2/oradata/PRDDBOR/undo/undo_tablespace_15.dbf 
2048.00  1774.94   86.67
                /u2/oradata/PRDDBOR/undo/undo_tablespace_16.dbf 
3000.00  2719.94   90.66
***************                                                 ------
--  --------
sum                                                            
33720.00  29429.88

                                                                ------
--- --------
sum                                                            
33720.00  29429.88


==> Ou seja, mesmo com transação aberta e consumindo, a área de free
space NÂO DIMINUIU, confere ??? E é natural isso, undo é feito
primariamente em memória...
Então provavelmente :

a) NÃO está acontecendo fragmentação, que é impossível em LMT
b) vc não está registrando o uso por estar com a ferramenta errada

Seguem os scripts :

[EMAIL PROTECTED]:SQL>get used_rollback_blocks
  1  -- script de chacagem de blocos de undo
  2  column   sid format   999
  3  column   segment_name format   a15
  4  select b.segment_name, a.username, a.sid, a.serial#,
c.used_ublk, c.used_urec,c.START_UBAFIL, c.START_UBABLK,
c.START_UBAREC , b.status,
  5  b.TABLESPACE_NAME, b.SEGMENT_ID, b.FILE_ID, b.BLOCK_ID
  6   from v$session a, dba_rollback_segs b, v$transaction c
  7  where b.segment_id = c.xidusn
  8    and a.taddr = c.addr
  9  /

[EMAIL PROTECTED]:SQL>get tablespaces_free_%_v2
  1  -- script de checagem de blocos/bytes livres
  2  accept v_tablespaces CHAR prompt 'Tablespace(s) a Incluir, já
contém %%, [ENTER] = todas:'
  3  clear breaks
  4  set pages 9999
  5  column a1 heading 'Tablespace'  format a30
  6  column a2 heading 'data File'   format a66
  7  column a3 heading 'Total|Space' format 999999.99
  8  column a4 heading 'Free|Space'  format 99999.99
  9  column a5 heading 'Free|%'      format 999.99
10  break on a1 SKIP 1 on report
11  compute sum of a3 on a1
12  compute sum of a4 on a1
13  compute sum of a3 on report
14  compute sum of a4 on report
15  select a.tablespace_name a1, a.file_name a2, a.avail a3,
16             nvl(b.free,0) a4, nvl(round(((free/avail)*100),2),0)
a5
17    from (select /*+ RULE */ tablespace_name, substr
(file_name,1,66) file_name,
18               file_id, round(sum(bytes/(1024*1024)),3) avail
19            from sys.dba_data_files
20           group by tablespace_name, substr(file_name,1,66),
file_id
21         ) a,
22         (select tablespace_name, file_id, round(sum(bytes/
(1024*1024)),3) free
23            from sys.dba_free_space
24           group by tablespace_name, file_id
25         ) b
26    where a.file_id = b.file_id (+)
27      and a.tablespace_name like upper('%&v_tablespaces%')
28    order by 1, substr(a.file_name, instr(a.file_name, '/', -1))
29  /
30  clear breaks

A resposta para a sua pergunta então "qual o "tratamento"
necessário", seria então NENHUM.

[]s


Chiappa
--- Em oracle_br@yahoogrupos.com.br, Gilson Fábio Robles Bernichi
<[EMAIL PROTECTED]> escreveu
>
>
>
>
>  Boa Tarde a todos
>
>  Uma duvida, tenho um banco com undo tablespace. E com o passar do
tempo
> essa  tablespace torna-se muito fragmentada. Causando assim um
problema no
> desempenho.
>
> Pois tenho uma UNDO TABLESPACE com os seguintes valor
> Total Blocks : 38400
> Empty Blocks : 35779
>
>  Qual o tratamento feito com as undo tablespace nesse caso.
>
>  Obrigado
>  Gilson
>







--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__________________________________________________________________
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.



Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE


Links do Yahoo! Grupos

Responder a