Retrieve SQL Server query statistics through JDBC - sql-server

Question

I would like to retrieve the statistics information returned by SQL Server when using SET STATISTICS IO ON through a JDBC interface.
Getting the execution plan is pretty simple because after running SET SHOWPLAN_XML ON the result of a call to Statement.execute() will be the execution plan. When using SET STATISTICS XML OFF a second ResultSet is returned by the Statement instance.
However when running SET STATISTICS IO ON before using Statement.execute() only the query results are returned. No further ResultSets, no Warnings nothing.
Does anyone have a clue how I can get that information? Where it might be hidden?
I tried using jTDS as well as Microsoft's JDBC driver (3.0 and 4.0) against SQL Server 2005, SQL Server 2008R2 and SQL Server 2012.
I checked all ResultSets returned by the query (checked by using Statement.getMoreResults()), as well as the Warning objects returned by the Connection.getWarnings() and Statement.getWarnings().

Answer 1

Contrary to SET SHOWPLAN_XML ON that change the resultset of any subsequent statement to the plan instead of the result of the query, SET STATISTICS IO ON doesn't.
SET STATISTICS IO ON let the query executes and displays the stats as a message.
See http://msdn.microsoft.com/en-us/library/ms131350.aspx
In ADO.NET, there is a event on the SqlConnection object called InfoMessage on which you can plug a handler and get any message the server displays, as prints or IO stats for example.
I have quickly looked at MS JDBC driver for SQL Server and didn't found anything close, best I found was this : Is there a way to display PRINT results with SQL server JDBC driver?.
My Java knowledge is thin and there could be something similar in an other driver although the above link on SQL Server Message Results only mention "SQL Server Native Client OLE DB provider".
After looking a bit more, I found out that you can get the message runing a trace (with the profiler) and that the message appears as a trace message under the "User Error Message" EventClass, which contains the TransactionID you can use to relate it to your batch.
There is a default trace running in the background of SQL Server.
See http://www.simple-talk.com/sql/performance/the-default-trace-in-sql-server---the-power-of-performance-and-security-auditing/ and http://www.sqlservercentral.com/articles/sql+server+2005/64547/ and you might insert the event you need in the trace, or run an other one then read from it.
Though to be honnest, I hope you find a better solution.
EDIT :
I have no clue why you would be able to get print message but not IO stats with the JDBC function but I can propose something else, in the direction I started with the trace.
You can do that with extended events, put a handle on the right event, and read the trace after with something like this :
First execute this on the DB :
CREATE EVENT SESSION QueryStats ON SERVER
ADD EVENT sqlserver.error_reported
(
ACTION(sqlserver.sql_text)
WHERE (severity = 10
AND state = 0
AND user_defined = 0
AND error = 3615)
)
ADD TARGET package0.ring_buffer
WITH(max_dispatch_latency = 1 seconds)
GO
then around your statement :
ALTER EVENT SESSION QueryStats ON SERVER STATE = START
SET STATISTICS IO ON
select * from MyTable -- your statement(s)
SET STATISTICS IO OFF
WAITFOR DELAY '00:00:01'; -- you have to wait because you can't set under 1 second of max_dispatch_latency
WITH QueryStats
AS (
SELECT CAST(target_data AS xml) AS SessionData
FROM sys.dm_xe_session_targets st
INNER JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
WHERE name = 'QueryStats'
)
SELECT
error.value('(#timestamp)[1]', 'datetime') as event_timestamp
,error.value('(action/value)[1]', 'nvarchar(max)') as sql_text
,error.value('(data/value)[5]', 'varchar(max)') as [message]
FROM QueryStats d
CROSS APPLY SessionData.nodes ('//RingBufferTarget/event') AS t(error)
ALTER EVENT SESSION QueryStats ON SERVER STATE = STOP
GO
And there you get a second result set with your IO stats.
Still, the solution is far from final, because there would be a need to remove the wait time and to scope the trace better, which might be possible.
You also might let the trace run and get all the statements / IO stats later in time depending on what you intend to do with those.