Re: [oracle_br] Re: Redução de tablespace - Oracle 8.1.7

2007-05-03 Por tôpico Cap Mota

Chiappa, mais uma vez muito obrigado, tanto pelo comando pela 
orientação. Funcionou beleza.

[]'s

Marcel

jlchiappa escreveu:
>
> Marcel, não tem aonde "trancar", LOBs são um conceito comum no banco
> Oracle, mas se vc ainda tem dúvidas nele eu recomendaria fortemente
> um bom estudo do manual "Oracle8i Application Developer's Guide -
> Large Objects (LOBs)" e do Concepts, absolutamente tudo o que vc
> precisa saber sobre LOBs está lá...
> No caso em questão : primeiro vc precisa saber o que é esse segmento
> SYS_LOBnnn que vc tem, consulte a DBA_SEGMENTS :
>
> [EMAIL PROTECTED]:SQL>select * from dba_segments where
> segment_name='SYS_LOB017499C2$$';
>
> OWNER SEGMENT_NAME
> PARTITION_NAME SEGMENT_TYPE
> TABLESPACE_NAME HEADER_FILE
> HEADER_BLOCK BYTES BLOCKS
> EXTENTS INITIAL_EXTENT NEXT_EXTENT
> MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
> FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
>  --- -
> - -- -- --
>  -- -- --
> -- -- -- 
> -- -- -- -- --
>  -- ---
> SCOTT SYS_LOB017499C2
> $$ LOBSEGMENT
> USERS 7
> 34689 163840 20
> 1 163840 163840 1
> 2147483645 0 1
> 1 7 DEFAULT
>
> ==> já que é um lob segment, vc consulta a DBA_LOBS pra saber quem é
> o dono, em qual tabela ele reside e qual é a coluna que é LOB :
>
> [EMAIL PROTECTED]:SQL>select * from dba_lobs where
> segment_name='SYS_LOB017499C2$$';
>
> OWNER TABLE_NAME
> COLUMN_NAME SEGMENT_NAME
> INDEX_NAME CHUNK
> PCTVERSION RETENTION FREEPOOLS CACHE LOGGING
> IN_
>  -- --
>  --- -
> - -- -- -- ---
> --- -- --- ---
> SCOTT TB_LOB
> C2 SYS_LOB017499C2$$
> SYS_IL017499C2$$ 8192
> 10 10800 NO YES YES
>
> ==> ok, no meu caso era a coluna C2 da tabela TB_LOB, como vc viu na
> DBA_SEGMENTS hoje esse segmento está na tablespace USERS, vou mover :
>
> [EMAIL PROTECTED]:SQL>alter table scott.TB_LOB move lob (C2) store as
> (tablespace TS_LMT_UNIF);
>
> Tabela alterada.
>
> ==> a coluna continua existindo, normal...
>
> [EMAIL PROTECTED]:SQL>select * from dba_lobs where
> segment_name='SYS_LOB017499C2$$';
>
> OWNER TABLE_NAME
> COLUMN_NAME SEGMENT_NAME
> INDEX_NAME CHUNK
> PCTVERSION RETENTION FREEPOOLS CACHE LOGGING
> IN_
>  -- --
>  --- -
> - -- -- -- ---
> --- -- --- ---
> SCOTT TB_LOB
> C2 SYS_LOB017499C2$$
> SYS_IL017499C2$$ 8192
> 10 10800 NO YES YES
>
> ==> mas o segmento foi pra outra tablespace :
>
> [EMAIL PROTECTED]:SQL>select * from dba_segments where
> segment_name='SYS_LOB017499C2$$';
>
> OWNER SEGMENT_NAME
> PARTITION_NAME SEGMENT_TYPE
> TABLESPACE_NAME HEADER_FILE
> HEADER_BLOCK BYTES BLOCKS
> EXTENTS INITIAL_EXTENT NEXT_EXTENT
> MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
> FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
>  --- -
> - -- -- --
>  -- -- --
> -- -- -- 
> -- -- -- -- --
>  -- ---
> SCOTT SYS_LOB017499C2
> $$ LOBSEGMENT
> TS_LMT_UNIF 26
> 265 1048576 128
> 1 163840 1048576 1
> 2147483645 0 1
> 1 26 DEFAULT
>
> []s
>
> Chiappa
>


-- 
.
Marcel Francisco MOTA - Cap QCO
Gabinete do Comandante do Exército
Seção de Telemática
Fone: 3415.56.36 RITEX: 860.5636




[oracle_br] Re: Redução de tablespace - Oracle 8.1.7

