Actually I have a project where we are going to set up a high availability infrastructure with RAC and Dataguard. Due to the requirements from several applications (e.g. Flashback) we decided to implement the Multitenant database option.
Even though it is not yet supported to flashback a single PDB we are able to use Snapshot Standby to flashback the standby database and unplug / create a PDB at a specific point in time.
We have two datacenters equaly equiped. In each datacenter we have one two node RAC. As storage we are using NetApp with the snapshot technologies. This is why we don’t use ASM but implemented the shared storage with direct NFS. This architecture is already in production at the customer for another project and I must admit it runs perfect! The Netapp offers us the ability to clone a database in minutes giving us a second option to flashback a pluggable database.
The customer is using Oracle Managed Files (OMF) for many years so without a dought we created the CDB using this automation feature. For the pluggable databases we decided to create some filessystems to devide the pluggable database – not a big issue …
Oracle Managed Files and Multitenant
For a NON-CDB the location of the datafiles is <db_create_file_dest>/<db_unique_name>/datafiles. And this is the same for CDBs! As you have to have distinct db_unique_names for your primary and standby database this leads into the following directory structure:
RAC_DC1: db_create_file_dest=/u03/oradata/RAC Datafile-Location=> /u03/oradata/RAC/RAC_DC1/datafile RAC_DC2: db_create_file_dest=/u03/oradata RAC Datafile-Location=> /u03/oradata/RAC/RAC_DC1/datafile
So you don’t specify (and you cannot) the full directory structure but the OMF mechnism will automatically add the db_unique_name. So far this works fine.
But what about a pluggable database?
As default you end up with the following layout:
As an example for RAC_DC1:
Datafile-Location => /u03/oradata/RAC/RAC_DC1/3DA40035937B0B1DE0530200007F3158/datafile
With Oracle 18.104.22.168 a new parameter has been added (create_file_dest). This parameter can be used to create a pluggable database in a well defined directory if you want to use OMF. Actually if the PDB has been created the value is stored as the db_create_file_dest for that specific PDB. So here’s again an example for the database
RAC_DC1: CREATE PLUGGABLE DATABASE pdb_test1 ADMIN USER pdb_admin IDENTIFIED BY password CREATE_FILE_DEST='/u03/pdb_shared/RAC'; Datafile-Location => /u03/pdbshared/RAC/RAC_DC1/3DA40035937B0B1DE0530200007F3158/datafile
As you can see there is no chance with OMF to overcome the db_unique_name part or the GUID for the PDB. But there are currently two limitations:
- If you duplication your CDB while the PDB has already been created (DUPLICATE DATABASE FOR STANDBY FROM ACTIVE DATABASE) the parameter “CREATE_FILE_DEST” for the PDB is being ignored and the PDB will be created in the db_create_file_dest for the CDB. So you have a mismatch and not only that. The duplication might fail because there is insufficient space in that filesystem.
- If you create a PDB while Dataguard is already running the create_file_dest will be used on both sides – but unfortunately the “CREATE PDB” command does not recognize that the db_unique_name(s) are different. So instead of using “RAC_DC2” on the standby database it used “RAC_D1”. The creating will not fail but your dataguard environment will be out of sync so there will no longer be a SQL Apply.
To workaround that issue I created symbolic links on both sides. But nevertheless there is again an inconsitency between primnary and standby. Hopefully the next Oracle database release will solve those issues / bugs.
If you join us for the DOAG Conference in November 2016 you might want to join my presentation about Multitenant database on Thursday (17th) or attend my training about the same topic on Friday(18th). More information about the conference and training can be found here: http://2016.doag.org/de/home.