Menu de navegação

[airoospParticipant]

Bom dia,

Pesquisando na internet vi que é possível monitorar a execução de uma exportação e importação usando o datapump.

Por exemplo:

Há um processo em execução chamado sys_import_schema_01 que pode ser monitorado com:

impdp user/pass attach=sys_import_schema_01

Ao executar o comando acima, é aberto um prompt:

import> executando status é possível ver o acompanhamento.

Alguém sabe se é possível o STATUS ser executado com um refresh automático ou com um intervalo de tempo?

Oracle 11g em Windows.

Obrigado.

Airton

[José Laurindo ChiappaModerator]

Opa , jóia ? Que eu saiba não tem não, esse modo interativo não tem como ser programado…. O que pode ser feito porém é :

a. uma vez que o client do datapump faz ** SIM ** uma conexão abrindo uma sessão no banco E envia SQLs pro banco através dessa sessão (OU mesmo abrindo múltiplas sessões se vc estiver usando paralelismo), nada te impede de usar as MESMAS views/tabelas internas que vc usaria para monitorar uma sessão outra qualquer, como a V$SESSION, V$SQL, etc.. E tal como Qualquer outro programa, quando a sessão do datapump estiver fazendo um SQL longo (ie, lendo ou gravando uma tabela/índice tão grande que o RDBMS estima que vai demorar mais de três segundos pra terminar a leitura), vc obtém os detalhes desse SQL (tipo, o quanto já progrediu, o quanto falta, o tempo estimado pra acabar, etc) na V$SESSION_LONGOPS …
O ponto Essencial para poder se fazer isso, porém, é um que eu Acredito que vc não conhecia, é consultar a view interna DBA_DATAPUMP_JOBS…

e/ou

b. o DATAPUMP é todo programado em PL/SQL, e mais que isso desde o começo ele ofereceu E oferece uma API (também feita em PL/SQL) para gerenciar os JObs/atividades do datapump (e também mesmo para iniciar, eliminar, etc, jobs de datapump SEM o client externo, tudo via PL/SQL) : assim, com a package DBMS_DATAPUMP vc poderia se ‘conectar’ (atachar, pra usar o jargão Oracle) num job do datapump e consultar status dele…

======> para AMBAS as possibilidades que indiquei, https://databaseinternalmechanism.com/2016/09/13/how-to-monitor-datapump-jobs/ dá uns exemplinhos, e no metalink/My Oracle Support a nota “How To Monitor The Progress Of Datapump Jobs” (Doc ID 1471766.1) também : estude eles e escreva a Sua rotina, em cima da Sua necessidade, e seria Essa rotina que vc colocaria nom LOOP enquanto o datapump tá rodando, ou (inversamente) teria essa rotina num job de banco disparando a cada poucos minutos….

[]s

Chiappa

OBS : para maiores refs na API do datapump, além do essencial manual Oracle correspondente vc pode também consultar as notas metalink/My Oracle Support “How To Use The Data Pump API: DBMS_DATAPUMP (Doc ID 1985310.1) e a “How to Refresh the Local Tables Using DataPump API” (Doc ID 1073046.1) ….

[José Laurindo ChiappaModerator]

Ah, uns detalhes adicionais :

1) Não costumo usar então não sei te indicar o que o OEM (e GUIs de auxílio ao DBA do tipo) possuem de nativo pra monitoração do tipo, mas dá uma olhada lá e veja se algo te ajuda…

2) Eu Não recomendo de modo algum (muita trabalheira imho) mas EM TESE é possível vc escrever um shell script que execute o client datapump, atache no job, dê um comando STATUS, saia (mas deixe o job rodando) com o comando EXIT_CLIENT, fique em loop um minuto, depois atache de novo, peça o STATUS de novo…. Não tenho nenhum Exemplo pra isso mas EM TESE deve ser possível, fica como registro de uma Possibilidade a mais a ser explorada…

