DB2 - L

 View Only

  • 1.  Daily DB2 Catalog Imagecopies

    Posted Mar 10, 2022 09:57 AM
    We take daily imagecopies of our DB2 Catalog objects and first run "ARCHIVE LOG MODE(QUIESCE)".
    There was a "complaint" that this caused application threads to wait.
    Is it proper to do this quiesce in order to get consistent backups for recovery purposes?
    Or can this be eliminated without risk?
    thanks
    Bill

    ------------------------------
    williamgiannelliMe
    ------------------------------


  • 2.  RE: Daily DB2 Catalog Imagecopies

    Posted Mar 10, 2022 10:51 AM
    Not anymore! Anthony Ciabattoni has just talked about this at Tridex. SHRLEVEL(CHANGE) twice a day is more than enough.

    Roy Boxwell

    SOFTWARE ENGINEERING GMBH and SEGUS Inc.
    -Product Development-

    Vagedesstrasse 19
    40479 Dusseldorf/Germany
    Tel. +49 (0)211 96149-675
    Fax +49 (0)211 96149-32
    Email: R.Boxwell@seg.de
    http://www.seg.de

    Software Engineering GmbH
    Amtsgericht Düsseldorf, HRB 37894
    Geschäftsführung: Gerhard Schubert, Ulf Heinrich

    -----Ursprüngliche Nachricht


    Original Message


  • 3.  RE: Daily DB2 Catalog Imagecopies

    Posted Mar 10, 2022 09:39 PM
    You are not getting consistent backups. If you wanted that, you would start all the
    tablespaces ACCESS(RO) before doing the imagecopies That would really create problems.

    What you are looking for is the means of being able to do a consistent recovery - all
    committed work applied, no uncommitted work applied. And, provided Db2 has enough logs
    from before the time you made your imagecopy , Db2 will do that.

    What is "enough logs"? Enough to ensure that Db2 will have all the information required to
    apply committed, but unwritten (to the VSAM clusters - and hence the image copy), updates
    and to remove any updates that were written, but were not committed. This means, at least,
    back to the checkpoint before the start of the oldest Unit of Work that had updated the
    catalog/directory and was still active active at the time of the the imagecopies. If there are
    committed, but unwritten, updates, Db2 will need to go further back.

    The reason of your archive log is to reduce the number of logs Db2 needs to go back.
    Because the earliest log that Db2 needs to go back to is the log newly started after the
    archive.

    You need to decide on the tradeoff between
    - reducing the number of logs that need to be processed in the event of a recovery of the
    catalog/directory - and hence the time to do the recovery; and
    - the impact on applications of doing the QUIESCE.

    Most sites have stopped doing those archive logs unless they are transporting image copy
    and archive log datasets to a remote site. In which case they do the archive log *after* the
    last image copy going off-site.

    James Campbell



    On 10 Mar 2022 at 14:57, william giannelli via Interna wrote:

    > We take daily imagecopies of our DB2 Catalog objects and first run "ARCHIVE LOG MODE(QUIESCE)".
    > There was a "complaint" that this caused application threads to wait.
    > Is it proper to do this quiesce in order to get consistent backups for recovery purposes?
    > Or can this be eliminated without risk?
    > thanks
    > Bill
    >
    > ------------------------------
    > williamgiannelliMe
    > ------------------------------
    >
    >


    Original Message


  • 4.  RE: Daily DB2 Catalog Imagecopies

    Posted Mar 11, 2022 08:53 AM
    We quit doing ARCHIVE LOG MODE(QUIESCE) many years ago because it did start causing timeout issues. We still issue an archive log command with our nightly image copies but not with a quiesce. Our image copies are all share level change; they have to be in our shop. We've never had an issue with either recovering a table or with a disaster recovery test.

    ------------------------------
    RussellPetersCentral Technology Services
    ------------------------------

    Original Message