DBMS_REDEFINITION – Alterando tabelas grandes sem causa indisponibilidade de dados

Como hoje a indisponibilidade de dados pode custar milhões para algumas corporações, junto com o Oracle 9i a Oracle introduziu um pacote que permite a reorganização “online” de tabelas. Essa feature é muito, muito boa mesmo.
Vou demonstrar com um exemplo simples, uma tarefa que me foi pedida, alterar a estrutura de uma tabela OLTP que possui 23GB e 143 milhões de linhas. Para realizar essa tarefa sem impacto no usuário final eu teria que realizar fora do horário comercial em uma janela de manutenção. Tendo a ferramenta correta, dá para realizar sem problemas durante o expediente e sem danos ao usuário.

Mãos na massa:

1) Verifique se a sua tabela tem os pré-requisitos para o REDEF:

exec dbms_redefinition.can_redef_table(‘SEU_SCHEMA’, ‘TB_ORIGEM’);

2) Crie uma tabela (SEM LINHAS 1=2) que será o destino da operação, já na tbs correta com a estrutura desejada. No meu caso tinha que mudar a ordem das colunas:

create table seu_schema.tb_destino
tablespace mytbs_01
as
select col1, col2, col3, coln
from seu_schema.tb_origem
where 1=2;

3) Adcione a chave primária da tabela destino

alter table seu_schema.tb_destino
add constraint pk_destino primary key (col1)
using index tablespace mytbs_01;

4) Adicione todos os índices primordiais a aplicação, e salve o script com aqueles que são utilizados esporadicamente, para acelerar o processo de REDEF

create index seu_schema.idx1
on seu_schema.tb_destino (col3)
tablespace mytbs_01;

create index seu_schema.idx2
on seu_schema.tb_destino (coln)
tablespace mytbs_01;

5) Inicie a redefinição da tabela

exec dbms_redefinition.start_redef_table
(‘SEU_SCHEMA’, –schema
‘TB_ORIGEM’, –tabela com os dados de origem
‘TB_DESTINO’);–tabela com os dados de destino

Obs.: Se tiver algum update ou no nome de colunas ou em valores essa é a hora

6) Sincronização dos dados das duas tabelas (Na veradade carga da destino):

exec dbms_redefinition.sync_interim_table
(‘SEU_SCHEMA’, –schema
‘TB_ORIGEM’, –tabela com os dados de origem
‘TB_DESTINO’);–tabela com os dados de destino

7) Nesse passo o Oracle faz o rename para acertar a casa

exec dbms_redefinition.finish_redef_table
(‘SEU_SCHEMA’, –schema
‘TB_ORIGEM’, –tabela com os dados de origem
‘TB_DESTINO’);–tabela com os dados de destino

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Obs.: !!!!!!!!!! Muito importante !!!!!!!!!
Quando acabar o processo, devemos dropar a tabela com o nome de TB_DESTINO, pois o Oracle já fez o trabalho todo para nós, e os dados estarão no final das contas na tabela “TB_ORIGEM”, então se dropar ela, aí sim vc pode ir direto passar no Rh da empresa. Rsrsrsrsrs
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Resumindo:

Enquanto o processo está rolando, O Oracle cria snapshotlogs e Mview assim a tabela TB_ORIGEM fica disponível durante todo o processo, que totalmente transparente para o usuário final.
Essa técnica é bastante usada por DBA’s experientes para particionar tabelas e claro que com os releases mais novos a Oracle vêm aperfeiçoando cada vez mais.

Para maiores informações consulte a documentação oficial “sempre” http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tables.htm#i1006754

Forte abraços a todos,

Dúvidas e Sugestões mufalani@gmail.com

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios são marcados com *