Menu de navegação

[msantinoParticipante]

Galera, alguém sabe explicar por que durante um EXPDP o banco gera archive excessivamente?

Está gerando archives de 600MB por minuto durante o EXPDP e não há nenhuma outra transação rolando.

O backup é relativamente grande e MUITO demorado (é o mesmo do outro post https://www.profissionaloracle.com.br/modules.php?name=Forums&file=viewtopic&t=5583) e tá acabando com o espaço da partição onde ficam os archives.

Tem alguma maneira de fazer com que o EXPDP não gere esse excesso? E qual o motivo, alguém sabe?

Vlw passoal, abs

[Rodrigo AlmeidaParticipante]

Msantino,

Primeiramente, tente usar o parâmetro METRICS=y no seu comando de EXPDP para coletar as informações de objetos e o tempo, será gerado um arquivo de log com essas informações.

Segundo, veja se no seu banco de dados, está com o FLASHBACK habilitado, dependendo da versão, existe um BUG que pode causar isso devido a tabela MASTER TABLE criado pela API do Data pump.

Terceiro, faça um trace na sessão que está rolando no EXPDP e em outra janela, veja o quanto a sessão do EXPDP está utilizando nos segmentos de UNDO. Talvez nem seja ele o problema.

Sobre o seu backup, isso pode ser devido as configurações dos parâmetros da instância, I/O e até mesmo um HANG no BD.

Abraços,

[msantinoParticipante]

@alphamek,

1 – Coloquei o parametro METRICS=y e não gerou nenhum log extra. Será que é porque eu já jogo a saída pra log (logfile=….)?
O que reparei de diferente foram umas informações extras, mas não entendi como isso pode ser útil nessa investigação além do tempo de backup por objeto:

Completed 3 TRIGGER objects in 1 seconds

2 – Sobre o flashback:

FLASHBACK_ON LOG_MODE
—————— ————
NO ARCHIVELOG

3 – Ainda não fiz o trace, porque o backup é feito à noite. Existe alguma forma de eu deixar agendado esse trace?

E respondendo à pergunta do @rman no outro tópico duplicado que eu abri, é um 10G e seguem os parâmetros:

expdp usuario/senha FULL=Y directory=DATA_PUMP_DIR dumpfile=${DUMP_NAME}_%U.dmp logfile=${DUMP_NAME}.log ESTIMATE=STATISTICS PARALLEL=20 “EXCLUDE=SCHEMA:”=’SYS'”” “EXCLUDE=SCHEMA:”=’SYSTEM'”” “EXCLUDE=SCHEMA:”=’SYSMAN'””

Valeu…

[msantinoParticipante]

Pessoal,

Após analisar as metricas geradas no backup, me deparei com essa parte:
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE
Completed 949207 TABLE objects in 103910 seconds

Ou seja:
103910 segundos = 1731 minutos = 28 horas

E pelo que entendi, nesta etapa ele está gerando o schema das tabelas, que no caso são 949.207 no total.

Será que existe alguma forma de otimizar essa etapa pra que não demore tanto tempo?

vlw pessoal…

[Rodrigo AlmeidaParticipante]

Então,

Mas tem que manter o foco, vamos tentar entender o problemas da geração de archives excessivo, acho muito estranho um EXPDP gerar 600MB por minuto, tudo bem que o Data Pump utiliza uma tabela mestre, mas não seria para tanto, nem para bases de 40TB faz isso.

Sobre performance, bom, são quase 1 milhão de objetos, só verificar se o hardware é o adequado para esse tipo de atividade, ou começar a customizar ao máximo a utilizados dos recursos de hardwares e parâmetros de banco de dados para agilizar o EXPDP.

Mas, voltando ao archive excessivo, teve alguma informação nova?

Abraços,

[msantinoParticipante]

@alphamek,

Sobre a geração dos archives eu não consegui evoluir, mas olha que coisa curiosa:
1 – Subi um oracle em outra máquina (mesma versão – 10.2.0.4)
2 – Restaurei um backup RMAN FULL da base de produção
3 – Validei o banco, alert.log, tudo normal, sem erros nem nada…
4 – Gerei um EXPDP desse cara

O EXPDP está tão demorado quanto o de produção, apesar de, nesta homologação ter o hardware inferior. Mas agora é que vem o lance:

Mas repare bem nas métricas:

Completed 12 TABLESPACE objects in 18 seconds
Completed 2 PASSWORD_VERIFY_FUNCTION objects in 3 seconds
Completed 3 PROFILE objects in 1 seconds
Completed 1 USER objects in 7 seconds
Completed 1565 USER objects in 7 seconds
Completed 34 ROLE objects in 10 seconds
Completed 7 PROC_SYSTEM_GRANT objects in 1 seconds
Completed 2087 SYSTEM_GRANT objects in 7 seconds
Completed 3545 ROLE_GRANT objects in 9 seconds
Completed 1565 DEFAULT_ROLE objects in 4 seconds
Completed 793 TABLESPACE_QUOTA objects in 2 seconds
Completed 1 RESOURCE_COST objects in 1 seconds
Completed 1 ROLLBACK_SEGMENT objects in 0 seconds
Completed 1 TRUSTED_DB_LINK objects in 1 seconds
Completed 210570 SEQUENCE objects in 694 seconds
Completed 176024 OBJECT_GRANT objects in 636 seconds
Completed 14 DIRECTORY objects in 0 seconds
Completed 16 OBJECT_GRANT objects in 1 seconds
Completed 2 OBJECT_GRANT objects in 0 seconds
Completed 5 CONTEXT objects in 131 seconds
Completed 341 SYNONYM objects in 18 seconds
Completed 5 SYNONYM objects in 16 seconds
Completed 12 TYPE objects in 285 seconds
Completed 4 PROCACT_SYSTEM objects in 11 seconds
Completed 6 PROCOBJ objects in 1 seconds
Completed 3 PROCACT_SYSTEM objects in 31 seconds
Completed 1571 PROCACT_SCHEMA objects in 1391 seconds
Completed 937613 TABLE objects in 177465 seconds
Completed 1372715 OBJECT_GRANT objects in 8306 seconds

Olha os objetos TABLE:
Completed 937613 TABLE objects in 177465 seconds

Tudo bem que são quase 1 milhão de objetos, mas isso ai são quase 50 horas!

Durante o EXPDP foi gerado mais de 400gb de archives. É mais que a base de dados inteira. Ela deve ter uns 300 e poucos GB de tamanho!

Que bizarro, não acha?

[msantinoParticipante]

Ih agora que eu vi que já tinha postado essa métrica! Cabeça de vento é beincadeira! rs…

Bom, to buscando na internet sobre essa questão do archive em excesso… qualquer novidade posto por aqui!

vlw pessoal…

[Autor]

Posts