Before you create a standby database you must first ensure the primary database is properly configured.

These are the tasks you perform to create a physical standby database.

The information in this topic is written at a level of detail that requires you to already have a thorough understanding of the following topics:

• Database administrator authentication

• Database initialization parameters

• Managing redo logs, data files, and control files

• Managing archived redo logs

• Fast recovery areas

• Oracle Net configuration

Table 3-1 provides a checklist of the tasks that you perform to create a physical standby database and the database or databases on which you perform each task.

After the physical standby database is running, you can upgrade the data protection mode, and you can enable Flashback Database.

You can create a physical standby of a multitenant container database (CDB) just as you can create a physical standby of a regular primary database.

The following are some of the behavioral differences to be aware of when you create and use a physical standby of a CDB:

• If you execute a switchover or failover operation, the entire CDB undergoes the role change. If you used the ENABLED_PDBS_ON_STANDBY intialization parameter, then be aware of the possibility that not every PDB is present in both the primary and the standby databases.

• The database role is defined at the CDB level, not at the individual container level.

• Any DDL related to role changes must be executed in the root container because a role is associated with an entire CDB. Individual pluggable databases (PDBs) do not have their own roles.

• In a physical standby of a CDB, the syntax of SQL statements is generally the same as for noncontainer databases. However, the effect of some statements, including the following, may be different:

  • ALTER DATABASE RECOVER MANAGED STANDBY functions only in the root container; it is not allowed in a PDB.

  • A role is associated with an entire CDB; individual PDBs do not have their own roles. Therefore, the following role change DDL associated with physical standbys affect the entire CDB:

    ALTER DATABASE SWITCHOVER TO target_db_name

    ALTER DATABASE ACTIVATE PHYSICAL STANDBY

• The ALTER PLUGGABLE DATABASE [OPEN|CLOSE] SQL statement is supported on the standby, provided you have already opened the root container.

• The ALTER PLUGGABLE DATABASE RECOVER statement is not supported on the standby. (Standby recovery is always at the CDB level.)

• To administer a multitenant environment, you must have the CDB_DBA role.

• Oracle recommends that the standby database have its own keystore.

• In a multitenant environment, the redo must be shipped to the root container of the standby database.

  The following is an example of how to determine whether redo is being shipped to the root container. Suppose your primary database has the following settings:

  LOG_ARCHIVE_DEST_2='SERVICE=boston ASYNC VALID_FOR=(ONLINE_LOGFILES,
  PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
  

  Redo is being shipped to boston. The container ID (CON_ID) for the root container is always 1, so you must make sure that the CON_ID is 1 for the service boston. To do this, check the service name in the tnsnames.ora file. For example:

  boston = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=boston-server)(PORT=1521))
  (CONNECT_DATA=(SERVICE_NAME=boston.us.example.com))
  

  The service name for boston is boston.us.example.com.

  On the standby database, query the CDB_SERVICES view to determine the CON_ID. For example:

  SQL> SELECT NAME, CON_ID FROM CDB_SERVICES;
  
  NAME                                 CON_ID
  ---------------------------------------------
  boston.us.example.com                 1
  

  The query result shows that the CON_ID for boston is 1.

In an Oracle Data Guard configuration, a pluggable database (PDB) on a primary database is created in the same way that a PDB on a regular database is created.

This topic lists key points about how Data Guard and the Oracle Multitenant option interact when any type of PDB creation is performed. For detailed information and examples, see My Oracle Support note 2049127.1 at http://support.oracle.com.

The steps to create a PDB on a regular database are documented in the Oracle Multitenant Administrator's Guide. Before following those steps, be sure to read the following:

