SSZG518: Database design and

Applications

BITS Pilani Prof. Uma Maheswari

Pilani Campus
 BITS Pilani
Pilani Campus

Session Query Processing

TUTORIAL
QUERY PROCESSING

BITS Pilani, Pilani Campus

Query Processing

Query tree draw:

Select s.name from student s,course c where s.age>50;

BITS Pilani, Pilani Campus

Query Processing

BITS Pilani, Pilani Campus

Query Processing
Estimate size (=cardinality) in a bottom-up fashion
– This is the most difficult part, and still inadequate intoday’s query optimizers

Estimate cost by using the estimated size

– Hand-written formulas, similar to those we used for computing the cost of each
physical operator

BITS Pilani, Pilani Campus

Query Processing
Cost-based Query Optimization¶ Database Statistics¶
•Compute database statistics regarding each table. This can be
• Given alternate query trees, find the lowest cost
accomplished using the Analyze command in SQL.
one.
•Simplest statistics:
• We do not really need to generate all possible query • TUPLES(R): the number of tuples in R
trees, but find: • PAGES(R): the number of pages R spans
• All potential access paths for selections (indices and table scans) • N_DISTINCT(R.A): the number of distinct values stored
• Join orderings that combine these access paths with specific join for R.A
implementations • MINVAL(R.A)/MAXVAL(R.A): min/max values stored for
• Estimate the cost of a partial query plan and eliminate other plans
that can never be cheaper.
R.A

• To be able to estimate the cost of query plans, we

need to know:
• Cardinality estimation: How many tuples we expect as the output of
joins and selections
• Space estimation: The size of the tuples on disk to estimate how
many disk pages are needed to store them.

BITS Pilani, Pilani Campus

Query Processing

BITS Pilani, Pilani Campus

Condition in Where clause and
Selectivity

BITS Pilani, Pilani Campus

Condition in Where clause and
Selectivity

BITS Pilani, Pilani Campus

Condition in Where clause and
Selectivity

BITS Pilani, Pilani Campus

Query optimization using heuristics:

BITS Pilani, Pilani Campus

Query optimization using heuristics:

BITS Pilani, Pilani Campus

Query optimization using heuristics:

BITS Pilani, Pilani Campus

Query optimization using heuristics:

BITS Pilani, Pilani Campus

Example

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

Solution

Since rating > 5

Ie., high rated sailors
500/2=250

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

Solution

Ie., 1000/100

BITS Pilani, Pilani Campus

Problem

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

Query Optimization example.

BITS Pilani, Pilani Campus

Problem

BITS Pilani, Pilani Campus

Solution

BITS Pilani, Pilani Campus

 Problem
Consider the relations:
vehicle (reg_no, make, colour)
Person (eno, name, address) i) Draw the initial TWO query trees.
Owner (eno, reg_no) ii) Compute cost of TWO query trees
Draw and compare the cost of two Query Tree for the query iii) Which is less expensive QUERY PLAN
Select eno, name, reg_no from Person, Owner
Where Person.eno = Owner.eno and Person.name = ‘Tori’;

Statistical data for the relations are :

Vehicle:
– Each tuple is 40 bytes long, 100 tuples per page, 1000 pages.
– Let’s say there are 10000 vehicles.
Person:
– Each tuple is 50 bytes long, 80 tuples per page, 500 pages.
– Let’s say there are 8000 Persons.
No Indexes are available for both relations.
Owner:
– Each tuple is 20 bytes long, 80 tuples per page, 500 pages.
– Let’s say there are 3000 Owners.

BITS Pilani, Pilani Campus

Solution

Optimized
tree

BITS Pilani, Pilani Campus

Thank you.

BITS Pilani, Pilani Campus

 SSZG518: Database design and
Applications

BITS Pilani Prof. Uma Maheswari

Pilani Campus
 BITS Pilani
Pilani Campus

Session 8 TRANSACTIONS
TUTORIAL
LEARNING OUTCOME

 Introduction to transactions
 States of a transaction
 Desirable properties of a transaction
 Schedules
 Concurrent transactions
 Serializability

