Migrating Oracle datafiles from SC10 to EVA3000

[Ricky_4]

Hi All,

We are planning to purchase EVA3000 as our new external storage. Currently, we are using SC10 and all the Oracle database files are stored on this. Please suggest or recommend if the activity mentioned below can successfully accomplish migration of Oracle datafile from SC10 to EVA3000. This activity assumed EVA3000 is already in placed.

1. Shutdown Oracle database.
2. Backup all the Oracle datafiles in the SC10.
3. Unmount all filesystems from SC10.
4. Create filesystems in EVA3000 similar how we defined filesystems in SC10.
5. Restore Oracle datafile backup.
6. Test Oracle database if successfully migrated.

For additional information, Oracle database and HPUX are 8.1.7 and 11.00, respectively. Your replies would be highly appreciated.

Regards,

Adriatico

[Indira Aramandla · Accepted solution]

Hi Adriatico,

The steps that you have are correct.

Before you shutdown the database for backup,
execute these queries to have a listsing of the existing files and logs.

select tablespace_name, file_name from dba_data_files;---This will give the listing of all the tablespace_name and the datafile names with the physical location on the disk.

select member from v$logfile; ----- This will give the redo logs location listing

select name from v$controlfile;---- This will give the control file listsing.

Then shutdown the database.
Take a full cold backup.
create the filesystem in EVA3000 with the same names for the path, as defined in SC10.
restore the datafiles, control files and the re-do logs.
then start up the database and verify the following.
select * from v$recover_file;
select * from v$recovery_log;

The above 2 queries ahould return 0 rows and that makes sure that there are no datafile or logs which require media recovery.

And I assume that the oracle software and other profiles are unaltered. So your ORACLE_HOME, ORACLE_BASE, ORACLE_SID, oratab entries all remains unaltered. Its only the datafiles, re-dologs and the control files are being moved to EVA3000.

Wish you good luck.
Indira A

[Hein van den Heuvel]

This is a fine plan. Do take Indira's advice and tell Oracle to report all DB file names it knows. For Oracle 9i I use a script similar to the attached and appended one.

I would also use 'alter database backup controlfile to trace' (check syntax!) to have yet an other fall back plan.

May we assume you want to minimize down-time?
In that case I suggest you skip the backup.
The old DB on the SC10 is your backup!
Unmount the SC10 db mount points. Eg /redo /data
Mount the EVA files systems on those mount-points.
Mount the SC10 files systems on fresh 'nicknamed' mountpoints. eg /redo_old /data_old
cpio to move copy the data over in multiple parralel streams.
(myself, I use a perl script with a selectable stream count that picks db files from large to smaller untill done).
Startup new DB!

Optionally... backup old DB now.
Optionally... activate old DB under new working name using 'create controlfile' with data saved to trace/alert.

Btw... I would probably design do this twice... (because you will anyway :-). The first time I'd just create a play version by restoring an older sc10 based backup. Do the restore at your leisure from an old backup. Try it out for a few minutes after some scheduled downtime (backup). That way you'll be much more confident for the real job.

hth,
Hein.


column status format a9
column file format a40
column id format 999
column type format a10

set lines 80
set pages 9999
set heading off
set FEEDBACK off
select 'Redo' "type", l.group# "Id", l.status, l.bytes/(1024*1024) "MB",
MEMBER "File" from v$logfile f, v$log l where l.group# = f.group#
union
select tablespace_name "type", FILE_ID "Id", status, bytes/(1024*1024) "MB",
file_name "File" from dba_data_files
union
select 'Temp' "type", FILE# "Id", status, bytes/(1024*1024) "MB",
name "File" from v$tempfile
union
select 'Control' "type", rownum "Id", status, 0 "MB",
name "File" from v$controlfile
order by 1,2
/

[Yogeeraj_1]

hi Adriatico,

if you can connect both your SC10 and the new EVA3000 at the same time, you may also:

a. backup your exisiting database using RMAN preferrably.
b. backup your control file to trace
c. Move your datafiles to the EVA3000 file system.
d. Modify your control file accordingly so that it uses the datafiles from the EVA3000. (make sure your temporary tablespaces, rbs are OK)
e. start your database using the new control file.

(Nb. this is a just a brief outline. you may wish to test it first. The will definitely take lesser time)

hope this helps too!

regards
Yogeeraj

[Jerry Zhang]

If downtime is an important issue, then you may considering these:

First idea (online data migration):
Create LUNs from EVA and add them into the Oracle volume group(s). Use LVM mirroring function to mirror LVs from SC10 disks (LUNs) to EVA LUNs. After that, you can reduce SC10 LUNs from VGs.

Second idea:
Create LUNs from EVA and add into different VGs on the system. Shutdown Oracle engine, and do online copy, such dd and find with cpio, etc.

[Richard Hood]

I am all about short cuts - so beware...

1: create new LV for the EVA (do not mount them)
2: Down Oracle
3: unmount existing oracle logical volumes
4: create temporary mount points for old database lv
5: modify /etc/fstab to:
mount SC10 files to temp mount pts
mount EVA to the original mount pts
6: mount SC10 and EVA lv's
7: perform cpio -p on the SC10 to EVA's
8: bring up Oracle
9: once all is well unmount SC10 lv's

This way you do not have to worry about control files - new partition names and such.
Also, once you change your partition names - you will need to cahnge all of your supporting documentation -- this way the docs are still accurate.