Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

DATA RECOVERY FROM BACKUP MADE VIA A NON-DATABASE UTILITY

IP.com Disclosure Number: IPCOM000013042D
Original Publication Date: 2001-May-01
Included in the Prior Art Database: 2003-Jun-12
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

Disclosed is a technique whereby it is possible to recover a database to its current state by using the backup copy made by a non-database utility and then applying the database log. To recover from a disk failure, customers make a backup copy of the database periodically via utilities which take advantage of the device geometry, such as Hierarchical Storage Management (HSM). These utilities are outside the scope of the database system and are faster than database utilities such as image copy. DBMS maintains a log-sequence-number (LSN) in the first page of the database called the header page. (The LSN is referred to as the LSN-Header here.) DBMS updates the LSN-Header by recording the LSN of the current-end-of-log when it closes the database and at least one update was performed while the database was open. Periodically, e.g., every nth checkpoint of the database system, it records the LSN as the LSN of the restart-redo-point for every database which is open and to which at least one update has been made since the database was opened. The LSN ranges corresponding to the first update to the database and its close are maintained by DBMS and are kept in a system database called SYSLGRNG. The ranges are referred to as LSN-First-Update and LSN-Close respectively. The LSN-Close recorded is the same as the LSN-Header in the header page. These ranges are used as filters when log apply is done for recovery.

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

Page 1 of 2

DATA RECOVERY FROM BACKUP MADE VIA A NON-DATABASE UTILITY

Disclosed is a technique whereby it is possible to recover a database to its current state by using the backup copy made by a non-database utility and then applying the database log.

To recover from a disk failure, customers make a backup copy of the database periodically via utilities which take advantage of the device geometry, such as Hierarchical Storage Management (HSM). These utilities are outside the scope of the database system and are faster than database utilities such as image copy.

DBMS maintains a log-sequence-number (LSN) in the first page of the database called the header page. (The LSN is referred to as the LSN-Header here.) DBMS updates the LSN-Header by recording the LSN of the current-end-of-log when it closes the database and at least one update was performed while the database was open. Periodically, e.g., every nth checkpoint of the database system, it records the LSN as the LSN of the restart-redo-point for every database which is open and to which at least one update has been made since the database was opened.

The LSN ranges corresponding to the first update to the database and its close are maintained by DBMS and are kept in a system database called SYSLGRNG. The ranges are referred to as LSN-First-Update and LSN-Close respectively. The LSN-Close recorded is the same as the LSN-Header in the header page. These ranges are used as filters when log apply is done for recovery.

A copy of the header page by the Backup utility is required prior to copying other pages of the database. This is not required however, if the database is put in R/O mode prior to making a backup copy. If all databases on disk are put in R/O mode then a disk dump can be taken to make the backup.

Recovery involves restoring the backup copy of the database on disk and then applying the log. To do this DBMS would examine the LSN in the header page (of the restored copy) and the log ranges in SYSLGRNG to determine the log-point from which to start the log apply. There are the following possibilities:

    -The backup was made when the database was closed, in which case the LSN-Header would be equal to the LSN-Close of the last entry in SYSLGRNG. No log apply is needed, the restored copy

can be used.

    -The backup was made when the database was open, in which case the LSN-Header is less than an LSN-First-Update recorded in SYSLGRNG. The log apply would do log apply starting from the

LSN-He...