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...
[oracle_br] Re: Delete em Tabela Muito Grande
jlchia...@yahoo.com.br [oracle_br] Tue, 28 Apr 2015 07:29:14 -0700
- [oracle_br] Delete e... alexssandro0...@yahoo.com.br [oracle_br]
- Re: [oracle_br]... Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
- Re: [oracle_br]... rodrigo stefanski rodrigo...@yahoo.com.br [oracle_br]
- Re: [oracle_br]... Andre Santos andre.psantos...@gmail.com [oracle_br]
- [oracle_br] Re:... jlchia...@yahoo.com.br [oracle_br]
- [oracle_br]... jlchia...@yahoo.com.br [oracle_br]
- [oracle_br]... alexssandro0...@yahoo.com.br [oracle_br]
- [oracle... jlchia...@yahoo.com.br [oracle_br]
- [or... alexssandro0...@yahoo.com.br [oracle_br]
- Re: [oracle_br]... angelo angelolis...@gmail.com [oracle_br]