ACTIVE & REAL TIME

DATABASES
A PRESENTATION BY

ANKIT SHARMA (24/AFI/05)

GANESH GUTTI (24/AFI/25)
 PASSIVE DATABASES

• Traditional database management systems (DBMS) are

passive in the sense that commands are executed by the
database (e.g., query, update, delete) as and when
requested by the user or application program.
• It has passive update principle. That is, client controls
DBMS updates.
• However, some situations cannot be effectively modeled
by this pattern.
2
 CONVENTIONAL DATABASES
PASSIVE DATABASES
T1: 25 copies of
Korth sold

Less than 5 copies of

Korth in stock?
DBMS Records
Order 100
More copies

3
PROBLEM WITH TRADITIONAL DATABASE
SYSTEMS: EXAMPLE

• As an example, consider a railway database where data are

stored about trains, timetables, seats, fares, and so on, which
is accessed by different terminals.
• In some circumstances (e.g., public holidays, cultural
events) it may be beneficial to add additional coaches to
specific trains if the number of spare seats a month in
advance is below a threshold value.
• How to administer this situation in the passive database?
4
RESOLUTION OF THE SITUATION:
EXAMPLE

Two options are possible:

• Add the additional monitoring functionality to all
booking programs so that the preceding situation is
checked each time a seat is sold.
• However, this approach leads to the semantics of
the monitoring task being distributed, replicated, and
hidden among different application programs.
5
RESOLUTION OF THE SITUATION:
EXAMPLE

• The second approach relies on a polling mechanism that

periodically checks the number of seats available.
• The difficulty in this approach stems from ascertaining
the most appropriate polling frequency.
• If too high, there is a cost penalty.
• If too low, the reaction may be too late (e.g., the coach is
added, but only after several customers have been
turned away). 6
SOME MORE EXAMPLES OF REAL- WORLD
PROBLEM NOT WELL SUITED FOR PASSIVE
UPDATE PRINCIPLE:

• Inventory control - reordering items when quantity in stock

falls below threshold.

• Travel waiting list - book ticket as soon as right kind is

available

• Stock market - Buy/sell stocks when price below/above

threshold

7
 ACTIVE DATABASES
• Active databases support the preceding application by moving
the reactive behavior from the application (or polling
mechanism) into the DBMS.
• Active databases are thus able to monitor and react to specific
circumstances of relevance to an application.
• An active database system must provide a knowledge model
(i.e., a description mechanism) and an execution model
(i.e., a runtime strategy) for supporting this reactive behavior.
8
 ACTIVE DATABASES
1. Active DBMS provides: Regular DBMS primitives + definition of
application-defined situations + triggering of application-defined
reactions
‣ being able to react automatically to situations in the database
‣ allowing the specification and implementation of reactive behavior
2. Active DBMS
• Embed situation-action rules in database
• Support many functionalities:
E.g. Integrity control, derived data, change notification
9
• Active DBMS functionality commercially available in SQL:99 as triggers
 ACTIVE DATABASES

Recognize predefined situations in database

• Trigger predefined actions when situations occur
• Actions are usually database updates
Active Rules – rules that are automatically triggered by
events in the database.

10
 ACTIVE DATABASES
T1: 25 copies of
Korth sold

Less than 5 copies of

Korth in stock?
DBMS Records
Order 100
More copies

On update of sales
when 11
Quantity <5
 TRIGGERS
• Triggers is a concept that is technique for specifying certain
types of active rules in the database.
• A data base that has a set of associated triggers is called an
active data base.
• Trigger is like a procedure that is automatically invoked by the
DBMS in response to specified changes to data base.
• Trigger is like a ‘Daemon that monitors a data base, and is
executed when the data base is modified in a way that matches
the event specification
12
 TRIGGER PARTS
Triggers work in ECA model. It has three parts:
• Event : A change to data base that activates the trigger
• Condition: A trigger restriction specifies a Boolean
(logical) expression must be TRUE for the trigger to fire
• Action: A procedure that is executed when the trigger is
activated. Similar to stored procedures, a trigger action can
contain PL/SQL statements

