CODEWITHSUNDEEP
c#sql-serverado.net
Kylo Ren
Kylo Ren

Reputation: 8803

DataAdapter.Fill performance anomaly

I have two DataBases (DB1 & DB2 : both DBs are same, DB2 is created from the backup of DB1). When I run a stored procedure SP1 on both DBs it takes approximately 2 seconds to give me an output (select statements) on both DBs.

Now the problem is when I point these DBs from a service and try to use DataAdapter.Fill method, it gives me different time(54 - 63 seconds on DB1 and 42 - 44 seconds on DB2) on both DBs consistently. Noted that I'm using same service to point DBs so it couldn't be service behave/performance. Now my question is:

What could be the reason for this? Any suggestions are welcome that What should I look into?

Helping Info:

  1. Both DB are on different servers(identical configuration) but since executing the SP on SQL Server Management Studio take the same time on both DBs so I ruled out the possibility of DB server performance. Network delay could be a factor But higlly unlikely as both servers are on same network and infact on same physical location. This is my last option to check.

  2. Some other services are using SQLDependency ON DB1. Which consistently fill DataAdapter(s), could this be the reason for my DataAdapter fill method to slow down? (less likely as I'm guessing)

As requested in comments below is code that is filling the DataSet:

DataSet Fill

PS: The time mentioned above is the execution time of the code line highlighted in the above image.

Upvotes: 8

Views: 4082

Answers (3)

Khadar
Khadar

Reputation: 79

Step one - rebuild or reorg your indexes. This is usually the most common performance issue with SQL Server and is easy to fix. Restart SQL Server some times this also a matters

Upvotes: 0

Ian Martin
Ian Martin

Reputation: 11

Have you tried not using the SQL.StoredProcedure and just run it as a line of SQL: "exec dbname.dbo.storedprocname params".

Its a bit more work because you'll have to loop around the parameters to add to the string at the end but its a SQL string, it doesn't care what you are doing, its not doing anything funny behind the scenes. Should have similar times, if this is failing, try checking things like indexes etc.. on db tables that the Stored Procedure is using.

Upvotes: 0

TToni
TToni

Reputation: 9391

That sounds very much like a query plan issue.

Erland Sommerskog has written an excellent article about this kind of problems, Slow in the Application, Fast in SSMS?.

My first guess would be "The Default Settings", but it might be one of the other issues, too.

Upvotes: 1

Related Questions