Performance considerations for save-while-active

 

While you can run save-while-active operations any time, save-while-active operations will affect the performance of other applications you are running.

You should run save-while active operations during times of low system activity. A few interactive jobs or batch jobs that are primarily read-only, are examples of activities that allow better system performance during the save-while-active operation.

In general, the system performs checkpoint processing faster for a small number of larger objects than for a large number of smaller objects.

You should not use the save-while-active function when the system is very busy or when there is very little disk storage available. Before you save large amounts of data (such as all user libraries), you should initially use the save-while-active function on a limited amount of data. Using the save-while-active feature on a limited amount of data will help you determine its impact on your system's performance and storage.

• Central processing unit (CPU) and save-while-active
  The relationship between the system's CPU and a save-while-active operation depends on the available CPU capacity and the characteristics of other jobs on the system

• Auxiliary storage activity and save-while-active
  When choosing the time period for a save-while-active operation, evaluate the activity in auxiliary storage without save-while-active processing.

• Main storage (memory) and save-while active
  How a save-while-active operation affects main storage depends on three items,

• DLO activity and save-while-active
  If the save-while-active operation is run at a time when users are updating document library objects (DLO), the save-while-active process may affect these users.

 

Parent topic:

Considerations and restrictions for the save-while-active function

Related concepts
Save-while-active restrictions Commitment control with save-while-active