Traditionally, a 'hard' quiesce point is required before a database can be backed up by HotBackup/Inflight procedures. For a hard quiesce point the database areas are varied read-only or offline, and online services are disrupted during this period. If it is planned correctly then this interruption to online services can be minimal. It is where Batch work is run against CV that the headaches begin!

Batch Work has to either be carefully scheduled around this 'outage', or batch jobs have to be manually cancelled and then restarted following the 'hard' quiesce. Even when all the effort has been put in to arrange the schedule to allow for the hard quiesce, what happens if a batch job that was expected to run for two hours is still running after three? Do the operators cancel it and restart it, or do they allow it to finish? Whichever course of action is taken, the batch work could now be running into the online day. If we waited for the program to finish, then we may have a much larger impact in the online day when we need to vary the areas to create the quiesce point. Also, if any part of this carefully planned batch schedule should not run as expected, then operator or human intervention is likely to be required - along with the associated costs! As online days are continually extended, so the Batch window forever shrinks. It may get to a stage where there is simply not enough time to run the Batch Work and schedule a quiesce point.

The DB-SQP utility allows the HotBackup to be taken without the read-only period and its associated disruption to online users and batch jobs. Transaction and Batch jobs can just continue with absolutely no interruption or special scheduling required - yet TOTAL integrity of the Backups is always maintained.

The SoftQuiesce point does away with the need to vary areas to either retrieval or offline. Updates just carry on as usual!

Stacks Image 32
Stacks Image 224