Chiappa, boa tarde! Muitíssimo obrigado pelas dicas!!! Lhe asseguro, serão de grande valia pra nós!!! Já estamos providenciando os ajustes necessários para a nossa database. Abração! Eugênio Tenórioeu_teno...@yahoo.com.br Em quinta-feira, 3 de outubro de 2019 17:23:04 BRT, jlchia...@yahoo.com..br [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: 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 #yiv7073066408 #yiv7073066408 -- #yiv7073066408ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7073066408 #yiv7073066408ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7073066408 #yiv7073066408ygrp-mkp #yiv7073066408hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv7073066408 #yiv7073066408ygrp-mkp #yiv7073066408ads {margin-bottom:10px;}#yiv7073066408 #yiv7073066408ygrp-mkp .yiv7073066408ad {padding:0 0;}#yiv7073066408 #yiv7073066408ygrp-mkp .yiv7073066408ad p {margin:0;}#yiv7073066408 #yiv7073066408ygrp-mkp .yiv7073066408ad a {color:#0000ff;text-decoration:none;}#yiv7073066408 #yiv7073066408ygrp-sponsor #yiv7073066408ygrp-lc {font-family:Arial;}#yiv7073066408 #yiv7073066408ygrp-sponsor #yiv7073066408ygrp-lc #yiv7073066408hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7073066408 #yiv7073066408ygrp-sponsor #yiv7073066408ygrp-lc .yiv7073066408ad {margin-bottom:10px;padding:0 0;}#yiv7073066408 #yiv7073066408actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7073066408 #yiv7073066408activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7073066408 #yiv7073066408activity span {font-weight:700;}#yiv7073066408 #yiv7073066408activity span:first-child {text-transform:uppercase;}#yiv7073066408 #yiv7073066408activity span a {color:#5085b6;text-decoration:none;}#yiv7073066408 #yiv7073066408activity span span {color:#ff7900;}#yiv7073066408 #yiv7073066408activity span .yiv7073066408underline {text-decoration:underline;}#yiv7073066408 .yiv7073066408attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv7073066408 .yiv7073066408attach div a {text-decoration:none;}#yiv7073066408 .yiv7073066408attach img {border:none;padding-right:5px;}#yiv7073066408 .yiv7073066408attach label {display:block;margin-bottom:5px;}#yiv7073066408 .yiv7073066408attach label a {text-decoration:none;}#yiv7073066408 blockquote {margin:0 0 0 4px;}#yiv7073066408 .yiv7073066408bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv7073066408 .yiv7073066408bold a {text-decoration:none;}#yiv7073066408 dd.yiv7073066408last p a {font-family:Verdana;font-weight:700;}#yiv7073066408 dd.yiv7073066408last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7073066408 dd.yiv7073066408last p span.yiv7073066408yshortcuts {margin-right:0;}#yiv7073066408 div.yiv7073066408attach-table div div a {text-decoration:none;}#yiv7073066408 div.yiv7073066408attach-table {width:400px;}#yiv7073066408 div.yiv7073066408file-title a, #yiv7073066408 div.yiv7073066408file-title a:active, #yiv7073066408 div.yiv7073066408file-title a:hover, #yiv7073066408 div.yiv7073066408file-title a:visited {text-decoration:none;}#yiv7073066408 div.yiv7073066408photo-title a, #yiv7073066408 div.yiv7073066408photo-title a:active, #yiv7073066408 div.yiv7073066408photo-title a:hover, #yiv7073066408 div.yiv7073066408photo-title a:visited {text-decoration:none;}#yiv7073066408 div#yiv7073066408ygrp-mlmsg #yiv7073066408ygrp-msg p a span.yiv7073066408yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7073066408 .yiv7073066408green {color:#628c2a;}#yiv7073066408 .yiv7073066408MsoNormal {margin:0 0 0 0;}#yiv7073066408 o {font-size:0;}#yiv7073066408 #yiv7073066408photos div {float:left;width:72px;}#yiv7073066408 #yiv7073066408photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv7073066408 #yiv7073066408photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv7073066408 #yiv7073066408reco-category {font-size:77%;}#yiv7073066408 #yiv7073066408reco-desc {font-size:77%;}#yiv7073066408 .yiv7073066408replbq {margin:4px;}#yiv7073066408 #yiv7073066408ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv7073066408 #yiv7073066408ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv7073066408 #yiv7073066408ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv7073066408 #yiv7073066408ygrp-mlmsg select, #yiv7073066408 input, #yiv7073066408 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv7073066408 #yiv7073066408ygrp-mlmsg pre, #yiv7073066408 code {font:115% monospace;}#yiv7073066408 #yiv7073066408ygrp-mlmsg * {line-height:1.22em;}#yiv7073066408 #yiv7073066408ygrp-mlmsg #yiv7073066408logo {padding-bottom:10px;}#yiv7073066408 #yiv7073066408ygrp-msg p a {font-family:Verdana;}#yiv7073066408 #yiv7073066408ygrp-msg p#yiv7073066408attach-count span {color:#1E66AE;font-weight:700;}#yiv7073066408 #yiv7073066408ygrp-reco #yiv7073066408reco-head {color:#ff7900;font-weight:700;}#yiv7073066408 #yiv7073066408ygrp-reco {margin-bottom:20px;padding:0px;}#yiv7073066408 #yiv7073066408ygrp-sponsor #yiv7073066408ov li a {font-size:130%;text-decoration:none;}#yiv7073066408 #yiv7073066408ygrp-sponsor #yiv7073066408ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv7073066408 #yiv7073066408ygrp-sponsor #yiv7073066408ov ul {margin:0;padding:0 0 0 8px;}#yiv7073066408 #yiv7073066408ygrp-text {font-family:Georgia;}#yiv7073066408 #yiv7073066408ygrp-text p {margin:0 0 1em 0;}#yiv7073066408 #yiv7073066408ygrp-text tt {font-size:120%;}#yiv7073066408 #yiv7073066408ygrp-vital ul li:last-child {border-right:none !important;}#yiv7073066408