Create and adjust the config file for AutoUpgrade 19c

Create and adjust the config file for AutoUpgrade 19cThis is the first of a series of blog post explaining the new AutoUpgrade utility step-by-step. You’ll find the tool and overview information in The New AutoUpgrade Utility in Oracle 19c

In this blog post here I will explain and demonstrate how you can create a sample config file and adjust it for a standard database upgrade.

You will see how to add additional options and change default settings. Furthermore, I will showcase how to change, adjust and tweak init.ora parameters during or after upgrade in the upcoming blog posts.

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: The ANALYZE phase
  6. AutoUpgrade: Where are the log files?
  7. Upgrading Multitenant databases with AutoUpgrade
  8. Moving to a new server with AutoUpgrade
  9. How to tweak the hidden settings in AutoUpgrade
  10. AutoUpgrade and Data Guard, RAC and non-CDB to PDB

Create and adjust the config file for AutoUpgrade

When you start working with the AutoUpgrade utility, the only manual task at the moment for you is the creation and adjustment of the config file. At the moment, the config file is just a sample file.

$ java -jar $OH19/rdbms/admin/autoupgrade.jar -create_sample_file config
Created sample configuration file /home/oracle/sample_config.cfg

The sample file contains 3 examples. In my example I just use the first example and adjust it based on my needs.

Sample 1:

#Global configurations
#Autoupgrade's global directory, non-job logs generated,
#temp files created and other autoupgrade files will be
#send here
global.autoupg_log_dir=/default/current/location

#
# Database number 1 
#
upg1.dbname=employee
upg1.start_time=NOW
upg1.source_home=/u01/app/oracle/product/11.2.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/19.1.0/dbhome_1
upg1.sid=emp
upg1.log_dir=/scratch/auto
upg1.upgrade_node=node1
upg1.target_version=19.1
#upg1.run_utlrp=yes
#upg1.timezone_upg=yes

You can put as many databases into the config file as necessary. There is no limitation. And you can upgrade to different target homes and from different source homes as well.

Modifying the sample_config.cfg

First of all, the name of the config file is something you can choose by yourself. You don’t have to stay with the name the tool uses.

Second, there are two types of parameters:

  • global
  • individual – in the sample file those are upg1, upg2 and upg3. But you can name it whatever you want.

You need to adjust the global.autoupg_log_dir, This is the global logging directory. And I usually use this as my root logging directory.

global.autoupg_log_dir=/home/oracle/logs

In the next step I adjust the settings for the database upg1, which in my case will be an 11.2.0.4 database from the Hands-On Lab named UPGR.

#
# Database number 1 
#
upg1.dbname=UPGR
upg1.start_time=NOW
upg1.source_home=/u01/app/oracle/product/11.2.0.4
upg1.target_home=/u01/app/oracle/product/19
upg1.sid=UPGR
upg1.log_dir=/home/oracle/logs/upgr
upg1.upgrade_node=hol
upg1.target_version=19

In this example, I set the target_home individually. But you can also make this a global parameter if you upgrade all databases to the same home:

global.target_home=/u01/app/oracle/product/19

Then of course you can remove it from the individual section.

You can do the same task with the upgrade_node parameter,. It is meant for cases where you define a comprehensive config file for all your databases but differ now between nodes. For example, having two databases with two different upgrade_node values will execute each section only in the case where upgrade_node matches the hostname:

upg1.upgrade_node=hol
...
upg2.upgrade_node=boston

In this case, database upg1 will be upgraded only when upgrade_node matches the hostname. And of course, the same applies to upg2. In my case all my databases will be upgraded on the same host. But I can’t make this a global parameter – it is meant to be a local or individual parameter only. It has to stay in each section.

And finally, as I will upgrade all my databases to Oracle 19c, the target_version can be switched into a global parameter as well.

Current status with only one database

When we look at the current status, my config file looks like this:

global.autoupg_log_dir=/home/oracle/logs
global.target_home=/u01/app/oracle/product/19
global.target_version=19