REFER: T1-Chapter 17
Sections: 17.1- 17.6

BITS Pilani, Pilani Campus

Transaction

BITS Pilani, Pilani Campus

MYSQL and MS SQLSERVER
MYSQL
SELECT * FROM account;
START TRANSACTION;
UPDATE account
SET bal = bal - 1000
WHERE acno = 155 AND bal >1000;

UPDATE account
SET bal = bal + 1000
WHERE acno = 200;
COMMIT;
SELECT * FROM account;

Initial:
Acno bal
155 3000
200 5000

Output:
acno bal
155 2000
200 6000

BITS Pilani, Pilani Campus

States of Transaction

BITS Pilani, Pilani Campus

Transaction and schedule

BITS Pilani, Pilani Campus

Anomalies with interleaved Execution
ACID properties

BITS Pilani, Pilani Campus

Properties of T

BITS Pilani, Pilani Campus

Transaction and schedule
Ref: https://youtu.be/GspaLqbj9jI

BITS Pilani, Pilani Campus

Transaction and schedule

BITS Pilani, Pilani Campus

Types of schedules:

BITS Pilani, Pilani Campus

Transaction and schedule

BITS Pilani, Pilani Campus

BITS Pilani, Pilani Campus
Serializable Schedule

BITS Pilani, Pilani Campus

 Problems: Testing of Serializability

Find if conflict serializable

Using Method 2: Precedence graph:
a) S1: R1(x) W1(x) R2(x) R1(y) W2(x) W1(y)
b) S2: R2(z) R2(y)W2(y)R3(y)R3(z)R1(x)W1(x) W3(y) W3(z) R2(x)R1(x)W1(x)W2(x)
Using Method1 :

BITS Pilani, Pilani Campus

 Problem

Find if conflict serializable

BITS Pilani, Pilani Campus

 Problems: Testing of View Serializability

A)
S1 s2

B) S: r1(a) w2(a) w1(a)

S1: r1(a) w1(a) w2(a)
S2: w2(a) r1(a) w1(a)

BITS Pilani, Pilani Campus

 Problems:
Convert to non serial schedule Convert to view equivalent and view serializable schedule

schedules S & S1 are view

serializable, because the
schedules S & Sl are view
equivalent.

This is conflict serializability.

BITS Pilani, Pilani Campus
Transaction and schedule
A recoverable schedule is one where, for each
pair of transactions Ti & Tj such that Tj reads a
data item previously written by Ti. .
The commit operation of Ti appears before the
commit operation of Tj.

BITS Pilani, Pilani Campus

Transaction and schedule

BITS Pilani, Pilani Campus

Problems:
Check if conflict operations are there?
S: R1(x) W2(x) R1(y) R2(z)
S: R1(x) W1(x) R1(y) R2(z)

Cascading abort and cascade less schedule:

S1: R1(x) W1(x) R2(x) W2(x) R3(x) W3(x) a1
Here say if after w3(x) its aborted …..
Say if abort after w1(x)

S2: R1(x) W1(x) c1 R2(x) W2(x) c2 R3(x) W3(x) c3

BITS Pilani, Pilani Campus

Problems:

S: R1(x), R2(x),R1(z),R3(x),R3(y),W1(x),c1,W3(y),c3,R2(y),W2(z),W2(y),c2

S: R1(x), R2(x),R1(z),R3(x),R3(y),W1(x),c1,W3(y),c2,R2(y),W2(z),W2(y),c3

S: R1(x), R2(x),R1(z),R3(x),R3(y),W1(x),c1,W3(y),c2,R2(y),W2(z),W2(y),c2

BITS Pilani, Pilani Campus

Transaction and schedule

BITS Pilani, Pilani Campus

Problems

Check if strict, cascadeless or recoverable ?

a. R1(x), R2(z),R3(x),R1(z),R2(y),R3(y),W1(x),c1,W2(z),W3(y),W2(y),c3,c2
b. R1(x),W1(x),R2(x),R1(y),R2(y),W2(x),W1(y),a1,a2
c. R1(x),W1(x),R2(x),R1(y),W2(x),c2,a1
d. R1(x),R2(x),W1(x),R1(y),W2(x),c2,W1(y),c1
e. R2(x),R1(x),W1(x),R1(y),W1(y),c1,W2(x),c2

