Managing Space - Recovery Appliance / ZDLRA / RA - 2 of 6 - Purge Rules

In this Second Part of a series of blogs on ZDLRA/RA backup storage/space, I am going to share some of my insights into Purging Rules on Oracle "Zero Data Loss Recovery Appliance" (ZDLRA) also referred to as the “Recovery Appliance” (RA). To keep it simple RA or ZDLRA are used through out this blog.  All references to backups are related to Oracle Database backups only. This blog also assumes you have a basic understand of Oracle Database Backup and Recovery and RA/ZDLRA Administration.

This blog is specific to understanding, where opportunities exist over and above the storage management automation integrated into the RA, and when needed, help the RA Admin better understand overall backup storage on the RA and manage storage from a database backup perspective. With this in view the content herein has been kept at a higher level of analysis and limited to known tuning capabilities available to an RA Admin.

While I have tried to share my personal insights in this blog, Oracle Documentation and MOS (My Oracle Support) Notes, should still be your primary source of content and references on this subject. Any queries provided in this blog are not supported by Oracle.

What is not covered in this blog, is REPLICATION or SBT USAGE and Enterprise Manager Cloud control (EMCC) RA Storage management capabilities.

Content in the series will be covered under the following with the highlighted focused in current blog:

Content [Click On Link]:

Attributes Helping Define Storage (1 of 6)

Storage Purge Rules (2 of 6)

Planning for Storage Capacity (3 of 6)

Analyzing Total Storage On RA (4 of 6)

Analyzing Storage for Individual Database Backup (5 of 6)

Managing Storage Attributes & Workload Balance (6 of 6)

Storage Purge Rules:

It is very essential before we start analyzing storage data, that we understand how the Purging Processes/Rules (Oracle Support Doc ID 2353188.1) are activated. Purging Rules can be invoked by ongoing storage maintenance or required free storage unavailability in meeting requirements. Proper Storage Planning is necessary both for current backups (i.e. used or reserved storage) and future requirements (Freespace Goal or Free Space) to ensure proper purging of old backups to prevent impact to recovery.  Figure 2-1 Show a brief insight into the Purging Rules.

               NOTE:   Review MOS Doc ID 2353188.1 for complete content and context. 

              

Figure 2-1 Storage Backup Purge Rules

Purge RULE 1, as seen from the below visual in Figure 2-2, space reclaim process reclaims all storage down to the Recovery Window Goal (RWG) once Retention goes over Max Disk Retention Window (MDR). This helps with automating periodic storage management between RWG and MDR.

Figure 2-2 Storage Backup Purge Rule 1 (Visual)

Purge RULE 2, as seen from the below visual in Figure 2-3 is a Freespace Goal threshold automating space reclaim for all assigned/used storage down to RWG. The Recovery Window Goal (RWG) is however left intact.

Figure 2-3 Storage Backup Purge Rule 2 (Visual)

Purge RULE 3, as seen from the below visual in Figure 2-4 is a Frees Space threshold automating space reclaim for all assigned/used storage down to Reserved Space. The Recovery Window Goal (RWG) may be impacted in proper Reserved Space has not been allocated.

Figure 2-4 Storage Backup Purge Rule 3 (Visual)

Now that we have identified the Purge RULES, it comes on mind how PURGE ORDER “[[QUERY: PURGE QUEUE]]” is used to identify purge candidate databases having backups on RA. Figure 2-5 shows how the RA identified databases for which backups can be candidates to be purged. 

Figure 2-5 Storage Backup Purge Order (Visual)

[[QUERY:  PURGE QUEUE]]

/* %%%%%%%%%%%%%% PURGE QUEUE QUERY %%%%%%%%%%%%%%%%% */
set    line 300 trimspool on
col    SL_NAME for a20
col    NEW_RECOVERY_WINDOW for a20
select
--    SL_NAME,        -- The Recovery Appliance storage location name.s
--    SL_KEY,            -- The primary key for this Recovery Appliance storage location in the recovery catalog.
    DB_UNIQUE_NAME,        -- The unique name of the protected database whose backups the Recovery Appliance will purge.
    DB_KEY,            -- The primary key for the protected database whose backups the Recovery Appliance will purge.
    PURGE_ORDER,        -- The order in which this protected database is eligible for purging.
    NEW_RECOVERY_WINDOW,    -- The recovery window goal for this protected database after a purge.
    NEW_PCT_RECOVERY,    -- The percentage of the recovery window goal remaining for this protected database after a purge.
    PCT_STORAGE        -- The percentage of reserved space being consumed by this protected database.
From    RA_PURGING_QUEUE;

Summary:

In the earlier blog we had seen how storage is managed through a few attributes for backups to the RA. In this blog we have extended on that knowledge to identify how the RA addresses storage allocation and release under space pressure using a set of predefined Purging Rules.

Going through the Next blogs in this series will provide insight into backup storage and how to manage some of the storage and capacity to meet user Oracle Database Recovery needs.