下面，我們來舉一個例子說明SQL Server 2000的修復實踐。

ALTER DATABASE POS_DB SET SINGL_USER

GO

DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK

GO

ALTER DATABASE POS_DB SET MULTI_USER

GO

　　CHECKDB 有3個參數(shù):

　　REPAIR_ALLOW_DATA_LOSS

　　執(zhí)行由 REPAIR_REBUILD 完成的所有修復，包括對行和頁進行分配和取消分配以改正分配錯誤、結構行或頁的錯誤，以及刪除已損壞的文本對象。這些修復可能會導致一些數(shù)據(jù)丟失。修復操作可以在用戶事務下完成以允許用戶回滾所做的更改。如果回滾修復，則數(shù)據(jù)庫仍會含有錯誤，應該從備份進行恢復。如果由于所提供修復等級的緣故遺漏某個錯誤的修復，則將遺漏任何取決于該修復的修復。修復完成后，備份數(shù)據(jù)庫。

　　REPAIR_FAST 進行小的、不耗時的修復操作，如修復非聚集索引中的附加鍵。這些修復可以很快完成，并且不會有丟失數(shù)據(jù)的危險。

　　REPAIR_REBUILD 執(zhí)行由 REPAIR_FAST 完成的所有修復，包括需要較長時間的修復（如重建索引）。執(zhí)行這些修復時不會有丟失數(shù)據(jù)的危險。

　　PHYSICAL_ONLY

　　僅限于檢查頁和記錄標題物理結構的完整性，以及頁對象 ID 和索引 ID 與分配結構之間的一致性。該檢查旨在以較低的開銷檢查數(shù)據(jù)庫的物理一致性，同時還檢測會危及用戶數(shù)據(jù)安全的殘缺頁和常見的硬件故障。PHYSICAL_ONLY 始終意味著 NO_INFOMSGS，并且不能與任何修復選項一起使用。

　　1.RAID5并不能保證SQLSERVER 2000 數(shù)據(jù)庫的數(shù)據(jù)文件的完整性；

　　2.SQLERVER 2000的備份程序不驗證數(shù)據(jù)庫文件的數(shù)據(jù)完整性；如果你的數(shù)據(jù)文件有問題，備份時也不圖示；

　　3.DBCC CHECKDB的repair_allow_data_loss并不是非常安全的，不能修復所有的錯誤，即使是對不完整頁（TORN PAGE）的修復也會著成數(shù)據(jù)丟失；

　　4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS參數(shù)無法修復所有的錯誤

標簽： 安全 數(shù)據(jù)庫 問題 用戶

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。