Sql server 数据库 疑似标记？

Question

我的 sql server 将一个数据库标记为可疑，在检查时我发现我的 mdf、ldf 文件丢失，但 chkdsk 没有错误，这意味着某种病毒？

Answer 1

http://support.microsoft.com/kb/180500

At startup, SQL Server attempts to obtain an exclusive lock on the device file. If the device is being used by another process (for example, backup software) or if the file is missing , the scenario described above will be encountered. In these cases, there is usually nothing wrong with the devices and database. For the database to recover correctly, the device must be made available, and the database status must be reset .

Answer 2

It means someone deleted the files.

They can not be deleted when in use so it happened:

• when SQL Server was shut down
• the database was closed (Express version usually)
• the database was taken offline

All user dbs will share the same folder (edit) by default (end edit) so this is deliberate

The more exotic options include restoring the master db where the databases/MDF files listed in the restored master db do not exist etc. But I doubt it.

Answer 3

Either the files were deleted, or they have been moved and a master database backup restored from before the change in location. In both cases the physical files can only be deleted or moved if the database is offline - either because sql server was shut down or the database was closed.

Either of these things is highly unlikely to have happened accidentally. It's unlikely to be a generic virus or trojan as such would either have to specifically delete the files on startup before SQL Server started (assuming your database starts automatically) or shut down the database then specifically delete the files. Given that chkdsk doesn't report errors either it's unlikely to be a disk issue, so it's a virtual certainty that the cause of the error is deliberate database (mis)management.

I think the most likely option is that a dba has decided that the files should be moved elsewhere - typically this is done for space or performance reasons - for instance if a new drive is added to a machine that is running out of space then the database could be moved to that. For some reason a backup of the master database has subsequently been restored from a point before the move.

My first action would be to do a full scan of the system for all mdf/ldf files and (hopefully) locate them. I'd also do a scan of backups and look for the latest master database backup. You could either then try restoring the last master backup and see if that fixed the issue (i'd back up the current master first of course), and failing that, or directly, reattach the missing files.

If you cannot find the mdf/ldf files then your only option is restore from backup. If you don't have a backup then your database is lost.

Answer 4

In SQL Server suspect database is a mode when user unable to connect with database. At this time user unable to perform any action and can not do anything like no open no backup and no restore etc.

Possible cause for this problem can be one of the following: 1. Database is corrupted 2. Insufficient memory state. 3. unexpected shutdown etc. 4. OS is unable to find the database file

Answer 5

In this situation, you can check the SQL Server logs. Go to Management, Click on SQL Server Logs and click on current and check the message.

In my case, I got this: Error 17207, severity 16, state 1 (it is related to log file deletion or corruption)

Solution:

Set the database into single user mode:

Alter database dbname set single_user

Now set the database into emergency mode:

Alter database dbname set emergency

Repair missing log file or corrupted log file with data loss.

DBCC CHECKDB ('dbname', REAPIR_ALLOW_DATA_LOSS)

Note: You may loss the data by using this command. It also depends on client's approval.

Now set the db in multi user mode;

alter database dbname set multi_user