 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a new system configuration and method for
operating a computing apparatus. More specifically, it relates to the use
of a recovery log for restarting a computing system following normal or
abnormal termination.
2. Description of the Prior Art
In the operation of computing systems, it is the practice to provide a
programming subsystem which includes a plurality of resource managers.
Such resource managers control the operation of system resources
(hereinafter also called resource collections) such as data bases,
teleprocessing or other communication facilities, and the system itself.
Further, there may be a plurality of data base resource managers managing
separate or shared data base facilities, a plurality of teleprocessing
resource managers, and a plurality of system resource managers--such as in
a multi-programming, multi-processor environment.
It is, unfortunately, a characteristic of computing systems that failures
occur which cause the abnormal termination of the system, the
communication links, the data bases, and/or their managers. Such failures
may leave, for example, a data base in an inconsistent state, or require
that other resources or their managers not directly affected by the
failure also suspend operation.
In order to facilitate the recovery of resource managers and the facilities
or objects which they manage, it is known to write (hereinafter also
called externalizing) at specified processing points, a system log
containing the states of the resource collections (hereinafter called
checkpointed states) to non-volatile storage together with before and
after images of changes made to the resource collections. Examples of
systems using such a system log are the IBM Information Management System
(IMS/VS), Program No. 5740-XX2, and Customer Information Control System
(CICS/VS), the latter being described in CICS/VS Version 1.5
System/Application Design Guide, SC33-0068, at pages 237-246. In these
systems, during an emergency restart operation, the resource managers use
the information in the log to perform their respective recovery
responsibilities such as restoring the data base to a consistent state,
reestablishing control block content, and backing out the effect of
interrupted work unit activity on resources. However, there is no
provision for restarting a subset of the resource managers, nor to defer
the recovery of selected work units due to the unavailability of certain
resources.
Consequently, there is a need in the art for the capability to restart all
or a subset of the resource manager components of a subsystem, and all or
a subset of the subsystem's resources. When components or the resources
they manage are not available to the restart process, and have been made
inconsistent by the actions of interrupted work unit activity, there is a
need for mechanisms to remember these outstanding work unit recovery
requirements until the components or resources become available.
SUMMARY OF THE INVENTION
The invention provides an improved control structure and method for
operating a computing apparatus which is being interrupted and restarted
from time to time. The computing apparatus includes a plurality of
resource managers and resource collections such as data bases and
including a recovery log. The computing apparatus is executing work unit
instructions, and writing log records to the recovery log, the log records
including checkpointed states and records of changes to the resource
collections and resource managers resulting from execution of work unit
instructions. A subset of the resource managers are responsible for the
execution work of units and have responsibilities in recovering the work
units during restart. The method of the invention is characterized by the
steps of:
maintaining in a first structure with respect to each interrupted work
unit, the location of a respective section of the recovery log which
contains information of its activities and the recovery responsibility of
each resource manager to the work unit; and
maintaining in a second structure with respect to each of said subset of
said resource managers (1) its operational state and (2) the location of a
respective different section of the recovery log which contains
information that particular resource manager needs to perform its recovery
responsibility.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a diagrammatic illustration of computing system showing the
recovery manager component of the invention.
FIG. 2 is a diagrammatic illustration of the manner in which log records
are linked on the recovery log shown in FIG. 1.
FIG. 3 is a diagram of a resource manager status table maintained in the
subsystem recovery data set of FIG. 1 by the recovery manager component.
FIG. 4 is a diagrammatic illustration showing the relationship between the
resource manager status table of FIG. 3 and the recovery log of FIG. 2.
FIG. 5 is a diagram of a restart unit of recovery element maintained by the
recovery manager component of FIG. 1.
FIGS. 6 and 7 are diagrammatic illustrations of recovery log for use in
explaining the UNDO, TODO, and REDO procedures executed by the recovery
manager component of the invention.
FIG. 8 is a diagrammatic illustration of the relationship between the
various modules comprising the recovery manager component.
FIG. 9 is a diagrammatic illustration of various control structures
maintained or accessed in main storage by the recovery manager component.
DESCRIPTION OF THE PREFERRED EMBODIMENT
This application is related to application serial number 06/390,454 filed
June 21, 1982 for "Method and Apparatus for Logging Journal Data in a
Continuous Address Space Across Main Storage, Direct Access, and
Sequential Access Devices," by C. Mellow, et al, abandoned, assigned to
the same assignee as the present invention. The apparatus and method of
this invention makes use of the continuous journal log of Mellow, et al,
to enhance the recovery characteristics of a data base management system.
System recovery of the apparatus is further enhanced by the two-phase
commit protocol. The two-phase commit protocol is well known in prior art
and is described in "Operating Systems--An Advanced Cource" by R. Bayer et
al (Eds.), Springer-Verlag, 1978, 459-481 and in "Database Security and
Integrity" by E. B. Fernandez et al Addison-Wesley 1981, 280-286.
Referring to FIG. 1, there is illustrated a portion of a computing
apparatus, showing participant domain 20 and coordinating domain 32 within
the volatile main storage address space of a central electronic complex,
or computing apparatus, together with recovery log 40, subsystem recovery
data set 42, and resource collection such as data bases 44 in non-volatile
storage. The computing apparatus may be an IBM System/360 or System/370,
described in U.S. Pat. No. 3,400,371 by G. M. Amdahl, et al, and in IBM
System/370 Principles of Operation, IBM Publication GA22-7000-6.
Participant domain, or subsystem 20 is a data base subsystem 22, including
for example, initialization procedures component 24, recovery log manager
component 26, recovery manager component 28, data base accessing and
management component 29, and connection component 30. Components 24, 26,
28, 29, and 30 are examples of resource managers 21, and data base 44 is
an example of recoverable objects or resources.
Coordinating domain 32 includes a transaction management subsystem 34, and
one or more application programs 36. Application programs 36 originate
work units, which are passed by transaction management subsystem 34 to the
participant domain for execution by the resource managers 21, for example,
against resources 44.
Recovery manager (RM) 28 is responsible for the coordination, control, and
log record retrieval and presentation functions which occur during the
restart process. When participant domain 20 is cold started, it undergoes
an initialization process under the control of initialization procedures
component 24 to bring it to an operable cold state having no knowledge of
a prior existence. However, when participant domain 20 is restarted,
following either a normal or an abnormal termination, it enters a warm
state by refreshing its memory from information found in recovery log 40.
Recovery log 40 represents a chronological record of the events and
actions of work units originated by, for example, applications 36, upon
the resource collections 44 managed by domain 20. The contents of recovery
log 40 reflect events which advance the progress states of work units, and
which alter the content of recoverable resources and change the state of
resource collections 44.
Recovery manager 28 supports the restoration of recoverable resources 44
managed by participant domain 20 resource managers 21 to their most recent
consistent state which existed prior to or at the time of the previous
termination of participant domain 20, controls the use of recovery log 40,
provides a restart environment that supports both a total domain 20
restart and the restarting of a subset of that domain, provides a restart
and operation environment wherein a subset of the domain can be restarted
after the rest of the domain is operational with the existence of the
operational subset transparent to the restarting subset, and provides the
capability to cold start a resource manager 21 such that its recovery
responsibilities are performed outside of the participant domain 20
environment with the resource manager started but its participation in the
restart process bypassed.
Resource Managers 21
Resource managers 21 are participant domain 20 components which provide
services to other components and to application programs 36.
Initialization procedures component 24 controls the initialization
process, above. Recovery manager component 28 controls the memory
refreshing process, above. Recovery log manager component 26 provides log
40 recording and retrieving services; the Mellow, et al application
previously mentioned is an example of a recovery log manager component 26.
Data base accessing and management component 29 provides databases 44
recording and retrieving services.
Resource managers 21 participate in various domain 20 events by providing
event notification exit routines which are invoked by the controllers of
those events through broadcasts, to be described hereafter. Resource
managers 21 participate in their own initialization process through this
broadcast mechanism, and in attaining the warm restart state by providing
routines which receive event notification and log record presentation
broadcasts from recovery manager component 28.
Linked Log Records
Referring now to FIG. 2, a description will be given of the format of Log
40 and of the function provided by recovery log manager component 26 to
support the recovery activity managed by recovery manager component 26. In
the copending application of C. Mellow, et al, recovery log 40 and
recovery log manager component 26 are further described. Recovery log
manager component 26, responsive to a request from recovery manager 28 to
write a log record at the beginning of a unit of recovery (begin UR record
60), creates log write cursor 50, including unit of recovery ID (URID)
field 52 and link field 54. A log write cursor 50 is created and
maintained for the life of each work unit, or unit of recovery, and is
used to provide certain header information in UR log records written to
recovery log 40. In FIG. 2, three such log records 60, 61, and 62 are
shown, each having in its header U fields 63-65 and L fields 66-68,
respectively. Recovery log manager 26 inserts into URID field 52 the log
relative byte address (RBA) of the begin UR record 60, the first UR record
for this unit of recovery, or work unit. The same URID 52 RBA value will
be inserted into the U field 63, 64, 65, . . . , of each log record 60,
61, 62, . . . , created for this unit of recovery. When begin UR record 60
is created, L field 66 is set to null, thus identifying log record 60 as
the beginning record in the chain. Also, LINK field 54 is set equal to
URID 52 RBA to point to record 60, as it is also the last record of the
chain at the time it is written originally to the log. In response to a
request from data base accessing and management component 29 to write a
log record 61 for a unit of recovery which already exists, recovery log
manager component 26 updates the link field 54 with the RBA value of
record 61, inserts the previous LINK 54 field value into L field 67, to
point to the previous UR log record 60, and inserts the URID 52 value into
U field 64. UR log record 62 is similarly created, resulting in the log
record chain illustrated in FIG. 2 for a given unit of recovery which, in
this example, includes three log records, with the pointer arrows pointing
to the location specified by the RBA values stored in each of the log
write cursor 50 and log records 60-62 fields.
First Data Structure--Resource Manager Status Table (RMST) 70
In order that recovery manager component 28 support the early termination
and deferred restarting of selected resource managers 21, (herein a
component 29 is the only logical candidate) the operational states and
recovery log interest scopes of each resource manager 21 are independently
maintained. An intersect scope of the recovery log is the section of the
log a resource manager is interested in reading to perform its recovery
responsibility. Also, the recovery responsibilities of resource managers
21 as they apply to interrupted recoverable work units are maintained for
each work unit. The two recovery manager 28 structures which perform this
function are resource manager status table 70 and restart unit of recovery
element 90.
Relative byte addresses (RBAs) refer to the continuous log data addressing
range value assigned to any record written to recovery log 40. An RBA
value is time-ordered and unique within domain 20 and the recovery log 40
it manages. Two such RBA values are used to delimit the upper and lower
bounds of the recovery log 40 interest scope of a resource manager 21 or
the log activity scope of a work unit which is section of the log
containing information (e.g. data changes) about the work unit.
Referring to FIG. 3 in connection with FIG. 4, a description will be given
of the resource manager status table (RMST) 70. RMST 70 includes in its
header most recent checkpoint RBA field 72, flip/flop control field 74,
and RMST entries changed flag field 76. Then follow entries for each
resource manager 21, including RM identifier 80, operational status 82,
beginning log interest scope RBA 84, and ending log interest scope RBA 86.
Operational status 82 fields indicate if the resource manager is active or
terminated, and if terminated, whether the termination was normal or
early. For terminated resource managers only, fields 84 and 86 contain RBA
values pointing to recovery log 40 records.
An operational copy of RMST 70 is constructed during recovery manager 28
initialization from a copy externalized on subsystem recovery data set 42.
The content of the recovery data set 42 copy of RMST 70 describes the last
consistent configuration of the resource managers 21 comprising subsystem
20 prior to or as of its last termination. The operational copy of RMST
70, maintained by recovery manager component 28 in main storage, is
updated as resource managers 21 restart or terminate and is externalized
to recovery data set 42 during checkpoint events which write checkpoints
92, 94, 96, . . . , to recovery log 40. Each checkpoint 92, 94, 96
includes one or more checkpoint records 101-103, with zero to `n`
checkpoint records for each resource manager 21 participating in the
checkpoint. Header portion 71 of the operational copy of RMST 70 is
externalized to subsystem recovery data set 42 during each subsystem 20
checkpoint. RMST 70 entries 73 identifying each resource manager 21 known
to recovery manager 28 are only externalized to subsystem recovery data
set 42 in connection with the writing of checkpoints 92, 94, 96, . . . ,
to recovery log 40 associated with a change in status of a resource
manager 21. Dual copies of RMST header 71 and of RMST entries 73 are
maintained by recovery manager 28 on recovery data set 42 using flip/flop
control key 74, the value of which alternates with each successive write
to recovery data set 42. This procedure assures that a prior consistent
copy of RMST entries 73 will not be destroyed as a result of a failure
while externalizing a new copy of RMST entries 73 to recovery data set 42.
Most recent checkpoint RBA 72 field gives the RBA of the record on log 40
delimiting the start, or beginning checkpoint (BCP) record 98 of most
recent subsystem checkpoint 96. The ending checkpoint (ECP) record 99
delimits the end of checkpoint 96. The most recent checkpoint RBA 72 value
is used during recovery manager 28 initialization in determining which of
the dual copies of RMST header 71 represents the most recent checkpoint
taken. It is also used to establish the beginning log interest scope of
all resource managers 21 which, according to the copy of RMST 70 on
recovery data set 42, were in an active operational state at the time of
the prior termination of subsystem 20.
Flip/flop control field 74 is the key suffix used when externalizing the
most recent copy of RMST entries 73. This value is used during recovery
manager 28 initialization to determine which of the dual copies of RMST
entries 73 on recovery data set 42 represents the most recent
configuration.
RMST entries changed flag 76 provides an indication of whether or not the
status information maintained in fields 82 of the operational copy of RMST
70 have changed since the last checkpoint was taken. This field 76 is used
to determine if entries 73, in addition to header 71, must be externalized
to recovery data set 42 during the next checkpoint to recovery log 40.
Operational status fields 82 identify the operational states of the
resource managers 21 (RM1, RM2, . . . ,RMN) as represented by recovery
manager 28. Status fields 82 are used during recovery manager 28
initialization to determine whether or not related resource manager 21 was
operationally active as of the prior subsystem 20 termination. Status
field 82 is set upon completion of a restart or termination involving the
related resource manager 21, as well as during recovery manager 28
initialization. Operating states include active, terminated, and cold. An
operational status 82 of active state indicates that the related resource
manager 21 has undergone restart and is currently operational. Terminated
state indicates that the related resource manager 21 has terminated, with
state subqualifiers indicating if the reIated resource manager 21
terminated early or concurrent with subsystem 20. Cold state indicates
that related resource manager 21 is to be restarted to an operational
state with no knowledge of a prior existence; this status 82 allows the
recovery responsibilities of one or more resource managers 21 to be
performed outside of participant domain 20. Any outstanding recovery
responsibilities being remembered by recovery manager 28 are treated as
completed for cold starting resource managers 21.
Beginning log interest scope RBA field 84 specifies the RBA of the log 40
checkpoint record delimiting the start of the most recent checkpoint 94
participated in by the related resource manager 21. Its value is
established during a termination checkpoint involving the related resource
manager 21, or during recovery manager 28 initialization if the related
resource manager 21 was in an active operational state 82 as of the prior
subsystem 20 termination. It is used as the lower bound for positioning
the log when restarting the related resource manager 21.
Ending log interest scope RBA field 86 specifies the RBA of the log 40
checkpoint record delimiting the end of the most recent checkpoint 94
participated in by the related resource manager 21. This value is
established during a termination checkpoint involving the related resource
manager 21, or by recovery manager 28 during the first phase of the next
subsystem 20 restart. It is used as the upper bound for positioning
recovery log 40 when restarting the related resource manager 73.
Recovery manager 28 uses the independent resource manager beginning and
ending log interest scope RBA fields 84 and 86 to restart with subsystem
20 those resource managers 21 which terminated early, or alternatively to
restart them after the rest of subsystem 20 is operational.
Second Data Structure--Restart Unit of Recovery Element (RURE)
The second of the two recovery manager 28 structures which perform the
function of independently maintaining the operational states and recovery
log interests scopes of each resource manager 21 is restart unit of
recovery element (RURE) 90. The first such structure, RMST 70, is
described above.
A unit of recovery (UR) is a term referring to the actions of a recoverable
work unit between points of logical consistency; that is, between commit
points. Generally, the term "work unit" will be used to refer to a unit of
recovery.
RURE 90 is the recovery manager 28 structure representing a recoverable
work unit which was interrupted by subsystem 20 termination. The exact
extent of the effect of the work unit on subsystem 20 managed resources,
such as recoverable objects in data bases 44, cannot be determined without
examining recovery log 40. The recovery responsibilities of resource
managers 21 which provide services to the work units will depend on the
records 106 those resource managers contributed to log 40 on behalf of the
work unit, and the progress state attained by the work unit, and tracked
on log 40 by recovery manager 28. Referring to FIG. 5, RURE 90 contains
unit of recovery activity scope delimiters 110, including unit of recovery
identifier (which is the beginning log activity scope RBA 112 of the work
unit) and work unit ending log activity scope RBA 114, progress state 116,
resource manager participation maps 120 including remembered map 122 and
handled map 124, and restart completion flag 126.
Resource manager participation maps 120 are provided in each RURE 90 to
reflect the disposition of resource manager 28 recovery responsibilities
on a per-work-unit basis. A resource manager identifier 80 value is used
as the bit index into each participation map 120. The bit settings in the
two maps 122, 124 indicate the resource managers 21 which have an interest
in log records 106 contributed on behalf of the work unit, and whether or
not the resource managers 21 have performed the recovery responsibilities
associated with the work unit.
During creation of the participation maps 120:
1. A zero in a given index position in both maps 122, 124 indicates no log
records 106 of interest to that resource manager 21 whose identifier 80
indexes to the given index position have been encountered in log 40 within
the work unit's activity scope 110. If the work unit's entire log activity
scope 110 is processed and both map 122, 124 positions remain zero, the
resource manager had no recovery responsibilities associated with the work
unit. That resource manager will not be involved if a subsequent recovery
process on behalf of the work unit is required.
2. A zero in a given index position in remembered map 122 and a one in the
same position in handled map 124 indicates that the resource manager has
an interest in log 40 records 106 contributed on behalf of the work unit
and has handled its recovery responsibilities for all records thus far
encountered within the work unit's log activity scope 110. If the entire
work unit's log activity scope 110 is processed and both map 120 positions
remain as described it indicates the resource manager had a recovery
responsibility associated with the work unit and completed that
responsibility. The resource manager will be bypassed if a subsequent
recovery processing of the work unit is required.
3. A one in a given index position in remembered map 122 indicates the
resource manager has an interest in log records contributed on behalf of
the work unit but for some reason has been unable to perform its recovery
actions. A resource manager 21 may have contributed log records 106 on
behalf of the work unit but, because the resource manager 21 was either
not restarting, or was restarting but activation of a needed resource
within collection 44 was deferred, has not fulfilled its responsibilities.
The resource manager 21 will participate in a subsequent work unit
recovery processing when the resource manager 21 next restarts, or when
the resource within collection 44 is activated.
4. If, after a work unit's log activity scope 110 has been processed, all
bit positions in remembered map 122 are zero, it indicates that all
resource managers 21 have fulfilled their recovery responsibilities
associated with the work unit. In this case, recovery manager 28 drops the
associated work unit from its collection of work units still requiring
recovery processing.
Restart completed flag 126 indicates whether or not the work unit has
undergone its restart processing before. If it has, previously created
handled 124 and remembered 122 participation maps 120 exist, and are used
in determining which resource managers 21 should or should not participate
in the recovery processing of a given work unit. If the work unit has not
been through restart processing the participation maps must be created,
and therefore cannot be used in determining resource manager
participation.
Recovery manager 28 builds RURE's 90 from checkpoint records 101, 102, . .
. , 103, and from log records 106 recorded by resource managers 21 outside
of the checkpoint which reflect the addition, deletion, or modification of
work units.
REDO/TODO/UNDO
Referring now to FIG. 6, recovery processes REDO, TODO, and UNDO will be
described. Restarting following an unplanned subsystem 20 termination
involves the restoration of resources 44 left in a potentially
inconsistent state due to work unit interruption. The three work unit
recovery processes are REDO, TODO, and UNDO. The three possible points of
interruption are shown at points 130, 132, and 134, each following the
unit of recovery beginning (BUR) 112, but in varying positions with
respect to log records recorded with respect to end of commit phase 1
(EO1), beginning of commit phase 2 (BO2), and end of commit phase 2 (EO2).
REDO is the forward recovery process of insuring recoverable resource 44
consistency when a work unit is interrupted at point 134 after subsystem
20 and all other interested participant domains have agreed (as is
represented by BO2) to commit the actions of the work unit, but before
completion of the committed actions (at EO2). Resource managers 21 are
expected to insure that the most recent agreed-to resource state is
externalized, for example, onto data base 44.
TODO is the forward recovery process necessary to relock, or otherwise
exclusively reallocate the use of recoverable resources 44 to a work unit
interrupted at point 132 while in a commit-in-doubt state (between EO1 and
BO2). A commit-in-doubt state exists when a participant domain 20,
requested by a coordinating domain 32 (a subsystem connected to subsystem
20) to vote on continuing a work unit's commit processing, returns a
positive vote and is awaiting the final commit decision (vote outcome)
from coordinating domain 32. The work unit affected is said to be
"indoubt" within participant domain 20 until the final vote outcome has
been received. Resource managers 21 are expected to insure the recoverable
resources 44 altered by the work unit remain inaccessible to other work
units until the indoubt situation has been resolved, and resource
consistency has been established.
UNDO is the backward recovery process of insuring recoverable resource 44
consistency when a work unit is interrupted at point 130 before subsystem
20 has agreed (EO1) to commit the actions of the work unit. Resource
managers are expected to reverse the affect of the work unit's activity on
recoverable resources 44 such that the resources are restored to their
most recent committed state BUR 112 which existed prior to the point 130
of the interruption.
Recovery manager 28 is responsible for recording commit control records
BUR, EO1, BO2, and EO2. Once EO2 has been recorded, the work unit is
completed. Image records 135 on log 40 are recorded by the various
resource managers 21, and are used to roll forward and backward objects 44
that are inconsistent.
Restart Invocation
The restart process is requested by an initialization process which occurs
at the beginning of time or following some system interruption. Recovery
manager 28 not only controls the entire restart process, but as a resource
manager 21, participates in the restart event notification and log record
presentation broadcasts through the same mechanisms used by other
participating resource managers 21.
Referring to FIG. 7, restart processing comprises three phases: (1) first
restart phase, including the current status phase; (2) second restart
phase, including an UR forward recovery and a RM forward recovery process;
and (3) third restart phase including UR backward recovery.
Two event notification broadcasts, a BEGIN and an END, delimit the entire
restart process. In addition, each phase has BEGIN and END phase
delimiting broadcasts. These broadcasts are made to all resource managers
21 involved in the current restart processing. Parameter lists are passed
as input to the resource managers 21 receiving a broadcast, and in some
cases include a feedback area in which the resource managers 21 return
information relative to the broadcast. Resource managers 21 supporting
these broadcasts do any necessary preparatory or completion work
appropriate to that portion of the restart process.
Other restart broadcasts for each phase are directed to participating
resource managers 21, as will be described hereafter.
First Restart Phase--Current Status Phase
Referring to FIG. 7, the objective of the current status phase is to
reestablish the representation of the states of resources 44 as of the
point of prior termination 136. During normal processing, subsystem 20
uses a checkpoint technique to periodically record summary resource status
information 101, 102, . . . ,103 on recovery log 40. The identity of the
most recent checkpoint 96 is retained by subsystem 20 across any
termination 136 by recording it in the subsystem recovery data set 42
and/or recovery log 40. During the current status phase, that checkpoint's
96 content is used by the contributing resource managers 21 (RM1, RM2, . .
. ,RMN) as a base representation of their resource collection 44 states.
Examples of these resources 44 and their checkpointed states are: (1) all
defined data bases 44 and the identity of those on-line or off-line at the
time of the termination 136; (2) the identity and progress state of all
recoverable work units (such as those originated by applications 36)
interrupted by the termination 136; (3) the identity of external media
collections 44 whose content is potentially older than one committed
version, or internally maintained queues, and the log positioning
information needed to rebuild their content.
During the current status phase, recovery manager 28 requests positioning
of the log 40 at the start 98 of the most recently completed checkpoint
96. It then reads log 40 in a forward direction making the records of
interest available to their contributing resource managers 21. A multiple
pass operation will be required if different resource managers 21 last
participated in different checkpoints 96, 94, . . . . The first pass
starts reading at the most recent checkpoint 96 and goes forward through
the log 40 to the end of file 136. Subsequent passes for those resource
managers which did not participate in the most recent checkpoint start
with the last checkpoint they did participate in (such as 94 or 92) and go
forward to the end of their respective log interest scopes 86.
During this restart phase all non-cold starting resource managers 21 are
eligible to receive the records they contributed, via log record
presentation broadcasts from recovery manager 28. Typically, resource
managers 21 which record summary information during a checkpoint 96 also
log event records 106 indicating a change in the status of a resource 44
during normal processing. As an example, the transition of a recoverable
work unit to a committing state is logged. Records of this type supplement
the checkpoint records of the states of active recoverable work units.
Records which represent additions to, or deletions from, an internal queue
supplement checkpoint records which list the log positions of other
elements on the queue as of the checkpoint event. Therefore, during this
phase, in addition to their checkpoint records, resource managers 21 will
also be interested in the individual event records 106 which follow the
checkpoint records 96 and signify resource 44 state changes.
Recovery manager 28 provides resource managers 21 with the ability to
establish record selection criteria for restart log record presentation
broadcasts. The header portion of all recovery log 40 records 60, 61, 62,
. . . (FIG. 2) contains the contributing resource manager's 21 identifier
80, generic record type, and where applicable a work unit identifier 63,
64, 65, . . . . Recovery manager 28 uses this information in determining
the interest of a given resource manager 21 in a record.
Upon completion of the current status phase of restart each resource
manager 21 is expected to have reconstructed the internal representation
of the state of the resources 44 they manage. They also may have collected
log 40 positioning information needed to retrieve and reconstruct obsolete
data base media content, internal queues, and so forth, during the
subsequent restart phases. As an example, recovery manager 28 as a
participating resource manager 21, has reconstructed restart unit of
recovery elements 90 representing all recoverable work units interrupted
by a prior subsystem 20 termination 136, identified the type of work unit
recovery (REDO, TODO, or UNDO) each must undergo based on its interrupted
progress state, and established log positioning boundaries for each.
Second Restart Phase
(a) Unit of Recovery (UR) Forward Recovery Phase
Referring still to FIG. 7, the forward recovery phase includes work unit UR
forward recovery and resource manager RM forward recovery. The UR forward
recovery phase deals with those work units which were interrupted by an
unplanned subsystem 20 termination 136 after the subsystem domain 20 had
agreed to commit the work unit's actions, but before the completion of
those actions was guaranteed by resource managers 21. Two types of
interrupted work units are addressed: (1) Work units whose actions have
been committed by all domains 20, 32, . . . . These are identifiable by
the presence of logged events. By participating in REDO work unit recovery
processes resource managers repeat the committed actions and insure
externalization of those actions. (2) A subset of the work units may be
"commit-in-doubt", where the commit decision of coordinating domain 32 is
unknown. The work units in this subset are identifiable by the absence of
events logged to recovery log 40. Resource managers 21 participate in TODO
work unit recovery processes, and make the resources 44 affected
inaccessible to further activity until the decision is known and acted
upon.
(b) Resource Manager (RM) Forward Recovery Phase
Referring still to FIG. 7 in connection with FIG. 6, the second purpose of
the forward recovery phase is to provide resource managers 21 with the
means of collecting information from log 40 which is not associated with
interrupted work units. This information is typically used when the data
base 44 media contains objects potentially older than one committed
version. Segments of the media must be updated to reflect the actions of
completed (not interrupted) work units. Another use is to rebuild the
contents of a queue whose elements only exist on log 40. When establishing
their record selection criteria for this phase, resource managers can
provide recovery manager 28 with a beginning interest scope log position,
or a list of log positions.
Recovery manager 28 requests the log be positioned at the earliest log
position of interest to any resource manager. As shown in FIG. 7, this may
be before, at, or after BUR 112. It then reads log 40 in a forward
direction. All non-COLD starting resource mana | | |
