Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««12345»»

A guide to recover a database out from Suspect mode Expand / Collapse
Author
Message
Posted Tuesday, February 09, 2010 10:03 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:30 PM
Points: 41,531, Visits: 34,448
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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #862935
Posted Wednesday, February 10, 2010 6:55 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 10:42 AM
Points: 41, Visits: 300
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
Post #863190
Posted Wednesday, February 10, 2010 7:50 AM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, October 07, 2013 9:29 AM
Points: 409, Visits: 421
i believe it should be
RESTORE DATABASE <suspecteddatabasename> WITH RECOVERY
Post #863258
Posted Wednesday, February 10, 2010 8:04 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:30 PM
Points: 41,531, Visits: 34,448
Vee (2/10/2010)
i believe it should be
RESTORE 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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #863268
Posted Wednesday, February 10, 2010 8:34 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, January 30, 2013 2:46 PM
Points: 14, Visits: 72
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.
Post #863306
Posted Wednesday, February 10, 2010 10:12 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 06, 2014 1:05 PM
Points: 1,334, Visits: 3,068
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. ..."
Post #863439
Posted Wednesday, February 10, 2010 10:24 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, April 14, 2014 5:49 PM
Points: 2,263, Visits: 3,758
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.


Mohammed Moinudheen
Post #863827
Posted Wednesday, February 10, 2010 10:32 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 02, 2011 9:50 PM
Points: 189, Visits: 335
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.
Post #863834
Posted Wednesday, February 10, 2010 10:46 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 2:09 PM
Points: 2,035, Visits: 1,655
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
Post #863841
Posted Thursday, February 11, 2010 7:29 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, January 30, 2013 2:46 PM
Points: 14, Visits: 72
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.
Post #864060
« Prev Topic | Next Topic »

Add to briefcase «««12345»»

Permissions Expand / Collapse