RMAN Recovery Window Retention Policy :
Assume, in RMAN the recovery window is set like below.
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAY;
For, each data file, there must always exist at least one backup that satisfies the following condition:
SYSDATE-backup_checkpoint_time >= recovery_window
This condition get always satisfied when the backup get older than 5 days, according to above concept.
let us disscuss clearly. The Recovery Manager (RMAN) provides the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy for controlling how long backups and copies should be retained. When a backup retention policy is in effect, RMAN considers the backups and copies of data files and control files as obsolete (i.e., the backups and copies are no longer needed for media recovery), according to the criteria specified in the CONFIGURE RETENTION POLICY command. The REPORT OBSOLETE and DELETE OBSOLETE commands can be executed periodically or regularly to view obsolete files and to delete them, respectively.
so when a recovery window of five days is implemented, the window of time must extend back exactly five days from the present, so that a backup can be restored and recovered to this point. This retention policy can be implemented by executing the following RMAN command:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS;
Executing the above command ensures that for each data file, one backup that is older than the point of recoverability must be retained. For example, if the recovery window is five, there must always exist one backup of each data file that satisfies the following condition:
SYSDATE – (SELECT CHECKPOINT_TIME FROM V$DATAFILE) >= 5
All backups older than the most recent backup that satisfies the above condition are obsolete. The recovery window always keeps pace with the current time. For example, if the current day is March 12 and the recovery window is five days, then the recovery window stretches between May 7 and May 12.
Backup Redundancy Vs Recovery Window:
Backup Redundancy:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
A redundancy-based retention policy specifies how many backups of each datafile must be retained.
Recovery Window:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability, that is, the earliest point to which you can recover following a media failure.
You can remove backup entries that are marked as expired using the RMAN command delete expired.
It is always important to have backups of the database. In the same manner, it is also important to delete those backups which are no longer required for the recovery. RMAN makes the identification of these backups very easy using retention policy, which governs which backups are safe to be deleted.
Using retention policy, backups are marked as obsolete, which means not required anymore. There are two possible settings for retention policy:
Redundancy stands for the number of copies that must be available. Once you have the chosen number of backup copies, any older backups are marked as obsolete. This does not put any sort of restriction on how long the backups can be kept. This kind of setting works best for environments where, depending on the SLA (service level agreement), some specified number of backup copies must be kept. By default, this is the setting on which RMAN works, using only the most current backup copy. Depending on the requirement, the number of copies can be changed using the configure command like the following:
RMAN> configure retention policy to redundancy 2;
In the above example, the redundancy has been set to two. This means that if you take two backups of your database now, the oldest copy of the backup would be marked as obsolete.
The other setting, recovery window, is not based on the number of backup copies, but on the number of days for which you want to keep the backup. This does not put any condition on the number of backup copies that can be retained; you can have n number of copies within the specified period of the recovery window. Any backup that is older than the recovery window is marked as obsolete.
In the recovery window, Oracle checks the current backup and looks for its relevance backwards in time. This is a default set to seven days which means that the backup must be kept for exactly seven days, ensuring that you can use it for the recovery within any point of time for this time period. Any file which does not come in this range of n days would require a backup to be done for it and the same would be reported from RMAN as well. To illustrate the above, look at a hypothetical situation where the backup is done after every week and the recovery window is also set for seven days, its default value.
You can see here that the backup is taken every seventh day. Now assume that you started on July 1st and have taken backups on the 8th, 15th, 22nd and 29th of July. Assuming the current date is the 25th of July, according to the recovery window of seven days, the point of recoverability goes up to the 18th of July. This means that to ensure the recoverability, the backup taken on 15th will be kept by Oracle so that you can recover up to that point.
Remember: To be able to recover to the 18th with a database backup of the 15th, subsequent archived redo logs from the 15th to the 18th are required. One interesting part of this type of retention policysetting is that it is not mandatory for RMAN to keep the backup only for the mentioned number of days. If you have taken the last level 0 backup and the time period of that exceeds the recovery window timing, Oracle would have to ensure that it is not marked as obsolete because just using the level 1 backup will not guarantee the complete recovery.
The default retention policy is set to a redundancy of 1. You can change it from its default value by using the configure command. Note that both redundancy and recovery window retention policies are mutually exclusive. Now see what retention policy your database is set to. You can use the show retention policy command for this:
RMAN> show retention policy;
RMAN configuration parameters are:
configure retention policy to redundancy 1;
So you have the retention policy set to redundancy 1. Change it to the recovery window of seven days:
RMAN> configure retention policy to recovery window of 7 days;
old RMAN configuration parameters:
RMAN> configure retention policy to redundancy 1;
new RMAN configuration parameters:
configure retention policy to recovery window of 7 days;
new RMAN configuration parameters are successfully stored. So now you have the retention policy set to seven days of the recovery window. In case you want to disable the retention policy for some reason, you can even do that. Here is how.
RMAN> configure retention policy to none;
This would disable the retention policy settings. However, doing so would stop the report obsolete and delete obsolete commands from marking any of your previously done backups as obsolete.
Recovery window and incremental backups:
Let's say you specify a recovery window of 7 days. That means rman will not obsolete any backup needed for recovery to any point in the last seven days. Check. But what's the subtle detail?
Suppose you take a full backup on 1 Sep, then start taking incremental backups going forward. Now we're down to 10 Sep which puts that full backup 3 days earlier than the recovery window. However, it is still the most recent full backup and so is needed to recover into any time during the 7 day recovery window. Therefore, it will NOT be marked obsolete.
Think about what this does in the textbook backup routine of a full backup every 7 days, with incremental backups the other 6 days. We take a full backup on day 1. We take incremental backups on days 2 - 7. We take a full backup again on Day 8, and incrementals on days 9 - 14.
Day = 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Bkup = F I I I I I I F I I I I I I
On day 14, our recovery window reaches back to day 7, and the only way to recover to day 7 is to use the full backup from day 1 and the incrementals from 2 through 7. So even though we have a 7 day recovery window, we actually have 14 days worth of backups that are yet to go obsolete. On day 15, we can obsolete and drop everything prior to the full backup on Day 8.
I think it will help to understandable.
Assume, in RMAN the recovery window is set like below.
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAY;
For, each data file, there must always exist at least one backup that satisfies the following condition:
SYSDATE-backup_checkpoint_time >= recovery_window
This condition get always satisfied when the backup get older than 5 days, according to above concept.
let us disscuss clearly. The Recovery Manager (RMAN) provides the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy for controlling how long backups and copies should be retained. When a backup retention policy is in effect, RMAN considers the backups and copies of data files and control files as obsolete (i.e., the backups and copies are no longer needed for media recovery), according to the criteria specified in the CONFIGURE RETENTION POLICY command. The REPORT OBSOLETE and DELETE OBSOLETE commands can be executed periodically or regularly to view obsolete files and to delete them, respectively.
so when a recovery window of five days is implemented, the window of time must extend back exactly five days from the present, so that a backup can be restored and recovered to this point. This retention policy can be implemented by executing the following RMAN command:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS;
Executing the above command ensures that for each data file, one backup that is older than the point of recoverability must be retained. For example, if the recovery window is five, there must always exist one backup of each data file that satisfies the following condition:
SYSDATE – (SELECT CHECKPOINT_TIME FROM V$DATAFILE) >= 5
All backups older than the most recent backup that satisfies the above condition are obsolete. The recovery window always keeps pace with the current time. For example, if the current day is March 12 and the recovery window is five days, then the recovery window stretches between May 7 and May 12.
Backup Redundancy Vs Recovery Window:
Backup Redundancy:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
A redundancy-based retention policy specifies how many backups of each datafile must be retained.
Recovery Window:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability, that is, the earliest point to which you can recover following a media failure.
You can remove backup entries that are marked as expired using the RMAN command delete expired.
It is always important to have backups of the database. In the same manner, it is also important to delete those backups which are no longer required for the recovery. RMAN makes the identification of these backups very easy using retention policy, which governs which backups are safe to be deleted.
Using retention policy, backups are marked as obsolete, which means not required anymore. There are two possible settings for retention policy:
- Redundancy
- Recovery window
Redundancy stands for the number of copies that must be available. Once you have the chosen number of backup copies, any older backups are marked as obsolete. This does not put any sort of restriction on how long the backups can be kept. This kind of setting works best for environments where, depending on the SLA (service level agreement), some specified number of backup copies must be kept. By default, this is the setting on which RMAN works, using only the most current backup copy. Depending on the requirement, the number of copies can be changed using the configure command like the following:
RMAN> configure retention policy to redundancy 2;
In the above example, the redundancy has been set to two. This means that if you take two backups of your database now, the oldest copy of the backup would be marked as obsolete.
The other setting, recovery window, is not based on the number of backup copies, but on the number of days for which you want to keep the backup. This does not put any condition on the number of backup copies that can be retained; you can have n number of copies within the specified period of the recovery window. Any backup that is older than the recovery window is marked as obsolete.
In the recovery window, Oracle checks the current backup and looks for its relevance backwards in time. This is a default set to seven days which means that the backup must be kept for exactly seven days, ensuring that you can use it for the recovery within any point of time for this time period. Any file which does not come in this range of n days would require a backup to be done for it and the same would be reported from RMAN as well. To illustrate the above, look at a hypothetical situation where the backup is done after every week and the recovery window is also set for seven days, its default value.
You can see here that the backup is taken every seventh day. Now assume that you started on July 1st and have taken backups on the 8th, 15th, 22nd and 29th of July. Assuming the current date is the 25th of July, according to the recovery window of seven days, the point of recoverability goes up to the 18th of July. This means that to ensure the recoverability, the backup taken on 15th will be kept by Oracle so that you can recover up to that point.
Remember: To be able to recover to the 18th with a database backup of the 15th, subsequent archived redo logs from the 15th to the 18th are required. One interesting part of this type of retention policysetting is that it is not mandatory for RMAN to keep the backup only for the mentioned number of days. If you have taken the last level 0 backup and the time period of that exceeds the recovery window timing, Oracle would have to ensure that it is not marked as obsolete because just using the level 1 backup will not guarantee the complete recovery.
The default retention policy is set to a redundancy of 1. You can change it from its default value by using the configure command. Note that both redundancy and recovery window retention policies are mutually exclusive. Now see what retention policy your database is set to. You can use the show retention policy command for this:
RMAN> show retention policy;
RMAN configuration parameters are:
configure retention policy to redundancy 1;
So you have the retention policy set to redundancy 1. Change it to the recovery window of seven days:
RMAN> configure retention policy to recovery window of 7 days;
old RMAN configuration parameters:
RMAN> configure retention policy to redundancy 1;
new RMAN configuration parameters:
configure retention policy to recovery window of 7 days;
new RMAN configuration parameters are successfully stored. So now you have the retention policy set to seven days of the recovery window. In case you want to disable the retention policy for some reason, you can even do that. Here is how.
RMAN> configure retention policy to none;
This would disable the retention policy settings. However, doing so would stop the report obsolete and delete obsolete commands from marking any of your previously done backups as obsolete.
Recovery window and incremental backups:
Let's say you specify a recovery window of 7 days. That means rman will not obsolete any backup needed for recovery to any point in the last seven days. Check. But what's the subtle detail?
Suppose you take a full backup on 1 Sep, then start taking incremental backups going forward. Now we're down to 10 Sep which puts that full backup 3 days earlier than the recovery window. However, it is still the most recent full backup and so is needed to recover into any time during the 7 day recovery window. Therefore, it will NOT be marked obsolete.
Think about what this does in the textbook backup routine of a full backup every 7 days, with incremental backups the other 6 days. We take a full backup on day 1. We take incremental backups on days 2 - 7. We take a full backup again on Day 8, and incrementals on days 9 - 14.
Day = 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Bkup = F I I I I I I F I I I I I I
On day 14, our recovery window reaches back to day 7, and the only way to recover to day 7 is to use the full backup from day 1 and the incrementals from 2 through 7. So even though we have a 7 day recovery window, we actually have 14 days worth of backups that are yet to go obsolete. On day 15, we can obsolete and drop everything prior to the full backup on Day 8.
I think it will help to understandable.
No comments:
Post a Comment