A customer wanted help upgrading and moving to new hardware:

I have an 11g database running on old hardware. I want to upgrade to 19c and move to new hardware. I can’t use Data Guard to move the database because I can’t install 11g binaries on the new hardware. What do I do?

Data Guard would be the obvious choice, but wasn’t possible here. But we can use RMAN incremental backups.

This allows us to move the database with little downtime and then perform the upgrade.

The Plan

Here’s an overview of the plan:

1. Perform a level 0 backup of the 11g database.
2. Restore the backup into a 19c instance on the new hardware.
3. Prepare the database for upgrade.
4. Perform a level 1 backup.
5. Recover the database.
6. Upgrade the database.

We can perform steps 1-2 in advance and save time during the outage.

Any newer version of Oracle AI Database can restore backups from a previous release. But to upgrade the database, we must be within the limitations for a direct upgrade. Oracle Database 19c supports direct upgrades from 11g.

Step 1: Initial Backup

The database is called UPGR and runs on the old hardware as an 11g database.

1. On the old system, I start by doing a level 0 backup of the source database:

   RMAN> CONNECT TARGET /
         RUN {
         ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
         ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
   
         BACKUP AS COMPRESSED BACKUPSET
            INCREMENTAL LEVEL 0
            DATABASE
            FORMAT '/u01/app/oracle/backup/L0_%d_%T_%U.bkp'
            PLUS ARCHIVELOG
            FORMAT '/u01/app/oracle/backup/L0_%d_%T_%U.bkp'
            TAG 'LEVEL0';
   
         BACKUP CURRENT CONTROLFILE
            FORMAT '/u01/app/oracle/backup/CTL.bkp'
            TAG 'CONTROLFILE';
   
         RELEASE CHANNEL c1;
         RELEASE CHANNEL c2;
         }
   

   • I store the backups on an NFS share that’s accessible to the new system as well.
   • I’m doing a compressed backup. Be sure you’re licensed for that.
   • You can customize the backup script.
2. I create a PFile:

   SQL> CREATE PFILE='/u01/app/oracle/backup/pfile.txt'
        FROM SPFILE;
   

Step 2: Configure Instance and Restore

I create a new instance on the new hardware. I must use the same name, UPGR.

1. On the new hardware, I create a PFile for my target instance. I use the original PFile as a template and make the necessary changes. Here’s the PFile that I’ll use:

   *._cursor_obsolete_threshold=1024
   *.audit_file_dest='/u01/app/oracle/admin/UPGR/adump'
   *.audit_trail='db'
   *.compatible='11.2.0.4.0'
   *.control_files='/u02/oradata/UPGR/controlfile/control01.ctl'
   *.db_block_size=8192
   *.db_create_file_dest='/u02/oradata'
   *.db_name='UPGR'
   *.db_recovery_file_dest_size=12884901888
   *.db_recovery_file_dest='/u02/fast_recovery_area'
   *.diagnostic_dest='/u01/app/oracle'
   *.pga_aggregate_target=1G
   *.sga_target=4G
   

   • I keep the same db_name.
   • Adjust locations, like db_create_file_dest and control_files accordingly.
2. I create the directory specified by audit_file_dest:

   mkdir -p /u01/app/oracle/admin/UPGR/adump
   

3. I set the environment and create a new password file:

   export ORACLE_HOME=/u01/app/oracle/product/19
   export ORACLE_BASE=/u01/app/oracle
   export ORACLE_SID=UPGR
   export PATH=$ORACLE_HOME/bin:$PATH
   
   $ORACLE_HOME/bin/orapwd file=orapwUPGR password=MyS3cr3tPassw0rd!
   

4. Next, I start the new instance in NOMOUNT mode:

   SQL> STARTUP NOMOUNT
   

5. I restore the control file:

   RMAN> CONNECT TARGET /
         RUN {
         RESTORE CONTROLFILE
            FROM '/u01/app/oracle/backup/CTL.bkp';
         }
   

   • I restore from the NFS share.