3) EVIDENTEMENTE, eu Imagino que vc ESTÁ usando a opção LOGFILE do client externo de datapump : se sim, uma Outra opção de monitoramento é simplesmente vc fazer um TAIL -F (ou qquer comando/utilitário que consulte arquivos-texto) para ver na tela o progresso do datapump…. No command prompt original (DOS) do Windows (entre OUTRAS tantas coisas faltantes!!) não há o comando tail, mas https://stackoverflow.com/questions/35920511/live-tail-of-windows-log-file indica que vc pode usar algumas built-ins do PowerShell para contornar essa necessidade – porém, por costume, eu prefiro baixar e instalar alguma coisa extra, como o CygWin ou então freewares dedicados como https://www.nextofwindows.com/baretail-is-a-windows-equivalent-linux-tail-app-monitors-log-file mais…
Claro, o LOGFILE não te dá a riqueza de detalhes da V$SESSION_LONGOPS nem das consultas á API mas para uma monitoração simples, tipo quero conferir em que ponto no geral está meu datapump, pode servir….E como é super-simples de implementar, NADA impede que vc use ele EM CONJUNTO com as outras técnicas de Monitoração…

4) Além da DBA_DATAPUMP_JOBS (que nos dá o nome dos JOBs de datapump correntemente conectados) nós temos também desde a versão 10g a DBA_DATAPUMP_SESSIONS, que nos diz o SID da sessão criada pela conexão do client de datapump, ela pode ser mais indicada para vc fazer JOINs com V$SQL, V$SESSION e quetais : consulta a documentação Oracle de referência que vc acha…

[]s

Chiappa

[Carlos Mauricio CerdeiraParticipant]

–

[Carlos Mauricio CerdeiraParticipant]

Depois que você fez o attach, ou seja, com o prompt aberto, ao invés do comando STATUS, acho que o que você quer é o comando CONTINUE_CLIENT.

Veja se ele te atende.

Outra opção, eu nunca utilizei, mas parece que o comando STATUS aceita um parâmetro para você informar o número em segundos para dizer a frequência para ele ser executado. Por exemplo, para ele rodar de 30 em 30 segundos: STATUS=30

Att,
Carlos

[airoospParticipant]

Boa tarde Chiappa,

Criei este tópico para ver alguma forma para monitorar uma importação que demorou muito, isto é:

Gerado um dump de 35.4GB usando o expdp banco 11g R2 em Windows. O schema que gerou este dump tem 65 tabelas, sendo que uma delas tem 37.04GB com mais de 120 milhões de linhas.

Este dump foi importado em outro banco 11g R2 também Windows, e o processo de importação do schema totalizando 230 objetos demorou 10 horas. Verificando o arquivo de log, o tempo que demorou mais foi nesta tabela de 37GB.

A tablespace deste schema foi criada com datafile em autoextend.

É possível melhor o tempo de importação, uma vez que este processo será executado novamente no próximo final de semana?

Obrigado.

Airton

[José Laurindo ChiappaModerator]

@carlos : sim, se o desejado fosse monitorar online (ie, tem alguém na frente do teclado , no prompt do client de datapump dando um comando STATUS e/ou então olhando a tela onde tá rodando o client do datapump) realmente digitando o comando STATUS frequentemente se obtém retorno, E também igualmente se vc passar na linha de comando do datapump um parâmetro STATUS=nn (onde nn é o número de segundos de intervalo) o client de datapump vai mostrar o mesmo output do STATUS digitado no prompt a cada nn segundos, sim… Porém, como ao que entendi é um processo longo, é INVIÁVEL ter uma pessoa não sei quantas horas olhando o output do client datapump e/ou digitando STATUS no prompt do client frequentemente, então a alternativa se for este o cenário são os outros procedimentos que indiquei….

@airosp : sim, existem Diversas possibilidades que podem causar lentidão/waits na importação, mas três causas Muito Comuns no import (principalmente para tabelas de maior porte!!) são a criação de índices, a validação de constraints e a coleta de estatísticas….
No caso de índice, o RDBMS precisa fazer ORDENAÇÃO da tabela completa, procurar o maior e o menor valor a importação na verdade está executando um DDL ou um DML através de uma sessão conectada no banco, e no caso de CONSTRAINTs e de Estatísticas obviamente o banco tem que varrer/ler/processar a tabela inteirinha também…. Tudo isso é demorado E normalmente o import faz tudo em SQL serial, ie, Não Faz paralelização de nenhum tipo (paralelização=criação de várias sessões escravas ao mesmo tempo, cada uma fazendo um bocadinho do trabalho) E também é single-thread logicamente falando, ie, faz uma coisa por vez : mesmo que o hardware server-class que vc tem na Empresa permita/seja capaz de executar vários SQLs ao mesmo tempo, ele primeiro faz o CREATE TABLE, só quando ele acaba é que vêm a criação de constraints, só quando esse acaba é que vêm a criação dos índices, tipo assim, step by step…