BITS Pilani, Pilani Campus

Example

BITS Pilani, Pilani Campus

Types

BITS Pilani, Pilani Campus

Equivalence of schedules

2. Conflict Equivalent Schedules-

If any two schedules satisfy the following two conditions, then

they are called as conflict equivalent schedules-
1.The set of transactions present in both the schedules is same.
2.The order of pairs of conflicting operations of both the
schedules is same.

1. Result Equivalent Schedules-

•If any two schedules generate the same result after their
execution, then they are called as result equivalent schedules.
•This equivalence relation is considered of least significance.
•This is because some schedules might produce same results for
some set of values and different results for some other set of
values.

BITS Pilani, Pilani Campus

Problems:

Result equivalence or not:

BITS Pilani, Pilani Campus

 Problem
Are the following three schedules result equivalent? Solution

To check whether the given schedules are result equivalent or not,

•We will consider some arbitrary values of X and Y.
•Then, we will compare the results produced by each schedule.
•Those schedules which produce the same results will be result
equivalent.

Let X = 2 and Y = 5.
On substituting these values, the results produced by each schedule
are-

Results by Schedule S1- X = 21 and Y = 10

Results by Schedule S2- X = 21 and Y = 10
Results by Schedule S3- X = 11 and Y = 10

•Clearly, the results produced by schedules S1 and S2 are same.

•Thus, we conclude that S1 and S2 are result equivalent schedules.

BITS Pilani, Pilani Campus

Equivalent schedules

BITS Pilani, Pilani Campus

How to find what Schedule?

Find if its c/s/recoverable?

R1(x) R2(x) R1(z) R3(x) R3(y) W1(x) W3(y) R2(y) W2(z) W2(y) c1 c2 c3

BITS Pilani, Pilani Campus

To check what Schedule

BITS Pilani, Pilani Campus

Topological sort

BITS Pilani, Pilani Campus

Transaction isolation levels

BITS Pilani, Pilani Campus

Example

BITS Pilani, Pilani Campus

Summary

 States of a transaction
 Desirable properties of a transaction
 Schedules
 Concurrent transactions
 Serializability

BITS Pilani, Pilani Campus

Thanks..

BITS Pilani, Pilani Campus

 SSZG518: Database design and
Applications

BITS Pilani Prof. Uma Maheswari

Pilani Campus
 BITS Pilani
Pilani Campus

Session 9 Concurrency Control

TUTORIAL
Concurrency and LOCKS

BITS Pilani, Pilani Campus

Concurrency control manager
Isolation

• This property ensures that multiple transactions can occur simultaneously without
causing any inconsistency.
• During execution, each transaction feels as if it is getting executed alone in the
system.
• A transaction does not realize that there are other transactions executed in parallel
• Changes made by a transaction becomes visible to other transactions only after they
are written in the memory.
• The resultant state of the system after executing all the transactions is same as the
state that would be achieved if the transactions were executed serially one after the
other.
• It is the responsibility of concurrency control manager to ensure isolation for all
the transactions.

BITS Pilani, Pilani Campus

Concurrency problems:

BITS Pilani, Pilani Campus

Concurrency problems:

BITS Pilani, Pilani Campus

Different 2-phase locking protocols

BITS Pilani, Pilani Campus

Check what 2-phase lock?

Lock_S(A) Lock_S(A) Lock_S(A)

R(A) R(A) R(A)
Lock_X(B) Lock_X(B) Unlock(A)
R(A) Unlock(A) Lock_X(B)
R(B) R(B) R(B)
B=A+B W(B) W(B)
Unlock(A) commit Unlock(B)
W(B) Unlock(B) commit
Unlock(B)

BITS Pilani, Pilani Campus

LOCKS in MYSQL

mysql> LOCK TABLES t1 READ;

mysql> SELECT COUNT(*) FROM t1;
+----------+ | COUNT(*) | +----------+ | 3 | +----------+ SET autocommit=0;

