Part one of the series provides an introduction to Oracle® refreshable clones, including when and why to use them. In this post, I demonstrate how to set up, configure, maintain, and drop a refreshable clone pluggable database (PDB) in Oracle 18c.
To follow along with this demonstration, complete the following prerequisites:
Have a database link for newly created refreshable clone pointing to a local or a remote container.
Use an engineered system or Enterprise Edition (EE) Oracle Cloud. If it’s not available in the same
platform or version, set the hidden parameter,
for this demonstration.
You can set the refreshable PDB in either CLOSED or OPEN READ ONLY mode and in OPEN READ ONLY mode for queries after a refresh.
For this demonstration, make sure your environment conforms to the following specifications:
Install Oracle 18c and perform the prerequisites on the machine and database.
For the role of the production database:
Set the container database (CDB) name: YCDB1
Set the PDB Name: PURCH_PDB
For the role of refreshable clone PDB:
Set the CDB Name: XCDB1
Set the PDB Name: PDB2_REFRO
Set the PDB to refresh automatically every 30 minutes
Create a public database link by using
create_pdb on XCDB. The link
should point to PURCH_PDB on YCDB.
-Execute the following Transparent Network Substrate (TNS)commands:
purch_pdb=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = tejashost2.localdomain)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = purch_pdb))) XCDB1=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = tejashost2.localdomain)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XCDB1))) YCDB1=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = tejashost2.localdomain)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = YCDB1)))
This demonstration performs the following activities:
Sets up the environment.
Finds the refresh mode of the production database.
Shows how to the refresh mode of the refreshable clone, including disabling refresh on the refreshable clone.
Switch between production and the refreshable clone.
For the refreshable clone environment, take the following actions.
Import the data from the EXPDP dumps that you took by using the
utility or importing an HR schema into PURCH_PDB. For this example,
import an HR schema by running the following script on the database:
After it finishes, validate the HR schema details, as shown in the following figure:
Create a database link to point to the production database, PURCH_PDB.
Create a refreshable PDB, set the refresh period to every 30 minutes, and validate that the data refreshed.
You can use all the attributes when you create a PDB that you plan to use to create a database in another location. For example, to modify a PDB datafile location, use CREATE_FILE_DEST or FILE_NAME_CONVERT.
The only addition is the REFRESH MODE attribute. To simplify this demonstration, I did not add any of the optional attributes.
You can query table DBA_PDBS to check details of the refreshable PDB mode, status, last refresh SCN, and its parent production database details. For PDB2_REFRO PDB, check the output as shown in the following example:
After you complete your task, you should convert the refreshable PDB back to MOUNTED mode for a continuous refresh according to the schedule. Use the following commands to do this activity. The open_mode.sql used here is a query to check the current open_mode of the database.
You might see the following error if you did not close the database instance for refresh:
ORA-65025: Pluggable database is not closed on all instances
You can change the mode of a refreshable clone as follows:
Change manual refresh to automatic refresh.
Change automatic refresh to manual refresh.
Disable refresh from automatic or manual refresh mode.
Note: You cannot change the PDB refresh mode when logged into one other PDB. For example, you can’t change the mode of XPDB while logged into YPDB. If you try, the following error occurs:
ORA-65118: operation affecting a pluggable database cannot be performed from another pluggable database.
In manual refresh mode, you can refresh your cloned PDB as needed by using the following command:
You can disable the refresh mode of a PDB to convert your refreshable clone into read-write mode.
Note: After you disable refresh for your pluggable database, you cannot enable it again. You must re-create the PDB to have it be a refreshable PDB. If you try to convert from the NONE refresh mode to refresh mode, you get the following error:
ORA-65261: pluggable database PDB2_REFRO3 not enabled for refresh.
After you disable refresh, the PDB has read-write access.
Before Oracle 18c, you needed to perform all the steps to switchover the role, including shutting the primary and opening it as read-only.
In this demonstration, I do the following:
Create user C##SWITCHUSER on the container databases XCDB1 and YCDB1 by
using grant connect,
Create a database link, dblink, pointing to another container database. In YCDB1, create the dblink, XCDB1SYSOPER, to connect XCDB1. Use database views, DBA_DB_LINKS and V$DATABASE to collect database details after creating the database link.
Open the refreshable clone database as read-only.
Run the switchover command.
Validate the database status and open mode after switching the production and refreshable clone databases.
Complete prerequisites 1 through 3 before executing the switchover command.
Database link details:
Check the database link details and find the database open mode by using DBA_DB_LINKS and V$DATABASE.
After the switchover completes, the original source PDB PURCH_PDB became the refreshable clone PDB. This PDB is currently in MOUNT status, and from now on, you can open it only in READ ONLY mode. In contrast, the original refreshable clone, PDB PDB2_REFRO is now open in READ or WRITE mode and functions as a source PDB.
You should not consider the refreshable clone PDB feature as a replacement for Data Guard from the perspective of high availability. However, you can use a refreshable clone to maintain a replica database on another server.
This post describes how to use refreshable PDBs as replicas so that you can resume certain low-load, non-critical applications operations, whether the switchover is a planned or an unplanned event. Keep in mind, you should consider the switchovers from the point of view of Recovery Time Objectives (RTOs, time to resume operations) and Recovery Point Objectives (RPOs, such as achieving minimal data loss).
Use the Feedback tab to make any comments or ask questions. You can also chat now to start the conversation.