Need recommendation to transfer 600gb of oracle data to new server

[S. Ney]

Hello,

We have an existing rx6600 server that is running 11.31os, oracle 11G with a LVM filesystem. It has RMAN enabled which backs up oracle data to a /backup filesystem. The data is approx 600Gb in size although the /backup filesystem is sized at 900Gb.

We are currently working on bringing up a second rx6600 server across the country which will also run 11.31 os however oracle version will be oracle 11G ASM, running the same application on the same type of storage.

What would be the most efficient way to get the 600Gb of data to the remote server in order to populate the database? We do not have san storage copy utilities available however we do have veritas netbackups so we could request a specific tape backup and then mail it out there however by the arrival time the data may be out of date. Would NFS be a better option? However would the database have to be offline while /backup was remote mounted so data could be transferred? Or would one of the oracle methods to transfer data be a better choice? I need to be able to provide input from the System Admin side to the dba team about available options.

[Yaroslaw]

If Logical Volume with /backup on separated VG you can export VG and send HDD across country with courier, and send email with attached map-file.

[S. Ney]

/backup is in a database volume group. It's spread across 9x100Gb luns although the dba's have informed me that there is actually about 600Gb worth of data that will need to be populated in the new database.

/dev/vgora/orabackup
1048412160 111600064 929493320 11% /backup

[Bill Hassell]

> ... veritas netbackups so we could request a specific tape backup and then mail it out there however by the arrival time the data may be out of date. Would NFS be a better option?

Unless you have an enormous amount of money to purchase an fibre link to your remote site, NFS would be the worst choice -- on a T1 link, the transfer would take about 170 hours (that is about 7 days). Your data center probably uses 100Mbit or even 1000Mbit LAN connections so 600GB seems like something that doesn't take too long to transfer. An OC12 fibre line transfers data at 600Mbits/sec but that will still take more than 24 hours to transfer. Oh, the monthly cost would be from $100,000 with a similar cost for the initial setup.

30 years ago, I postulated that the fastest and cheapest data transfer system was some tapes in a FedEx envelope. That has not changed today. An overnight box from California to New York can cost about $60 and hold several dozen terabytes of data, significantly less costly than any possible network solution, given your (assumed) short timeframe for the copy.

Yes, your data will be out of date, but you probably can't afford the costs needed to transfer the data in a few hours. So you send the full backup overnight, install it on the remote system, then send incremental backups (changes only) by courier until such time as the change rate can be handled by your existing network connections and the two sites are synced.

NOTE: your local data may be changing far too fast for your WAN to handle. The DBAs must provide a daily data volume report (average and worst case) so management can decide if a realtime sync between the two sites is feasible (or affordable).

[Kapil Jha]

Nothing can match the bandwidth of a truck filled with tape moving from one location to other.
I read it smwhere :)
so the only solution you have is to send full backup on tape and then sync the incremental backup with rsync.
Just to make things lil easier, check what time data base is haveing least transations and plan the full backup and incremental accordingly.

BR,
Kapil+

[Elmar P. Kolkman]

You might want to look at oracle dataguard...
You can then do use a backup of the database as the original filling of the database (the first 600 Gb, which should fit on some tapes) and then dataguards archivelog shipping can help keeping the databases in sync.

I've only limited oracle DBA experience, but it seems you have some DBA's available. Perhaps some discussion with them about this might help.

Off topic: the fastest way to transport LARGE AMOUNTS of data might be by truck, but the definition of LARGE AMOUNTS rises constantly with the changes in bandwidth and tapecapacity.

[Dennis Handly]

>Bill: I postulated that the fastest and cheapest data transfer system was some tapes in a FedEx envelope. That has not changed today.

Well, now days it might be mandatory that you encrypt the data.

[S. Ney]

So tape backup looks to be the best option so far. However the current database has a cooked lvm filesystem with a dedicated /backup filesystem. The new server will be oracle ASM, no filesystems, just ASM disks for the database.

I'm not a storage/backup or oracle admin so I'm not sure how the data would be restored from tape. /backup on the current system is where RMAN data is stored on disk before being backed up by tape. Is this a case where I request temporary luns and build a 600Gb filesystem until the DBA's can convert the data in asm disk space?

PS points will be assigned, just need options of how to convert the data once its on tape. thanks all for the discussion so far.

[Bill Hassell]

The DBAs will define how to convert the database from files to raw disks. Essentially, the database must be dumped in a special format and then db-loaded at the destination. This produces significantly more data is most cases and loading the new database will take quite a while (compared to a simple filesystem restore of an existing database).

[johnsonpk]

As Elmar said , Dataguard would be an intelligent solution you can think about ,

You could also plan like below,

On primary site :
1) create a full back up of db on tape and send it second site
2) schedule a ftp/scp/sftp script to copy the archive logs as and when it gets created (those are generated after the full backup)

on secondary site:

1) restore the full back up,
2) schedule a script to apply archive logs that arrives at second site through ftp/sftp/scp from primary site.