IDMS

Re:Second Data Center for Disaster Recovery

  • 1.  Re:Second Data Center for Disaster Recovery

    Posted Nov 05, 2009 11:06 AM
    Dear Listers :



    We will be opening a new Disaster Recovery Center in less than a year.

    We will be replicating all data to this center from our primary operations using an IBM product called

    ""Global Mirror"".



    All data is replicated at the DASD block level in real time for all volumes.



    The primary and secondary sites are not expected to be more than a minute or

    two out-of-sync during the heaviest of processing.



    All our archive journals are written to disk and then migrated off to tape

    after several days.



    Also, every day, we do a FLASHCOPY of the entire mainframe complex and do

    nightly tape backups of the Flashed volumes.

    This also captures all database, disk journals, and journal archives.



    With all databases, journals, and even journal archives on disk...

    and

    In a true disaster, it seems that recovery is as simple as starting an instance of IDMS at the DR site and

    let it go through WARMSTART.



    Am I correct about this, or is it more complicated than that?

    And if more complicated, I'll have the archives replicated if I have to do more.



    Thanks.

    Jon Gocher
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Second Data Center for Disaster Recovery
    "Hmmmm. I would wonder about what happens if the replication of data volumes (relatively low update level) is allowed to proceed ahead of the replication of journal volumes (relatively high level of updates).

    Without knowing the technical details of the solution you're using, I'm assuming it shoves things down the pipe as fast as it can, and applies it on the far end as fast as it can. All this without attempting to keep things in exact timestamp order across different datasets or volumes. I would assume it makes this tradeoff in order to avoid impacting write throughput on the ""live"" side.

    IF this can happen, then you might have warmstart/integrity issues. Chances are probably low, but not zero. The short answer is if the jrnl replication runs behind the database replication, you WILL have images on the database files for which you lack sufficient jrnl data to remove (incomplete or aborted run-units).

    Don Casey
    Principal Consultant
    Run Right, LLC