Rename LVM Volume Group Holding Root File System Volume

I’m not sure exactly when this change happened, but in Oracle [Enterprise] Linux 5 days a default installation would result in the root file system being created as a LVM logical volume (LV) named LogVol00 in a volume group (VG) named VolGroup00. I must confess that I wasn’t paying too much attention to LV and VG default names in the days I was playing with OL5 a lot, but that’s partly because there was nothing to drag my attention to them.

Along comes Oracle Linux 6 and off I go creating VMs, cloning them and then really not liking the fact that the default VG created during the installation, and holding the LV for the root file system, is named vg_<hostname> where <hostname> is the hostname of the original VM I installed. If I clone a VM the next thing I do is change the hostname, which means that I’m left with an inconsistent and somewhat confusing VG name. I think I screwed up one VM before realising that it wasn’t just simply a case of renaming the VG and updating /etc/fstab. I asked a friend who does much more Linux admin how to achieve what I wanted and didn’t take it any further when he said words to the effect of, “Yeah, it’s more complicated than that.”

Fairly recently I walked into the same situation again, only this time I decided that I wasn’t going to take “more complicated” for an answer :-). I searched, found a few articles that seemed to have logic in their approach and figured I had nothing to lose. I also thought there were some redundant steps in the posts I was following, hence feeling it’s worth blogging my slimmed down approach.

Well, that’s enough preamble. Here’s the details:

1) Boot Into Rescue Mode

For me booting from CD/iso was the easiest way to get into “rescue mode”. To do this select “Rescue installed system” when the welcome screen is presented during the boot process. You will then be prompted with:

Choose a Language – You know better than I what’s the best choice for you. Select it and then OK.

Keyboard Type – Again, pick what you think best matches your keyboard. Then select OK.

Rescue Method – Select “Local CD/DVD”, then OK.

Setup Networking – Select “No”

Rescue – Select “Continue”

Rescue (message about your system being mounted under /mnt/sysimage and use of chroot) – OK.

Rescue (another message about having mounted your system under /mnt/sysimage) – OK.

First Aid Kit quickstart menu – Select “shell  Start shell”, then OK.

The above will get you to a prompt so you can actually do what you came here for!

2) Rename Volume Group

The LVM commands you issue are the same as usual, only they need to be prefixed with lvm. I suggest listing the VGs to be sure the state of the system is as you expect, and using more is a good idea as you don’t have a scrollbar, i.e.:

lvm vgdisplay | more

Once you’re happy, rename the VG as below:

lvm vgrename <original> <desired>

You should get a success message after this command.

3) Update All References

Change the root directory to that of your installed system using chroot:

chroot /mnt/sysimage

The following files need to be modified to replace references to the old VG name with the new VG name:

  • /etc/fstab
  • /boot/grub/grub.conf

There will be multiple references per line in grub.conf, so a bit of “global replace” is in order.

4) Create New Ramdisk Image

Run the following command to make a new initial ramdisk image

mkinitrd --force /boot/initramfs-<kernel version>.img <kernel version>

Note that the force option is only required because there is already an existing image with the same name. You could use a different name if you want, but you’d need to add an appropriate entry to the grub.conf to reflect this.

If the above command completes without error messages and you didn’t make any errors in the editing of the files earlier then you should be all set… Only one way to find out!

5) Reboot Machine

Exit out of the chroot environment (type “exit”).

Exit out of the shell to return to the “First Aid Kit quickstart menu” (type “exit”).

First Aid Kit quickstart menu – Select “reboot Reboot”, then OK.

At the welcome screen select “Boot from local drive”.

If all goes well then remember to remove the CD/iso from your [virtual] CD drive.


The 2 articles that helped me with this are the following, so thanks to the authors:

Update [27th January 2014]

I have just noticed that the default volume group name when installing Oracle Linux 6.5 has changed from “vg_<hostname>” to “VolGroup”.

SQL_Developer to SQL Developer

When I first ran SQL Developer on my Mac I remember being a bit put off by the fact that the application name showed up as SQL_Developer rather than SQL Developer as I would have expected.

The address book application shows up as Address Book rather than Address_Book and Keychain Access show up as just that, rather than Keychain_Access. Just to pick two examples from my running applications. It just doesn’t look right!

That was a few years ago and I figured there must be a reason why it’s like this, but it didn’t bother me enough to spent any time trying to understand why it is this way and if there is any way to change it.

Having found my way into the inner files of /Applications/ during my recent attempts to get SQL Developer working with EUS I thought it was time to see if I could work out why, and ideally “fix” it.

