Bom dia, tudo blz ? Então, a única informação ** crucial ** é justamente a que 
vc não dá : exatamente O QUANTo de espaço esse "um ano" que vc quer manter 
representa em relação ao total de 824 GB, e há alguma maneira - índice, 
provavelmente - de se localizar rapidamente apenas esses registros ?????? Isso 
é crítico pois a maneira Racional de se fazer uma larga deleção é NÂO SE 
DELETAR, e ao invés disso salvar os relativamente poucos registros que se quer 
manter numa outra tabela (via INSERT /*+ APPEND */ ) e queimar a tabela grande 
com um TRUNCATE, okdoc ??? Vc vai afaik sofrer aí bastante porque está usando a 
capadinha da versão Standard (caso em que afaik vc NÃO tem paralelismo e NÃO 
tem particionamento, ambas features que provavelmente seriam inestimáveis para 
melhor performance), mas é o que é...
 
 Evidentemente também eu **** IMAGINO **** que mesmo sendo dados de Auditoria, 
eles são dados , são de Produção e são Importantes, então vc *** JÁ OS TEM *** 
na sua rotina de backup de banco, Totalmente Possível de se restaurar para 
quando forem necessários no futuro, certo ? Vc já tendo um backup 100% testado 
e confiável, aí Então não vejo sentido em se perder tempo em se fazer um export 
adicional além disso, okdoc ??? 
 
 CASO, por segurança, seja MESMO requerido se ter uma cópia extra dessa tabela 
de auditoria grande (ou pior ainda, hoje essa tabela grande não está coberta 
por backup - horror, horror!), Óbvio que não é com export que vc fará : para um 
volume desses a opção viável penso que é vc gerar um arquivo-texto em bulk 
(provavelmente com pro*c, 
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:459020243348 
tem um exemplo) , E além disso fazer parelelismo "de pobre", manual (ie, vc vai 
disparar múltiplas instâncias do seu programa ao mesmo tempo, cada uma fazendo 
leitura e gravação de uma parte diferente dos dados da tabela, separando por 
rowids - 
https://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:10498431232211
 tem um exemplo) ... Vc até pode testar as outras opções não-programáticas, 
como transport/backup de tablespace via RMAN, criação de external table TYPE 
ORACLE_DATAPUMP, etc, mas Muito Provavelmente a opção programada com array 
processing/bulk vai sim SOBREPUJAR TOTALMENTE o export, EM ESPECIAL porque vc 
não pode usar Parallel SQL no export por estar com Standrad Edition... Vc pode 
também experimentar os muitos utilitários de terceiros capazes de gerar dumps 
em texto - é duvidoso se eles vão ser mais eficientes do que um programa que 
use array + bulk + paralelismo DIY (na falta da coisa real) mas tenta lá...
 
 []s
 
   Chiappa
   
 OBS : para complemento, é ** CONCEITUAL ** que vc não vai ganhar COISA NENHUMA 
em termos de performance para DELETE botando a tabela em NOLOGGING - veja na 
Documentação que o NOLOGGING só funciona para INSERT em APPEND-mode, ele é 
TOTALMENTE IGNORADO para outros DMLs...

Responder a