February 9, 2010 at 10:03 pm
y.koteswarrao-652921 (2/9/2010)
This is artice is very good and usefull in solving
No, the article is neither good nor useful. Read over the prior comments to see why.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 10, 2010 at 6:55 am
Hi Gail,
I suspect he\she was commenting on the followup comments regarding corruption, dbcc, video links etc..
Thanks to everyone for posting the links and other comments, it turned a bad article into a great resource for others.
Dave
February 10, 2010 at 7:50 am
i believe it should be
RESTORE DATABASE <suspecteddatabasename> WITH RECOVERY
February 10, 2010 at 8:04 am
Vee (2/10/2010)
i believe it should beRESTORE DATABASE <suspecteddatabasename> WITH RECOVERY
Yes, however that does not fix a suspect database. It brings a database that's in the RESTORING... state Online.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 10, 2010 at 8:34 am
Very nice article.
I remember one of my production databases went to SUSPECT, basically the drive where the data/log files were located ran out of space.
Basically I released space, stopped-started the sql service and voilá. The database came online.
Rolando.
February 10, 2010 at 10:12 am
BTW, you can write some T-SQL code with little effort that will check disk space on all fixed drives on your db server via a daily job and notify you via email if available space on any of your drives falls below a given amount. This is indispensable in preventing this from catching you unaware and sending your database into suspect mode before you can do something about it 🙂 Let me know through email talltop@bellsouth.net if you are interested and I can send it to you....
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
February 10, 2010 at 10:25 pm
TravisDBA (2/10/2010)
BTW, you can write some T-SQL code with little effort that will check disk space on all fixed drives on your db server via a daily job and notify you via email if available space on any of your drives falls below a given amount. This is indispensable in preventing this from catching you unaware and sending your database into suspect mode before you can do something about it 🙂 Let me know through email talltop@bellsouth.net if you are interested and I can send it to you....
Travis, Thanks for your points.
Do you have any suggestions if we need to use this script for around 200 to 250 instances.
Then we would need to use SQLCMD or ISQL right? That is to connect to each one of them. However, ISQL would no longer be supported in future.
Otherwise, it would get too manual to set 250 jobs for 250 servers to monitor disk space.
M&M
February 10, 2010 at 10:32 pm
The more I read on this thread the more worried I become... do you actually believe this ...?
RUNNING OUT OF DISK SPACE WILL NOT SEND YOUR DATABASES SUSPECT.
Come on guys read Books on line, buy an Admin guide, heck fill a disk drive and see what happens. Thankfully its comments like these that keep employers worried and me employeed.
February 10, 2010 at 10:46 pm
I heard this anecdotally several times while writing CHECKDB and emergency mode repair for 2005. Spent several days trying to force SQL Server to make a database go suspect because of running out of space.
It's not possible in 2000 onwards. The transaction log reserves space in itself to guarantee that in-flight transactions can always rollback and not make the database go suspect. Hitting a corrupt page during a rollback will make the database go suspect however. Running out of space cannot, unless rollback hits a corrupt page (that it didn't hit during the actual transaction). That's corruption - that's not running out of space.
Thanks
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
February 11, 2010 at 7:29 am
I know the SQL is prepared for every known bad situation, but it still fails.
I've seen lot of situations where the package should not fail and it does. Here is another story about space : A DBCC that hungs or stalls because there is not enough space on disk. Error log reports "...waiting for FCB_Replica...".
The database is 150GB and the free space is about 70GB. When I released some to some 120 GB, it runs smootly.
I've read many msdn blogs, articles, none realy gave a real solution, releasing space gave it.
Well this comment is out of the topic but this confirms that all sistems fails. I still like the package and is very reliable but I'm confident that all systems fails sometimes with unexpected issues.
February 11, 2010 at 8:41 am
Well of course they do - no-one was saying SQL Server is infallible - just that it doesn't fail in the way described.
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
February 11, 2010 at 8:52 am
Cars break (or don't brake, thank you Toyota, Honda, Ford), planes break (Boeing, Airbus), my bones have been broken (Mom).
It all comes down to using the best practices to try and keep everything humming along and minimizing the hicups that all software, hardware will eventually suffer.
Having a preventive process in place and the resources, knowledge and processes to lean on when something does break is the key to restful nights and happy
bosses and customers.
Dave
February 11, 2010 at 9:09 am
Malcolm Daughtree (2/10/2010)
The more I read on this thread the more worried I become... do you actually believe this ...?RUNNING OUT OF DISK SPACE WILL NOT SEND YOUR DATABASES SUSPECT.
Come on guys read Books on line, buy an Admin guide, heck fill a disk drive and see what happens. Thankfully its comments like these that keep employers worried and me employeed.
That was not my point. Whatever the failure is or isn't, or as Paul basically states "it doesn't fail in the described way" that is still no reason to not check for available apace left on drives regularly. It can head off a lot of unexpected issues from occurring. That is what I was trying to put forth. It's not so much about what exactly causes or doesn't cause a failure, it's more about installing proactive measures like I stated above to prevent them, or at least notify someone beforehand, in the first place. For example, your car engine can fail for a myriad of reasons (most of them you may not even know), and many of them may have nothing to do with dirty oil, but it would still be foolhardy for anyone to not change the oil regularly.. That is just common sense. So, regardless of whether a full drive causes a suspect database or not in any version of SQL Server, doesn't really matter, even so still check the available space on those drives regularly! 🙂
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
October 21, 2013 at 2:49 am
Hi Gail,
Your nice-n-simple Offline/Online worked perfectly for us when we had a DB in "Recovery Pending" state.
Cheers!
March 11, 2014 at 3:34 am
Hi Prasad,
Please help me the complete details in code format.I'm very new to Sql Server.
Appreciate your help on this..
Regards
Ravi Theja
Viewing 15 posts - 31 through 45 (of 46 total)
You must be logged in to reply to this topic. Login to reply