An item of interest is the fact that ANY database will over time experience
"internal" fragmentation. This is where records are removed from the file, but the space it occupied is still there and is either reused for a new record or has to be skipped over. Most databases have utilities to restructure the files, but without defragmenting the other files or consolidating the free space, the rebuilt database file will be physically fragmented.
Diskeeper will work just fine in environments with live large databases, whether they be Exchange, SQL, SMS, Sybase, Oracle, Informix, etc....
In most cases these databases are made up of large container file(s) that are pre-allocated in size at the point of creation, but if the size increases beyond the initial value they will become physically fragmented. Diskeeper never restructures the internal contents of the file. After defragmentation a file it will be a bit for bit duplicate of the original. Therefore any holes or 'records marked as deleted' within the database are still present and you will need, from time to time, to restructure your database files per the recommendations of their respective manufacturers.
People sometimes use the word fragmentation to describe the condition of a file which has its records (internal contents) scattered about within the file, separated by numerous small gaps. This type of fragmentation may be a problem with the application which maintains the file; it is not inherent in the operating system or disk file structure.
There are two types of fragmentation with which we are immediately concerned: file fragmentation and free space fragmentation. File fragmentation concerns computer disk files that are not whole but rather are broken into scattered parts, while free space fragmentation means that the empty space on a disk is broken into scattered parts rather than being collected all in one big empty space. File fragmentation causes problems with accessing data stored in computer disk files, while free space fragmentation causes problems creating new data files or extending (adding to) old ones.
Taken together, we refer to the two types of fragmentation as disk fragmentation. It is important to note that, when talking about fragmentation, we are talking about the file as a container for data and not about the contents (data) of the file itself. People sometimes use the word fragmentation to describe the condition of a file which has its records (internal contents) scattered about within the file, separated by numerous small gaps. This type of fragmentation may be a problem with the application which maintains the file; it is not inherent in the operating system or disk file structure.
Internal fragmentation reflects the "holes" and wasted "free space" within a given file. A database would be a good example. Let's say you have 250,000 records represented in the file. If an individual record is removed, the location is simply marked as deleted. In the course of doing business hundreds, perhaps thousands of records are added and deleted. It doesn't take long for the internal organization of a database file, its indexes, and other related files to quickly become quite disorganized. The speed of locating a particular record or segment of information is directly related to the amount time spent skipping over these holes or internal fragments.
Diskeeper handles the disk (file and free space) fragmentation only. Under no circumstance does Diskeeper change or alter the internal contents of a file. This would be a very dangerous thing to do as one would have to have a very intimate knowledge of a given file structure and be able to detect changes as the various databases evolved with new releases.
The tools for databases deal with this internal record fragmentation by rearranging the internal records on the fly when possible, and at times requiring a whole new copy of the database to be created and each record copied to the new file. Unless this copy is done to a freshly formatted partition or a partition with a single chunk of free space large enough to contain the entire database the chances are very good that this new copy will become physically fragmented. You may actually have worsened your performance due to additional disk head seeks.
