Calculating staging resources

Assuming that M sensitive units of recovery have been identified, numbered 1 to M, and that N sensitive tables have been identified, numbered 1 to N, the values being used in the calculation are as follows:

  • URConcurrency_m—The maximum number of concurrently logged (overlapping) copies of sensitive unit of recovery m (ranging from 1 to M).
  • INSERTs_m_n—The maximum number of inserts into sensitive table n (ranging from 1 to N) that occur in unit of recovery m. This may be 0 for certain combinations of m and n.
  • UPDATEs_m_n—The maximum number of updates to sensitive table n that occur in unit of recovery m. This may be 0 for certain combinations of m and n.
  • DELETEs_m_n—The maximum number of deletes from sensitive table n that occur in unit of recovery m. This may be 0 for certain combinations of m and n.
  • RecordLength_n—The record length of sensitive table n.

For each value of m, calculate the following:

ChangeVolume_m calculation formula

where 280 is the control information overhead, and UPDATEs_m_n is doubled to account for before and after images of the updated row.

Then calculate:

TotalChangeVolume calculation formula

TotalChangeVolume is the outside maximum amount of storage contained in staging spaces in above the bar storage and which potentially can be required of Auxiliary Storage to manage the staging of ongoing mirroring activity. As mentioned earlier, the practical maximum may be lower than TotalChangeVolume. Some of the factors that can produce lower results are:

  • How well distributed (versus “clumped”) the commits and rollbacks are in the DB2® log.
  • How many changes are discarded by filtering criteria in the source environment.
  • How variable the estimates of INSERTs_m_n, UPDATEs_m_n, and DELETEs_m_n are (these estimates are of maximum) from the average values for specific m and n.

Example calculation

Suppose you have 2 sensitive tables, table_1 with a row length of 1200 bytes and table_2 with a row length of 2100 bytes. Suppose further that there are three types of URs involving these tables.

UR_1 can contain up to 100 inserts and 100 updates for table_1, and there can be up to 50 concurrent URs of this type. UR_Concurrency_1 is 50, INSERTs_1_1 is 100, UPDATEs_1_1 is 100, DELETEs_1_1 is 0 and RecordLength_1 is 1200.

UR_2 can contain up to 1000 updates for table_2, and there can be up to 100 concurrent URs of this type. UR_Concurrency_2 is 100, INSERTs_2_2 is 0, UPDATEs_2_2 is 1000, DELETEs_2_2 is 0, and Record_Length_2 is 2100.

UR_3 can contain up to 200 inserts, updates, and deletes for each of table_1 and table_2, and there can be up to 25 concurrent URs of this type. UR_Concurrency_3 is 25, INSERTs_3_1 is 200, UPDATEs_3_1 is 200, DELETEs_3_1 is 200, INSERTs_3_2 is 200, UPDATEs_3_2 is 200, DELETEs_3_2 is 200, RecordLength_1 is 1200, and RecordLength_2 is 2100.

ChangeVolume_1 is (280 + 1200) * (100 + 2 * 100 + 0), or 444,000.

ChangeVolume_2 is (280 + 2100) * (0 + 2 * 1000 + 0), or 4,760,000.

ChangeVolume_3 is ((280 + 1200) * (200 + 2 * 200 + 200)) + ((280 + 2100) * (200 + 2 * 200 + 200)), or 1,184,000 + 1,904,000, or 3,088,000.

TotalChangeVolume is (50 * 444,000) + (100 * 4,760,000) + (25 * 3,088,000), or 575,400,000. A staging space size (as specified by the MAXSUBSCRSTAGESIZE keyword) of 600MB would be sufficient.

In practice, it may be possible to reduce the size of the staging spaces below the value computed for TotalChangeVolume. The Storage Manager STATUS command will display how much storage is being used by each subscription’s staging space, and will also display the maximum amount of storage ever used by each subscription’s staging space. In addition, the Staging Space Report will display the detailed contents of each subscription’s staging space. In Management Console the Source Engine performance metrics Staging space current bytes used and Staging space maximum bytes used also provide information on staging space storage used by the current run of the subscription.