mysql> LOCK TABLES t2 WRITE; LOCK TABLES t1 WRITE, t2 READ

mysql> SELECT COUNT(*) FROM t2; …do something with tables t1 and t2 here
ERROR 1100 (HY000): Table 't2' was not locked with ...
LOCK TABLES
COMMIT;
UNLOCK TABLES;
mysql> LOCK TABLE t WRITE, t AS t1 READ;

mysql> INSERT INTO t SELECT * FROM t;

ERROR 1100: Table 't' was not locked with LOCK TABLES

mysql> INSERT INTO t SELECT * FROM t AS t1;

BITS Pilani, Pilani Campus

 Locks in Mysql
Row level locking
Connection 2
Connection 1 UPDATE accDetails SET ledgerAmount = ledgerAmount + 250 WHERE id=2;
START TRANSACTION;
SELECT ledgerAmount FROM accDetails WHERE id = 1 FOR UPDATE; 1 row(s) affected

row level lock obtained by SELECT ... FOR UPDATE statement.

But while updating some other row in connection 2 will be
executed without any error.
Connection 2
UPDATE accDetails SET ledgerAmount = ledgerAmount + 500 WHERE Connection 1
id=1; UPDATE accDetails SET ledgerAmount = ledgerAmount + 750 WHERE id=1;
When some one try to update same row in connection 2, that will wait for COMMIT;
connection 1 to finish transaction or error message will be displayed
1 row(s) affected
according to the innodb_lock_wait_timeout setting, which defaults to 50
seconds. Now row lock is released, because transaction is commited in
Error Code: 1205. Lock wait timeout exceeded; try restarting Connection 1.
transaction
To view details about this lock, run SHOW ENGINE INNODB STATUS
Connection 2
When two sessions or users of database try to update or UPDATE accDetails SET ledgerAmount = ledgerAmount + 500 WHERE id=1;
delete the same data in a table, then there will be a concurrent 1 row(s) affected
update problem. In order to avoid this problem, database The update is executed without any error in Connection 2 after
locks the data for the first user and allows him to Connection 1 released row lock by finishing the transaction.
update/delete the data.
BITS Pilani, Pilani Campus
Isolation levels for transaction:
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
}

BITS Pilani, Pilani Campus

 Examples
Let's write a transaction without Isolation level.
1.BEGIN TRANSACTION MyTransaction
2.BEGIN TRY
3.UPDATE Account SET Debit=100 WHERE Name='John Cena'
4.UPDATE ContactInformation SET Mobile='1234567890' WHERE Name='The Rock'
prevents Dirty Read. When this level is set, the transaction can not read the data
5.COMMIT TRANSACTION MyTransaction
6.PRINT 'TRANSACTION SUCCESS' that is being modified by the current transaction. This will force user to wait for the
7.END TRY current transaction to finish up its job.
8.BEGIN CATCH
9.ROLLBACK TRANSACTION MyTransaction 1.SET TRANSACTION ISOLATION LEVEL
10.PRINT 'TRANSACTION FAILED' 2.READ COMMITTED
11.END CATCH 3.BEGIN TRANSACTION MyTransaction
4.BEGIN TRY
the transaction can read uncommitted data resulting in the Dirty Read problem. With this isolation level, we allow a
5.UPDATE Account SET Debit=100 WHERE Name='John Cena'
transaction to read the data which is being updated by other transaction and not yet committed. 6.UPDATE ContactInformation SET Mobile='1234567890' WHERE Name='The Rock'
7.COMMIT TRANSACTION MyTransaction
8.PRINT 'TRANSACTION SUCCESS'
1.SET TRANSACTION ISOLATION LEVEL 9.END TRY
2.READ UNCOMMITTED 10.BEGIN CATCH
3.BEGIN TRANSACTION MyTransaction 11.ROLLBACK TRANSACTION MyTransaction
12.PRINT 'TRANSACTION FAILED'
4.BEGIN TRY
13.END CATCH
5.UPDATE Account SET Debit=100 WHERE Name='John Cena'
6.UPDATE ContactInformation SET Mobile='1234567890' WHERE Name='The Rock'
7.COMMIT TRANSACTION MyTransaction
8.PRINT 'TRANSACTION SUCCESS'
9.END TRY
10.BEGIN CATCH
11.ROLLBACK TRANSACTION MyTransaction
12.PRINT 'TRANSACTION FAILED'
13.END CATCH

