In case you missed the previous posts:
When upgrading Oracle Databases in Oracle Cloud, there are several fallback options to ensure minimal risk and maximum reliability during the upgrade process. These options provide flexibility and safeguards in case the upgrade needs to be reverted or issues arise.
Honestly, in 23 years of consulting, I never performed a downgrade. I always preferred to address any issues post-go-live. However, I understand that customers often want a rollback option as a safety measure.
Key fallback strategies in OCI include:
1. Refreshable Clone
- A Refreshable Clone I explained it here, and the source database remains untouched during the upgrade.
- If the upgrade encounters issues, you can simply discard the clone without any impact on the original database.
2. Data Guard with Redo Apply Disabled
- Oracle Data Guard provides a robust fallback mechanism by allowing you to disable Redo Apply during the upgrade process.
- By doing so, the standby database remains unaffected by the changes made during the upgrade.
- If the upgrade fails, you can perform a failover to the standby database to quickly resume operations with minimal downtime.
3. Restore from RMAN Backup
- RMAN (Recovery Manager) backups can be used to restore the database to its pre-upgrade state if the upgrade needs to be reverted.
- While effective, this option is less suitable for large databases due to the time and resources required for the restore process.
- It’s more commonly used for smaller databases or environments where other fallback mechanisms are not feasible.
Does the AutoUpgrade can help?
Yes, you can use the AutoUpgrade parameter target_pdb_copy_option if you have enough space to duplicate your PDB. This option copies the datafiles from 19c to 23ai, keeping the datafiles for the source PDB intact in case a rollback is needed.
Example of copy using OMF:
upg1.target_pdb_copy_option=file_name_convert=NONEIf you need to rollback the upgrade, you can use:
$ java -jar autoupgrade.jar -config PDB1.cfg -restore -jobs 103I will cover this in a future blog post.
How about catdwgrd.sql/ dbdowngrade?
To use the catdwgrd.sql script, the COMPATIBLE parameter must remain unchanged. However, this functionality is currently not supported in the ExaCS/ExaCC.
Let’s try to create a new 23ai database setting the COMPATIBLE parameter to 19.
I tried to use --initparams 'compatible=19.0.0'
dbaascli database create --dbName CDB23AZ --oracleHome /u02/app/oracle/product/23.0.0.0/dbhome_1 --sgaSizeInMB 4448 --pgaSizeInMB 1481 --datafileDestination +DATAC4 --fraDestination +RECOC4 --fraSizeInMB 100000 --createAsCDB true --nodeList azh-tsgxb1,azh-tsgxb2 --initparams 'compatible=19.0.0'
As you can see, I got an error.
Oracle Databases in the Oracle Cloud come with pre-created templates designed to simplify and accelerate database deployment. These templates are pre-configured with the Compatible parameter set to 23.
How about Transportable Tablespaces?
Transportable Tablespaces is not a good option when you are going to a lower release.
Check this and this for more details.
What if?
Yes, you can copy a template from an on-premises Oracle Home to create a database or set up a database manually. This approach involves additional steps, such as configuring Transparent Data Encryption (TDE) and setting various database parameters.
You might also encounter blogs discussing the use of DBCA to create a 23ai database on ExaCS/ExaCC. However, it’s always best to refer to Oracle’s official documentation.
Before using any methods outside the Oracle Cloud console or cloud tooling, check with Oracle Support to ensure compliance.
How about changes during the tests after the upgrade?
If you made changes to the database after the upgrade and need to replicate these changes back to the source database, you can use the following tools:
1. Oracle GoldenGate (OGG):
- Oracle GoldenGate is a robust solution for replicating changes between databases.
- It supports real-time data synchronization, ensuring that any updates made to the upgraded database can be propagated back to the source database seamlessly.
- This is especially useful for capturing changes made during post-upgrade operations.
2. Oracle Data Pump:
- Oracle Data Pump can be used to export the changes from the upgraded database and import them into the source database.
Choosing the right tool depends on the volume and complexity of the changes that need to be replicated.
Workaround?
Alternatively, you can create an empty 19c Container Database (CDB), upgrade it to Oracle 23ai and keep the COMPATIBLE parameter set to 19.
I’m working on this option and will talk more about it soon.
Stay tuned for the next post.
Links to the Complete Blog Post Series on AutoUpgrade for ExaCS/ExaCC: