October 24, 2007 at 11:56 am
If you're doing a lot of writes then RAID 5 is not the way to go - you'd be better off with RAID 10. See this whitepaper on Physical Database Storage Design for more info - the concepts mostly apply to 2000 as well as 2005.
I'm not an expert on the output of SQLIOSim, but there are some good articles by the top guys in Product Support that explain them - see my blog post here for links.
Hope this helps.
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
October 24, 2007 at 11:21 pm
Thanks a lot to all for your help and advice. The workaround Gail suggested earlier seems to be getting me past the latch error situation. I have been shrinking 10 gig at a time rather than trying to shrink 50 or 100 gig in one shot, and that's been working fine. Thanks Paul for the DBCC PAGE and trace flag tips, I'd like to learn more about all that.
I will be looking into learning more about analyzing the results of the simulator.
Looks to me like the hardware or firmware in the controller is suspect.
This forum is a great resource and I look forward to being able to contribute some day.
Best regards,
CJR
October 26, 2007 at 10:20 am
I'm not sure about the latch error, but the timeout could be just trying to do too much at a time.
Try smaller increments. Do something like:
dbcc shrinkdatabase 'dbname',40
dbcc shrinkdatabase 'dbname',30
dbcc shrinkdatabase 'dbname',20
dbcc shrinkdatabase 'dbname',10
Same can be done with shrinkfile.
October 29, 2007 at 6:28 am
Dear CJR
dont worry its happened
any ways i am giving you some techenique if you follow you will get rid off this issue
For example your Database name is Smart
Create another database, name is Smart2
create the table structrure from enterprise manager
in smart database
Export the complete table that you feelt in problem
to smart2 database ,,, ok
Drop the the table in smart database
execute the script of the table on smart Database that you have created
from enterprise manager.
again export the table from smart2 to smart database
drop all indexes
perform shirink operation
inshallah your problem will resolved
do inform me
Regards
Syed Muhammad Naveed
Database Administrator
October 30, 2007 at 5:09 pm
syed muhammad naveed (10/29/2007)
Dear CJRdont worry its happened
any ways i am giving you some techenique if you follow you will get rid off this issue
For example your Database name is Smart
Create another database, name is Smart2
create the table structrure from enterprise manager
in smart database
...
Might as well i do a backup and restore. This method doesnt make sense to me because unless the DBA understands the DB structure throughly, its dodgy this way assuming you have to know all the contraint, indexes, referential integrity, etc were rebuilt during the transfer. I'm not sure how this will help in the shrinkfile timeout.
I do agree with Gail on performing the shrinkfile in smaller chunks. Makes sense especially if you're shrinking a large chunk of space. Same goes to allocating more space for filegroups. I've had experience with auto-growth, where the tempdb filegroup was growing at a tremendous pace. Default 10% of 50GB is 5GB and it'll give you a similar timeout on a busy server.
Simon
Simon Liew
Microsoft Certified Master: SQL Server 2008
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply