Upgrading in the cloud – VM DB Systems

Upgrading in the cloud 2 Minutes

This is the first post in a series on the entry-level database system in OCI – being Virtual Machine DB System (VM DB System). You don’t get the same specs as with Exadata DB Systems and Bare Metal DB Systems, but it is much more affordable and still a very good platform. There is good tooling that allows most operations to be fully automated. Upgrades can be made in two ways:

  1. Automated
  2. Manual

Automated

Since November 2020 it is possible to upgrade a database to Oracle Database 19c using the cloud tooling. However, your DB System must meet these requirements:

  • Oracle Linux 7
  • Grid Infrastructure (GI) 19 (only for systems with ASM)

To check the OS version:

[oracle@host]$ cat /etc/os-release

To check GI version:

[grid@host]$ crsctl query crs activeversion

If your system doesn’t meet these requirements either:

  • Move the database to a new DB System that meets these requirements via cloning or backup/restore, or
  • Use the manual approach

At time of writing, if you must upgrade to any other version than Oracle Database 19c you have to do it manually.

Manual

There are some limitations that you must be aware of that makes manual upgrading slightly different.

  • It is not supported to install a second database Oracle Home. You must use the one that is supplied when the system is provisioned. If you need a new database Oracle Home, you must provision a new system.
  • It is not supported to upgrade the Grid Infrastructure.
  • It is not supported to upgrade the operating system.
  • It is not supported to drop the existing CDB and create your own. It is, however, supported to drop the pre-created CDB and replace it with a backup (and we will discuss this option later).
  • You can only provision systems with multitenant architecture.

Having said that, there are some advantages to do manual upgrades:

  • You are in full control
  • You can decide exactly how to perform the upgrade
  • It can be faster because you can customize the upgrade, and you can avoid some of the tasks that the tooling does.

But the downside is that you will need to move the database to a new VM DB System.

Choose a Method

Automated upgrade is easy – manual upgrade is faster and with more control. When you have decided on a method read the other blog post in the series for much more information and demoes.

Other Posts in This Series

Published

