Ⅰ sql2000backup database不能用於緊急模式打開的資料庫
資料庫置疑後，你執行語句修復時需要將資料庫設為緊急模式，也許你用的是復制過來的語句自己並不清楚，只要將資料庫緊急模式取消就好了！在master表中執行語句取消緊急模式 update sysdatabases set status= 0 where name='你的庫名'
Ⅱ 什麼方法可以修復SQL server資料庫
SQL Server 2000資料庫LDF損壞,只有mdf的恢復方法。
SQL Server 2000資料庫文件遭到破壞的現象經常出現，資料庫出錯是否可以修復呢？答案是可以的，本日誌以一個sql server 2000資料庫，資料庫日誌文件ldf損壞了，mdf正常，資料庫附加失敗的修復方法總結一下，資料庫數據恢復在很多時候比較復雜，當資料庫存在大量錯誤的時候，使用DBCC修復也是不可以的，需要拆解資料庫來搶救重要的數據，下面是較為常見的一種SQL Server 2000資料庫修復方式：
1） 先及時把原來的資料庫文件（如test.mdf)備份到其他地方。
2） 停掉伺服器。
3） 刪除這個test.mdf。
4) 重新建立一個test同名資料庫。
5） 刪除這個新建立的test資料庫的test.ldf文件，並用開始備份好test.mdf文件覆蓋這個新建立的test.mdf文件。
6） 啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。
.設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」。
7） 設置test為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀\置疑\離線\緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表
8） 下面執行真正的恢復操作，重建資料庫日誌文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
執行過程中，如果遇到下列提示信息：
伺服器: 消息 5030，級別 16，狀態 1，行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
說明您的其他程序正在使用該資料庫，如果剛才您在操作中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。
9） 驗證資料庫一致性
dbcc checkdb('test')
10.設置資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。
11）最後一步，我們要將步驟6中設置的「允許對系統目錄直接修改」一項恢復；
Ⅲ sql2005資料庫緊急模式怎麼恢復
1、使資料庫變為單用戶模式 ALTER DATABASE 資料庫名 SET SINGLE_USER （當變成單用戶的模式只能在同一個窗口執行語句） 2、修正資料庫日誌重新生成，此命令檢查的分配，結構，邏輯完整性和所有資料庫中的對象不正確
Ⅳ 如何解決資料庫是緊急狀態
SQL資料庫修復 資料庫緊急狀態解決方法(2007-12-29 12:23:39)標簽：it1、USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGO2、UPDATE SYSDATABASES SET STATUS =-32768 WHERE NAME='twhis'Go3、sp_dboption 'twhis', 'single user', 'true' --設置為單用戶模式Go4、 update sysdatabases set status =28 where name='twhis'Go5、dbcc rebuild_log('twhis','D:\Program Files\Microsoft SQL Server\MSSQL\Data\twhis_log.ldf') --重建日誌，需要把原先的日誌文件改名或者刪除go6、DBCC CHECKDB('twhis',REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGSGo7、sp_configure 'allow updates', 0 reconfigure with overrideGo8、--修復數據表use twhisdeclare @dbname varchar(255) set @dbname='twhis' exec sp_dboption @dbname,'single user','true' dbcc checktable('mzmxz',REPAIR_ALLOW_DATA_LOSS) dbcc checktable('mzmxz',REPAIR_REBUILD) ------把』 需要修復的數據表的名稱』更改為執行DBCC CHECKDB時報錯的數據表的名稱 exec sp_dboption @dbname,'single user','false' sp_dboption 'twhis', 'single user', 'false'Go9、sp_dboption 'twhis', 'dbo use', 'false' sp_dboption 'twhis', 'single user', 'true' DBCC CHECKDB('twhis',REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS DBCC CHECKDB('twhis',REPAIR_rebuild) ===================================
Ⅳ 如何修復 SQL 資料庫置疑
修復sql2000資料庫置疑
在實際的操作中由於突然斷電或者突然斷網造成資料庫置疑（在企業管理器中資料庫後面出現置疑兩個字），下面我們通過以下方法來進行修復置疑的資料庫。
A．我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
B.停掉資料庫伺服器。
C. 將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的資料庫數據文件test_data.mdf。
D. 啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。
E. 設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F.設置test為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀\置疑\離線\緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表
G.下面執行真正的恢復操作，重建資料庫日誌文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
執行過程中，如果遇到下列提示信息：
伺服器: 消息 5030，級別 16，狀態 1，行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。
H.驗證資料庫一致性（可省略）
dbcc checkdb('test')
一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
I.設置資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。
J.最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
Ⅵ sql server2008怎麼修復
1、修改資料庫為緊急模式ALTER DATABASE Stock SET EMERGENCY
2、使資料庫變為單用戶模式ALTER DATABASE Stock SET SINGLE_USER
3、修復資料庫日誌重新生成，此命令檢查的分配，結構，邏輯完整性和所有資料庫中的對象錯誤。當您指定「REPAIR_ALLOW_DATA_LOSS」作為DBCC CHECKDB命令參數，該程序將檢查和修復報告的錯誤。但是，這些修復可能會導致一些數據丟失。DBCC CheckDB (Stock, REPAIR_ALLOW_DATA_LOSS)
4、使資料庫變回為多用戶模式ALTER DATABASE Stock SET MULTI_USER1：重新建立一個，一樣的資料庫，路徑名稱，文件都一樣哈！
Ⅶ sql2000資料庫緊急模式如何恢復
你說的sql
2000
他的儲存文件是
ldf
和
mdf
為後綴的文件名.
一般是
mdf
是主文件..相當的大.
你發的這個
應該不是
sql
2000的資料庫文件..我猜應該是access
或類似的小弄的資料庫的文件
.
Ⅷ 創建一個新的SQL資料庫，如何設置其屬性當中的恢復模式默認為「完整」而不是「簡單」
--設置恢復模式（'SIMPLE'表示簡單；'FULL'表示完整）
ALTER DATABASE 庫名 SET RECOVERY FULL
Ⅸ 講SQL Server資料庫的幾種恢復模式
恢復模式說明了工作丟失的風險，能否恢復到時點? SQL Server資料庫有三種恢復模式：簡單恢復模式、完整恢復模式和大容量日誌恢復模式。 相對於簡單恢復模式而言，完整恢復模式和大容量日誌恢復模式提供了更強的數據保護功能。這些恢復模式都是基於備份事務日誌來提供完整的可恢復性及在最大范圍的故障情形內防止丟失工作。通常，資料庫使用完整恢復模式或簡單恢復模式。 下面對三種恢復模式做一個比較： 恢復模式 日誌備份 恢復點 優點 缺點 解決方案及建議 簡單(Simple) 無日誌備份。 自動回收日誌空間以減少空間需求，實際上不再需要管理事務日誌空間。 最新備份之後的更改不受保護。在發生災難時，這些更改必須重做。只能恢復到備份的結尾。 簡單恢復模式可最大程度地減少事務日誌的管理開銷，因為不備份事務日誌。 如果資料庫損壞，則簡單恢復模式將面臨極大的工作丟失風險。數據只能恢復到已丟失數據的最新備份。 在簡單恢復模式下，備份間隔應盡可能短，以防止大量丟失數據。簡單恢復模式並不適合生產系統，因為對生產系統而言，丟失最新的更改是無法接受的。在這種情況下，我們建議使用完整恢復模式。 完整(Full) 需要日誌備份。 理論上可以恢復到任意時點。 數據文件丟失或損壞不會導致丟失工作。 此模式完整記錄所有事務，佔用大量空間。 大容量(Bulk-logged) 需要日誌備份。 如果在最新日誌備份後發生日誌損壞或執行大容量日誌記錄操作，則必須重做自該上次備份之後所做的更改。 可以恢復到任何備份的結尾。不支持時點恢復。 該模式是完整恢復模式的附加模式，允許執行高性能的大容量復制操作。通過使用最小方式記錄大多數大容量操作，減少日誌空間使用量。 比完整模式節省日誌存儲空間。 對於某些大規模大容量操作(如大容量導入或索引創建)，暫時切換到大容量日誌恢復模式可提高性能並減少日誌空間使用量。由於大容量日誌恢復模式不支持時點恢復，因此必須在增大日誌備份與增加工作丟失風險之間進行權衡。 注意： 1. 適合於資料庫的恢復模式取決於資料庫的可用性和恢復要求。 2. 在完整恢復模式和大容量日誌恢復模式下，必須進行日誌備份。
Ⅹ SQL2008中三種恢復模式的區別在哪裡
SQL Server資料庫有三種恢復模式：簡單恢復模式、完整恢復模式和大容量日誌恢復模式。
Simple 簡單恢復模式,
Simple模式的舊稱叫」Checkpoint with truncate log「，其實這個名字更形象，在Simple模式下，SQL Server會在每次checkpoint或backup之後自動截斷log，也就是丟棄所有的inactive log records，僅保留用於實例啟動時自動發生的instance recovery所需的少量log，這樣做的好處是log文件非常小，不需要DBA去維護、備份log，但壞處也是顯而易見的，就是一旦資料庫出現異常，需要恢復時，最多隻能恢復到上一次的備份，無法恢復到最近可用狀態，因為log丟失了。
Simple模式主要用於非critical的業務，比如開發庫和測試庫，但是道富這邊的SQL Server（即使是生產庫）大都採用Simple模式，是因為這邊的SQL Server大都用於非critical的業務（critical的資料庫大都採用Oracle和DB2)，可以忍受少於1天的數據丟失(我們的job每天都會定時備份全庫）。Full 完整恢復模式,
和Simple模式相反，Full模式的舊稱叫」Checkpoint without truncate log「，也就是SQL Server不主動截斷log，只有備份log之後，才可以截斷log，否則log文件會一直增大，直到撐爆硬碟，因此需要部署一個job定時備份log。Full的好處是可以做point-in-time恢復，最大限度的保證數據不丟失，一般用於critical的業務環境里。缺點就是DBA需要維護log，增加人員成本（其實也就是多了定時備份log這項工作而已）。
Bulk-logged 大容量日誌恢復
Bulk-logged模式和full模式類似，唯一的不同是針對以下Bulk操作，會產生盡量少的log：
1) Bulk load operations (bcp and BULK INSERT).
2) SELECT INTO.
3) Create/drop/rebuild index
眾所周知，通常bulk操作會產生大量的log，對SQL Server的性能有較大影響，bulk-logged模式的作用就在於降低這種性能影響，並防止log文件過分增長，但是它的問題是無法point-in-time恢復到包含bulk-logged record的這段時間。
Bulk-logged模式的最佳實踐方案是在做bulk操作之前切換到bulk-logged，在bulk操作結束之後馬上切換回full模式。