#
# Database number 1 
#
upg1.dbname=UPGR
upg1.start_time=NOW
upg1.source_home=/u01/app/oracle/product/11.2.0.4
upg1.sid=UPGR
upg1.log_dir=/home/oracle/logs/upgr
upg1.upgrade_node=hol.localdomain

Adding additional databases

Now I’m adding two additional databases – FTEX, another Oracle 11.2.0.4 database, and DB12, an 12.2.0.1 database.

global.autoupg_log_dir=/home/oracle/logs
global.target_home=/u01/app/oracle/product/19
global.target_version=19

#
# Database number 1 
#
upg1.dbname=UPGR
upg1.start_time=NOW
upg1.source_home=/u01/app/oracle/product/11.2.0.4
upg1.sid=UPGR
upg1.log_dir=/home/oracle/logs/upgr
upg1.upgrade_node=hol.localdomain

#
# Database number 2 
#
upg2.dbname=FTEX
upg2.start_time=NOW
upg2.source_home=/u01/app/oracle/product/11.2.0.4
upg2.sid=FTEX
upg2.log_dir=/home/oracle/logs/ftex
upg2.upgrade_node=hol.localdomain

#
# Database number 3 
#
upg3.dbname=DB12
upg3.start_time=NOW
upg3.source_home=/u01/app/oracle/product/12.2.0.1
upg3.sid=DB12
upg3.log_dir=/home/oracle/logs/db12
upg3.upgrade_node=hol.localdomain

During the next step, we will add optional parameters and adjust the starting time for each upgrade.

Documentation

Please find the full list of parameters supported in the config file in the Oracle 19c Database Upgrade Guilde.

–Mike

Share this:

6 thoughts on “Create and adjust the config file for AutoUpgrade 19c

  1. Mike,
    The documentation of Autograde is confusing. It states:
    dbname
    Identifies the DB_UNIQUE_NAME value of the database that you want to upgrade. This name should be registered in the server host file ( for example, /etc/hosts), or on a domain name server. When you are logged in to the server, it should be the name that is returned when you enter the command hostname.

    The DB_UNIQUE_NAME is never registered in the hosts file. The hostname command on Linux always returns the name of the server and not the DB_UNIQUE_NAME.

    restoration
    (Optional) Generates a Guaranteed Restore Point (GRP) for database restoration. If you select this option, then both database backup and database restoration must be performed manually by the DBA.

    I thought that if I specify restoration=no, then I have to take care of backup and restore myself, but the documentation seems to be ambiguous.

    Can you please clarify?
    Thanks,
    Arun Gupta

    • Arun,

      correct – this is not mentioned correctly in the doc.
      I will feedback this to the doc guys.

      The dbname is what you have as DB_UNIQUE_NAME in your spfile.

      And you are right with the GRP as well – restoration=no overrides the GRP creation (meant for SE2 databases and dbs in noarchivelogmode).
      If something fails in such cases, it will be your task to restore by yourself. But the doc is not correct here.

      Cheers,
      Mike

  2. Mike,
    I ran into another issue with Autoupgrade. I was following the steps to upgrade from 12.1 to 19c via Data Guard.

    https://docs.oracle.com/database/121/SBYDB/rollup.htm#SBYDB00830

    The broad steps are:
    a) Create a physical standby using Data Guard.
    b) Convert physical standby to logical standby.
    c) Stop redo apply.
    d) Upgrade the logical standby to 19c.

    In the last step, when I ran Autoupgrade in analyze mode against the logical standby, it just kept complaining that two datafiles needed recovery. These two datafiles belonged to SYSTEM and SYSAUX tablespaces of the PDB$SEED database which is READ ONLY by default. I searched on MOS if there was any way to make these datafiles not need recovery, but didn’t have much luck. Finally, I just used the DBUA from 19c to upgrade and it performed the upgrade without any issues. Something the Autoupgrade team needs to look at.

    Thanks,
    Arun

    • Hi Arun,

      I think this is at first a general Multitenant problem. I have seen this in other cases as well that the PDB$SEED does seem to be in this strange state after duplication for standby. But let me discuss this with the developers.

      I’ll try to get back to you asap.

      Cheers,
      Mike

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required

*

I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.