Menu de navegação

[msantinoParticipante]

Puts, pod crer! O burro fui eu!

Ou é só usar o EXCLUDE=”IN (…)”

[fabiogaleraParticipante]

msantino,

Resolveu o problema já ?

Apenas para verificação, verifique na DBA_DATAPUMP_JOBS, uma coluna que se chama STATE, verifique se possui algum JOB pendente, o status fica como RUNNING or NOT RUNNING.

Todas aquelas que estão NOT RUNNING, você pode dropar usando DROP TABLE

DROP TABLE .;

[msantinoParticipante]

@fabiogalera,

o problema foi resolvido em termos. Essa verificação que você falou eu já tinha feito. De fato, existiam uma série de jobs nessa tabela, todos em NOT RUNNING e eu apaguei todos eles. Mas mesmo assim, o backup ficava demorando absurdos.

Ele terminou de rodar com 3 dias de duração. Pra mim isso é inédito. 56gb de backup em 3 dias de duração. Já fiz backup de 600GB em pouco mais de 2h. Só pode ser o hardware, não é possível.

Eu sei que a estrutura não é a das melhores nesse caso. Tanto é que o ORADATA e o ORABCK estão no mesmo array de discos. Quando mando um DATAPUMP qualquer, a utilização do disco vai pra 95 a 100%. Impraticável! rs…

mas enfim, pelo menos nesse caso vamos manter o RMAN todos os dias e o backup lógico apenas 1x por semana….

valeu pela força galera…

[rmanParticipante]

@msantino

Dump de 56 gb em 3 dias, realmente é totalmente impraticável.

Se parar para analisar, 1 dump por semana também é impraticável. Pois se você precisar do dump não é viável voltar, pois voltaria 1 semana atrás. Se o problema não for resolvido é melhor nem fazer dump.

[Autor]

Posts