Results 1 to 4 of 4
  1. #1
    Join Date
    Feb 2011
    Posts
    45
    Provided Answers: 1

    Answered: Getting event monitor details inside procedure

    DB2 9.7

    I set up an event monitor to troubleshoot a latency-laden process. All is fine except that all the latency occurs inside a procedure, and my event monitor (filtered to my user and the particular application I am running) shows only the call to the procedure--none of the individual statements inside that procedure. Without that, I am still completely blind, knowing only that the latency is not in one of the simple SQL statements run by my application, but in one of perhaps 1500 lines inside a procedure.

    Is there a way to configure an event monitor differently in expose/record each SQL statement inside the call to the procedure? Is this because the procedure itself is not related to my particular application? Do I need to remove the application-level filter when running the monitor?

  2. Best Answer
    Posted by Brian.Hart

    "Well, I eventually did remove the application filter, leaving only the filter on my authorization ID, and this seems to have done the trick, since I now see all the SQL statements running within procedures called by the application. I infer, then, that the SQL statements contained in a procedure called by an application are unrelated to that application but are still related to the authorization ID. That is, the relationship between the statements inside called procedures and the original application apparently have no relationship to the spawning application, but they do seem to retain a relationship to the authorization ID."


  3. #2
    Join Date
    Apr 2012
    Posts
    1,143
    Provided Answers: 27
    The account that calls the sproc can be different from the account that executes the sproc depending on how it's set up, so you might not be filtering on the right account.

    If the sproc uses static SQL you need to monitor the sections of the package(s) involved.

  4. #3
    Join Date
    Jul 2016
    Location
    Moscow
    Posts
    294
    Provided Answers: 45
    Regards,
    Mark.

  5. #4
    Join Date
    Feb 2011
    Posts
    45
    Provided Answers: 1
    Well, I eventually did remove the application filter, leaving only the filter on my authorization ID, and this seems to have done the trick, since I now see all the SQL statements running within procedures called by the application. I infer, then, that the SQL statements contained in a procedure called by an application are unrelated to that application but are still related to the authorization ID. That is, the relationship between the statements inside called procedures and the original application apparently have no relationship to the spawning application, but they do seem to retain a relationship to the authorization ID.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •