This post is more than 5 years old
207 Posts
0
1279
SRDF/A for z/os DB2
Hello,
We have been relplicating various flat files and OS volumes with srdf/a. At some point we will start replicating DB2. I don't know a lot about DB2 but I know it has an active log and the actual database.
With other DBMSs we have replicated just the log and all transactions get applied to the remote side by the dbms. Will this work with DB2 or do I need to replicate both the active log and the data. If we only need to replicate the active log this would be helpful as it would cut down the amount of changed tracks going between California and Texas.
PedalHarder
465 Posts
0
July 19th, 2010 16:00
Hi,
Like all databases, to provide a recoverable and restartable consistent copy of the of the database, both the database and logs need to be replicated.
Would you mind expanding on the configuration you have wiih the databases that you just replicate the logs. Have you tested this in a DR test? I'm happy to learn from your setup, but this is what typically occurs in a database sense in a DR/DR test from RDF replicated data...
- The database and logs are replicated in the same SRDF/A session in the same array OR if multiple SRDF/A sessions, the sessions are managed by MSC.
- SRDF/A is dropped to get a consistent copy on the R2 devides (or a cosnsistent local copy is made of the R2 devices)
- The database at the the remote end is likely to have had in-flight transactions at the point the repllica was made. The database logs have the details required on this, so when the database starts, the in-flight transactions resolved using the database data and the log data. What is required for this to happen is that the database data and the log data must be from the same consistent point in time.
Notach
21 Posts
0
July 20th, 2010 07:00
Hi,
you can find a EMC paper for DB2 on Z/OS on EMC array. http://www.emc.com/collateral/hardware/solution-overview/h2505-db2-udb-zos-symmetrix-wp-ldv.pdf
For a DR Test, i think yo have no problem sith SRDF/A replication for DB2.
So maybe you are in sysplexmode anbd have CF (Coupling Facility). Think about db2 castout. When you have a transaction, all change are in DB2 log on dasd and replication gives you data on remote site. For DB2 all is right, but you can have some data only in CF.
For a test u can plan a quiesce for all databases to force data on dasd, but in real disaster mode you can loose some data in CF. On disaster site your DB2 susbsystem will retstart , but some application can have problem because data was not on dasd ( in CF only). So you have log to make recover.
I'm not a DB2 specialist, but we have made many disaster mode with Autoswap and when we made a 2+1 solution (2 local site in SRDF/S; + 1 in SRDF/AD), the question of DB2 castout will occurs.
Hope it's help you .
brad12341
207 Posts
0
July 20th, 2010 08:00
Good info. We have many different technologies besides IBM zos. We have a Unisys host that uses a dbms called dmsII. The administrator gave me the 4 sym volumes that make up the DMSII logs. I set up srdf/a between CA and TX. When data was added to the logs in CA it was replicated to TX. In Texas the dbms would automatically apply the log changes to the DB. We verified that all data added in CA was also present in TX. This was a test only and we are not running in production yet.
I know MVS/DB2 is a different animal and it sounds like I need to replicate the active logs and the data. The data has a huge change rate with lots of activity on the online log files. The archive volumes in the archive logs can also be very busy at times. I'm hoping that I do not need to replicate these archive logs because of bandwidth limitations.
Without the archive logs I'm hoping we would still have a good "restartable" DB2 data base in Texas after a disaster. The database and the active log would be in Texas but it would be up to 1 minute old (we are using 30 second cycles in SRDF/A). During a disaster, I'm guessing we would go to our ECC box in Texas and do a "symrdf -g mvsgrp failover". When DB2II starts/restarts in Texas it will use the active log to backout/roll forward in flight transactions. I realize we will lose the 1 minute of data and will not have the archive logs in Texas. Does this sound like a good way to get a restartable DB2 database?
Notach
21 Posts
0
July 20th, 2010 23:00
Hi again
For archive log, it's depends about db2 activity and size of actives logs. If your active log are too small , you can have some problem for recovery. We size log to 20 mn db2 activty. I don't know if you have multi databases with integrity dependancy. Ask your DB2 administrator to know it.
Our archive logs were on dasd too and migrate by HSM next day after creation date; so in major case we have active and archive log on disaster site.
The 1mn lost may be nothing for DB2 restart, but it will be more important, depend of DB2 activity when disaster occurs. You can test it in DR exercice of you can plan it. So in majors cases DB will restart in good condition.