Db2 - L

 View Only

  • 1.  Advices of not using Incremental ImageCopy

    Posted May 20, 2022 05:21 AM
    Hello everybody. I hope you're doing well.
    I've just read this blog about Incremental Image Copy : 

    https://www.kbce.com/incremental-copies-a-false-sense-of-security/

    So i would like to have your opinion about it.
    Do you agree with the analize of not using  Incremental Image as much as possible ?

    ------------------------------
    SamBoORANGE
    ------------------------------


  • 2.  RE: Advices of not using Incremental ImageCopy

    Posted May 23, 2022 12:04 AM
    Hi Sam,

    First, a disclaimer - I have not worked on Mainframe Db2 for a long time.

    On to the article.  Be aware , the article is 9 years old, and 3 versions of Db2 ago. Things change a lot in that time.
    The scenario they are depicting of a system that gets a Full Image Copy (FIC) followed by 7 weeks of only incremental copies is, in my opinion, ludicrous. No site should take that sort of risk. 

    Most places would have at least a weekly FIC, and probably daily incrementals for a Production system. You would need to ensure that you know the retention times for your Archive Logs, Image copies etc. so that you can ensure that your archive logs are available when you need them.

    For a production database, when I did MF work, we would have dual logging, dual archives, dual BSDS.  We did backups and archives to disk, with HSM doing dataset migration to secondary storage at certain intervals.

    It really is a matter if ensuring you know your system, and that your setup is correct for your needs. I'm sure you'll get more detailed feedback from people who  are more current on the zOS systems than I am :D

    Regards,
    Greg


    ------------------------------
    Greg Palgrave
    Database Herder
    ------------------------------

    Original Message


  • 3.  RE: Advices of not using Incremental ImageCopy

    Posted May 23, 2022 03:01 AM
    Hi!
    I think that IICs are actually very good but there is a sweet spot for their usage of course! An example is a one byte Y/N flag change on a tablespace with a LOB column. The FIC could be TBs but the IIC only a few KBs. I would also never do more than five IICs before finally doing a FIC (MERGECOPY is *not* my favourite utility!)
    The problems of Data-sharing and IICs must also be weighed up... I know shops where TRACKMOD NO is used for performance but that causes death by R Scan for IICs...
    Basically "It depends" is the correct answer!

    Just for fun: A few years ago I took 80 IICs of an object and then the MERGECOPY abended due to SOS attempting to allocate lots of input DSNs in parallel... I have not been bored enough to try this again but this is just a reminder of not just doing IICs!

    Hope that Helps!

    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
    Web http://www.seg.de
    Link zur Datenschutzerklärung

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


    Original Message


  • 4.  RE: Advices of not using Incremental ImageCopy

    Posted May 23, 2022 08:18 AM
    Thank's for your answers.

    ------------------------------
    SamBoORANGE
    ------------------------------

    Original Message


  • 5.  RE: Advices of not using Incremental ImageCopy

    Posted May 23, 2022 09:25 AM
    Hi Sam,

    first: what Greg says.
    secondly: MERGECOPY is your friend here - if you run regular incremental IC, run MERGECOPY at least once a week.

    then a question: why would you run incremental IC, when you can run online IC (depending on your SHRLEVEL value)?

    Thanks.


    ------------------------------
    Aurora


    Stay safe and healthy, y'all
    ------------------------------

    Original Message


  • 6.  RE: Advices of not using Incremental ImageCopy

    Posted May 29, 2022 07:31 AM
    Hello.

    My two cents here.

    We run a full image copy with shrlevel change only for tables that changed that day.

    A table is considered changed if a load was run or DML was executed (using RTS to check that).

    After the copy ends, we find a mutual quiet point in the log for all of the objects that were copied and inserting a quiesce point in SYSCOPY.
    This ensures a "clean" point to return to if needed.

    Once a week (on Saturday) , we copy everything so the oldest copy of each table is no more than a week old.

    Hope this helps.

    Shay.

    ------------------------------
    ShayMillerMataf
    ------------------------------

    Original Message