物理文件碎片整理
Database Administration,Opinion | May 1, 2009 | 12:45 pm
Do You Include Physical File Defragmentation as Part of Your SQL Server Maintenance?
你是否在你的SQL Server維護工作中把物理文件的碎片整理考慮在內了呢？
Ever since I can remember, beginning with MS-DOS 1.0, physical file fragmentation has often been a problem on many systems I have used, hurting I/O performance as the disk heads have to thrash about to find all the many file fragments that make up a single physical file. Generally, using either the built-in OS defragmentation tools, or third-party tools, I have kept my physical files defragmented, so they are contiguous, helping to optimize my system’s I/O.
從我能回憶起以來（始於MS-DOS1.0），物理文件的碎片整理就是系統使用中經常出現的性能問題。由於磁頭必須反覆讀取大量的文件碎片來拼湊成一個物理文件，IO性能將嚴重受到影響。我通常使用操作系統內置的碎片整理工具或者第三方的碎片整理工具來進行物理文件碎片整理，以確保物理文件連續從而優化系統IO性能。
As technology has changed (SANs or SSD drives) physical file fragmentation has become less important. See Linchi Shea’s blog series on this topic. On the other hand, there are still a lot of servers with local storage that can be still be negatively affected by physical file fragmentation.
由於技術的改進（SAN和SSD驅動器）物理文件碎片的問題已顯得無關緊要。請看Linchi Shea關於此話題的系列博客（Linchi Shea’s blog series）。而另一方面，仍有大量的服務器採用本地存儲，這種情況下物理文件碎片仍然會對IO性能產生負面影響。
When I build a new physical box to run SQL Server, the new box has little or no physical file fragmentation to start with. Then, when I create my MDF and LDF files, I pre-size them to as close as I can to their final size (or at least as large as I expect them to grow in the next year or so). This way, when the MDF and LDF files are created on a new server, they are created in a contiguous manner, and there is no physical file fragmentation. Of course, if I do need to grow the MDF or LDF files, I do so in a controlled manner to minimize fragmentation. I avoid using autogrowth to grow my databases, as this can greatly contribute to file fragmentation as the MDF and LDF files grow over time.
當我新搭建一個物理機器來運行SQL Server時，這臺新機器上很少或者幾乎沒有物理文件碎片。接着我創建了MDF和LDF文件並將它們的大小預設成儘可能接近它們的最終大小（或者至少預設成來年該文件預期增長到的大小）。這樣在MDF和LDF在心服務器上創建時，它們都是連續的，沒有任何物理文件碎片。當然，如果我需要增長MDF或者LDF文件，我將以可控的方式增長以文件碎片最少。我避免使用自動增長功能來增長數據庫，因爲隨着MDF和LDF文件的增長，自動增長將引起大量的文件碎片。
In other cases, I have to deal with SQL Servers that have been around for a long time and have not been properly maintained. In those cases, I check for how bad fragmentation is, and if it is bad, I fix it before I create any new pre-sized MDF or LDF files. As a DBA, I prefer to be proactive and prevent physical file fragmentation from occurring in the first place.
在很多情況下，我必須應付一些運行了很長時間而沒有進行維護的SQL Server系統。在那些工作中，我會檢查文件碎片的嚴重程度，如果文件碎片很嚴重，我會在創建任何預設大小的MDF和LDF文件之前整理文件碎片。作爲一位DBA，我傾向於未雨綢繆而將文件碎片整理作爲第一要務。
What I would like to know is what has been your experience with physical file fragmentation on your SQL Servers? Have you experienced it? How has it affected performance? How do you fix it if you have it? What defragmentation tools do you use, and why? How do you prevent it from happening in the first place? In other words, how do you deal with physical file fragmentation on your SQL Servers?
我希望瞭解你經歷了那些物理你在SQL Server系統中的文件碎片問題？你碰到此類問題了嗎？文件碎片是如何影響你的系統性能的？如果你碰到過此類問題，你是如何解決的？你使用什麼碎片整理工具，你爲什麼使用它呢？你又是如何在第一時間避免文件碎片的出現呢？換言之，你如何在你的SQL Server系統中處理物理文件碎片問題？
Share and Enjoy:
Read more: http://www.bradmcgehee.com/2009/05/physical-file-defragmentation/#ixzz110ICM8Ks
Under Creative Commons License: Attribution