Menu de navegação

[PetersonParticipante]

Bom dia Lista,

Preciso da ajuda de vocês para o seguinte: Tenho uma política de backups configurada no RMAN que é a seguinte:
Domingo: Backup incremental nível 0 do database;
Segundas e terças: Backup incremental nível 2 do database;
Quartas: Backup incremental nível 1 do database;
Quintas, sextas e sáb.: Backup incrementarl nível 2 do database;
Todo dia a cada 4hs: Backup de todos os archivelogs;

Bom, é o seguinte, configurei uma retenção de 7 dias no RMAN. Quando olho a pasta onde ele gera os backups pieces, vejo que há arquivos de 10 dias… Quando executo o comando report obsolete, ele não me mostra esses arquivos com mais de 7 dias. Alguém tem alguma idéia do por quê disso?

abraços!

Peterson

[vieriParticipante]

Inclua estes bloco no final do script RMAN.

crosscheck backupset;
crosscheck archivelog all;
CROSSCHECK BACKUP;
#RESTORE TABLESPACE SYSTEM VALIDATE;
#RESTORE ARCHIVELOG ALL VALIDATE;
LIST BACKUP OF DATABASE;
REPORT UNRECOVERABLE;
REPORT SCHEMA;
REPORT NEED BACKUP;
REPORT OBSOLETE;

Delete noprompt expired backup;
Delete noprompt expired archivelog all;
Delete noprompt obsolete;

[PetersonParticipante]

Vieri,

Obrigado pela resposta, mas os arquivos ainda não foram deletados.

[Marcos BragaParticipante]

Olá Peterson,

Pode passar para nós o resultado do SHOW ALL do RMAN?

Como alternativa é possível utilizar esse período dentro do comando executado no rman. Por exemplo:

RMAN> delete obsolete recovery window of 7 days;

[]s
Braga

[PetersonParticipante]

Bom dia Braga,

A Retention Policy está setada com o período de 7 dias, portanto o efeito do comando que sugeriu foi o mesmo, ou seja, ainda não apagou os arquivos (atualmente com 12 dias).

using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘E:RMANProtprdcontrol_%F.bkp’;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘E:ORACLEPRODUCT10.2.0DB_1DATABASESNCFPROTPRD.ORA’; # default

[Marcos BragaParticipante]

Olá Peterson,

Posso concluir que: o RMAN precisa desses arquivos antigos para efetuar um recover completo do banco (uma hipótese).

Algo estranho de ocorrer, mas há possibilidade de verificar utilizando o seguinte comando:

RMAN> restore database validade;

Esse comando efetua uma checagem dos arquivos de backup necessários para restaurar o banco de dados. Observe se realmente o RMAN precisa desses arquivos antigos.

Agora, caso não precise, efetue um backup completo sem a opção incremental ou diferencial e depois execute um CROSSCHECK BACKUP e depois um DELETE OBSOLETE.

Esse procedimento vai apagar os arquivos antigos, depois disso é possível acompanhar o que pode estar ocorrendo com o backup.

Não sei se é a solução, mas é mais uma opção para verificar.

[]s
Braga

[PetersonParticipante]

Braga,

Obrigado pela ajuda. Vou fazer esses testes e posto o resultado aqui.

Peterson

[vieriParticipante]

Faz um teste execute o backup level0 diversas vezes num mesmo dia e ve se os antigos são removidos… derrepente isso lhe explica algo. 😆

[PetersonParticipante]

Vieri,

Fazer mais de um backup nível 0 não está excluindo os outros, nem o RMAN entende os antigos como obsoletos. O problema está aí. Por que ele não entende o backup antigo como obsoleto uma vez que já existe um backup nível 0 mais novo?

[vieriParticipante]

No minimo extrano…

utilize as claúsulas padrão então, enquanto o Rodrigo Almeida não vem aqui esclarecer esse dilema:

RMAN> delete backup completed before ‘sysdate -8’;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1055 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=1004 devtype=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: sid=1094 devtype=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: sid=1038 devtype=DISK
….

[Rodrigo AlmeidaParticipante]

Pessoal,

A politica de retenção é para mencionar ao Oracle as opções que ele tem de recuperação a partir da data de configuração do RETENTION WINDOWS POLICY.

Se o problema está sendo os backupsets que estão em disco ainda, na verdade quem tem que fazer essa tarefa é o agente que manda para fita caso vc esteja trabalhando com o RMAN para DISCO e depois outro agente manda para FITA.

Se estiver trabalhando com MML, isso não ocorre pq não para em disco.

Afinal, a configuração está no agente que manda para fita e mencionar que quando ele copiar para fita apagar o arquivo.

Dependendo do agente que está trabalhando, pode mencionar para apagar os arquivos e deixar em disco os arquivos dos últimos 7 dias, e com isso contempla a sua RETENION WINDOW POLICY.

