The Virtual Private Catalog (VPC) user is a key piece for a good ZDLRA architecture design. The detail is not how to create it, but how to correctly integrate it in your design, and this is more important if you have replicated ZDLRA or using Real-Time redo transport.
Here I will show and discuss VPC implications for your architecture design when deploying ZDLRA. Even for a complete and new implementation (together with database) or adding ZDLRA at your already running environment. All points here try to show some perspectives and key points that can help you to correct use and define VPC’s.
VPC
For the simple definition, VPC user is created directly inside ZDLRA database using the “racli” (or EM/CC) as you can see below and here in the doc:
[root@zdlras1n1 ~]# /opt/oracle.RecoveryAppliance/bin/racli add vpc_user --user_name=vpcsrc [vpcsrc] New Password: Mon Nov 25 23:41:45 2019: Start: Add vpc user vpcsrc. Mon Nov 25 23:41:46 2019: Add vpc user vpcsrc successfully. Mon Nov 25 23:41:46 2019: End: Add vpc user vpcsrc. [root@zdlras1n1 ~]#
The VPC is used when you connect using rman from the client, and it is the catalog owner for your rman:
[oracle@orcloel7 ~]$ rman target=/ catalog=vpcsrc/vpcsrc@zdlras1 Recovery Manager: Release 18.0.0.0.0 - Production on Tue Nov 26 00:23:40 2019 Version 18.6.0.0.0 Copyright (c) 1982, 2018, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL18 (DBID=3914023082) connected to recovery catalog database recovery catalog schema version 19.03.00.00. is newer than RMAN version RMAN>
Inside ZDLRA it is just a logical organization for your connections, it does not store tables or views. Just made the link for rman catalog views (RC_*) between the VPC user itself and the internal RASYS (ZDLRA user/schema that have all tables).
When you add the database inside of ZDLRA you grant the access for the database using VPC user as a parameter too:
SQL> BEGIN 2 DBMS_RA.GRANT_DB_ACCESS ( 3 db_unique_name => 'ORCL18' 4 , username => 'VPCSRC' 5 ); 6 END; 7 / PL/SQL procedure successfully completed. SQL>
But to be honest this is just a simple definition. VPC is more important in the architecture of your solution than “creation and connection commands”. I will explain.
For ZDLRA, the VPC is just a logical definition (don’t store data itself), you can create more than you single VPC. You can create multiple VPC’s and separate databases based on your own rules. Like one VPC for DEV database, one for PROD, or can be one per rack (like Exadata, AIX, Power). You choose.
Remember that the VPC is the rman catalog user, so every database with the grant, “share” it. If you do “list db_unique_name all” (and if do “set dbid”) everyone in the same catalog can be access the backups.
So, when you are planning your architecture for ZDLRA deployment, think about the VPC users that you will have. How you can divide/aggregate your databases. But don’t worry if you need to create more VPC’s in the future, remember that it is just a logical definition. If you want to move databases between VPC’s you just need to call DBMS_RA.GRANT_DB_ACCESS for your database to the new VPC. All the backups will appear automatically with/in the new catalog.
But it is not just a rman catalog that VPC defines. There are other points that can change your architecture, I will explain below.
VPC and Real-Time Redo transport
The Real-Time Redo is the feature for ZDLRA that guarantee the zero RPO, you can see more details in my previous posts (here and here). But the point is that the VPC needs to be used as REDO_TRANSPORT_USER parameter for your database to real-time redo work.
This is needed because the ZDLRA is one destination for archive logs (log_archive_dest parameter) and since ZDLRA “simulate” dataguard in this case, both sides need to have the same user (as a normal DG does). Usually, you don’t change this for DG since both sides talks using sys user. But for ZDLRA, you need to use VPC as redo user. And besides that, the automatic backups for archivelog need to appear inside rman catalog (list backup of archive as an example). As told in my post here, create user inside your database (with sysoper permission at least) and change the database parameter.
So, unfortunately, this can impact again at the architecture design and not just for ZDLRA, but for all databases. Sometimes the database username needs to follow some naming/security rules and VPC definition will need to follow this too.
VPC and Real-Time Redo transport and DataGuard
The point for VPC and Real-Time Redo when using Dataguard is that in this scenario you have at least two sites, two ZDLRA’s, two databases with dataguard, and real-time redo transport enabled. But, everything needs to have/use the same, and only one, VPC username.
Database in site 1 will talk with ZDLRA at site 1 using the VPC for backup and real-time redo. And since it is dataguard, the database in site 1 talks with the database in site 2 (for DG) using the redo_transport_user. So, if you are doing a backup of the database in site 2 at ZDLRA in site 2, and even the real-time redo, the VPC for ZDLRA in site 2 needs to be the same than redo_transport_user. As you can imagine, the same VPC username in both ZDLRA’s in this case. If you are not planning to use real-time redo for your database, you can use different VPC usernames.
So, if you are planning to use multiple ZDLRA’s to protect your sites the architecture design needs to be well planned. If you were planning to use different VPC usernames (to represent different rman catalogs for each site), you need to review. You can use this approach for databases that don’t use dataguard, but will not fit for DG databases.
VPC and Replicated ZDLRA
Another point that needs attention for VPC is when using replicated ZDLRA. Besides, if you are using the real-time redo, here, you need two additional VPC’s (three at total):
- ZDLRA site 1 VPC: The normal VPC used to database (from the same site) connect and do backups and use real-time redo.
- ZDLRA site 2 VPC: VPC at second that will be used as is normal rman catalog. This is needed if you want to connect the database from site 1 in ZDLRA site 2 (think that your ZDLRA from site 1 is out).
- ZDLRA side 2 VPC for replication: VPC user to receive the replicated backups from ZDLRA in the other site. This is used internally by ZDLRA to intercommunication but still is a VPC.
When using replicated ZDLRA you have one database doing backup at a local ZDLRA in the same site, and this ZDLRA sends this backup to other replicated ZDLRA. The connection between the database and local ZDLRA uses the VPC from point 1 listed above. The replication between ZDLRA’s will use the VPC from point number 3. And if you want, you can have the VPC of point #2 to do backups when the “source” ZDLRA is down.
This scenario can complicate a little more if you are planning to use real-time redo because the VPC from points 1 and 2 needs to be the same.
As you can see, other points that you need to verify and take care of ZDLRA architecture design.
Architecture
In this level of architecture design probably you will have more than one ZDLRA, protecting more than one site, or doing replication to achieve ideal protection. But even if you use only one ZDLRA, the concerns are the same.
Independently the number of ZDLRA’s is possible that you will mix all the available features, real-time redo, and replication. It is common that you have different requirements for your databases, you may need to handle (and protect) single/isolated databases (like DEV), databases with just real-time redo in use, databases with ZDLRA replication (for multi-site protection), and probably databases with DG that needed to be protected in both sides.
Usually, when deploying ZDLRA you are dealing with huge and mixed environments that need different levels of protection. But before “just deploy” ZDLRA there you need to start with good architecture design, identify the needs and how you care VPC to handle correctly everything.
Maybe you will need to create more than one VPC, this totally depends on your requirements. It does not exist a magic receipt to do that, but if you know all the details that can impact VPC definition, the success will be achieved. As you saw, VPC it is not just the user for rman connection.
The idea of this post was pointing most of the details that are important to know about VPC when designing the architecture to deploy and integrate ZDLRA.
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.”