Refreshable clone with AutoUpgrade but keep your RAC configuration?

I had to shorten the headline a bit. It got very bulky saying at first: Use a Refreshable Clone with AutoUpgrade from non-CDB to PDB but keep your RAC configuration alive. Well, you see, that’s bulky. But it describes the case I would like to briefly show you. Helmut Pfau, a colleague of mine here in Germany asked this the other day, and it took us a bit to get the correct answer to him – I confess, simply because I didn’t know the right AutoUpgrade parameter.

Photo by Adrian Infernus on Unsplash

We love Refreshable Clones

You’ve seen it in our seminars, our in-person workshops – we love to use Refreshable Clones especially for the migration from non-CDB to PDB. Regardless of whether you move to a new release or just stay within the same patch level. It’s convenient, perfect for testing, very handy – and AutoUpgrade does it all fully automated end-to-end for you.

For those of you who haven’t seen this before: The magic is that you can easily migrate your non-CDB into a PDB skipping the downtime piece for copying around a large database. Your source stays intact, and you can test this multiple times. The only real downside is that Refreshable Clones don’t propagate seamlessly to the standby site. So, when you use this for a production environment, you need to be aware that you will use Deferred Recovery on the standby, and you need to restore your PDB.

You can see the entire process including the standby part in our Virtual Classroom Seminars #19:

• 1:06:00 Migration – Refreshable Clones – includes DEMO
• 1:17:33 Migration – Customer Case: ZKB

But my RAC configuration …

Now back to Helmut and his honest question for a migration from non-CDB to PDB, in this case involving also the upgrade to 23ai.

Now if the source is Non-CDB (and we still have a lot of 19c Non-CDBs), the files are copied or not, but in both cases there are no cluster resources (database instance), no services and no /etc/oratab entries any more.

So basically, AutoUpgrade wiped out the configuration in the source home. Which is less than ideal especially since we run around everywhere telling people that this technique by using AutoUpgrade is the ideal vehicle for testing. It’s obviously less ideal when your services get removed when you want your production to be alive when you test.

Daniel has this excellent blog post for this case – but he didn’t talk about this service cleanup part. And zero blame on him, the option I am going to talk about did not exist by the time he wrote the blog post.

Many parameters

AutoUpgrade has a lot of options. It is like a super-sports car. You can drive very fast but you have also a lot of setup options. If only I would read our own documentation more often.

Helmut had used already these AutoUpgrade parameters:

• upg1.keep_source_pdb=yes
  • (Optional) Specifies if the source PDB in an unplug-plug upgrade operation is kept in a closed state instead of being removed from the source CDB.

    Usage Notes

    By default, the source PDB is removed from the source CDB during the upgrade process. When keep_source_pdb is set to YES, the source PDB is not removed from the earlier release system. You are only able to set the parameter to YES when the copy option is specified in the parameter target_pdb_copy_option. When the copy option is not used, this parameter is ignored, because the PDB must be dropped. Without a copy, the existing datafiles can only be used by a single CDB.
    .

• upg1.target_pdb_copy_option=file_name_convert=none
  • (Optional) Specifies the file_name_convert option used by the create pluggable database statement that AutoUpgrade runs when converting a non-CDB database to a PDB or an existing PDB from a different source CDB into a PDB in the specified target CDB.
  • See also: More Information on target_pdb_copy_option
    .
• upg1.close_source=no
  • (Optional) Closes the source non-CDB or source PDB just before AutoUpgrade starts a non-CDB to PDB conversion, starts an unplug-relocate upgrade, or uses a refreshable clone PDB.

    Usage Notes

    During the operations described above, if close_source is set to yes (the default), then AutoUpgrade closes source non-CDB or source PDB just before starting the upgrade. Additionally, if Oracle Real Application Clusters or Oracle Grid Infrastructure (CRS) services are configured for a non-CDB source, then they are disabled before starting the upgrade.

    This parameter can only be used when the source and target databases are both on the same system. When they are on different systems, the source non-CDB or PDB cannot be closed, because AutoUpgrade has no access to it.
    .

The first one, keep_source_pdb won’t help here since we don’t do an unplug/plug operation but it doesn’t harm either. Furthermore, target_pdb_copy_option is used to ensure that you have your PDB being copied, mapping to COPY/NOCOPY in the raw command. Very much needed in our case but doesn’t tackle the original problem.

And finally you may set close_source=NO for the testing case we are talking about here to prevent your source from being shutdown at start_time.

But none of the above options solve the problem that the RAC configuration got cleaned up in the source environment.

Byron to the rescue …

I love the Upgrade Development Team not only for the positive team spirit but also for the wealth of knowledge and experience – and for foreseeing things and covering them proactively.

Byron knew the solution. It is:

• upg1.remove_rac_config=NO
  • (Optional) Specifies whether to remove a non-CDB Oracle RAC database from clusterware on the source Oracle home after a successful conversion to the target CDB home, or to leave the source database unchanged.

    Usage Notes

    By default, the source Oracle RAC database configuration on a non-CDB is removed from the source Oracle Grid Infrastructure when it is migrated to a CDB during the upgrade process. When remove_rac_config is set to no, the source Oracle RAC database is not removed from the earlier release non-CDB system.
    .

This does the trick.

Very simple, isn’t it? Well, when you know the solution – thanks Byron!! And this way I can remove an information from my inbox and hopefully will find it later again when needed.

Further Links and Information

• AutoUpgrade Parameter remove_rac_config
• AutoUpgrade Parameter close_source
• AutoUpgrade Parameter target_pdb_copy_option and More Information on target_pdb_copy_option
• AutoUpgrade Parameter keep_source_pdb
• Daniel’s blog post for non-CDB to PDB conversion with AutoUpgrade
• Virtual Classroom Seminars

–Mike