Caso precise de restauração com datas anteriores ao seu retention, basta aumentar a janela e realizar um crosscheck!

Abraços,

[PetersonParticipante]

Boa tarde Rodrigo,

Então tenho que tratar a exclusão dos backup pieces manualmente, seja por script ou seja por interação do agente de cópia para fita?

No meu ambiente atual, o RMAN faz backup para uma área de disco e o agente de backup depois leva esses backup pieces como flat files para fita. Você aconselha que faça o controle das deleções pelo Oracle (usando o comando que nosso amigo Vieri sugeriu “delete backup completed before…” ou pelo agente de backup???

[Rodrigo AlmeidaParticipante]

Olá Peterson,

Como o Vieri disse está correto, o RMAN pode realizar a tarefa de limpar os BS do disco conforme você queira, executando comando DELETE.

Porém, você tem que manter o controle das deleções conforme a sua janela de backup, se realizar um CROSSCHECK o RMAN irá validar todos os backups em disco que estão de acordo com a sua RETENTION POLICY.

Os que não estão de acordo, será marcado como obsoleto, isso irá depender se está trabalhando com RETENTION REDUNDANCY ou RETENTION RECOVERY WINDOWS (Por tempo).

Geralmente, o que fazemos para isso, se temos uma área em disco suficiente para armazenar todos os nossos backups pelos dias da nossa retenção, usamos o RMAN para controlar tudo, ou seja, fazemos um outro script que faça o crosscheck de todos os BS’s e aqueles que ultrapassam os 7 dias por exemplo, são excluídos. Isso o RMAN faz.

Agora, se não tem a opção de espaço em disco suficiente para armazenar os 7 dias, então, adotamos a seguinte estratégia, todos os dias, um AGENTE de backup que grava para fita apaga do disco o arquivo que foi copiado, isso diariamente, deixando a pasta de backup com espaço para os próximos backups.

Mas e a janela de retenção?

Bom, quando ocorrer uma catástrofe que precise dos últimos 7 dias de backup, isso pode ocorrer com operações de BMR (Block Media REcovry), então, você pode adotar 2 estratégias:

1) Alocar no servidor mais discos para realizar a operação, restaurar via AGENTE todos os BS dos últimos 7 dias, catalogar novamente todos os BS’s de maneira que fiquem disponíveis ao RMAN e realizar as operações necessárias.

2) Trabalhar com o espaço que já existe, ou seja, analisar quais os BS’s serão necessários para a sua recuperação com precisão, de archives para archives de backupset para backupset e restaurar só os necessários, para isso também deverá fazer um CROSSCHECK BACKUP OF DATABASE e depois um CROSSCHECK BACKUP OF ARCHIVELOG ALL para disponibilizar ao RMAN e ele validar a sequencia necessária.

Outras dúvidas podem surgir:

2.1) Mas se os BS que eu precisar, o espaço em disco não é o suficiente?

Bom, aí teremos que avaliar o disco que está despejando o seu backup e ver o que mais ocupa espaço nele e avaliar o ambiente por completo, se existe datafiles no mesmo disco de backup, então faça o MOVE deles para outro disco. Apague arquivos desnecessários, traces e logs. E realoque para outro lugar.

2.2) Mas mesmo assim, não tem espaço?

Aí comela a ficar mais legal, pois então irá fazer o RMAN primeiramente ler os BS’s mais antigos e forçar o SCN ou Log sequence chegar o mais perto do que você precisa, até chegar um ponto do RECOVER que ele irá pedir uma SEQUENCIA ou SCN que não esteja disponível, saia da operação do recover sem tentar abrir o banco nem nada, apague os BS’s antigos e restaures os superiores a ele até deixar o banco com o LOG SEQUENCE ou SCN igual ao control file para abrir o banco de dados.

Tudo isso é a forma de garantir uma estratágia de recuperação baseado no seu retention policy que está configurado. Se está usando a retenção baseada em REDUNDANCY, creio que tudo isso não será o suficiente pois, ele irá basear nos seus backups, ou seja, independente se é FULL, HOT, nível 1,2,3 e assim seja.

Abraços,

[Rodrigo AlmeidaParticipante]

Uma observação ao contéudo.

Sobre os agentes de backup, é interessante saber que muitos produtos, como CA ArcServer, NetBackup, OmniBack, SBS e etc, os seus agentes são baseados no RMAN, ou seja, o agente nada mais é que scripts próprios das empresas customizados para trabalhar com a ferramenta do mesmo, usa scripts de RMAN (geralmente) configurados para usar uma SBT, para realizar o processo de cópia. Isso quando está se trabalhando com os agentes de backup para banco de dados.

Caso contrário, são comandos de SO que utilizam as libs proprietarias para mandar os arquivos para FITA.

Era só uma observação.

Abraços,[/b]

[Autor]

Posts