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

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

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

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

3、行完畢后報(bào)告有錯(cuò)。在報(bào)告開頭附近就有兩行紅字如下：張金玉的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ù)隊(duì)列:3。ServiceBroker消息9669，狀態(tài)1:已分析的會(huì)話端點(diǎn):0。ServiceBroker消息9674，狀態(tài)1:已分析的會(huì)話組:0。ServiceBroker消息9670，狀態(tài)1:已分析

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

5、IXED_EXTALLOCATED0_PCT_FULL'。CHECKDB發(fā)現(xiàn)有2個(gè)分配錯(cuò)誤和0個(gè)一致性錯(cuò)誤與任何單個(gè)的對(duì)象都沒有關(guān)聯(lián)?！趫?bào)告的末尾處有總結(jié)如下：CHECKDB在數(shù)據(jù)庫'張金玉'中發(fā)現(xiàn)2個(gè)分配錯(cuò)誤和0個(gè)一致性錯(cuò)誤。對(duì)于由DBCCCHECKDB(張金玉)發(fā)現(xiàn)的錯(cuò)誤，repair_allow_data_loss是最低的修復(fù)級(jí)別。DBCC執(zhí)行完畢。如果DBCC輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。好像是建議使用“DBCCCHECKDB”的repair_allow_data_loss參數(shù)修復(fù)。那么在查詢選項(xiàng)卡中運(yùn)行“DB

6、CCCHECKDB(張金玉,repair_allow_data_loss)”。但是，一運(yùn)行就報(bào)錯(cuò)。原因是修復(fù)數(shù)據(jù)庫時(shí)，該數(shù)據(jù)庫需要設(shè)置成“單用戶”狀態(tài)。將數(shù)據(jù)庫屬性的“選項(xiàng)”→“狀態(tài)”→“限制訪問”設(shè)置成“SINGLE_USER”，使其變成單用戶。設(shè)置成單用戶之后立即再運(yùn)行“DBCCCHECKDB(張金玉,repair_allow_data_loss)”。但是仍然報(bào)錯(cuò)。然而，退出“SQLServerManagementStudio”再重新啟動(dòng)“SQLServerManagementStudio”后再運(yùn)行“DBCCCHECKDB(張金玉,

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

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