"DO NOT DEFRAG DATABASES!" is one of the more popular myths/misconceptions we encounter in promoting and selling Diskeeper. BTW; when I define database (DB) servers, I also include purposed servers such as email, Domain Controller, DNS, etc. And of course MS SQL, Oracle, Sybase, and others (where the DB back-ends an app – e.g. a Customer Relationship Management program). I've seen technically comprehensive studies measuring IO throughput and transactions per second (TPS), performed by customers, validating the need for defragmentation of their database servers. They spend weeks/months of careful execution, verifying the source of performance issues and that defragmentation truly solves them. The degree of benefit that defragmentation brings to databases depends on several factors. The obvious of course is the degree of fragmentation. The less obvious include the purpose of that database and how it is used. Defragmentation is not going to solve all DB-optimization requirements, but it is a piece in the puzzle. Often a recommendation to "NOT defrag" hinges on the, understandably, accepted conception that defragmentation-generated I/O will impact the use of that DB. That is especially true when that database must operate at capacity 24/7. I agree with those caveats 100%. With free/built-in defragmenters, there is a use/benefit trade-off, and they can do more harm than good. That is where advanced defragmentation technology such as InvisiTasking comes in. If you are interested in more information on defragmentation and databases (i.e. does Diskeeper defragment the internal records?), there are white papers in our Knowledge Center (see link on the left), as well as product reviews by DBAs (Database Administrators). Here is a link to a recent review done by SQL-Server-Performance.Com.
Defragmenting Databases. Myth or Real-McCoy?
This site uses Akismet to reduce spam. Learn how your comment data is processed.