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

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

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

　　PHYSICAL_ONLY

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

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

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

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

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

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

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