Database Dashlet Exec Avg time and DB Time Measure
Hi,
First of all I m quite new to Dynatrace so bare with me,
We have a Java application with a MS SQL server that Dynatrace monitor (Only the Java Application) and recently have observed one of the dashboards we have which got a chart of a Average DB Time, it is indicating that it has doubled, so I started looking in to finding what happened and was going through and comparing 2 time slots before and after the increase in DB Time on the database dashlet to see if I can see any inconsistencies.
When I compare Database Time Measure (In the Measurements) and the Exec Avg in Database Dashlet under Transaction response time contribution look inconsistent,
For example
The DB Time(Avg) is showing it has jumped from 1.68 to 3.29 but in the Database Dashlet under Transaction response time Contribution Exec Avg has not changed in that proportion.
Tried finding some documentation but non that explains it well,
So What I m after is what does the Exec Avg, Exec Total, Executions under transaction response times in Database Dashlet mean? and How does that co relates to DB Time and DB Count Measures,
Please help.
Thanks in advance.
Charaka,
This certainly seems odd. Can you post two small session files (even a single PP) from before and after the configuration change?
If for some reason this isn't possible, I might recommend that you open a support case and upload the session files there (along with a support archive).
What release / version are you running?
-- Graeme
Hi
Any chance you can export some PurePaths from both time periods? Or show some screenshots?
I always like the comparison feature of the Database Dashlet itself. You can specify two timeranges and it will show you the difference in both Exec Time but also in Exec Count. Also the total sum would be interesting to compare instead of just the individual differences between single SQL statements. Maybe you get a changed access pattern - meaning - you have one SQL statement that is not necessarily slower than before but is not called much more frequently. If this statement has a higher average than others that might be called less now it would explain an overall increase in average execution time
So - have a look and compare two timeslots but also look at Execution Count and at Execution Sum
Hi Andreas,
Thanks for the reply, Managed to find the problem, around the same time we see the DB Time going up, we have changed the capture settings for JDBC sensor configuration as part of a recommendation to be "No Aggregate or bind value capturing" to "Enable Aggregation", when I rollback the change the DB time went back to what it used to be,
Now the question takes a different prospect, Have we been monitoring the correct DB Time before or are we looking at the correct one now?(Enabled aggregation) , What is the correct metric? And also Aggregating the capture setting effecting the way it calculates the DB Time kind of worries me, Any thought on this? really appreciate you response.
The timings SHOULD NOT change. If you see different timings this might indicate a bug in dynatrace.
What version of dynatrace is this?
