Home > Database > Mysql Tutorial > [翻译]为什么你不要收缩数据库文件

[翻译]为什么你不要收缩数据库文件

WBOY
Release: 2016-06-07 17:44:58
Original
1071 people have browsed it

前言,这几天查看了很多关于 SQL SERVER 收缩数据文件方面的文章,准备写一篇关于收缩日志方面的文章,但是突然有种冲动将看过经典的文章翻译出来,下面这篇文章是翻译的是Paul Randal Why You Should Not Shrink Your Data Files。有些比较难以翻译、清晰的

  前言,这几天查看了很多关于SQL SERVER收缩数据文件方面的文章,准备写一篇关于收缩日志方面的文章,但是突然有种冲动将看过经典的文章翻译出来,下面这篇文章是翻译的是Paul Randal – “Why You Should Not Shrink Your Data Files”。有些比较难以翻译、清晰的地方,我会贴上原文。好了,不啰嗦了,直接看下面的翻译吧。

 

  我最大的一个热点问题是关于收缩数据文件,虽然在微软的时候,我自己写了相关收缩数据文件代码,我再也没有机会去重写它,让它操作起来更方便。我真的不喜欢收缩。

  现在,不要混淆了收缩事务日志文件和收缩数据文件,当事务日志文件的增长失控或为了移除过多的VLF碎片(这里和这里看到金佰利的优秀文章),然而,收缩事务日志数据文件不要频繁使用(罕见的操作)并且不应是你执行定期维护计划的一部分。

  收缩数据文件应该执行得甚至更少。这就是为什么——数据文件收缩导致产生了大量索引碎片,让我用一个简单并且你可以运行的脚步来演示。下面的脚本将会创建一个数据文件,创建一个10MB大小的“filler”表,一个10MB大小的“production”聚簇索引,然后分析新建的聚集索引的碎片情况。 

Code Snippet

 

执行结果如下

 

clipboard

聚集索引的逻辑碎片在收缩数据文件前大约接近0.4%。[但是我测试结果是0.54%,如上图所示,不过也算是接近0.4%]

 

现在我删除filter表,运行收缩数据文件命令后,重新分析聚集索引的碎片化。

SQL Code Two

下面是我的执行结果,作者执行结果,请看原文:

image

原文:

Wow! After the shrink, the logical fragmentation is almost 100%. The shrink operation *completely* fragmented the index, removing any chance of efficient range scans on it by ensuring the all range-scan readahead I/Os will be single-page I/Os.

译文:

哇,真是恐怖!数据文件收缩后,索引的逻辑碎片几乎接近100%,收缩数据文件导致了索引的完全碎片化。消除了任何关于它的有效范围扫描的机会,确保所有执行提前读范围扫描的 I/O 在单页的 I/O操作

为什么会这样呢? 当单个数据文件收缩操作一次后,它会用GAM位图索引找出数据文件中分配最高的页,然后尽可能的向前移动到文件能够移动的地方,就这样子,网站空间,在上面的例子中,美国服务器,它完全反转了聚集索引,让它从非碎片化到完全碎片化。

同样的代码用于DBCC SHRINKFILE, DBCC SHRINKDATABASE,以及自动收缩,他们同样糟糕,就像索引的碎片化,数据文件的收缩同样产生了大量的I/O操作,耗费大量的CPU资源,并且生成了*load*事务日志,香港服务器,因为任何操作都会全部记录下来。

数据文件收缩决不能作为定期维护的一部分,你决不能启用“自动收缩”属性,我尝试把它从SQL 2005和SQL 2008产品中移除,它还存在的唯一原因是为了更好的向前兼容,不要掉入这样的陷阱:创建一个维护计划,重新生成所有索引,然后尝试回收重建索引耗费的空间采取收缩数据文件 — — 这就是你做的生成了大量事务日志,但实质没有提高性能的零和游戏。

所以,你为什么要运行一个收缩呢,?举例来说,如果你把一个相当大的数据库删除了相当大的比例,该数据库不太可能增长,或者你需要转移一个数据库文件前先清空数据文件?

 

译文:

我很想推荐的方法如下:

基本上你需要提供一些更多的空间,才可以收缩的旧文件,但它是一个更清晰的设置。

 

原文:

The method I like to recommend is as follows:

Basically you need to provision some more space before you can shrink the old files, but it’s a much cleaner mechanism.

   如果你完全没有选择需要收缩日志文件,请注意这个操作会导致索引的碎片化,你应该在收缩数据文件采取一些步骤消除它可能导致的性能问题,唯一的方式是用DBCC INDEXDEFPAGE或 ALTER INDEX ...REORGANIZE消除索引的碎片不要引起数据文件的增长,这些命令要求扩展空间8KB的页代替重建一个新的索引在索引重建操作中。

底线 — — 尽量避免不惜一切代价运行数据文件收缩

------------------------------------------------分割线----------------------------------------

所以,还在用作业定期收缩数据文件或数据库开启了“自动收缩”属性的朋友们,请及时纠正你们的错误认识吧!

支持原著,也希望大家支持我辛苦的翻译劳动,请加上链接潇湘隐者博客。

 

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template