It turned out to be amazingly simply. I ran a quick find with grep to look for files that had the string “SQL_Developer”:

macbook-pro:~ martin$ find /Applications/ -type f -exec grep -H SQL_Developer {} \;
macbook-pro:~ martin$ 

Well, this looks easy!

A quick test of changing the option to “SQL Developer” and a restart of the application makes me a happier man.

I’d like to clarify that I know this is a bit of a trivial/weird thing to be bothered by, but it just messes with my desire for consistency.

For the full harmonising effect you can also rename the application “file” in your Applications folder from SQLDeveloper to SQL Developer so that the application name in the dock and menu bar match up.

How to rename ASM diskgroup in 11.2

I hope you always do thing right from the first attempt. Sadly I am not. I have generate the Database on incorrectly named ASM Diskgroups.
And there was no space to create the new one to switch to image copy. Luckly it was 11g database that have ASM disk group rename option.
This is the my step by step instruction how to rename ASM diskgroup with RAC database running on it.

1.Switch to clusterware environment
2.Get DB configuration

$ srvctl config database -d orcl

Database unique name: orcl
Database name:
Oracle home: /u01/oracle/product/11.2.0/db_1
Oracle user: oracle
Spfile: +ORA_FRA/orcl/spfileorcl.ora
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: orcl
Database instances: orcl1,orcl2
Mount point paths:
Services: srvc_orcl
Type: RAC
Database is administrator managed

3. Get ASM configuration

$ srvctl config asm -a

ASM home: /u01/grid/
ASM listener: LISTENER
ASM is enabled.

4. If there is no SPFILE check init.ora files

$ cat /u01/grid/
$ cat /u01/grid/

5. Prepare Database configuration

5.1 Backup spfile
change environment to the orcl

sqlplus "/as sysdba"
create pfile='/u01/oracle/product/11.2.0/db_1/dbs/initorcl.ora.bkp' from spfile;

File created.

5.2 Prepare commands to rename files

