Oracle’s autoupgrade tool makes upgrading your older versions significantly easier than past methodologies. It allows for an in-place migration on the same server, which saves time and resources. This in-place migration is similar to how many of us have done Oracle patching for many years now, think Gold Image patching and multiple Oracle Homes.
Oracle has done a fine job with ongoing support, updates, and enhancements to the tool and it is recommended to always check for the latest version. Very seldom have I run into issues using the tool, and when I do it is related to something pre-existing to the target database or it’s deployment. I would go out on a limb and call it rock solid, so lets take a look at it from a Linux/Unix OS standpoint.
The tool also creates a Guaranteed Restore Point(GRP) making for an easy roll back and recovery, if necessary. This does require that the target database be in Archive Log Mode and have adequate space available to create the GRP, adequate space and redo logs should be validated:
- SQL> shutdown immediate;
- SQL> startup mount;
- SQL> alter database archivelog;
- SQL> alter database open;
One should be sure and check for any invalid objects and any other pre-existing database problems by doing a thorough review and audit of the system. To lower completion time it is also a good idea to refresh statistics on the database and its objects, the upgrade tool will do this on it’s own, however it will generally lengthen an outage window.
The autoupgrade tool is driven by a configuration file, one can use the tool to create a sample default file. If the database across the enterprise are of a similar deployment and architecture that one sample default file can be used to create a configuration file for each subsequent database. I like to clean mine up for the first database and then use that version as my model thereafter, but thats me and what do I know.
Creating a sample config file:
- cmdline > $JAVA_HOME/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -create_sample_file config
Sample config file:
global.autoupg_log_dir=<global_directory_path_for_logs> # # Database number 1 – Full DB/CDB upgrade # upg1.log_dir=<directory_path_for_logs> upg1.sid=<db_sid> upg1.source_home=<target_to_upgrade_home> upg1.target_home=<oracle_19c_home> upg1.start_time=NOW upg1.upgrade_node=<target_server_name> upg1.run_utlrp=yes upg1.timezone_upg=yes upg1.target_version=19 |
The usage of the tool requires one to set some system parameters. The Oracle home and Java home should be directed to your Oracle 19c deployment on the system, examples:
- export ORACLE_SID=<target_dB_sid>
- export ORACLE_HOME=<19c_ORACLE_HOME>
- export PATH=$ORACLE_HOME/bin:$PATH
- export JAVA_HOME=$ORACLE_HOME/jdk/bin
Running autoupgrade in analyze mode can be done any time, and any number of times, leading up to a database upgrade with no impact. It would be recommended to do this well in advance of the planned upgrade in order to have time to resolve any issues. It should also be done just prior to an upgrade to make sure no changes have occured prior to the upgrade that could affect one’s success.
Running in analyze mode:
$JAVA_HOME/java -jar /$ORACLE_HOME/rdbms/admin/autoupgrade.jar -config /<path>/<to_config_file>/<config_file_name>.cfg -mode analyze |
Once analyze mode is complete and returns no errors or problems you can then perform the upgrade:
$JAVA_HOME/java -jar /$ORACLE_HOME/rdbms/admin/autoupgrade.jar -config /<path>/<to_config_file>/<config_file_name>.cfg -mode deploy |
I thought I was done with this tool a few years ago as far as upgrading to 19c from 12c, however recently I have had to dig back into this tool. It is quite robust and makes this upgrade much easier with a little planning.