Menu de navegação

[msantinoParticipante]

@rman,

O exclude é porque são muitos schemas. Muitos, muitos mesmo! Vale mais a pena excluir esses 3 do que incluir todos os outros.
E não fui eu quem montou, já estava assim quando eu cheguei. juro! hahahaha

Serinho, pelo que entendi, a idéia de excluir esses 3 schemas é porque o principal objetivo é ter o backup dos schemas dos usuários que são mais de 100.

Sobre o tamanho do banco, não sei exatamente, mas o último backup (lógico) feito de quase 1 mês atrás tem cerca de 60gb.

A princípio ele está executando mesmo, porque esse tablespace DATAPUMP agora está com 218MB ocupados, apesar do EXPDP ainda estar no mesmo status no console. na dba_datapump_jobs tá como EXECUTING…

Só que o arquivo de dump continua com 4k ainda.

O que acho estranho é essa lentidão absurda… nunca foi tão demorado assim….

[rmanParticipante]

@msantino

O que eu achei estranho é que esta FULL com EXCLUDE, se está com EXCLUDE não tem sentido ser FULL, entendeu ?

Pela mensagem ele está calculando uma estimativa do tamanho do dump por STATISTICS, teste por BLOCK que é padrão.

O dump está com 4K ainda por que não começou a exportar.

Da noite do dia ficou lento ? Antes fazia em quanto tempo ?

[msantinoParticipante]

@rman,

então, como eu disse, o objetivo do exclude é tirar esses schemas que são mto grandes. Essa base possui mais de 100 schemas de negócios, então o objetivo desse backup lógico é termos apenas esses schemas.
Sem ser FULL, como eu faria pra pegar todos os schemas tirando esses 3? Só tirar o FULL e botar o exclude ele já faria do resto todo ou eu teria que listar schema por schema?

Achei mais lógico dessa forma. Mas se tiver outra e vc achar que é melhor, toda dica será bem vinda! rs…

Acho que ele está fazendo por blocks já:

Estimate in progress using BLOCKS method…
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 58.72 GB

E realmente o tamanho já está aumentando. Está com 48GB agora, quase 48h depois do início. E o tablespace DATADUMP q eu criei está com 18G ocupados. Só por causa do backup! Bizarro…

Não sei dizer sobre os backups antigos, mas to achando que não é uma situação nova. Eu sou novo aqui e vi que o ultimo backup era do dia 4/11, mas não tinha outros na pasta. Imaginei que tinham ido pra fita já, mas pelo visto faz mto tempo q não rola… Os logs de outubro já mostravam o erro de tablespace cheio…

[rmanParticipante]

@msantino

Sim, exatamente, apenas retire o FULL e mantenha o EXCLUDE.

Eu tenho um dump de 70 GB que é feito em meia hora e com 100 MB na tablespace do DATAPUMP já é suficiente.

Você está trabalhando com a versão Enterprise Edition ? Vi o parâmetro PARALLEL em 20. Será que o paralelismo está atrasando devido a concorrência ? Teste sem o PARALLEL. Aqui estou com o Standard Edition sem PARALLEL e faz em meia hora.

A máquina do servidor é boa ?

[msantinoParticipante]

@rman,

Vou testar sem o FULL.

Sobre o paralelismo, já testei. Depois que mandei o comando aqui no post pensei nisso e interrompi e mandei fazer de novo sem ele. Está gerando um único arquivo desde então.

Cara, a máquina é um Xeon X5460 @ 3.16GHz e 32Gb de RAM. Só não sei a estrutura de discos, em qual RAID está e tal…
Sò sei que o /oradata e o /orabkcp são partições do mesmo HD ou array de discos (total de 2tb).

Mandei um IOSTAT com intervalos de 2s na segunda. no início do backup o %util não ficava abaixo de 90% e o await sempre acima de 4. Agora tá mais tranquilo, em torno de 20 e 30% e await em 1.5/1.7.

Tem uma outra instância nessa mesma máquina que faz um backup de 22GB em 12h todos os dias, sem problema nenhum.

Que acha?

[rmanParticipante]

@msantino

