This was actually a question on Oracle forum which I had replied to. Basically the Poster, wanted to know if he could rename the ASM Diskgroup name by renaming/editing ASM Disk header. He had also mentioned that he had heard about this being done by Oracle for its few customers using kfed.
Answer is NO. It is not possible to rename the diskgroup by editing the ASM disk header. kfed is known to be used for patching ASM disk headers for corruption (only oracle support can do it) and for viewing ASM header contents. Only way to change this by dropping and recreating the diskgroup.
In case you wish to create a new diskgroup with a name say +DG1 which was being used by a Diskgroup which is not mounted (Have some ASM Disk members still in ASM_DISKSTRING path), then you would face following error
ORA-15030: diskgroup name "string" is in use by another diskgroup
Cause: A CREATE DISKGROUP command specified a Diskgroup name that was already assigned to another diskgroup.
Action: Select a different name for the Diskgroup.
In case you wish to create the Diskgroup with same name +DG1 you will be required to clear the ASM disk header using
dd if=/dev/zero of=/dev/raw/raw11 bs=1024 count=100
After this you can recreate the Diskgroup with same name.
One Poster suggested renaming at LUN/Storage level. I believed this to be a destructive idea which could corrupt the Diskgroup. nvengurl replied to this and informed that we read ASM disk header to mount the Diskgroup and thus changing the LUN name/id/path will not solve the issue.
A disk Group can be renamed. I have implemented this procedure with customers that required to mount several clones of the production database on the same server.
Regards,
Alejandro
Alejandro,
I believe there is not a straight forward way to do it. May be you would have used kfed. In any case is the solution available to customers or is it only support can do it.
I found that a solution to rename Diskgroup has been posted on the OTN Forum. You can find the thread here . Please note that I have not tested this and would not recommend it to be run on production databases.