I've been wanting to test out DGPDB, which is Data Guard per PDB.
This new feature was introduced with 21c and is covered in detail in this blog here .
Since I cover a lot of topics around backup, recovery, and availability this feature intrigued me.
NOTE: DGPDB is NOT supported with the tooling on DBCS and by testing it in your environment as I am going to do here your databases will not be supported.
First I am going to start with the documentation which can be found here.
My Environment :
I created 2 database services in ExaCS, both of which are 23c databases that are TDE encrypted (since they are in DBCS), and I am using a locally managed key (local wallet file).
| CDB Name | DB Unique Name | PDB name |
|---|---|---|
| cdb1 | cdb1_c83_iad | pdb1 |
| cdb2 | cdb2_cdx_iad | cdb2_pdb2 |
Step # 1 - Prepare the 2 CDBs
The first step is to prepare the 2 CDBs and follow the steps in the documentation
On both databases execute
- ALTER DATABASE FORCE LOGGING;
- ALTER DATABASE FLASHBACK ON;
On the source database execute
- alter system set dg_broker_start=true scope=both;
- alter system set log_archive_dest_1="LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=cdb1_c83_iad";
- alter system set standby_file_management=auto scope=both; ;
On the destination database execute
- alter system set dg_broker_start=true scope=both;
- alter system set log_archive_dest_1="LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=cdb2_cdx_iad";
- alter system set standby_file_management=auto scope=both;
Step # 2 - Configure tnsname.oras and SEPS wallets
First I am going to ensure that both tnsnames.ora files contains entries for both CDBs.
- CDB1_C83_IAD
- CDB2_CDX_IAD
Next I create a SEPS wallet on both nodes, and add entries for both databases
mkdir -p $ORACLE_HOME/dbs/wallets/dgpdb
mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -createALO
mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -createCredential cdb1_c83_iad sys {password}
mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -createCredential cdb2_cdx_iad sys {password}
mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -listCredential
Then I update the sqlnet.ora to use this wallet file.
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/product/23.0.0.0/dbhome_1/dbs/wallets/dgpdb)
)
)
SQLNET.WALLET_OVERRIDE = TRUE
And finally I test the connection
- sqlplus /@cdb1_c83_iad as sysdba
- sqlplus /@cdb2_cdx_iad as sysdba
Step # 3 - Create source and target configuration
Configure the source
dgmgrl /@cdb1_c83_iad <<EOF
CREATE CONFIGURATION 'cdb1_c83_iad' AS CONNECT IDENTIFIER IS cdb1_c83_iad;
SHOW CONFIGURATION;
EOF
Configure the target
dgmgrl /@cdb2_cdx_iad <<EOF
CREATE CONFIGURATION 'cdb2_cdx_iad' AS CONNECT IDENTIFIER IS cdb2_cdx_iad;
SHOW CONFIGURATION;
EOF
Step # 4 - Establish the connection between configurations
I ran the step in the documentation to configure the connection.
dgmgrl /@cdb1_c83_iad <<EOF
ADD CONFIGURATION 'cdb2_cdx_iad' CONNECT IDENTIFIER IS cdb2_cdx_iad;
SHOW CONFIGURATION;
ENABLE CONFIGURATION ALL;
SHOW CONFIGURATION;
EOF
And I validated that the output looked correct.
Configuration - cdb1_c83_iadProtection Mode: MaxPerformanceMembers:cdb1_c83_iad - Primary databasecdb2_cdx_iad - Primary database in cdb2_cdx_iad configurationFast-Start Failover: DisabledConfiguration Status:SUCCESS (status updated 1 second ago)
Step # 5 - Prepare the databases for DGPDB
The first step was to ensure that the PDBS are open in both database, which they are.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
SQL>
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 CDB2_PDB1 READ WRITE NO
SQL>
Then prepare the databases for DGPDB
dgmgrl /@cdb1_c83_iad
DGMGRL for Linux: Release 23.0.0.0.0 - Production on Thu Sep 28 17:40:38 2023
Version 23.3.0.23.09
Copyright (c) 1982, 2023, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "cdb1_c83_iad"
Connected as SYSDBA.
DGMGRL> EDIT CONFIGURATION PREPARE DGPDB;
Enter password for DGPDB_INT account at cdb1_c83_iad:
Enter password for DGPDB_INT account at cdb2_cdx_iad:
Prepared Data Guard for Pluggable Database at cdb2_cdx_iad.
Prepared Data Guard for Pluggable Database at cdb1_c83_iad.
DGMGRL>
Step # 6 - Restart the listeners and databases with the wallet location
On both the source and destination, I performed an "su - grid" and restarted the listeners.
I also restarted both databases. Until I restarted the databases I kept getting a
"Error: ORA-12578: A wallet file was not found or failed to open."
error message.
Step # 7 - Add the pluggable database to the destination
The next step is to add the pluggable database to the destination in dgmgrl.
DGMGRL> add pluggable database pdb1_stby at cdb2_cdx_iad source is pdb1 at cdb1_c83_iad pdbfilenameconvert is "'+DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/','+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/'" ;
ORA-46697: Keystore password required.
Help: https://docs.oracle.com/error-help/db/ora-46697/
At this point by following the documentation, adding the pluggable database failed with "ORA-46697: Keystore password required."
After some digging I found that I need to pass the wallet password (which is my sys password), and that the phrase needs to be in single quotes.
DGMGRL> add pluggable database pdb1_stby at cdb2_cdx_iad source is pdb1 at cdb1_c83_iad pdbfilenameconvert is "'+DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/','+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/'" 'keystore IDENTIFIED BY "W3lCom3#123#123"';
Pluggable Database "PDB1_STBY" added
Step # 8 - List datafiles in the source PDB
FILE# NAME
---------- ------------------------------------------------------------------------------------------------------------------------
8 +DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/system.273.1148746431
9 +DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/sysaux.270.1148746437
10 +DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/undotbs1.271.1148746445
12 +DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/users.274.1148746543
Step # 9 - Copy the datafiles to the destination
First I logged onto the primary database and closed it.
alter pluggable database pdb1 close;
I decided to use DBMS_FILE_TRANSFER.GET_FILE
Step 9a - create directory on source pointing to datafiles
SQL*Plus: Release 23.0.0.0.0 - Production on Fri Sep 29 11:33:11 2023
Version 23.3.0.23.09
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 23c EE High Perf Release 23.0.0.0.0 - Production
Version 23.3.0.23.09
SQL> create directory SOURCE_DUMP as '+DATA/CDB1_C83_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/';
Directory created.
SQL> grant read,write on directory SOURCE_DUMP to public;
Grant succeeded.
SQL>
Step 9b - Log onto ASM and precreate directory
ASMCMD> mkdir
+data/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/datafile
Step 9c - create directory on target pointing to datafiles
[oracle@cdb1 admin]$ sqlplus /@cdb2_cdx_iad as sysdba
SQL*Plus: Release 23.0.0.0.0 - Production on Fri Sep 29 11:33:44 2023
Version 23.3.0.23.09
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 23c EE High Perf Release 23.0.0.0.0 - Production
Version 23.3.0.23.09
SQL> create directory TARGET_DUMP as '+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/';
grant read,write on directory TARGET_DUMP to public;
Directory created.
SQL> SQL>
Grant succeeded.
Step 9d - create database link on target pointing to source database
SQL> SQL> SQL> create public database link SOURCEDB connect to system identified by {password} using 'CDB1_C83_IAD';
Database link created.
SQL> select sysdate from dual@SOURCEDB;
select sysdate from dual@SOURCEDB
*
ERROR at line 1:
ORA-02085: database link SOURCEDB.ZFSADMIN.VCN.ORACLEVCN.COM connects to
CDB1.ZFSADMIN.VCN.ORACLEVCN.COM
Help: https://docs.oracle.com/error-help/db/ora-02085/
SQL> show parameter global
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
allow_global_dblinks boolean FALSE
global_names boolean TRUE
global_txn_processes integer 1
SQL> alter system set global_names=false;
System altered.
SQL> select sysdate from dual@SOURCEDB;
SYSDATE
---------
29-SEP-23
SQL>
Step 9e - Get the datafiles from the source
SQL> set timing on
BEGIN
dbms_file_transfer.get_file('SOURCE_DUMP',
'system.273.1148746431',
'SOURCEDB',
'TARGET_DUMP',
'SYSTEM.DBF');
END;
/SQL> 2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.21
Step # 10 - Rename datafiles in the destination.
List the placeholder datafiles in destination database
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 CDB2_PDB1 READ WRITE NO
4 PDB1_STBY MOUNTED
SQL> alter session set container=pdb1_stby;
Session altered.
Elapsed: 00:00:00.02
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/MUST_RENAME_THIS_DATAFILE_8.4294967295.4294967295
+DATA/MUST_RENAME_THIS_DATAFILE_9.4294967295.4294967295
+DATA/MUST_RENAME_THIS_DATAFILE_10.4294967295.4294967295
+DATA/MUST_RENAME_THIS_DATAFILE_12.4294967295.4294967295
Elapsed: 00:00:00.02
SQL>
Match the file number in the destination files to the source datafiles and rename them.
SQL> alter database rename file '+DATA/MUST_RENAME_THIS_DATAFILE_8.4294967295.4294967295' to '+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/SYSTEM.dbf';
Database altered.
Elapsed: 00:00:00.04
SQL> alter database rename file '+DATA/MUST_RENAME_THIS_DATAFILE_9.4294967295.4294967295' to '+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/SYSAUX.dbf';
Database altered.
Elapsed: 00:00:00.02
SQL> alter database rename file '+DATA/MUST_RENAME_THIS_DATAFILE_10.4294967295.4294967295' to '+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/UNDOTBS1.dbf';
Database altered.
Elapsed: 00:00:00.05
SQL> alter database rename file '+DATA/MUST_RENAME_THIS_DATAFILE_12.4294967295.4294967295' to '+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/USERS.dbf';
Database altered.
Elapsed: 00:00:00.03
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/system.dbf
+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/sysaux.dbf
+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/undotbs1.dbf
+DATA/CDB2_CDX_IAD/066E9679DE2850DCE063A104000ABBA7/DATAFILE/users.dbf
Elapsed: 00:00:00.02
SQL>
Step # 11 - Bring over the TDE keys
Export the encryption keys from the source database
SQL> ADMINISTER KEY MANAGEMENT
EXPORT ENCRYPTION KEYS WITH SECRET "export_secret"
TO '/tmp/mykey'
FORCE KEYSTORE
IDENTIFIED BY "{password}"; 2 3 4 5
keystore altered.
Import them into the target database
ADMINISTER KEY MANAGEMENT
IMPORT KEYS WITH SECRET "export_secret"
FROM '/tmp/mykeypdb1'
force keystore
IDENTIFIED BY "W3lCom3#123#123"
WITH BACKUP;
SQL> SQL> 2 3 4 5 6
keystore altered.
SQL> SQL>
List the encryption keys on the source database
PDB Name Key ID Master Key ID
--------------- ----------------------------------- -------------------------
CDB$ROOT 35B424EFDB6D4F19BFF31B5D3DE0BFFA ATW0JO/bbU8Zv/MbXT3gv/o=
PDB$SEED 00000000000000000000000000000000 AQAAAAAAAAAAAAAAAAAAAAA=
PDB1 1AAD19EB6F364F3BBF6FE226A25AF1E5 ARqtGetvNk87v2/iJqJa8eU=
List the encryption keys on the destination database
Master Key ID Tag PDB Name KEYSTORE_TYPE Origin Key Creation Time Key Act. Time
------------------------------------------------------- -------------------- --------------- ----------------- ---------- ------------------ ------------------
AZ5CKuJLrU/Nv5M5pXQCFcEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CDB$ROOT SOFTWARE KEYSTORE LOCAL 09/28/2023 09:09 09/28/2023 09:09
ATW0JO/bbU8Zv/MbXT3gv/oAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CDB$ROOT SOFTWARE KEYSTORE LOCAL 09/28/2023 09:10 09/28/2023 09:10
AVAymCcev0/Pv94Tiqw/P50AAAAAAAAAAAAAAAAAAAAAAAAAAAAA CDB2_PDB1 SOFTWARE KEYSTORE LOCAL 09/28/2023 09:12 09/28/2023 09:12
ARqtGetvNk87v2/iJqJa8eUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CDB2_PDB1 SOFTWARE KEYSTORE LOCAL 09/28/2023 09:13 09/28/2023 09:13
Step # 12 - Add the standby redo logs to the PDB and validate
I created standby redo logs in the PDB on Target database
select 'ALTER DATABASE ADD STANDBY LOGFILE thread ' ||a.thread# || ' group 1' ||a.group# || ' (''' ||substr(b.member,1,35) || 'standby_pdb1_1' || a.group# || ''') size ' || a.bytes ||';'
from v$log a, v$logfile b
where a.group#=b.group# ;SQL> 2 3
'ALTERDATABASEADDSTANDBYLOGFILETHREAD'||A.THREAD#||'GROUP1'||A.GROUP#||'('''||SUBSTR(B.MEMBER,1,35)||'STANDBY_PDB1_1'||A.GROUP#||'
----------------------------------------------------------------------------------------------------------------------------------
ALTER DATABASE ADD STANDBY LOGFILE thread 1 group 13 ('+RECO/CDB2_CDX_IAD/ONLINELOG/group_standby_pdb1_13') size 1073741824;
ALTER DATABASE ADD STANDBY LOGFILE thread 1 group 12 ('+RECO/CDB2_CDX_IAD/ONLINELOG/group_standby_pdb1_12') size 1073741824;
ALTER DATABASE ADD STANDBY LOGFILE thread 1 group 11 ('+RECO/CDB2_CDX_IAD/ONLINELOG/group_standby_pdb1_11') size 1073741824;
SQL> alter session set container=PDB1_STBY;
Session altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE thread 1 group 4 ('+RECO/CDB2_CDX_IAD/ONLINELOG/group_standby_pdb1_13') size 1073741824;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE thread 1 group 5 ('+RECO/CDB2_CDX_IAD/ONLINELOG/group_standby_pdb1_12') size 1073741824;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE thread 1 group 6 ('+RECO/CDB2_CDX_IAD/ONLINELOG/group_standby_pdb1_11') size 1073741824;
Database altered.
SQL>
And then I validated the configuration
DGMGRL> VALIDATE PLUGGABLE DATABASE PDB1_STBY AT cdb2_cdx_iad;
Ready for Switchover: NO
Data Guard Role: Physical Standby
Apply State: Not Running
Standby Redo Log Files: 3
Source: PDB1 (con_id 3) at cdb1_c83_iad
Step # 13 - change the state of standby to APPLY-ON
I changed the state of the standby and checked the configuration.
DGMGRL> VALIDATE PLUGGABLE DATABASE PDB1_STBY AT cdb2_cdx_iad;
Ready for Switchover: NO
Data Guard Role: Physical Standby
Apply State: Not Running
Standby Redo Log Files: 3
Source: PDB1 (con_id 3) at cdb1_c83_iad
DGMGRL>
EDIT PLUGGABLE DATABASE PDB1_STBY AT cdb2_cdx_iad SET STATE='APPLY-ON';DGMGRL>
Succeeded.
DGMGRL> SHOW CONFIGURATION;
Configuration - cdb2_cdx_iad
Protection Mode: MaxPerformance
Members:
cdb2_cdx_iad - Primary database
Warning: ORA-16910: inconsistency detected for one or more pluggable databases
cdb1_c83_iad - Primary database in cdb1_c83_iad configuration
Data Guard for PDB: Enabled in TARGET role
Configuration Status:
SUCCESS (status updated 37 seconds ago)
DGMGRL> SHOW PLUGGABLE DATABASE pdb1 AT cdb1_c83_iad;
Pluggable database - PDB1 at cdb1_c83_iad
Data Guard Role: Primary
Con_ID: 3
Active Target: con_id 4 at cdb2_cdx_iad
Pluggable Database Status:
SUCCESS
DGMGRL> SHOW PLUGGABLE DATABASE pdb1_stby AT cdb2_cdx_iad ;
Pluggable database - PDB1_STBY at cdb2_cdx_iad
Data Guard Role: Physical Standby
Con_ID: 4
Source: con_id 3 at cdb1_c83_iad
Transport Lag: 20 hours 26 minutes 24 seconds (computed 9 seconds ago)
Apply Lag: (unknown)
Intended State: APPLY-ON
Apply State: Running
Apply Instance: cdb2
Average Apply Rate: (unknown)
Real Time Query: OFF
Pluggable Database Status:
SUCCESS
DGMGRL> VALIDATE PLUGGABLE DATABASE PDB1_STBY AT cdb2_cdx_iad;
Ready for Switchover: NO
Data Guard Role: Physical Standby
Apply State: Waiting for Redo Data
Standby Redo Log Files: 3
Source: PDB1 (con_id 3) at cdb1_c83_iad
DGMGRL>
Step # 14 - Perform a log switch at both databases
sqlplus /@cdb1_c83_iad as sysdba
SQL*Plus: Release 23.0.0.0.0 - Production on Fri Sep 29 15:57:52 2023
Version 23.3.0.23.09
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 23c EE High Perf Release 23.0.0.0.0 - Production
Version 23.3.0.23.09
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.
SQL> exit
Disconnected from Oracle Database 23c EE High Perf Release 23.0.0.0.0 - Production
Version 23.3.0.23.09
[oracle@cdb2 admin]$ sqlplus /@cdb2_cdx_iad as sysdba
SQL*Plus: Release 23.0.0.0.0 - Production on Fri Sep 29 15:58:11 2023
Version 23.3.0.23.09
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 23c EE High Perf Release 23.0.0.0.0 - Production
Version 23.3.0.23.09
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.
SQL>
Step # 15 - Validate standby is applying redo.
DGMGRL> SHOW PLUGGABLE DATABASE pdb1_stby AT cdb2_cdx_iad ;
Pluggable database - PDB1_STBY at cdb2_cdx_iad
Data Guard Role: Physical Standby
Con_ID: 4
Source: con_id 3 at cdb1_c83_iad
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 4 seconds (computed 1 second ago)
Intended State: APPLY-ON
Apply State: Running
Apply Instance: cdb2
Average Apply Rate: 489 KByte/s
Real Time Query: OFF
Pluggable Database Status:
SUCCESS
SUMMARY :
This is an exciting new feature, and I am looking forward to see it expand.
Since a target database, can only have one source, I see this being useful to "pair" CDBs.
Instead of having 2 Primary CDBs in DC1 (for example) and 2 standby CDBs in DC2 you would have 2 Primary CDBs in in each Data Center, and you would be able to switch over any PDBs individually.
Since this is a paradigm change for RMAN, I am going to be following how this affects RMAN, the RMAN catalogs, and the ZDLRA/Recovery Service in it's support.
Finally :
It is all working, and for fun I am going to look at the destination settings on the source Database.
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=cdb1_c83_iad
log_archive_dest_2 string service="cdb2_cdx_iad", ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 reopen=300 db_unique_name="cdb2_cdx_iad" net_timeout=30, valid_for=(online_logs)
Today I did have time to perform a switchover and a second switchover to bring it back.
Because my database is encrypted, I did import the keys from CDB2 into CDB1. I am thinking when you implement this with TDE, you do need to keep the keys from both CDBs syncronized.
In OKV, I'm thinking you would want to possibly even use a single wallet. At the very least both primary databases would need access to both wallets.
OBSERVATIONS:
I will continue to update this post as I find useful observations.
Observation 1 :
I looked at the archive log using v$archived_logs view in the target (CDB2).
In it I only 6 archive logs were created.
SQL> select thread#,sequence#,dest_id,blocks,status from v$ARCHIVED_LOG;
THREAD# SEQUENCE# DEST_ID BLOCKS S
---------- ---------- ---------- ---------- -
1 2 1 230208 A
1 3 1 896391 A
1 4 1 7 A
1 5 1 35474 A
1 6 1 387 A
I then created a workload in both PDBS and looked at the archive logs on the source.
THREAD# SEQUENCE# DEST_ID BLOCKS S
---------- ---------- ---------- ---------- -
1 3 2 4894 A
1 4 2 567681 A
1 5 2 14 A
1 6 2 871136 A
1 7 2 1756544 A
1 8 2 1847012 A
1 9 2 1931501 A
1 10 2 1901263 A
1 11 2 1931491 A
1 12 2 1931837 A
1 13 2 1465002 A
1 14 2 1955017 A
1 15 2 1936946 A
1 16 2 1685507 A
1 17 2 1931499 A
1 18 2 1808038 A
1 19 2 1874455 A
1 20 2 1910501 A
1 21 2 2038138 A
1 22 2 1812968 A
1 23 2 1935941 A
1 24 2 1939459 A
1 25 2 2030413 A
1 26 2 1934927 A
24 rows selected.
Then I looked at ASM on the target and I could ALL the archive logs on the target.
ASMCMD> ls
thread_1_seq_10.282.1148837541
thread_1_seq_11.283.1148837541
thread_1_seq_12.284.1148837557
thread_1_seq_13.285.1148837667
thread_1_seq_14.287.1148837943
thread_1_seq_15.288.1148837963
thread_1_seq_16.289.1148837979
thread_1_seq_17.290.1148837979
thread_1_seq_18.291.1148838023
thread_1_seq_19.292.1148838023
thread_1_seq_20.293.1148838101
thread_1_seq_21.294.1148838119
thread_1_seq_22.295.1148838137
thread_1_seq_23.296.1148838137
thread_1_seq_24.297.1148838183
thread_1_seq_25.298.1148838213
thread_1_seq_26.299.1148838237
thread_1_seq_3.275.1148831895
thread_1_seq_4.276.1148831899
thread_1_seq_5.274.1148831883
thread_1_seq_5.278.1148837115
thread_1_seq_6.277.1148836711
thread_1_seq_6.286.1148837681
thread_1_seq_7.279.1148837481
thread_1_seq_8.280.1148837499
thread_1_seq_9.281.1148837517
Observation 2 :
RMAN does not support this feature at this point.
What I have
discovered is that
- Within the CDB,
V$ARCHIVED_LOG does not recognize archive logs from the second primary
needed to recovery the standby
- Within the CDB,
V$DATAFILE does not recognize the datafiles for the “standby database”
- Within the standby PDB,
V$DATAFILE recognizes the datafiles for that standby database, and only
the standby datafiles
- Within the standby PDB
V$ARCHIVED_LOG only sees this archive logs for the standby database, and
not the local archive logs produced
- When executing RMAN for
the CDB, only the locally produced archive logs are backed up
- When executing RMAN for
the CDB, only the primary datafiles are backed up.
- When executing RMAN for
the standby PDB, no datafiles are backed up. “pluggable database
PDB1_STBY does not have any data files”
- When executing RMAN for
the standby PDB, only the primary database’s locally produced archive logs
are backed up.
SUMMARY – with DGPDB
