SQLServer数据库无法收缩问题.doc

MS SQL Server数据库
无法收缩的处理办法
一. 数据库数据文件无法收缩的情况
在MS SQL Server 2008中有一个叫做“张金玉”的数据库。想把他收缩一下。
进入“SQL Server Management Studio”，使用“数据库”→“张金玉”鼠标右键菜单中的“任务”→“收缩”→“文件”菜单项，弹出一个“收缩文件”窗口，如下图。

在这个窗口中可以看到“当前分配的空间”为31236.00MB，“可用空间”为23341.81MB（74%）。可以缩小很多。
选中窗口中的“在释放未使用的空间前重新组织页”单选按钮，并将那个“将文件收缩到”框框里面的值设为0（此处设为0在运行中会自动填入这个框框右边的最小值—7825）。
点击“确定”按钮，稍等片刻，这个窗口自动关闭，表示已经收缩完毕。但是，再次打开这个窗口看看，“当前分配的空间”仍然是31236.00MB。换句话说，这个数据库实际上并没有收缩。换用其它的收缩方法，统统不能收缩。
鉴于此种情况，考虑数据库本身可能存在错误。试用“DBCC CHECKDB”检查是否有误。
在“SQL Server Management Studio”中新建一个查询选项卡，先指定数据库名称为“张金玉”，然后执行“DBCC CHECKDB”。执行期间服务器的硬盘灯常亮。执行完毕后报告有错。在报告开头附近就有两行红字如下：
张金玉的 DBCC 结果。
Service Broker 消息 9675，状态 1: 已分析的消息类型: 14。
Service Broker 消息 9676，状态 1: 已分析的服务约定: 6。
Service Broker 消息 9667，状态 1: 已分析的服务: 3。
Service Broker 消息 9668，状态 1: 已分析的服务队列: 3。
Service Broker 消息 9669，状态 1: 已分析的会话端点: 0。
Service Broker 消息 9674，状态 1: 已分析的会话组: 0。
Service Broker 消息 9670，状态 1: 已分析的远程服务绑定: 0。
Service Broker 消息 9605，状态 1: 已分析的会话优先级: 0。
消息 2576，级别 16，状态 1，第 1 行
索引分配映射(IAM)页 (1:3998207) (位于对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID 332260034084864 (类型为 Unknown))的上一个指针指向了 IAM 页 (0:0)，但扫描过程中检测不到它。
消息 8906，级别 16，状态 1，第 1 行
数据库 ID 5 中的页 (1:3998200) 在 SGAM (1:3578625) 和 PFS (1:3995472) 中进行了分配，但未在任何 IAM 中分配。PFS 标志 'MIXED_EXT ALLOCATED 0_PCT_FULL'。
CHECKDB 发现有 2 个分配错误和 0 个一致性错误与任何单个的对象都没有关联。
………………
在报告的末尾处有总结如下：
CHECKDB 在数据库 '张金玉' 中发现 2 个分配错误和 0 个一致性错误。
对于由 DBCC CHECKDB (张金玉)发现的错误，repair_allow_data_loss 是最低的修复级别。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
好像是建议使用“DBCC CHECKDB”的repair_allow_data_loss参数修复。那么在查询选项卡中运行“DBCC CHECKDB(张金玉,repair_allow_data_loss )”。但是，一运行就报错。原因是修复数据库时，该数据库需要设置成“单用户”状态。将数据库属性的“选项”→“状态”→“限制访问”设置成“SINGLE_USER”，使其变成单用户。
设置成单用户之后立即再运行“DBCC CHECKDB(张金玉,repair_allow_data_loss )”。但是仍然报错。然而，退出“SQL Server Management Studio”再重新启动“SQL Server Management Studio”后再运行“DBCC CHECKDB(张金玉,repair_allow_data_loss )”就不报错了。运行后的界面如下图。

从运行结果看，错误已经被修复了。
既然已经修复了错误，那么就重新进行“收缩”。收缩后再使用“数据库”→“张金玉”鼠标右键菜单中的“任务”→“收缩”→“文件”菜单项，打开“收缩文件”窗口看看，情况如下图。

此时“当前分配的空间”已经变成了7895.00MB，说明收缩成功。
下次再遇到不能“收缩”的情况时，首先要考虑数据库内部是否有错。可以先直接使用“DBCC CHECKDB(张金玉,repair_allow_data_loss )”修复一下。修复后便可以顺利收缩了。
二. 数据库日志文件无法收缩的情况
在MS SQL Server 2008中有一个叫做“庞继刚”的数据库。在数据库属性中的“文件”中可以见到日志是3460MB。如下图。

而在数据库属性的“选项”中“恢复模式”是“完整”。如下图。

这里的“恢复模式”在MS SQL Server 2000中文版中曾经叫做“故障还原模型”。在SQL Server 2008英文版中叫做“Recover model”。作用是指定数据库被完全损坏时的修复方式。所谓完全损坏，通俗地说就是“彻底完蛋”的意思。实际上这里的“恢复模式”是指数据库“彻底完蛋”时的“拯救”方式。
在右边的下拉中有三个选项：“完全”、“大容量日志的”、“简单”。当选用“完全”或“大容量日志的”时。完全损坏的数据库可以利用“备份文件”（备份设备）还原到做备份时的状态，并且可以再使用日志文件恢复到最后一次操作的状态。前提条件是数据库完全损坏了，而日志文件仍然完好无损。不过，这种情况是很难办到的……。可能需要将数据库存储在“镜像”方式等的环境之内。这样大概不用担心数据库完全损坏时日志也被破坏。话说回来，在这种环境中主存储中的数据库完全损坏时，镜像中的那一套会仍然存在的，这样一来就不必考虑“完全”或“大容量日志的”了。
对于“简单”方式只能恢复到做备份时的状态。
在“完全”或“大容量日志的”情况下，如果不采取特殊措施，日志文件将不会被收缩。出现“日志文件无法收缩”的情况。
如果不想或者没有条件使用日志来“拯救”完蛋了的数据库，那么干脆把这个选项改成“简单”就能够收缩了，如下图。

进入“任务”→“收缩”→“文件”功能，各个选项如下图。

然后点击“确定”按钮进行收缩操作。
收缩完毕后再到“数据库属性”中的“文件”去看看，日志已经变成1了。如下图。