Seguem as Respostas e Obs :
"Estou ciente do fato de que - principalmente devido à execução de declarações
SQL muito longas (> 3h) não dá tempo do banco sincronizar os dados da database
com os dos segmentos de UNDO, e isso causa o erro informado."
==> NÃO, colega, não é bem isso não : pra começo de conversa, não é "dados do
database que serão sincronizados", nada a ver : o mecanismo é, por EXIGÊNCIA
fundamental de um RDBMS, quando um SQL terminar ele TEM que enxergar os dados
os dados EXATAMENTE COMO ESTAVAM no instante em que ele começou, e para
alcançar isso o RDBMS Oracle, ao começar um DML qualquer (seja INSERT, UPDATE
ou DELETE), simplesmente "COPIA" os dados como estavam antes da alteração pra
uma área "temporária" especial, a chamada ÁREA DE UNDO : aí, quando um SQL
qualquer que começou antes desse DML que está alterando os dados precisar, ele
simplesmente vai no UNDO e LÊ esses dados , ok ?? NÃO HÁ SINCRONIZAÇÃO ALGUMA,
e realmente essa área de undo deve ser entendida como algo "temporário", a ser
simplesmente DESCARTADO (sem sincronizar coisa alguma, repito!!)
automaticamentee quando o RDBMS detectar que não há nenhum SQL em execução que
começou num momento no tempo ANTES do DML alterar os dados... Okdoc ?? Talvez
vc estivesse pendando no REDO LOG, esse sim contém alterações que TEM que ser
INTRODUZIDAS nos datafiles, então aí SIM poderíamos falar de SINCRONIZAÇÃO
entre dados do REDO LOG FILE e dados nos DATAFILES...
Muito bem, compreendido o mecanismo do UNDO/ROLLBACK, isso logo de cara nos
traz ao Primeiro Ponto : isso é um mecanismo OBRIGATÓRIO para consistência de
dados, para que o RDBMS ORACLE ** cumpra ** os ditames da tecnologia de RDBMS,
que entre outras coisas EXIGEM que um SQL SEMPRE TEM QUE ENXERGAR OS DADOS
EXATAMENTE COMO ESTAVAM ano momento em que ele começa... Inclusive, o RDBMS
ORACLE leva isso muito muito a sério, então nele vc pode até mesmo, enquanto
uma sessão A tá fazendo um SELECT de longa duração, vc APAGAR e COMITAR os
dados da MESMA TABELA SENDO LIDA em outra sessão B que a sessão A VAI VER OS
DADOS IGUAZINHOS COMO ESTAVAM... É um pouco diferente de outros SGBDs, onde
isso não acontece... E já que é algo tão fundamental, NÂO TEM COMO vc
'desligar' esse mecanismo, não....
O Segundo ponto é : o uso de UNDO sim, depende da duração do SQL mas TAMBÉM
DEPENDE que haja OUTRAS sessões fazendo DMLs : se teu SQL, como vc diz, dura 3
horas MAS não há outras sessões fazendo DML nas mesmas exatas tabelas,
ABSOLUTAMENTE NÃO SERÀ GERADO/USADO UNDO ALGUM... certo ???
==> Então ESSA é a sua primeira resposta Parcial : se vc quer Minimizar a
chance de UNDO esgotado, PROGRAME ESSES SQLs LONGOS para horários em que as
tabelas sendo acessadas não estejam sendo alteradas por outras sessões, OK ??
Veja, não é "sem nenhum usuário acessando", é sem nenhum usuário FAZENDO DML
NAS TABELAS A SEREM USADAS, blz ???
E outro ponto : vc não diz mas IMAGINO que vc está usando o expdp como se
fosse um "backup", "backupeando" todo o database ??? Se for isso, UMA das
vantagens de um backup REAL, feito com RMAN, é JUSTAMENTE A QUE ele trabalha
copiando BLOCOS DE DADOS DE DATAFILES EM DISCO, ele ABSOLUTAMENTE NÃO USA SQLs
para obter os dados , portanto é MENOS QUE ZERO a chance de um backup de
verdade, feito com RMAN, esgotar UNDO.... E é ** ÓBVIO **, esse "BACKUP" feito
com export tem ASPAS TOTAIS, é um PSEUDO-BACKUP, já que entre N outros
problemas, ele NÃO COPIA os dados do SYS/metadados, NÃO permite backup
incremental... É algo PRIMITIVO e Não SEGURO usar export (seja exp tradicional,
seja datapump) como um "BACKUP"....
==> Vou continuar respondendo à sua pergunta sobre EXPORT mas PLEASE considere
com carinho a Hipótese de usar um BACKUP DE VERDADE ao invés de export,
please...
"Para solucionar o erro, foi feito o ajuste da tablespace UNDO:
-- Tablespace UNDOTBS1 --
Ajustada de:
FILE_NAME MBytes
------------------------------------------ -------------
D:\APP\ORACLE\ORADATA\SENIOR\UNDOTBS01.DBF 1024
Para:
FILE_NAME MBytes
------------------------------------------ -------------
D:\APP\ORACLE\ORADATA\SENIOR\UNDOTBS01.DBF 1544
E da retenção de UNDO:
alter system set undo_retention = 7627;
alter tablespace undotbs1 retention guarantee;
"
==> veja, não tem como a gente saber daqui, mas VIA DE REGRA, falando nos dias
de hoje onde QUALQUER PEN-DRIVE tem dezenas de GBs, sorry mas 1,5 GB de UNDO é
** risível **, é MUITO MUITO PEQUENO, é muito POUCO para Qualquer ambiente de
Produção... Como eu disse não dá pra gente daqui de fora saber exatamente
QUANTO vc está usando, mas eu digo pra vc deixar PELO MENOS UMA DEZENAS DE GBs
na sua tablespace de UNDO, já de cara bote aí uns 10 ou 15 GB de UNDO , e
depois vai monitorando o consumo disso....
Afinal, de nada adianta vc pedir pra vc reter o UNDO por um LOOONGO tempo se o
espaço físico se esgotar, o que FACILMENTE PODE ACONTECER num ambiente Produção
muito ativo com relativamente tão pouco UNDO como vc mostra....
Afora se ter uma tablespace de UNDO de tamanho decente, que AGUENTE todos os
DMLs sendo feitos no período em que o export tá sendo feito, um outro
Procedimento que vc pode fazer para diminuir a chance de esgotamento de
rollback é DIMINUIR a chance de vc ter que necessitar de dados alterados lidos
via UNDO : por exemplo, quando vc pede um export consistente para um dado SCN,
** obviamente ** o SCN é a nível de database, então TODOS OS SELECTs sendo
feito para obter dados de TODAS AS TABELAS vão ter que enxergar TODOS os dados
tal como estavam nesse SCN, o que implicaria que vc teria que encontrar no UNDO
os dados alterados TODINHOS a partir desse SCN... Frequentemente porém há
tabelas que são de dados históricos, que vc sabe que não sofrem alterações por
regras de negócio, é um DESPERDÍCIO de recursos forçar o RDBMS a procurar dados
no UNDO para essas também, TALVEZ vc possa ter vários exports, alguns
exportando a partir de um SCN mas outros exportando objetos que vc sabe que não
sofrem DMLs.... Ou ainda, se vc tiver um PARTICIONAMENTO apropriado nas
tabelas, vc poderia exportar apenas algumas partições, mantendo os exports
anteriores : isso mais ou menos Simularia um "backup incremental".... E vc não
diz mas CERTAMENTE esse "backup" via export deve estar durando HORAS justamente
porque não tem muito o que vc fazer para obter backup incremental via export...
Outra opção COMUM pra vc não ter o risco de snapshot too old se
possivel;viável é vc criar uma Cópia daquelas tabelas frequentemente
alteradas/acessadas (via CREATE TABLE COPIA_nomedatabela as SELECT * FROM
nomedatabela, ou mesmo via INSERT /*+ APPEND PARALLEL(x) */ INTO
COPIA_nomedatabela (SELECT * FROM tabela), que seja), aí vc exporta ESSA TABELA
DE CÓPIA, não a tabela real - como a tabela de cópia com certeza não está sendo
usada pela aplicação, é ZERO a chance de vc precisar ler UNDO para o SELECT do
export que vai buscar dados nela....
E é claro, quanto mais vc ACELERAR o export, menor a chance de esgotar UNDO :
aí é usar as técnicas COMUNS de acelerar export, como NÂO fazer um export full
de banco mas sim vários exports em paralelo cada um exportando uma parte do
todo, Não exportar nem índices nem constraints nem estatísticas (essas coisas
podem ser refeitas depois), usar as opções de performance Adequadas (se for
datapump, vc TEM que ler/estidar a nota metalink/my oracle support "Checklist
For Slow Performance Of DataPump Export (expdp) And Import (impdp)", com Doc
ID=453895.1)....
[]s
Chiappa
