ASM 12c : how to rename a Diskgroup

by Fred Denis on Aug 9, 2016 12:00:00 AM

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

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 : https://gist.github.com/freddenis/895f577efa9a87a19f392d49e67dae35

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/ddd560668d07a38c21da24e73ccc4b8b

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 : https://gist.github.com/freddenis/cb79b66393c05241c8d3a272a1091b8a

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 : https://gist.github.com/freddenis/9c3f29ba5391ab9bc87b75aa4f1750a9

5/ 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

6/ Umount the Diskgroup

We can now umount the DATAC1 diskgroup ! https://gist.github.com/freddenis/1eeb5a328a989b5c48751f836ca94d43

7/ Rename the Diskgroup

After this quite long preparation, we can now rename the diskgroup : https://gist.github.com/freddenis/98d945a5a62eb7d8d591163d473a8fa6

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 : https://gist.github.com/freddenis/38bc3e52086aa8d069e7058cebdf7dc4 A quick check with asmcmd : https://gist.github.com/freddenis/ad242156fe6c344eaf01d3748aef1999

9/ Rename disk all

10/ Recreate MGMTDB

As MGMTDB is a Container Database with a Pluggable Database, we first have to recreate the CDB : https://gist.github.com/freddenis/3d1540fda0e3b7ee245d90a72703d266 Then the PDB : https://gist.github.com/freddenis/60a0eefcb3e6241d3abc43d13aa29d05 Check that MGMTDB is running : https://gist.github.com/freddenis/52997ed8bfc43053b67b40e30d17319c And enable and start the resource : https://gist.github.com/freddenis/48bda9ffd301b74af3b3ad355c2fc37b

11/ Set everything as it was previously

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

-- OCR and Voting

https://gist.github.com/freddenis/d8aa6b669b3a95c6d6011d7e1b6bfa93

-- ASM spfile and passwordfile

https://gist.github.com/freddenis/82b0523844cd84f5250785d56d0c8cfe 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 : https://gist.github.com/freddenis/6dc363fc844f651b9c699192b609473c

-- 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 : https://gist.github.com/freddenis/dad334e7a1c806c329c4efab20aab689 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!

Topics: Linux Monitoring Java Technical Track

No Comments Yet

Let us know what you think

Share this