ASM 12c : how to rename a Diskgroup

The first time I was asked to rename a diskgroup, I thought that it would be a trivial operation, but what should be an easy operation is not really that easy.
First, let's have a quick look at the procedure : from Oracle 11g, we have to use the renamedg command to rename a dismounted diskgroup, then the rough procedure is :
- Unmount the diskgroup
- Rename it with renamedg
- Mount the diskgroup
It looks like a walk in the park, right?
This example has been done on an X5-2 half rack Exadata, the goal here was to rename the RECOC1 diskgroup to RECO and the DATAC1 diskgroup to DATA - here is the situation before the rename operation : https://gist.github.com/freddenis/8a2d01d8e1066c139f48d1031317e5a4 Let's then explore the two different cases you can face when renaming a diskgroup with ASM 12c. When the diskgroup is empty and when the diskgroup is not empty.- Rename an empty diskgroup
In my example, RECOC1 was empty, the procedure is then quite straightforward :1/ umount the DG on *all* the nodes of the cluster
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 : https://gist.github.com/freddenis/ddd560668d07a38c21da24e73ccc4b8b3/ 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 : https://gist.github.com/freddenis/cb79b66393c05241c8d3a272a1091b8a4/ 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 : https://gist.github.com/freddenis/9c3f29ba5391ab9bc87b75aa4f1750a95/ Check this new DG :
Let's have a look at this new DG : https://gist.github.com/freddenis/9043e7a68660945ac65af5adf2967c27 You will see that the old RECOC1 DG is still here (?) -- we then have to remove it : https://gist.github.com/freddenis/be29943882ba8055616a89e5e4b68391 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 : https://gist.github.com/freddenis/74605e6587373b55c9eecaeb679e2b65 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. https://gist.github.com/freddenis/28393bb811878e2c397a10f5a4e811f1 Note : You can also use the spmove command to move the spfile.3/ ASM passwordfile
I moved it to RECO as well : https://gist.github.com/freddenis/b2394ea70964b4a2c26ec5a66e8326e7 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 https://gist.github.com/freddenis/44953dbbf0f1409338b3f42b4087428f 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 : https://gist.github.com/freddenis/152d4ec662d218409a715c8c6ddb6941 And then move everything to RECO : https://gist.github.com/freddenis/0fcb1cd46b75a4f50ceffc3cbd30cf26 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. https://gist.github.com/freddenis/ddf02d5ebfd241c27591af2e70ea5ceb 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 : https://gist.github.com/freddenis/d96c8d7d2485cac5c7eb83d2f2f8ade1