Menu de navegação

[vieriParticipante]

Caros,

estou querendo manter apenas 3 dias
de backup com RMAN, que são “backupeados” (usando catalogo),
no meu server de backup diariamente.

Qual a melhor maneira de fazer isso , sem comprometer
a intgridade das informações no catalogo do rman.

Estou pensando em algo do tipo

script backup;
database.
archive.
controlfile.
…..

E no fim do shell.

crosscheck backup;
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
delete noprompt obsolete;

com isso eu consigo manter somente os 3 dias com meu catalogo
integro e sem erros no backup.

Pode ser que funcione mas acho que alguem já tem
alguma boa prática por ai..

[]s

delete obsolete;

[Regis AraujoParticipante]

Fala Vieri..

Entao..

Basta vc configurar o parametro de retention policy para 3 dias.. Não precisa rodar ele todas as vezes q vc gerar o backup.

Quando vc seta ele para 3.. ele fica armazenado esta configuração..

configure retention policy to recovery window of X days;

O comando que vc passou.. “CONFIGURE RETENTION POLICY TO REDUNDANCY 3; ” define quantos backups o oracle pode deixar para recuperação..

Abraços..

[vieriParticipante]

Thunder_Catz,

posso estar errado mas apenas setar essa config não
apaga meus backup’s apenas marcar ele no catalogo
como obsoleto.
Os BS’s continuam no disco.

teria que fazer o delete obsolete, ou algo do genêro.

🙄

[Marcos BragaParticipante]

Oi Vieri,

Uma mescla das duas respostas, creio ser a mais acertada. Utilize o método do Thunder_Catz para definir a configuração e como você disse, somente definí-la uma vez basta, fica gravada.

[]s
Braga

[CleitonHanzenParticipante]

Opá….

Fala vieri, blz?

Bom, eu iria na recomendação do Thunder (configure a retention policy baseada em DIAS, não utilize baseado em REDUNDANCY, já tive problemas com a retention policy baseada em REDUNDANCY)..

Após salvar a config (seja para o controlfile ou seja para o catálogo do RMAN), basta vc fazer o crosscheck e depois fazer o delete obsolete….

[]s

[vieriParticipante]

Perfeito basta configurar.. até ai tranquilo.

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 4;

old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 4;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete

Ia colocar no script apenas para garantir… pq outra pessoas colocam a mão na base.

Minha dúvida é como montar o expurgo.

setar essa configuração não paga os antigos, marcar eles no catalogo
como “expired” e “obsolet”…

[Marcos BragaParticipante]

Oi Vieri,

Observe o que o Thunder_Catz falou na primeira mensagem. A opção REDUNDANCY define quantas cópias do backup serão guardadas no host para uma possível recuperação.

Você tem que definir a RETENTION; essa sim define quantos dias os backups ficarão guardados no host.

Resumindo:
REDUNDANCY = quantidade de cópias do backup;
RETENTION = quantidades de dias do backup.

Creio que é bom esclarecer bem esses conceitos para não se enganar no momento de definir os parâmetros.

[]s
Braga

[vieriParticipante]

Beleza incluir as 2 config’s e vou incluir os
dois comandos abaixo no fim do script de bkp.

crosscheck backup ;
delete noprompt obsolete ;

Vamos ver se vai funcionar mais eu acho que o policy não é tão simples assim, como qtas copias e qtos dias e tudo vai acontecer que é uma maravilha existem outras particularidade e depêndencias.

 My Oracle Support (the new MetaLink)   Bookmarks   Admin   Profile   Feedback   Sign Out   Help   

Headlines   Knowledge    Service Request   Collector   Patches & Updates   Community   Certify  

Knowledge Browser Advanced Search Bug Search

Quick Find
All Sources Knowledge Base Knowledge Base (Including Archived Articles) Bug Database Technical Forums Document ID (Knowledge Base, Forum, or Bug) Service Request Number Error Code Patch Number Go
Advanced Saved Searches

Did this article help solve your problem? Select Yes No Does Not Apply Would you recommend this document to others? Select Yes No Not Sure

TIP: Click help for a detailed explanation of this page.
Bookmark Go to End

Subject: Frequently asked questions on Rman backup retention policy
Doc ID: 463875.1 Type: FAQ
Modified Date : 01-SEP-2008 Status: PUBLISHED

