Best Practices for the Tivoli Storage Manager V6 DB Disk volumes

Answer

Best Practices as of this writing are:

Use fast, low latency disks for the DB. (SSD is great for the DB, but can still be expensive). Don’t use the slower internal disk included by default in most AIX servers, or using consumer grade PATA/SATA disk in a Linux or Windows system.

Use multiple database containers. For an average size DB, it is recommended to use at least 4 containers initially for the DB, spread across 4 LUNs / physical disks. Larger TSM servers, or TSM servers planning on using data deduplication, should have up to 8 containers or more. (Exception to multiple LUNS can be XIV.)

Plan for growth with additional containers up front. Adding containers later can result in an imbalance of IO and create hot spots.

Place each database container is in a different filesystem. This improves performance; DB2 will stripe the database data across the various containers. Tivoli Storage Manager supports up to 128 containers for the DB.

There should be a ratio of one database directory, array, or LUN for each inventory expiration process.

The block size for the DB varies depending on the tablespace, most are 16K, but a few are 32K. Segment/strip sizes on disk subsystems should be 64K or 128K.

If using RAID, then define all your LUNs with the same size and type.
- (For example, don’t mix 4+1 RAID5 and 4+2 RAID6 together)

RAID10 outperforms RAID5 (when doing large numbers of writes) but comes at a cost of twice as much disk being needed.

Smaller capacity disks are better than larger ones if they have the same rotational speed.
Have containers on disks that have the same capacity and IO characteristics.
- (For example, don’t mix 10K and 15K drives for the DB containers)

Use faster disks for the Active Logs. Do not mix active logs with disks containing the DB, archive logs, or system files such as page or swap space.

Slower disks for archive logs and failover archive logs can be used, if needed.

Cache subsystem "readahead" is good to use for the active logs; it helps in archiving them faster.

RAID1 is good for active logs.

It is highly recommended that FailoverArchiveLog space be set aside for possible emergency use. Slower disks can also be used for FailoverArchiveLog space.

Disk subsystems detect readahead on a LUN by LUN basis. If you have multiple reads going against a LUN, then this detection fails.
- What this means is that you should have more LUNS of a smaller size. But too many LUNS can be harder to manage.
- Current recommendations are to have file device class volumes in the 20-25 GB range.

Use pre-allocated volumes vs. scratch volumes. Scratch volumes will cause file fragmentation.
- Each new fragment means cache read ahead stops
- Use the fileplace (AIX), filefrag (Linux), or contig (Windows) commands to see if file fragmentation is happening
- With Tivoli Storage Manager V6.3, “define volume” performance is much faster.

If you use devclass DISK for your storage pools, have 1 storage pool volume per filesystem, and have no more than N volumes for an N+1 RAID5.

If you use devclass FILE, then you need at least MAXSESSIONs worth of volumes defined, but this will impact performance. The resulting IO will be more random in nature.

Buy as much disk cache for the storagepool volumes as you can afford.

DIO (Direct IO) is enabled by default for stgpools
- The DIRECTIO option is not displayed with “q opt”. Use the “query option directio” command to see its current setting.
- You MIGHT benefit from DIRECTIO NO if your disk subsystem has a small amount of cache on it.
- Using file system cache (DIRECTIO NO) can decrease overall server throughput and increase server processor utilization. Also, If you have set this option and call Tivoli Storage Manager support with a performance issue, you should tell them that you have set it to NO. Setting this to NO is not a best practice.