In most cases we are using only simplest hard drive configuration
on the computer - single hard drive. But this is much slowest configuration of
any possible.

Hard drive planning principles for heavy loaded server are based on the
principles of file usage principles and are independent of the server type.
First of all, administrator must determine what files are used by the server and
file's usage modes.

If two files are located on the same hard drive, write or read operations
with one file reposition hard drive head and this position is profitless for
operations with second file. Using two (or more) this files on different hard
drives allows I/O requests to be performed in parallel and each drives head is
independent.

So, to improve performance of database system, we must use (ideally) one hard
drive per each file, and split randomly used files per several hard drives. Of
course, it is impossible and we must find compromise.

MiniM Database Server uses the following files:

Before Image Journal / often is used with sequential access

Transaction Journal / often is used with sequential access

Data files / are used with random access

Executable files / are used with read only access

If administrator is able to use several hard drives, he can place this files
on different hard drives.

In depends of ability, I recommend place BIJ file on separate and fastest
hard drive, but this drive may be with small volume.

Second, I recommend to find most widely used database and place data files on
fast RAID array.

Third, I recommend to place journal directory on the separate hard drive.

Fourthly, I recommend locate executables and install MiniM instance on the
system drive and all data files, BIJ and Journal locate on other hard drive.

Content of temporary database (TEMP) does not used after restart or hardware
failure, so this data file may be located on RAM drive. If applications are
heavy use this database, this option may improve performance without data lost.
Note that RAM drive must be active before MiniM instance start.

And, last recommendation - check that application uses much more indices and
randomly access real big globals, for example, application use many index
structures. This type of access may cover all space in database much random. In
this case I recommend (if it is able) plan to use database consisting of several
extents and locate ones on different hard drives. This may significantly improve
random access to database.