ZDLRA best practices (updated 2025)
I have seen a lot of changes with the ZDLRA over the last 10 years or so, and because of that I wanted to document the best practices to follow that evolved up to now (2025).
Because of these changes, I wanted to write a blog post on what customers should think about doing now.
1. Channel Configuration
There are a few items to talk about with channel configuration. First let's break down the pieces of the channel configuration
a) Library
Version
Up until version 19.26, you could use a shared version of the library (libra.so) based on the OS. Updates to the library could be downloaded directly from MOS.
Starting with version 19.27 on Linux, you must use the version that is stored in $ORACLE_HOME and patched using OPatch. More information can be found in the MOS note below.
Location (channel setting)
In the previous section I mentioned that the library is tied to the version of Oracle starting with 19.26. Prior to this release, the default channel setting for the library with the ZDLRA was
- "PARMS 'SBT_LIBRARY=$ORACLE_HOME/lib/libra.so"
In order to always utilize the current library for the $ORACLE_HOME, the recommendation is to set the channel setting to
- "SBT_LIBRARY=libra.so" - No path, and it will default to the current $ORACLE_HOME/lib"
Or
- "SBT_LIBRARY=oracle.zldlra" - This will default to the current $ORACLE_HOME/lib/libra.so
b) Environment
In the environment section, you specify the SEPS wallet location. Because there could be conflicts with other oracle products that use a wallet (like OUD), the default location for the SEPS wallet should be set to the WALLET_ROOT location, rather than within the $ORACLE_HOME location.
In the past, the channel setting for ZDLRA was
- "RA_WALLET=location=file:${ORACLE_HOME}/dbs/ra_wallet credential_alias={SEPS entry in wallet}"
The recommendation is to set the WALLET_ROOT in the spfile, and store the SEPS wallet within the server_seps directory under this location. If WALLET_ROOT is set to $ORACLE_BASE/admin/{$DB_NAME}/wallet, the setting would be
- "RA_WALLET=location=file:${ORACLE_BASE}/admin/${DB_NAME}/wallet/server_seps/ credential_alias={SEPS entry in wallet}"
c) TLS or non-TLS
If a customer has the ZDLRA configured to encrypt backups with TLS/SSL, the library, by default, will attempt to encrypt the backup using SSL/HTTPS. If TLS/SSL is configured as optional, and if the client does not have the certificate information, backups will fail. To avoid this, it is recommended to add the following setting to the channel configuration. This setting will allow you to send backups even if optional TSL/SSL is configured.
- _RA_NO_SSL=TRUE
d) Space Efficient Encrypted Backups
In order to use Space Efficient Encrypted Backups, you must set the following in your channel configuration. This is only available on linux with DB version 19.18+. Keep in mind this setting will only compress datafile backup pieces.
- RA_FORMAT=TRUE
2. RMAN encryption
One misconception with Space Efficient Encrypted Backups, is that by setting RA_FORMAT=TRUE you are both compressing and encrypting backups. This is not true. You are only compressing the backups. If the tablespace is encrypted with TDE, the backup will remain encrypted, but any non-TDE tablespace backups will be unencrypted. In order to encrypt the backup pieces (Datafiles, controlfile,. archive logs and spfile) you need to both set an encryption key (if not already set), and set RMAN encryption on. If you are backing up any tablespaces that are not TDE, you must also ensure you set RA_FORMAT=TRUE.
You should also set the default encryption algorithm to AES256, as most customers use this today rather than the default of AES128
NOTE: Use of RA_FORMAT=TRUE (RMAN Compression) and RMAN encryption is included in the license for ZDLRA and you do not need the ACO or ASO license for backups to the ZDLRA.
3. Real-time redo settings.
a) Default SEPS wallet location
Wallets are becoming more and more common with databases, and this increases the chances that there will be conflict with other Oracle features that also utilize a wallet. To avoid this there is a new default location for the SEPS wallet used by real-time redo. The database will first look in the {WALLET_ROOT}/server_seps location for the wallet. It is recommended to set the WALLET_ROOT for all databases and use this default location for the SEPS wallet. Of course you may use links to simplify management.
b) Encrypt Redo
If you have an encryption key set, and you wish to fully encrypt your backups, you also need to ensure that real-time redo is also encrypted. You need to set encryption on the destination for real-time redo
- ENCRYPTION=ON
4. Reserve Space
Reserve space has been difficult to explain, and it has become even more important when implementing a compliance window. If there is no compliance set, then the reserve space is only interrogated when the ZDLRA runs out of space. When a compliance window is set, the reserve space is interrogated when backing up to ensure that compliance locked backups fit within the reserved space. If they do not, backups are rejected. Because of this, I always recommend setting the "auto-tune reserve space" for the policies, especially when setting a compliance window. This setting will automatically adjust the reserve space for you as databases grow.
5. When encrypting backups set "secure mode"
If you need to fully encrypt your backups with RMAN encryption, it is recommended to use "secure mode" on your protection policy. This setting checks all backup pieces (including real-time redo) to ensure that they are RMAN encrypted. Any unencrypted backup pieces will be rejected.
6. Use racli commands
One of the biggest changes is the increase in the functionality available with racli command vs executing DBMS_RA PL/SQL packages. It is recommended to utilize RACLI commands when possible. I know when trying to automate onboarding databases, it is much easier to utilize PL/SQL packages.
7. Pair ZDLRAs when using replication
Another change is the ability to pair ZDLRAs that have replication configured. This can be done with the "racli add ra_partner" command. Using the ZDLRA pairing commands for replication greatly simplifies the configuration of replication. Existing configurations can be converting to using the pairing model.
8. Review types of DB users
There have been a few changes to DB users. There are now 4 types of DB users.
- ADMIN -Used to administer ZDLRA configuration settings
- MONITOR - Read-only account that can view metadata
- REPLICATION - Used to replicate backups between ZDLRAs
- VPC - Used by protected databases to send/received backups
- Insecure=TRUE - VPC user's password will expire, but it can be reset to the same password. This type of user does not support password rollover
- insecure=false - VPC user's password will expire, but this user can leverage password rollover (STIG) to manage password rotation without having backups fail.
Summary:
- Set WALLET_ROOT in the database and store the SEPS in the {WALLET_ROOT}/server_seps directory
- Ensure the library location in the channel configuration defaults to the current $ORACLE_HOME
- Set _RA_NO_SSL=TRUE to ensure that converting to TLS/SSL will not cause existing backups to fails
- Set RA_FORMAT=TRUE to leverage space efficient encrypted backups --> Linux only
- Enable RMAN encryption, and set algorithm to AES256 --> Linux only
- Encrypt Real-time redo if applicable
- If you require fully encrypted backups, set SECURE_MODE on the policy
- Enable auto-tune of reserved space for all databases, especially those using a compliance window.
- Use RACLI commands to manage the ZDLRA
- Pair ZDLRAs when configuring replication
- Leverage password rollover for VPC users if you require password rotation