6. Then, I mount the database and start the restore:

   RMAN> CONNECT TARGET /
         ALTER DATABASE MOUNT;
         RUN {
         ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
         ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
   
         SET NEWNAME FOR DATABASE TO NEW;
   
         CATALOG START WITH '/u01/app/oracle/backup/' NOPROMPT;
   
         RESTORE DATABASE;
         SWITCH DATAFILE ALL;
         RECOVER DATABASE UNTIL AVAILABLE REDO;
   
         RELEASE CHANNEL c1;
         RELEASE CHANNEL c2;
         }
   

   • I use Oracle Managed Files (OMF), so I use SET NEWNAME accordingly.
   • I use CATALOG to tell RMAN where to find the backups.
   • I restore the database and recover until there’s no more redo.

Step 3: Prepare for Upgrade

Downtime starts now.

1. On the source system, I create an AutoUpgrade config file, so I can check the upgrade readiness of my database.

   global.global_log_dir=/home/oracle/autoupgrade-logs
   upg1.source_home=/u01/app/oracle/product/11.2.0.4
   upg1.target_home=/tmp
   upg1.target_version=19
   upg1.sid=UPGR
   

   • I can’t set target_home to the real value because it doesn’t exist on the source server. I use a fake entry instead.
   • AutoUpgrade normally deduces the target_version from target_home, but since it doesn’t exist, I need to specify it manually.
2. I perform the preupgrade check:

   java -jar autoupgrade.jar -config UPGR.cfg -mode analyze
   

   • Check the preupgrade summary report.
   • I use the latest version of AutoUpgrade.
3. I run the preupgrade fixups:

   java -jar autoupgrade.jar -config UPGR.cfg -mode fixups
   

4. Then, I run an incremental backup:

   RMAN> CONNECT TARGET /
         RUN {
         ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
         ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
   
         BACKUP AS COMPRESSED BACKUPSET
            INCREMENTAL LEVEL 1
            DATABASE
            FORMAT '/u01/app/oracle/backup/L1_%d_%T_%U.bkp'
            PLUS ARCHIVELOG
            FORMAT '/u01/app/oracle/backup/L1_%d_%T_%U.bkp'
            TAG 'LEVEL1';
   
         RELEASE CHANNEL c1;
         RELEASE CHANNEL c2;
         }
   

   • The incremental backup captures the last changes to my database.
5. I shut down the database on the old system.

Step 4: Recover

1. On the target database, I recover the incremental backup.

   RMAN> CONNECT TARGET /
         RUN {
         ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
         ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
   
         CATALOG START WITH '/u01/app/oracle/backup/' NOPROMPT;
   
         RECOVER DATABASE UNTIL AVAILABLE REDO;
   
         RELEASE CHANNEL c1;
         RELEASE CHANNEL c2;
         }
   

   • I use the CATALOG command to tell RMAN about the new backup.
   • I recover the database until there is no more redo.
2. Then, I open the database in upgrade mode:

   SQL> ALTER DATABASE OPEN RESETLOGS UPGRADE;
   

   • I use the RESETLOGS clause to create redo logs.
   • I must open in upgrade mode to start the upgrade. If I try to open in normal mode, I’ll get an error ORA-00704: bootstrap process failure.

Step 5: Upgrade

The database is open in upgrade mode. I must perform the upgrade to 19c.

1. On the target system, I create an AutoUpgrade config file:

   global.global_log_dir=/home/oracle/autoupgrade-logs
   upg1.source_home=/tmp
   upg1.target_home=/u01/app/oracle/product/19
   upg1.sid=UPGR
   

   • I can’t set source_home to the real value because it doesn’t exist on the target server. I use a fake entry instead.
2. I perform the upgrade:

   java -jar autoupgrade.jar -config UPGR.cfg -mode upgrade
   

   • I start with -mode upgrade to complete the upgrade. Don’t use -mode deploy.
   • I use the latest version of AutoUpgrade.
3. After a while, the upgrade completes. All done.

That’s it

RMAN incremental backup is a great feature to reduce downtime when Data Guard is not an option. You can restore to a higher release of Oracle AI Database as long as you stay within the limits for a direct upgrade.

You can enhance the procedure:

• Run additional level 1 incremental backup/restores to minimize the time it takes to perform the last one.
• Enable Block Change Tracking on the old database to shorten the time it takes to do incremental backups.
• Run an additional AutoUpgrade preupgrade check days in advance to get early notice on any showstoppers.

Happy upgrading!