13
 TYPES OF TRIGGERS
An SQL statement may change several rows.
• Apply action once per SQL statement.
• Apply action for each row changed by SQL statement.
Row Triggers
• A row trigger is fired each time the table is affected by the triggering
statement.
• If a triggering statement affects no rows, a row trigger is not executed at all.
Statement Triggers
• A statement trigger is fired once on behalf of the triggering statement,
regardless of the number of rows in the table that the triggering statement
affects (even if no rows are affected) 14
 TRIGGER TIMINGS
Actions may apply before or after the triggering event is
executed.
Before Trigger
• Execute the trigger action before the triggering statement.
• Eliminate unnecessary processing of the triggering statement.
After Trigger
• AFTER triggers are used when you want the triggering
statement to complete before executing the trigger action 15
AVAILABILITY

Triggers included in SQL 1999 (SQL 3)

• Not in earlier standards.

Included much earlier in most products:

• Oracle, Sybase, DB2

• As a consequence, syntax may

differ from the standard.

16
 CREATING A TRIGGER

CREATE [OR REPLACE ] TRIGGER trigger_name

{BEFORE | AFTER } {INSERT [OR] | UPDATE [OR] | DELETE}
[OF col_name] ON table_name
[FOR EACH ROW]
DECLARE
Declaration-statements
BEGIN
Executable-statements
END trigger_name;
17
 E-C-A MODEL
• Most active databases support a knowledge model that uses rules
with three components: an event, a condition, and an action.
• The event part of a rule describes a happening to which the rule may
be able to respond.
• The condition part of the rule examines the context in which the
event has taken place.
• The action describes the task to be carried out by the rule if the
relevant event has taken place and the condition has evaluated to
true.
18
 EVENTS
An event is something that happens at a point in time.
Possible alternatives:
• structure operation (insert, update, access);

• behavior invocation (the message display is sent to an object of type widget);

• transaction (abort, commit, begin-transaction);

• exception (an attempt to access some data without appropriate authorization);

• clock (the first day of every month);

• External (the temperature reading goes above 30 degrees)

19
 CONDITION
• The condition indicates whether rule action should be executed.
• In ECA-rules, the condition is generally optional.
• Once the triggering event has occurred , the condition may be
evaluated. If condition evaluates to be true, the rule action will be
executed.
• If no condition is specified, the action will be executed once the event
occurs.

20
 ACTION
The range of tasks that can be performed if the rule condition
is evaluated to be true.
It is usually a sequence of SQL statements.
But actions may:
• Perform some behavior invocation within the database or an
external call,
• inform the user or system administrator of some situation,
• abort a transaction,
• take some alternative course of action using do-instead
21
EXECUTION MODEL OF ACTIVE DATABASES

• The execution model specifies how a set of rules is treated at

runtime.
• Although the execution model of a rule system is closely related to
aspects of the underlying DBMS (e.g., data model, transaction
manager), there are a number of phases in rule evaluation.

22
EXECUTION MODEL OF ACTIVE DATABASES

• The signaling phase refers to the appearance of an event

occurrence caused by an event source.
• The triggering phase takes the events produced thus far, and
triggers the corresponding rules.
• The evaluation phase evaluates the condition of the triggered
rules.
• The scheduling phase indicates how the rule conflict set is
processed.
• The execution phase carries out the actions of the chosen
rule instantiations.
23
 DESIGN AND IMPLEMENTATION
ISSUES FOR ACTIVE DATABASES
An active database should allow users to make the following
changes to triggers (rules)
• Activate
• Deactivate
• Drop
A deactivated rule will not be triggered by the event. This feature
will allow user to selectively deactivate rules for certain periods
of time when they are not needed.
The activate command will make the rule active again.
The drop command deletes the rule from the system. 24
 DESIGN AND IMPLEMENTATION
