在12.1.0.2中，在创建PDB时有了一个新的选项（STANDBYS=NONE），允许在备库上延迟创建PDB（PDB目录结构会创建，但在备库上属于新的PDB的所有文件被标示为OFFLOINE/RECOVER），除了这个新的PDB不能打开，其他已有的PDB都可以处于READ ONLY的状态，可以继续应用日志，持续保护。我们可以通过查询v$pdb.recovery_sttaus来查询PDB是否处于保护状态（有两种状态，ENABLED和DISABLED）。
延迟创建PDB后，在将来的某个时间，我们再将文件复制到备库并启用PDB的恢复，再开始对PDB进行数据保护。Oracle提供了工具，可以在PDB打开的时候将文件从主库复制到备库。在备库上，我们只需暂时停止应用redo，将数据库启动到mount状态做恢复，恢复后继续应用redo即可。
可能使用延迟创建PDB的几个场景
1.用CREATE PLUGGABLE DATABASE做远程克隆且备库上redo应用启用时，因为我们不能将文件预复制到物理备用数据库，并确保它们处于正确的状态
2.用于临时测试或临时用，会很快被删除，因此不需要数据保护
3.备用环境中PDB的存储空间，暂时不够，需要扩容
4.比如在主库上创建pdb后，对应的应用可能着急使用。复制文件到备库还需要时间，为了减小影响
5.在某些情况下，新创建的PDB不需要更高级别的数据保护，我们可以永久禁用（MAA团队不建议使用这种方式）
影响备库上创建pdb的因素有两个，分6个场景
在CDB的Data Guard环境中，启用了ADG，如果是通过本地clone创建pdb，备库上不需要做任何操作。如何是remote clone，就需要使用standbys=none的选项，也就是本文中所操作的。如果是通过xml文件创建pdb，在主库上执行plug之前，需要把文件复制到备库和主库同样的目录，然后再执行plug。当然在主库上还可能drop pdb，unplug等操作。如果是非CDB，和之前的操作一样。
当前环境的配置信息：主库yodaprim，备库yodastby，参考了Note1916648.1。在主库上已经创建了5个PDB，并且和备库是同步的。我们会在主库上通过远程克隆的方式，创建一个pdb006。并做了switchover和failover操作，最后对备库上的pdb006进行了恢复操作。在使用延迟创建pdb时，对主备库角色的切换没有影响。我们需要做的就是，把主库的文件复制过去，针对PDB做恢复就好了，这个特性很不错。
当前Data Guard配置信息DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodaprim - Primary database
yodastby - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 11 seconds ago)
DGMGRL> validate database yodastby
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
主库信息，目前创建了5个pdbSQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string yodaprim
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PRIMARY
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ WRITE NO
4 PDB0002 READ WRITE NO
5 PDB0003 READ WRITE NO
6 PDB0004 READ WRITE NO
7 PDB0005 READ WRITE NO
备库信息，也是5个pdbSQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string yodastby
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ ONLY NO
4 PDB0002 READ ONLY NO
5 PDB0003 READ ONLY NO
6 PDB0004 READ ONLY NO
7 PDB0005 READ ONLY NO
SQL> select name, recovery_status from v$pdbs;
NAME RECOVERY
------------------------------ --------
PDB$SEED ENABLED
PDB0001 ENABLED
PDB0002 ENABLED
PDB0003 ENABLED
PDB0004 ENABLED
PDB0005 ENABLED
6 rows selected.
在主库上创建一个pdb006，用的方式是STANDBYS=NONE;SQL> create pluggable database pdb0006 from pdb1025@cdb200 tempfile reuse STANDBYS=NONE;
Pluggable database created.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ WRITE NO
4 PDB0002 READ WRITE NO
5 PDB0003 READ WRITE NO
6 PDB0004 READ WRITE NO
7 PDB0005 READ WRITE NO
8 PDB0006 MOUNTED
SQL> alter pluggable database pdb0006 open;
Pluggable database altered.
在备库上我们可以看到，pdb006没有启用恢复状态。并且尝试在备库上打开pdb006时会报错。SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ ONLY NO
4 PDB0002 READ ONLY NO
5 PDB0003 READ ONLY NO
6 PDB0004 READ ONLY NO
7 PDB0005 READ ONLY NO
8 PDB0006 MOUNTED
SQL> select name, recovery_status from v$pdbs;
NAME RECOVERY
------------------------------ --------
PDB$SEED ENABLED
PDB0001 ENABLED
PDB0002 ENABLED
PDB0003 ENABLED
PDB0004 ENABLED
PDB0005 ENABLED
PDB0006 DISABLED
7 rows selected.
SQL> alter session set container=pdb0006;
Session altered.
SQL> set lines 120
SQL> set pages 9999
SQL> col name format a65
SQL> select name, status from v$datafile;
NAME STATUS
----------------------------------------------------------------- -------
/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED00178 SYSOFF
/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED00179 RECOVER
/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED00180 RECOVER
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME CON_ID
---------- ------- ------- ---------- ---------- --------- ----------
178 OFFLINE OFFLINE 79225498 11-AUG-14 8
179 OFFLINE OFFLINE 79225498 11-AUG-14 8
180 OFFLINE OFFLINE 79225498 11-AUG-14 8
SQL> alter pluggable database pdb0006 open;alter pluggable database pdb0006 open
*
ERROR at line 1:
ORA-01147: SYSTEM tablespace file 178 is offline
alert日志中关于在备库上创建pdb006的信息
Xxx Xxx NN NN:NN:NN NNNN Recovery created pluggable database PDB0006 Recovery scanning directory +DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE for any matching files File #178 added to control file as 'UNNAMED00178'. Originally created as: '+DA1/YODAPRIM/0063D458AAACA633E0537A28890A6CD1/DATAFILE/system.584.855343419' because the pluggable database was created with nostandby or the tablespace belonging to the pluggable database is offline. File #179 added to control file as 'UNNAMED00179'. Originally created as: '+DA1/YODAPRIM/0063D458AAACA633E0537A28890A6CD1/DATAFILE/sysaux.593.855343419' because the pluggable database was created with nostandby or the tablespace belonging to the pluggable database is offline. File #180 added to control file as 'UNNAMED00180'. Originally created as: '+DA1/YODAPRIM/0063D458AAACA633E0537A28890A6CD1/DATAFILE/soets.696.855343419' because the pluggable database was created with nostandby or the tablespace belonging to the pluggable database is offline.切换前验证，我们看到还是有很多错误，不过不影响正常切换
DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodaprim - Primary database
yodastby - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 15 seconds ago)
DGMGRL> validate database yodastby
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Temporary Tablespace File Information:
yodaprim TEMP Files: 8
yodastby TEMP Files: 7
DGMGRL> validate database yodastby
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: No (Primary Running)
Temporary Tablespace File Information:
yodaprim TEMP Files: 8
yodastby TEMP Files: 7
Automatic Diagnostic Repository Errors:
Error yodaprim yodastby
System data file offline NO YES
User data file offline NO YES
RMAN> list failure;
using target database control file instead of recovery catalog
Database Role: PHYSICAL STANDBY
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
3347 CRITICAL OPEN 13-AUG-14 System datafile 181: '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED00181' is offline
3368 HIGH OPEN 13-AUG-14 Name for datafile 183 is unknown in the control file
360 HIGH OPEN 13-AUG-14 One or more non-system datafiles are offline
3359 HIGH OPEN 13-AUG-14 Name for datafile 182 is unknown in the control file
3350 HIGH OPEN 13-AUG-14 Name for datafile 181 is unknown in the control file
3302 HIGH OPEN 13-AUG-14 Datafiles are mutually inconsistent
正式做切换（switchover），并查看DG配置信息DGMGRL> switchover to yodastby
Performing switchover NOW, please wait...
Operation requires a connection to instance "yodastby" on database "yodastby"
Connecting to instance "yodastby"...
Connected as SYSDBA.
New primary database "yodastby" is opening...
Oracle Clusterware is restarting database "yodaprim" ...
Switchover succeeded, new primary is "yodastby"
DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodastby - Primary database
yodaprim - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 14 seconds ago)
DGMGRL> validate database yodastby
Database Role: Primary database
Ready for Switchover: Yes
DGMGRL> validate database yodaprim
Database Role: Physical standby database
Primary Database: yodastby
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Temporary Tablespace File Information:
yodastby TEMP Files: 7
yodaprim TEMP Files: 8
切换后，备库成主库，这时新的主库中的PDB006还是处于mounted状态SQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string yodastby
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ WRITE NO
4 PDB0002 READ WRITE NO
5 PDB0003 READ WRITE NO
6 PDB0004 READ WRITE NO
7 PDB0005 READ WRITE NO
8 PDB0006 MOUNTED
切换后，主库成备库，这时新的主库中的PDB006还是处于read only状态。
注意：因为是备库，所以只能read only，这个是正常的
SQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string yodaprim
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 MOUNTED
4 PDB0002 MOUNTED
5 PDB0003 MOUNTED
6 PDB0004 MOUNTED
7 PDB0005 MOUNTED
8 PDB0006 MOUNTED
SQL> alter pluggable database all open;
Pluggable database altered.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ ONLY NO
4 PDB0002 READ ONLY NO
5 PDB0003 READ ONLY NO
6 PDB0004 READ ONLY NO
7 PDB0005 READ ONLY NO
8 PDB0006 READ ONLY NO
刚才尝试了异常switchover，我们可以通过switchover再回到原来的状态。
我们也可以用failover的方式来切换到原始状态。在新主库上执行shut abort。然后做failover。
SQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string yodastby
SQL> shutdown abort
ORACLE instance shut down.
DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodastby - Primary database
Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
yodaprim - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR (status updated 0 seconds ago)
DGMGRL> failover to yodaprim
Performing failover NOW, please wait...
Failover succeeded, new primary is "yodaprim"
DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodaprim - Primary database
yodastby - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 14 seconds ago)
Failover之后，主库还是主库，我们重新初始化下备库。因为启用了flashback，所以非常方便DGMGRL> reinstate database yodastby
Reinstating database "yodastby", please wait...
Reinstatement of database "yodastby" succeeded
DGMGRL> validate database yodastby
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Temporary Tablespace File Information:
yodaprim TEMP Files: 8
yodastby TEMP Files: 7
关闭归档删除策略，然后在备库上停止应用日志RMAN> show archivelog deletion policy;
RMAN configuration parameters for database with db_unique_name YODAPRIM are:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
RMAN> configure archivelog deletion policy to none;
old RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
new RMAN configuration parameters are successfully stored
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ WRITE NO
4 PDB0002 READ WRITE NO
5 PDB0003 READ WRITE NO
6 PDB0004 READ WRITE NO
7 PDB0005 READ WRITE NO
8 PDB0006 READ WRITE NO
DGMGRL> edit database yodastby set state='apply-off';
Succeeded.
DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodaprim - Primary database
yodastby - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 30 seconds ago)
连接备库，把文件从主库复制到备库上restore pluggable database pdb0006 from service yodaprim;在主库PDB打开的时候，就可以用，这个命令非常方便
RMAN> connect target sys@yodastby
target database Password:
connected to target database: YODAPRIM (DBID=663359056, not open)
RMAN> @copy.cmd
RMAN> run{
2> set newname for pluggable database pdb0006 to new;
3> restore pluggable database pdb0006 from service yodaprim;
4> switch datafile all;
5> }
executing command: SET NEWNAME
Starting restore at 12-AUG-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=585 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=774 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=967 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service yodaprim
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00178 to +DATA
channel ORA_DISK_2: starting datafile backup set restore
channel ORA_DISK_2: using network backup set from service yodaprim
channel ORA_DISK_2: specifying datafile(s) to restore from backup set
channel ORA_DISK_2: restoring datafile 00179 to +DATA
channel ORA_DISK_3: starting datafile backup set restore
channel ORA_DISK_3: using network backup set from service yodaprim
channel ORA_DISK_3: specifying datafile(s) to restore from backup set
channel ORA_DISK_3: restoring datafile 00180 to +DATA
channel ORA_DISK_1: restore complete, elapsed time: 00:00:24
channel ORA_DISK_2: restore complete, elapsed time: 00:00:21
channel ORA_DISK_3: restore complete, elapsed time: 00:03:04
Finished restore at 12-AUG-14
datafile 178 switched to datafile copy
input datafile copy RECID=38 STAMP=855397781 file name=+DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE/system.296.855397779
datafile 179 switched to datafile copy
input datafile copy RECID=39 STAMP=855397794 file name=+DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE/sysaux.365.855397781
datafile 180 switched to datafile copy
input datafile copy RECID=40 STAMP=855397960 file name=+DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE/soets.293.855397807
RMAN> **end-of-file**
在备库上启动到mount状态，然后切换到pdb006，再做恢复SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 4831838208 bytes Fixed Size 3720600 bytes Variable Size 1308625512 bytes Database Buffers 3506438144 bytes Redo Buffers 13053952 bytes Database mounted. SQL> alter session set container=pdb0006; Session altered. SQL> show con_name CON_NAME ------------------------------ PDB0006 SQL> alter pluggable database enable recovery; Pluggable database altered.然后在备库上应用日志并查看，这时备库上的pdb006已经恢复正常了
DGMGRL> edit database yodastby set state='apply-on';
Succeeded.
Verify the physical standby database in the Data Guard Broker
DGMGRL> validate database yodastby
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Temporary Tablespace File Information:
yodaprim TEMP Files: 8
yodastby TEMP Files: 7
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
SQL> alter database open;
Database altered.
NOTE：it may take 30s for redo apply to restart
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
# Open the PDB if necessary
SQL> alter pluggable database pdb0006 open;
Pluggable database altered.
SQL> alter session set container=pdb0006;
Session altered.
SQL> alter tablespace temp add tempfile size 20g;
Tablespace altered.
SQL> select name, status from v$datafile;
NAME STATUS
------------------------------------------------------------------------------------- -------
+DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE/system.296.855397779 SYSTEM
+DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE/sysaux.365.855397781 RECOVER
+DATA/YODASTBY/0063D458AAACA633E0537A28890A6CD1/DATAFILE/soets.293.855397807 RECOVER
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME CON_ID
---------- ------- ------- ---------- ---------- --------- ----------
178 ONLINE ONLINE 79225498 11-AUG-14 8
179 ONLINE ONLINE 79225498 11-AUG-14 8
180 ONLINE ONLINE 79225498 11-AUG-14 8
SQL> select name, recovery_status from v$pdbs where name = 'PDB0006';
NAME RECOVERY
------------------------- --------
PDB0006 ENABLED
再次校验，并配置归档删除策略。到此，pdb006在备库上已恢复，所有操作结束。DGMGRL> validate database yodastby Database Role: Physical standby database Primary Database: yodaprim Ready for Switchover: Yes Ready for Failover: Yes (Primary Running) RMAN> show archivelog deletion policy; using target database control file instead of recovery catalog RMAN configuration parameters for database with db_unique_name YODASTBY are: CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default RMAN> configure archivelog deletion policy to APPLIED ON ALL STANDBY; new RMAN configuration parameters: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; new RMAN configuration parameters are successfully stored
如何Disable PDB Recovery
DGMGRL>edit database yodastby set state='apply-off';
SQL> alter session set container=pdb0006;
SQL> alter pluggable database disable recovery;
DGMGRL>edit database yodastby set state='apply-on';
DGMGRL> edit database yodastby set state='apply-off'; Succeeded. SQL> alter session set container=pdb0006; Session altered. SQL> alter pluggable database disable recovery; Pluggable database altered. DGMGRL> edit database yodastby set state='apply-on'; Succeeded.
SQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string yodastby
SQL> alter database open;
Database altered.
SQL> alter pluggable database all open;
alter pluggable database all open
*
ERROR at line 1:
ORA-01147: SYSTEM tablespace file 181 is offline
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB0001 READ ONLY NO
4 PDB0002 READ ONLY NO
5 PDB0003 READ ONLY NO
6 PDB0004 READ ONLY NO
7 PDB0005 READ ONLY NO
8 PDB0006 MOUNTED
9 PDB0007 READ ONLY NO
10 PDB0008 READ ONLY NO
11 PDB0009 READ ONLY NO
SQL> alter session set container=pdb0006;
Session altered.
SQL> col name format a85
SQL> select name, status from v$datafile;
NAME STATUS
------------------------------------------------------------------------------------- -------
+DATA/YODASTBY/008AA2A17CBC2A52E0537A28890AF1A8/DATAFILE/system.296.856610895 SYSOFF
+DATA/YODASTBY/008AA2A17CBC2A52E0537A28890AF1A8/DATAFILE/sysaux.269.856610899 RECOVER
+DATA/YODASTBY/008AA2A17CBC2A52E0537A28890AF1A8/DATAFILE/soets.383.856610911 RECOVER
SQL> col error format a10
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME CON_ID
---------- ------- ------- ---------- ---------- --------- ----------
181 OFFLINE OFFLINE 79953149 14-AUG-14 8
182 OFFLINE OFFLINE 79953149 14-AUG-14 8
183 OFFLINE OFFLINE 79953149 14-AUG-14 8
SQL> select name, recovery_status from v$pdbs;
NAME RECOVERY
------------------------------ --------
PDB$SEED ENABLED
PDB0001 ENABLED
PDB0002 ENABLED
PDB0003 ENABLED
PDB0004 ENABLED
PDB0005 ENABLED
PDB0006 DISABLED
PDB0007 ENABLED
PDB0008 ENABLED
PDB0009 ENABLED
10 rows selected.
DGMGRL> show configuration
Configuration - yoda_dg
Protection Mode: MaxPerformance
Members:
yodaprim - Primary database
yodastby - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 46 seconds ago)
DGMGRL> validate database yodastby;
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
If you bounce the standby instance and rerun VALIDATE DATABASE you will see:
DGMGRL> validate database yodastby;
Database Role: Physical standby database
Primary Database: yodaprim
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Automatic Diagnostic Repository Errors:
Error yodaprim yodastby
System data file offline NO YES
User data file offline NO YES
In RMAN, you will see something similar to the following:
RMAN> list failure;
Database Role: PHYSICAL STANDBY
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
4114 CRITICAL OPEN 26-AUG-14 System datafile 181: '+DATA/YODASTBY/008AA2A17CBC2A52E0537A28890AF1A8/DATAFILE/system.296.856610895' is offline
360 HIGH OPEN 26-AUG-14 One or more non-system datafiles are offline
4102 HIGH OPEN 26-AUG-14 Datafiles are mutually inconsistent
Reference
Note 1916648.1 Making use Deferred PDB Recovery and the STANDBYS=NONE Feature with Oracle Multitenant
https://docs.oracle.com/en/database/oracle/oracle-database/18/refrn/ENABLED_PDBS_ON_STANDBY.html
https://docs.oracle.com/database/121/SBYDB/create_ps.htmhttps://docs.oracle.com/en/database/oracle/oracle-database/12.2/sbydb/creating-oracle-data-guard-physical-standby.html
