下面，我們來舉一個(gè)例子說明SQL Server 2000的修復(fù)實(shí)踐。

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個(gè)參數(shù):

　　REPAIR_ALLOW_DATA_LOSS

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

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

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

　　PHYSICAL_ONLY

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

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

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

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

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

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

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