Modernisation is essential to keep up with latest innovations in Oracle Database Platform.
But does it mean that you need to a have big project for Database Migration when you reach the end of life of your existing Database Hardware ?
No , not when you are using Generation 2 Exadata Database Service on Dedicated Infrastructure (ExaDB-D) or Generation 2 Exadata Database Service on Cloud@Customer(ExaDB-C@C).
Oracle has long back released the capability to migrate from Gen 2 ExaDB-D to another ExaDB-D using Data Guard association from console .
However , is it applicable when you have an existing standby database ?
Until the recent release of Multiple Standby Databases , it was more manual work and there are situations where you may not have a standby to meet your RTO/RPO requirements.
Not any longer !
Let’s see how to handle the migration with an existing Standy Database using Multiple Standby Databases feature.
I have used ExaDB-D for this blog , however similar steps are applicable for ExaDB-C@C as well.
Below is my environment.
Source Database Primary: OXA_FRA_P ( Oracle ExaDB-D in Frankfurt VM Cluster 1)
Source Standby Database : OXA_FRA_S ( Oracle ExaDB-D in Frankfurt VM Cluster 2)
Source DB Version : 19.24
Target Primary Database : OXA_AMS_P (Oracle ExaDB-D in Amsterdam VM cluster 1)
Target Standby Database : OXA_AMS_LS (Oracle ExaDB-D in Amsterdam VM Cluster 3)
Target DB version : 19.24
I have divided the steps in to multiple sections as below so that it is easy to navigate.
Let’s explore one step at a time.
Step 0 – Prerequisites
Please refer to the general prerequisites for configuring Data Guard for ExaDB-D in the official documentation.
Also note that you can only use this feature for migrating from a Generation 2 ExaDB-D to another ExaDB-D (or between two Gen 2 ExaDB-C@Cs).
For e.g Migrating from ExaDB-D X8 to ExaDB-D X9/X10/X11.
Below are some additional prerequisites that we have uncovered during the testing , thanks to my colleague Sneha Nitin Pednekar for identifying some of them.
SYS$UMF user account
This particular database user account should be in OPEN status in Source Primary database.
There is a high chance that this user account is in locked state especially if your database was created some time back. Please unlock the user account since it is used by the cloud tooling.
dbaascli tools version
Please ensure that version of dbaascli is same across all the nodes in Source and Target.
As per my experience this is a basic requirement not just for this activity but also for many other activities using cloud automation.
You can check the version of dbaascli using below command.
dbaascli admin showLatestStackVersion
If there is a difference in dbaascli version on any of the nodes , you can update them using below command.
dbaascli admin updateStack
dbcs-agent-update version
Please ensure version of dbcs-agent-update is same across all the nodes of Source and Target VM clusters.
Check the version of dbcs-agent-update using below query.
rpm -qa –last | egrep -i ‘dbaastools_exa|dbcs’
If there is any difference in the version on any of the database nodes , Please raise an Oracle Support ticket to update them.
Primary Database PDBs
I have noticed most of the console automation (not for this activity) require the PDBs in correct state and the same applies for this activity also.
Make sure your PDBs in Source Primary Database are in Read/Write mode.
Create Oracle Home
Create an Oracle Home in Target VM cluster with same Database version and one-off patches as your Primary Database.
Step 1 – Switch to new Data Guard Group resource (No downtime)
If you have an existing standby database created using console in the past , it would have been created using Data Guard Association resource (it was the only available option in the past).
We need to switch to New Data Guard Group resource to leverage the Multiple Standby Database feature.
Switching to new resource doesn’t have any impact on both Primary and Standby database and also on the Data Guard.
Please refer documentation to understand whether you will be impacted in any way.
Let’s proceed further to see how this can be done.
Navigate to Data Guard Association section from the Primary Database console as shown below.
Click on Add Standby to bring up below screen.
Click on Start to initiate the switch.
We can see a screen similar to below at the end of successful work request.
We can see the Data Guard group in console as shown below.
What about if there is no existing standby database ?
You will get an option to choose between Data Guard Association resource and Data Guard group resource when you go for first Standby Database creation.
Step 2 – Create an additional Standby Database (No downtime)
Let’s add a new Standby Database to the existing Data Guard Group configuration using console.
Navigate to the Data Guard group section of the Primary Database as shown below.
Click on Add standby to bring up below screen.
Select the details of the Peer VM cluster (in the new ExaDB-D) as shown above.I have selected a VM cluster in a different region (Amsterdam) , however in your case it may or may not be in the same region.
Also provide details of the existing Oracle Home created earlier and other details as shown below and click on Add standby to proceed further.
We will be able to see a screen similar to below at the end of successful creation of new Standby Database.
Step 3 – Perform sanity check (No downtime)
Let’s check couple of things to ensure that everything looks good.
Navigate to the Data Guard Group section of the console and see how it looks now.
We can see the newly added Standby Database in the console.
Let’s look at the DG broker now.
Below is the DG configuration.
oxa_ams_p is the standby database that we have added in Step 2.
Everything looks good from DG broker side as well.
I would recommend to look at the database parameters related to DG and also the alert log to ensure everything looks good.
Step 4 – Create additional standby databases (No Downtime)
This step can be optional for certain customers .
Let me explain.
If you have an existing standby database for your current Primary Database before migration and you would like to have the same configuration immediately after the migration then we have to add an additional standby (in the new ExaDB-D) before migration so that we will have a standby in new ExaDB-D (Different from the New ExaDB-D for Primary) immediately after the migration.
Repeat the same steps mentioned in Step 4 to add additional standby database in a different VM cluster and Exadata Infrastructure.
I have added an additional standby database in Amsterdam region.
Step 5 – Perform Sanity check (No downtime)
Navigate to the Data Guard Group section of the console and see how it looks now.
As you can see console is updated with latest standby database.
Let’s check the DG broker again to see the changes.
We can see that the latest standby database (oxa_ams_ls) is also reflecting in the configuration.
Step 6 – Perform Database Switchover(Downtime required)
In a typical scenario this step will be done with in a maintenance window with downtime. However that really depends on multiple factors including the customer application , whether application continuity is enabled etc.
Let’s assume we are going with downtime . Bring down the application and proceed as below.
Navigate to the Data guard group section from the Primary Database console and select switchover against the database that you want to promote as the new Primary Database as shown below.
I have selected database in Amsterdam (oxa_ams_p) for switchover.
This will initiate the switchover and we can monitor the same using work request.
Below is the status from console after successful database switchover.
Happy Modernisation!
Leave a Reply