5.5 Database Node Aggregation
Hi All,
Trying to determine the possible impact of migrating to 5.5 from 4.2 at one of my customers. Just want to verify what I believe to be true:
In our case for every JDBC query there is a prepareStatement(), getConnection(), and executeQuery() invoked. Will these become one node instead of 3 after the agent upgrade?
Thanks,
Rick B
Hi all,
tweaked Sensor Properties#DB, and Database Query Statement Aggregation in JDBC Sensor and ADO.Net Sensorto be more informative and accurate.
Looking forward to the things to come
G.
hi Rick,
just adding to Rob's comment:
the DB node aggregation in 5.5 will aggregate preparations & executions so they will be grouped by SQL string (not including bind values).
getConnection() calls will not be aggregated yet, this is something we're currently working on.
best,
Christian
The dtMigration tool should work fine for you on this.
The new database aggregation is an option available to you in dT 5.5. You don't have to use it, but I know you've been looking forward to it! :-)
The aggregation is different from what you mention above. It collapses "like" statements, not "statement families" as you're asking.
See this for some details: https://apmcommunity.compuware.com/community/display/DOCDT55/JDBC+Sensor#JDBCSensor-DatabaseQueryStatementAggregation
Rob
I had seen that but still don't quite know what to make of it or how to interpret your explanation. I guess I'll see for myself, but can anyone say in general if this optimizes MPS (NPS)?
and of course this reduces NPS, as the aggregation happens on the agent.
Yes, the goal is absolutely to reduce MPS.
What I meant was that it would take copies of the same statement and collapse them into one line. (In the screenshot, it has the queries and a count associated with them). What's it's not going to do is take create/prepare/execute and turn that into single nodes. I think (but do not know for sure) that this kind of optimization is in the works. Perhaps the lab can comment on that.