Assim, um teste DIRETO que vc pode fazer é abrir várias janelas de import incialmente Excluindo sempre as constraints da importação, e sendo que na primeira vc excluiu a(s) tabela(s) gigantes que vc tenha, e aí na segunda/terceira janelas vc Simultaneamente vai importando só os dados da(s) tabela(s) gigantes…. SE com isso de cara vc já ver uma queda monstruosa do tempo do import, tá comprovado que era isso o seu ‘problema’…. Sendo isso, acabado tudo, aí sim vc extrai os CREATE INDEX da(s) tabela(s) e os executa manualmente (via sqlplus, que seja) numa sessão onde vc habilitou PARALLEL SQL, e depois vc extrai o DDL das constraints e os altera para ter um NOVALIDATE : o ponto é que EM TESE as constraints Já Foram Validadas no banco origem, portanto pedindo para Não Validar o que vc já sabe estar válido vc Poupou um monte de leituras completas das tabelas envolvidas…. Para exemplos/refs de como operacionalizar isso, dá uma pesquisada na Documentação e uma googlada pelos parâmetros EXCLUDE, LOGFILE e CONTENTS do datapump…

Isso deve te ajudar Muitíssimo, mas é Possível que não seja esse o seu problema… Alternativamente, se desde o passo inicial de importar inicialmente sem constraints, com múltiplas sessões de import simultâneas E excluindo os índices da(s) tabela(s) grande(s) não te deu um resultado Significativamente muito melhor no tempo total gasto, TÁ PROVADO que não era esse seu ‘problema’ : aí vc vai precisar fazer uma análise mais detalhada…. No caso, como eu tinha dito, o datapump abre Sessões no database e envia SQLs por estas sessões, pra vc saber qual sessão tá emitindo SQLs que estão demorando muito, a ** primeira coisa ** que vc tem que fazer é IDENTIFICAR as sessões criadas pelo datapump, provavelmente consultando a DBA_DATAPUMP_SESSIONS : feito isso, nós sabemos que POR DEFINIÇÃO o RDBMS Oracle Não mantém o histórico completo e detalhado de cada wait que cada sessão sofreu, só registra o último, nas coluns LOCKWAIT e BLOCKING_SESSION_STATUS/BLOCKING_INSTANCE/BLOCKING_SESSION (se for espera por algum tipo de LOCK), e nas colunas ROW_WAIT_OBJ#/ROW_WAIT_FILE#/ROW_WAIT_BLOCK#/ROW_WAIT_ROW#/EVENT/P1TEXT/P1/P1RAW/P2TEXT/P2/P2RAW/P3TEXT/P3/P3RAW/WAIT_CLASS_ID/WAIT_CLASS#/WAIT_CLASS/WAIT_TIME/SECONDS_IN_WAIT/STATE para outros tipos de WAITs…

Sendo assim, OU na hora exata em que o import tá rodando vc vai consultando a V$SESSION durante o import pra ver se está tendo alguma demora maior em alguma das sessões OU então vc grava em algum lugar os waits que vão sendo registrados na V$SESSION pra analisar depois… Essa opção de GRAVAR os waits pode ser feita pelo AWR interno do RDBMS (isso ** SE ** vc tiver Licença de uso adquirida para ele E o teu RDBMS for Enterprise Edition) ou pode ser uma rotina/job seu que a cada poucos minutos grava numa tabela sua o conteúdo da V$SESSION para as sessões desejadas….

[]s

Chiappa

[airoospParticipant]

Chiappa,

Referente a execução do IMPDP, a geração dos archives poderia ter causada a lentidão no processo, devido há uma das tabelas de uma quantidade significativa de registros?

