Dbas just need the actual sql statement that is getting executed. The number of times each statement is executed is a nice feature. That will help prioritize what need to be worked on first.

I can't think of any other things, as most of my job from there on would be to use the tools specific to the database in question. One nice feature would be to be able to setup a tools option for editing/testing the sql statement. Meaning that I could double/right click and have the statement open in my favorite sql tool.

i would also include the average duration time for each statement... that also paves the way to including a feature similar to dotTrace's HotSpots view. Which would be very useful for both developers and DBA's i think.

Why not let DBA to generate his own reports ?

Just give him enough information in the format that can be easily imported in db table. DBA can then write SQL they like against that table and perform analysis they are interested in.

Not only the average duration time, but also the:

• exact time statement has begun execution

• duration

• value of bind variables

It would also be nice if DBA could make a backup of database at time T1, let application run until T2, get profile log, restore backup (to another db instance) to state at T1 and run statements from profile log again.

Even if you dont have dba, you may still be interested in statistics to tune indexes/optimize query plan

The boundry between DBA and developer varies massively. Why not just have 'advanced' level information?

I really liked the idea you came up with for applications having a blog RSS feed ( ayende.com/.../...-you-application-has-a-blog.aspx).

I don't know if that would be a suitable publishing channel for this kind of information, but food for thought!

Additionnaly to the average response time per statement, I would add the N worst statements in terms of response time for a single call.

Another interesting feature would be to correlate the response time with the actual quantity of data that was output by the query (just mark bad performers as warnings ... it's difficult to guess the complexity of a query returning a scalar value ...)

I was thinking today about this... And I have no suggestion, just a simple question:

If I were dba, which benefits would have to use nhProf over the standard database profiler? (lets say Sql Server Profiler)

A dba will not use this tool, they will use the target database tools and run the query through the optimiser, looking at the execution plan as they go, they will be familiar with the tools they already have and know how to use them.

I'm struggling to see how NH Prof is useful to them.

NHProf is not for DBAs. The database profiling tools they already have are much better tools for them and more useful.

I realize I'm late here, but I agree with Mark 100%.

Have to agree with Mark & John here - There's much more to query performance that what can be gathered on the client. Elapsed time? Not really useful except as an rough indicator to the developer.

What I've seen before is an impedence mismatch between the developer who's thinking in HQL/Criteria and the DBA thinking in a particular SQL dialect. The profiler might be useful if it can bridge this somehow.

But the big thing is: is the DBA really going to be a customer?

From what I've seen the DBAs can get a bit hung-up on the generated query syntax and readibility; sometimes offering optimisations that either are impossible to implement, or just plain don't optimise because the HQL is actually better even though it looks a bit chaotic.

If the role of the DBA is to offer advice on indexing, partitioning, disk usage, etc, yet another list of the SQL statements executed is not going to help much.

NHP is useful to developers and in those situations where the database is not critical enough that you need DBAs.

Unless you can get a real set of requirements from a DBA that satisfy a real business need, I wouldn't focus too much on trying to offer them things they might not need.