sqlserver2012直接收缩数据库有问题吗

在 SQL Server 2012 中，收缩数据库是一种常用的维护 *** 作，可以帮助将不再需要的空间释放回 *** 作系统，从而提高存储空间的利用率。但是，直接收缩数据库存在一些潜在的问题和注意事项，需要慎重考虑以下几点：

1. 收缩数据库可能导致性能下降：当数据库文件被压缩时，SQL Server 必须重新组织页之间的逻辑顺序，并将未使用的页从文件中删除。这个过程可能会对数据库的性能产生负面影响，尤其是对于大型数据库。

2. 收缩数据库可能会增加 I/O 负载：当数据库被压缩时，SQL Server 必须读取并写入大量的数据。这可能会导致额外的磁盘 I/O 负载，从而影响其他用户或应用程序的性能。

3. 收缩数据库可能会导致数据文件的碎片：收缩数据库会导致数据文件中存在大量的空间碎片，这可能会影响以后的性能。此时，最好使用 ALTER INDEX REORGANIZE 或 ALTER INDEX REBUILD 来解决碎片问题。

因此，建议在进行数据库收缩之前，先备份数据库并进行测试，以确保您的收缩计划不会对生产环境造成损害。如果没有必要，最好选择定期进行数据库维护，而不是直接收缩数据库。

1. 收缩所移动的每个数据页都会被写入事务日志

假设你有个数据库(含数据和索引)占用了50G空间, 你想收缩成40G. 而收缩过程 就是要把那40G的东西移到数据文件的开始. 同时, 为这个收缩, 事务日志需要40G 的空间, 就象自动增长了那些空间(如果你之前没预留那么多空间的话). 然后, 你的日志备份大小就会是40G加上”正常部分的”日志. 如果你的数据库恢复模式设成简单的话,不会有这个现象, 因为在收缩过程中的CHECKPOINT会把日志截断的.

(此条适用于收缩数据文件) 2. 收缩后, 当用户加入数据时, 数据文件又会自动增长.

增加数据库的空间是个很”昂贵的” *** 作, 因为数据文件增长很费时间, 并且因为需要很多的资源而影响数据库的性能. 同时, 一些 *** 作会被阻塞直到增长的 *** 作结束.

(此条适用于收缩数据和日志文件)

SQL Server 2005及以后的版本:

SQL Server 2005加入了一个新特征: 即时初始化(instant file initialization), 就是说建数据文件和增长数据文件会很快, 因为Windows不再把所有数据库文件都写上零了. 不过, 即时初始化只适用于数据文件, 而不适用于日志文件. 同时, 对数据文件的初始化需要SQL SERVER服务帐号具有WINDOWS的SE_MANAGE_VOLUME_NAME的权限 (这一权限可以用WINDOWS的Perform Volume Maintenance Tasks的安全策略来设定). 在缺省条件下, 这个权限只限于系统管理员. 3. 在某些情况下, 自动增长不能”赶上”SQL SERVER对空间的需求.

这会产生两个错误信息: 1) 如果数据文件空间满了, 则产生错误11052) 如果日志文件满了, 则产生错误9002.

(此条适用于收缩数据和日志文件) 4. 移动数据页会使你的数据库产生碎片

假设你先重建索引(这个要求数据库有空间), 然后又收缩数据库. 实际上, 收缩会把你之前重建的索引又改回去了, 使你的数据库产生碎片. (如果你先收缩, 然后重建索引, 结果就是你的数据库文件会增大.)

(此条适用于收缩数据文件) 5. 频繁地收缩和增长数据库文件会使底层的文件系统产生碎片, 从而影响数据库性能.(此条适用于收缩数据和日志文件)

---