Sei que não é recomendado, mas bloquear a geração dos archives durante o processo de importação é possível?

Verificando lá no servidor, durante a importação foram gerados 1504 archives num total de 67.6GB.

Obrigado.

Airton

[José Laurindo ChiappaModerator]

Então : a única maneira de vc ‘bloquear’ a geração de archives durante a execução de SQLs (que Éo que o datapump faz no fim das contas) é vc desativar o ARCHIVE MODE no banco destino – DESDE QUE esse banco não vá participar de STANDBY/DATA GUARD, nem vá utilizar alguma feature que exija ARCHIVE MODE (como FLASHBACK ARCHIVE, entre outros) é tecnicamente Possível, sim… Porém, eu ** DUVIDO ** que seja esse a sua issue pois :

a. gravar 67.6 GB NEM DE LONGE é justificativa pra uma demora ultra aguda e crítica, desde que a tua área de archive esteja em discos de performance Normal num hardware enterprise class

E

b. o import faz INSERTs apenas, e INSERT gera POUCO redo logs, pois desfazer um INSERT é basicamente só um DELETE, e o archive simplesmente é a gravação dos redo log files : veja https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5259963300346090234 que o Autor lá explica que para INSERTs não há alterações posteriores / imagem dos dados anterior a desfazer, ENQUANTO que para UPDATEs tem sim …

==>> dado esses dois pontos eu ** repito ** ser Duvidoso a gravação dos archives ser motivo principal de performance inferior de um import, mas nada impede vc de testar, botando o banco vazio que vc criou na mão pra fazer o IMPORT em noarchive mode…

NÂO DEIXE de fazer o outro teste que indiquei de importar sem constraints E com a importação da tabela gigante numa sessão SEPARADA e depois criando em parallel-mode E novalidate os índices e as constraints, que muito Provavelmente isso deve te dar um retorno muuuuuuito maior….

[]s

Chiappa

[José Laurindo ChiappaModerator]

Ah, enquanto estamos falando de performance do impdp há dois pontos Críticos que esqueci de comentar, seguem aqui e tomara que te sejam úteis :

1) Por menor que seja o “overhead” causado por redo log (e consequente geração de archives, como eu disse archives nada mais são do que uma Cópia otimizada do redo log file), cfrme nós sabemos desde há muito é possível se ‘poupar’ uma enorme parte da geração de redo log para INSERTs, desde que esses INSERTs sejam feitos no ‘final’ do datafile, não reaproveitando eventuais espaços disponíveis no ‘meio’ do datafile, isso é o chamado DIRECT-MODE INSERT… Ele gera muito muito Muuuito Menos redo log porque os dados Obrigatoriamente serão gravados em blocos recém-formatados, ‘virgens’, não havendo portanto nenhuma informação/dado anterior a ser logado….
Uma das diferenças Positivas do impdp sobre o imp tradicional é justamente essa, o impdp PODE se aproveitar do APPEND-MODE para os INSERTs que ele enviará para o database, e PORTANTO gerar muito menos REDO LOG E PORTANTO arquivar MUITO MENOS redo log files : para isso vc usa o parâmetro ACCESS_METHOD=DIRECT_PATH na linha de comando do impdp…. EVIDENTEMENTE, isso não é de graça, isso não vem do nada : há uma SÉRIE de exigências/pré-requisitos para isso, que vão desde o database (E/OU alguma das tablespaces!!) não estar configurado em modo de FORCE LOGGING até exigências nas tabelas, que tem que estar com a atributo de NOLOGGING ativo (óbvio) e além disso não podem ser cluster tables, não pode estar havendo uma OUTRA transação já fazendo APPEND na tabela a importar, não deve ter TRIGGER ativa na tabela… Dá um look em https://docs.oracle.com/cloud/latest/db112/SUTIL/dp_import.htm#SUTIL3097 para refs gerais do parâmetro, e https://docs.oracle.com/cloud/latest/db112/SUTIL/ldr_modes.htm#SUTIL1288 para info geral de DIRECT-MODE

