Menu de navegação

[Vinicius BertiParticipante]

Bom dia a todos.
Já utilizei bastante este fórum, mas como visitante, e foi extremamente útil.

Mas agora, estou com um enigma na geração de um dump Oracle.
A rotina de backup é executada todos os dias (duração: 20m), mas algumas vezes no mês, esta duração vai para 4 horas!
Se o banco é reiniciado, automaticamente a duração volta para 20 minutos. Mas o problema volta a ocorrer dentro de alguns dias.
Executávmos um script de geração de estatisticas todos os dias, mas mesmo removendo a rotina, o problema voltou a aparecer.
Não conseguimos descobrir o porque deste comportamento.

Qualquer ajuda é extremamente bem vinda.

Segue parâmetros

Oracle Database 12c Release 12.1.0.1.0 – 64bit Production (não é enterprise)
schemas=PRODUCTION
directory=EXP_DIR
dumpfile=20171119.dmp
logfile=20171119.expdp.log
EXCLUDE=STATISTICS
METRICS=Y

RAM Servidor: 32gb
Tamanho da database: 20gb

memory_max_target 16000M
memory_target 16000M
pga_aggregate_limit 11200M
pga_aggregate_target 0
sga_max_size 16000M
sga_target 0

Desde já, muito obrigado!

[José Laurindo ChiappaModerador]

Jóia ? Então, antes de responder um Aviso : se vc está usando export (e import posterior, claro) como ferramenta principal de Backup/Restore, lamento informar mas vc está Fundamentalmente Errado – https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:19310294390482 e a própria Documentação Oracle já avisam, mas isso é Completamente Inseguro…. Entre outras coisas, o export NÃO faz recover de eventuais corrupções em disco, Não permite backup incremental, Não grava os dados/tabelas internos do database Oracle (ele só grava os dados DOS USUÁRIOS, os dados internos do database, que ele usa pra ase controlar Não São exportados nunca – o que vc acha que acontece se der um crash e vc só ter dados do usuário ?? Vc VAI ter que tentar construir NA MÃO um database vazio pra poder importar esses dados de usuário!!)…. Enfim, é uma FURADA : por essas e outras razões imho export só para COMPLEMENTAR tua política, o backup e restore PRINCIPAL *** tem **** que ser por cópia física dos datafiles e arquivos internos/de controle do database, preferencialmente pelo utilitário RMAN da própria Oracle…

Isso dito, a sua resposta : o export nada mais é do que uma série de Queries, e queries essas que normalmente lêem a tabela inteira – nesse tipo de cenário as DUAS coisas que podem fazer uma query demorar muito mais são OU concorrência com outros SQLs (digamos, há um SQL pesado que faz toneladas de I/O que praticamente esgota a capacidade de I/O do teu hardware e não deixa quase nada pras queries do export que de vez em quando calha de rodar simultaneamente ao export) OU então o RDBMS Oracle tá tendo que fazer alguma manutenção interna (digamos, gravação de redo logs, checkpoints, delayed block cleanout/limpeza de caches, etc, etc) que de vez em quando calha de precisar ser executada ao mesmo tempo que o export….
Como pelo que vc diz é uma coisa que acontece de vez em quando, vc tem que ter um HISTÓRICO da performance do datapump : para isso a tua única possibilidade é ter um JOB que dispare a cada poucos minutinhos e REGISTRE os waits/eventos que as sessões estão enfrentando…. Como teu banco não é Enterprise Edition vc não pode usar o JOB e as tabelas criados pela própria Oracle para essa monitoração e registro (o chamado AWR), então a sua Alternativa é escrever um…. E Evidentemente, acredito que vc não quer monitorar/registrar/obter histórico de performance de TODAS as sessões do database, mas sim apenas daquelas criadas pelo export – vc as encontra consultando as views do datapump, como DBA_DATAPUMP_SESSIONS e DBA_DATAPUMP_JOBS, aí vc filtra apenas essas sessões na V$SESSION…

Adicionalmente a isso, vc pode Também implantar opções de Monitoração do datapump em si : como é algo que acontece Ocasionalmente e (vc não diz mas é quase Certo que) não há uma pessoa em frente à máquina olhando durante todo o export, eu entendo que vc vai ter que a cada poucos minutos obter o status do export programaticamente (veja aqui mesmo no Fórum a thread com o título de “Monitorar EXPDP e IMPDP”) e depois gravar num arquivo esse status, provavelmente via UTL_FILE creio…

[]s

Chiappa

[José Laurindo ChiappaModerador]

Obs adicionais :

