Managing Space - Recovery Appliance / ZDLRA / RA - 3 of 6 - Planning Storage Capacity

In this Third part of a series of blogs on ZDLRA/RA backup storage/space, I am going to share some of my insights into a few methodologies of Storage Capacity Planning 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 (3of 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)

  24 24

Planning for Storage Capacity:

Now that we have some knowledge on how the Attributes impact RA/ZDLRA Backup Storage allocation, management and purging, it becomes the RA Admins responsibility to ensure that periodic Storage Capacity Planning provisions for both current and future recovery needs. Before we dive into ways to plan storage, it is recommended to always engage Oracle Sales/Support while executing capacity planning to ensure a balanced approach using the latest RA enhancements. 

While there is no steadfast rule provided, from my perspective there are four database backup sizing methodologies you can choose to size your recovery needs One for First Time Backups to the RA and Three when you have backups on the RA. Figure 3-1, Figure 3-2  & Figure 3-3 represents sizing for backup on RA to meet your Recovery requirements.  We will touch on all just for our underestanding. 

INITIAL BACKUP: This is storage capacity needed for Databases not currently backed up to the RA. Traditional   methods can help address the storage sizing for this with some caveats. Below are some suggestions for a sizing estimation driven by emphasis weather Recovery Window Goal (RWG) to Max Disk Retention Window (MDR) is the driving need:

RWG REQUIRED STORAGE = L0 + (5% CHANGE RATE x RWG) + (5% REDO RATE x RWG)

MDR REQUIRED STORAGE = L0 + (5% CHANGE RATE x MDR) + (5% REDO RATE x MDR)

NOTE: L0 and “CHANGE RATE”/L1 reference RMan (Oracle Recovery Manager) Level 0 and Level 1 backups. “REDO RATE” references the amount of redo shipped in real time to ZDLRA. Please refer to latest Oracle Documentation on Recovery Manager for more information.

NOTE: 5% is a assumed Change/Redo in this example assumes a new database with not previous history and can be set higher for high transaction databases as needed. This can also be replaced by what you see on your existing database today.

NOTE: For Databases that do not use In-Database Compression or Encryption a 2x RA compression can be assumed however this can vary. There is one caveat to keep in mind and that in rare cases where Redo Shipping did not work i.e. network issues or was not setup and RMan Archive Log backups were initiated to RA. These RMan Archive Log backups may not compress as well as Redo Shipping on RA.

ESTIMATED:        The RA has internal algorithms that provides analytical space requirements based on trending backups during last 6 hours with the analytical backup data calculated every 3 Hours for existing Recovery Window Goal (RWG). This makes it simple to size storage capacity with other storage needs i.e. KEEP_BACKUP etc. as in Figure 3-1,  Figure 3-2& Figure 3-3 (System Activity/SAR Report SUM_RECOVERY_WINDOW_SPACE). This could be good metric for consistent backup volumes across longer periods of time i.e. Weeks/Months, where there are no/small changes in incoming backup volumes for the databases. However, for backups that have inconsistent sized/volumes this size could be considered. Always capture and use the MAX Estimated over a long period of time i.e. Months/Year.

NOTE: The sizing is based on RWG so if you plan to treat the Max Disk Retention and size based on allocated space then the estimated sizing could to be extrapolated for MDR.

USED:                   Capturing current used storage across a period of time i.e. Months/Year, is another methodology, when you have a full Recovery Window Goal (RWG) on the RA and ongoing future backups and RWG will remain consistent. Figure 7-1 provides USED Storage History.

NOTE: It is important to keep in mind the USED space includes your Max Disk Retention (MDR) space, KEEP SPACE (backups using KEEP Clause), FULL BACKUPS (not L0 backup) that can lead to over provisioning.

RESERVED:          Reserved Space is a good way to ensure ample space is allocated to existing database backups on RA, reducing any allocation/purge due to free space limitations, on incoming backups. This I feel, is a very good sizing strategy when size of backups to RA especially when incoming backup sizes/volumes are unknown i.e. Seasonal Changes, Large Transactions, Migrations (TITS, PDB plugin) etc. As a good practice setting the allocation above the RWG required space/storage creates a healthy and proactive storage practice.

Whichever RA, provisioning/sizing methodology you choose Figure 3-1 & Figure 3-2 show the various metrics that are needed for calculating total usable storage needed for your backup and recovery storage needs.

Figure 3-1 Capacity Planning (Visual)

 

Figure 3-3 below provides shows a sample methodology to calculate the required storage. What is not included in here are backups metrics not available that need RA Admin inputs i.e. New Database Backup, TTS (Transportable Tablespace Attached), PDB Plugged-In, Backups with KEEP UNTIL Clause etc. as these backups will consume additional storage that are unknown to the RA. For these scenarios the Free Space overhead must consider additional storage for future and unforeseen needs.

Figure 3-2 Capacity Planning (Visual)

Figure 3-3 System Activity Report

 

Summary:

Now that we have discussed some methodologies on sizing for RA storage, a general recommendation would be to set Disk Retention Window and Reserved Space above the RWG. Always work with Oracle Sales/Support to ensure that changes and any unseen requirements are incorporated into you future sizing needs.