ASM 12c : how to rename a Diskgroup

As there’s no option to do that with asmcmd, you have to connect to every node and execute “asmcmd umount recoc1“, use “dcli” if you are on Exadata or use the easier :

2/ Rename the DG with renamedg :

We can now rename the DG with renamedg; there’re two phases in renamedg but I don’t see much interest in detailing both of them nor in using phase 1 and then phase 2 as phase=both will do the whole job :

3/ Mount the DG back :

Same as to umount a DG, it is not possible to mount a DG on all the nodes using asmcmd then :

4/ Rename disks all

It is now time to rename the disks with the new diskgroup name. Indeed, disks are usually named diskgroupname_####, where #### is the disk number; it is better to have these disks named newdiskgroupname_####. A diskgroup has to be mounted in restricted before doing that :

5/ Check this new DG :

Let’s have a look at this new DG :

You will see that the old RECOC1 DG is still here (?) — we then have to remove it :

Quite easy for this one.
Now let’s see how it goes with the most likely situation where you have to rename a diskgroup that contains…many things.

– Rename a non-empty diskgroup

Here, this is a bit more tricky and painful, as we have to stop / move all the dependencies to this diskgroup before being able to umount it. Hopefully for me, no databases were created when I did that (but I’ll mention about what to do if you have some databases already created as well).

1/ Stop all the databases

The first step is to stop all the databases that use this diskgroup — you may need to stop all the database running on the server depending on how the ASM diskgroups have been designed on your server :

Note : don’t forget to put a blackout in your monitoring tool :)

2/ ASM spfile

Here, I chose to move it to RECO, as everything is under ASM, I don’t really like to let things outside of it.

Note : You can also use the spmove command to move the spfile.

3/ ASM passwordfile

I moved it to RECO as well :

If you have databases already created, you can use the pwmove command to move the passwordfiles of your databases to another diskgroup (or recreate it later).

4/ OCR and voting disks

As this is an Exadata (then a RAC), we have OCR and Voting; according the 12c renamedg documentation, we can use the parameter

to keep the voting disks on the diskgroup during the rename operation. As I found this option very weird (indeed, why would I delete the voting disks from my diskgroup during a rename operation ?), I have moved it to RECO as well.

First let’s double check that the OCR and Voting are on the DATAC1 diskgroup :

And then move everything to RECO :

OK good, we should be ready now, shouldn’t we? Well, not really, there’s a little 12c surprise that still depends on the DATAC1 diskgroup : MGMTDB !

5/ MGMTDB

MGMTDB is a new 12c feature; It is a 12c database used for storing the data of Cluster Health Monitor. It has a single instance in failover. Another interesting point is that it is a CDB with a PDB; I am not sure why a CDB and a PDB are needed here but this is how it has been designed.

Now, how to move it?  Follow the official documentation here : Drop MGMTDB (How to Move/Recreate GI Management Repository to Different Shared Storage (Diskgroup, CFS or NFS etc) (Doc ID 1589394.1). Yes, you got it, it is not supported to move it, you have to drop and recreate it — poor users that were really relying on the CHM data … but hopefully you can backup the data…

This procedure will NOT preserve Management Database contents. To back up manually in text format, as grid user on any node: 

… in text format… :)

Then let’s stop the resource, disable it and drop this database :

6/ Umount the Diskgroup

We can now umount the DATAC1 diskgroup !

7/ Rename the Diskgroup

After this quite long preparation, we can now rename the diskgroup :

8/ Mount the new diskgroup

For any reason, we still have a reference to the old DATAC1 diskgroup then we also have to remove it :

A quick check with asmcmd :

9/ Rename disk all

It is now time to rename the disks with the new diskgroup name. Indeed, disks are usually named diskgroupname_####, where ####  is the disk number; it is better to have these disks named newdiskgroupname_####. A diskgroup has to be mounted in restricted before doing that :

10/ Recreate MGMTDB

As MGMTDB is a Container Database with a Pluggable Database, we first have to recreate the CDB :

Then the PDB :

Check that MGMTDB is running :

And enable and start the resource :

11/ Set everything as it was previously

Then we have to set everything as it was previously set :

— OCR and Voting

— ASM spfile and passwordfile

Note : You can also use the spmove command to move the spfile.

— Restart cluster

Here, it is worth restarting the cluster to be sure that all is good after all the moves we did :

— Databases passwordfiles

There’s nothing to do about the databases passwordfiles.

— Database spfiles

Here, you have to modify all the parameters that still point to the old +DATAC1 like db_create_file_dest, db_create_online_log_dest_1, control_files, … and make them point to the new diskgroup +DATA instead of the old +DATAC1

— Database datafiles

If you had databases already created before renaming the diskgroup, as it is not possible to create a symbolic link like DATAC1  pointed to  +DATA and then use the very cool rename datafiles online 12c feature, you will have to rename it offline :

And then you should be done with this rename diskgroup operation !

As you can see, renaming a non-empty diskgroup (which is most likely what happens in real life), is (very) long and (very) painful, especially on clusters with many databases like we can have on some Exadatas, as many manual operations are needed to move the spfiles, passwordfiles, modify parameters and configuration, rename datafiles, etc… then it is easy to run into trouble at first human error. If we could at least create a symbolic link +DATAC1 that point to +DATA, we could speed up the operation and really rename what needs to be rename later knowing that many things can be renamed online.

My only advice here is to try to avoid this kind of tricky situation by checking, double checking, and triple checking with the client the name of the diskgroup they want, before doing anything else.

Hope this helps and best of luck if you need to rename a non-empty diskgroup!