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

1、MSSQLServer數(shù)據(jù)庫無法收縮的處理辦法.數(shù)據(jù)庫數(shù)據(jù)文件無法收縮的情況在MSSQLServer2008中有一個叫做“張金玉”的數(shù)據(jù)庫。想把他收縮一下。進入“SQLServerManagementStudio”，使用“數(shù)據(jù)庫”f“張金玉”鼠標右鍵菜單中的“任務”一“收縮”一“文件”菜單項，彈出一個“收縮文件”窗口，如下圖。在這個窗口中可以看到當前分配的空間”為31236.00MB,“可用空間”為23341.81MB(74%)。可以縮小很多。選中窗口中的“在釋放未使用的空間前重新組織頁”單選按鈕，并將那個“將文件收縮到”框框里面的值設為0(此處設為0在運行中會自動填入這個框框右邊的最小值一7

2、825)。點擊“確定”按鈕，稍等片刻，這個窗口自動關閉，表示已經(jīng)收縮完畢。但是，再次打開這個窗口看看，“當前分配的空間”仍然是31236.00MB。換句話說，這個數(shù)據(jù)庫實際上并沒有收縮。換用其它的收縮方法，統(tǒng)統(tǒng)不能收縮。鑒于此種情況，考慮數(shù)據(jù)庫本身可能存在錯誤。試用“DBCCCHECKDB”檢查是否有誤。在“SQLServerManagementStudio”中新建一個查詢選項卡，先指定數(shù)據(jù)庫名稱為“張金玉”，然后執(zhí)行“DBCCCHECKDB”。執(zhí)行期間服務器的硬盤燈常亮。執(zhí)行完畢后報告有錯。在報告開頭附近就有兩行紅字如下：ServiceBroker消息9675，狀態(tài)ServiceBroker

3、消息9676，狀態(tài)ServiceBroker消息9667，狀態(tài)ServiceBroker消息9668，狀態(tài)ServiceBroker消息9669，狀態(tài)ServiceBroker消息9674，狀態(tài)ServiceBroker消息9670，狀態(tài)ServiceBroker消息9605，狀態(tài)張金玉的DBCC結(jié)果。消息2576，級別16，狀態(tài)1，1:已分析的消息類型:14。1:已分析的服務約定:6。1:已分析的服務:3。1:已分析的服務隊列:3。1:已分析的會話端點:0。1:已分析的會話組:0。1:已分析的遠程服務綁定:01:已分析的會話優(yōu)先級:0。1行索引分配映射(IAM)頁(1:3998207)(位于

4、對象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)中進行了分配,但未在任何IAM中分配。PFS標志MIXED_EXTALLOCATED0_PCT_FULL。CHECKDB發(fā)現(xiàn)有2個分配錯誤和0個一致性錯誤與任何單個的對象都沒有關聯(lián)。在報告的末尾處有總結(jié)如下：CHECKDB在數(shù)據(jù)庫張金玉中發(fā)現(xiàn)2個分配錯誤和0個一致性錯誤。對于由DBCCCHEC

5、KDB(張金玉)發(fā)現(xiàn)的錯誤,repair_allow_data_loss是最低的修復級別。DBCC執(zhí)行完畢。如果DBCC輸出了錯誤信息,請與系統(tǒng)管理員聯(lián)系。好像是建議使用“DBCCCHECKDB”的repair_allow_data_loss參數(shù)修復。那么在查詢選項卡中運行“DBCCCHECKDB(張金玉,repair_allow_data_loss)”。但是，一運行就報錯。原因是修復數(shù)據(jù)庫時，該數(shù)據(jù)庫需要設置成“單用戶”狀態(tài)。將數(shù)據(jù)庫屬性的“選項”一“狀態(tài)”一“限制訪問”設置成“SINGLE_USER”，使其變成單用戶。設置成單用戶之后立即再運行“DBCCCHECKDB(張金玉,repair

6、_allow_data_loss)”。但是仍然報錯。然而，退出“SQLServerManagementStudio”再重新啟動“SQLServerManagementStudio”后再運行“DBCCCHECKDB(張金玉,repair_allow_data_loss)”就不報錯了。運行后的界面如下圖。立艸戟狗跆EiEflcfiiIE）啊皿Ifl-n甸口艦ttEt）裕肋也A確I*in山l泌慍缶漁口XYI辺孑血胡咤h!執(zhí)行叫好冒2Jr暫勵圖電|壬劉寧車|姑.iVt岳25JlJ1CljIm比1開能|密母少G旳|量檢査劉6厲出比3.|FExiE訟1SQLE.e.站野:旺書艮）（E巾從運行結(jié)果看，錯誤已

