ORA-01466: unable to read data – table definition has changed

Estou tendo problemas com o export do meu banco, onde a aplicação que esta sendo executada no mesmo momento que o meu export executa comandos de truncate table em tabelas do sistema.

E neste momento no meu log  gera uma porcaria de erro ora, [ORA-01466: unable to read data - table definition has changed]

Eu me pergunto: O que fazer nesta situação?

1. Verificar se há a necessidade do desenvolvedor efetuar esse truncate;

2. Verificar se o truncate esta agendado, caso sim trocar o horario do export;

Pois lendo a literatura sobre o comando truncate diz que é um comando DDL, onde move a marca d'água da tabela para zero. Não gerando redo ou undo, consequentemente não tem como burlar um truncate no momento de um export.

Leia mais sobre o truncate: Psoug


Export .dmp gigante?

Bom uma prática do tempo do Unix 32bits na hora de fazer export ou import utilizar um recurso para des/compactar ou partir os arquivos na hora que eles estao sendo criados. É +/- isso ai mesmo.
No momento que tais fazendo um exp system/senha full=y file=/backup/expfull.dmp este arquivo pode mtas vezes ter centenas de gigas, mas compactados podem ficar com pequenos megas.
Bom muito DBA nos seus scripts de backup no Linux ou Unix fazem esse export e dps passam um gzip expfull.dmp para compactar ai mora outro problema, o gzip compacta mas se o arquivo dmp ficou com 20Gb e o .gz for ficar 4Gb no total vai ter que ter pelo menos de espaco livre uns 24,5Gb para essa maratona toda ai.....
Mas como eu estava dizendo há uma forma mais simplificada nisso tudo ai, como o unix ou linux todos os arquivos sao concatenados, é o termo nao é bem esse mas é algo assim, entao no momento q estou criando um arquivo posso estar pegando a informacao de dentro dele e jogando para outro lugar.
bom para nao enrolar mto vou fazer um exemplo que ficará mais fácil de enteder.

1. Tens que criar um arquivo temporario, é .... aquele que eu disse que vai ser alimentado mas vai ser jogado o seu conteudo para outro
[oracle@localhost oracle] mknod /tmp/exp_pipe p # criando um arquivo para o export
[oracle@localhost oracle] gzip < /tmp/exp_pipe > /backup/expfull.dmp.gz & # gzip recebendo a informacao do exp_pipe e a saida do gzip está sendo para /backup/expfull.dmp.gz já compactado e o & quer dizer em segundo plano
[oracle@localhost oracle] exp system/senha full=y file=/tmp/exp_pipe log=/backup/expfull.log # aqui o export vai jogar as informacoes para o exp_pipe onde o gzip que está em segundo plano esperando estas para compactar.

Não há necessidade de matar o gzip pois ele fica em segundo plano, no momento que termina o export o gzip finaliza o export e ai está o seu export de 20Gb já saiu compactado em 4Gb.
Ok pode perder um pouco de performace pois será dois processos de arquivos no servidor mas nao será tao problemático em questão de espaco.

E em relação a importar esse gzip, nao há necessidade de descompactar e dai fazer o import, vou colocar somente o código e dai com a explicação anterior já irão induzir o que ele está fazendo.

[oracle@localhost oracle] mknod /tmp/imp_pipe p
[oracle@localhost oracle] gzip -d < /backup/expfull.dmp.gz > /tmp/exp_pipe &
[oracle@localhost oracle] imp system/senha full=y file=/tmp/exp_pipe log=/backup/impfull.log fromuser=deUsuario touser=paraUsuario

Obs.: O ideal depois de compactar usando esse recurso se certificar que o arquivo está ok, como foi usado o gzip posso recomendar o seguinte comando:
gunzip -t /backup/expfull.dmp.gz ; RC=$?
if test ${RC} -ne 0
then
# aqui vc fazer um comando mail para enviar um email para o DBA dizendo que o backup falhou
fi

Referencias: OraFAQ,

Oracle export 2 gig file