I’m working on an application with SQL Server 2008 as the backend. At the end of each day, I back up the database and restore it on my laptop so I can continue development at home. Everything works fine in both setups, with the exception being that queries running on my local machine take dramatically longer (several seconds vs subsecond) than when I’m querying a remote server at work.
I specify the server by name and use “.” to connect to my local instance. The app is Excel VBA connecting via ADO using integrated security.
I don’t know the specs of the server at work, but I imagine they are better than my laptop, so that probably accounts for some of the difference. However, my dev laptop is decent (Windows 7, 2.4GHz Core i5, 64-bit, 8GB RAM) and the database is very small at this point.
Why would performance be so dramatically different? What should I look at on my laptop to improve performance?
EDIT: It turns out that the queries aren’t at fault. The round-trip to the server to get data was taking a lot longer on my laptop, and I incorrectly assumed it was the query, when it is actually the connection. When I connect to the database engine through SSMS it takes about the same amount of time in either environment, but when I connect using ADO, the connection is what is taking way longer locally. Any idea what would cause this delay?
I’m marking Mitch’s reply as the answer (helpful in troubleshooting variance in query times and environments) and will create a new question regarding the connection delay.
UPDATE: Here is a link to my question on SE.DBAs regarding the horrible performance of the connection on localhost: https://dba.stackexchange.com/q/18231/2848
Do the queries in question have the same query plan in both environments?
Is it slow locally the first time you run, and then fast on the second run? (If so, it’s likely the difference in physical I/O speed loading pages into memory)
As a first step, I would rebuild all indexes and update column statistics in both environments and then re-compare the query plans:
With the usual caveats regarding production (you state your DB is small, so it shouldn’t take long to run these commands).