BITS Pilani, Pilani Campus

Timestamp ordering protocol
Timestamp protocol always ensure
Rule No. 01 is used when any transaction wants to Basic TO Protocol Serializabilty and Deadlock removal
perform Read(A) operation •Not Allowed because Transaction with smaller

If WTS(A) > TS (Ti), then Ti Rollback • R1(X) W 2(X) timestamp (TS) will come first in
execution sequence than Transaction
• W 1(X) R2(X) with higher TS.
Else (otherwise) execute R(A) operation and SET RTS (A) = MAX • W 1(X) W 2(X)
{RTS(A), TS(Ti)} •Allowed
Rules No.2 is used when a transaction needs to perform WRITE (A) • All operations where T2 occurs before T1.
• R1(X) R2(X)
If RTS(A) > TS (Ti), then Ti Rollback
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute W(A) operation and SET WTS (A) =
TS(Ti)
Where “A” is some data

Let's assume there are two transactions T1 and T2.

Suppose the transaction T1 has entered the system at
007 times and transaction T2 has entered the system at
009has
T1 times.
the higher priority, so it executes first as it is entered
the system first. BITS Pilani, Pilani Campus
 Example of Timestamp ordering Protocol

Rule No. 01 is used when any transaction wants to

perform Read(A) operation
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute R(A) operation and SET RTS
(A) = MAX {RTS(A), TS(Ti)}

Rules No.2 is used when a transaction needs to

perform WRITE (A)
If RTS(A) > TS (Ti), then Ti Rollback
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute W(A) operation and SET WTS
(A) = TS(Ti)
Where “A” is some data

BITS Pilani, Pilani Campus

 Example of Timestamp ordering Protocol

Rule No. 01 is used when any transaction wants to

perform Read(A) operation
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute R(A) operation and SET RTS
(A) = MAX {RTS(A), TS(Ti)}

Rules No.2 is used when a transaction needs to

perform WRITE (A)
If RTS(A) > TS (Ti), then Ti Rollback
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute W(A) operation and SET WTS
(A) = TS(Ti)
Where “A” is some data

BITS Pilani, Pilani Campus

Thomas Write Rule:

Thomas Write Rule does not enforce Conflict Thomas Write Rule
Serializability but rejects fewer Write •Not Allowed
Operations by modifying the check • R1(X) W 2(X)
Operations for W_item(X) • W 1(X) R2(X)
•Allowed
If R_TS(X) > TS(T), then abort and roll back T and • All operations where T2 occurs before
reject the operation. T1.
If W_TS(X) > TS(T), then don’t execute the Write • Outdated Writes: W 1(X) W 2(X)
Operation and continue processing. This is a case of
Outdated or Obsolete Writes. Remember, outdated • R1(X) R2(X)
writes are ignored in Thomas Write Rule but a
Transaction following Basic TO protocol will abort
such a Transaction.
If neither the condition in 1 or 2 occurs, then and only
then execute the W_item(X) operation of T and set
W_TS(X) to TS(T)

Thomas Write rule doesn’t allow conflict serializable schedule but only allows “view
serializable” schedules!!!

BITS Pilani, Pilani Campus

 Problem If R_TS(X) > TS(T), then abort and roll back T and reject the
operation.
If W_TS(X) > TS(T), then don’t execute the Write Operation
and continue processing. This is a case of Outdated or
Is this allowed Thomas write rule or not? Obsolete Writes. Remember, outdated writes are ignored in
Thomas Write Rule but a Transaction following Basic TO
protocol will abort such a Transaction.
If neither the condition in 1 or 2 occurs, then and only then
execute the W_item(X) operation of T and set W_TS(X) to
TS(T)