ISSUES FOR ACTIVE DATABASES
⮚ The second issue is whether the triggered action should be
executed before, after or concurrently with the triggering
event.
⮚ The issue is whether the action being should be considered to
be part of the same transaction that triggered the rule.
⮚ An event can be considered in 3 ways
• Immediate consideration
• Deferred consideration
• Detached consideration
25
 DESIGN AND IMPLEMENTATION
ISSUES FOR ACTIVE DATABASES
Immediate consideration
▪ Part of the same transaction and can be one of the following
depending on the situation, Oracle uses this model
• Before
• After
• Instead of
Deferred consideration
• Condition is evaluated at the end of the transaction
Detached consideration
• Condition is evaluated in a separate transaction 26
 ACTIVE DATABASE APPLICATIONS
In the case of active rules, the following categories of
application can be distinguished.
ECA rules have been used:
• To support integrity constraints,
• In materialized views
• Maintenance of derived data
• Coordination of distributed computation
• Transaction models
• Advanced data modeling constructs
• Automatic screen updating in the context of database change.
27
EXAMPLE: CALCULATING DERIVED COLUMNS
SQL>CREATE OR REPLACE TRIGGER derive_commission_trg
2 BEFORE UPDATE OF sal ON emp
3 FOR EACH ROW
4 WHEN (new.job = 'SALESMAN')
5 BEGIN
6 :new.comm := :old.comm * (:new.sal/:old.sal);
7 END;
8 /
Trigger name: derive_commission_trg
Timing: BEFORE executing the statement
Event: UPDATE of sal column
Condition: job = ‘SALESMAN’
Target: emp table
Parameters: old, new
28
Trigger action: calculate the new commission to be updated
 EXAMPLE: COUNTING STATEMENT
EXECUTION
SQL>CREATE OR REPLACE TRIGGER audit_emp
2 AFTER DELETE ON emp
3 FOR EACH ROW
4 BEGIN
5 UPDATE audit_table SET del = del + 1
6 WHERE user_name = USER
7 AND table_name = 'EMP’;
7 END;
8 /

Whenever an employee record is deleted from database, counter in an

audit table registering the number of deleted rows for current user in
system variable USER is incremented.
29
 EXAMPLE: RECORDING CHANGES
SQL>CREATE OR REPLACE TRIGGER audit_emp_values
2 AFTER DELETE OR UPDATE ON emp
3 FOR EACH ROW
4 BEGIN
5 INSERT INTO audit_emp_values (user_name,
6 timestamp, id, old_last_name, new_last_name,
7 old_title, new_title, old_salary, new_salary)
8 VALUES (USER, SYSDATE, :old.empno, :old.ename,
9 :new.ename, :old.job, :new.job,
10 :old.sal, :new.sal);
11 END;
12 /
Whenever some details for an employee are deleted or updated, both the previous and new details
are recorded in an audit table to allow tracing the history of changes. An insert operation cannot be
recorded with this trigger as old.empno has no value. 30
 EXAMPLE: PROTECTING REFERENTIAL
INTEGRITY
SQL>CREATE OR REPLACE TRIGGER cascade_updates
2 AFTER UPDATE OF deptno ON dept
3 FOR EACH ROW
4 BEGIN
5 UPDATE emp
6 SET emp.deptno = :new.deptno
7 WHERE emp.deptno = :old.deptno;
8 END
9 /

Whenever the department number changes, all employee records for this
department will automatically be changed as well, so that the employees
will continue to work for the same department.
31
 CONTROLLING TRIGGERS USING SQL

• Disable/Re-enable database trigger

ALTER TRIGGER trigger_name DISABLE | ENABLE

• Disable or Re-enable all triggers for table

ALTER TABLE table_name DISABLE | ENABLE ALL TRIGGERS

• Removing a trigger from database

DROP TRIGGER trigger_name

