cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

A business transaction split on database statement filtered on database exception

mgarrison
Guide

I'm trying to write a business transaction that shows me the breakdown of database calls that are timing out. In my case the database is DB2 LUW.

Here's a sample purepath:

I am filtering on DB2Exception containing SQL0952N which is a timeout.

I would like to then split on the database statement, which can be seen as the argument value of ExecuteReader.

Unfortunately there can be many calls to ExecuteReader in the purepath (but probably only one that is part of the failed Invoke).

I tried to just use this as the splitter, but it didn't work:

Does anyone have any ideas how I can accomplish this?

2 REPLIES 2

graeme_william1
Inactive

Mark,

There's something I noticed in your measure. The Method field should be just the method name, 'ExecuteReader' and not the fully qualified name that you're showing in the screenshot. How did you create the measure?

So that may be the cause of your immediate problem, but it's not the only one.

Unfortunately Dynatrace, in an effort to be helpful, has led you astray. The stored procedure name shown in the argument field of the call to ExecuteReader is not, in fact, the argument to ExecuteReader. The CommandBehavior argument to ExecuteReader is just a set of bit flags which control how the SQL will be executed. Dynatrace has collected the stored procedure name from somewhere else.

I'd do a couple of things to track down the stored procedure name. First, capture the first argument to GetList. If you're lucky, that will be the stored procedure name. Second, click on "Show All Nodes" in the upper right of the lower pane to see if there is another ADO procedure in the call stack which will give you the stored procedure.

Also, don't worry about the fact that ExecuteReader (or whatever method you finally settle on to collect the stored procedure name) is called multiple times in a PurePath. There's some logic involved in using multiple splitting measures in a business transaction that I think will work in your favor -- so once you've collected the stored procedure name, just try it out with the other splitting measure and the right thing should happen.

-- Graeme

Thanks, as to the fully qualified name, that's what the class browser populates when you use it:

As to your next point, I see now that the argument isn't really the DB statement, doh.