InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 25 May 2013 23:41:49 GMT20http://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]Malcolm Daughtree (2/10/2010)[/b][hr]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.[/quote]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! :)Thu, 11 Feb 2010 09:09:51 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxCars 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 happybosses and customers.DaveThu, 11 Feb 2010 08:52:13 GMTDMarvezhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxWell of course they do - no-one was saying SQL Server is infallible - just that it doesn't fail in the way described.Thu, 11 Feb 2010 08:41:02 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxI 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.Thu, 11 Feb 2010 07:29:46 GMTRolando Hernandezhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxI 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.ThanksWed, 10 Feb 2010 22:46:17 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxThe 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.Wed, 10 Feb 2010 22:32:33 GMTMalcolm Daughtreehttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]TravisDBA (2/10/2010)[/b][hr]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....[/quote]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.Wed, 10 Feb 2010 22:24:59 GMTmohammed moinudheenhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxBTW, 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....Wed, 10 Feb 2010 10:12:02 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxVery 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.Wed, 10 Feb 2010 08:34:32 GMTRolando Hernandezhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]Vee (2/10/2010)[/b][hr]i believe it should beRESTORE DATABASE <suspecteddatabasename> WITH RECOVERY[/quote]Yes, however that does not fix a suspect database. It brings a database that's in the RESTORING... state Online.Wed, 10 Feb 2010 08:04:55 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxi believe it should beRESTORE DATABASE <suspecteddatabasename> WITH RECOVERYWed, 10 Feb 2010 07:50:01 GMTVeehttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxHi 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.DaveWed, 10 Feb 2010 06:55:33 GMTDMarvezhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]y.koteswarrao-652921 (2/9/2010)[/b][hr]This is artice is very good and usefull in solving [/quote]No, the article is neither good nor useful. Read over the prior comments to see why.Tue, 09 Feb 2010 22:03:24 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxGo here, look listen and learn. http://www.sqlskills.com/BLOGS/PAUL/post/TechEd-80-minute-video-of-Corruption-Survival-Techniques-presentation.aspxI can't say this loud enough [b]DONT GO ANYWHERE WITHOUT DOING SO. IT IS THE BEST 80 MINUTES YOU"LL EVER SPEND.[/b]Thanks Paul, all DBA's should see this, even the Old Farts like me !!CodeOn:-PTue, 09 Feb 2010 21:50:30 GMTMalcolm Daughtreehttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxHi,This is artice is very good and usefull in solving .............thanksKoteswar RaoTue, 09 Feb 2010 21:44:52 GMTy.koteswarrao-652921http://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]Paul Randal (2/9/2010)[/b][hr]There's also a video recording of my Corruption Survival Techniqes session from TechEd Europe in 2008 which shows me doing all of this live on stage: [url=http://www.sqlskills.com/BLOGS/PAUL/post/TechEd-80-minute-video-of-Corruption-Survival-Techniques-presentation.aspx]TechEd: 80 minute video of Corruption Survival Techniques presentation[/quote]This is the video I was referring to in my previous post that everyone should watch multiple times until you have all of the info in it committed to memory. I have watched it at least 5 times myself and the information in it is priceless. Paul also includes the corrupt dbs and code that he addresses in the video as well. One of the best videos out there on database corruption, bar none! Plus Paul goes much further, covers more errors, and in much more depth than this article covered. If you are a production DBA concerned with future database corruption then this video is a must see... It is a little on the lengthy side (80 minutes) but well worth the time put into watching it... It's like Paul says "Database corruption will happen to you sooner or later in your career" This video will go a long way to helping you prepare for it... :)Tue, 09 Feb 2010 19:21:35 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx@ Paul R, Thanks for your input. Personally, this article should never have got off the Editors desktop. It is akin to answering "How do I get SQL running faster ?" ANS: add more RAM !! Between losing database files, dodgy Transactions and suspect hardware I think there are deeper issues here and most of which could be prevented by proper Change/ Code control and a little time and effort into capacity planning in the first instance. And if these 4 situations are from "real life" I'll stand in [Insert prominant local feature] shouting beers. And I hate beer ......... :-DCodeOn :-P (better !)Tue, 09 Feb 2010 18:16:42 GMTMalcolm Daughtreehttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx@gdmilner That's not true. It's pretty well known how to attach a detached suspect database back into SQL Server in all versions, using a dummy database. Plenty of sites document the procedure (with varying degrees of correctness).For the correct method for doing it in 2005 and 2008, see my blog post that explains a demo I did at TechEd/PASS/etc in 2006-2008: [url=http://www.sqlskills.com/BLOGS/PAUL/post/TechEd-Demo-Creating-detaching-re-attaching-and-fixing-a-suspect-database.aspx]TechEd Demo: Creating, detaching, re-attaching, and fixing a suspect database[/url]. There's also a video recording of my Corruption Survival Techniqes session from TechEd Europe in 2008 which shows me doing all of this live on stage: [url=http://www.sqlskills.com/BLOGS/PAUL/post/TechEd-80-minute-video-of-Corruption-Survival-Techniques-presentation.aspx]TechEd: 80 minute video of Corruption Survival Techniques presentation[/url].No need to spend money on potentially dodgy software when SQL Server can do it for you for free if you know how.Potentially dodgy? Yes. I don't know of any of these 'recovery tool' vendors that work in all cases.ThanksTue, 09 Feb 2010 17:58:09 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxIf you make the mistake of detaching a suspect databases (as I did in my younger days) and you are pretty sure it IS corrupt -- since you cannot re-attach it and you are basically hosed -- a good tool for getting out all the possible data from and offline .MDF file is "[url=http://www.officerecovery.com/mssql/index.htm]Recovery for SQL Server[/url]." I used it and it worked really well. As I recall, it's pretty cheap, too. Cheers.Tue, 09 Feb 2010 15:58:04 GMTGreg Milnerhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxYou know an article is good if you can relate to the discussion and it gets a conversation going.Even though there is some disagreement with the information provided, it is often the case that the writer is basing his statements on real world experience.That being said, it is often the case that two techs can be "correct" in different context. But having experiences these issues mentioned in the article, I appreciate the information to help as a guide when the troubleshooting mind is harassed by fatigue and pressure to get production back on line.Good job to all the contributors on this.Tue, 09 Feb 2010 07:38:40 GMTosgcurthttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxSorry Guys and Gals but I couldn't stay quiet over this. 1. If you move Data files when in 'off line' mode it should have been communicated to your stakeholders that you were doing it and "Code red" irrelevant. “Some one deleted/misplaced a data/log file when SQL Server was offline and the database can not start because of missing file” just makes me angry where is your change control and why didn’t you backup the Database before taking it off line.2. “SQL Server could not access or place an exclusive lock on the data or log file while coming online. Typically I experience this when SQL Server is shared with some other tool” WTF. What other tool should be accessing your Datafiles apart from SQL Server and related services. And you have Anti-virus checking your data files, heaven help us all !!3. Database is in suspect because of a corrupted transaction. “The root cause of this issue is most likely SQL server abruptly went down/restarted in the middle of a transaction and while coming back” Now unless the undo and redo phase of the SQL server recovery fails you have bigger problems than a dodgy transaction and I hope you have a better backup strategy..And the comment regarding the use of DBCC commands “I recommend trying all other possible options including calling Microsoft Support before executing below steps.” Read books online. Have you tried ringing microsoft support ?? 4. I happen to agree on the probable cause, in theory, in practice anything this important to cause a “Code Red” would be on a highly available server or other enrolled in one of several scenarios the prevent this from occurring. And as foot note: Following, or at least recognizing, best practices and change control this type of situation should be a rare occurance. I have been doing this for a Long, Long time and suspect databases are RARE !Mon, 08 Feb 2010 16:49:49 GMTMalcolm Daughtreehttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]Joan OBryan (2/8/2010)[/b][hr]The easiest way I found to recover in this scenario was to take the database OFFLINE (not detach!) and then bring it back ONLINE in Enterprise Manager. This worked very well in SQL Server 2000 and didn't affect any of the other databases in the instance. I haven't encountered this kind of suspect db in SQL Server 2005 yet.[/quote]Not always it would work. I had a database suspect just 10 - 12 days back and I tried to change the status to 24 (recommended in most sql sites)UPDATE master.dbo.sysdatabasesSET Status = 24WHERE [Name] = 'MyDatabaseName'GOIt did not work. Then tried offline and online method and it also did not work. with recovery method had no luck. Last option I had and did was to copy and paste data and log files on a different path and then drop suspected database. And then attached copied files giving new database name and then mapped all users and logins.It worked like a charm.I agree with most of the comments but there is no hard code rule guaranteed for getting suspected database online. It depends what ever method works for you.Manager and users just want their database and they give a damn about how DBA gets it back,Cheers.By the way, its sql server 2000 sp4. Yeah, we still had some running on 2000.Mon, 08 Feb 2010 15:50:37 GMTSanjayAttrayhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]Joan OBryan (2/8/2010)[/b][hr]The easiest way I found to recover in this scenario was to take the database OFFLINE (not detach!) and then bring it back ONLINE in Enterprise Manager. This worked very well in SQL Server 2000 and didn't affect any of the other databases in the instance. I haven't encountered this kind of suspect db in SQL Server 2005 yet.[/quote]That is exactly how you do fix the problem where the files were inaccessible (for whatever reason) when SQL started and you have rectified the problem so that the files are accessible. By taking the DB offline and bringing it online, you're allowing SQL to try again to find and open the files. A restart of the SQL service will achieve the same thing.Note, this is for when the DB is suspect (or more likely recovery_pending) due to inaccessible files.Mon, 08 Feb 2010 12:38:14 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxThis also goes back to a point made a few months back of being careful on what you deploy based on an article you've read on the web. This site is a great resource but as with everything out there on the interweb...."Trust but verify"!Mon, 08 Feb 2010 12:26:20 GMTDMarvezhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxUtsab, I am very glad you included Possibility #2 in your guide, because like you stated, there are various conditions that can cause a database to be marked "suspect" and most people ignore this benign state in Possibility #2 that the database sometimes falls into when they document how to recover from the problem. Once SQL Server marks a db 'suspect' the worst is usually expected due to all the worst case scenarios that have been documented elsewhere and the fact that your database is no longer accessible, which tends to freak people out. I have one server that had multiple production databases, but one db would get marked 'suspect' occasionally for just this reason. And the reason is evident when you look at the SQL Error log and you see that when SQL needed access, some other process had it locked. It was then marked as suspect. The easiest way I found to recover in this scenario was to take the database OFFLINE (not detach!) and then bring it back ONLINE in Enterprise Manager. This worked very well in SQL Server 2000 and didn't affect any of the other databases in the instance. I haven't encountered this kind of suspect db in SQL Server 2005 yet.Mon, 08 Feb 2010 12:23:53 GMTJoan OBryanhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxWhile the articles author made a contribution that he thought he was helping his community - the discussion responses speak otherwise. The SSC community stepped in to clarify, augment and correct misinformation in the article. I laud the members of the SSC community that stepped up and openly discussed this article. A while back there was a rather involved discussion about 'vetting' the QOTD. Maybe now an active 'practice' of a high level 'vetting' for all of the submitted articles for content review should be thought about. While it is great that the 'experience' and 'knowledge' in the community stepped in, just think of the potential damage that may have been mistakenly caused by those more junior thinking the article was 'gospel'.Mon, 08 Feb 2010 12:20:01 GMTrudy - Doctor "X"http://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxI think Gail, Grant and Paul have made the counter points very well. It seems that the decision in this article to jump straight to emergency mode recovery was done hastily. More explanation and caution throughout the article is advisable.Mon, 08 Feb 2010 11:39:18 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxI agree, which is why I recommended Pauls site. He covers this topic in the kind of detail it deserves. His "In Recovery" series is outstanding as well as a video he did on the topic. Who better to address this very important subject than the man who wrote DBCC CHECKDB? Like Paul states it is not always neceassry to recover or repair the entire database risking unknown data loss Many times it is either a matter of just rebuilding indexes or just finding the offending record(s) and either updating or removing them. This is where DBCC PAGE can come into play. One one of the most important undocumented DBCC commands out there IMHO. Don't cut-off your arm when a band-aid will do....:)Mon, 08 Feb 2010 10:20:20 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxThis article would be fine except it doesn't cover the ground sufficiently and you could end up restoring a database over new data when there was nothing wrong in the first place.Before restoring a database that is in suspect mode, check your error log. You may find that a drive has gone offline. You may be able to bring that drive back online with the data file in tact. I have done this with SAN connections that are failing.It pays to be very thorough before jumping to the conclusion that you need to restore a production database over new data.Mon, 08 Feb 2010 09:21:45 GMTdon_goodmanhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx@Robert Not true - the action CHECKDB takes depends on the corruption - there are some cases where I delete just the corrupt record rather than the whole page.IMHO this article should not have been published in it's current form. It does not explain all the ramifications of going straight to emergency mode repair (running REPAIR_ALLOW_DATA_LOSS in emergency mode), doesn't explain the SUSPECT and RECOVERY_PENDING statuses correctly, and also doesn't advocate attempting an export/import into a new database rather than running repair.ThanksMon, 08 Feb 2010 08:13:48 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxIt is worth mentioning that after a repair with data loss, not only is the corrupted record lost, but the whole data page. The good news is that with a good backup strategy, the lost page can be restored from backups.Considering that the transaction is written to the transaction logs before committed to the database, you may get lucky and have no data loss after restoring the page.Mon, 08 Feb 2010 07:45:10 GMTRobert Ederhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote][b]GilaMonster (2/8/2010)[/b][hr]A suspect DB has to be set to Emergency mode before CheckDB can be run. There's a brief (one sentence) mention of running CheckDB in Scenario 3, right before the checkDB with repair. It should have been a lot clearer.[/quote]Ah, I did miss that part, but scenario 3 is not the only place I'd run it, depending on the situation.Mon, 08 Feb 2010 07:42:42 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxA suspect DB has to be set to Emergency mode before CheckDB can be run. There's a brief (one sentence) mention of running CheckDB in Scenario 3, right before the checkDB with repair. It should have been a lot clearer.Mon, 08 Feb 2010 07:32:15 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxI'm a little surprised that you're not recommending running CHECKDB on the database in question. Yes, it's marked as suspect, and yes, you might find a cause in the error log, but then again, you might not. Running a database consistency check will frequently identify the root cause. It might be something recoverable through other means than running repair with data loss, which is a very dangerous thing to do to a production system.Mon, 08 Feb 2010 07:22:39 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspx[quote]Possibility 1: Some one deleted/misplaced a data/log file when SQL Server was offline and the database can not start because of missing file. The solution is to place the missing data/log file in proper location. The SQL Server Error Log error message will give you the exact name and path of the missing file. Once you place the file execute below command to bring your database online with no data loss.RESTORE DATABASE WITH RECOVERYPossibility 2: SQL Server could not access or place an exclusive lock on the data or log file while coming online. Typically I experience this when SQL Server is shared with some other tool (like Antivirus), which puts an exclusive lock on the data/log file. To resolve it, use process explorer and kill the file handler which placed lock on the file. You may want to involve your System Admins to get this step executed. Then execute below command and you will have your database online with no data loss:RESTORE DATABASE WITH RECOVERY[/quote]Sorry, but I am going to completely, 100% disagree with you. RESTORE DATABASE <DB Name> WITH RECOVERY is what you run if your database is in a RESTORING state because an earlier backup was restored with NORECOVERY. It is not used to bring a database out of the suspect state.I did a quick test. Created a DB, shut SQL down, renamed the data file and restarted SQL. The DB came up in the RECOVERY PENDING state (not suspect). I then followed your instructions, renamed the file correctly and ran the RESTORE DATBASE statement. RESTORE DATABASE SuspectDB WITH RECOVERY[color="#FF0000"]Msg 3148, Level 16, State 3, Line 1This RESTORE statement is invalid in the current context. The 'Recover Data Only' option is only defined for secondary filegroups when the database is in an online state. When the database is in an offline state filegroups cannot be specified.Msg 3013, Level 16, State 1, Line 1RESTORE DATABASE is terminating abnormally.[/color]The correct solution, when a file has been moved or was locked by some other app when SQL started, is to rectify the root cause first (put the file back, remove whatever was locking it), then take the DB offline and bring it back online (or restart the SQL Service). That will allow SQL to open the DB again, this time find all the files and run the restart_recovery again this successfully.This will work if the DB state is RECOVERY PENDING (meaning that restart-recovery has not started due to missing or inaccessible files). If the DB state is truly suspect, it means there's a problem in the data file or log file, the restart recovery started (so all files are accessible) but could not complete. That's a lot more severe than just a missing file and usually indicates corruption of the data/log that was encountered during the restart-recovery.One additional note on Emergency mode repair. It's a last resort. If it fails, there's nothing else that can be done.Mon, 08 Feb 2010 07:08:36 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxAnother possible issue/solution, probably under possibility 1:I get a lot of SAN detatch errors from a certain iSCSI SAN. The SAN Drives will drop, and reattach. Fortunately, the Windows OS sees the drives as being back but once SQL Server looses the connection, there is no reconnect. These will show up as suspect databases (multiple). Solution so far (and I have been lucky) is simply restart the SQL Service. Usually shows up as a 9002 error in the error log.Mon, 08 Feb 2010 06:47:03 GMTsjimmohttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxPaul S. Randal is the definitive source on Database Corruption and recovering corrupt databases. Check him out at http://www.sqlskills.com/BLOGS/PAUL/category/CHECKDB-From-Every-Angle.aspx He wrote DBCC CHECKDB for Mircosoft. A lot of things in this article and a whole lot more is in his site....Mon, 08 Feb 2010 05:11:16 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxVery helpful arcticle..thanks a lot. Wish I should not come across this situation. :-)Mon, 08 Feb 2010 02:23:11 GMTjshailendrahttp://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxWell thats a really helping things to bring the Database Online. But before going to perform the thrid step I would like to go for DBCC DBRECOVER(DBNAME) command. Also after setting the Database in emergency do not forget to execute the DBCC Checkdb command, this will give what are the objects or transcations having the problem. Then in the end go for DBCC CHECKDB with allowloss option.:-)Mon, 08 Feb 2010 02:06:34 GMTprasad2085http://www.sqlservercentral.com/Forums/Topic861264-2613-1.aspxGood article - To the Point.I had a problem of SUSPECTED Database few years back (SQL2000). I updated the status in sysdatabases, and the problem never reoccured.ThanksB.K.PrasadMon, 08 Feb 2010 01:56:01 GMTbijoy.prasad