BITS Pilani, Pilani Campus

 Multi granularity locking protocol
The multiple granularity locking (MGL) protocol consists of the
following rules:

1. The lock compatibility (based on Figure 22.8) must be adhered to.

2. The root of the tree must be locked first, in any mode.
3. A node N can be locked by a transaction T in S or IS mode only if
the parent node N is already locked by transaction T in either IS or IX
mode.
4. A node N can be locked by a transaction T in X, IX, or SIX mode
only if the parent of node N is already locked by transaction T in
either IX or SIX mode.
5. A transaction T can lock a node only if it has not unlocked any node
(to enforce the 2PL protocol).
Locks are acquired 6. A transaction T can unlock a node, N, only if none of the children of
node N are currently locked by T.
from top to bottom
of tree and Rule 1 simply states that conflicting locks cannot be
released from granted. Rules 2, 3, and 4 state the conditions when a
bottom to top
transaction may lock a given node in any of the lock
modes. Rules 5 and 6 of the MGL protocol enforce 2PL
rules to produce serializable schedules.
BITS Pilani, Pilani Campus
Example: MGLP

BITS Pilani, Pilani Campus

 Locking in Sqlserver
shared lock on the database level that is DML statement (i.e. insert, update, delete) a shared lock (S) will be
imposed whenever a transaction is connected imposed on the database level, an intent exclusive lock (IX) or
to a database. intent update lock (IU) will be imposed on the table and on
the page level, and an exclusive or update lock (X or U) on the
row

Locks will always be acquired from the At the table level, there are five different types of locks:
top to the bottom as in that way SQL At the row level, the following three lock •Exclusive (X)
Server is preventing a so-called Race •Shared (S)
condition to occur.
modes can be applied:
•Exclusive (X) •Intent exclusive (IX)
Not all lock modes can be applied at all
levels. •Shared (S) •Intent shared (IS)
•Update (U) •Shared with intent exclusive (SIX)

BITS Pilani, Pilani Campus

Deadlocks

BITS Pilani, Pilani Campus

Deadlocks

BITS Pilani, Pilani Campus

Summary

 Concurrency
 Concurrent protocols
 Deadlock and recovery

BITS Pilani, Pilani Campus

THANK YOU

BITS Pilani, Pilani Campus

 SSZG518: Database design and
Applications

BITS Pilani Prof. Uma Maheswari

Pilani Campus
 BITS Pilani
Pilani Campus

Session 10 DB RECOVERY
TUTORIAL
RECOVERY

BITS Pilani, Pilani Campus

 DB recovery
A database has the properties of atomicity, consistency,  The recovery techniques in DBMS maintain
isolation, and durability. The durability of a system is marked by the properties of atomicity and durability of
the ability to preserve the data and changes made to the data. the database.
A database may fail due to any of the following reasons,
 System failures are caused due to hardware or software  A system is not called durable if it fails
problems in the system. during a transaction and loses all its data
 Transaction failures occur when a particular process that and a system is not called atomic, if the data
deals with the modification of data can't be completed. is in a partial state of update during the
 Disk crashes may be due to the inability of the system to transaction.
read the disk.
 Physical damages includes problems like power failure or  The data recovery techniques in DBMS make
natural disaster. sure, that the state of data is preserved to
protect the atomic property and the data is
 Log-based recovery in DBMS. always recoverable to protect the durability
 Recovery through Deferred Update property.
 Recovery through Immediate Update

BITS Pilani, Pilani Campus

Rollback/Undo Recovery Technique: The rollback/undo recovery technique is based on the principle of
backing out or undoing the effects of a transaction that has not completed successfully due to a system failure
or error. This technique is accomplished by undoing the changes made by the transaction using the log
records stored in the transaction log. The transaction log contains a record of all the transactions that have
been performed on the database. The system uses the log records to undo the changes made by the failed
transaction and restore the database to its previous state.

BITS Pilani, Pilani Campus

