I have a customer that has done this successfully with SVC (IBM product) replication. The trick I believe is to have the DB and logs in a "consistency group", which means that SRDF must enforce the correct order of writes.
Here is the TSm doc on what is required: http://www-1.ibm.com/support/docview.wss?rs=663&context=SSGSG7&q1=tsm+data+base+replication&uid=swg21205074&loc=en_US&cs=utf-8&lang=en (Or just go to www.ibm.com and search *1205074).* ** *W* On 6/19/08, Shawn Drew <[EMAIL PROTECTED]> wrote: > > The recent talk about srdf and dr reminded me of our situation > > Layout: > - 2 Datacenters with a routed SAN (90 miles a part) > - TSM DB is on DMX that is setup with SRDF in sync mode to the remote > site. > - The DMX luns are assigned to the AIX host, and formated with JFS2. > - The log volume does share one of the luns with part of the DB. (I'm not > sure if this is a big deal or not) > - VTL's and library managers at both sites. Primary pools at one site, > copypools at the other. > > I tested an srdf split, while TSM was running, and attempted to bring TSM > up at the remote site. It was not successfull, and a DB restore would > have been required. > We re-established and split again with TSM down. This time it worked > fine. > > When this was originally implemented, the project owners claimed that SRDF > was a supported solution. After this test, I called IBM to verify it, and > support said the only form of DR that is supported is a database restore. > > Questions: > > Is there any trick to get this working right? > Do I have to have the log on a separate lun? maybe different srdf group? > Should I be running this in Async mode? > > I think the 90 mile separation prevents me from using TSM to mirror the > volumes. This would introduce a big performance hit, right ? > > Regards, > Shawn > > > This message and any attachments (the "message") is intended solely for > the addressees and is confidential. If you receive this message in error, > please delete it and immediately notify the sender. Any use not in accord > with its purpose, any dissemination or disclosure, either whole or partial, > is prohibited except formal approval. The internet can not guarantee the > integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) > not therefore be liable for the message if modified. Please note that > certain > functions and services for BNP Paribas may be performed by BNP Paribas RCC, > Inc. >
