Achieving specific recovery targets
Use this topic for guidance on how we can achieve specific recovery target times by adjusting backup frequency.
If we have specific recovery targets to achieve, for example, completion of the queue manager recovery and restart processing in addition to the normal startup time within xx seconds, we can use the following calculation to estimate your backup frequency (in hours):Formula (A) Required restart time * System recovery log read rate (in secs) (in MB/sec) Backup frequency = ----------------------------------------------------- (in hours) Application log write rate (in MB/hour)Note: The examples given next are intended to highlight the need to back up your page sets frequently. The calculations assume that most log activity is derived from a large number of persistent messages. However, there are situations where the amount of log activity is not easily calculated. For example, in a queue sharing group environment, a unit of work in which shared queues are updated in addition to other resources might result in UOW records being written to the IBM MQ log. For this reason, the Application log write rate in Formula (A) can be derived accurately only from the observed rate at which the IBM MQ logs fill.
For example, consider a system in which IBM MQ MQI clients generate a total load of 100 persistent messages a second. In this case, all messages are generated locally.
If each message is of user length 1 KB, the amount of data logged each hour is approximately:100 * (1 + 1.3) KB * 3600 = approximately 800 MB where 100 = the message rate a second (1 + 1.3) KB = the amount of data logged for each 1 KB of persistent messagesConsider an overall target recovery time of 75 minutes. If we have allowed 15 minutes to react to the problem and restore the page set backup copy, queue manager recovery and restart must then complete within 60 minutes (3600 seconds) applying formula (A). Assuming that all required log data is on RVA2-T82 DASD, which has a recovery rate of approximately 2.7 MB a second, this necessitates a page set backup frequency of at least every:
3600 seconds * 2.7 MB a second / 800 MB an hour = 12.15 hours
If the IBM MQ application day lasts approximately 12 hours, one backup each day is appropriate. However, if the application day lasts 24 hours, two backups each day is more appropriate.
Another example might be a production system in which all the messages are for request-reply applications (that is, a persistent message is received on a receiver channel and a persistent reply message is generated and sent down a sender channel).
In this example, the achieved batch size is one, and so there is one batch for every message. If there are 50 request replies a second, the total load is 100 persistent messages a second. If each message is 1 KB in length, the amount of data logged each hour is approximately:50((2 * (1+1.3) KB) + 1.4 KB + 2.5 KB) * 3600 = approximately 1500 MB where: 50 = the message pair rate a second (2 * (1 + 1.3) KB) = the amount of data logged for each message pair 1.4 KB = the overhead for each batch of messages received by each channel 2.5 KB = the overhead for each batch of messages sent by each channelTo achieve the queue manager recovery and restart within 30 minutes (1800 seconds), again assuming that all required log data is on RVA2-T82 DASD, this requires that page set backup is carried out at least every:
1800 seconds * 2.7 MB a second / 1500 MB an hour = 3.24 hours
Periodic review of backup frequency
Monitor the IBM MQ log usage in terms of MB an hour. Periodically perform this check and amend your page set backup frequency if necessary.
Parent topic: Plan for backup and recovery