AutoUpgrade and Data Guard, RAC, Restart and non-CDB to PDB

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 and Data Guard, RAC, Restart and non-CDB to PDB

AutoUpgrade – Step-by-step

  1. The new AutoUpgrade Utility – Download, documentation and supported versions
  2. Create and adjust the config file for AutoUpgrade
  3. Config file for AutoUpgrade – Advanced options
  4. Config file for AutoUpgrade – Tweaking init parameters
  5. AutoUpgrade: ANALYZE, FIXUPS, UPGRADE and DEPLOY modes
  6. AutoUpgrade: Where do you find all the logfiles?
  7. UPG: The AutoUpgrade Command Line Interface
  8. Upgrading Multitenant databases with AutoUpgrade
  9. Moving to a new server with AutoUpgrade
  10. How to tweak the hidden settings in AutoUpgrade
  11. AutoUpgrade and Data Guard, RAC, Restart and non-CDB to PDB
  12. 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:

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)


IMPORTANT:
With the AutoUpgrade 19.8 from March 27, 2020, the below steps are obsolete. The tool automates these now end-to-end.
See: https://mikedietrichde.com/2020/04/01/autoupgrade-new-version-with-rac-database-upgrade-support/


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.

Here is an overview on the steps as an example:

  1. Determine the SPFILE and make a note. We will use it later:
    $ srvctl config database -d myinst2 | grep spfile
  2. Set cluster database to false:
    $ alter system set cluster_database=FALSE scope=spfile sid='*’;
  3. Stop the DB and start the local instance only:
    $ srvctl stop database -d myinst2
    $ srvctl start instance -d myinst2 -n 'hostname'
  4. Run AU (modes => analyze, deploy)
    NOTE: Set upg1.timezone_upg=no unless you use the Oct 2019 version of AutoUpgrade.
  5. Manual upgrade Timezone if desired
  6. Update the OCR configuration for the database by running the ‘srvctl upgrade’ command from the new database home:
    $ srvctl upgrade database -d myinst2 -o /u01/app/oracle/product/19.4.0/dbhome_1
  7. Modify the SPFILE to the original in step 1:
    $ srvctl modify database -d myinst2 -spfile +DATAC3/MYINST2/PARAMETERFILE/spfile.911.1234567890
  8. Restart the DB in RAC mode:
    $ sqlplus / as sysdba
    SQL> shutdown immediate
    $ srvctl start instance -d myinst2 -n 'hostname'
    SQL> alter system set cluster_database=TRUE scope=spfile sid='*’;
    $ srvctl stop instance -d myinst2 -n 'hostname'
    $ srvctl start database -d myinst2

    .

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.

–Mike

Share this: