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