Browse Prior Art Database

PDAR - Pool Dispense Array for Restore

IP.com Disclosure Number: IPCOM000200602D
Publication Date: 2010-Oct-20
Document File: 6 page(s) / 35K

Publishing Venue

The IP.com Prior Art Database

Abstract

PDAR - Pool Dispense Array for Restore - to avoid database corruption after database restore

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

Page 01 of 6

PDAR - Pool Dispense Array for Restore

Disclosed is a process to reserve a number of pool records that will remain free between a time a backup copy is taken and a time an actual restore occurs. Using an embodiment of the disclosed

p

 rocess, during a restore process a demand for a pool record is satisfied from a set of reserved records.

Using an embodiment of the disclosed process an airline control system (ALCS) will be able to guarantee none of the records dispensed during duration of a restore process will be found in a LOG file therefore avoiding any sort of corruption.

A basic architecture of real-time systems consists of conversational software linked to a database where application transactions simultaneously make inquires and updates. One of several other characteristics of ALCS is a capability to restore a database to a checkpoint position after a failure or disaster over the database. Generally the restore logic uses update log records to restore uncommitted data.

For each database update a copy of the updated record is stored in a sequential log file. A backup copy (checkpoint) of the database is taken regularly. When a failure or disaster occurs the database can be restored from the backup copy and the log file can be applied to commit updates processed between the backup and the failure. The log file is applied by reading sequentially and moving updated version of records found in the log to the database.

A peculiar concept unique to ALCS is a set of pre-defined records that can be shared by the application. Each record of this set can be obtained or released by the application depending on the application need. Within ALCS those records are known as Pool Records. The general restore technique currently used by ALCS described above does not entirely cope with Pool Records.

At backup copy time a certain Pool Record may be free. By the time a failure happens, that same Pool Record might be used by the application. Therefore versions of the record may exist in which one is as a free record at the backup copy time, and the other version is in the log file as taken by the application.

When the restore process begins, the database is restored from the backup copy and that Pool Record is shown as free. Then the log file is applied. In the meantime, it is possible that an application requires a free record, but that Pool Record is taken. When that happens, and the updated version of that Pool Record found in the Log file is processed the new information just stored by the application will be lost.

In the ALCS system a restore process run without application interference. However exceptions happen and a Pool Record may be taken by an application while a restore is running.

The disclosed process typically addresses the corruption of Pool Records on the ALCS system

1


Page 02 of 6

after a restore process. A new subgroup of records within the Pool Records set is defined. The subgroup of records is classified as reserved and is un...