Siebel 7 with DB2 for z/OS: Database Implementation and Administration Guide

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

encounter.

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

required.

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

database.

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

availability.

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

DASD.