2007-05-03 Por tôpico jlchiappa
Marcel, não tem aonde "trancar", LOBs são um conceito comum no banco 
Oracle, mas se vc ainda tem dúvidas nele eu recomendaria fortemente 
um bom estudo do manual "Oracle8i Application Developer's Guide - 
Large Objects (LOBs)" e do Concepts, absolutamente tudo o que vc 
precisa saber sobre LOBs está lá...
 No caso em questão : primeiro vc precisa saber o que é esse segmento 
SYS_LOBnnn que vc tem, consulte a DBA_SEGMENTS :

[EMAIL PROTECTED]:SQL>select * from dba_segments where 
segment_name='SYS_LOB017499C2$$';

OWNERSEGMENT_NAME
PARTITION_NAME SEGMENT_TYPE   
TABLESPACE_NAME   HEADER_FILE   
HEADER_BLOCK  BYTES BLOCKS
EXTENTS INITIAL_EXTENTNEXT_EXTENT
MIN_EXTENTSMAX_EXTENTS   PCT_INCREASE  
FREELISTSFREELIST_GROUPS   RELATIVE_FNO BUFFER_
 --- -
- -- -- --
 -- -- --
 -- -- -- 
-- -- -- -- --
 -- ---
SCOTTSYS_LOB017499C2
$$  LOBSEGMENT 
USERS   7  
34689 163840 20  
1 163840 163840  1 
2147483645  0  1  
1  7 DEFAULT

==> já que é um lob segment, vc consulta a DBA_LOBS pra saber quem é 
o dono, em qual tabela ele reside e qual é a coluna que é LOB :

[EMAIL PROTECTED]:SQL>select * from dba_lobs where 
segment_name='SYS_LOB017499C2$$';

OWNERTABLE_NAME 
COLUMN_NAMESEGMENT_NAME
INDEX_NAME  CHUNK 
PCTVERSION  RETENTION  FREEPOOLS CACHE  LOGGING 
IN_
 -- --
 --- -
- -- -- -- ---
--- -- --- ---
SCOTTTB_LOB 
C2 SYS_LOB017499C2$$   
SYS_IL017499C2$$ 8192 
10  10800NO YES YES

==> ok, no meu caso era a coluna C2 da tabela TB_LOB, como vc viu na 
DBA_SEGMENTS hoje esse segmento está na tablespace USERS, vou mover :

[EMAIL PROTECTED]:SQL>alter table scott.TB_LOB move lob (C2) store as 
(tablespace TS_LMT_UNIF);

Tabela alterada.

==> a coluna continua existindo, normal...

[EMAIL PROTECTED]:SQL>select * from dba_lobs where 
segment_name='SYS_LOB017499C2$$';

OWNERTABLE_NAME 
COLUMN_NAMESEGMENT_NAME
INDEX_NAME  CHUNK 
PCTVERSION  RETENTION  FREEPOOLS CACHE  LOGGING 
IN_
 -- --
 --- -
- -- -- -- ---
--- -- --- ---
SCOTTTB_LOB 
C2 SYS_LOB017499C2$$   
SYS_IL017499C2$$ 8192 
10  10800NO YES YES

==> mas o segmento foi pra outra tablespace :

[EMAIL PROTECTED]:SQL>select * from dba_segments where 
segment_name='SYS_LOB017499C2$$';

OWNERSEGMENT_NAME
PARTITION_NAME SEGMENT_TYPE   
TABLESPACE_NAME   HEADER_FILE   
HEADER_BLOCK  BYTES BLOCKS
EXTENTS INITIAL_EXTENTNEXT_EXTENT
MIN_EXTENTSMAX_EXTENTS   PCT_INCREASE  
FREELISTSFREELIST_GROUPS   RELATIVE_FNO BUFFER_
 --- -
- -- -- --
 -- -- --
 -- -- -- 
-- -- -- -- --
 -- ---
SCOTTSYS_LOB017499C2
$$  LOBSEGMENT 
TS_LMT_UNIF26
2651048576128  
1 

[oracle_br] Re: Redução de tablespace - Oracle 8.1.7

2007-05-02 Por tôpico jlchiappa
Marcel, *** de forma alguma *** a situação que vc descreve implica 
única e necessariamente em fragmentação, ok ? Ao afirmar direta e 
unicamente que sim, vc tranquilamente pode estar redondamente 
enganado veja vc, FRAGMENTAÇÃO propriamente dita implica que o 
espaço livre é IMPOSSÍVEL de ser reusado porque está formatado 
em "pedaços" - os extents - de x bytes E o objeto que quer espaço a 
mais está pedindo por pedaços de y bytes, onde y é absolutamente 
diferente e não-múltiplo de x... No seu caso tranquilamente PODE SER 
SIM, é mesmo PROVÁVEL, que não seja isso que ocorre, e que na verdade 
seja algo causado por white-space OU append de extents, ambas coisas 
que não tem ** NADA ** vezes ** NADA ** a ver com fragmentação 
 Começando pelo white-space, isto decorre do seguinte : normalmente 
