Re: Suspect

Tech-Archive recommends: Fix windows errors by optimizing your registry

But the question is, why would it need to sync with the Log files? I set the databases to full. Also, there has been no activity on these databases so there shouldn't be any records in the tran logs to get unsynced.

A database consists of two or more files. These files need to be from a consistent point in time. This is just how the product work, and there is plenty of information in Books Online etc on this. This is just how the product work. SQL server perform system stuff in the background, so even if you didn't do any operations, there are checkpoint and other things going on.

The error sounds to me like the files (mdf vs ldf) are from different points in time. But that is, again, just a guess. I wasn't present when whatever operations was performed to render the database suspect, which is why I have to guess.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"tshad" <toms@xxxxxxxx> wrote in message news:uVVhQn81JHA.3988@xxxxxxxxxxxxxxxxxxxxxxx
But the question is, why would it need to sync with the Log files? I set the databases to full. Also, there has been no activity on these databases so there shouldn't be any records in the tran logs to get unsynced.

The mdf files are still there, so is there a way to just use them? Possibly detach and reattach?

Would there be a way to tell the system to ignore the Tran Logs?

There are not production databases but development databases.

I do know that the CheckDB was done according to the logs and there were no errors, as you can see.

but when I try to run it now I get:

Msg 926, Level 14, State 1, Line 1
Database 'UCLAExtensionECARSDEV' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information

Thanks,

Tom

"Tibor Karaszi" <tibor_please.no.email_karaszi@xxxxxxxxxxxxxxxxxx> wrote in message news:O2EJ3k41JHA.1420@xxxxxxxxxxxxxxxxxxxxxxx
I'm sorry but there's not much we can do at this end. Something has happened and the ldf files for each database do no longer sync with the mdf files. Perhaps the ldf files were altered in some way, or perhaps you got the file sets from different point in time? But the error message is clear. If you can't work out what happened that caused the un-sync state and revert that operation, then it is likely you are in for a restore. Or, as mentioned, hire help or open case with MS Support...

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"tshad" <toms@xxxxxxxx> wrote in message news:%23ZM9Ra41JHA.4944@xxxxxxxxxxxxxxxxxxxxxxx
I assume that the databases are not actually corrupted as we have 10 databases and they are all giving us the message. It wouldn't make any sense that there would be a problem with all of them.

Tom

"tshad" <toms@xxxxxxxx> wrote in message news:OFbTRP41JHA.5896@xxxxxxxxxxxxxxxxxxxxxxx
Well, does mention a possible problem with the log file not matching the data file.

What would cause that, if in fact that is the reason?

Thanks,

Tom

"Tibor Karaszi" <tibor_please.no.email_karaszi@xxxxxxxxxxxxxxxxxx> wrote in message news:OzCemr31JHA.4272@xxxxxxxxxxxxxxxxxxxxxxx
Changing recovery models do not cause these types of problems. Resizing the disks probably did (but of course we can't say for sure since we didn't perform the operations nor do we have access to the system). You can work the errorlog files and through the error messages try to determine what happened. My guess is that you are in for a restore operation for each database. However, considering hiring a consultant who did this type of work before or opening a case with MS Support. I would not have much hope, though, I'm afraid.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"tshad" <toms@xxxxxxxx> wrote in message news:%23wajBf31JHA.140@xxxxxxxxxxxxxxxxxxxxxxx
On Sql Server 2008, we have all our user databases showing as (Suspect) under Database Snapshots instead of Databases.

We just had our disks resized on our vitual server and all the system databases seemed to come up fine. But tnot the User Databases.

The system is trying to connect but we keep getting:

05/17/2009 19:52:35,Logon,Unknown,Login failed for user 'NT AUTHORITY\SYSTEM'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
05/17/2009 19:52:35,Logon,Unknown,Error: 18456<c/> Severity: 14<c/> State: 38.
05/17/2009 19:51:35,Logon,Unknown,Login failed for user 'NT AUTHORITY\SYSTEM'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
05/17/2009 19:51:35,Logon,Unknown,Error: 18456<c/> Severity: 14<c/> State: 38.

and further down we are getting for all our databases:

05/17/2009 17:22:25,spid19s,Unknown,CHECKDB for database 'RPT' finished without errors on 2009-05-12 07:55:33.320 (local time). This is an informational message only; no user action is required.
05/17/2009 17:22:25,spid19s,Unknown,An error occurred during recovery<c/> preventing the database 'RPT' (database ID 14) from restarting. Diagnose the recovery errors and fix them<c/> or restore from a known good backup. If errors are not corrected or expected<c/> contact Technical Support.
05/17/2009 17:22:25,spid19s,Unknown,Error: 3414<c/> Severity: 21<c/> State: 1.
05/17/2009 17:22:25,spid19s,Unknown,The log scan number (9830:422:1) passed to log scan in database 'RPT' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication<c/> re-create the publication. Otherwise<c/> restore from backup if the problem results in a failure during startup.
05/17/2009 17:22:25,spid19s,Unknown,Error: 9003<c/> Severity: 20<c/> State: 1.

Earlier (Friday) I had change some of the databases to Simple Recovery from Full as we don't really need the Log backups. We don't use replication on these databases.

Could this have something to do with it?

Thanks,

Tom










.

Relevant Pages

  • Create indexes - own File Group
    ... on their own logical raid groups. ... My databases are SIMPLE, so they dont use much, if any logs (none as I ... SQL Server 2005 Enterprise x64 SP2 ...
    (comp.databases.ms-sqlserver)
  • Re: Question about Exchange Logs and DBs Best Practice
    ... Yes, even from 5.5 days, the primary reason you separate logs from databases ... For Exchange news, links and tips, check: ... > If you put ALL the databases in one RAID set, then if that one RAID set ...
    (microsoft.public.exchange2000.admin)
  • Re: Checkpointing Not Happening in Simple Recovery Model
    ... Columnist, SQL Server Professional ... > "Daniel Joskovski" wrote in message ... > Yes, you are right, I read that Michelle is writing about logs not log, is ... >>> We have at least two databases on this server in simple recovery ...
    (microsoft.public.sqlserver.server)
  • Re: Disk Partitioning/RAID recommendations
    ... Probably the best thing you can do is to separate the databases and logs ... However, you may be tight for space on the mirror this way, so you could ... Repartitioning drives as we move from Exchange 2000 to ...
    (microsoft.public.exchange2000.setup.installation)
  • Re: E2K7 SP1 Configuring Storage
    ... So any info you can provide on how NetApp has their databases or storage ... One Volume has one LUN in it and one database inside that LUN. ... Put the SNAPINFO on the same LUN as the transaction logs. ... talk to NetApp about your aggregates. ...
    (microsoft.public.exchange.setup)