In this Document
Purpose
Questions and Answers
How do we Set A Retention Policy For Tape Backups And Disk Backups Differently?
How does the RMAN Retention Policy Obsolete Incremental Backupsets ?
How can we have different retention policies for different backups ?
Why do the backups do not become obsolete even if they are out of retention policy ?
What is the recommended retention policy for incremental merge backups ?
Neither list backup or report/delete obsolete display the obsolete backup pieces. But the backup pieces are very much available on the disk.
References

---

Applies to:
Oracle Server – Enterprise Edition – Version: 9.0.1.4 to 11.1.0.6
Information in this document applies to any platform.

Purpose
This note summarizes the frequently asked questions on Rman backup retention policy.
Questions and Answers
How do we Set A Retention Policy For Tape Backups And Disk Backups Differently?
For example, setting the tape retention policy to 14 days while setting it to 3 days for the disk backups

Step 1: Set the retention policy.

RMAN currently only allows one retention policy. The retention policy should be set to 14 days.
RMAN> configure retention policy to recovery window of 14 days;

Step 2: Move the backups from disk to tape to meet the specified disk retention policy. This must be done manually.

The following command will move the backups from disk to tape and delete the original backup copy from disk.

RMAN> backup device type sbt backupset completed before ‘sysdate-2’ delete input;

The time specified may be changed depending which backupsets will be moved to tape and deleted from disk. The retention policy guarantees that the backups will not be marked as obsolete unless they meet the specified retention policy.

How does the RMAN Retention Policy Obsolete Incremental Backupsets ?

The report/delete obsolete commands works in two steps.

First, we identify the oldest full backup (i.e. full or level 0 backupset, or image copy) of every file that is not obsolete, as defined by the retention policy (either REDUNDANCY or RECOVERY WINDOW). Every older full backup is obsolete.

Then, all archived logs and level > 0 incremental backups that are older than the oldest non-obsolete full backup are also considered to be obsolete, because there is no longer any full backup to which they could possibly apply.

Note that a level > 0 backup performs much the same function as an archived log – it causes a full backup to move forward in time, so those backups are treated in the same manner as archived logs for the purposes of retention. Incremental backups are not restored using the restore command, they are restored using the recover command if it will cause fewer archive logs to be needed during recovery. When you restore it is always only from full or level 0 incremental backups of
the datafiles.

How can we have different retention policies for different backups ?

We cannot have different retention policies for different backups . The retention policy is always same for all backups .

But there could be situations where you would be looking for different kind of retention policies.Such kind of a situation is explained below.

EXAMPLE

QUESTION

There are 3 types of backup , daily , weekly and monthly, so we would like to have 3 retention policies 1 for retention of 32 days, 2 for retention of 365 days and other for 700 days for example

ANSWER

For all your daily backups maintain a normal retention policy i.e

Rman > configure retention policy for recovery window of 32 days ;

This retention policy is always common for all backups . But since you have to retain the weekly backups for 365 days and monthly backups for 700 days .

Therefore for the weekly and monthly backups we will be going for ” KEEP ” option .

You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command
when you create the backup, or the KEEP option of the CHANGE command to exempt an existing backup.
Note that backups exempted from the retention policy are still fully valid backups, which can be
used in restore and recovery operations like any other if RMAN judges them to be the best choice
available.

You can change the exempt status of a backup using the CHANGE… KEEP and CHANGE… NOKEEP
commands. The NOKEEP option (default) indicates that the backup is not immune from the configured
retention policy.

You can specify the LOGS option to save archived logs for a possible incomplete recovery of the
long-term backup. When LOGS is specified, all logs more recent than the backup are kept as long as
the backup is kept. In other words, KEEP UNTIL TIME… LOGS means that RMAN will keep all logs
required to recover the backup as long as the backup is kept. If you specify NOLOGS, then RMAN
does not keep the logs required to recover the backup. Note that if you use KEEP UNTIL TIME…
with an inconsistent backup, you must use the LOGS option, or that backup will become unusable
when the logs required to recover it are deleted as obsolete. In fact rman does not allow us to take a inconsistent backup with KEEP NOLOGS option.

You can specify an end date using the UNTIL clause, or either specify that the backup should be
kept FOREVER. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the
UNTIL date has passed. Note that it is an error to specify KEEP FOREVER with the LOGS option, as
this would require keeping all redo logs forever.

EXAMPLE:

