Task to migrate ASM diskgroups to another storage is not too complicate if you can afford some downtime period.

If you can, then the basic steps are:

1. Shut down all Oracle Db instances that are using ASM instance which you are going to migrate into the new storage.

2. Shut down Grid infrastructure/Clusterware (that will shut down ASM instance on that particular node as well).

3. Start up Grid infrastructure.

4. Add a new disks that will reside on the new storage.

chown oracle:oracle /dev/rhdisk93
chmod 660 /dev/rhdisk94

chown oracle:oracle /dev/rhdisk93
chmod 660 /dev/rhdisk94

5. Perform migration by executing the following command:


alter diskgroup DATA add disk '/dev/rhdisk93', '/dev/rhdisk94' drop disk 'DATA_0000', 'DATA_0001' rebalance power 6 nowait;

6. Remove old disks (disks that are on the old storage) by executing the following commands (as a root user):

rmdev -dl hdisk1
rmdev -dl hdisk2

The last command will execute successfully because in previous steps you have restarted clusterware.

7. Start database instances.

 

But in most cases (especially with large databases) you’ll want to perform storage migration online.

This is possible, but you have to introduce several workarounds.

1. In case you are not able to delete disk devices from OS

rmdev -dl hdisk1

Method error (/usr/lib/methods/ucfgdevice):
0514-062 Cannot perform the requested function because the
specified device is busy.

You’ll have to run

fuser -fu /dev/rhdisk1

/dev/rhdisk1: 8978588(oracle) 14876792(oracle)

And then:
perl close_fds.pl 8978588 14876792

The close_fds.pl is Perl script that will connect to ASM instance and close all staled disk descriptors (you’ll need to have MOS credentials to be able to download that script).

2. Execute the following statement against ASM instance


select p.spid FG_OSPID, s.process CL_OSPID, s.program CL_NAME
from v$session s, v$process p
where p.addr = s.paddr
and spid = '&ospid_seen_in_fuser';

If the daemon process is crsd.bin or CRSD agent, then you can restart it while Oracle Db is running:

crsctl stop res ora.crsd -init
crsctl start res ora.crsd -init

If the agent is OHASD agent, you can kill that process (oraagent.bin) with
kill -9

3.
Case which is not described in any Oracle Note is when the process belongs to running Oracle Database.

perl close_fds.pl 55640114 9503098 51446250 51642636 6042462

SYS@+ASM2> ORA-00075: process “Unix process pid: 55640114, image: ” not found in this instance
SYS@+ASM2> ORA-00072: process “9503098” is not active
SYS@+ASM2> ORA-00075: process “Unix process pid: 51446250, image: ” not found in this instance
SYS@+ASM2> ORA-00072: process “51642636” is not active
SYS@+ASM2> ORA-00075: process “Unix process pid: 60424628, image: ” not found in this instance

As you can see, there are several processes that not belong to ASM instance.

Searching for process details by using grep utility shows it’s not related to Clusterware either.

As the owner of those processes are oracle user, you can execute the following command to get more detail regarding sessions that are using staled disk descriptors:


select *
from v$session s, v$process p where s.paddr = p.addr and p.spid in (55640114, 51446250, 60424628); 

After inspecting, in most situation you can kill those processes.


select 'alter system kill session ''' || s.sid || ','  || s.serial# || ''' immediate;' 
from v$session s, v$process p where s.paddr = p.addr and p.spid in (55640114, 51446250, 60424628);

After that, you’ll be able to remove disk from the OS.



Get notified when a new post is published!

Loading

Comments

There are no comments yet. Why not start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.