34,838
社区成员
发帖
与我相关
我的任务
分享sql server 中收缩数据库有意义吗？？
本人是sybase-dba，也顺便兼职搞搞sqlserver。基于sybase的经验，我觉得没有必要经常收缩sql server数据库的大小或者数据文件文件的大小。
因为在sybase中迄今没有能够减小已经分配数据库大小的办法，也就是说：在sybase中数据库的空间大小只能涨不能降。其实，这不是sqlserver没必要收缩的原因。
在sql server中数据文件中会随着时间而产生一些碎片，但是，收缩数据库不会合并各个小的碎片。收缩数据mdf文件时剩下来的空间是初始化时分配了但是还没用到的空间。绝不是各个page之间的碎片部分。
还有，sql server中的日志文件是按照顺序写的（从文件头一直往下写，也就不存储在碎片的概念了）。收缩数据库日志文件的效果就是让日志记录点跳到文件前部分而已。
日志文件被收缩，以后还得继续写日志吧？照样ldf文件又变大了。 个人认为：收缩ldf的大小不如截断日志来得实在。只要适时的截断不活跃日志，或者数据文件所在磁盘有足够的空间，收缩数据文件是没有什么意义的！
将sql server传输给其他人的时候，如果对数据文件进行压缩，那么收缩和不收缩效果差不多（因为压缩算法肯定会忽略数据文件中的空页面或者碎片）！
收缩数据库的唯一效果可能就是对象在附加你的数据库的时候不用分配那么多的磁盘空间了。
个人感觉收缩数据文件不能提高性能！
因为在sybase中迄今没有能够减小已经分配数据库大小的办法，也就是说：在sybase中数据库的空间大小只能涨不能降。其实，这不是sqlserver没必要收缩的原因。
在sql server中数据文件中会随着时间而产生一些碎片，但是，收缩数据库不会合并各个小的碎片。收缩数据mdf文件时剩下来的空间是初始化时分配了但是还没用到的空间。绝不是各个page之间的碎片部分。
还有，sql server中的日志文件是按照顺序写的（从文件头一直往下写，也就不存储在碎片的概念了）。收缩数据库日志文件的效果就是让日志记录点跳到文件前部分而已。
日志文件被收缩，以后还得继续写日志吧？照样ldf文件又变大了。 个人认为：收缩ldf的大小不如截断日志来得实在。只要适时的截断不活跃日志，或者数据文件所在磁盘有足够的空间，收缩数据文件是没有什么意义的！
将sql server传输给其他人的时候，如果对数据文件进行压缩，那么收缩和不收缩效果差不多（因为压缩算法肯定会忽略数据文件中的空页面或者碎片）！
收缩数据库的唯一效果可能就是对象在附加你的数据库的时候不用分配那么多的磁盘空间了。
个人感觉收缩数据文件不能提高性能！
...全文
请发表友善的回复…
发表回复
rfq 2013-02-18
- 打赏
- 举报
日志文件收缩， 回收磁盘空间。
数据文件 根据设计 设计的大小，一般情况不用收缩，收缩可能带来性能的问题。
日志
如果 选择的日志恢复模型是完全，如果没有日志截断，日志增长的很大，
建议
备份日志。
backup log db to disk='备份设备'
截断日志
backup log db with no_log
然后收缩。
dbcc shrinkfile(2,10)
rfq 2013-02-06
- 打赏
- 举报
收缩 数据库 是非常耗费server性能的操作，如果没有必要不要收缩
go
收缩 无非就是把已经分配给数据库文件空间收回来，但是，收缩的时候 要移动数据页，而且可能造成大量的碎片，影响性能。
go
日志收缩和数据文件收缩不一样，日志中的虚拟文件状态 只有 在可复用 时候 才能收缩。
而且 凡是有活动的日志的日志虚拟文件都是活动的不能收缩。
go
pgy8288 2013-02-06
- 打赏
- 举报
我一般是不会收缩的，除非有特别大的项目数据更新，导致mdf或ldf文件已经大到压根就不会需要的大小的地步。
mayuanf 2013-02-05
- 打赏
- 举报
best practice是永远不要收缩文件或日志。如果你需要shrink，说明你dba工作没做好。
不懂必须要问 2013-02-03
- 打赏
- 举报
受益很浅
windxfxx8 2010-08-16
- 打赏
- 举报
[Quote=引用 17 楼 lzd_83 的回复:]
收缩减小占用磁盘空间的大小，但如果你想提高性能的，仅收缩一下数据库是没有太大的用处的，要想提
高性能的化，应该从多方面的考虑。服务器配置、内存、服务器I/O操作，查询语句优化以及大的表应
采取分区表的形式等。
[/Quote]
是这样的
收缩减小占用磁盘空间的大小，但如果你想提高性能的，仅收缩一下数据库是没有太大的用处的，要想提
高性能的化，应该从多方面的考虑。服务器配置、内存、服务器I/O操作，查询语句优化以及大的表应
采取分区表的形式等。
[/Quote]
是这样的
暗夜之王 2010-08-14
- 打赏
- 举报
當數據量大時你就覺得有必要了......
空心兜兜 2010-08-14
- 打赏
- 举报
我觉得有用
但我理解的很混乱
数据库很大的时候，做查询、插入会慢，减小他的自动增加比例值就稍微好些
同理…………
但我理解的很混乱
数据库很大的时候，做查询、插入会慢，减小他的自动增加比例值就稍微好些
同理…………
Sybase数据库恢复 2010-08-14
- 打赏
- 举报
[Quote=引用 12 楼 crszf 的回复:]
最直观的效果就是可以节省磁盘空间啊
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的
[/Quote]
怕日志暴涨， 可以备份日志或者截断日志。
最直观的效果就是可以节省磁盘空间啊
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的
[/Quote]
怕日志暴涨， 可以备份日志或者截断日志。
Sybase数据库恢复 2010-08-14
- 打赏
- 举报
[Quote=引用 12 楼 crszf 的回复:]
最直观的效果就是可以节省磁盘空间啊
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的
[/Quote]
能解释一下还原的时候为什么慢吗？
个人觉得理论上不应该慢！
最直观的效果就是可以节省磁盘空间啊
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的
[/Quote]
能解释一下还原的时候为什么慢吗？
个人觉得理论上不应该慢！
crszf 2010-08-14
- 打赏
- 举报
最直观的效果就是可以节省磁盘空间啊
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的
z574438205 2010-08-14
- 打赏
- 举报
迄今为止还没看出收缩有什么效果
xlh0053 2010-08-14
- 打赏
- 举报
貌似没有很大的意义
ChinaITOldMan 2010-08-14
- 打赏
- 举报
收缩可减少磁盘空间
chinammm 2010-08-14
- 打赏
- 举报
习惯后差不多
数字化从业者老高 2010-08-14
- 打赏
- 举报
若要收缩特定数据库的所有数据和日志文件，请执行 DBCC SHRINKDATABASE 命令。若要一次收缩一个特定数据库中的一个数据或日志文件，请执行 DBCC SHRINKFILE 命令。
若要查看数据库中当前的可用（未分配）空间量，请运行 sp_spaceused。
可在进程中的任一点停止 DBCC SHRINKDATABASE 操作，任何已完成的工作都将保留。
收缩后的数据库不能小于数据库的最小大小。最小大小是在数据库最初创建时指定的大小，或是使用文件大小更改操作（如 DBCC SHIRNKFILE 或 ALTER DATABASE）显式设置的最后大小。例如，如果数据库最初创建时的大小为 10 MB，后来增长到 100 MB，则该数据库最小只能收缩到 10 MB，即使已经删除数据库的所有数据也是如此。
运行 DBCC SHRINKDATABASE 而不指定 NOTRUNCATE 选项或 TRUNCATEONLY 选项等价于带 NOTRUNCATE 运行 DBCC SHRINKDATABASE 操作，然后再带 TRUNCATEONLY 运行 DBCC SHRINKDATABASE 操作。
要收缩的数据库不必在单用户模式下；其他的用户仍可以在数据库收缩时对其进行工作。这也包括系统数据库。
不能在备份数据库时收缩数据库。反之，也不能在数据库执行收缩操作时备份数据库。
DBCC SHRINKDATABASE 的工作原理
DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而，DBCC SHRINKDATABASE 在对日志文件进行收缩时，它将视为所有的日志文件都存在于一个连续的日志池中。文件始终从末尾开始收缩。
假设名为 mydb 的数据库有一个数据文件和两个日志文件。数据文件和日志文件分别是 10 MB，并且数据文件包含 6 MB 数据。
对于每个文件，数据库引擎都会计算一个目标大小。这就是文件将要收缩到的大小。将 target_percent 与 DBCC SHRINKDATABASE 一起指定时，数据库引擎计算的目标大��是收缩后文件中的 target_percent 可用空间大小。例如，如果在收缩 mydb 时将 target_percent 指定为 25，则数据库引擎将此文件的目标大小计算为 8 MB（6 MB 数据加上 2 MB 可用空间）。因此，数据库引擎将任何数据从数据文件的后 2 MB 中移动到数据文件前 8 MB 的可用空间中，然后对该文件进行收缩。
假设 mydb 的数据文件包含 7 MB 的数据。将 target_percent 指定为 30，以允许将此数据文件收缩到可用空间的 30％。但是，将 target_percent 指定为 40 却不会收缩数据文件，因为数据库引擎收缩文件的目标大小不能小于数据当前占用空间大小。您还可以用另一种方法来考虑此问题：所要求的 40％ 可用空间加上整个数据文件大小的 70％（10 MB 中的 7 MB），超过了 100％。因为所要求的可用百分比加上数据文件占用的当前百分比大于 100%（多出 10%），所以任何大于 30 的 target_size 都不会收缩此数据文件。
对于日志文件，数据库引擎使用 target_percent 来计算整个日志的目标大小；因此，target_percent 是收缩操作后日志中的可用空间大小。之后，整个日志的目标大小转换为每个日志文件的目标大小。
DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。如果虚拟日志中的所有逻辑日志部分都没有超出日志文件的目标大小，则该文件将成功截断，DBCC SHRINKDATABASE 完成且不显示任何消息。但是，如果部分逻辑日志位于超出目标大小的虚拟日志中，则数据库引擎将释放尽可能多的空间，并发出一条信息性消息。该消息说明需要执行哪些操作来将逻辑日志移出位于文件末尾的虚拟日志。执行该操作以后，DBCC SHRINKDATABASE 可用于释放剩余空间。有关详细信息，请参阅收缩事务日志。
因为日志文件只能收缩到虚拟日志文件边界，所以不可能将日志文件收缩到比虚拟日志文件更小（即使现在没有使用该文件）。虚拟日志文件的大小在创建或扩展这些日志文件时由数据库引擎动态选择。有关虚拟日志文件的详细信息，请参阅事务日志物理体系结构。
最佳做法
当您计划收缩数据库时，请考虑以下信息：
* 在执行会产生许多未使用空间的操作（如截断表或删除表操作）后，执行收缩操作最有效。
* 大多数数据库都需要一些可用空间，以供常规日常操作使用。如果反复收缩数据库并注意到数据库大小变大，则表明收缩的空间是常规操作所必需的。在这种情况下，反复收缩数据库是一种无谓的操作。
* 收缩操作不会保留数据库中索引的碎片状态，通常还会在一定程度上增加碎片。这是不要反复收缩数据库的另一个原因。
* 除非有特定要求，否则不要将 AUTO_SHRINK 数据库选项设置为 ON。
若要查看数据库中当前的可用（未分配）空间量，请运行 sp_spaceused。
可在进程中的任一点停止 DBCC SHRINKDATABASE 操作，任何已完成的工作都将保留。
收缩后的数据库不能小于数据库的最小大小。最小大小是在数据库最初创建时指定的大小，或是使用文件大小更改操作（如 DBCC SHIRNKFILE 或 ALTER DATABASE）显式设置的最后大小。例如，如果数据库最初创建时的大小为 10 MB，后来增长到 100 MB，则该数据库最小只能收缩到 10 MB，即使已经删除数据库的所有数据也是如此。
运行 DBCC SHRINKDATABASE 而不指定 NOTRUNCATE 选项或 TRUNCATEONLY 选项等价于带 NOTRUNCATE 运行 DBCC SHRINKDATABASE 操作，然后再带 TRUNCATEONLY 运行 DBCC SHRINKDATABASE 操作。
要收缩的数据库不必在单用户模式下；其他的用户仍可以在数据库收缩时对其进行工作。这也包括系统数据库。
不能在备份数据库时收缩数据库。反之，也不能在数据库执行收缩操作时备份数据库。
DBCC SHRINKDATABASE 的工作原理
DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而，DBCC SHRINKDATABASE 在对日志文件进行收缩时，它将视为所有的日志文件都存在于一个连续的日志池中。文件始终从末尾开始收缩。
假设名为 mydb 的数据库有一个数据文件和两个日志文件。数据文件和日志文件分别是 10 MB，并且数据文件包含 6 MB 数据。
对于每个文件，数据库引擎都会计算一个目标大小。这就是文件将要收缩到的大小。将 target_percent 与 DBCC SHRINKDATABASE 一起指定时，数据库引擎计算的目标大��是收缩后文件中的 target_percent 可用空间大小。例如，如果在收缩 mydb 时将 target_percent 指定为 25，则数据库引擎将此文件的目标大小计算为 8 MB（6 MB 数据加上 2 MB 可用空间）。因此，数据库引擎将任何数据从数据文件的后 2 MB 中移动到数据文件前 8 MB 的可用空间中，然后对该文件进行收缩。
假设 mydb 的数据文件包含 7 MB 的数据。将 target_percent 指定为 30，以允许将此数据文件收缩到可用空间的 30％。但是，将 target_percent 指定为 40 却不会收缩数据文件，因为数据库引擎收缩文件的目标大小不能小于数据当前占用空间大小。您还可以用另一种方法来考虑此问题：所要求的 40％ 可用空间加上整个数据文件大小的 70％（10 MB 中的 7 MB），超过了 100％。因为所要求的可用百分比加上数据文件占用的当前百分比大于 100%（多出 10%），所以任何大于 30 的 target_size 都不会收缩此数据文件。
对于日志文件，数据库引擎使用 target_percent 来计算整个日志的目标大小；因此，target_percent 是收缩操作后日志中的可用空间大小。之后，整个日志的目标大小转换为每个日志文件的目标大小。
DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。如果虚拟日志中的所有逻辑日志部分都没有超出日志文件的目标大小，则该文件将成功截断，DBCC SHRINKDATABASE 完成且不显示任何消息。但是，如果部分逻辑日志位于超出目标大小的虚拟日志中，则数据库引擎将释放尽可能多的空间，并发出一条信息性消息。该消息说明需要执行哪些操作来将逻辑日志移出位于文件末尾的虚拟日志。执行该操作以后，DBCC SHRINKDATABASE 可用于释放剩余空间。有关详细信息，请参阅收缩事务日志。
因为日志文件只能收缩到虚拟日志文件边界，所以不可能将日志文件收缩到比虚拟日志文件更小（即使现在没有使用该文件）。虚拟日志文件的大小在创建或扩展这些日志文件时由数据库引擎动态选择。有关虚拟日志文件的详细信息，请参阅事务日志物理体系结构。
最佳做法
当您计划收缩数据库时，请考虑以下信息：
* 在执行会产生许多未使用空间的操作（如截断表或删除表操作）后，执行收缩操作最有效。
* 大多数数据库都需要一些可用空间，以供常规日常操作使用。如果反复收缩数据库并注意到数据库大小变大，则表明收缩的空间是常规操作所必需的。在这种情况下，反复收缩数据库是一种无谓的操作。
* 收缩操作不会保留数据库中索引的碎片状态，通常还会在一定程度上增加碎片。这是不要反复收缩数据库的另一个原因。
* 除非有特定要求，否则不要将 AUTO_SHRINK 数据库选项设置为 ON。
Sybase数据库恢复 2010-08-14
- 打赏
- 举报
[Quote=引用 20 楼 claro 的回复:]
收缩远没有您想的那样简单，有很多因素和前提的影响。
在没有前提的情况下，回答可能都是事实而非的。这其中涉及到区还有统计信息等
[/Quote]
你要是了解的话，请从“这其中涉及到区还有统计信息等”角度帮忙分析一下。
收缩远没有您想的那样简单，有很多因素和前提的影响。
在没有前提的情况下，回答可能都是事实而非的。这其中涉及到区还有统计信息等
[/Quote]
你要是了解的话，请从“这其中涉及到区还有统计信息等”角度帮忙分析一下。
obuntu 2010-08-14
- 打赏
- 举报
只有在需要磁盘空间或者异常增大时才对数据库进行收缩。。
总之，收缩是一个不怎么推荐的操作。。
总之，收缩是一个不怎么推荐的操作。。
claro 2010-08-14
- 打赏
- 举报
收缩远没有您想的那样简单，有很多因素和前提的影响。
在没有前提的情况下，回答可能都是事实而非的。这其中涉及到区还有统计信息等
在没有前提的情况下，回答可能都是事实而非的。这其中涉及到区还有统计信息等
Sybase数据库恢复 2010-08-14
- 打赏
- 举报
[Quote=引用 15 楼 ccs02287 的回复:]
我觉得有用
但我理解的很混乱
数据库很大的时候，做查询、插入会慢，减小他的自动增加比例值就稍微好些
同理…………
[/Quote]
查询插入的快慢和数据库大小有关系。 和里面的碎片倒是有关系，但是收缩能清理碎片吗？
我觉得有用
但我理解的很混乱
数据库很大的时候，做查询、插入会慢，减小他的自动增加比例值就稍微好些
同理…………
[/Quote]
查询插入的快慢和数据库大小有关系。 和里面的碎片倒是有关系，但是收缩能清理碎片吗？
加载更多回复（10）
