The preferred way of doing the file movement amoung ASM DISKGROUPS is using RMAN. RMAN is critical to Automatic Storage Management and is responsible for tracking the ASM filenames and for deleting obsolete ASM files. Since ASM files cannot be accessed through normal operating system interfaces, RMAN is the preferred means of copying ASM file.
The steps involved in moving a datafile from a diskgroup to another is as given below.
1) Identify the data file to be moved.
2) Identify the diskgroup on to which the file has to be moved.
3) Take the file offline.
4) Copy the file to new diskgroup using Either RMAN or DBMS_FILE_TRANSFER.
5) Rename the file to point to new location.
6) Recover the file.
7) Bring the file online.
Verify the new file locations.
9) Delete the file from its original location.
1) Identify the data file to be moved.
—————————————-
In database instance
SQL:ORCL> SELECT FILE_NAME FROM DBA_DATA_FILES:
+ASMDSK2/orcl/datafile/users.256.565313879 <======= Move this to ASDSK1.
+ASMDSK1/orcl/sysaux01.dbf
+ASMDSK1/orcl/undotbs01.dbf
+ASMDSK1/orcl/system01.dbf
2) Identify the diskgroup on to which the file has to be moved.
--------------------------------------------------------------
In ASM instance
SQL:ASM> SELECT GROUP_NUMBER, NAME FROM V$ASM_DISKGROUP;
GROUP_NUMBER NAME
———— ———
1 ASMDSK1
2 ASMDSK2
3) Take the file offline.
————————–
SQL:ORCL> ALTER DATABASE DATAFILE ‘+ASMDSK2/orcl/datafile/users.256.565313879′ OFFLINE;
4)Now Copy the file from Source diskgroup ASMDSK1 to target Diskgroup ASMDSK2.
——————————————————————————————–
Either
4. a) DBMS_FILE_TRANSFER package or
4. b) RMAN
can be used for this step.
( The step 5 to step 8 is based on the filenames from method b).
4.a).Using DBMS_FILE_TRANSFER package
SQL:ORCL>create or replace directory orcl1 as ‘+asmdsk1/orcl/datafile’;
SQL:ASM> Alter disgroup asmdsk2 add directory ‘+asmdsk2/test’;
SQL:ORCL> create or replace directory orcl2 as ‘+asmdsk2/test’;
SQL:ORCL>
BEGIN
DBMS_FILE_TRANSFER.COPY_FILE(
source_directory_object => ‘ORCL1′,
source_file_name => ‘users.259.565359071′,
destination_directory_object => ‘ORCL2′,
destination_file_name => ‘USERS01.DBF’);
END; Database altered.
4 b).Using RMAN copy the file to new diskgroup.
$ rman target system@orcl10
target database Password:
connected to target database: ORCL (DBID=1089529226)
RMAN>
RMAN> COPY DATAFILE ‘+ASMDSK2/orcl/datafile/users.256.565313879′ TO ‘+ASMDSK1′;
Starting backup at 03-AUG-05
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=146 devtype=DISK
channel ORA_DISK_1: starting datafile copy
input datafile fno=00004 name=+ASMDSK2/orcl/datafile/users.256.565313879
output filename=+ASMDSK1/orcl/datafile/users.259.565359071 tag=TAG20050803T12110
9 recid=2 stamp=565359071
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
Finished backup at 03-AUG-05
5) Rename the file to point to new location.
——————————————-
If you have used DBMS_FILE_TRANSFER (method 4 a)) use the following command to rename:
SQL:ORCL> ALTER DATABASE RENAME FILE ‘+ASMDSK2/orcl/datafile/users.256.565313879′ TO
‘+ASMDSK1/orcl/datafile/users.259.565359071′
Database altered.
If you have used RMAN (method 4 b) use the following option of RMAN
RMAN run {
set newname for datafile ‘+ASMDSK2/orcl/datafile/users.256.565313879′
to ‘+ASMDSK1/orcl/datafile/users.259.565359071′ ;
switch datafile all;
}
6) Recover the file.
——————-
SQL:ORCL> RECOVER DATAFILE ‘+ASMDSK1/orcl/datafile/users.259.565359071′
Media recovery complete.
7) Bring the file online.
———————–
SQL:ORCL>ALTER DATABASE DATAFILE ‘+ASMDSK1/orcl/datafile/users.259.565359071′ ONLINE
Database altered.
Verify the new file location.
———————————
SQL:ORCL> SELECT FILE_NAME FROM DBA_DATA_FILES;
FILE_NAME
——————————————————————————-
+ASMDSK1/orcl/datafile/users.259.565359071
+ASMDSK1/orcl/sysaux01.dbf
+ASMDSK1/orcl/undotbs01.dbf
+ASMDSK1/orcl/system01.dbf
9) Delete the file from its original location
SQL:ASM> ALTER DISKGROUP ASMDSK2 DROP FILE users.256.565313879;
Note: 1) The steps provided here assume that the database is open and in Archivelog mode.
2) The steps outlined here are not for system or sysaux datafiles. For System and Sysaux an approach similar to the one given below can be used.
1) Create a Copy of datafile in target Diskgroup:
RMAN> backup as copy tablespace system format ‘
RMAN> backup as copy tablespace sysaux format ‘
2) Then shutdown the database and restart to a mounted state
RMAN> shutdown immediate;
RMAN> startup mount;
3) switch the datafiles to the copy
RMAN> switch tablespace system to copy;
RMAN> switch tablespace sysaux to copy;
4) Recover the changes made to these tablespaces;
RMAN> recover database;
Hi All,
There are many reasons for the failing for root.sh when you are installing Oracle 10gR2 CRS. I have observed some of them and listed below.
CAse 1 :
Root.sh fails when run on the last node of the RAC on any platform saying that
The given interface(s), “eth0″ is not public. Public interfaces should be used to configure virtual IPs.
This issue is specific to Oracle 10.2.0.1 only (noted in BUG 4437727) and needs to be resolved before continuing. The easiest workaround is to re-run vipca (GUI) manually as root from the last node in which the error occurred. Please keep in mind that vipca is a GUI and will need to set your DISPLAY variable accordingly to your X server:
# $ORACLE_HOME/bin/vipca
Go back to the OUI and acknowledge the “Execute Configuration scripts” dialog window.
CASE 2:
In case of Solaris when the RAW device is used for configuring OCR and when cylinder 0 or first 1 MB of the partition is not skipped ( Refer my previous article for more details)
In that case root.sh fails on the first node itself and gives the following error
Failed To Upgrade Oracle Cluster Registry Configuration
In that case cleanup the failed CRS installation, Recreate the partition for OCR and Voting Disk by skipping the first few cylinders using format command and reinstall CRS
CASE 3:
When Different partition names are used to identify the OCR/Voting partitions RAW partitions from different Nodes for e.g
From Node 1 location of OCR is identified as
/dev/rdsk/c3t40d0s0
From Node 2 same location of OCR is identified as
/dev/rdsk/c3t44d0s0
In the above case use symbolic links so that OCR location is identified using same name from both the location
CASE 4:
If your hostname of the nodes contains a mixture of small case letters and Capital alphabets for e.g WiMAXDB, WiMAXDB
Using such hostnames may not be supported by Oracle 10g CRS.you can identify such case by going into $ORA_CRS_HOME/log and if there are 2 directory created with different names like in my case it was the following directories were found in $ORA_CRS_HOME/log directory
WiMAXDB1 and wimaxdb1
In that case cleanup the failed CRS installation,change the hostname and then reinstall CRS.
CASE 5:
Finally the root.sh script can also fail due to improper permissions to CRS home in UNIX systems. during CRS installation the CRS home should be owned by oracle user and when you run root.sh script you will see several warnings as shown
WARNING: ‘/oracle’ not owned by root
WARNING:’/oracle/clusterware’ not owned by root
WARNING:’/oracle/clusterware/crs’ not owned by root
WARNING:’/oracle/clusterware/crs/oracle’ not owned by root
WARNING:’/oracle/clusterware/crs/oracle/10.2.0′ not owned by root
However only when the CRS is completely and sucessfully installed you can change the ownership to the root user of CRS home
chown -R root:oinstall /oracle/clusterware/crs/oracle/product/10.2.0
chmod -R 775 /oracle/clusterware/crs/oracle/product/10.2.0