Databases Reference
In-Depth Information
user transactions
undo transactions
Repair
Manager
Scheduler
Recovery
Log
Cache
Manager
Fig. 4.
Architecture of an On-the-fly Repair System
in the
su
x
of the rewritten history. The sux starts with
B
F
1
. Note that the
last transaction in the rewritten history should be the first one to compensate,
and
B
F
1
should be the last one. Since every legitimate, unaffected transaction
will precede
B
F
1
, the work of all unaffected transactions will be kept. More-
over, since affected transactions may precede
B
F
1
1
, the work of many affected
transactions may be saved as well.
4.3 Dynamic DQR Solutions
In static DQR, new transactions are blocked during the repair process. This
prevents static DQR mechanisms from being deployed by 24*7 database appli-
cations. As 24*7 database applications are becoming more and more common,
dynamic DQR solutions that can do non-stop, zero down-time attack recovery
are in demand.
Dynamic DQR Solutions with Reactive Quarantine
To have zero down-time, neither damage assessment nor repair can block the
execution of new transactions. This means that dependency analysis, execu-
tion of new transactions, execution of cleaning transactions, and reexecution of
affected transactions need to be done in parallel. To meet this challenge, peo-
ple may wonder if the traditional transaction management architecture needs
to be rebuilt. Fortunately, Figure 4 shows that the traditional transaction
management architecture [3] is adequate to accommodate on-the-fly repair.
The
Repair Manager
is applied to the growing logs of on-the-fly histories to
mark any bad as well as affected transactions. For every bad or affected trans-
action, the Repair Manager builds a cleaning transaction and submits it to
the
Scheduler
. The cleaning transaction is only composed of write operations.
The
Scheduler
schedules the operations submitted either by user transactions
or by cleaning transactions to generate a correct on-the-fly history. Affected
transactions that are semantically revoked (or undone) can be resubmitted to
the Scheduler either by users or by the Repair Manager. Finally, the
Recovery
Manager
executes the operations submitted by the Scheduler and logs them.
