SAN Migration and moving files with ASM
17/01/2017 Leave a comment
Here’s a quick post to help with LUN, SAN or File migration when using Oracle ASM.
Please note that this is just an example method, and is not a definitive guide.
You need to ensure your approach is appropriate for your environment.
Did you know that you can add and drop disks on a diskgroup in a single command.
This saves Oracle from doing 2 REBAL actions and speeds things up considerably using a lot fewer resources.
sqlplus / as sysasm; > ALTER DISKGROUP data 2 ADD DISK 'ORCL:disk101','ORCL:disk102' 3 DROP DISK 'disk042' ,'disk043' 4 REBALANCE POWER n; Diskgroup altered.
You can monitor the REBAL operation:
select * from v$asm_operation; GROUP_NUMBER OPERA PASS STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE CON_ID ------------ ----- --------- ---- ----- ------ ----- -------- -------- ----------- ---------- ------ 6 REBAL REBALANCE RUN 1 1 68 20397 3030 8 0 6 REBAL COMPAT WAIT 1 1 0 0 0 0 0
If you are just migrating from one SAN to another, without needing to move files between diskgroups, this is a really easy way to achieve it.
From Oracle 12.1 onwards. if you are moving Datafiles from one Diskgroup to a new Diskgroup, that’s straightforward too:
export ORACLE_SID=ORCL sqlplus / as sysdba alter database move datafile '+DATA_DG/ORCL/DATAFILE/system.101.902468275' to '+NEW_DG';
Moving logfiles involves a drop and re-create, but it still fully online.
Take care if using DataGuard that you do not try to drop logfiles before they are archived and applied to the standby:
alter database add logfile member '+NEW_DG' to group 1; alter database drop logfile member '+DATA_DG/ORCL/ONLINELOG/group_1.102.902049284';
Moving tempfiles can be tricky. The default gets used really quickly after startup.
You need to add a tempfile and then get all processes to not be using the old tempfile before you can drop it [select * from gv$sort_usage]. Worst-case, this may involve a SHUTDOWN, then a STARTUP RESTRICT to stop processes connecting. Alternatively, create a new default TEMP tablespace and convince processes to use that one.
alter tablespace temp add tempfile '+NEW_DG'; alter tablespace temp drop tempfile '+DATA_DG/ORCL/TEMPFILE/temp.204.992482742';
Moving controlfiles requires a stop and start of the database. There’s no on-line options here. I tend to do the following:
srvctl stop database -d ORCL sqlplus / as sysdba startup nomount show parameter control_files rman target / restore controlfile to '+NEW_DG' from '+DATA_DG/ORCL/CONTROLFILE/current.291.939274434'; sqlplus / as sysdba alter system set control_files='+NEW_DG/ORCL/CONTROLFILE/current.992.346677889' ,'+FRA_DG/ORCL/CONTROLFILE/current.???.?????????' scope=spfile sid='*'; shutdown srvctl start database -d ORCL
To move your spfile in ASM is a 2-stage process which will automatically update your database config in grid control:
sqlplus / as sysdba create pfile='/tmp/ORCL.ora' from spfile; create spfile='+NEW_DG' from pfile='/tmp/ORCL.ora';
Moving a password file in ASM is straightforward too:
NOTE: you are not allowed to move OMF files names and you must copy files via their alias.
as grid: asmcmd cp +DATA_DG/ORCL/orapworcl +NEW_DG/ORCL/orapworclexit as oracle: srvctl modify database -d ORCL -pwfile +NEW_DG/ORCL/orapworclsrvctl config database -d ORCL | grep Password
If you are using Block Change Tracking, you may need to move that file too:
alter database disable block change tracking; alter database enable block change tracking using file '+NEW_DG';
Finally, if you’re dropping disk groups don’t forget to modify the disk group dependencies in Grid Infra so your DB isn’t dependent upon groups you have now removed:
srvctl config datbase -d ORCL | grep Group srvctl modify database -d ORCL -diskgroup 'NEW_DG,FRA_DG,other_DG'
I hope you found this quick guide useful.