• You can specify a subset of PDBs to be replicated on a physical standby of a multitenant container database (CDB). To do so, use the ENABLED_PDBS_ON_STANDBY initialization parameter to specify a list of PDBs or use the STANDBYS clause on the CREATE PLUGGABLE DATABASE statement, or both.

  The ENABLED_PDBS_ON_STANDBY parameter (see ENABLED_PDBS_ON_STANDBY) is valid only on a physical standby; it is ignored by primary databases. (It can be set on a primary database for use if that database ever becomes a standby database.) It can be used to specify which PDBs should or should not be enabled on a physical standby database. If the parameter is not specified, then all PDBs in the CDB are created on the standby unless the STANDBYS clause is used.

  The STANDBYS clause has no effect on whether recovery is later enabled or disabled. The STANDBYS clause of the SQL CREATE PLUGGABLE DATABASE statement has the following syntax:

  CREATE PLUGGABLE DATABASE … STANDBYS={('cdb_name', 'cdb_name', ...) | NONE | ALL [EXCEPT ('cdb_name', 'cdb_name', ...)]}

  • cdb_name is the DB_UNIQUE_NAME for the physical standbys in which the PDB is to be included.

  • NONE excludes the PDB from being created in any of the standby CDBs. When a PDB is excluded from all standby CDBs, the PDB's data files are offline and marked as unnamed on all of the standby CDBs. Any new standby CDBs that are instantiated after the PDB has been created must disable the PDB for recovery explicitly to exclude it from the standby CDB. It is possible to enable a PDB on a standby CDB after it was excluded on that standby CDB.

  • ALL (the default) includes the PDB being created in all standby CDBs.

  • EXCEPT cdb_name includes the PDB being created in all standby CDBs except for those CDBs listed in this clause by their DB_UNIQUE_NAME.

  When a list of CDB names is provided on the STANDBYS clause, the list must be enclosed in parentheses and each name must be enclosed within single quotation marks. The value of DB_UNIQUE_NAME can be up to 30 characters and is case insensitive. The following characters are valid in a database name: alphanumeric characters, underscore (_), number sign (#), and dollar sign ($).

  The standbys in the list must be pre-populated with the required files unless the PDB is being created from seed, or a local clone with the standby running Active Data Guard, or a remote clone using the STANDBY_PDB_SOURCE_FILE_DBLINK parameter.

• When you create a PDB as a local clone from a different PDB or from the seed PDB within the same primary CDB, note the following:

  • When a new PDB is created from seed, the standby automatically instantiates the files.

  • In an Active Data Guard environment, when a PDB is cloned in the same CDB, Data Guard automatically instantiates the files.

  • In a non-Active Data Guard environment, when a PDB is cloned in the same CDB, use the STANDBYS clause on the CREATE PLUGGABLE DATABASE statement and enable recovery later.

• To automatically maintain standby databases when performing PDB remote clones or plugins, use the following initialization parameters:

  • STANDBY_PDB_SOURCE_FILE_DBLINK—For use with remote cloning. Specifies the name of the database link used to clone the PDB at the primary.  When the redo for the PDB clone operation is applied at the standby, it uses that database link to connect to the source database to repeat the clone process to the destination standby database. This parameter is available only in Active Data Guard because it accesses the database dictionary for specific information about the link.

    The source PDB for the cloning operation must be in read only mode for the duration of both the clone to the primary and the clone to the standby.

    On remote clones that do not use the STANDBY_PDB_SOURCE_FILE_DBLINK parameter, the SQL CREATE PLUGGABLE DATABASE statement used to create the PDB must use the STANDBYS=NONE clause.

  • STANDBY_PDB_SOURCE_FILE_DIRECTORY—For use with plugins. Specifies the directory location where files of a PDB being used for repeated plugins are stored.  When the redo for the PDB plugin operation is applied at the standby, it searches the directory location for the data files and after finding them, copies them to the location the standby requires them to be based on the settings of the DB_CREATE_FILE_DEST and DB_FILE_NAME_CONVERT parameters.

    Note:

    The files must be image copies of the source PDB data files. The copies should be created after creation of the manifest XML file for the source PDB.

  These parameters should be reset after they have been used and are no longer needed. There is no runtime impact from setting and resetting these parameters because doing so does not require that instances be restarted.

  See My Oracle Support note 2274735.1 at http://support.oracle.com for detailed information about using these parameters.

• To create a PDB from an XML file, copy the data files specified in the XML file to the standby database.

  When a PDB is plugged into a primary database from an XML file, all standby databases in the configuration must be given access to the source PDB's files. (The only exceptions to this are standbys that have recovery deferred by use of either the STANDBYS clause on the CREATE PLUGGABLE DATABASE statement or the ENABLED_PDBS_ON_STANDBY initialization parameter.)

  To provide standbys in the configuration with access to the source PDB's files, either use the STANDBY_PDB_SOURCE_FILE_DIRECTORY initialization parameter or copy the files of the source PDB to the standby site, typically the same set of PDB files that are to be plugged into the primary database. The files should be copied to the standby prior to the plugin operation being performed at the primary to minimize disruptions to managed standby recovery. Ensure the files are copied to the appropriate location at the standby where managed standby recovery can find them, as follows:

  • If data files reside in standard operating system file systems, then the location of the files at the standby database are based on the value of the DB_FILE_NAME_CONVERT parameter. For more details about setting primary database initialization parameters, see Set Primary Database Initialization Parameters

  • If data files reside in ASM, then use the ASMCMD utility to copy the files to the following location at the standby database:

    db_create_file_dest/db_unique_name/GUID/datafile
    

    The GUID parameter is the global unique identifier assigned to the PDB; once assigned, it does not change. To find the value of the GUID parameter, query the V$CONTAINERS view before unplugging the PDB from its original source container. The following example shows how to find the value of the GUID parameter for the PDB whose PDB container ID in the source container is 3:

    SELECT guid
      FROM V$CONTAINERS
     WHERE con_id=3;
     
    GUID
     
    D98C12257A951FC4E043B623F00A7AF5
    

    In this example, if the value of the DB_CREATE_FILE_DEST parameter is +DATAFILE and the value of the DB_UNIQUE_NAME parameter is BOSTON, then the data files are copied to:

    +DATAFILE/BOSTON/D98C12257A951FC4E043B623F00A7AF5/datafile
    

The path name of the data files on the standby database must be the same as the resultant path name when you create the PDB on the primary, unless the DB_FILE_NAME_CONVERT database initialization parameter has been configured on the standby. In that case, the path name of the data files on the standby database is the path name on the primary with DB_FILE_NAME_CONVERT applied.