Architecture I has the following properties: (1) It builds
itself on top of an “off-the-shelf” DBMS. It does not require
the DBMS kernel to be changed. It has almost no impact on
the performance of the database server except that the
Mediator can cause some service delay and the cleaning
transactions can make the server busier. (2) The
self-healing processes are all on-the-fly. (3) During attack
recovery, the data integrity level can vary from time to time.
When the attacks are intense, damage spreading can be very
serious, and the integrity level can be dramatically lowered.
In this situation, asking the Mediator to slow down the
execution of new transactions can help stabilize the data
integrity level, although this can cause some availability
loss. This indicates that integrity and availability can be two
conflicting goals in self-healing. (4) More availability loss
can be caused when (a) the Intrusion Detector raises false
alarms; or (b) a corrupted object is located (It will not be
accessible until it is cleaned. Making damaged parts of the
database available to new transactions can seriously spread
the damage). (5) Inaccuracy of intrusion detection can
cause some damage to not be located or repaired. (6)
Architecture I is not designed to and cannot handle physical
world attack recovery, which usually requires many
additional activities. Logically repairing a database does
not always indicate that the corresponding physical world
damage can be recovered.