SQL > select 'ALTER DATABASE RENAME FILE '''||NAME||''' TO '''||REPLACE(NAME,'+ORA_DATA','+NEW_DATA')||'''; ' FROM v$datafile;
SQL > select 'ALTER DATABASE RENAME FILE '''||NAME||''' TO '''||REPLACE(NAME,'+ORA_DATA','+NEW_DATA')||'''; ' FROM v$tempfile;

– sample output

ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_1.271.783943471' TO '+NEW_REDO/orcl/onlinelog/group_1.271.783943471';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_2.259.783944261' TO '+NEW_REDO/orcl/onlinelog/group_2.259.783944261';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_3.269.783943509' TO '+NEW_REDO/orcl/onlinelog/group_3.269.783943509';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_4.267.783943593' TO '+NEW_REDO/orcl/onlinelog/group_4.267.783943593';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_12.265.783944075' TO '+NEW_REDO/orcl/onlinelog/group_12.265.783944075';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_11.257.783944289' TO '+NEW_REDO/orcl/onlinelog/group_11.257.783944289';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_13.263.783944091' TO '+NEW_REDO/orcl/onlinelog/group_13.263.783944091';
ALTER DATABASE RENAME FILE '+ORA_REDO/orcl/onlinelog/group_14.260.783944103' TO '+NEW_REDO/orcl/onlinelog/group_14.260.783944103';
ALTER DATABASE RENAME FILE '+ORA_DATA/orcl/datafile/system.258.783943013' TO '+NEW_DATA/orcl/datafile/system.258.783943013';
ALTER DATABASE RENAME FILE '+ORA_DATA/orcl/datafile/sysaux.262.783942959' TO '+NEW_DATA/orcl/datafile/sysaux.262.783942959';
ALTER DATABASE RENAME FILE '+ORA_DATA/orcl/datafile/undotbs1.261.783942985' TO '+NEW_DATA/orcl/datafile/undotbs1.261.783942985';
ALTER DATABASE RENAME FILE '+ORA_DATA/orcl/datafile/data.263.783942913' TO '+NEW_DATA/orcl/datafile/data.263.783942913';
ALTER DATABASE RENAME FILE '+ORA_DATA/orcl/datafile/undotbs2.259.783943011' TO '+NEW_DATA/orcl/datafile/undotbs2.259.783943011';
ALTER DATABASE RENAME FILE '+ORA_DATA/orcl/tempfile/temp.281.783943239' TO '+NEW_DATA/orcl/tempfile/temp.281.783943239';

5.3 Prepare new initialisation parameter file

$ cp /u01/oracle/product/11.2.0/db_1/dbs/initorcl.ora.bkp /u01/oracle/product/11.2.0/db_1/dbs/initorcl.ora.old
$ vi /u01/oracle/product/11.2.0/db_1/dbs/initorcl.ora.bkp


and all other parameters containing old DISK GROUPS names

5.4 Prepare database for moving: disable block change tracking and flashback

SQL > alter database disable block change tracking;
SQL > alter database flashback off;

6. Stop databases
$ Switch to clusterware environment

srvctl stop database -d orcl

7. Unmount Diskgroups on all nodes

$ asmcmd umount ORA_DATA 
$ asmcmd umount ORA_FRA 
$ asmcmd umount ORA_REDO

– check that all groups are unmounted

$ asmcmd lsdg 

8. Run rename discgroups commands
– stop the second node to leave first node exclusive owner

$ crsctl stop has on node 2
$ renamedg phase=both dgname=ORA_DATA newdgname=NEW_DATA verbose=true 
$ renamedg phase=both dgname=ORA_FRA  newdgname=NEW_FRA verbose=true 
$ renamedg phase=both dgname=ORA_REDO newdgname=NEW_REDO verbose=true 

9. Mount renamed Diskgroups

$ asmcmd mount NEW_DATA
$ asmcmd mount NEW_FRA
$ asmcmd mount NEW_REDO

– check that all groups are mounted

$ asmcmd lsdg 

9. Bring up orcl
change environment to the orcl

$ sqlplus "/as sysdba"
SQL > startup nomount pfile='/u01/oracle/product/11.2.0/db_1/dbs/initorcl.ora.bkp'
SQL > alter database mount;

10. Run prepared rename files commands

SQL > ...
SQL > create spfile='+NEW_FRA/orcl/spfileorcl.ora' from pfile='/u01/oracle/product/11.2.0/db_1/dbs/initorcl.ora.bkp'

11. modify link to spfile

$ vi /u01/oracle/product/11.2.0/db_1/dbs/initorcl1.ora on node 1


$ vi /u01/oracle/product/11.2.0/db_1/dbs/initorcl2.ora on node 2

to poing to new DISKGROUP

12. modify database configuration in clusterware

$ srvctl modify database -d orcl -p +NEW_FRA/orcl/spfileorcl.ora
$ srvctl modify database -d orcl -a "NEW_DATA,NEW_FRA,NEW_REDO"
$ srvctl config database -d orcl 
$ srvctl start database -d orcl 

13. enable temporary disable functionality

SQL >  alter database enable  block change tracking;
SQL >  alter database flashback on;


$ crsctl delete resource ora.ORA_DATA.dg
$ crsctl delete resource ora.ORA_FRA.dg
$ crsctl delete resource ora.ORA_REDO.dg

As result all the configuration that has been done inside database has been saved

11.2 Oracle Restart – Changing Hostname

It has taken me a good deal longer that I would have expected to change the hostname on some cloned VMs that are home to Oracle 11.2 databases running on ASM with Oracle Restart.

I was clearly not alone in thinking that it would just be a case of running localconfig delete/localconfig add, as I have done in the past for hosts running Oracle database 10.2 with ASM for storage. However, things have changed and having done a fair amount of searching using both MetaLink (My Oracle Support) and Google it appears that there isn’t much out there yet in the form of clear instructions. The best I could find was My Oracle Support article ID 887658.1, which got me moving in the right direction.

So, in the hope of saving others the time I have lost working this out, here are the steps I used to rename a Linux host running Oracle Database 11.2 with ASM in an Oracle Restart configuration. The steps have been written for an installation that splits the ownership of the “Grid Infrastructure” and the database between a user named grid and a user named oracle respectively. It is important who you run at least some of these commands as, so please check which user you are before each command. Or more likely, if things don’t look to be working then check which user you ran the command as before going further. It is easy to backtrack if you do get it wrong.

Remove the existing configuration as root (with ORACLE_HOME set to the grid home):

[root@old-host grid]# $ORACLE_HOME/perl/bin/perl -I $ORACLE_HOME/perl/lib -I $ORACLE_HOME/crs/install $ORACLE_HOME/crs/install/ -delete

* In some of my earlier attempts I stopped everything gracefully, but it does not appear to be necessary.

Change the value of HOSTNAME in the network file using the editor of your choice.

[root@old-host ~]# vi /etc/sysconfig/network

Update /etc/hosts as appropriate

[root@old-host ~]# vi /etc/hosts

Change the IP address in ifcfg-<interface> as required

[root@old-host ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

Change the hostname in the listener configuration file

[root@old-host ~]# vi $ORACLE_HOME/network/admin/listener.ora

* Clearly you don’t need to be root to do the previous command, but as reboot is next it doesn’t seem worth switching user.

Reboot to pickup hostname change

When the host has restarted run as root (with ORACLE_HOME set to the grid home)

[root@new-host grid]# $ORACLE_HOME/perl/bin/perl -I $ORACLE_HOME/perl/lib -I $ORACLE_HOME/crs/install $ORACLE_HOME/crs/install/

The output should look something like:

2009-12-19 15:10:36: Checking for super user privileges
2009-12-19 15:10:36: User has super user privileges
2009-12-19 15:10:36: Parsing the host name
Using configuration parameter file: /u01/app/grid/product/11.2.0/grid/crs/install/crsconfig_params
Creating OCR keys for user 'grid', privgrp 'oinstall'..
Operation successful.
CRS-4664: Node new-host successfully pinned.
Adding daemon to inittab
CRS-4123: Oracle High Availability Services has been started.
ohasd is starting

2009/12/19 15:11:58     /u01/app/grid/product/11.2.0/grid/cdata/new-host/backup_20091219_151158.olr
Successfully configured Oracle Grid Infrastructure for a Standalone Server

Exit from root user.

You now need to add the listener, ASM, database and services (if applicable) into the Oracle Restart configuration.

[grid@new-host ~]$ srvctl add listener
[grid@new-host ~]$ srvctl add asm -d '/dev/sd[a-h]1'
[grid@new-host ~]$ srvctl start listener
[grid@new-host ~]$ srvctl start asm

* Your asm_diskstring, specified with the -d option to “srvctl add asm”, with almost certainly be different!

Note that the diskgroups are not automatically added back to the Oracle Restart configuration (as shown by the output of “srvctl status” below) and must be manually started:

[grid@new-host ~]$ srvctl status diskgroup -g data
PRCR-1001 : Resource ora.DATA.dg does not exist

[grid@new-host ~]$ sqlplus /nolog
SQL> conn / as sysasm
SQL> alter diskgroup data mount;

Diskgroup altered.

SQL> exit

[grid@new-host ~]$ srvctl status diskgroup -g data
Disk Group data is running on new-host
[grid@new-host ~]$

Adding the database to Oracle Restart:

[oracle@new-host ~]$ srvctl add database -d ora11gr2 -o $ORACLE_HOME -n ora11gr2 -p +DATA/ora11gr2/spfileora11gr2.ora -a DATA
[oracle@new-host ~]$ srvctl config database -d ora11gr2
Database unique name: ora11gr2
Database name: ora11gr2
Oracle home: /u01/app/oracle/product/11.2.0/db_1
Oracle user: grid
Spfile: +DATA/ora11gr2/spfileora11gr2.ora
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
[oracle@new-host ~]$ srvctl start database -d ora11gr2
[oracle@new-host ~]$ srvctl status database -d ora11gr2
Database is running.
[oracle@new-host ~]$

That should be it. The only other place to update the home name is in the tnsnames.ora file.

Simply Renaming A Schema

What started off as just moving a database from UAT to QA soon turned into something slightly more complex, with an interesting discovery for me.

For reasons that preceed my involvement in this project, not only did the database name indicate the region (UAT, QA, production), but the username for the application schema also indicated the region. This didn’t fit with the standard, but the work required to change this in all regions wasn’t considered viable.

Anyway, this left me in a position of having copied and renamed the UAT database to QA, but the application username/schema indicated UAT. This was clearly a recipe for later confusion… What I needed was to rename the schema, but unfortunately Oracle doesn’t provide this as one-liner.

This is a database, so it was time for imp and exp… “Just a case of export user, create new appropriately named user, import from original user to new user, drop original user if all goes smoothly.” Well, it didn’t.

The export went fine, but when importing I hit ORA-02304 errors in more than one place. This was a new one on me. An example of the errors is shown below:

IMP-00003: ORACLE error 2304 encountered
ORA-02304: invalid object identifier literal
IMP-00017: following statement failed with ORACLE error 2304:
"CREATE TYPE "xxxxxxx" TIMESTAMP 'yyyy-mm-dd:hh24:mi:ss' OID '###############"

Oracle was complaining about the fact that I was trying to create objects with same object identifier (OID) as objects that already exist in the database. I had decided that keeping the original schema in place until I’d the new user was successfully imported was a sensible thing to do just in case things didn’t go to plan, but as it turned out keeping the original user in the database whilst importing under the new user was the root of my problem.

If you found this page because, like me, you haven’t yet got to the point of checking MetaLink as the first port of call then check out MetaLink note 1066139.6 for more detail.