I need to bring this blog post forward about AutoUpgrade and Data Guard, RAC, Restart and non-CDB to PDB. Initially I planned to write this a bit later. But some of you had questions or were wondering why AutoUpgrade hasn’t done certain tasks. Hence, I’d like to clarify what AutoUpgrade can do, what it can’t and what you’ll have to do at the moment.
I refer to the AutoUpgrade tool as of July 2019. In later versions, one or the other restriction may be lifted. I will blog about it then as well.
AutoUpgrade – Step-by-step
- The new AutoUpgrade Utility – Download, documentation and supported versions
- Create and adjust the config file for AutoUpgrade
- Config file for AutoUpgrade – Advanced options
- Config file for AutoUpgrade – Tweaking init parameters
- AutoUpgrade: ANALYZE, FIXUPS, UPGRADE and DEPLOY modes
- AutoUpgrade: Where do you find all the logfiles?
- UPG: The AutoUpgrade Command Line Interface
- Upgrading Multitenant databases with AutoUpgrade
- Moving to a new server with AutoUpgrade
- How to tweak the hidden settings in AutoUpgrade
- AutoUpgrade and Data Guard, RAC, Restart and non-CDB to PDB
- AutoUpgrade and Wallets
AutoUpgrade and Data Guard
Many of you may have standby solutions with Oracle Data Guard. In the current version, the AutoUpgrade tool can’t interact with the Data Guard broker and does not do any special tasks when you upgrade a database which is protected with one or more standby databases.
You will have to disable the Broker by yourself at first when you attempt to upgrade a standby database:
- When you upgrade, disable the Data Guard Broker
This blog post I wrote in September 2017 explains you how to disable the Broker, and that it is best practice to defer the log transport as well.
We are working on the inclusion of the correct Data Guard handling. Once it is there, the tool will disable the Broker and defer the log transport. And of course, enable everything correctly afterwards.
AutoUpgrade and Oracle Restart
Actually a lot of “my” reference customers use Oracle Restart. It gives you ASM and single-instance high availability. In the current version of the AutoUpgrade tool, it upgrades your databases in Oracle Restart correctly. But what it can’t do – or what you will have to do manually by yourself: You will need to prevent clusterware to control the database while you are upgrading.
And after the upgrade – at the moment – you will need to do the resource adjustment for the newer version:
In a later version of the tool we will handle this for you. We have a prototype running already but more tests are needed before we will release this to you.
AutoUpgrade and Oracle RAC (and RAC One-Node)
Exactly the same applies as I wrote in the “Restart” section before. This means, you will have to shutdown the instances on all other nodes. Otherwise you’ll hit an issue. Once you completed this, since the July 2019 version of the AutoUpgrade, we keep
cluster_database=false until the very end of our workflow. Before, the time zone change failed as we started the database with
cluster_database=true already while the resources and services weren’t upgraded. This is fixed now.
With the July 2019 version of the AutoUpgrade you don’t have to disable
cluster_database anymore either. The tool handles it correctly.
AutoUpgrade and non-CDB-to-PDB
Another of our high priority projects is the conversion from non-CDB to PDB. You need to upgrade your non-CDB database first before you can plug it in and make it a PDB. We are working on the automation of this step. You will need to specify your destination CDB in the config file, but then the tool will do the upgrade, the plugin and the conversion for you. Of course, you will need to precreate the receiving CDB.