SQLServer数据库无法收缩问题

1、MSSQLServer数据库无法收缩的处理办法.数据库数据文件无法收缩的情况在MSSQLServer2008中有一个叫做“张金玉”的数据库。想把他收缩一下。进入“SQLServerManagementStudio”，使用“数据库”f“张金玉”鼠标右键菜单中的“任务”一“收缩”一“文件”菜单项，弹出一个“收缩文件”窗口，如下图。在这个窗口中可以看到当前分配的空间”为31236.00MB,“可用空间”为23341.81MB(74%)。可以缩小很多。选中窗口中的“在释放未使用的空间前重新组织页”单选按钮，并将那个“将文件收缩到”框框里面的值设为0(此处设为0在运行中会自动填入这个框框右边的最小值一7

2、825)。点击“确定”按钮，稍等片刻，这个窗口自动关闭，表示已经收缩完毕。但是，再次打开这个窗口看看，“当前分配的空间”仍然是31236.00MB。换句话说，这个数据库实际上并没有收缩。换用其它的收缩方法，统统不能收缩。鉴于此种情况，考虑数据库本身可能存在错误。试用“DBCCCHECKDB”检查是否有误。在“SQLServerManagementStudio”中新建一个查询选项卡，先指定数据库名称为“张金玉”，然后执行“DBCCCHECKDB”。执行期间服务器的硬盘灯常亮。执行完毕后报告有错。在报告开头附近就有两行红字如下：ServiceBroker消息9675，状态ServiceBroker

3、消息9676，状态ServiceBroker消息9667，状态ServiceBroker消息9668，状态ServiceBroker消息9669，状态ServiceBroker消息9674，状态ServiceBroker消息9670，状态ServiceBroker消息9605，状态张金玉的DBCC结果。消息2576，级别16，状态1，1:已分析的消息类型:14。1:已分析的服务约定:6。1:已分析的服务:3。1:已分析的服务队列:3。1:已分析的会话端点:0。1:已分析的会话组:0。1:已分析的远程服务绑定:01:已分析的会话优先级:0。1行索引分配映射(IAM)页(1:3998207)(位于

4、对象ID0,索引ID-1,分区ID0,分配单元ID332260034084864(类型为Unknown)的上一个指针指向了IAM页(0:0),但扫描过程中检测不到它。消息8906,级别16,状态1,第1行数据库ID5中的页(1:3998200)在SGAM(1:3578625)和PFS(1:3995472)中进行了分配,但未在任何IAM中分配。PFS标志MIXED_EXTALLOCATED0_PCT_FULL。CHECKDB发现有2个分配错误和0个一致性错误与任何单个的对象都没有关联。在报告的末尾处有总结如下：CHECKDB在数据库张金玉中发现2个分配错误和0个一致性错误。对于由DBCCCHEC

5、KDB(张金玉)发现的错误,repair_allow_data_loss是最低的修复级别。DBCC执行完毕。如果DBCC输出了错误信息,请与系统管理员联系。好像是建议使用“DBCCCHECKDB”的repair_allow_data_loss参数修复。那么在查询选项卡中运行“DBCCCHECKDB(张金玉,repair_allow_data_loss)”。但是，一运行就报错。原因是修复数据库时，该数据库需要设置成“单用户”状态。将数据库属性的“选项”一“状态”一“限制访问”设置成“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!执行叫好冒2Jr暂勵圖电|壬劉寧車|姑.iVt岳25JlJ1CljIm比1开能|密母少G旳|量检査劉6厉出比3.|FExiE讼1SQLE.e.站野:旺书艮）（E巾从运行结果看，错误已

7、经被修复了。既然已经修复了错误，那么就重新进行“收缩”收缩后再使用“数据库”一“张金玉”鼠标右键菜单中的“任务”f“收缩”f“文件”菜单项，打开“收缩文件”窗口看看，情况如下图。此时“当前分配的空间”已经变成了7895.00MB，说明收缩成功。下次再遇到不能“收缩”的情况时，首先要考虑数据库内部是否有错。可以先直接使用“DBCCCHECKDB（张金玉,repair_allow_data_loss）”修复一下。修复后便可以顺利收缩了。二.数据库日志文件无法收缩的情况在MSSQLServer2008中有一个叫做“庞继刚”的数据库。在数据库属性中的“文件”中可以见到日志是3460MB。如下图。T鞍按

8、宙圧村能曲削3曲本屉需助*姐跟馬規瞄件理取眼展百鲫文屈更积扩空空空空耳律一J?所有舌辺：IT曲用主立耒耳|Q)逼务若甬文件类型艾用a初闻大小射匚包St増怅踣径氐祁“门閃疔劇gPBIWXSJLL6増星为】NB和Eftll増忙|.|d:iTyojt-iji卩皿匚出:TT詐EiMTi曰志不15用5460増量为10Z.峽的盘.|!：也rocraFil*1用呻数IE岸文件血務器：JHIBSqLEEFRES5逹接.JHI玳AdaixaxtrLtm-添加而在数据库属性的“选项”中“恢复模式”是“完整”。如下图。这里的恢复模式”在MSSQLServer2000中文版中曾经叫做故障还原模型”在SQLServer

9、2008英文版中叫做“Recovermodel”作用是指定数据库被完全损坏时的修复方式。所谓完全损坏，通俗地说就是“彻底完蛋”的意思。实际上这里的“恢复模式”是指数据库“彻底完蛋”时的“拯救”方式。在右边的下拉中有三个选项：“完全”、“大容量日志的”、“简单”当选用“完全”或“大容量日志的”时。完全损坏的数据库可以利用“备份文件”（备份设备）还原到做备份时的状态，并且可以再使用日志文件恢复到最后一次操作的状态。前提条件是数据库完全损坏了，而日志文件仍然完好无损。不过，这种情况是很难办到的。可能需要将数据库存储在“镜像”方式等的环境之内。这样大概不用担心数据库完全损坏时日志也被破坏。话说回来，在这种环境中主存储中的数据库完全损坏时，镜像中的那一套会仍然存在的，这样一来就不必考虑“完全”或“大容量日志的”了。对于“简单”方式只能恢复到做备份时的状态。在“完全”或“大容量日