• For weekly and monthly backups you can take the backups in this way :

Rman > BACKUP DATABASE KEEP UNTIL TIME “TO_DATE(’31-DEC-2007′ ‘dd-mon-yyyy’)” NOLOGS;

OR

Rman > BACKUP DATABASE KEEP UNTIL TIME ‘sysdate +365’ NOLOGS;

Specify the until time as needed depending upon whether the backup is weekly or monthly .

For the rest of your daily backups you can have the normal retention policy of 32 days .

Why do the backups do not become obsolete even if they are out of retention policy ?

We can have different conditions due which the backups would not become obsolete. They are :

1) There is an offline datafile in the database because of which the all the archivelogs or the archivelog backups needed to recover the datafile will not become obsolete.

2) The archivelog/archivelog backups do not become obsolete, if there are no full backups of the datafiles.

3) The backups were done with KEEP option.

4) If the above conditions do not satisfy , then there could be a bug due to which the backups are not becoming obsolete.

What is the recommended retention policy for incremental merge backups ?

To implement the retention policy for the incremental merge backups, please use the following guidelines.

• Retain the default retention policy to redundancy 1. This enables all the incremental backups to become obsolete as soon as they are applied to the copy.

• To implement the retention policy based on recovery window,do not use the CONFIGURE command.Instead use the UNTIL CLAUSE in the RECOVER COMMAND.

Example

run {
allocate channel oem_disk_backup device type disk;
RECOVER COPY OF DATABASE with tag ‘ORA$OEM_LEVEL_0 until time ‘sysdate-8’ ‘;
backup incremental level 1 cumulative copies=1 for recover of copy with tag ‘ORA$OEM_LEVEL_0’ database;
}

NOTE

For incremental merge backups,please ensure that the retention policy is retained to its default value of redundancy 1.However if you want to configure retention policy based on recovery window of n days , then ensure that you include the UNTIL TIME clause in the RECOVER command to ‘sysdate-(n+1)’.

Neither list backup or report/delete obsolete display the obsolete backup pieces. But the backup pieces are very much available on the disk.

It is possible that the information about these backups are removed/overwritten in the controlfile.
To prevent this ensure the control_file_record_keep_time initialization parameter value is set to a value higher than the retention policy of recovery window OR consider using a recovery catalog.

References
Note 206862.1 – How does the RMAN Retention Policy Obsolete Incremenatal Backupsets
Note 351455.1 – Oracle Suggested Strategy & Backup Retention
Note 434345.1 – How Do I Set A Retention Policy For Tape Backups And Disk Backups Differently?
Note 452529.1 – Recovery catalog for RMAN backup
Note 462978.1 – Rman backup retention policy

Keywords

RETENTION ; RECOVERY~CATALOG ; CONTROL_FILE_RECORD_KEEP_TIME ; POLICY ; RMAN ;

Help us improve our service. Please email us your comments for this document. .

My Oracle Support (the new MetaLink) Bookmarks Admin Profile Feedback Sign Out Help

Copyright © 2006, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement

[Regis AraujoParticipante]

Fala Vieri…

Então.. a quantidade de arquivos vai depender de quantos backups vc gera por dia.. vamos la.. aqui criei uma politica de backup assim..

DIAS VÁLIDOS = 3
BAKCUP NIVEL 0 = 2 /DIA
BACKUP NIVEL 1,2,3,4 = 6 /DIA
TOTAL ARQUIVOS DIA = 8

ARQUIVOS X DIA = 16

Então configurei para 3 dias e 16 arquivos.. assim eu terei os arquivos validos dos 3 dias… Bom.. esta é a maneira q eu entendi o REDUNDANCY e o RETENTION e no script de RUN eu fiz assim.

run {
crosscheck backupset;
crosscheck archivelog all;
execute script NOME_DO_SCRIPT;
Delete noprompt expired backup;
Delete noprompt expired archivelog all;
Delete noprompt archivelog all completed before ‘sysdate-3’;
Delete noprompt obsolete;
}

OBS.: Eu criei scripts para cada tipo de backup e já deixei gravado no catalogo.. quando preciso rodar algum eu insito o nome do script no RUN apenas…

Eu não sou expert em RMAN.. estou aprendendo ainda..!!

Abraços..

Abraços….

[vieriParticipante]

É mais ou menos por ai, que estava procurando!
agora ta nota 10 valeu regis !!

