SQLServer数据库无法收缩问题

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了。

如下图。