Question about DB extent performance
-
Hello,
We have SQL 2k with a 7gb database and 10% autogrow. Seems that when an (admittedly rare) extent is called for, transactions that normally run around 800k single-threaded per day seem to die after 30 seconds, and this goes on for about 1-2 hours. Then all is well. Is this a time-out? We aren't getting any bad rc back to the VBscript app (I know, but we're stuck with it) and it goes on its merry way like nothing happened, meanwhile, NO INSERT!
Is the VBscript swallowing our error? Is a 700mb extent THAT horrible? What's SQL doing with this insert, wouldn't the first one just wait for the extent to finish? But then how does the extent ever finish (which it does eventually) if every insert fails? I am clearly missing a concept here.
We are on a 2-way with a 3x36mb disk in raid-5. I know raid-5 is bad for writes (i.e.: the formatting during an extent), but this seems excessive.
Thanks
Database Dave
-
autoextend is indeed a slow process, but 1 - 2 hours
If you create a new db with a datafile of 700mb at the same device as your current extended-datafile, how long does that take ?
Having good sized db-files is offcourse the best way to avoid this.
If you can extend the files yourself before the system does, so you have control and know when interference happens.
Maybe you would be better off with a raid10 of 2 times (33+33).
the is an other forumthread about extends : http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=5&messageid=128021#bm128118
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data/code to get the best help[/url]- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply