Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Boa tarde, sou novo aqui no fórum.
Estou desenvolvendo um projeto para criação de base de expurgo (Espelho), o sistema tem 6 anos de base de dados, preciso deixar 2 anos na tabela quente, e criar uma tabela espelho (exemplos a baixo) com a mesma estrutura e particionada por mês.
A principio este não é o problema, pois temos DBA na empresa que faz esta criação, porem, preciso criar uma rotina que capture os dados da tabela TBXX010 (Ocorrencia_cliente) para a nova particionada TBXX050 (Historico_Ocorrencia_cliente).
Obs: Na tabela TBXX050 criei um campo a mais "Data" para funcionar o particionamento por mês.
Para todo este processo seria um select na tabela TBXX010 com insert direto na TBXX050 passando o campo data para que o particionamento inclua no lugar correto? e depois excluir os dados da tabela TBXX010?
Se precisarem de mais informação para o auxilio, eu mando.
Obrigado.
Então motta esse é o problema, perguntei algumas coisas e falou que não conhecia e que era para eu testar no ambiente de testes rsrs...
Pesquisei algumas coisas e vi sobre a função EXCHANGE PARTITION que faz muito mais rápido que um insert.
Você ou alguém aqui já trabalhou com essa função, tem algum exemplo mais pratico e usando a regra de data?
------------------
EXCHANGE PARTITION
------------------
O comando EXCHANGE PARTITION é um método bem eficiente de realocar um segmento de tabela não particionada para uma tabela particionada. Poderemos perceber que o procedimento será muito mais rápido do que que realizar um INSERT na tabela. Vale a pena salientar que este recurso permite tanto mover o segmento de uma tabela não particionada para uma tabela particionada como o contrário. Para realizar esta demonstração irei criar uma tabela T2 com aproximadamente 10 milhões de registros. Primeiro irei recriar a partição PMILHARES_N com MAXVALUE para pode acomodar os registros que virão do segmento T2.
SQL> alter table t1 add partition PMILHARES_N
2 values less than (maxvalue)
3 tablespace tbs_milhares;Tabela alterada.
Agora irei criar a tabela T2 com aproximadamente 10 milhões de registros.
SQL> create table t2
2 tablespace tbs_milhares
3 as
4 select id from (select level id
5 from dual
6 connect by level <=10000000)
7 where id >= 7000;Tabela criada.
SQL> select count(*) from t2;
COUNT(*)Agora irei simular a inserção dos dados na tabela T1 provenientes da tabela T2 utilizando um INSERT SELECT.
SQL> set timing on
SQL> insert into t1 select * from t2;
9993001 linhas criadas.
Decorrido: 00:02:21.64
Podemos perceber que a operação executou em 2 minutos e 21 segundos. Agora irei limpar os dados da partição e utilizar o método EXCHANGE PARTITION de forma a transferir os dados da tabela T2 para a tabela T1:
SQL> set timing off
SQL> alter table t1 truncate partition PMILHARES_N;
Tabela truncada.
SQL> set timing on
SQL> alter table t1
2 exchange partition PMILHARES_N
3 with table t2;Tabela alterada.
Decorrido: 00:00:12.11
Podemos perceber acima que a operação foi executada em aproximadamente 12 segundos, ou seja, nem se compara com o método INSERT SELECT.
SQL> set timing off
SQL> select count(*) from t2;
COUNT(*)Me desculpe , mas montar um particionamento é uma tarefa complexa , copiar dados entre tabelas uma tarefa trivial.
Não faz sentido, deveria estar no escopo do trabalho do dba na minha modesta opinião.
...
Mas a solução básica é
"desligar" o audittrail
fazer um bloco insert select
"religar" o audit
O DBA faz isto com o pé nas costas.