7、經(jīng)被修復了。既然已經(jīng)修復了錯誤，那么就重新進行“收縮”收縮后再使用“數(shù)據(jù)庫”一“張金玉”鼠標右鍵菜單中的“任務”f“收縮”f“文件”菜單項，打開“收縮文件”窗口看看，情況如下圖。此時“當前分配的空間”已經(jīng)變成了7895.00MB，說明收縮成功。下次再遇到不能“收縮”的情況時，首先要考慮數(shù)據(jù)庫內(nèi)部是否有錯。可以先直接使用“DBCCCHECKDB（張金玉,repair_allow_data_loss）”修復一下。修復后便可以順利收縮了。二.數(shù)據(jù)庫日志文件無法收縮的情況在MSSQLServer2008中有一個叫做“龐繼剛”的數(shù)據(jù)庫。在數(shù)據(jù)庫屬性中的“文件”中可以見到日志是3460MB。如下圖。T鞍按

8、宙圧村能曲削3曲本屜需助*姐跟馬規(guī)瞄件理取眼展百鯽文屈更積擴空空空空耳律一J?所有舌辺：IT曲用主立耒耳|Q)逼務若甬文件類型艾用a初聞大小射匚包St増悵踣徑氐祁“門閃疔劇gPBIWXSJLL6増星為】NB和Eftll増忙|.|d:iTyojt-iji卩皿匚出:TT詐EiMTi曰志不15用5460増量為10Z.峽的盤.|!：也rocraFil*1用呻數(shù)IE岸文件血務器：JHIBSqLEEFRES5逹接.JHI玳AdaixaxtrLtm-添加而在數(shù)據(jù)庫屬性的“選項”中“恢復模式”是“完整”。如下圖。這里的恢復模式”在MSSQLServer2000中文版中曾經(jīng)叫做故障還原模型”在SQLServer

9、2008英文版中叫做“Recovermodel”作用是指定數(shù)據(jù)庫被完全損壞時的修復方式。所謂完全損壞，通俗地說就是“徹底完蛋”的意思。實際上這里的“恢復模式”是指數(shù)據(jù)庫“徹底完蛋”時的“拯救”方式。在右邊的下拉中有三個選項：“完全”、“大容量日志的”、“簡單”當選用“完全”或“大容量日志的”時。完全損壞的數(shù)據(jù)庫可以利用“備份文件”（備份設備）還原到做備份時的狀態(tài)，并且可以再使用日志文件恢復到最后一次操作的狀態(tài)。前提條件是數(shù)據(jù)庫完全損壞了，而日志文件仍然完好無損。不過，這種情況是很難辦到的?？赡苄枰獙?shù)據(jù)庫存儲在“鏡像”方式等的環(huán)境之內(nèi)。這樣大概不用擔心數(shù)據(jù)庫完全損壞時日志也被破壞。話說回來，在這種環(huán)境中主存儲中的數(shù)據(jù)庫完全損壞時，鏡像中的那一套會仍然存在的，這樣一來就不必考慮“完全”或“大容量日志的”了。對于“簡單”方式只能恢復到做備份時的狀態(tài)。在“完全”或“大容量日