Databases Reference
In-Depth Information
Chapter 48
Leveraging
Checkpoint
Processing
William Pearson
O
, following are a few reflections
on lessons learned in the “glass house.” I will introduce the concept of
checkpoint restartability. Then, I will go on to explain how this can shave
hours off of your batch window, just when you need it the most. Finally, I
will show how you can apply checkpoint restart to any database manage-
ment system (DBMS) such as DB2, ORACLE, SYSBASE or SQL server.
N
THE
ROAD
TO
THE
ENTERPRISE
SERVER
Murphy's Law proposes that anything that can go wrong, will, and usu-
ally at the worst possible time. For the manager of a support application,
this usually means that the day begins sitting down to talk with a dishev-
eled programmer. Now, given the 1990s dress code, your first clue that
something went wrong during the night is not the faded T-shirt and blue
jeans; nor is it the bags under the eyes, the five o'clock shadow, or even the
extra large coffee mug clutched between white knuckles, has started weav-
ing intricate patterns over your special report. No, it's the socks! They
don't match — one of them is definitely black while the other is quite red.
The story is the old classic of heroic recovery where once again good tri-
umphs over evil. It starts with a beep in the middle of the night and a 2:30
a.m. call to operations. Next comes the 45-minute drive to work, where,
upon arrival, it only takes 15 minutes to analyze and resolve the problem
(note the 'genius at work' logo on T-shirt). Then, 30 minutes to recover files
to a prior run state. Finally, a long 1 1/2 hour wait to reprocess transaction
records to get back to where the original ABEND occurred…only to discov-
er a minor typo in the 'fix'; completely, understandable, under the circum-
stances. Fast forward 2 hours and 15 minutes to when the run finishes and
your story's main character has just the time to buy a coffee and appear at
your desk by 8:00 a.m.
Search WWH ::
Custom Search