Opa, começou a clarear.
Vejamos, se a tabela sofre muito INSERT/UPDATE/DELETE, uma hora vai mesmo ficar
fragmentada.
Um script que uso para identificar isso, mostra o candidato a REORG escolhido
pela maior quantidade de espaço desperdiçado (WASTED):
set lines 200;
column owner format a15;
column segment_name format a30;
select
a.owner,
a.segment_name,
a.segment_type,
round(a.bytes/1024/1024,0) MBS,
round((a.bytes-(b.num_rows*b.avg_row_len) )/1024/1024,0) WASTED
from dba_segments a, dba_tables b
where a.owner=b.owner
and a.owner='&w_OWNER'
and a.segment_name = b.table_name
group by a.owner, a.segment_name, a.segment_type, round(a.bytes/1024/1024,0)
,round((a.bytes-(b.num_rows*b.avg_row_len) )/1024/1024,0)
having round(bytes/1024/1024,0) >100
order by round(bytes/1024/1024,0) desc ;
Os atributos blob, vc pode melhorar a organização, quando vc cria uma
tablespace esclusiva para eles e faz um MOVE prá lá:
select 'alter table '||owner||'.'||table_name ||' move lob ('
||column_name||')' || ' store as (tablespace SOMENTE_BLOBS);' retorno
from dba_lobs
where segment_name in (select segment_name
from dba_segments
where tablespace_name='MY_DATA' and owner='MY_OWNER' and
segment_type='LOBSEGMENT');
(SOMENTE_BLOBS, MY_DATA e MY_OWNER: substitua conforme seu uso).
Após mover os LOBS, a tabela não foi mexida, pois o segmento de lob já é
separado dos dados da tabela (esta parte já estava clara, confere?). Observe
que depois de organizar a tabela, pode haver necessidade de REORG da tablespace
(mas não vamos misturar os tópicos).
Agora sim, para organizar a tabela, vai bastar:
alter table TABELA_CANDIDATA enable row movement;
(
alter table TABELA_CANDIDATA shrink space cascade;
ou
alter table TABELA_CANDIDATA move;
ou
alter table TABELA_CANDIDATA move NOVA_TABLESPACE; <<--- aqui vc pode fazer um
VAI-E-VOLTA
--alter table TABELA_CANDIDATA move TABLESPACE_ORIGINAL; <---fica muito bom.
)
Depois disto, os indices vão ficar inválidos, verifique:
--Indice
select 'ALTER INDEX ' || INDEX_NAME || ' REBUILD;' Sentenca
from user_indexes
where STATUS <> 'VALID';
Na parte de mudar o tipo de uma coluna, eu prefiro criar uma nova coluna no
tipo e tamanho certo e rodar um update para tratar o dado original, copiando o
valor para a nova coluna, pois vc poderá conferir se os valores ficaram como vc
esperava (lembrar do backup antes tb é fundamental).
Em seguida verificar dependencias (indices e constraints naquela coluna devem
estar em um DDL pronto para ser executado após o procedimento): rodar o drop na
coluna antiga com cascade constraints, renomear a nova coluna para o nome
original e recriar as constraints/indices, recompilando também os objetos
invalidados pelo processo (pack, procs, funcs e triggers ...).
Como vc vê, isto exige que a tabela tenha lock exclusivo prá vc: procedimento
prá ser feito à noite ou fora dos horários de uso daquele objeto.
À disposição,
Ederson Elias
DBA Oracle - http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
------------ Labor improbus omnia vincit
---Em [email protected], <reginaldo@...> escreveu:
Olá Ederson, boa tarde.
Então, as necessidades são as mais diversas: Reog mesmo (tabelas que sofrem
muito inserts e deletes (para esses casos o ganho de performance é imenso),
mudança em tipo de campo por necessidade de negócio, ligar o "enable in storage
in row" nos xBLOB - essa necessidade para liberar espaço em disco, dentre
outras).
Testei a função "CAN_REDEF" e não havia problemas.
Uso no Oracle 11g Standard sem problemas, mas no Oracle 10g tem ocorrido essa
situação do lock. Li os manuais e em todos tinha "The table is locked in the
exclusive mode only during a very small window that is independent of the size
of the table and complexity of the redefinition, and that is completely
transparent to users". Não encontrei nada sobre lock na versão 10g.
E
Atenciosamente,
Reginaldo de Faveri da Silva
Administrador de Banco de Dados
Unidade Justiça
Softplan/Poligraph
+55 48 3027-8000
www.softplan.com.br http://www.softplan.com.br
twitter.com/softplanonline http://twitter.com/softplanonline
Em 18 de setembro de 2014 13:21, ederson2001br@... mailto:ederson2001br@...
[oracle_br] <oracle_br@... mailto:oracle_br@...> escreveu:
Reginaldo,
A versão STANDARD não tem a capacidade de fazer alguns procedimentos online. Se
houver mudaça de ROWID, vai acontecer bloqueio exclusivo na linha pela
transação que pediu primeiro, as demais transações vão sim esperar. Esta
condição não acontece com a versão ENTERPRISE.
Vc verificou também o resultado da DBMS_REDEFINITION.CAN_REDEF_TABLE ?
Dá uma lida no artigo http://www.dba-oracle.com/t_dbms_redefinition_example.htm
http://www.dba-oracle.com/t_dbms_redefinition_example.htm e
http://docs.oracle.com/cd/B28359_01/server.111/b28310/tables007.htm#ADMIN11677
http://docs.oracle.com/cd/B28359_01/server.111/b28310/tables007.htm#ADMIN11677
que tem uns exemplos, veja se encaixa no seu cenário.
Opcionalmente, considere escolher o tipo de reorg, pois os procedimentos
diferem bem como os impactos:
-Reorganizar PCT_FREE
-Shrink de tabela
-Mover para segmento inicial, quando a tabela foi bastante "esvaziada"
-Mover para outra tablespace
-Refazer indices
Conside também:
alter table xxx deallocate unused space;
alter table xxx SHRINK SPACE COMPACT;
alter table xxx move;
Explica melhor a sua necessidade, porque vc quer fazer reorg? A tabela ter
muitos dados não é problema para o banco. Já consultá-la, pode haver demora se
as suas consultas não estão otimizadas para o modelo, talvez criar/usar indices
mais específicos vá modificar o seu cenário.
Ederson Elias
DBA Oracle - http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
------------ Labor improbus omnia vincit
