To accomplish the rebuild, DB2 moves the changed pages from the old GBP
structure to the new one. This is done in a parallel fashion, with the work being
done under multiple tasks across multiple DB2s. The work is spread out across
the members based on the page set and partition level castout ownership. If
there are insufficient data entries in the new GBP, the changed pages are cast
out to DASD.
In case of 100% loss of connectivity by all members, a new GBP structure will be
allocated when the first new connection to the GBP occurs. This will only be
allowed after the “Damage Assessment Pending” status has been cleared for
that GBP. It is important to note that this is not a rebuild but an allocation of a
new GBP cache structure. No GBP entries are recovered in this situation.
Recovery of GBP data in the event of a connectivity failure (which includes POR
and deactivations of CF LPs) is automatic for all GBPs defined with the option
AUTOREC(YES). With this definition DB2 can immediately detect the failure and
initiate the recovery. This improves availability for two reasons:
The recovery does not wait for manual intervention to detect the condition
before initiating the recovery process. Recovery starts immediately.
DB2 can avoid some of the overhead associated with issuing the START
DATABASE command. Drains, DB2 catalog accesses, and reading page set
header pages are all eliminated. This improves the performance of
recovering the GBP and LPL.
As a structure failure can be considered to be a connectivity
members of a DB2 data sharing group, GBP structure rebuild will
not take place. However, as described in “Connectivity Failures” on page 117,
the data can be recovered automatically. This also holds true for CF failures.
Manual structure rebuild allows the GBP structure to be
moved, reallocated, and populated without shutting down the DB2 data sharing
group. Availability is improved when CF maintenance needs to be performed or
GBP structures have to be redefined to improve performance. With this
enhancement, the SETXCF command can be used to rebuild the GBP structure
on the original CF or a different CF.
For more information on enhanced GBP rebuild and recovery support in DB2 for
OS/390 V5 and later release, see
DB2 UDB for OS/390 V6 Data Sharing: Planning
18.104.22.168 IRLM Lock Structures
Notice that as soon as the 7th IRLM member joins the group, IRLM rebuilds the
lock structure to go to a 4-byte-wide lock table entry. As soon as the 23rd IRLM
member joins the group, IRLM rebuilds the lock structure to go to a 8-byte-wide
lock table entry.
2.8.5 DB2 Structures and Volatility
DB2 structures can be allocated in any CF, regardless of volatility or
failure-isolation characteristics. APAR PQ16193 makes a change to the way DB2
allocates structures—prior to this APAR, DB2 would request a failure-isolated CF,
resulting in nonvolatile CF (which might be second in the PREFLIST) being used
instead of a volatile one (which might be first in the list). After this APAR is
applied, the DB2 structure is more likely to be allocated in the first CF in the list,
Parallel Sysplex Configuration, Volume 2: Cookbook
all other things being equal. DB2 will still issue a message to warn you if the
structure is allocated in a volatile CF.
However, for best availability, there are some considerations. First, the IRLM
lock structure and the SCA structure should both be placed in CFs that are
failure-isolated. If either of these structures, along with one of the connected
DB2s, are lost at the same time, a group restart is required.
For the GBPs, we strongly recommend using duplexing to protect the GBPs from
a loss of a CF. There is no additional CF storage required—you will just be using
storage that would otherwise have been reserved as part of the white space.
And the additional CP CF requirement is not significant: see
DB2 UDB for OS/390
Version 6 Performance Topics
, SG24-5351, which contains information about the
capacity and performance implications of duplexing.
Additionally, if possible, you should use a nonvolatile CF for all the DB2
structures. The advantage of a nonvolatile CF is that if you lose power to a
nonvolatile CF, the CF enters power save mode, saving the data contained in the
structures. When power is returned, there is no need to do a group restart, and
there is no need to recover the data from the GBPs. For DB2 systems requiring
high availability, nonvolatile CFs are recommended. If your CF does not have a
battery backup but has some other form of UPS, then the state can be set to
nonvolatile through an operator command to the CF. See 2.1.3, “CF
Volatility/Nonvolatility” on page 67.
Chapter 2. A Structured View of CF Structures