Modernisation of entire database stack is key not just to ensure that you can benefit from the latest features but also to ensure that you are on a supported version of Platform/Shape/Database.
Modernisation in OCI is easy and you have multiple solutions to adopt based on your requirement.
My Environment :
Platform : Oracle Base Database in Oracle Cloud Infrastructure
Database Version : 19.16
Grid Version : 19.16
OS : Oracle Linux (OL7)
Shape : Intel X7 (Fixed Shape)
We have a Standby DB system with same DB, GI and OS version as Primary DB system.
Goal : Upgrade OS to Oracle Linux 8 (OL8) and Shape to Intel X9 (Flex shape) for both Primary and Standby DB system.
Concept
We will use Refreshable Pluggable Database method to clone the existing PDB (on Intel X7 Shape ) to a new CDB on Intel X9 Shape with minimal downtime.
Step 1 : Create a new DB system with Intel X9 Shape (No downtime)
Create a DB system with database version 19.21 or above.
I have created a DB System with GI/DB version 19.24.
We can do this from OCI console , ensure to select Intel X9 as the shape while provisioning a new DB System.
We have to select database version 19.21 or above so that the new DB System will have OL8.
I haven’t elaborated on the details of creating a new DB System since it is a fairly simple process.
Refer documentation if you need any help.
Please provide same values for Availability Domain , OCPU , Edition , Storage , VCN , Subnet and other relevant fields for as your existing Intel X7 DB system.
Step 2 : Enable Data Guard for New DB System (No downtime)
Navigate to the Database Console of the New DB system and go to Data Guard Association section (shown below).
Click on Enable Data Guard to bring up below screen and enter the details of the Standby DB System as shown below.
Click on change shape (as seen above) to bring up the below screen which allows you to change the OCPU of the DB System.
Please note that shape of DB system will default to the shape of Primary DB System (which is Intel X9 in this case).
We can keep the same OCPU as the existing standby DB System on Intel X7.
Click on Select shape after making required changes to go back to original screen.
Select the VCN and subnet exactly same as your current Standby DB system for Intel X7.
Enter remaining details matching your existing Standby DB system (on Intel X7) as below and click on Next after entering all details.
Enter the database password and click on Enable Data Guard.
This will initiate a work request and we will have standby DB system for Intel X9 after successful completion of work request.
Step 3 : Create a common user in Primary Database (No downtime)
Create a common user using below commands on Intel X7 CDB.
CREATE USER c##clone IDENTIFIED BY some-password CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SELECT_CATALOG_ROLE TO c##clone CONTAINER=ALL;
GRANT READ ON sys.enc$ TO c##clone CONTAINER=ALL;Step 4 : Create a Refreshable PDB (No downtime)
We will use PDB lifecycle management options from console for this.
Navigate to PDB console on OCI for the Intel X7 DB system and click on Clone option as seen below for the PDB (SALES in this example ) which we will clone to Intel X9 DB system.
Select Refreshable clone , Destination DB system (created in step 1 ) , Destination Database and name of the new PDB (SALES_X9) as seen below.
Provide Source Database (Intel X7) SYS password and also the details of the user created in step 3.
Click on the Clone pluggable database to initiate creation of Refreshable PDB.
PDB creation might take time depending on the size of the source PDB.
We will see a screen similar as shown below during provisioning of PDB.
After successful provisioning , we will be able to see the newly created refreshable PDB on Intel X9 as shown below.
Can we see this PDB in Standby DB System of Intel X9 ?
Well, Cloud automation creates refreshable PDB with standby=none clause which means they are not yet available on DR . You will be able to see the skeleton of PDB in standby database but there won’t be data files for it.
Step 5 : Refresh the Refreshable PDB (No downtime)
We have created a refreshable PDB instead of remote clone so that the time taken for cloning(previous step) doesn’t count towards the downtime.
We will refresh our PDB regularly so that incremental changes (which requires source database archive logs) from source are applied on target PDB until we decide to move to Intel X9.
Navigate to the PDB console for Intel X9 DB System and click on Refresh as shown below.
Click on “Refresh” on below screen to proceed with refresh.
This will initiate the refresh of PDB from existing PDB on Intel X7.
Step 6: Convert the Refreshable PDB to Regular PDB(Downtime required)
This is the final step before we can start using PDB on Intel X9.
We have to shutdown the Applications pertaining to the Source PDB (in Intel X7) and perform a final refresh (using same the procedure mentioned in step 5).
Once the final refresh has been completed , we can navigate to the PDB in the Target DB system and click on Convert to regular PDB as seen below.
Provide the SYS and TDE wallet password when asked and click on Submit as shown below.
After successful conversion , you will have a screen similar to below.
We have successfully converted the Refreshable Pluggable database to a regular PDB in Intel X9.
I am sure cloud automation will do the sanity check before marking the conversion as successful , however I did query using below to check for any PDB plug in violations and I didn’t find any violations.
select con_id,name,type,status,message from pdb_plug_in_violations where status<>'RESOLVED';We can now modify the Application to point to new PDB and bring up the application.
What about the PDB on our Standby database system ?
Cloud Automation does the additional work to make the PDB available on the standby.
That’s all, we have successfully modernised shape and OS of our DB System with minimal downtime.
How to fallback ?
Simply switch to the old DB System since our Source PDB is already up and running and ready for use.
Pros
Very minimal downtime.
Easy and Fast Fallback.
Cons
Application changes may or may not be required since our PDB is on a new DB System.
Database RUs may be updated depending on our database version ( in this case it was changed from 19.16 to 19.24)
Caution
I have tested the same method where the Target Database version was 19.22 and it was failing ( I didn’t explore it further) .
As always test the procedure in your lower environment before doing it on your critical DB systems.
Happy Modernising!
Leave a Reply