Browse Prior Art Database

Smarter thread level recovery from invalid data from application onto database level

IP.com Disclosure Number: IPCOM000240558D
Publication Date: 2015-Feb-09
Document File: 5 page(s) / 167K

Publishing Venue

The IP.com Prior Art Database

Abstract

For a set of applications, it is extremely difficult to restore a single or group of database objects/tables due to the complexity involved. Such applications have referential integrity maintained at program (application) level and not at database object level. For ex, when a Job/script has performed incorrect updates on multiple critical database objects/tables which resulted in bad/invalid data. Application transaction would return wrong/unexpected results while accessing the bad/invalid data, could lead to major outage to business. In this scenario, the business/application team has decided to undo the updates made by the particular job/script. When multiple jobs/scripts has updated multiple critical database objects/tables then the impact could be huge and complex to recover every single object(s) by using the existing object level recovery solution. The new proposed technique addresses the challenges with existing recovery process. It introduces new data recovery solution based on thread level instead of object level. The new technique introduces two new concepts. a) Recovery by thread level. b) System level backward log recovery.

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

Page 01 of 5

Smarter thread level recovery from invalid data from application onto database level

The concept/technique 'recovery by thread level' is further split into two solutions.


a) Option to back out/roll back the update made by specific committed thread(s) and subsequent updates to the object(s) made by other committed thread(s) to restore data consistency.

b) Option to back out/roll back the update made by specific committed thread(s) alone provided there are no further updates made by other subsequent committed thread(s) to the same object(s) and its corresponding page(s) accessed by thread(s) being recovered.

The concept/technique 'system level backward log recovery' addresses option to restore the database/sub system data to the required/desired point in time by 'roll backward log' method. It identifies the list of Committed threads between the current point (current state) and desired recovery point (old state) and performs rollback/undo the database changes from current point (current state) to the desired point of consistency (old state). The existing object recovery technique becomes more complex and tedious when multiple objects are involved in the recovery. The new technique overcomes the existing limitations and speeds up the recovery

process. In the existing scenario there is no problem with uncommitted thread(s) as part of any recovery. The new solution aims to solve the problem for committed threads.

Thread level recovery

I. The new technique performs recovery by THREAD as entity. Every THREAD has CORRELATION-ID/THREAD-ID and using this the new UTILITY performs the recovery by applying the UNDO log records to roll back the COMMITTED changes.

II. The new approach recovers all database objects updated by any particular THREAD(s) when compared to the existing recovery method which works on individual objects. It also eliminates the delay(s) while recovering multiple objects and RI scenarios using existing recovery method.

III. The new method provides precise data recovery approach by providing the following options

I. Rollback/undo changes made by any committed thread(s) being recovered and subsequent committed thread(s) that has updated the same object(s).

II. Rollback/Undo changes made by any committed thread(s) being recovered and leave the updates/changes made by the subsequent committed thread(s) on the same object(s).

III. Rollback/Undo the changes made at database level (all committed threads) between current point and the previous required point in time. This option will be quite useful for scenarios that require rollback/undo all changes made to the database by the committed thread(s) between desired point of consistency or between current point and the previous consistent point.


IV. The new approach completely eliminates the analysis and sequencing the recovery

procedure while processing objects with referential integrity (RI). The new approach

performs recovery by committed THREAD(s) and not by individual object(s...