Effects of SMAPP on performance and storage

Processor performance

SMAPP has some affect on processor performance. The lower the target recovery time you specify for access paths, the greater this affect is. Typically, the affect on processor performance is not very noticeable, unless the processor is nearing capacity.

Auxiliary storage

SMAPP causes increased disk activity, which increases the load on disk input/output processors. Because the disk write operations for SMAPP do not happen at the same time, they do not directly affect the response time for a specific transaction. However, the increased disk activity might affect overall response time.

Also when you use SMAPP, the system creates an internal journal and journal receiver for each disk pool on your system. The journal receivers that SMAPP uses take additional auxiliary storage. If the target recovery time for access paths for a disk pool is set to *NONE, the journal receiver has no entries. The internal journal receivers are spread across all the arms in a disk pool, up to a maximum of 100 arms.

The system manages the journal receivers automatically to minimize the affect as much as possible. It regularly discards internal journal receivers that are no longer needed for recovery and recovers the disk space. The internal journal receivers that are used by SMAPP require less auxiliary storage than the journal receivers for explicit journaling of access paths. Internal journal receivers are more condensed because they are used only for SMAPP entries.

If you have already set up journaling for a physical file, the system uses the same journal to protect any access paths that are associated with that physical file. If the system chooses to protect additional access paths, your journal receivers will grow larger more quickly. You will need to change journal receivers more often.

Tips to reduce SMAPP's affect on auxiliary storage

• When you set up SMAPP, specify target recovery times for access paths either for the entire server or for individual disk pools, but not for both. If you specify both, the system does extra work by balancing the overall target with the individual targets.
• If you also journal physical files, to deal with the increased size of your journal receivers, consider specifying to remove internal entries when you set up journaling or swap journal receivers. If you specify this, the system periodically removes internal entries from user journal receivers when it no longer needs them to recover access paths. This prevents your journal receivers from growing excessively large because of SMAPP.
• If your system cannot support dedicating any resources to SMAPP, you can specify *OFF for the system target recovery time. Before choosing this option, consider setting the recovery time to *NONE for a normal business cycle, perhaps a week. During that time, periodically display the estimated recovery time for access paths. Evaluate whether those times are acceptable or whether you need to dedicate some system resources to protecting access paths.

  If you turn SMAPP off, any disk storage that has already been used will be recovered shortly thereafter. If you set the SMAPP values to *NONE, any disk storage that has already been used will be recovered after the next time you restart your system.

  Note: If you want to change the target system recovery time to a different value after you have set it to *OFF, the system must be in a restricted state.

For more information about removing internal entries, see Receiver size options for journals. See the Performance topic for more information about system performance.