views:

954

answers:

7

I have a java program that runs a bunch of queries against an sql server database. The first of these, which queries against a view returns about 750k records. I can run the query via sql server management studio, and I get results in about 30 seconds. however, I kicked off the program to run last night. when I checked on it this morning, this query still had not returned results back to the java program, some 15 hours later.

I have access to the database to do just about anything I want, but I'm really not sure how to begin debugging this. What should one do to figure out what is causing a situation like this? I'm not a dba, and am not intimately familiar with the sql server tool set, so the more detail you can give me on how to do what you might suggest would be appreciated.

heres the code

stmt = connection.createStatement();
clientFeedRS = stmt.executeQuery(StringBuffer.toString());

EDIT1:

Well it's been a while, and this got sidetracked, but this issue is back. I looked into upgrading from jdbc driver v 1.2 to 2.0, but we are stuck on jdk 1.4, and v 2.0 require jdk 1.5 so that's a non starter. Now I'm looking at my connection string properties. I see 2 that might be useful.

SelectMethod=cursor|direct
responseBuffering=adaptive|full

Currently, with the latency issue, I am running with cursor as the selectMethod, and with the default for responseBuffering which is full. Is changing these properties likely to help? if so, what would be the ideal settings? I'm thinking, based on what I can find online, that using a direct select method and adaptive response buffering might solve my issue. any thoughts?

EDIT2:

WEll I ended changing both of these connection string params, using the default select method(direct) and specifying the responseBuffering as adaptive. This ends up working best for me and alleviates the latency issues I was seeing. thanks for all the help.

A: 

Pulling back that much data is going to require lots of time. You should probably figure out a way to not require that much data in your application at any given time. Page the data or use lazy loading for example. Without more details on what you're trying to accomplish, it's hard to say.

JP Alioto
I'm ok with a long time, I'm even ok with it taking several minutes, tens of minutes is fine, but hours just seems to me that something odd is going on.
shsteimer
How is your memory doing on the box?
JP Alioto
A: 

The fact that it is quick when run from management studio could be due to an incorrectly cached query plan and out of date indexes (say, due to a large import or deletions). Is it returning all 750K records quickly in SSMS?

Try rebuilding your indexes (or if that would take too long, update your statistics); and maybe flushing the procedure cache (use caution if this is a production system...): DBCC FREEPROCCACHE

Mitch Wheat
A: 

To start debugging this, it would be good to determine whether the problem area is in the database or in the app. Have you tried changing the query such that it returns a much smaller result? If that doesnt return, I would suggest targeting the way you are accessing the DB from Java.

akf
A: 

Does it take a similar amount of time with SQLWB? If the Java version is much slower, then I would check a couple of things:

  1. You shoudl get the best performance with a forward-only, read-only ResultSet.
  2. I recall that the older JDBC drivers from MSFT were slow. Make sure you are using the latest-n-greatest. I think there is a generic SQL Server one and one specifically for SQL 2005.
Brian Reiter
+2  A: 

Be sure that your JDBC driver is configured to use a direct connection and not a cusror based connection. You can post your JDBC connection URL if you are not sure.

Make sure you are using a forward-only, read-only result set (this is the default if you are not setting it).

And make sure you are using updated JDBC drivers.

If all of this is not working, then you should look at the sql profiler and try to capture the sql query as the jdbc driver executes the statement, and run that statement in the management studio and see if there is a difference.

Also, since you are pulling so much data, you should be try to be sure you aren't having any memory/garbage collection slowdowns on the JVM (although in this case that doesn't really explain the time discrepancy).

Yishai
why do you say to use direct instead of cursor based? isn't based supposed to help with large result sets?
shsteimer
@shsteimer, Accroding to Microsoft docs, Direct is faster. You should only use cursors if you need the row by row access (or in JDBC, if you need distributed transactions across multiple database, you have no choice.
Yishai
A: 

Try adjusting the fetch size of the Statement and try selectMethod of cursor

http://technet.microsoft.com/en-us/library/aa342344(SQL.90).aspx

We had issues with large result sets using mysql and needed to make it stream the result set as explained in the following link.

http://helpdesk.objects.com.au/java/avoiding-outofmemoryerror-with-mysql-jdbc-driver

objects
A: 

use http://jtds.sourceforge.net/ for jdbc driver.. and check parameters..