1. além de status/waits das sessões do export, seria interessante vc manter também um histórico de status/waits do banco em geral, justamente para tentar captar/provar ou desprovar a ação de processamento interno do database interferindo no export, E também status/waits/ações das OUTRAS sessões no banco para tentar provar/desprovar a possibilidade de outra sessão consumindo recursos em demasia… O manual Oracle de database Concepts no capítulo “Data Dictionary and Dynamic Performance Views” (online em https://docs.oracle.com/database/121/CNCPT/datadict.htm#CNCPT002) dá os conceitos e o manual “Database Reference” (online em https://docs.oracle.com/database/121/REFRN/toc.htm) lista/detalha as fontes de informação de performance e status do database e das sessões…

2. um modelo possível para a rotina que vc vai escrever seria algo mais ou menos próximo do Simulated ASH, veja em http://pioro.github.io/orasash/ : claro, essa tool pretende simular o awr/ash da Oracle quase que em full, então ela é bem longa e complexa : talvez ela seja demais pro seu caso e vc prefira escrever algo mais simples e melhor adaptado pra sua necessidade, mas fica o exemplo

   []s

   Chiappa

[Vinicius BertiParticipante]

Caramba, que resposta.
Muito, muito obrigado pelo seu tempo em detalhar tudo isto.

Sobre o RMAN, já tentei implementar, mas o projeto não foi pra frente por problemas de falta de espaço em disco.

Vou tentar montar um ambiente para monitoramento das tabelas mencionadas.
Obrigado novamente.

[José Laurindo ChiappaModerador]

Blz ? Sim, as vezes minhas respostas ficam um tanto compridas porque eu tento Conceituar e explicar os detalhes, ao invés de só dar a resposta devida mínima – fico contente que tenha te ajudado….
Quando vc for criar uma solução de monitoramento sua, é como eu disse, a lógica básica é simples : vc cria tabelas com as mesmas colunas da V$SESSTAT, da V$SYSSTAT, da V$SESSION, da V$SQL, etc, adicionando uma coluna numérica pra ser a chave E uma coluna de data pra registrar a hora que o INSERT foi feito nelas e cria uma procedure que é disparada a cada 5 minutos ou coisa assim por um JOB de banco – nada muito Sofisticado, o mais trabalhoso é que vc vai ter que escrever algo, mas a lógica Não É altamente complexa…. E adicionalmente, para ter um histórico de performance do banco como um todo, além de escrever a sua rotina vc num banco não-Enterprise Edition vc não pode usar o AWR/ASH mas ** pode ** usar o STATSPACK : ele não é tão preciso como o AWR/ASH e além disso por ser antigo não registra/guarda ** todas ** as colunas das V$, mas pode ser uma adição útil, também …. Veja a Documentação Oracle e sites de ref como http://loredata.com.br/2016/07/21/instalacao-oracle-statspack/ , http://www.oraclehome.com.br/2014/04/16/implementando-o-statspack-oracle-1011g/ e https://oracle-base.com/articles/8i/statspack-8i para instruções de setup dele… E é claro, para que seja útil para uma análise Pontual como a que vc quer fazer, vc deve colocar um INTERVALO entre cada leitura / coleta nas V$ que o statspack faz de POUCOS minutos, coisa de 5 ou 10 talvez, não mais que isso…

Sobre o RMAN, observo que Não faz lá muito sentido alegar ‘falta de espaço’ pro RMAN : primeiro, eu IMAGINO que esses dumps vão pra pra uma unidade de backup externa, seja fita ou disco USB/firewire removível né ? Afinal, se vc mantém só em disco teus dumps na hora que der um crash de disco vc perde tudo, né não ?? Sendo isso, Por Que vc não pode enviar os arquivos de backup do RMAN diretamente pra esse unidade externa ???
E um segundo ponto, se o backup TEM que ir pra disco : se tem espaço pra um dump FULL dos dados (já que o export quase não tem opções de cópia Incremental), será que não dá mesmo pra que no mesmo espaço de disco vc ter BACKUPS RMAN INCREMENTAIS ???? Será que essa ‘falta de espaço’ na tentativa anterior foi porque vc queria fazer sempre backup RMAN full, todo dia ?? Aí não tem espaço que guente, mesmo…. AVALIE essas possibilidades, se esse database é crítico para a Empresa…

[]s

Chiappa

[Alan ResendeParticipante]

boa tarde.
Vinicius,

Eu tive um problema semelhante aqui na versão 12.1.0.1. À época, encontrei algo sobre um bug relacionado ao parâmetro streams_pool_size. Como workaround, uma nota citava a necessidade de configurar um valor de 160M (167772160). Para solução definitiva a nota também citava a aplicação de um patch corretivo. Não tenho o número do patch aqui, mas você pode procurar no MOS a respeito. Pesquise por “streams_pool_size” ou “dpexp bug on 12.1.0.1” que vai encontrar qual patch você deve aplicar.

Boa sorte. Espero ter ajudado.

Att.

Alan

[José Laurindo ChiappaModerador]

Sim, houveram uns tantos bugs relacionados com streams e/ou gerenciamento de memória no release inicial do 12c (como o Bug 9896536 – Small memory leak occurs in streams pool when expdp is executed (Doc ID 9896536.8) e o Bug 17365043 – “STREAMS AQ: ENQUEUE BLOCKED ON LOW MEMORY” WHEN REDUCING STREAMS_POOL_SIZE , fixed in 12.2.0.1) para citar dois, mas normalmente eles são Fáceis de identificar, pois os eventos relacionados com streams e/ou com memória alocada das sessões criadas pelo datapump vão lá em cima – NATURALMENTE, se/quando ele Monitorar as sessões do datapump como indicado ele encontra isso, SE for essa a Causa da lentidão…

E é claro, antes de sair setando isto ou aquilo, vale SEMPRE a pena checar no Suporte Oracle se há patches recomendáveis, EM ESPECIAL quando o patchlevel é 1, como a porção “0.1.0” do release 12.1.0.1.0 que está sendo em uso : isso normalmente indica que NENHUM patch foi Aplicado…

[]s

Chiappa

[Autor]

Posts