Operating System - HP-UX
1825007 Members
3004 Online
109678 Solutions
New Discussion юеВ

Using Business Copy to copy databases

 
Jason Narenkivicius
Occasional Contributor

Using Business Copy to copy databases

Greetings all,
We are currently looking at moving away from a Direct attached storage model to a san with a VA7410 as the disk array.
We have 4 UNIX boxes that will be included ( 1-N4000, 1-L2000, 1-K460, 1- K360)
One of the "many" driving factors for this move is in our current operation we dump a 80 gig sybase database nightly from
our production server and load it to our report server (so the Data analyst are not attached to the production server.)
We use omniback to preform this task and it takes up to 10 hours to dump and load the database to tape media.
Is anyone using business copy do this type of copy of databases?
I have heard that with business copy this type of action can be done in minutes.

any help would be greatly appreciated

Thanks
Jason

10 REPLIES 10
Uday_S_Ankolekar
Honored Contributor

Re: Using Business Copy to copy databases

Few info here on typical usage of business copy.

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065011836

-USA..
Good Luck..
Uday_S_Ankolekar
Honored Contributor

Re: Using Business Copy to copy databases

John Poff
Honored Contributor

Re: Using Business Copy to copy databases

Hi Jason,

We are doing what you describe with an EMC array using BCVs. We have played with an XP array and Business Copy before, and it will do the same thing. You'll probably go from 10 hours for a database reload to a matter of minutes.

JP
Jason Narenkivicius
Occasional Contributor

Re: Using Business Copy to copy databases

John,
Did you guys need to create scripts to change the database names?
Martin Johnson
Honored Contributor

Re: Using Business Copy to copy databases

Just a note of caution: Make sure your database is in a quiessed state to insure the integrity of your data. Your backup will be corrupted if part of your data is in buffers in memory.

HTH
Marty
John Poff
Honored Contributor

Re: Using Business Copy to copy databases

Jason,

Our DBAs wrote scripts to handle changing the database name on the copy. I'm not a DBA but I think they pretty much have it down to a science. We keep a copy updated every two weeks for test and development.

If you like I can ask one of our DBAs about the script/process they use for changing the name and bringing up the copy database.

JP
Jason Narenkivicius
Occasional Contributor

Re: Using Business Copy to copy databases

John,
That would be great if you can ask them how they rename the database and get it ready for people to access

thanks
Jason
Rajeev  Shukla
Honored Contributor

Re: Using Business Copy to copy databases

Hi Jason,
I have worked with EMC storage taking backup of Oracle database using Business copy. Its very fast if you do incremental backup but always take care that you dont copy from business copy to original.
The process is you write scripts to put the database in backup mode, merge the BCV(incremental) after they are synced 100% you split them and bring database out of backup mode. You'r backup is now in BCV which you can mount as a different volume group. And depending on the database (Oracle/Informix/Sybase) you change the configuration files to bring it up as a different DBNAME. You then start supplying the logs to bringup the database.

Rajeev
Brian M Rawlings
Honored Contributor

Re: Using Business Copy to copy databases

Jason: from your description, it may not be necessary to change the DB/instance names, etc. If you are mounting the copy up on another server, wouldn't that be enough uniqueness to allow the DB to be brought up and accessed?

Typically, that is how business copy is used: make BCV copy as described above (quiesce the DB; sync BCV volumes; split BCV; return DB to normal state), giving you a perfect copy of the DB at a point in time. Then you can:

- Mount the copy to a backup server and back it up with no impact to production, or

- Mount the copy to a test/dev box and test new patches/programs/etc against "live" data, or other development work, or

- Mount the copy to a report server, start the DB, and run extracts and reports from it without impacting production, or

- Not mount the copy anywhere, and just save it as a point in time copy you can revert to if the production copy gets corrupted (this is often done in conjunction with the backup -- get it copied to tape, but those are for archival purposes... the fast recovery would come from the BCV copy).

Other scenarios are, of course, possible, but I think you can see what I mean. After the copy, this is just a volume you can mount up on a different server, which provides different paths, different names, different IP access, and sufficient differences that you don't always have to change the Instance name to bring up the DB.

Your mileage will vary, of course, this is very case specific and dependent... but talk to your DBAs about it. In reality, it is not much different than what they're doing now, but it eliminates the "tape transfer" step. When you read in the backup tape on the Report server (or whatever), what do they have to change to bring up the DB? It should be the same after mounting up the BCV copy to a different server.

Hope this helps...

--bmr
We must indeed all hang together, or, most assuredly, we shall all hang separately. (Benjamin Franklin)
John Poff
Honored Contributor

Re: Using Business Copy to copy databases

Jason,

I talked to our local wizard DBA. Here is what he replied with:

"If he is not adding datafiles as often as we do then he could have the file in place to do the rename.

If files are changing constantly then before split issue command alter database backup controlfile to trace; ( do this from server manager)
some type of awk script to do global change on database name within the file .
Once the mounts are up start server manager and execute the file with substitutions.

There is a little more to it than this, but that's the general idea."

I hope that makes some sense and helps you a little bit.

JP