在沒有數據庫日志的情況下數據的恢復:
由于誤刪的事務日志文件，導致數據庫無法啟動（置疑狀態），數據無法取去，
方法：
新建一個同名數據庫，把數據文件copy覆蓋
打開系統表的操作權限
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
設置成為緊急狀態
update sysdatabases set status = 32768 where name = 'databaseName'
然后刷新一下數據庫
變成了緊急狀態
然后再
update sysdatabases set status =26 where name = ''databaseName''
然后刷新一個數據庫
一般情況下就應該可以了。
http://www.itpub.net/showthread.php?s=&threadid=32011&highlight=%C8%D5%D6%BE%CE%C4%BC%
太興奮了,我的數據終于找回來了
數據庫被置疑的解決辦法 一:
在MS SQLSERVER中一直有這樣的問題,SQLSERVER的狀態"置疑",我們先來分析一下SQLSERVER數據庫"置疑"的原因:
1.錯誤的刪除日志;
2.硬件(HD)損壞,造成日志和數據文件寫錯誤;
3.硬盤的空間不夠,比如日志文件過大;
解決辦法:
這是最簡單的辦法是有數據庫的全備份,然后恢復即可.
步驟:
1. 刪除原始的數據庫:
USE MASTER
GO
DROP DATABASE DB_SUEPECT
2.建立同名的數據庫:
USE master
GO
CREATE DATABASE DB_SUSPECT
ON
( NAME = DBNAME_DAT,
FILENAME = 'C:',
SIZE = 10,
FILEGROWTH = 5 )
LOG ON
( NAME = 'DBNAME_LOG',
FILENAME = 'g:',
SIZE = 5MB,
FILEGROWTH = 5MB )
GO
3.恢復數據庫:
RESTORE DATABASE DB_SUSPECT
FROM DBNAME_BACKUP.DAT
4.數據庫完整性檢測:
DBCC CHECKDB('DB_SUSPECT')
5.重新啟動MSSQLSERVER服務.
如果沒有全備份,那就要用一些特殊的方法:
1.設置數據庫為緊急模式
Use Master
GO
sp_configure 'allow updates', 1
reconfigure with override
GO
UPDATE sysdatabases SET status = 32768 where name = 'DB_SUSPECT'
GO
2.停掉SQL Server服務:.Net STOP MSSQLSERVER
3.把原始數據庫的數據文件DBNAME_DAT.MDF,DBNAME_LOG.LDF移走:
4.啟動SQL Server服務:.Net START MSSQLSERVER
5.重新建立一個同名的數據庫DB_SUSPECT；
USE master
GO
CREATE DATABASE DB_SUSPECT
ON
( NAME = DBNAME_DAT,
FILENAME = 'C:',
SIZE = 10,
FILEGROWTH = 5 )
LOG ON
( NAME = 'DBNAME_LOG',
FILENAME = 'g:',
SIZE = 5MB,
FILEGROWTH = 5MB )
GO
6.設置數據庫運行在單用戶的模式:
USE MASTER
GO
ALTER DATABASE DB_SUSPECT SET SINGLE_USER
GO
7.停掉SQL服務:.Net STOP MSSQLSERVER
8.把原來的數據文件再覆蓋回來:
9.啟動SQL Server服務:.Net START MSSQLSERVER
10.重新設置SQLSERVER的狀態:
USE MASTER
GO
EXEC sp_resetstatus "DB_SUSPECT"
11.數據庫完整性檢測:
DBCC CHECKDB('DB_SUSPECT')
12.恢復數據庫為多用戶模式:
USE MASTER
GO
ALTER DATABASE DB_SUSPECT SET MULTI_USER
GO
13.恢復SQLSERVER原始的配置:
USE MATER
GO
UPDATE sysdatabases SET status = 4194320 where name = 'DB_SUSPECT'
GO
14.配置SQLSERVER不允許更新系統表:
USE MASTER
GO
sp_configure 'allow updates', 0
reconfigure with override
GO
15.重新啟動MSSQLSERVER服務:
最好重新啟動操作系統
16.備份數據庫:
可以通過SQLSERVER企業管理器或T-SQL.需要備份MASTER和DB_SUSPECT
補充一點，如果用DOMAIN\USER時,要注意對.MDF.LDF的所在目錄的權限.
Zach的靈驗腳本
Zach說他每次遇到這種數據庫置疑情況，就運行下面這個腳本，屢試不爽：
======================================================
--before running any script, run the following to set the
master database to allow updates
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
--Run the following script
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = 'Database_Name'
--Run the following script
exec SP_resetstatus Database_Name
--stop and start the MSDTC at this stage
--After the procedure is created, immediately disable
updates to the system tables:
exec sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
=====================================
該文章轉載自網絡大本營： http://www.xrss.cn/Info/7753.Html
數據庫被置疑的解決辦法方法二:
SQL Server數據庫多數據文件恢復技術
由于截斷數據庫日志或者其他需要，我們需要由單個數據文件中恢復數據庫。下面的操作需要用sa的身份在SQL Server 查詢分析器中登錄，并一直假設我們要恢復的數據庫是test，數據文件是C:\Program Files\Microsoft SQL Server\MSSQL\data\test_data.mdf。同時如果你需要截斷日志文件，請在數據庫脫機后將日志文件改名。
如果您的mdf文件是當前數據庫產生的并且是單個數據日志的，那么一般情況下你可以很輕松的使用sp_attach_single_file_db恢復數據庫，操作語句如下：
sp_attach_single_file_db @dbname = ’test’, @physname = ’C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf’
會出現類似下面的提示信息
設備激活錯誤。物理文件名 ’C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF’ 可能有誤。
已創建名為 ’C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF’ 的新日志文件。
如果目的是截斷日志，你可以將剛才改名的日志文件刪除或者備份了。
但是，如果您的數據庫文件是從其他計算機上復制過來的或者有多個數據或日志文件，那么很不幸，上述辦法多半行不通了。你也許會得到類似下面的錯誤信息
服務器: 消息 1813，級別 16，狀態 2，行 1
未能打開新數據庫 ’test’。CREATE DATABASE 將終止。
設備激活錯誤。物理文件名 ’C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF’ 可能有誤。
我們需要用下面的操作來試著恢復（此操作具有很大的危險性，請確認在操作時您的數據庫不在使用中）。
我們使用默認方式建立一個供恢復使用的數據庫(如test)。如果是多數據文件的，請確認新建數據文件的名稱及數目和要恢復的數據文件一致。日志文件就不必了；
停掉數據庫服務器；
將剛才生成的數據庫的日志文件test_log.ldf刪除，用要恢復的數據庫mdf文件覆蓋剛才生成的數據庫數據文件test_data.mdf；
啟動數據庫服務器。此時會看到數據庫test的狀態為“置疑”；
設置數據庫允許直接操作系統表。在SQL Server 企業管理器里面選擇數據庫服務器，按右鍵，選擇“屬性”，在“服務器設置”頁面中將“允許對系統目錄直接修改”一項選中；
設置test為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID(’test’)
此時可以在SQL Server 企業管理器里面看到該數據庫處于“只讀\置疑\脫機\緊急模式”可以看到數據庫里面的表，但是僅僅有系統表；
下面重建數據庫日志文件
dbcc rebuild_log(’test’,’C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf’)
執行過程中，如果遇到下列提示信息：
服務器: 消息 5030，級別 16，狀態 1，行 1
未能排它地鎖定數據庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
說明其他程序正在使用該數據庫，如果您正在使用SQL Server 企業管理器，那么關閉它。
正確執行完成的提示應該類似于：
警告: 數據庫 ’test’ 的日志已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置數據庫選項，并且可能需要刪除多余的日志文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server 企業管理器里面會看到數據庫的狀態為“只供DBO使用”；
驗證數據庫一致性（可省略）
dbcc checkdb(’test’)
在進行了多個驗證后，最后的執行結果一般如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在數據庫 ’test’ 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系；
設置數據庫為正常狀態
sp_dboption ’test’,’dbo use only’,’false’
如果沒有出錯，那么恭喜，現在就可以正常的使用恢復后的數據庫啦；
最后一步，我們要將步驟5中設置的“允許對系統目錄直接修改”一項恢復。在SQL Server 企業管理器里面選擇數據庫服務器，按右鍵，選擇“屬性”，取消在“服務器設置”頁面中將“允許對系統目錄直接修改”的選擇。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1425440