› Fóruns › Banco de dados Oracle › Particionamento de elefante branco › Particionamento de elefante branco
Olá,
Vieri! Concordo contigo quando estamos falando em limitações de espaço em disco no servidor ou até mesmo a utilização do DBMS_REDEFINITION no banco de dados.
Para qualquer solução adotada, o DBA deverá analisar qual será a melhor técnica a ser aplicada.
O DBMS_REDEFINITION sim pode utilizar os mesmo default storages da sua tabela antiga, se etiver utilizando os valores padrões de gerenciamento LMT ou valores pré-determinados do seu gosto quando utilizado com DMT, terá os mesmos valores com o DBMS_REDEFINITION na nova estrutura, se trabalha com valores específicos à nível de tabela, o particionamento assumirá, porém, se tu verificar que não ficou bom o novo modelo, nada lhe impede de ALTER TABLE MODIFY PARTITION default storage ( … ); e BIMBA!!! Mudar somente o que precisa, seja na ALOCAÇÃO DE NOVOS EXTENS, PCTFREE, PCTUSED e etc..
O maior problema que vejo é sair da tabela HEAP e ir para uma particionada, pois, pelos padrões de armazenamento, deverá mudar em muito, pois não teremos mais uma LINGUIÇONA GIGANTE, e SIM, DIVERSOS FRAGMENTOS PEQUENOS DE PREFERÊNCIA. E isso mudar a forma de armazenamento, no particionamento. Esses parâmetros podem ser desde PCTUSED, PCTFREE, INITIAL e NEXT EXTENT, até mesmo uma outra configuração de BUFFER CACHE (RECYCLE ou KEEP) no segmento.
Enquanto a utilização do INSERT INTO … é uma técnica bem fácil mesmo, e deve sim utilizar com o hint /+ APPEND +/ para não ter que ficar vendo os blocos livres e realocando eles, o APPEND simplesmente pega blocos novos sem ter essa preocupação de realocação, por isso ele será sempre mais rápido…
Fora que para a Técnica de INSERT INTO ou EXP/IMP, dependerá sempre de SORT, PROCESSAMENTO, BUFFER CACHE e etc… fica mais a critério do cliente =D
O bom do export/import, tu pode realizar o EXPORT da tabela no formato antigo, e usar técnicas de performance como DIRECT, RECORDLENGTH, BUFFER, COMPRESS, que dependendo do hardware ode ser mais rápido e retira praticamente a fragmentação…
Mas varia muito Viere, depende da situação e quais recursos que tem em mãos. Eu geralmente uso DBMS_REDIFINITION, pq quando passo para o novo formato que preciso, toda a minha consistência lógica como PK e FK se transferem automaticamente e isso não faz invalidar meu modelo de dados.
Outras soluções são boas também, não existe técnica ruim, o bom que Bob Bryla quando estava fazendo o CORE lançou o ALTER TABLE que facilita a vida… heheheheheheh
Abraços,
Rodrigo Almeida