Checklist for server database disks

Use the checklist to verify that disk systems for the server database have the characteristics and configuration that are key to good performance.

Question Tasks, characteristics, options, or settings More information
Is the database on fast, low-latency disks? Do not use the following drives for the Tivoli® Storage Manager database:
  • Nearline SAS (NL-SAS)
  • Serial Advanced Technology Attachment (SATA)
  • Parallel Advanced Technology Attachment (PATA)
Do not use internal disks that are included by default in most server hardware.

Enterprise-grade solid-state disks (SSD), with Fibre Channel or SAS interface, offer the best performance.

If you plan to use the data deduplication functions of Tivoli Storage Manager, focus on disk performance in terms of I/O operations per second (IOPS).

Checklist for data deduplication
Is the database stored on disks or LUNs that are separate from disks or LUNs that are used for the active log, archive log, and storage pool volumes? Separation of the server database from other server components helps reduce contention for the same resources by different operations that must run at the same time.  
If you are using RAID, did you select the optimal RAID level for your system? Did you define all LUNs with the same size and type of RAID? When a system must do large numbers of writes, RAID 10 outperforms RAID 5. However, RAID 10 requires more disks than RAID 5 for the same amount of usable storage.

If your disk system is RAID, define all your LUNs with the same size and type of RAID. For example, do not mix 4+1 RAID 5 with 4+2 RAID 6.

 
If an option to set the strip size or segment size is available, did you optimize the size when you configured the disk system? If you can set the strip size or segment size, use 64 KB or 128 KB sizes on disk systems for the database. The block size that is used for the database varies depending on the table space. Most table spaces use 8 KB blocks, but some use 32 KB blocks.
Did you create at least four directories (also called storage paths) on four separate LUNs for the database?

If you are using Tivoli Storage Manager data deduplication, did you create at least eight storage paths on eight separate LUNs?

Heavier workloads and use of some features require more database storage paths than the minimum requirements.

Server operations such as data deduplication drive a high number of input/output operations per second (IOPS) for the database. Such operations perform better when the database has more directories.

For server databases that are larger than 500 GB or are expected to grow to that size, use eight directories.

Consider planned growth of the system when you determine how many storage paths to create. The server uses the higher number of storage paths more effectively if the storage paths are present when the server is first created.

For more information, see the following topics:

For help with forecasting growth when the server deduplicates data, see technote 1596944 (http://www.ibm.com/support/docview.wss?uid=swg21596944).

For the most recent information about database size, database reorganization, and performance considerations for Tivoli Storage Manager Version 6 and Version 7 servers, see technote 1452146 (http://www.ibm.com/support/docview.wss?uid=swg21452146).

Are all directories for the database the same size? (Directories for the database are sometimes called storage paths.) Directories that are all the same size ensure a consistent degree of parallelism for database operations. If one or more directories for the database are smaller than the others, they reduce the potential for optimized parallel prefetching.

This guideline also applies if you must add storage paths after the initial configuration of the server.

 
Did you raise the queue depth of the database LUNs on AIX® systems? The default queue depth is often too low. See Configuring AIX systems for disk performance.