This post is intended to be a Quick Start Guide for those who are new to ZDLRA (RA for short). I spend part of time working with customers who are new the RA and often the same topics/questions come up. I wanted to put together a "Quick Start" guide that they can use to learn more about these common topics.
The steps I would follow for anyone new to the RA are.
- Read through the section on configuring users and security settings for the RA. Decide which compliance settings make sense for the RA and come with a plan to implement them.
- Identify the users, both OS users (if you are disabling direct root access), and users within the databases that will mange and/or monitor the RA. OS users can be added with "racli add admin_user". Database users can be added with "racli add db_user"
- Create protection policies that contain the recovery window(s) that you want to set for the databases. You will also set compliance windows when creating policies. This can be done manually using the package DBMS_RA.CREATE_PROTECTION_POLICY.
- Identify the VPC user(s) needed to manage the database. Is it a single DBA team, or different teams requiring multiple VPC users? Create the VPC user using "racli add vpc_user"
- Add databases to be backed up to the RA, associate the database with both a protection policy and a VPC user who will be managing the database. NOTE that you should look at the Reserved Space, and adjust it as needed. Databases can be added manually by using two PL/SQL calls. DBMS_RA.ADD_DB will add the database to the RA. DBMS_RA.GRANT_DB_ACCESS will allow the VPC user to manage the database.
- Configure the database to be backed up to the RA either by using OEM, or manually. The manual steps would be
- Create a wallet on the DB client that contains the VPC credentials to connect to the RA.
- Update the sqlnet.ora file to point to this wallet
- Connect to the RMAN catalog on the RA from the DB client
- Register the database to the RA
- Configure the channel configuration to point to the RA
- Configure Block change tracking (if it is not configured).
- Configure the redo destination to point to the RA if you want to configure real-time redo.
- Change the RMAN retention to be "applied to all standby" if using real-time redo, or "backed up 1 time" if not.
- Update OEM to have the database point to the RMAN catalog on the ZDLRA.
Documentation
The documentation can be found here. Within the documentation there are several sections that will help you manage the RA.
Get Started
The get started section contains some subtopics to delve into
Install and configure the Recovery Appliance
The links in this section cover all the details about the installation and configuration of the RA. I won't be talking about those sections in the post, but be aware this is where to look for general maintenance/patching/expanding information.
Learn about the Recovery Appliance.
This section covers an overview of the RA, and is mostly marketing material. If you are not familiar with the RA, or want an overview this is the place to turn.
Administer the Recovery Appliance
These sections are going to be a lot more helpful to get you started. This section of the documentation covers
Managing Protect Policies - Protection policies is the place to start when configuring an RA. Protection policies group databases together and it is critical to make sure you have the correct protection policies in place before adding databases to be backed up.
Copying Backups to Tape - This section is useful if you plan on creating backups (either point in time or archival) that will be sent externally from the RA. This can be either to physical/virtual tape, or to an external media manager.
Archiving Backups to the Cloud - This section covers how to configure the RA to send backups to an OCI compatible object storage. This can either be OCI, or it can be an on-premises ZFS that has a project configured as OCI object storage.
Accessing Recovery Appliance Reports - This section covers how to access all the reports available to you. You will find these reports are priceless to manage the RA over time. Some examples of the areas these reports cover are.
- Storage Capacity Planning reports with future usage projections
- Recovery Window Summary reports to validate backups are available
- Active incident reports to manage any alerts
- API History Report to audit any changes to the RA
NOTE : If you are using the RA in a charge backup model to your internal business units, there is specific reporting that can be used for this. Talk your Oracle team find out more.
Monitoring the Recovery Appliance - This section covers how to monitor the RA and set up alerts. This will allow you identify any issues that would affect the recovery of the backups including space issues, and missing backups.
Administer the Recovery Appliance
Configure Protected Databases - This section goes through how to configure databases to be backed up to the recovery appliance and includes instructions for both using OEM, and adding databases using the command line.
Backup Protected Databases - This section covers how to backup a database from either OEM, or from the traditional RMAN command line. I would also recommend looking at the MOS note to ensure that you are using the current best practices for backups. "RMAN best practice recommendations for backing up to the Recovery Appliance (Doc ID 2176686.1)".
Recover Databases - This section covers how to recover databases from the RA. This section also covers information about cloning databases. Cloning copies of production is a common use case for the RA, and this section is very useful to help you with this process.
Books
This section contains the documentation you look at regularly to manage the RA and answer questions that you may have on managing it. I am only going to point the sections that you find most useful.
Deployment
The one important section under deployment is the Zero Data Loss Recovery Appliance Owners Guide.
Zero Data Loss Recovery Appliance Owners Guide - This guide contains information on configuring users on the RA, and the most critical sections to look at are
- "Part III Security and Maintenance of Recovery Appliance". If you are using the RA to manage immutable backups, it is important to go through this section to understand how users will be managed for maximum protection of your backups.
- Part IV Command Reference - This section covers the CLI commands you will use the manage the RA.
Administration
This is probably the most important guide in the documentation. It covers many of the areas of you will be managing as you configure databases to be backed up. The most critical sections are
Part I Managing Recovery appliance - This section covers
- Implementing Immutable Backups
- Securing the Recovery Appliance operations
- Managing Protection Policies
- Configuring replication and replication concepts
- Additional High Availability strategies
Part III Recovery Appliance Reference - This section covers
- DBMS_RA packages to manage the RA through commands
- Recovery Appliance View Reference to see what views are available
MOS Notes
There are number of useful MOS notes that you will want to bookmark
- Zero Data Loss Recovery Appliance (ZDLRA) Information Center (Doc ID 2673011.2)
- How to Backup and Recover the Zero Data Loss Recovery Appliance (Doc ID 2048074.1)
- Zero Data Loss Recovery Appliance Supported Versions (Doc ID 1927416.1)
- Zero Data Loss Recovery Appliance Software Updates Guide (Doc ID 2028931.1)
- Cross Platform Database Migration using ZDLRA (Doc ID 2460552.1)
- How to Move RMAN Catalog To A Different Database (Doc ID 351918.1)
Helpful Blogs
Fernando Simon
Fernando has a number of helpful blog entries. Be aware he has been blogging for a long time on the RA, and some of the management processes have changed. One example is RACLI is now used to create VPC users. Some of the Blogs to note are
Bryan Grenn
I have a number of blog posts on features of the ZDLRA.
Hello Bryan,
ReplyDeleteThanks for the article. I wanted to ask you about the management of space policies. When defining space management policies, there is the possibility of defining the Autotune_Reserved_Space parameter and/or YES instead of defining the reserved_space parameter at the database level. What is best practice and which one is recommended to use? Thanks.
i would absolutely use the Autotune of reserved space. I have always found that reserved space can be a challenge to keep current, and autotune takes care of a lot of that work.. if you have databases that have special needs, you can still override autotune by setting reserved space manually.
Delete