Obs complementares : => quando vc diz que a remoção dos dados é necessária "pois estes dados estão ocupando muito espaço em disco e o mais importante que é problema de performance", vamos esclarecer um ponto : no RDBMS Oracle, *** DIFICILMENTE *** há impacto para o database como um todo quando há segmentos gigantescos (pois NUNCA o RDBMS precisa varrer as tablespaces ou os discos, e além disso os metadados para segmentos são Indexados, muito bem divididos, separados e independentes - se vc duvida, pegue um banco Oracle qualquer, faça uns SQLs numa tabela qualquer medindo a performance, depois crie uma tabela gigante e re-execute os mesmos SQLs nas outras tabelas, vc vai ver performance MUITO MUITO MUITO similar)... Vc pode encontrar impacto para a performance para SQLs que se referem a esse segmento gigante, pois (óbvio) aí sim haverá mais dados a serem lidos - tal impacto pode se ENORMEMENTE reduzido via indexação cuidadosa e particionamento "de pobre", manual, mas é Claro que algum haverá...
=> evidentemente a opção de gerar arquivos-texto no servidor para se ter um backup adicional antes da deleção dos dados caso não possa contar com um backup RMAN full recente é a melhor considerando apenas o servidor isoladamente : nem preciso dizer que se vc tiver um outro servidor Oracle com espaço suficiente E haja link de rede performático entre os dois, vc Tranquilamente poderia mandar um INSERT /*+ APPEND */ lendo esses dados a partir do outro server via dblink => IMPORTANTE : nós não conhecemos o seu ambiente, então RIGOROSAMENTE NÂO SABEMOS se o teu Storage tem a capacidade de clonar ultra-rapidamente o disk volume onde estão os datafiles (ou mesmo os datafiles em si) da tablespace aonde reside a tal tabela gigante : caso tenha, Claro que a opção de clonar os discos/datafiles, os disponibilizar numa outra instância, fazer um transport dos metadados para a nova instância (para poder abrir a tablespace lá) pode SIM ser considerada... []s Chiappa
