Preventing Log Saturation

You may also like...

7 Responses

  1. Raul Baron says:

    Wow !! Excellent article !! I will put this in my to-do list immediately !!! Thanks for sharing !!

  2. Ananth says:

    Ian, Excellent blog.. I love that parameter that would be of great help. But i have a doubt in using db2gov as it sometimes consider backup as idle application and forces it aswell.. So i would use this parameter making things simple. Thanks again

  3. Wen says:

    Great idea! We had the similar situations of “log full” caused by some uncommitted transaction. This is an excellent way to handle the situation. Thanks!

  4. Luke Numrych says:

    This is a great tip!

  5. Robelis says:

    Great Tip…

    But, a little doubt.
    Suppose that exist two apps holding the logs, following your example, the DB2 will understands that each transaction can hold 10 logs or will share this number for both?

    • @Robelis, It does not matter how many applications are connected and active, it’s always the application with the oldest transaction (i.e. the application with the current LowTranLSN) that will be killed if the difference between Current LSN and LowTranLSN exceeds NUM_LOG_SPAN.

      Only 1 application can have LowTranLSN at a time, so the application with the oldest transaction will be forced when NUM_LOG_SPAN is exceeded for its transaction. At this point, a different transaction will have LowTranLSN. If the Current LSN moves forward enough to cause this transaction to exceed NUM_LOG_SPAN, then it will be forced, too.

      Make sense?

  6. larry sokoloski says:

    @soko15576 Hi Ian, I just ran into this problem using ATS running RUNSTATS. Great article!

Leave a Reply

Your email address will not be published. Required fields are marked *