IBM E16RMLL-I Implementation Guide - Page 74
Primary disk storage pool
![]() |
View all IBM E16RMLL-I manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 74 highlights
you have to manually increase the size of the recovery log. This may take some time but can usually be avoided with adequate precautions (for example, by monitoring and planning for growth). To estimate the size of the recovery log, multiply the database size by the percentage of data that changes each backup cycle. Double this number to allow for two backup cycles to occur without a database backup. This gives a starting point for the recovery log. For example, if the database size is 1386 MB, and 5% of the data changes every backup cycle, then the estimated size for the recovery log would be 1386 MB x 0.05 x 2 = 138.6 MB (141 MB for better allocation, if using a single volume). As with the database, we recommend using the Tivoli Storage Manager mirroring function for the recovery log instead of hardware or operating system mirroring. If you are using Tivoli Storage Manager mirroring, you need to plan for the mirror copy by doubling the amount of disk for the recovery log. Various file systems have different maximum capacities, so the recovery log may have to be split across numerous volumes to make up your total recovery log size. To ensure no single point of failure when mirroring the recovery log, each volume in a mirrored set should be placed on a separate drive and even controller. Complete Table 2-10 with the recovery log file names for your primary and copy recovery log. Table 2-10 Recovery log worksheet Log volume File name (primary) Vol1 /tsm/log/primary/file01 Total Size (MB) 141 141 File name (copy) /tsm/log/copy/file01 Total Size (MB) 141 141 2.8.8 Primary disk storage pool The traditional Tivoli Storage Manager design uses disks as a cache for nightly backups. Data is migrated daily from disk to a less expensive medium such as tape. A best practice is to have enough disk storage pool space to store one night's incremental file system backup, and send large file backups directly to tape (for example, database files) to optimize the overall I/O. Consider using the cache=yes parameter on disk storage pools-this means files remain on disk 44 IBM Tivoli Storage Manager Implementation Guide
![](/manual_guide/products/ibm-e16rmlli-implementation-guide-3588123/74.png)