Re: [oracle_br] Re: ORA-01555 - Oracle 12g
Blz, espero que a minha resposta tenha Esclarecido um pouco ao menos o funcionamento/conceitos do UNDO, demonstrado o porquê da Necessidade dele, sugerido enfaticamente adotar o backup real via RMAN, E caso isso não seja possível espero ter indicado as Possibilidades de melhoria no procedimento de export E no UNDO em si para Minimizar o risco de SNAPHOT TOO OLD []s Chiappa
Re: [oracle_br] Re: ORA-01555 - Oracle 12g
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] 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
[oracle_br] Re: ORA-01555 - Oracle 12g
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