10 thoughts on “Upgrading in the cloud – VM DB Systems”

  2. Thank you for this excellent post. I have a scenario I would love your guidance on.

    I have a 2-node Oracle RAC cluster running Oracle AI Database 26ai (23.26.1.0.0) as a CDB on Oracle Linux 8. I also have a separate standalone VM running a 19c non-CDB (19.30.0.0.0) on a regular filesystem (not ASM).

    My goal is to migrate the 19c non-CDB into the 26ai RAC CDB as a new PDB using the AutoUpgrade refreshable clone method you documented here, so that it ends up on ASM and benefits from the RAC infrastructure.

    I have already created the dblinkuser on the source, created the CLONEPDB database link in the target CDB (tested successfully with SELECT name FROM v$database@clonepdb), and prepared the AutoUpgrade config file on the RAC node with source_home=/tmp as you recommend for cross-system migrations.

    However, when I run AutoUpgrade in deploy mode from the RAC node, I consistently get:AutoUpgrade is unable to connect to the target CDB upgraddb for prefix upg1.

    The upgraddb service is registered with the listener, sqlplus / as sysdba connects fine, and ORACLE_SID=upgraddb1 is set correctly. The config uses upg1.target_cdb=upgraddb exactly as shown in your example.

    Is cross-system refreshable clone migration supported when the target is an Oracle RAC CDB? And is there anything specific about how AutoUpgrade connects to the target CDB in deploy mode for this scenario that I might be missing?

    Thank you very much.

    Like

    Reply

      1. Hi Daniel, thank you for the quick response. I will update target_cdb=upgraddb1 and will test shortly.

        For full context, here is my annotated config file in case you see anything that needs correcting for our RAC scenario.

        AutoUpgrade Config — Non-CDB to PDB Migration i

        Source: 19c non-CDB (ORADB) on standalone VM

        Target: 26ai RAC CDB (upgraddb) on 2-node RAC cluster (OL8, ASM storage)

        Method: Refreshable Clone PDB — source stays open during migration

        AutoUpgrade version: 26.3.260401

        Run from: RAC node1 (upgrade-rac-node1) as oracle user

        global.global_log_dir=/home/oracle/autoupgrade/logs

        source_home=/tmp because the 19c home is on a remote system (srv1)

        not on the RAC node where AutoUpgrade is running

        upg1.source_home=/tmp

        target_home is the 26ai DB home on the RAC node

        upg1.target_home=/u01/app/oracle/product/26ai/dbhome_1

        sid is the source database SID on srv1

        upg1.sid=oradb

        target_cdb — for RAC this must be the instance SID not the db_name as pointed out

        db_name=upgraddb, instance SID on node1=upgraddb1

        upg1.target_cdb=upgraddb1

        Database link created in target CDB (upgraddb) connecting to source (ORADB)

        1800 = refresh interval in seconds (30 minutes)

        Link created as: CREATE DATABASE LINK clonepdb CONNECT TO dblinkuser

        IDENTIFIED BY “…” USING ‘srv1:1521/oradb.localdomain’

        upg1.source_dblink.oradb=CLONEPDB 1800

        Name of the new PDB in the target CDB after migration

        upg1.target_pdb_name.oradb=oradb_pdb

        start_time far in future — I control final cutover manually

        using: upg> proceed -job 100 from the AutoUpgrade console

        upg1.start_time=01/01/2099 00:00:00

        Limit parallel processes for initial datafile copy

        prevents overloading the source database on srv1

        upg1.parallel_pdb_creation_clause.oradb=2

        file_name_convert=NONE — let Oracle manage file placement (OMF)

        datafiles land on ASM (+DATA) automatically

        upg1.target_pdb_copy_option.oradb=file_name_convert=NONE

        drop the database link automatically after migration completes

        upg1.drop_dblink=yes

        Any corrections or additional parameters needed for a cross-system RAC target would be greatly appreciated.

        Like

        Reply

          1. However I would keep two things from my original that Gemini dropped:

            1. The lean CDB context — Daniel needs to know WHY Java was removed. Without that he may just say “reinstall Java in the CDB” which defeats the whole point. One sentence is enough.

            2. The source_base discovery — this is a genuine documentation gap worth flagging to him. Keep it as one line.

            Here is the merged final version:

            Subject: 26ai Migration: Stuck at 96% — Post-JVM-Removal Ghost in catupend.sql

            Hi Daniel,

            Thanks for your reply. It works. I am at 96% on the 26ai refreshable clone migration (19c non-CDB → 26ai RAC CDB). The dictionary upgrade completed successfully but I am hitting a crash in catupend.sql during Final Actions.

            Proposed fix: The script executes drop java source “PreupCreateDir”. Because the JVM is uninstalled, the kernel hits a recursive ORA-00942 looking for JAVANAMESTATUS$. I am considering creating a dummy SYS.JAVANAMESTATUS$ table to allow the DROP to fail gracefully with ORA-04043 and let AutoUpgrade continue. Is that safe, or do you have a cleaner path?

            The error:

            SCRIPT: catupend.sql
            STATEMENT: drop java source “PreupCreateDir”
            ERROR: ORA-00604: recursive SQL level 1
            ORA-00942: table or view “SYS”.”JAVANAMESTATUS$” does not exist

            Verification: PreupCreateDir is already absent from sys.obj$ in the PDB — the failure is purely the DROP JAVA kernel routine referencing a missing dictionary table.

            Why Java was removed: I built my 26ai CDB lean following your 3xC guidance — New_Database.dbt template with JSERVER:false. My 19c source was General Purpose template (includes JAVAVM). Hit ORA-65346 on first clone attempt. Chose to remove Java from source rather than install it into the lean 26ai CDB. Cleaned up Bug 30779964 orphaned objects manually after rmjvm.sql.

            One additional finding for your docs: For RAC cross-system migration, upg1.source_base=/u01/app/oracle is required alongside source_home=/tmp. Without it AutoUpgrade fails with Invalid value for source_base [N/A]. Not in your article currently.

            Have you seen this post-JVM-removal crash before? Green light on the dummy table approach?

            Thanks,
            Thomas

            Like

            Reply

            1. Hi,

              I’m not aware of any known issues with the JVM component, but I suggest that you search the knowledge base on MOS. Else, you must create an SR and have our support staff take a look. Don’t create objects yourself. This is not supported.

              “source_base” is not needed in most cases, because we can deduce it from either the source or target Oracle home. Only in rare cases where you have multiple Oracle homes might this be needed, or if you have a configuration issue with your Oracle software.

              I think you should engage with support on your errors. I’m not able to do such troubleshooting via my blog.

              Regards,
              Daniel

              Like

              Reply

              1. Hi Daniel,

                My apologies for the unintentional inclusion of the top portion of my previous comment included my edited thought drafting reply which was reviewed by Claude and made final suggestions.

                I wanted to give you a quick update on the resolution.

                After your guidance to engage MOS, I investigated further and identified the exact failure point. The catupend.sql script at line 466 contains a bare drop java source "PreupCreateDir" as ,I was it was cussing the issue in the log, with no exception handler. In a lean CDB without the JVM installed, the DROP JAVA kernel routine internally references SYS.JAVANAMESTATUS$ which does not exist to causing an ORA-00604/ORA-00942 cascade before it even checks whether the object being dropped exists. I confirmed that PreupCreateDir was already absent from obj$ in the PDB, so the drop was a no-op that simply had no safe mechanism to fail gracefully.

                My resolution: I took a backup of the original script, wrapped the bare statement in a BEGIN...EXCEPTION WHEN OTHERS THEN NULL; END; block, the same pattern Oracle uses elsewhere in the same file for other optional cleanup drops, ran the deployment to completion, then immediately restored the original script from backup. All validations passed: registry components are VALID, datafiles on ASM, all application schemas and tablespaces migrated cleanly, zero data loss confirmed via proof tables created across multiple sync windows during the refreshable clone.

                You were also correct regarding source_base. I have two Oracle homes which justifies the error I got in my deploy run.

                I have learnt a lot from your work and the team and will keep doing so. This cross systems upgrade was tricky due to the diff db creation templates used which required fixes on Sources and some cleaning which leaves ghost objs also that I took care of. I learnt a lot!

                Thank you very much for your help throughout this process. Much appreciated.

                Thomas

                Like

                Reply

Leave a comment