What data sets to replicate in VVR for DB2 database

[pandeysid]

Hi,

Current Environment -

I have a customer who has DB2 database deployed on Intel based HP servers.  The Production & DR locations are WAN apart in two different cities.  there are 5 applications which have their individual databases on DB2.  VCS is configured for local failover & VVR is configured for a Geographical replication.  SF HA/DR with the Global Cluster option is being used for across the site failover.  The storage for all the databases is on external storage through an FC based SAN.

The database sizes (physical data file) ranges from 500 MB to 100 GB.  THe changes for the smallest databse of 500 MB are maximum. 

Issue -

We are experiencing a lot of bandwidth consumption for all the databases causing the maxing out of the 6 Mbps bandwidth between the production & DR locations. 

Question -

What are the data sets that need to be really replicated for DB2.  My gut feel is that its only the production data file & maximum the online transaction logs of DB2 that need to be replicated across to DR location.  Currently we were replicating all volumes for the DB2 data viz. data files, archive logs, mirror logs, mirror copy of the database & online logs.

Can someone guide me to the best practice of what should be replicated from DC to DR in case of a DB2 database (or for that matter any database).

The RPO expected by the customer is maximum 15 minutes.

Regards,
Sid

[mikebounds · Accepted solution]

I have dealt with VVR on Oracle, Informix on UNIX and Sequel in Windows, so DB2 should have the same concepts:

There is no need to replicate mirror copies of data and logs (I have excluded these in Oracle)

If you don't mirror archive logs (in Oracle) then this works, but a DBA came up with some corner cases that you wouldn't be able to recover from, which I can't remember details, but I think it was some double disastor scenaio.

You need to replicate data and logs, but you should exclude temporary tables spaces - I have found this can make a huge differences, for one customer writes to temp were 50% and for another 75%.  This is because temp is used for things like sorting and can generate hugh amounts of data which is of no use at DR as temp is cleared down when database starts.  To exclude temp database spaces means they need to be on separate volumes and then you just exclude them from the RVG.  Note different databases react different to no temp on DR site, from memory:

• Sequel creates file, so no issue
• Oracle requires file to be there but it can be of zero size (so just need to touch a file)
• Informix requires file to be there in Informix datafile format, but doesn't need to be current, so only needs to be created as a one off task and then it can be reused.

So you will need to test what you need to do with DB2.  If you are not sure how much is written to temp spaces and so if it is worth excluding it, you can use vxstat if temp spaces are on dedicated volumes.

Mike

[pandeysid]

Thanks a ton Mike.  This was useful information.

Earlier we were replicating all data from production to DR; that included the DB2 mirror logs, Archive logs, events, even on disk data dumps to the DR site.

Now the plan is to replicate only the data file & the DB2 online logs.  I'll definetely check on the temp tablespaces, whether they are eliminated or not.  Personally I think that even the online logs needn't be replicated since the database copy at the DR is going to be consistent anyways.

Regards,

Sid