Monitorar EXPDP e IMPDP

[José Laurindo ChiappaModerador]

Opa , então :

“O pessoal de infra fez uma verificação e identificou que o problema é na controladora do disco, ela trabalha de uma forma mais lenta, mas a importação foi feita e isso é o que precisava ser resolvido.”

==> OK, vc contornou pro cenário de exp/imp, mas uma controladora não otimizada/adequada IMPLICA em I/O mais lento, o que PODE SIM ser uma fonte de performance Inadequada ** Séria ** se/quando esse ambiente fazendo a importação tiver que ser utilizado como Produção…. Se for esse o caso, é IMPERATIVO que isso seja Solucionado, e isso é o tipo de issue qur somente aí, localmente, no seu ambiente, é que isso pode ser feito….

“Outra coisa, no Domingo 26/11 a noite, o backup com o expdp funcionou corretamente, já contemplando o novo schema que foi importado. ”

==> Tá, mas por questão de adequação, PLZ não se refira a export/import como BACKUP : como eu frisei bem em outra thread aqui do Fórum mesmo (e em Trocentos sites bons de referência, como https://asktom.oracle.com/pls/apex/asktom.search?tag=export-and-import-best-option-to-use-in-practical-enviroment) exp/imp são ferramentas de Transferência de Dados, para vc ter um backup COMPLETO e RESTAURÁVEL mesmo após um crash completo vc tem que usar as opções de BACKUP REAL do Oracle, como RMAN….

“Só que este mesmo ‘backup’ foi executado ontem e apareceu a mensagem abaixo:

.
.
.
>>> DBMS_AW_EXP: SYS.AW$AWXML: OLAP not enabled
>>> DBMS_AW_EXP: SYS.AW$AWREPORT: OLAP not enabled
Processando o tipo de objeto DATABASE_EXPORT/SCHEMA/TABLE/POST_INSTANCE/PROCACT_INSTANCE
Processando o tipo de objeto DATABASE_EXPORT/SCHEMA/TABLE/POST_INSTANCE/PROCDEPOBJ
Processando o tipo de objeto DATABASE_EXPORT/SCHEMA/POST_SCHEMA/PROCOBJ
Processando o tipo de objeto DATABASE_EXPORT/SCHEMA/POST_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto DATABASE_EXPORT/AUDIT
ORA-31693: Objeto de dados de tabela “MDC4WEB”.”GERA_HISTORICOEVENTOS” falhou ao ser carregado/descarregado e está sendo ignorado em decorrência de um erro:
ORA-02354: erro ao exportar/importar dados
ORA-01555: instantâneo muito antigo: número de segmento de rollback 1 com nome “_SYSSMU1_1880814008$” muito pequeno
. . exportou “SISORC”.”ORC_FORMULA_COMPLETA_VALORES” 9.756 GB 21695894 linhas
. . exportou “SISORC”.”ORC_FORMULA_COMPLETA” 2.184 GB 19705793 linhas
.
.
.

Pelo que já pesquisei na internet, o erro deve ter ocorrido pois a tabela poderia estar sendo utilizada no momento do backup.
”

==> Sim : export lê os dados através de uma Query/comando SELECT e POR DEFINIÇÃO um SELECT qualquer ** TEM ** que trazer os dados EXATAMENTE COMO ESTAVAM no instante em que o SELECT começou – se alguma outra Transação estava mexendo nesses dados (e/ou passa a mexer DURANTE o export!!) os dados originais vão estar no UNDO, que se for insuficiente vai dar esse erro, sim… INCLUSIVE, essa é uma das Muuuuuitas vantagens de vc usar uma ferramente de BACKUP real, elas copiam OS ARQUIVOS FÍSICOS, portanto INDEPENDEM de redo ou de qquer estrutura interna de controle de transações….
CASO vc realmente PRECISE mesmo usar export/import por qquer motivo, a “solução” para isso é óbvia : OU vc aumenta o espaço em disco para o UNDO (e provavelmente Aumenta também o setting de RETENTION, para que os dados necessários para a integridade do SELECT sejam mais prováveis de ficarem retidos nesse UNDO aumentado) OU então vc lança o export numa ocasião / momento em que NÂO hajam transações simultâneas/concorrentes….

“Essa tabela tem 121 milhões de registros e não tem nenhuma coluna do tipo lob.”

==> Independe em Grande Parte do tamanho da tabela : os settings de UNDO se relacionam é com QUANTO desses 121 milhões está sendo Alterado, não com o tamanho total dos dados…

“Nas pesquisas, o pessoal pede para verificar se a tabela tem coluna do tipo lob, analisar a tablespace de undo e o valor do parâmetro undo_retention.”

==> Sim, a questão dos LOBs é porque o versionamento dos dados em LOBs tem algumas diferenças dos dados escalares, mas se a tal tabela não tem LOBs, essas diffs não vem ao caso para vc…
Como eu disse, PREFERENCIALMENTE ou vc usa tools de backup REAL, que independem de undo (normalmente só dependem do REDO LOG e dos archives, ou nem disso se o banco for fechado durante o backup) ou então simplesmente que vc não tenha Transações concorrentes durante o export ou então aumenta teu espaço de UNDO e a Retenção para o valor máximo que pode ser exigido….

Se vc REALMENTE não puder usar tools reais de backup (digamos, porque o banco não pode ser fechado durante o backup E as exigências para um backup real à quente/online não podem ser cumpridas – digamos, banco não está em archive mode, ou então está mas gera uma quantidade tão loucamente enorme de redo log archives que não há na mídia de backup espaço suficiente para as incluir no backup online, ou coisa assim), aí só te sobra as opções de RE-AGENDAMENTO desse export ou de aumento de undo…
Não sendo possível o backup real, REAGENDAMENTO seria o melhor, mas dadas as dificuldades para se implementar uma política factível de horários de utilização do database / scheduling de processos num ambiente onde não há uma política Rígida (imagino ser seu caso), aí vc chegou no último caso, de ajustar UNDO…

“O undo_retention esta configurado com 900 e o tamanho da tablespace de undo 2 GB autoextensible.”

==> 900 segundos (o valor de RETENTION é em segundos) é o DEFAULT desse parâmetro (de onde ** DEDUZO ** que nunca um DBA fez análise das Transações e nem tuning/verificação disso aí nesse database) , e implica em 15 minutos : guardar só 15 minutos das últimas Alterações imho torna EXTREMAMENTE MAIS PROVÁVEL que dados alterados há várias horas atrás (já que teu export dura várias horas) possam ter sido DESCARTADOS, não é ????
De momento, eu aumentaria para 3600 a retenção (3600 segundos = 60 minutos = 1 hora) e da mesma forma que Quadrupliquei o retention eu Quadruplicaria o espaço máximo disponível pra área de UNDO… Eu prefiro sempre indicar o tamanho máximo pra tablespace de UNDO para o tamanho que eu quero MAIS uma gordurinha, mas se vc quiser pode também usar datafiles AUTO-EXTENSÍVEIS, que podem ter um MAXSIZE UNLIMITED (caso em queé VOCÊ que tem que se Assegurar que o filesystem/disk volume onde os datafiles ficam POSSUI espaço livre que dá pra chegar no espaço que eu quero) ou pode ter MAXSIZE xxxx, onde xxx já é o tamanho que eu quero…

[]s

Chiappa

OBS : refs para análise de UNDO e aumento/redefinição de undo settings no RDBMS Oracle são TROCENTAS, eu indico além da (crucial!!) Documentação Oracle https://dbatricksworld.com/ora-01555-snapshot-too-old/ , https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923 , https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:7705505116425 , http://olivertconsultoria.blogspot.com.br/2013/08/resolvendo-o-erro-ora-01555.html, https://mohamedazar.com/2010/02/23/ora-01555-snapshot-too-old-why/ e http://glufke.net/oracle/viewtopic.php?t=8811 como Demonstração/Exemplos ….