A máquina não é ruim não hein… O problema não deve ser a máquina. Mesmo 22 gb em 12 horas é muito lento.

E o backup full pelo RMAN, quanto tempo demora ?

Qual a versão do Oracle e o SO ?

[msantinoParticipante]

@Rman,

É oracle 10g (10.2.0) num Red Hat 4.

Se liga no erro que está dando agora:

ORA-31693: Table data object “NOME_SCHEMA”.”NOME_TABELA” failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-00604: error occurred at recursive SQL level 3
ORA-21780: Maximum number of object durations exceeded.
ORA-06512: at “SYS.DBMS_METADATA”, line 2682
ORA-06512: at “SYS.DBMS_METADATA”, line 2828
ORA-06512: at “SYS.DBMS_METADATA”, line 4498
ORA-06512: at line 1

(Obs: eu renomeei o nome do schema e o nome da tabela aqui no post)

Já viu isso?

O backup do RMAN dessa outra instância (de 22gb) roda em 2h. O dessa instância principal (com o problema do backup) roda em 3h e os 2 RMAN rodam em simultâneo.

[rmanParticipante]

@msantino

Esse erro eu nunca vi não… Vou deixar essa pros nossos colegas opinarem…

Creio que se você executar o RMAN um de cada vez, você deve baixar esse tempo…

[msantinoParticipante]

@rman,

Com certeza ser´amais rápido um RMAN de cada vez. Mas isso não chega a ser um problema, já que nesse horário não tem operação no banco, então a demora não impacta na performance.

Só que esse erro agora f#&@& tudo! hahahaha
Não to achando nada na internet sobre… só fala sobre loops e recursividade em procedures e tal…

Vou ficar sem backup do banco ou então vou ter que fazer schema por schema! rs…

[rmanParticipante]

@msantino

Por que não faz FULL ? Os schemas SYS, SYSTEM e SYSMAN vai aumentar em muito o dump ?

Aqui é feito 2 dumps FULL diário.

[msantinoParticipante]

Cara, se pra fazer um dump sem eles já demora mais de 48h, imagina com eles? hahahaha

Então, eu achei esse link aqui http://www.oracle86.com/a/backup/expdpimpdp/2011/1102/84.html mse referindo a isso como um BUG no expdp/impdp relacionado ao paralelismo. Pelo que eu entendi, eu teria que aumentar esse parâmetro.

Botei pra rodar de novo o DUMP com paralelismo e alterei a forma do EXCLUDE, botando assim:
"EXCLUDE=SCHEMA:"NOT IN ('SYS', 'SYSTEM', 'SYSMAN', 'DATAPUMP')""

Se não funcionar vou tentar ele FULL mesmo, sem o EXCLUDE.

Obs: tentei rodar sem o FULL=Y, só com o EXCLUDE mas deu erro:

ORA-39001: invalid argument value
ORA-39038: Object path “SCHEMA” is not supported for SCHEMA jobs.

Aí eu acrescentei o FULL=Y e tá rodando! rs…

[rmanParticipante]

@msantino

Se a ideia é fazer dump de schemas que não são do Oracle, falta filtrar um monte 😆


SELECT *
FROM ALL_USERS


[msantinoParticipante]

Sim, mas esses são os mais significativos em questões de tamanho e tempo de duração.

Por isso excluimos só esses.

[msantinoParticipante]

Po, o meu NOT IN não funcionou! Ele SÓ fez o dump dos schemas dentro do NOT IN. Ele é burro? hahahahah

Mandei um NOT LIKE ‘%SYS%’ pra ver no que dá. Será que ele só vai fazer desses ‘%sys%’? hahahaha

[rmanParticipante]

@msantino

Se você for parar para analisar:


"EXCLUDE=SCHEMA:"NOT IN ('SYS', 'SYSTEM', 'SYSMAN', 'DATAPUMP')""


Você tem 2 negação (EXCLUDE + NOT), logo o resultado trazer SYS, SYSTEM, SYSMAN e DATAPUMP e excluir o resto.

Tente:


"INCLUDE=SCHEMA:"NOT IN ('SYS', 'SYSTEM', 'SYSMAN', 'DATAPUMP')""


[Autor]

Posts