uma segment no bd Oracle (tabela/índice/o que for) é altamente 
dinâmico, ou seja, se agora ele sofreu DELETE em breve devem estar 
entrando registros a mais via INSERT. Então pra acelerar o INSERT o 
bd Oracle usa de um truque que é, quando a tabela sofre um DELETE o 
espaço *** não volta *** à lista de espaço disponível pra qualquer 
obj do banco, e sim esse espaço continua RESERVADO para o segmento em 
questão que sofreu o DELETE, aí os INSERTs vindouros NÃO TEM 
QUE "formatar" espaço novo em disco, tem um ganho legal aí. A contra-
partida é que enquanto os tais INSERTs não vierem, esse espaço 
continua reservado até que (nas versões mais recentes via deallocate 
unused esse espaço não-usado seja liberado), OU (em qquer versão) 
haja um re-criação/eliminação do segmento, via TRUNCATE ou 
MOVE/REBUILD. 
  Imagine que a sua tablespace estava assim (cada X abaixo representa 
um extent usado pela tabela T, digamos, e cada . um extent livre):
  
  XX..
  
  aí houve um DELETE na tabela T que eliminou dados dos 9 últimos 
extents, como acima dito esse espaço NÂO VOLTA ao pool geral de 
espaço livre, ele continua marcado como pertencente à tabela T, aí vc 
logicamente NÂO VAI PODER fazer resize desse datafile, os extents 
acima do ponto aonde vc quer ter a diminuição ESTÂO SIM marcados com 
em uso, certo ?? Tranquilamente PODE SER isso que vc tem aí... 
 Já quanto ao APPEND, isso decorre do fato de que um INSERT feito em 
append-mode ** necessariamente ** não reusa o espaço livre pré-
existente, com isso vc pode acabar tendo um datafile ocupado assim 
 
 X..X
 
os últimos X é (digamos) resultado de INSERT em append-mode, também 
nesse caso vc NÂO VAI conseguir fazer o RESIZE  Uma variação 
desta situação ocorre quando, na hora de inserir dados, só há espaço 
mais ao fim dos extents, se essa situação mudar (via MOVE ou TRUNCATE 
ou o que for do segmento que ocupava esse espaço), os demais 
segmentos mais abaixo NÂO SÂO automaticamente movidos, tipo : estou 
assim na alocação :

..

aí pedi pra criar novo objeto e inserir dados (reprsentado por Ys) :

..

aí o espaço de X é liberado, o datafile VAI FICAR assim :

..

vc NÂO VAI conseguir fazer o resize por causa desses extents mais ao 
fim do datafile, eles TEM QUE serem movidos...

==> A verdade será revelado primeiro em vc fazendo a consulta na 
DBA_EXTENTS e na DBA_FREE_SPACE, é a fonte quase que única e primária 
da situação REAL de alocação num datafile Oracle duma tablespace 
permanente qquer, tipo :

[EMAIL PROTECTED]:SQL>l
  1  select file_id, block_id, bytes, block_id+blocks proximo_extent, 
OWNER, SEGMENT_TYPE, SEGMENT_NAME, partition_name
  2*  from dba_extents where tablespace_name='USERS' order by 1,2
[EMAIL PROTECTED]:SQL>/

   FILE_ID   BLOCK_ID  BYTES 
PROXIMO_EXTENT OWNERSEGMENT_TYPE   
SEGMENT_NAMEPARTITION_NAME
-- -- -- -
-  -- 
--- --
 7  9 
163840 29 SYSTEM   TABLE  TESTTAB
 7 29 
163840 49 SYSTEM   TABLE  
SQLPLUS_PRODUCT_PROFILE
 7 49 
163840 69 SYSTEM   TABLE  
PLAN_TABLE
 7 69 
163840 89 SCOTTTABLE  DEPT
 
==> ok, até aqui a alocação foi sequencial, ok, mas logo abaixo :

 7509 
163840529 SCOTTTABLE  STOCKS
 
ou seja, nesse datafile número 7, no bloco 89 tenho um espaço que não 
está reservado pra nada, está livre :

[EMAIL PROTECTED]:SQL>select file_id, block_id, bytes, block_id+blocks 
proximo_extent
  from dba_free_space  where file_id=7 and block_id=89;

   FILE_ID   BLOC