Disk Arrays
Showing results for 
Search instead for 
Did you mean: 

How does Hitachi (HDS) shadowing work?

Jerie Dahlman_1
Occasional Contributor

How does Hitachi (HDS) shadowing work?

We are thinking about using HDS shadowing to create a copy of a database for users to access for reporting. Can someone explain how this works?

Does the copy database have a new db_name when it's opened?

Or maybe HDS shadow databases can not be used in this manner.

Thanks for your input.
Valued Contributor

Re: How does Hitachi (HDS) shadowing work?

Hi Jerie,

I'm not sure of the term "shadowing" you refer here, but i presume you meant hard disk mirroring. i'll not explain the nitty gritties of how disk mirroring works (google it, if want to) but to be simple the controller writes data to all disks in a mirror set. so even if one disk fails you get the data from mirror'd disk.

That aside, if you plan to make a copy of the database using disk mirroring then, foremost, you should have mirror'd all files (datafiles, archivelogs, redologs etc) first and then split mirror, mount these disks on to another machine and do a in-complete recovery. This should work, however dbname would be same but thats minor thing to change. To answer your question, yes duplicate copies of database can be made from disk mirroring.

But, if i were you, i would look into transportable tablespaces. They are pretty simple. All you got to do is, create an empty reporting database, then export/import necessary tablespace metadata from production to reporting database along with their datafiles and make them readonly.

Depending on your requirement, you have other options like restoring the db from recent hotbackup and make it as reporting db.

Michael Steele_2
Honored Contributor

Re: How does Hitachi (HDS) shadowing work?

Refer to BCV's or Business Copy Volumes on a XP disk array.

XP's are HP's renamed HDS.
Support Fatherhood - Stop Family Law
Honored Contributor

Re: How does Hitachi (HDS) shadowing work?

ShadowCopy is basically similar to all the other products out there ... EMC BCV, StorageWorks BusinessCopy, etc.. If cost of ShadowCopy or any StorageManagement Tool is of a concern to you, then perhaps you can use this approach, instead of ShadowCopy:
Have a set of LUNs from your HDS be configured such that these LUN's are multi-pathed - meaning LUN's appearing on your production server also appears on your reporting/test server. I suppose you have an FC connected HDS box or a SAN (SAN does not matter really in this case). Then use your server's Volume manager (LVM or VxVM) to mirror your DB instance filesystems onto these "multi-pathed or floater LUNS" -- depending on the number of FC paths, come into up with a number of concurrent mirroring processes that won't affect performance much (Veritas host based mirroring is excellent with very minor impact). Once the mirrors are synched up, to break a working copy of the DB instance - you bring the database into "hotbackup mode" for all tablespaces, and "suspend" the DB. At that point, break the mirrors, resume the DB and palce the instance into normal operating mode. From hotbackup, to suspend, to breakage of mirros to resumption -- this will just be literally seconds or process time. The "floater LUNs" now broken off from the instance filesystems can then be broken off from their VG/DG into a separate VG/DG, deported, and imported on the server where they will be needed... If scripted, you can have job control do this all for you.
My studies comparing software based split-mirroring techniques(for the purpose of backups, snpshots, etc..) show more flexibilty than hardware based ones and will not necessarily impact a running server if done and planned right. If you will have to do this approach, I strongly suggest you use the Full Veritas Volume Manager with the FastResync Option.

Hakuna Matata.
Stuart Abramson_2
Honored Contributor

Re: How does Hitachi (HDS) shadowing work?

ShadowCopy is HDS' version of EMC BCVs.

I can explain BCVs. In the normal case you have a m1-m2 mirrored pair. In the BCV case you have an 3-group "pair" like this: m1-m2-bcv1.

The m1-m2 pair is called a "Standard". Your primary DB runs on the STD. You must set up N DB VGs and N (usually 1) Archive log VGs, and BCV groups. The primary DB runs on the STD disks on the primary server.

You synch the BCV1s to the STDs. It is now an exact bit-for-bit copy of the STDs.

You put your DB in backup mode (oracle), and split the DB BCVs. Then you end backup mode. Then you force the current redo log to be archived to the archive log VG and split the Archive Log BCVs.

Now you present the BCV disks to another server, called your BCV server. You vgchange the PVs, vgimport the BCV VGs, fsck the filesystems and mount the LVs.

Here is an example of the "mount sequence":

mkdir /dev/vgTSTB
mknod /dev/vgTSTB/group c 64 0x110000
vgchgid /dev/rdsk/c10t2d5
vgimport -m mapfile.TSTB -v /dev/vgTSTB /dev/dsk/c10t2d5
vgchange -a y /dev/vgTSTB
fsck -F vxfs /dev/vgTSTB/lv01
#fsck -y -F vxfs /dev/vgTSTB/lv01
mkdir /u1001
mount /dev/vgTSTB/lv01 /u1001

But don't start Oracle yet, because remember they are a bit-for-bit copy of the STDs. It's the same SID name, etc.

You must rename the DB from a sql control script that you created from the original SID. Then bring it up. EMC has commands for this. HDS may also.
Lee Tae-kyung
Regular Advisor

Re: How does Hitachi (HDS) shadowing work?

I experienced HDS shadowing Storage and SF12000*2, RAC in SK C&C in korea.
Shadowing is similar to business copy in HP storage - XP,VA storage -.
But One difference is that HDS have same volume group name, and HP storage can be different volume group name.
db_name can't be changed.
Shadow database's db_name is identical.

Good day~~

From korea ^^
I think I am a specialist in IT Korea^^. I am a programmer and SE and DBA