Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

System and method to enable high speed recovery of RDBMS objects

IP.com Disclosure Number: IPCOM000245841D
Publication Date: 2016-Apr-13
Document File: 8 page(s) / 100K

Publishing Venue

The IP.com Prior Art Database


Design of a backup and recovery infrastructure that will enable a high speed recovery of RDBMS object(s) in general and DB2 for z/OS objects in particular. DB2 for z/OS allows database Indexes to be backed up and hence allow recovery using the backup copies. This process caters exclusively to huge critical tables that are used heavily for Read(s) and Write(s).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

Page 01 of 8

System and method to enable high speed recovery of RDBMS objects

Most of the transaction tables used by applications today are huge and is practically in use all the time. They are often prone to data corruption due to faulty execution of application processes. Swift recovery to a stable point in time is critical for the business. The recovery activity involves recovering the table objects and rebuilding any Indexes defined on the table. This has always been a very critical and time consuming activity. The time taken may vary from several minutes to hours depending on various factors. Every single minute of outage is critical to the application as it impacts the business directly.

The most important thing to be addressed here is the time to recover objects. The proposed method to address this situation has the following salient features:
1. An intelligent agent that will be part of the RDBMS as a Daemon process that proactively determines requirement for taking backup and also help arrive at a optimal recovery route in case of a recovery scenario.

2. A novel method to arrive at the accurate amount of update activity on a given table over log ranges is proposed.

3. Ability to liaise with any system level backups to create recovery points for individual objects.

4. Proposal to use flash copies for Indexes that will be used for recovering Indexes rather than rebuilding them to speed up the recovery process.

The design of the proposed method is described in the below section.

A new tablespace parameter (FREC) is introduced for Database Administrators to either enable or disable the use of high speed recovery. For tables that have the FREC option enabled, DB2 will trigger incremental image copies of candidate table(s) and snapshot copies of its associated Indexes that meet certain special conditions.

Whenever there is a requirement to recover a tablespace to a point in time, the high speed recovery process will do the following:

1. Perform a innovative log analysis to ascertain the possibility of log based recovery instead of a costly backup based recovery. If it is deemed feasible, a log based recovery is done. Else, the processing continues to the next step.

2. Look up the system table that stores image copy information for tables and generate a list of full image copy and any subsequent incremental copies taken before the point of recovery. It will also locate the flash copies of the associated Index(es).

3. Recover the tablespace by merging the full image copy and any subsequent incremental copies.

4. Recover the Indexes using the flash copies.

5. Read the RDBMS transaction log to apply any changes that may have happened on the object since the latest image onto to the tablespace and Index(es). The need to rebuild Index(es) separately is eliminated.

The simultaneous recovery of both the tablespace and its Index(es) will lead to faster recovery times.

Acronyms that will be used in the following sections are as follows:

RDBMS - Relat...