Mark Yudkin wrote:
Not quite. EMC does a disk-by-disk propogation (I'm being a bit sloppy with
the word disk here, I mean the logical "storage volume"), whereas Hitachi
uses a global timestamp over the entire SAN (I'm not sure how IBM's Flash
Copy works). The result is that if data is split over multiple EMC disks,
there is no guarantee of consistency between the two disks, which can
prevent your simply starting your database from the replicated disks an
impossibility (logical inconsistent state).
From a DBA perspective, I think the general process is the same:
1) Sync disks (this varies from vendor to vendor)
2) Freeze database
3) Split mirror (varies...)
4) "Unfreeze" database
5) Use mirror(s) on another server.
How the underlying hardware handles the mirrors, and the commands that are
used to manage the mirrors is not really a DBA issue, although that's my
myopic perspective. :-) Maybe it is if you're dealing with a small NAS
device, but with multi-million dollar enterprise storage devices, it's been
my experience that customers typically have someone who knows the device
inside and out.
This issue with Symmetrix is interesting, though. I wasn't aware of this
(and obviously haven't run into it, either). I thought that, once the BCVs
have been synchronized, they remained in sync until they were split from
their primary volumes. The whole point of the 'suspend write' command in
the database is to prevent any I/O (and the applies across all partitions)
while the mirrors are split. Once the split has completed, then I/O may
be resumed ('resume write').
I agree that it would not make any sense to try and split mirrors while
the database is still actively performing I/O.
Do you know of any white papers that explain this issue in depth?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
