The drives or file systems on which you locate the database and log directories are important to the proper operation of your IBM® Tivoli® Storage Manager server. Placing each database and recovery log directory on a separate disk provides the best performance and the best disaster protection.
For the optimal database performance, choose the fastest and most reliable disks that are configured for random access I/O, such as Redundant Array of Independent Disks (RAID) hardware. The internal disks included by default in most servers and consumer grade Parallel Advanced Technology Attachment (PATA) disks and Serial Advanced Technology Attachment (SATA) disks are too slow.
To maintain database integrity, ensure that the storage hardware can withstand failures such as power outages and controller failure. You can improve database performance by using hardware that provides a fast, nonvolatile write cache for both the database and logs. Put the database directories on fault tolerant storage with high-availability features.
It is best to use multiple directories for the database, with four to eight directories for a large Tivoli Storage Manager database. Locate each database directory on a disk volume that uses separate physical disks from other database directories. The Tivoli Storage Manager server database I/O workload is spread over all directories, thus increasing the read and write I/O performance. Having many small capacity physical disks is better than having a few large capacity physical disks with the same rotation speed.
Locate the active log, mirror log, and archive log directories also on high-speed, reliable disks. The failover archive log can be on slower disks, assuming that the archive log is sufficiently large and that the failover log is used infrequently.
The access pattern for the active log is always sequential. Physical placement on the disk is important. It is best to isolate the active log from the database and from the disk storage pools. If they cannot be isolated, then place the active log with storage pools and not with the database.
Enable read cache for the database and recovery log, and enable write cache if the disk subsystems support it.