Commit/Redo Recovery Technique: The commit/redo recovery technique is
based on the principle of reapplying the changes made by a transaction that
has been completed successfully to the database. This technique is
accomplished by using the log records stored in the transaction log to redo
the changes made by the transaction that was in progress at the time of the
failure or error. The system uses the log records to reapply the changes made
by the transaction and restore the database to its most recent consistent
state.

BITS Pilani, Pilani Campus

BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
And third technique called checkpoint recovery. Checkpoint recovery is a
technique used to reduce the recovery time by periodically saving the state
of the database in a checkpoint file. In the event of a failure, the system can
use the checkpoint file to restore the database to the most recent consistent
state before the failure occurred, rather than going through the entire log to
recover the database.

BITS Pilani, Pilani Campus

BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
What is a Log-Based Recovery?
Any DBMS has its own system logs that have the records
for all the activity that has occurred in the system along
with timestamps on the time of the activity. Databases
handle different log files for activities like errors, queries, MySQL terminal to set up logging in to a MySQL
and other changes in the database. database,
• Create a variable to store the file path of the
log file(.log) to which the logs must be stored.

BITS Pilani, Pilani Campus

In the quick update method, the update to the data
is made concurrently before the transaction
reaches the commit stage.

The logs are also recorded as soon as the changes to

the data are made. In the case of failure, the
data may be in a partial state of the transaction,
and undo operations can be performed to
restore the data.

We can also mark the state of the transaction and

recover our data to the marked state using SQL
commands. The following commands are used to
achieve this,

BITS Pilani, Pilani Campus

In the Deferred update, the state of the data in the database is
not changed immediately after any transaction is executed, but
as soon as the commit has been made, the changes are
recorded in the log file, and the state of data is changed.

VS

In the Immediate update, at every transaction, the database is

updated directly, and a log file is also maintained containing the
old and new values.

BITS Pilani, Pilani Campus

 Shadow paging
 In shadow paging, a database is split into n- multiple pages
that represent a fixed-size disk memory.
 Similarly, n shadow pages are also created which are copies
of the real database.
 At the beginning of a transaction, the state in the database
is copied to the shadow pages.
 The shadow pages will not be modified during the
transaction and only the real database will be modified.
 When the transaction reaches the commit stage, the
changes are made to the shadow pages. The changes are
made in a way that if the i-th part of the hard disk has
modifications, then the i-th shadow page is also modified.
 If there is a failure of the system, the real pages of the
database are compared with the shadow pages and recovery In the Caching/Buffering method, a collection of buffers called
operations are performed. DBMS buffers are present in the logical memory. The buffers
are used to store all logs during the process and the update to
the main log file is made when the transaction reaches
the commit stage.
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
•Undoing – If a transaction crashes, then the recovery manager may undo transactions i.e. reverse
the operations of a transaction. This involves examining a transaction for the log entry write_item(T,
x, old_value, new_value) and set the value of item x in the database to old-value. There are two
major techniques for recovery from non-catastrophic transaction failures: deferred updates and
immediate updates.
•Deferred update – This technique does not physically update the database on disk until a
transaction has reached its commit point. Before reaching commit, all transaction updates are
recorded in the local transaction workspace. If a transaction fails before reaching its commit point, it
will not have changed the database in any way so UNDO is not needed. It may be necessary to
REDO the effect of the operations that are recorded in the local transaction workspace, because
their effect may not yet have been written in the database. Hence, a deferred update is also known
as the No-undo/redo algorithm
•Immediate update – In the immediate update, the database may be updated by some operations
of a transaction before the transaction reaches its commit point. However, these operations are
recorded in a log on disk before they are applied to the database, making recovery still possible. If a
transaction fails to reach its commit point, the effect of its operation must be undone i.e. the
transaction must be rolled back hence we require both undo and redo. This technique is known
as undo/redo algorithm.
BITS Pilani, Pilani Campus
• Caching/Buffering – In this one or more disk pages that include data items to be updated are cached into main memory
buffers and then updated in memory before being written back to disk. A collection of in-memory buffers called the DBMS
cache is kept under the control of DBMS for holding these buffers. A directory is used to keep track of which database items
are in the buffer. A dirty bit is associated with each buffer, which is 0 if the buffer is not modified else 1 if modified.
• Shadow paging – It provides atomicity and durability. A directory with n entries is constructed, where the ith entry points to
the ith database page on the link. When a transaction began executing the current directory is copied into a shadow
directory. When a page is to be modified, a shadow page is allocated in which changes are made and when it is ready to
become durable, all pages that refer to the original are updated to refer new replacement page.
• Backward Recovery – The term “Rollback ” and “UNDO” can also refer to backward recovery. When a backup of the data is
not available and previous modifications need to be undone, this technique can be helpful. With the backward recovery
method, unused modifications are removed and the database is returned to its prior condition. All adjustments made during
the previous traction are reversed during the backward recovery. In another word, it reprocesses valid transactions and
undoes the erroneous database updates.
• Forward Recovery – “Roll forward “and “REDO” refers to forwarding recovery. When a database needs to be updated with
all changes verified, this forward recovery technique is helpful.
Some failed transactions in this database are applied to the database to roll those modifications forward. In another word,
the database is restored using preserved data and valid transactions counted by their past saves.

