---
title: "ASM 12c : how to rename a Diskgroup"
description: 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 e
---

[Blog | Pythian ](https://www.pythian.com/blog)

# [ASM 12c : how to rename a Diskgroup](https://www.pythian.com/blog/asm-12c-rename-diskgroup)

 Written by [Fred Denis](https://www.pythian.com/blog/author/fred-denis) | Aug 9, 2016 4: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](https://docs.oracle.com/database/121/OSTMG/GUID-45A0F079-2D23-47D3-A366-569076D2F845.htm#OSTMG94159) command to rename a dismounted diskgroup, then the rough procedure is :

1. Unmount the diskgroup
2. Rename it with renamedg
3. 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](https://docs.oracle.com/database/121/OSTMG/GUID-45A0F079-2D23-47D3-A366-569076D2F845.htm#OSTMG94159); 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](https://docs.oracle.com/database/121/OSTMG/GUID-05F55D3C-F582-481E-8C23-A58E16260DAD.htm#OSTMG94431) 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](https://docs.oracle.com/database/121/OSTMG/GUID-6DFC9F42-A949-412F-B9F3-D947C1A620B8.htm#OSTMG95378) 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](https://docs.oracle.com/database/121/OSTMG/GUID-45A0F079-2D23-47D3-A366-569076D2F845.htm#OSTMG94159), 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

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

### 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](https://docs.oracle.com/database/121/OSTMG/GUID-05F55D3C-F582-481E-8C23-A58E16260DAD.htm#OSTMG94431) 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](https://docs.oracle.com/database/121/ADMIN/dfiles.htm#ADMIN11430), 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](https://blog.pythian.com/status-script-exadata/), 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 disk group!

## Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?

[View full post](https://www.pythian.com/blog/asm-12c-rename-diskgroup)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Fred Denis"
  },
  "dateModified" : "2026-03-01T16:09:05.688Z",
  "datePublished" : "2016-08-09T04:00:00Z",
  "headline" : "ASM 12c : how to rename a Diskgroup",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://www.pythian.com/blog/asm-12c-rename-diskgroup",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Pythian Blog"
  }
}
```