The replication from ZDLRA is easy to configure and operate. Most of complex part resides for policy management and define correctly what will be replicated. I already wrote about the basics for ZDLRA Replication in this post, and how to configure the dedicated network for replication in another post.
But also wrote how to startup and configure the replication server in another post. This is the first step and needs to be done before what I will describe in this post, they are the “physical” configuration. Here I will show the “logical” configuration for native ZDLRA replication and how correctly define it to avoid problems.
Replication Workflow
The image below shows the official ZDLRA documentation and report the workflow related to replication (can be found here):
And here too:
If you look closely you can see that the policy definition is the base for replication, and came first. And this configuration can be more difficult to be done because can vary a lot (from each one), so, it is important to understand the concept.
The focus in this post is to show how to configure the replication, linking policies, and replication server that we create in the previous post. I will cover more about the backupset replication at other posts. With this post, you can check how to create the replication config.
To configure the replication, we use the DBMS_RA.ADD_REPLICATION_SERVER. Linking the server that we create in the previous post, with the desired policy.
Policies for Replication
Maybe the most important for a good ZDLRA replication is to understand the policies and the inter-relations. The ZDLRA does the replication based on protection policies, so, it replicates the policy.
So, if your design for ZDLRA has few policies and a lot of databases inside of that (like SILVER, GOLD and PLATINUM policies), probably you need to change that and create dedicated policies for replication. If you do not do that, as explained before, all the database for that particular policy will be replicated. So, create dedicated policies and links with the databases that you want to replicate is the best practice.
It is not a drawback (since you need to duplicate your policies), but a better design to avoid incorrect space and resource usage. And also avoid competition over the stream for the replication server.
So, in this post, I will replicate the policy BRONZE only. Remember upstream is the ZDLRA that is sending the backup, and the downstream is the ZDLRA that is receiving the backups.
Policies at Downstream
One important detail is that the policy at downstream can be completely different than at upstream, and don’t need to be one to one. This means that you can have just one policy at downstream (even if the upstream is replicating more than one policy) and that the parameters like recovery_window_goal and max_retention_window can be different than upstream.
By design, this can be important because you can have one small upstream ZDLRA, and one big downstream to store your backups more time. And since the rman catalog is self-managed everything will be automatically available.
Creating the Configuration
Policies
Creating the policies at Upstream
So, we first create the policy at upstream, in this scenario the name is ZDLRAUP_BRONZE. If you already have the policy that you want to replicate, you can use it. But just remember that all databases linked with the policy will have backupsets replicated.
[oracle@zdlras1n1 ~]$ sqlplus rasys/change^Me2 SQL*Plus: Release 19.0.0.0.0 - Production on Sun Dec 22 19:13:41 2019 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Last Successful login time: Sun Dec 22 2019 18:09:24 +01:00 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> BEGIN 2 DBMS_RA.CREATE_PROTECTION_POLICY( 3 protection_policy_name => 'ZDLRAUP_BRONZE' 4 , description => 'Policy ZDLRA MAA BRONZE' 5 , storage_location_name => 'DELTA' 6 , recovery_window_goal => INTERVAL '14' DAY 7 , max_retention_window => INTERVAL '21' DAY 8 , recovery_window_sbt => INTERVAL '30' DAY 9 , guaranteed_copy => 'NO' 10 , allow_backup_deletion => 'YES' 11 ); 12 END; 13 / PL/SQL procedure successfully completed. SQL>
Creating the policies at downstream
Now we create the policy at downstream, remember that they can have different parameter values (that it is the case for recovery window values):
[oracle@zdlras2n1 ~]$ sqlplus rasys/change^Me2 SQL*Plus: Release 19.0.0.0.0 - Production on Sun Dec 22 20:22:52 2019 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Last Successful login time: Sun Dec 22 2019 19:24:02 +01:00 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> BEGIN 2 DBMS_RA.CREATE_PROTECTION_POLICY( 3 protection_policy_name => 'ZDLRA_BRONZE_REP' 4 , description => 'Policy ZDLRA MAA BRONZE' 5 , storage_location_name => 'DELTA' 6 , recovery_window_goal => INTERVAL '28' DAY 7 , max_retention_window => INTERVAL '45' DAY 8 , recovery_window_sbt => INTERVAL '60' DAY 9 , guaranteed_copy => 'NO' 10 , allow_backup_deletion => 'YES' 11 ); 12 END; 13 / PL/SQL procedure successfully completed. SQL>
ADD_DB and GRANT_DB_ACCESS
Grant access at upstream
For upstream we just need to add the db and grant the access just for only to one VPC. Remember that in the previous post we not create the VPC at upstream ZDLRA? This is because we use a pre-existence VCP. But if you want to know how it is made you can see here below. Just remember that this is not needed if you already registered the database at your upstream ZDLRA.
[oracle@zdlras1n1 ~]$ sqlplus rasys/change^Me2 SQL*Plus: Release 19.0.0.0.0 - Production on Sun Dec 22 20:30:59 2019 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Last Successful login time: Sun Dec 22 2019 19:13:41 +01:00 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> BEGIN 2 DBMS_RA.ADD_DB( 3 db_unique_name => 'ORCL19' 4 , protection_policy_name => 'ZDLRAUP_BRONZE' 5 , reserved_space => '7G' 6 ); 7 END; 8 / PL/SQL procedure successfully completed. SQL> BEGIN 2 DBMS_RA.GRANT_DB_ACCESS ( 3 db_unique_name => 'ORCL19' 4 , username => 'VPCSRC' 5 ); 6 END; 7 / PL/SQL procedure successfully completed. SQL>
So, in this case we have database ORCL19 linked with the user “vpcsrc” and with policy ZDLRAUP_BRONZE that we create before.
Grant access at downstream
Here we can see a big key point since we need to grant access to both VPC users that we create downstream. Doing this we grant the access at the user used to do the replication itself, and to the VPC for catalog access.
So, we can access directly the catalog at ZDLRA downstream (to use when the upstream is unavailable as an example) to do restore. Downstream ZDLRA can configure sync (send) backups to upstream (when it returns available), but I will not cover in this post.
So, we grant access:
[oracle@zdlras2n1 ~]$ sqlplus rasys/change^Me2 SQL*Plus: Release 19.0.0.0.0 - Production on Sun Dec 22 20:22:52 2019 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Last Successful login time: Sun Dec 22 2019 19:24:02 +01:00 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> BEGIN 2 DBMS_RA.ADD_DB( 3 db_unique_name => 'ORCL19' 4 , protection_policy_name => 'ZDLRA_BRONZE_REP' 5 , reserved_space => '7G' 6 ); 7 END; 8 / PL/SQL procedure successfully completed. SQL> BEGIN 2 DBMS_RA.GRANT_DB_ACCESS ( 3 db_unique_name => 'ORCL19' 4 , username => 'VPCREP' 5 ); 6 END; 7 / PL/SQL procedure successfully completed. SQL> BEGIN 2 DBMS_RA.GRANT_DB_ACCESS ( 3 db_unique_name => 'ORCL19' 4 , username => 'REPUSR_FROM_ZDLRAS1' 5 ); 6 END; 7 / PL/SQL procedure successfully completed. SQL>
Look that now the ORCL19 is linked with the policy ZDLRA_BRONZE_REP. And the downstream ZDLRA can receive backups of this database from two users, vpcrep and repusr_from_zdlras1.
DBMS_RA.ADD_REPLICATION_SERVER
In the previous post the DBMS_RA.CREATE_REPLICATION_SERVER was used to create the replication server upstream. And now, we use the DBMS_RA.ADD_REPLICATION_SERVER to link this server and the policy that we want to replicate.
It is simple to call done at ZDLRA upstream:
[oracle@zdlras1n1 ~]$ sqlplus rasys/change^Me2
SQL*Plus: Release 19.0.0.0.0 - Production on Sun Dec 22 20:46:51 2019
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Last Successful login time: Sun Dec 22 2019 20:33:15 +01:00
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> SELECT COUNT(*) FROM RA_REPLICATION_SERVER;
COUNT(*)
----------
1
SQL> BEGIN
2 DBMS_RA.ADD_REPLICATION_SERVER (
3 replication_server_name => 'zdlras2_rep',
4 protection_policy_name => 'ZDLRAUP_BRONZE'
5 );
6 END;
7 /
PL/SQL procedure successfully completed.
SQL> col REPLICATION_SERVER_NAME format a30
SQL> col PROTECTION_POLICY format a20
SQL> col REP_SERVER_CONNECT_NAME format a20
SQL> set linesize 250
SQL> select REPLICATION_SERVER_NAME, REPLICATION_SERVER_STATE, PROTECTION_POLICY, REP_SERVER_CONNECT_NAME, MAX_STREAMS from RA_REPLICATION_SERVER;
REPLICATION_SERVER_NAME REPLICATION_SERVER_ST PROTECTION_POLICY REP_SERVER_CONNECT_N MAX_STREAMS
------------------------------ --------------------- -------------------- -------------------- -----------
ZDLRAS2_REP RUNNING ZDLRAUP_BRONZE RASYS 4
SQL>
As you can see above, the upstream ZDLRA (ZDLRAS1) is creating the ZDLRAS2_REP using the DBMS_RA.ADD_REPLICATION_SERVER to replicate ZDLRAUP_BRONZE policy. And if we need to have more policies to be replicated, we need to create new replication servers calling DBMS_RA.ADD_REPLICATION_SERVER. Doing that more lines will appear at rasys.ra_replication_server table.
So, the relation is 1 to 1 for replication_server_name and protection policy. If you are replicating more than one policy, is best practice to create a readable and distinct name for replication_server_name.
Doing backup, example
If the database is recently added, we can register the database at rman catalog. But whatever it is a new, or old database, we can do the backup and check that they will be replicated and the rman catalog is automatically aware of that,
I will cover more about the rman backupset replication in other posts. But with what we made here, the “replication” configuration is done.
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS "SBT_LIBRARY=/u01/app/oracle/product/19.3.0.0/dbhome_1/lib/libra.so, ENV=(RA_WALLET='location=file:/u01/app/oracle/product/18.6.0.0/dbhome_1/dbs/ra_wallet credential_alias=zdlras1-scan:1521/zdlras1:VPCSRC')"; new RMAN configuration parameters: CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS "SBT_LIBRARY=/u01/app/oracle/product/19.3.0.0/dbhome_1/lib/libra.so, ENV=(RA_WALLET='location=file:/u01/app/oracle/product/18.6.0.0/dbhome_1/dbs/ra_wallet credential_alias=zdlras1-scan:1521/zdlras1:VPCSRC')"; new RMAN configuration parameters are successfully stored starting full resync of recovery catalog full resync complete RMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 1 TAG 'BKP-DB-INC0'; Starting backup at 22-12-2019_21:54:44 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=62 device type=SBT_TAPE channel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=9A521EDF1FE73C47E053010310AC5B4E channel ORA_SBT_TAPE_1: starting incremental level 0 datafile backup set channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL19/system01.dbf channel ORA_SBT_TAPE_1: starting piece 1 at 22-12-2019_21:54:47 channel ORA_SBT_TAPE_1: finished piece 1 at 22-12-2019_21:57:32 piece handle=ORCL19_16uk3h97_1_1 tag=BKP-DB-INC0 comment=API Version 2.0,MMS Version 12.2.0.2 channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:02:45 Finished backup at 22-12-2019_21:57:32 Starting Control File and SPFILE Autobackup at 22-12-2019_21:57:32 piece handle=c-323177095-20191222-01 comment=API Version 2.0,MMS Version 12.2.0.2 Finished Control File and SPFILE Autobackup at 22-12-2019_21:57:44 RMAN>
And after that we can see that backupset is replicated in the downstream ZDLRA:
RMAN> list backup of datafile 1 completed before "to_date('22/12/2019 22:05:00','dd/mm/rrrr hh24:mi:ss')";
List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ----------
9221 Incr 0 321.61M
List of Datafiles in backup set 9221
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2064007 22/12/2019 21:54:47 NO /u01/app/oracle/oradata/ORCL19/system01.dbf
Backup Set Copy #1 of backup set 9221
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:05:32 22/12/2019 22:00:20 YES BKP-DB-INC0
List of Backup Pieces for backup set 9221 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
9222 1 AVAILABLE VB$_1891149551_9211I
Backup Set Copy #2 of backup set 9221
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:05:32 22/12/2019 22:00:19 YES BKP-DB-INC0
List of Backup Pieces for backup set 9221 Copy #2
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
9674 1 AVAILABLE ZDLRAS2_REP VB$_2127575003_7524I
RMAN>
Look above that the backupset of datafile 1 that we made before (look the Ckp Time) has two backupiece copies. The copy number 1 is in ZDLRA upstream (media is empty) and another at ZDLRA downstream (media report ZDLRAS2_REP).
The Replication Config
With the DBMS_RA.ADD_REPLICATION_SERVER we finish the configuration for our native ZDLRA replication. The server configuration was made in the previous post, and the link between the database, replication server, and protection policy, was made in this post.
The most important is to understand that replication is based on protection policy. You can add more than one policy to replicate, this is not a problem. But you need to understand that all databases liked with the policy will have backupset replicated. So, create the policies correctly is crucial to avoid “waste” replication throughput sending something that is not needed.
In the next post, I will show the detail of how the replication works for database and how this appears/interact with the rman catalog, and what you can do with that.
Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community. Post protected by copyright.”