We have traditionally used tape restores at Sungard for executing a disaster/recovery test. Our corporate TCC wants to switch to using SMRC disk copying to a new second data center. SMRC will synchronously write to the production and secondary disk packs, so any write done here will be done there as well.
The plan is that the mirror will be broken and then we will just start up the mainframe at the secondary data center and everything will be working. However, I have concerns about the state of Adabas. Knowing we use the asynchronous buffer flush capabilities of Adabas (so the process of doing physical I/O is not a serial process performed by the nucleus for performance reasons), I think we could not only lose committed transactions but also be in an inconsistent state. I want to fall back to using tape restores to be sure that Adabas has consistency and integrity. We use Adabas Delta Save and have exercised a D/R plan with this strategy successfully multiple times.
I recently posted this question to SAG-L, but since Software AG people are permitted to respond here, I was wondering if someone could let me know if my concerns are reasonable or if, as some had responded on SAG-L, I am overly concerned and Adabas can’t get messed up by this. Some people said that Adabas is able to recover from this state and restore integrity. Someone else said that Adabas can detect changed blocks it lost marked for flushing or flushed from the buffer pool but not yet written to disk, and that in worst case, Adabas won’t stay up but will let me know its inconsistent state (telling me when I have to restore from tape).
Please advise on the best practices of utilizing SRDF for recovering Adabas in a D/R scenario.