BITS Pilani, Pilani Campus

Some of the backup techniques are as follows :
• Full database backup – In this full database including data and database, Meta
information needed to restore the whole database, including full-text catalogs are
backed up in a predefined time series.
• Differential backup – It stores only the data changes that have occurred since the
last full database backup. When some data has changed many times since last full
database backup, a differential backup stores the most recent version of the
changed data. For this first, we need to restore a full database backup.
• Transaction log backup – In this, all events that have occurred in the database, like
a record of every single statement executed is backed up. It is the backup of
transaction log entries and contains all transactions that had happened to the
database. Through this, the database can be recovered to a specific point in time. It
is even possible to perform a backup from a transaction log if the data files are
destroyed and not even a single committed transaction is lost.

BITS Pilani, Pilani Campus

Summary

The following techniques are used to recover data in a DBMS,

 Log-based recovery in DBMS.
 Recovery through Deferred Update
 Recovery through Immediate Update

BITS Pilani, Pilani Campus

THANK YOU !

BITS Pilani, Pilani Campus

 SSZG518: Database design and
Applications

BITS Pilani Prof. Uma Maheswari

Pilani Campus
 BITS Pilani
Pilani Campus

Session 11 DB Security
TUTORIAL
DB SECURITY

BITS Pilani, Pilani Campus

BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
Problem

BITS Pilani, Pilani Campus

Problem

BITS Pilani, Pilani Campus

Problem

BITS Pilani, Pilani Campus

Problem
ACCESS MATRIX :

BITS Pilani, Pilani Campus

Problem
ACCESS MATRIX :

BITS Pilani, Pilani Campus

 Problem
The authorization graph for this example
GRANT SELECT ON Sailors TO Art WITH GRANT OPTION
(executed by Joe)

GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION

(executed by Art)

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION

(executed by Bob)

GRANT SELECT ON Sailors TO Cal WITH GRANT OPTION

(executed by Joe)

GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION

(executed by Cal)

REVOKE SELECT ON Sailors FROM Art CASCADE (executed by

Joe)

BITS Pilani, Pilani Campus

Problem
Hospital management system has different types of users and
they are:

Doctors : attends to patient , recommends tests, creates

prescription or updates the prescription, reads the report
Patients : registers in the portal and books for appointment
and payment are done
Lab technicians : they do the test as said by doctor and
reports are generated.
Bill desk : they update the payment details of the patient.
Also updates the total fees collected for each doctor.

BITS Pilani, Pilani Campus

For Doctor
CREATE ROLE doctor;
GRANT SELECT, INSERT, UPDATE ON prescription, recommend_test TO doctor;
GRANT SELECT ON lab_report TO doctor;
CREATE USER d1,d2,d3;
GRANT doctor to d1,d2,d3;

BITS Pilani, Pilani Campus

SQL injection

BITS Pilani, Pilani Campus

SQL injection

BITS Pilani, Pilani Campus

SQL INJECTION

BITS Pilani, Pilani Campus

THANKS

BITS Pilani, Pilani Campus