sqlserver數(shù)據(jù)庫無法收縮問題

《sqlserver數(shù)據(jù)庫無法收縮問題》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、MSSQLServer數(shù)據(jù)庫無法收縮的處理辦法一.數(shù)據(jù)庫數(shù)據(jù)文件無法收縮的情況在MSSQLServer2008中有一個叫做“張金玉”的數(shù)據(jù)庫。想把他收縮一下。進入“SQLServerManagementStudio”，使用“數(shù)據(jù)庫”→“張金玉”鼠標(biāo)右鍵菜單中的“任務(wù)”→“收縮”→“文件”菜單項，彈出一個“收縮文件”窗口，如下圖。在這個窗口中可以看到“當(dāng)前分配的空間”為31236.00MB，“可用空間”為23341.81MB（74%）。可以縮小很多。選中窗口中的“在釋放未使用的空間前重新組織頁”單選按鈕，并將那個“將文件收縮到”

2、框框里面的值設(shè)為0（此處設(shè)為0在運行中會自動填入這個框框右邊的最小值—7825）。點擊“確定”按鈕，稍等片刻，這個窗口自動關(guān)閉，表示已經(jīng)收縮完畢。但是，再次打開這個窗口看看，“當(dāng)前分配的空間”仍然是31236.00MB。換句話說，這個數(shù)據(jù)庫實際上并沒有收縮。換用其它的收縮方法，統(tǒng)統(tǒng)不能收縮。鑒于此種情況，考慮數(shù)據(jù)庫本身可能存在錯誤。試用“DBCCCHECKDB”檢查是否有誤。在“SQLServerManagementStudio”中新建一個查詢選項卡，先指定數(shù)據(jù)庫名稱為“張金玉”，然后執(zhí)行“DBCCCHECKDB”。執(zhí)行期間服

3、務(wù)器的硬盤燈常亮。執(zhí)行完畢后報告有錯。在報告開頭附近就有兩行紅字如下：張金玉的DBCC結(jié)果。ServiceBroker消息9675，狀態(tài)1:已分析的消息類型:14。ServiceBroker消息9676，狀態(tài)1:已分析的服務(wù)約定:6。ServiceBroker消息9667，狀態(tài)1:已分析的服務(wù):3。ServiceBroker消息9668，狀態(tài)1:已分析的服務(wù)隊列:3。ServiceBroker消息9669，狀態(tài)1:已分析的會話端點:0。ServiceBroker消息9674，狀態(tài)1:已分析的會話組:0。ServiceBroke

4、r消息9670，狀態(tài)1:已分析的遠程服務(wù)綁定:0。ServiceBroker消息9605，狀態(tài)1:已分析的會話優(yōu)先級:0。消息2576，級別16，狀態(tài)1，第1行索引分配映射(IAM)頁(1:3998207)(位于對象ID0，索引ID-1，分區(qū)ID0，分配單元ID332260034084864(類型為Unknown))的上一個指針指向了IAM頁(0:0)，但掃描過程中檢測不到它。消息8906，級別16，狀態(tài)1，第1行數(shù)據(jù)庫ID5中的頁(1:3998200)在SGAM(1:3578625)和PFS(1:3995472)中進行了分配

5、，但未在任何IAM中分配。PFS標(biāo)志'MIXED_EXTALLOCATED0_PCT_FULL'。CHECKDB發(fā)現(xiàn)有2個分配錯誤和0個一致性錯誤與任何單個的對象都沒有關(guān)聯(lián)?！趫蟾娴哪┪蔡幱锌偨Y(jié)如下：CHECKDB在數(shù)據(jù)庫'張金玉'中發(fā)現(xiàn)2個分配錯誤和0個一致性錯誤。對于由DBCCCHECKDB(張金玉)發(fā)現(xiàn)的錯誤，repair_allow_data_loss是最低的修復(fù)級別。DBCC執(zhí)行完畢。如果DBCC輸出了錯誤信息，請與系統(tǒng)管理員聯(lián)系。好像是建議使用“DBCCCHECKDB”的repair_allow_dat

6、a_loss參數(shù)修復(fù)。那么在查詢選項卡中運行“DBCCCHECKDB(張金玉,repair_allow_data_loss)”。但是，一運行就報錯。原因是修復(fù)數(shù)據(jù)庫時，該數(shù)據(jù)庫需要設(shè)置成“單用戶”狀態(tài)。將數(shù)據(jù)庫屬性的“選項”→“狀態(tài)”→“限制訪問”設(shè)置成“SINGLE_USER”，使其變成單用戶。設(shè)置成單用戶之后立即再運行“DBCCCHECKDB(張金玉,repair_allow_data_loss)”。但是仍然報錯。然而，退出“SQLServerManagementStudio”再重新啟動“SQLServerManageme

7、ntStudio”后再運行“DBCCCHECKDB(張金玉,repair_allow_data_loss)”就不報錯了。運行后的界面如下圖。從運行結(jié)果看，錯誤已經(jīng)被修復(fù)了。既然已經(jīng)修復(fù)了錯誤，那么就重新進行“收縮”。收縮后再使用“數(shù)據(jù)庫”→“張金玉”鼠標(biāo)右鍵菜單中的“任務(wù)”→“收縮”→“文件”菜單項，打開“收縮文件”窗口看看，情況如下圖。此時“當(dāng)前分配的空間”已經(jīng)變成了7895.00MB，說明收縮成功。下次再遇到不能“收縮”的情況時，首先要考慮數(shù)據(jù)庫內(nèi)部是否有錯?？梢韵戎苯邮褂谩癉BCCCHECKDB(張金玉,repair_a

8、llow_data_loss)”修復(fù)一下。修復(fù)后便可以順利收縮了。二.數(shù)據(jù)庫日志文件無法收縮的情況在MSSQLServer2008中有一個叫做“龐繼剛”的數(shù)據(jù)庫。在數(shù)據(jù)庫屬性中的“文件”中可以見到日志是3460MB。如下圖。而在數(shù)據(jù)庫屬性的“選項”中“恢復(fù)模式”是“完整”。如