2) Mesmo fazendo o teste que recomendei de ter diversas sessões simultâneas (e que preferencialmente vão estar trabalhando com dump files diferentes, uma com a(s) tabela(s) gigante(s) e outra(s) com as restante(s), sempre incialmente SEM constraints e sem índices para que não haja inter-dependência entre as sessões (tipo, querer importar uma tabela-filha antes da tabela-pai) , mesmo assim Não deixe de Analisar/Testar também a opção de PARALLEL SQL nos seus datapump jobs : https://docs.oracle.com/cloud/latest/db112/SUTIL/dp_import.htm#SUTIL920 registra a sintaxe…. A única coisa a notar é que iirc parallel só está disponível no Enterprise Edition, não lembro se era essa a sua Edition…. E cfrme a nota metalink “Parallel Capabilities of Oracle Data Pump” (Doc ID 365459.1) só na versão 12.2 é que os metadados são importados usando parallel slaves : teste CUIDADOSAMENTE, se a sua versão é anterior a essa…

==> Agora sim, acho que vc tem em mãos TODAS as infos mais importantes para fazer seus testes e ver qual combinação de opções te dá a melhor Performance….

[]s

Chiappa

[airoospParticipant]

Chiappa,

Referente ao assunto acima, o processo de importação foi realizado em 2 horas, a diferença entre a execução anterior e essa, foi que no sábado a noite o processo de geração dos archives foi desativado. Além disso, a tablespace do schema que recebeu os dados, foi recriada e os datafiles colocados em uma storage.
Importação realizada e novamente archives ligado. Usando o parâmetro status na linha de comando do impdp, foi possível acompanhar a execução.

Antes de definir como o processo seria executado, todas as partes envolvidas entraram em acordo.

Obrigado.

Airton

[José Laurindo ChiappaModerator]

Bem, primeira coisa se vc não usou NENHUM dos recursos de performance que citei e a ** única ** diferença nas duas execuções foi desabilitar o arquivamento de redo logs e só com isso esse processo único/serial (não paralelizado E não simultâneo em múltiplas janelas) caiu de 10h para 2h no total, IMHO isso indica que vc tem algum problema ** SEVERO ** de I/O e/ou de configuração (ou de inadequação) no device onde esse arquivamento está sendo feito : como eu disse, é normal que a gravação de archives demore um pouco mas não a ponto de QUINTUPLICAR o tempo total…. Recomendo que um Especialista verifique aí NO LOCAL esse setup e esse device…

Mas ok, falando aqui da sua pergunta ref. import se essa simples Ação já fez cair 5x o tempo total blz, a adote… Provavelmente esse tempo cairia ainda mais aplicando as outras técnicas de melhoria de Performance mas se só com isso já chegou num patamar legal, não esquente com elas…

[]s

Chiappa

[airoospParticipant]

Chiappa,

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.

Outra coisa, no Domingo 26/11 a noite, o backup com o expdp funcionou corretamente, já contemplando o novo schema que foi importado. 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. Essa tabela tem 121 milhões de registros e não tem nenhuma coluna do tipo lob.

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.

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

Obrigado.

Airton

[José Laurindo ChiappaModerator]

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 ….

[José Laurindo ChiappaModerator]

Ah, detalhe adicional : além dos ORA-01555 (que é SIM um erro, quase todas mensagens ORA-xxx são SIM um erro/exception/issue a ser resolvida), observo também que vc recebeu msgs do tipo :

DBMS_AW_EXP: SYS.AW$AWXML: OLAP not enabled
DBMS_AW_EXP: SYS.AW$AWREPORT: OLAP not enabled

cfrme a nota metalink/documento de Suporte Oracle ‘Datapump Export (expdp) Raises Warnings Like “DBMS_AW_EXP: SYS.AW$EXPRESS: OLAP not enabled”‘ (Doc ID 1638799.1) registra, em princípio isso são Warnings apenas (não tem um ORA-xxx relacionado), podem ser desconsiderados…. Talvez só valha a pena o DBA confirmar se realmente o database não está com a Option de OLAP instalada/licenciada (provavelmente com o auxílio do Suporte Oracle), pois se alguém tá usando alguma Feature de OLAP sem a Option pode incorrer em issues…

[]s

Chiappa

[Author]

Posts