32
Compensation and
Databases Recovery
33
1. Introduction to Database Recovery
2. Types of Failures in Databases
3. Compensation and Logging Mechanisms
4. Database Recovery Techniques (Examples)
5. Real-World Applications (With Case Studies)
6. Challenges and Solutions in Database
Recovery 34
 Introduction to Database Recovery

• Database recovery is the process of restoring

the database to a correct, consistent state
after an error or failure.
• Examples:
- In a banking system, a database crash during
a money transfer must ensure that either both
accounts reflect the transaction or neither
does.
35
 Types of Failures in Databases

1. Transaction Failure: Errors within transactions make them

impossible to complete.
- Example: User inputting invalid data during a bank
transfer.
2. System Failure: Unexpected shutdowns due to hardware or
power issues.
- Example: A server crash mid-operation.
3. Media Failure: Permanent damage to the storage medium.
- Example: A corrupted database disk leading to loss of
36
records.
 Compensation in Databases

● Compensation is the process of undoing or mitigating

the effects of incomplete or failed transactions.
● Example: In an e-commerce system, if a transaction
fails while debiting payment but doesn’t update order
status, compensation reverses the payment or updates
the status.
● Types of Compensation:
- Rollback: Reverts changes made by failed transactions.
- Undo Operations: Performed when a transaction
cannot be completed. 37
 Types of Logging in Databases

1. Undo Logging: Logs the original value (before-image)

before a change is made. Recovery can "undo" the
operation if failure occurs.
Example: Undo logs revert changes if a system crash
occurs mid-update.
2. Redo Logging: Logs the new value (after-image) so the
system can "redo" any committed changes after failure.
Example: Redo logs ensure successful order processing
even if the system crashed after the operation. 38
 Transaction Logging Explained (Example)

• Scenario: A banking system processes a $100

transfer from Account A to Account B.
• - If a crash occurs after debiting A but before
crediting B, logs restore consistency.
• - Step-by-step: Undo log reverts incomplete
actions; redo log finalizes committed
transactions.
39
 Recovery Techniques (Examples)

1. Deferred Update: Applies changes only after a transaction is

committed.
- Example: Flight booking system confirms seat only after payment is
complete.
2. Immediate Update: Updates are made immediately, rollback is used
if necessary.
- Example: Inventory system deducts stock as soon as the sale starts.
3. Shadow Paging: A copy of the database is made before executing a
transaction.
- Example: Power outage protection by keeping original data intact.
40
 Checkpointing in Databases

• A checkpoint is a point where the database

state is saved, minimizing the amount of data
that needs to be reprocessed after failure.
• Example: Large retail systems save a
checkpoint every hour to ensure fast recovery
in case of failure.

41
 Two-Phase Commit Protocol (2PC)

2PC ensures that in distributed systems, all parties either

commit or abort a transaction.
Steps:
1. Prepare Phase: Coordinator checks if all participants
are ready to commit.
2. Commit Phase: If all are ready, transaction is
committed, otherwise aborted.
Example: Global banking systems require all accounts to
reflect the transaction. 42
Practical Example of Database Recovery

• Case Study: In 2012, an AWS database failure

affected multiple websites.
• AWS used redo logs and shadow paging to
restore services quickly by redoing committed
operations and using shadow pages to avoid
data loss.

43
 Real-World Applications

1. Banking Systems: Recovery ensures accurate

money transfers.
2. E-commerce Platforms: Orders and inventory
are recovered to ensure customer satisfaction.
3. Healthcare Systems: Medical data is restored
after failures to ensure patient records are up-
to-date.
44
Challenges in Database Recovery

Challenges:
- Managing large volumes of data.
- Balancing consistency with availability.
- High costs for advanced recovery systems.
Solutions:
- Use of advanced log processing algorithms and
distributed recovery protocols. 45
 Conclusion

• Summary: Compensation and database

recovery are essential for maintaining data
integrity and system stability.
• Final Thought: As databases grow, recovery
mechanisms must evolve to ensure seamless
operations.

46
Thank you