Sizing Guide Exchange Server 2003 - Fujitsu

White Paper Sizing Guide Exchange Server 2003 Version: 4.2, July 2006
Access pattern
Database administration activities result in two completely complementary data access patterns. On the one
hand the database with 100% random access. In this respect, 2/3 are typically accounted for by read and 1/3
by write accesses. On the other hand, a data flow which is written 100% in sequence arises as a result of the
transaction log files. To do justice to this it is advisable to spread the databases and log files over different
physical disks.
A second aspect as regards the physical separation of log files and databases: In the transaction concept all
changes to the database are recorded in the log files. If the database is lost, it is possible to completely
restore the database using a backup and the log files since the backup was generated. In order to achieve
maximum security it is sensible to store the log files and the database on physically different hard disks so
that all data are not lost in the event of a disk crash. As long as only one of the two sets of information is lost,
the missing information can be restored. This is particularly valid for small Exchange installations where the
lack of a large number of hard disks encourages the storing of both sets of information on one data medium.
Caches
For an intelligent SCSI controller with its own cache mechanisms there are further opportunities of adapting
the disk subsystem to the requirements of the Exchange server. Thus the write-back cache should be
activated for the volume on which the log files are to be found. Read-ahead caches should also be activated
for the log files; this has advantages during restore where log files have to be read. The same applies to the
volume on which queues (SMTP or MTA queues) are filed.
However, for the volume at which the store is filed it is not practical to activate the read-ahead cache. It may
sound illogical to deactivate a cache that is used to accelerate accesses. However, the store is a database of
many Gigabytes, to which random access in blocks of 4 kB is made. The probability of a 4-kB block from an
infinitely large data amount being found in a cache of a few MB and not having to be read from the disk is
very unlikely. With some controllers it is unfortunately not possible to deactivate the read cache
independently of the write cache and also when reading, a check is first made as to whether the data
requested are available in the cache. In this case, better overall throughput is achieved by deactivating the
cache (except for with RAID 5) as read accesses are typically twice as frequent as write accesses.
In addition, each individual hard disk also provides write and read caches. As standard the read cache is
always activated. A lengthy discussion is going on about the activation of the write cache, because in
contrast to the write caches of the RAID controller this cache does not have a battery backup. On condition
that the server (and of course the disk subsystem) is UPS-protected, it may be sensible to activate the write
caches of the hard disk. All hard disks from Fujitsu are for security reasons supplied with the write caches
deactivated. Some of our competitors supply their hard disks with activated write caches with the result that
at first sight such systems appear to have a better performance in comparative testing. However, if a system
is not protected against power failures by a UPS, or if it is deactivated abruptly, data losses can occur on the
activated write caches of the hard disks.
© Fujitsu Technology Solutions, 2009 Page 20 (69)