crosscheck backupset;
crosscheck archivelog all;

meu script…

Delete noprompt expired backup;
Delete noprompt expired archivelog all;
Delete noprompt archivelog all completed before ‘sysdate-3’; — este não vai precisar… eu uso o delete all input após a o bkp dos archives.
Delete noprompt obsolete;

Só não entendo porque vc criou uma politíca de backup
com um dois nivel 0 por dia e diversos niveis 1,2,3,4.
Bastaria um Full por dia, em que situações de restore/recover essa
política iria te favorecer?
se for durante a semana tudo bem,

seg=nivel0 ter=nivel1 quar=nivel2 quint=nivel3 sext=nivel2
sab=nivel1

Não gosto muito do backup incremental, porque vc fica sempre dependente do nivel 0, se ele falhar já era.

Mas em fim talvez por não gostar não tenha adquirido conhecimento para customizar legal, por isso utilizo o backup full +archive+cTL -file padrão

[Regis AraujoParticipante]

Opa..

Então.. é backup cumulativo.. pois eu gero um full (nivel 0) a cada 12 hras.. e depois vou gerando só as alterações que ocorreram desde o ultimo backup gerado…

Pois preciso ter sempre um backup atualizado com no máximo 3 hras… E ficar gerando a cada 3 hras um backup full eh complicado por falta de espaço..

Abraços..

[vieriParticipante]

Shiii imaginei que fosse por espaço em Disco !!

Então ta explicado já que o incremental copia apenas os blocos alterados.

Exigente o pessoal ai hein, backup de 3 em 3 hrs com pouco espaço em disco.. ainda bem que o rman é flexivel.

[]s

[Regis AraujoParticipante]

Opa..

Exigente e muito.. Nossas bases de dados são atualizadas constantemente.. coisa de minutos haver atualizações em milhares de registros.. então a politica de backup/recovery é bem critica.. Perder 1 dia de produção é muito arriscado….!!

Abraços..!

[Regis AraujoParticipante]

Caraca.. preciso voltar as aulas de tabuada…

3x 1 = 3
3x 2 = 6
3x 3 = 9
3x 4 = 12
3x 5 = 15
3x 6 = 18
3x 7 = 21
3x 8 = 24
3x 9 = 27
3×10 = 30

Onde q 3×8 é 16… hunf..!! hauhauhua..!! Acontece.. (mas não era para acontecer)

[quote=”Thunder_Catz”:1h6kf8z3]Fala Vieri…

DIAS VÁLIDOS = 3
BAKCUP NIVEL 0 = 2 /DIA
BACKUP NIVEL 1,2,3,4 = 6 /DIA
TOTAL ARQUIVOS DIA = 8

ARQUIVOS X DIA = 16

[/quote][/b]

[Rodrigo AlmeidaParticipante]

Olha eu de intrometido! Bom, vou tentar resumir aqui e contribuir.

Vieri,

Tu deseja eliminar os seus BSs do catalogo do RMAN ou eliminar o arquivos físico dos BSs do disco?

E tome cuidado, não DEIXE no RMAN configurado REDUNDANCY e RETENTION POLICY juntos! Isso em recover dá N problemas. Opte por utilizar RETENTION POLICY ou REDUNDANCY.

Sugestão!

Sou da mesma opinião dos demais, utilize RETENTION POLICY OF x DAYS. è muito melhor que redundancy. Pois no REDUNDANCY independendo do seu backup, cada backup feito é considerado 1, se pegar o exemplo do REgis, ele iria estourar esse limite em 1 dia.

Thunder_Cats (Regis),

Utilizo em minhas políticas de backup o uso de incrementais, nível 0 (horário de menor movimento da base) e 1,2,3 (Diferenciais) durante o dia, em 3 em 3 horas.

Também sugiro utilizar o BCT (Block Change Tracking) para aumentar a performance dos seus backups incremetais. Isso não gera problemas, somente um espaço em disco será necessário.

Voltando ao VIERI!

Se deseja eliminar os BSs do disco, o RMAN não faz isso!

Só dá para eliminar os BS com o RMAN se utilizar o comando HOST em conjunto com RM e o caminho desejado! Aí o RMAN apaga mesmo.

Caso contrário, deverá pedir para o Agente (ArcServer, Netbackup, Tivoli e etc) para fazer isso depois que copiar para fita!

Abraços,

[Autor]

Posts