ZDLRA and the FRA
I often get questions around the FRA (Flash Recovery Area), and how it should be used when moving backups to the ZDLRA.
First though, the recommendation is to ALWAYS set your db_recovery_file_dest_size to be 10% less than the amount of space available, and don't put other files in this same location (that are not managed as part of the FRA).
Having a 10% buffer ensures that you can increase the available storage if necessary. For those experienced on-call DBA's I'm sure there have been times where increasing the db_recovery_file_dest_size by that last 10% was used to keep the database running while space was cleaned up.. And of course this is often at 3:00 AM when the dreaded "archive log destination full" alert comes across.
First let's go through what's in the FRA and how it's being used.
There is a lot of information in MOS and I will include pertinent MOS notes at the end of this post.
What's in the FRA (V$FLASH_RECOVERY_AREA_USAGE shows us )?
Here is a sample output
SQL> Select file_type, percent_space_used as used,
percent_space_reclaimable as reclaimable,
number_of_files as "number" from v$flash_recovery_area_usage;
FILE_TYPE USED RECLAIMABLE number
------------ ---------- ----------- ----------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 4.77 0 2
BACKUPPIECE 56.80 0 10
IMAGECOPY 0 0 0
FLASHBACKLOG 11.68 11.49 63
From this you can see the following items are in the FRA.
CONTROLFILE -- This comes from setting the location of the CONTROLFILE backup.
configure controlfile autobackup on;
If you configure controlfile backups using the 'FORMAT" option, it will not be managed by the FRA.
ONLINELOG
A copy of the online redo logs go to the FRA when the DB_RECOVERY_FILE_DEST is set and the DB_CREATE_ONLINE_LOG_DEST_n is not set.
ARCHIVELOG --
Archive logs are managed by the FRA when the archive LOG_ARCHIVE_DEST_n parameter contains the clause 'LOCATION=USE_DB_RECOVERY_FILE_DEST'
alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'';
BACKUPPIECE or IMAGECOPY
RMAN backups are managed by the FRA when you configure RMAN to (or explicitly) send backups to disk AND the FORMAT option is not specified.FLASHBACKLOG
If flashback database is turned on for the database, flashback logs will be kept in the FRA automatically. The database parameter db_flashback_retention_target is set to determine the amount of flashback logs that are kept for the database.
Now let's take a look at how space is managed for each piece
ONLINELOG -- Since online redo logs are necessary for the database, this is not affected with space pressure.
BACKUPPIECE or IMAGECOPY and/or CONTROLFILE and ARCHIVELOG -- these are managed by the setting in RMAN for the retention policy.
The recommendation for the ZDLRA (when using real-time redo apply) is to set this parameter to
CONFIGURE ARCHIVELOG RETENTION POLICY SHIPPED to all STANDBY;
NOTE - This policy marks archive logs as "reclaimable" as soon as they are considered shipped to ALL standby databases. If the ZDLRA is the only external destination, then as soon as it's received on the ZDLRA, it is "reclaimable". If you have Dataguard along with ZDLRA, then archive logs are considered "reclaimable" as soon as they are received by both.
OR
CONFIGURE ARCHIVELOG RETENTION POLICY APPLIED on all STANDBY;
NOTE - This policy marks archive logs as "reclaimable" as soon as they are considered APPLIED on ALL standby databases. If the ZDLRA is the only external destination, then as soon as it's received on the ZDLRA AND has been cataloged, it is "reclaimable". This takes less than a minute, and occurs independent of the protected database. If you have Dataguard along with ZDLRA, then archive logs are considered "reclaimable" as soon as they are applied by both.
*** Note that "APPLIED" is the most desirable because this ensures that the log is not removed until it "processed" by all destinations, HOWEVER, if you have a standby location that has a gap in apply then you need to consider "SHIPPED".
Both Policies will work, but it depends on your configuration.
The recommendation for the ZDLRA (when using log sweeps) is to set this parameter to
CONFIGURE ARCHIVELOG RETENTION POLICY xx backed up 1 times device type SBT;
Where XXX is
1) not used if there is no Dataguard or other destinations beyond local disk for archive logs.
2) "SHIPPED to all STANDBY" if Dataguard or Golden Gate is used.
3) "APPLIED" on all STANDBY if Dataguard or Golden Gate is used.
Where XXX is
1) not used if there is no Dataguard or other destinations beyond local disk for archive logs.
2) "SHIPPED to all STANDBY" if Dataguard or Golden Gate is used.
3) "APPLIED" on all STANDBY if Dataguard or Golden Gate is used.
Now let's take a look at how space is managed (315098.1)
There is a MOS note on this, but it there are still some misconceptions on what you see happening.
Looking at the output of view V$RECOVERY_FILE_DEST you will see 3 pertinent columns.
SPACE_LIMIT ==> this is the amount of space that is allocated to the FRA.
SPACE_USED ==> This is the amount of space currently used
SPACE_RECLAIMABLE ==> This is the amount space that the FRA considers reclaimable.
** This NOT the total amount space reclaimable, just the amount
that the FRA knows about (I'll get to what this means soon).
The note says that
If the free space becomes less then 15% in the Flash Recovery Area then all the archivelogs in the Flash Recovery Area which are not needed for recovery by the current backups in the FRA will become obsolete and the space occupied will be shown in the SPACE RECLAIMABLE column of V$RECOVERY_FILE_DEST.
From this I made some assumptions that were incorrect.
I assumed
1) Since I was immediately sending all backups and archive logs to the ZDLRA (Real Time Apply), the space for the ARCHIVELOG would all show up in the SPACE_RECLAIMABLE column.
2) When the FRA reaches 85%, it would automatically clean up ARCHIVELOGS to bring it down to 85%.
Both of these assumptions were wrong. By testing I found that this is what actually happens, and this still falls within the verbiage in that note.
This is what happens as the space fills up.
For my example I have a 1 TB FRA.
For my example I have a 1 TB FRA.
849 GB used in the FRA. The reclaimable space is NOT calculated yet because we have not hit the 85% full mark.
Space_limit 1000GB
Space_used 849GB
Space_reclaimable 0GB
At 850GB I reached 85% full. This is the point where the database calculates SPACE_RECLAIMABLE. Note that it does not fully calculate what's reclaimable, it only finds a portion of the reclaimable space.
Space_limit 1000GB
Space_used 850GB
Space_reclaimable 300GB
At 999GB it's not quite full. The reclaimable space shows there is space available,
but it still only finds a portion of the available space.
Space_limit 1000GB
Space_used 999GB
Space_reclaimable 300GB
At 1000GB it is completely full. The reclaimable space shows space available to be reclaimed.
At this point I can see in the alert log that archive logs are being removed.
Only enough logs are removed to make space for new logs. it remains at 99% used.
Space_limit 1000GB
Space_used 999GB
Space_reclaimable 160GB
As I added more logs, it remained at 99% used.
This makes it very difficult to know how much space you have available in your FRA.
The warnings start occurring at the 85% full mark.
Since the FRA recalculates the SPACE_RECLAIMABLE at 85% full, but only adjusts it to keep from warning,
it is impossible to tell how much TOTAL space is reclaimable.
Using the formula
SPACE_LIMIT - SPACE_RECLAIMABLE
Does not give you amount of space that is actually reclaimable.
It is only useful to tell you when the amount of unreclaimable space > 85%.
Here are the useful MOS notes.
NOTE:305817.1 - FAQ - Flash Recovery Area feature
How is the space pressure managed in the Flash Recovery Area - An Example. (Doc ID 315098.1)Correctly configuring the Flash Recovery Area to allow the release of reclaimable space (Doc ID 316074.1) |
No comments:
Post a Comment