Everything goes Auto? First experiences with the Oracle Autoupgrade-Tool - Part 1 - introduction and configuration

At the DOAG conference 2019 I had a presentation (due to the filled up room it was repeated the day after) regarding the Oracle Autoupgrade tool. The slides are in german and can be found at my Slide Download Center. As most slides are screenshots only, I will write in this series of posts a little bit about this new tool.

The first part will now cover an introduction and how to setup the configuration file.

Introduction:
After OOW 2018 I have heard the first time of the Autoupgrade Tool and I was very curious. I have downloaded the slides and what I have found was a thing I thought it should be there since years.
A tool which helps you upgrading your databases from one release to another without running all these scripts, pre-installation.jars and DBUA manually. With less hands on and with a lot of things automated. The more I have read the more curious I got.

Later on, I have seen autoupgrade as part of the documentation of Oracle 19c, but I wasn't really able to see how it could work and I also had no time to step into it in detail.

Then, Mid of June 2019, I have seen Mike Dietrichs (Mister Upgrade Guru) blog post about how to create a sample configuration file and with how less parameters an upgrade could be started.
So I decided (after a short conversation with Mike on twitter, June 13th) to test the tool and to send a proposal for a presentation at the DOAG conference. I already had installed a 19c Database software on my laptop with Windows 10, so I decided to make the first small test there.

Unfortunately, I've got a java exception at running autoupgrade.jar with a -version flag. Also the downloaded version from support.oracle.com had this problem. (Slide 11) It's so typical, that it hits me...😳

So I was really sorry to inform Mike that I couldn't test that due to (in my opinion) a problem with the german environment I had. I opened a SR to pass all the logs to the Oracle Support and Mikes Team.
July 1st (! I started testing mid of June! - Slide 13) I've got an email from Mike that the bug should be fixed in the version they have uploaded some days before. The fix included a "fallback" to default language (english) if the OS language is not supported. I downloaded that version and yes, it was working now. (Slide 15)

I asked my colleague to set up a "Swiss customer similar database environment" on a Windows 2012 server and I prepared a virtualbox with Oracle Linux and some CDBs.
As I was busy over the summer I only were able to test things in my spare time mostly. So I've started with reading the documentation and Mikes blog.
The more I read, the more I have seen some targets, that my employer could reach by using this tool (Slide 7):

As an ISV and System Integrator, we have a lot of databases to upgrade (most of them from 12.1 to 19c) next year. Some on Linux, some on Windows, some on ODA (but ODA is out of scope here).
The database editions are Standard Edition 2 and Enterprise Edition and we have all kind of licenses (Embedded, Application Specific and Full Use).
Main target for us is to get rid of any manual work as this is most error-prone, e.g. changing SPFile parameters, switching from Non-CDB to the new CDB architecture, maybe combining application upgrades with database upgrades (scripted), etc..

After the virtualbox and the Windows environments (on VMWare) have been installed, I was ready to start with the tests.

Preparation:

As a lot servers don't have (the right) java (version) installed, it's best to use the java from the ORACLE_HOME/jdk/bin directory of 18c or 19c (Slide 15). This works fine. Also, as release cycles of the autoupgrade tool are very short, you should download always the newest autoupgrade.jar from support.oracle.com. Even if you have checked the note a week ago, check again, before you start your work.

With that in mind, you can run the tool with the -create_sample_file config parameter (by the way, on my german environment it says unsupported language, defaulting to English) (Slide 16).

It's very easy to use the sample config file (Slide 17) to create your own configuration. A small thing that can be found on Windows is the global log directory misses "backslashes". This does not work out of the box but is easy to fix.On Linux, the default log directory is fine and points to /home/oracle. (Slide 18)

Next to do is to specify (Slide 19) e.g. the DB_UNIQUE_ID as "DBNAME", the "SID", "SOURCE HOME" and "TARGET HOME", "TARGET_VERSION" of the database and, if you wish so, even more (see the documentation for all parameters). The "START_TIME" parameter can be set to 'now' or a date/time - the format can be found in the documentation (no NLS_LANG setting). With "add_after_upgrade_pfile" (or delete or before or during instead of after) you can change automatically the SPFILE content.

One of the things I really like is to change is the tag "UPG1." to a tag that gives more information (e.g. EDM for our Energy Data Management DB, DAPHNE for the museums DB, etc.) (Slide 19).

So you can create one config file for all kind of databases and they are pretty named. Running "UTLRP" for recompilation is a nice thing, also have a look at the parameter for "TIMEZONE_UPG"rades as it is often forgotten in manual upgrades. You should also know the "RESTORATION" parameter, more information on this parameter will follow later.

If you have setup the config file, you are ready to start to work with your database(s).


The next step is the Pre-Upgrade analysis (next post).