- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- Disk Enclosures
- >
- How does Hitachi (HDS) shadowing work?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-08-2003 07:34 AM
тАО10-08-2003 07:34 AM
How does Hitachi (HDS) shadowing work?
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.
Jerie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-08-2003 03:00 PM
тАО10-08-2003 03:00 PM
Re: How does Hitachi (HDS) shadowing work?
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.
hth,
-
Stan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-08-2003 07:32 PM
тАО10-08-2003 07:32 PM
Re: How does Hitachi (HDS) shadowing work?
XP's are HP's renamed HDS.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-09-2003 12:53 AM
тАО10-09-2003 12:53 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-09-2003 01:55 AM
тАО10-09-2003 01:55 AM
Re: How does Hitachi (HDS) shadowing work?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-09-2003 01:37 PM
тАО10-09-2003 01:37 PM
Re: How does Hitachi (HDS) shadowing work?
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 ^^