Hi, everyone!
I have this strange problem... After every time my application leaves sql-server idle (doesn't send anything, doesn't retrieve anything) next command to sql-server processes really long.
I've also noticed this bug/feature/misconfiguration even if I open a DB in Management Studio...
Please, could someone tell me, is there any timer that "puts a DB to sleep" if no one is using it for some time? Can I change the way server behaves in this situation?
I saw this problem once long ago when we had to shovel coal into our PC's to make them run.
In our case, the database server was on a dedicated PC. Someone had installed a graphics-intensive screen-saver. Evertime the screen-saver kicked in performance dropped.
Another possibility: Opening a DB connection takes a long time. You may be timing out and getting kicked out of the server.
|||Thanks for the reply.
Well, that's not screen saver, definitely. I had this problem both on local machine (obviously when screen saver is not running :) ) and on a remote server, but I know for sure what is going on there too.
And as I understood the second possible reason you're saying server kicks me out, but I've set the timeout to pretty big number (before I did that, I actually was kicked out all the time), but now I don't get connection-not-opened exception or anything else like that.
Everything works pretty smooth all the time (like ASP.NET page loads fast, fast postbacks, management studio works fine) until I leave server alone for some time. After that this damn lag happens (for one time, like it's reconnecting to DB or smth like that) and everything works fine again.
Maybe it's not the database but asp.net.
When all sessions end or time out, your application is shut down. See if the Application_End event is raised.
|||No, i don't think so... First of all, I used the same app with MSDE 2000 and didn't have this issue. Second, I see this issue not only when using my asp.net app, but also WinForms app, and even Management Studio (as I think I mentioned in the first post).
No comments:
Post a Comment