Does AutoUpgrade support the MOVE option?

Sometimes you have different plans for the day. Or, in my case, the day just needs a few extra hours. Today, I received a very interesting question on the blog at first by a customer I know very well. Then we exchanged mails – and I was caught forgetting what I wrote on the blog a longer while ago. The core question is: Does AutoUpgrade support the MOVE option? But there was much more to discuss and figure out as you can read below.

Photo by Arron Choi on Unsplash

Which options does AutoUpgrade offer?

The case here is simple, and many of you may see the same situation. You have a Oracle Database 19c non-CDB, and now it is time to move into Oracle AI Database 26ai. Since we don’t support the non-CDB architecture anymore since Oracle Database 21c, this will be a migration from non-CDB to PDB.

So far, so good. And the first step is that we need a new Oracle AI Database 26ai CDB. I created mine with the DBCA using a custom template.

Now, in order to migrate to the 26ai CDB, AutoUpgrade supports:

• COPY
• NOCOPY

And the highly used Refreshable Clone PDB option to migrate from non-CDB to PDBs is a deviation of the COPY option where we create a clone, and refresh it going forward.

But, as a matter of fact, AutoUpgrade does not support the MOVE option. In this case, the customer sent me a screenshot from my blog where I did answer this question in the comments section. Well, Daniel confirmed it to me.

Space is precious, right?

In this specific case, the customer has two additional requirements.

At first, they don’t have much space on each server. Therefore, the COPY choice may not be an option, even though it prevents you nicely from any sort of issues during the plugin by leaving the source intact (as do refreshable clone PDBs as well with the extra advantage: you don’t have to wait for the COPY operation to be completed).

In addition, the customer had the wish to move – without using ASM – from non-OMF to OMF file naming. OMF stands for “Oracle Managed Files”. I explained how to do such a move seamlessly when you move to the CDB architecture a while ago as well. But not in relation to the MOVE command, and only for AutoUpgrade.

Let’s tackle it step-by-step

I created a 19c non-CDB database in file system, no OMF naming used. SID is HUGO.

1. Preparing the source

   shutdown immediate
   startup mount
   alter database open read only;
   
   exec DBMS_PDB.DESCRIBE('/home/oracle/hugo.xml');
   
   shutdown immediate

2. Preparing the CDB for OMF files

   alter sysetm set DB_CREATE_FILE_DEST='/u02/oradata' scope=both;

   Here it is really crucial that you let “us” do the thing. Don’t pass on destinations such as /u02/oradata/CDB/mypdb, or so. This will lead to an obscure subdirectory tree you really don’t want to have.

3. Plugin the non-CDB as a PDB with the MOVE option

   CREATE PLUGGABLE DATABASE PDB_HUGO
     USING '/home/oracle/hugo.xml'
     MOVE
     FILE_NAME_CONVERT = NONE
   ;

   Again, let me emphasize that you must not pass on any sort of conversion parameter options. Leave it to “us” to do the right thing. This means that NONE is your right choice here. This is important to allow the database take over control and move to OMF.

4. Start the PDB in UPGRADE mode 

   alter pluggable database PDB_HUGO open upgrade;

5. Upgrade the PDB to 26ai

   global.autoupg_log_dir=/home/oracle/logs/au
   upg1.source_home=/u01/app/oracle/product/26
   upg1.target_home=/u01/app/oracle/product/26
   upg1.sid=CDB26
   upg1.pdbs=PDB_HUGO
   upg1.restoration=NO
   upg1.timezone_upg=YES
   upg1.replay=NO

   Important here is that I am giving the PDB a new name. This is intentionally since I am running this operation on the same server. It is just to avoid any service naming conflicts. The crucial part is to call AutoUpgrade now with the -mode upgrade option.

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

   And after a little while, my PDB is upgraded.

6. Final check – OMF?

   alter session set container=PDB_HUGO;
   
   select file_name from dba_data_files;

   All set!
   My files have been all converted now to OMF format.

.

Summary

Ok, AutoUpgrade does not support the MOVE command for several reasons – and it is happening not often that somebody asks about it. Still, if you’d like to realize it, the above way is possible with a little bit of extra scripting.

The important part for the OMF conversion was the NONE option for FILE_NAME_CONVERT, and the config file which has source_home and target_home both pointing to the 26ai home since the previous 19c home plays no role in this upgrade anymore. And of course, calling AutoUpgrade with -mode upgrade is important. Don’t call it  with -mode deploy, it will fail since it will try an analyze/fixup as well which does not work here. I almost had forgotten about it.

If you want to run the recommended analyze/fixups actions, you need to do this beforehand in your 19c environment. I skipped this part in my sequence above.

Further Links and Information

• 3 PDBs included and the desupport of the non-CDB architecture
• DBCA database creation with your own template
• More information about AutoUpgrade and TARGET_PDB_COPY_OPTION

–Mike