Chapter 8. Monitoring the Siebel 7 database 133
򐂰 Disaster recovery with additional hardware
This is a broad topic that varies widely in both user requirement and scenario
implementation. The scenario PIT recovery using suspension of DB2
updating on page 139 could provide a starting point in addressing your
disaster recovery requirements. This scenario will require high-speed
hardware to get copies of your DB2 log, BSDS, and data offsite.
8.6.3 Point-in-time recovery
The usual reason for a point-in-time recovery is an application programming error
or a flawed operational procedure. This exposure is always present, regardless of
your hardware/software configuration. A point-in-time recovery, in a Siebel
environment, has the potential to be the most disruptive outage you are likely to
You may need to recover all Siebel-DB2 objects to a prior point in time.
Depending on how you have mapped your tables to table spaces, this could
mean recovering 181 table spaces and 13,244 indexes to a prior point of
consistency. Your usual point-in-time recovery techniques, which you probably
regard as conventional at this time, may be insufficient in this environment.
A failure in the application caused by a programming defect, or in a flawed
operational procedure, such as running a job twice, introduces the requirement
for point-in-time recovery. As much as possible, you will want to avoid PIT
recovery with preventive measures such as increased attention to:
򐂰 Change management
򐂰 Problem management
򐂰 Tes tin g
Each of these disciplines is procedure-oriented and management-driven. As
attention to these disciplines is increased, the need for point-in-time recovery is
usually decreased. Unfortunately, the need for point-in-time recovery is never
entirely eliminated. Consequently, you will want to make every effort to avoid
having to do a point-in-time recovery, but you should be prepared to do one if
Note: The discussion on recovery in this section relates to the DB2 database
only. Keep in mind that if you perform a PIT recovery on the database you also
need to recover the Siebel file system to the same point in time as the
134 Siebel 7 with DB2 for z/OS: Database Implementation and Administration Guide
Unless you are facing an application error and you have guidance from Siebel on
which exact subset of tables requires PIT recovery, you will be required to reset
all Siebel tables to a prior point of consistency.
There are several techniques to effect a point-in-time recovery, including:
򐂰 PIT recovery using user-written application programs
򐂰 PIT recovery using DB2 utilities
The DB2 Quiesce and Copy utilities are the primary tools.
򐂰 PIT recovery using a Dump/Restore scenario
This scenario typically employs non-DB2 utilities.
򐂰 PIT recovery using a DB2 conditional restart
Any conditional restart scenario is potentially risky. The benefit of this
scenario is the effectively free definition of the candidate points of
consistency. Candidate points of consistency are a set of points on the log.
Consistency may be established at any point in the set that you choose.
򐂰 PIT recovery using suspension of DB2 updating
DB2 update activity is suspended using the SET LOG command to
SUSPEND/RESUME logging. This function was introduced into DB2 in V6.
In the following sections, we discuss these techniques in more detail.
PIT recovery using user-written application programs
This is a strategic direction and not a scenario. It acknowledges that data can be
corrupted due to program error. If this happens, you may attempt to correct the
contaminated data with application programs. If you fail to correct the data with
application programming, a scenario such as one of those following could be
used as a last resort. This approach is gaining favor among users striving for high
In implementing an approach like this, it is important to determine which
transactions will make the data more corrupt or propagate the errors. This
information then can either be communicated to end users, or the DBA can use it
to disable the erroneous processes.
PIT recovery using DB2 utilities
The scenario for a PIT recovery using DB2 utilities is as follows:
򐂰 Execute the QUIESCE utility on all of the tables that are candidates to be
reset if a PIT recovery is required.
This causes the DB2 buffers for the quiesced tables to be externalized to

Get Siebel 7 with DB2 for z/OS: Database Implementation and Administration Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.