• comprehensive material on how to hunt for deadlocks

    From Joachim Tuchel@21:1/5 to All on Thu Feb 21 23:20:33 2019
    I am looking for material that can help me find a deadlock in our db2 application. I have found lots of docs and tutorials that tell me a lot about why deadlocks are bad and that *.evt files may help, but most of them end with something like "our
    services, btw, are available to do it for you".

    We've come so far that we can tell that we have deadlocks - even though db2diag.log doesn't say so. But what is an efficient way to commence from here?

    How to find out which tables/pages/whatever are locked?
    How to find out which queries do block each other?

    Is there any material that guides you throught such a process? What to look at, what to try?

    Joachim

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ian@21:1/5 to Joachim Tuchel on Fri Feb 22 08:24:08 2019
    On Friday, February 22, 2019 at 12:20:35 AM UTC-7, Joachim Tuchel wrote:
    I am looking for material that can help me find a deadlock in our db2 application. I have found lots of docs and tutorials that tell me a lot about why deadlocks are bad and that *.evt files may help, but most of them end with something like "our
    services, btw, are available to do it for you".


    Please see:

    https://datageek.blog/2012/01/18/analyzing-deadocks-the-old-way/

    and

    https://datageek.blog/2012/01/23/analyzing-deadlocks-the-new-way/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joachim Tuchel@21:1/5 to All on Tue Feb 26 01:03:29 2019
    Ian,

    thanks a lot for the links. This may be a stupid question, but the measures described there are to be taken before/until a deadlock occurs, right? So the monitor will be logging stuff for quite in case or rare deadlocks.

    Sorry if I failed to read something obvious...

    Joachim

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)