Distributed Database Design and Relational Query Language

AAKANKSHA JAIN
AAKANKSHA JAINAssistant Professor en Poornima University
Distributed database Design
& Relational Query Language
Content
• Transaction Management
• Serializability
• Blocking
• Deadlock
• Query Optimization
Transaction Management
• A transaction is a logical unit of work that contains one or
more SQL statements. A transaction is an atomic unit.
• A transaction begins with the first executable SQL statement.
A transaction ends when it is committed or rolled back,
either explicitly with a COMMIT or ROLLBACK statement or
implicitly when a DDL statement is issued.
• For example :
Lets consider a banking database. When a bank customer
transfers money from a savings account to a checking
account, the transaction can consist of three separate
operations:
Banking Transaction example
Transaction States
There are the following six states in which a transaction may exist:
A) Active: The initial state when the transaction has just started execution.
B) Partially Committed: At any given point of time if the transaction is executing properly,
then it is going towards it COMMIT POINT. The values generated during the execution
are all stored in volatile storage.
C) Failed: If the transaction fails for some reason. The temporary values are no
longer required, and the transaction is set to ROLLBACK. It means that any change made
to the database by this transaction up to the point of the failure must be undone. If the failed
transaction has withdrawn Rs. 100/- from account A, then the ROLLBACK operation should
add Rs 100/- to account A.
D) Aborted: When the ROLLBACK operation is over, the database reaches the BFIM. The
transaction is now said to have been aborted.
Transaction States Continue..
E) Committed: If no failure occurs then the transaction reaches the COMMIT POINT. All
the temporary values are written to the stable storage and the transaction is said to have
been committed.
F) Terminated: Either committed or aborted, the transaction finally reaches this state.
Partially
committed
Committed
Terminated
AbortedFailed
Active
Properties of Transaction
A Transaction has four properties, taking the initial letters of these
four properties we collectively call them the ACID Properties.
1. Atomicity: This means that either all of the instructions within
the transaction will be reflected in the database, or none of
them will be reflected.
for example, we have two accounts A and B, each containing
Rs 1000/-. We now start a transaction to deposit Rs 100/- from
account A to Account B.
Read A;
A = A – 100;
Write A;
Read B;
B = B + 100;
Write B;
Properties of Transaction
2. Consistency: If we execute a particular transaction in isolation or
together with other transaction, (i.e. presumably in a multi-
programming environment), the transaction will yield the
same expected result.
• To give better performance, every database management
system supports the execution of multiple transactions at the
same time, using CPU Time Sharing. Concurrently executing
transactions may have to deal with the problem of sharable
resources, i.e. resources that multiple transactions are trying to
read/write at the same time.
• For example . A transaction which deposits Rs 100/- to account
A must deposit the same amount whether it is acting alone or in
conjunction with another transaction that may be trying to
deposit or withdraw some amount at the same time.
Properties of Transaction
3. Isolation: In case multiple transactions are executing
concurrently and trying to access a sharable resource at the
same time, the system should create an ordering in their
execution so that they should not create any anomaly in the
value stored at the sharable resource.
4. Durability: It states that once a transaction has been complete
the changes it has made should be permanent.
• As we have seen in the explanation of the Atomicity property,
the transaction, if completes successfully, is committed. Once
the COMMIT is done, the changes which the transaction has
made to the database are immediately written into permanent
storage. So, after the transaction has been committed
successfully, there is no question of any loss of information even
if the power fails. Committing a transaction guarantees that the
AFIM has been reached.
Serializability
Serializability is a concept that helps to identify
which non-serial schedules are correct and will
maintain the consistency of the database.
Why?
When multiple transactions run concurrently, then it
may give rise to inconsistency of the database.
• Serializable Schedules-
If a given schedule of ‘n’ transactions is found to
be equivalent to some serial schedule of ‘n’
transactions, then it is called as a serializable
schedule.
Serializability Continue..
1. Properties of Serializable Schedules-
Serializable schedules behave exactly same as serial schedules. So, they are
always-
 Consistent
 Recoverable
 Casacadeless
 Strict
2. Difference between Serial Schedules and Serializable Schedules-
The only difference between serial schedules and serializable schedules is
that-
 In serial schedules, only one transaction is allowed to execute at a
time i.e. no concurrency is allowed.
 Whereas in serializable schedules, multiple transactions can execute
simultaneously i.e. concurrency is allowed.
Types of Serializability
Serializability is mainly of two types-
1. Conflict Serializability
2. View Serializability
Figure : Types of serializability
Conflict Serializability
If a given schedule can be converted into a serial schedule
by swapping its non-conflicting operations, then it is
called as a conflict serializable schedule.
• What are conflicting operations?
Two operations are called as conflicting operations if all
the following conditions hold true for them-
– Both the operations belong to different
transactions.
– Both the operations are on same data item
– At least one of the two operations is a write
operation
Conflict Serializability
Example- Consider the following schedule-
In this schedule, W1 (A) and R2 (A) are called as conflicting operations
because all the above conditions hold true for them.
Checking of conflict serializable schedule
1) Step-01:
Find and list all the conflicting operations.
2) Step-02:
Start creating a precedence graph by drawing one node for each transaction.
3) Step-03:
Draw an edge for each conflict pair such that if Xi (V) and Yj (V) forms a conflict
pair then draw an edge from Ti to Tj which ensures that Ti gets executed before Tj.
4) Step-04:
Check if there is any cycle formed in the graph. If there is no cycle found, then
the schedule is conflict serializable otherwise not.
View Serializability-
If a given schedule is found to be view equivalent to some serial
schedule, then it is called as a view serializable schedule.
What are view equivalent schedules?
• Consider two schedules S1 and S2 each consisting of two
transactions T1 and T2. Schedules S1 and S2 are called view
equivalent if the following three conditions hold true for
them-
Condition-01:
If transaction Ti reads a data item X from the database initially in
schedule S1, then in schedule S2 also, Ti must perform the initial
read of the data item X from the database.
The same has to be true for all the data items.
View Serializability-
Thumb rule
“Initial reads must be same for all data items”.
Condition-02:
• If transaction Ti reads a data item that has been updated by
the transaction Tj in schedule S1, then in schedule S2 also,
transaction Ti must read the same data item that has been
updated by transaction Tj.
Thumb rule
“Write-read sequence must be same.”.
View Serializability-
Condition-03:
• If data item X has been updated at last by transaction Ti in schedule
S1, then in schedule S2 also, the data item X must be updated at last
by transaction Ti
• The same has to be true for all the data items.
Thumb rule
“Final writers must be same for all data items”.
How to check whether a given schedule is view serializable or not?
Method-01:
Check whether the given schedule is conflict serializable or not.
• If the given schedule is conflict serializable, then it is surely view
serializable. Stop and report your answer.
Continue..
If the given schedule is not conflict
serializable, then it may or may not be
view serializable. Go and check using
other methods.
Thumb rule
All conflict serializable schedules are view serializable but all view
serializable schedules may or may not be conflict serializable.
Method-02:
Check if there exists any blind write operation (writing without
reading a value is known as a blind write).
• If there does not exist any blind write, then the schedule is
surely not view serializable. Stop and report your answer.
Continue..
• If there exists any blind write, then the schedule may or may
not be view serializable. Go and check using other methods.
Thumb rule
No blind write means not a view serializable schedule.
Method-03:
• In this method, try finding a view equivalent serial schedule.
• By using the three conditions mentioned above, write all the
dependencies and then draw a graph using those
dependencies. If there exists no cycle, then the schedule is
view serializable otherwise not.
Deadlock
• In a database, a deadlock is an unwanted situation in which
two or more transactions are waiting indefinitely for one
another to give up locks.
• Deadlock is said to be one of the most feared complications
in DBMS as it brings the whole system to a Halt.
• Example – let us understand the concept of Deadlock with an
example :
Suppose, Transaction T1 holds a lock on some rows in the
Students table and needs to update some rows in the Grades
table. Simultaneously, Transaction T2 holds locks on those
very rows (Which T1 needs to update) in the Grades table but
needs to update the rows in the Student table held by
Transaction T1.
Deadlock
Deadlock Avoidance
• When a database is stuck in a deadlock, It is always better to
avoid the deadlock rather than restarting or aborting the
database. Deadlock avoidance method is suitable for smaller
database whereas deadlock prevention method is suitable for
larger database.
• One method of avoiding deadlock is using application
consistent logic. In the above given example, Transactions
that access Students and Grades should always access the
tables in the same order. In this way, in the scenario
described above, Transaction T1 simply waits for transaction
T2 to release the lock on Grades before it begins. When
transaction T2 releases the lock, Transaction T1 can proceed
freely.
• Another method for avoiding deadlock is to apply both row
level locking mechanism and READ COMMITTED isolation
level. However, It does not guarantee to remove deadlocks
completely.
Deadlock Detection
• Deadlock Detection –
When a transaction waits indefinitely to obtain a lock, The
database management system should detect whether the
transaction is involved in a deadlock or not.
• Wait-for-graph is one of the methods for detecting the
deadlock situation. This method is suitable for smaller
database. In this method a graph is drawn based on the
transaction and their lock on the resource. If the graph
created has a closed loop or a cycle, then there is a deadlock.
• For Example: When a transaction Ti requests for a lock on an
item, say X, which is held by some other transaction Tj, a
directed edge is created from Ti to Tj. If Tj releases item X, the
edge between them is dropped and Ti locks the data item.
Wait-for Graph
Deadlock Prevention
To prevent any deadlock situation in the system, the
DBMS aggressively inspects all the operations, where
transactions are about to execute. The DBMS
inspects the operations and analyzes if they can
create a deadlock situation. If it finds that a deadlock
situation might occur, then that transaction is never
allowed to be executed.
• There are deadlock prevention schemes that use
timestamp ordering mechanism of transactions in
order to predetermine a deadlock situation.
Deadlock Prevention
1. Wound-Wait Scheme
• In this scheme, if a transaction requests to lock a resource
(data item), which is already held with conflicting lock by
some another transaction, one of the two possibilities may
occur −
• If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is
Ti wounds Tj. Tj is restarted later with a random delay but
with the same timestamp.
• If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is
available.
Note: This scheme, allows the younger transaction to wait; but
when an older transaction requests an item held by a younger
one, the older transaction forces the younger one to abort and
release the item.
Deadlock Prevention
2. Wait-Die Scheme
• In this scheme, if a transaction requests to lock a resource (data
item), which is already held with a conflicting lock by another
transaction, then one of the two possibilities may occur −
• If TS(Ti) < TS(Tj) − that is Ti, which is requesting a conflicting lock, is
older than Tj − then Ti is allowed to wait until the data-item is
available.
• If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Tidies. Ti is
restarted later with a random delay but with the same timestamp.
Note: This scheme allows the older transaction to wait but kills the
younger one.
Distributed Database Design and Relational Query Language
Distributed Database Design and Relational Query Language
1 de 30

Recomendados

Transaction Management por
Transaction Management Transaction Management
Transaction Management Visakh V
6.4K vistas130 diapositivas
Introduction to database-Transaction Concurrency and Recovery por
Introduction to database-Transaction Concurrency and RecoveryIntroduction to database-Transaction Concurrency and Recovery
Introduction to database-Transaction Concurrency and RecoveryAjit Nayak
1.5K vistas79 diapositivas
Chapter17 por
Chapter17Chapter17
Chapter17gourab87
4.1K vistas33 diapositivas
serializability in dbms por
serializability in dbmsserializability in dbms
serializability in dbmsSaranya Natarajan
23.7K vistas24 diapositivas
Unit06 dbms por
Unit06 dbmsUnit06 dbms
Unit06 dbmsarnold 7490
5.5K vistas69 diapositivas
Unit 4 dbms por
Unit 4 dbmsUnit 4 dbms
Unit 4 dbmsSweta Singh
39 vistas66 diapositivas

Más contenido relacionado

La actualidad más candente

Transactions por
TransactionsTransactions
TransactionsKetaki_Pattani
444 vistas40 diapositivas
Transaction and serializability por
Transaction and serializabilityTransaction and serializability
Transaction and serializabilityYogita Jain
105 vistas26 diapositivas
Concurrency control por
Concurrency control Concurrency control
Concurrency control Abdelrahman Almassry
2.4K vistas41 diapositivas
Schedule in DBMS por
Schedule in DBMSSchedule in DBMS
Schedule in DBMSPratibhaRashmiSingh
683 vistas14 diapositivas
Databases: Concurrency Control por
Databases: Concurrency ControlDatabases: Concurrency Control
Databases: Concurrency ControlDamian T. Gordon
8.9K vistas25 diapositivas
DBMS - Transactions por
DBMS - TransactionsDBMS - Transactions
DBMS - TransactionsMythiliMurugan3
31 vistas14 diapositivas

La actualidad más candente(20)

Transaction and serializability por Yogita Jain
Transaction and serializabilityTransaction and serializability
Transaction and serializability
Yogita Jain105 vistas
Concurrency control por kansel85
Concurrency controlConcurrency control
Concurrency control
kansel854K vistas
protocols of concurrency control por MOHIT DADU
protocols of concurrency controlprotocols of concurrency control
protocols of concurrency control
MOHIT DADU995 vistas
DBMS-chap 2-Concurrency Control por Mukesh Tekwani
DBMS-chap 2-Concurrency ControlDBMS-chap 2-Concurrency Control
DBMS-chap 2-Concurrency Control
Mukesh Tekwani28.4K vistas
Concurrency of Issues of Distributed Advance Transaction por Abdelhafiz Khoudour
Concurrency of Issues of Distributed Advance TransactionConcurrency of Issues of Distributed Advance Transaction
Concurrency of Issues of Distributed Advance Transaction
Abdelhafiz Khoudour210 vistas
Svetlin Nakov - Database Transactions por Svetlin Nakov
Svetlin Nakov - Database TransactionsSvetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov2.6K vistas
Concepts of Data Base Management Systems por Dinesh Devireddy
Concepts of Data Base Management SystemsConcepts of Data Base Management Systems
Concepts of Data Base Management Systems
Dinesh Devireddy353 vistas
Concurrent transactions por Sajan Sahu
Concurrent transactionsConcurrent transactions
Concurrent transactions
Sajan Sahu8.1K vistas
7. transaction mang por khoahuy82
7. transaction mang7. transaction mang
7. transaction mang
khoahuy821K vistas

Similar a Distributed Database Design and Relational Query Language

transaction_processing.ppt por
transaction_processing.ppttransaction_processing.ppt
transaction_processing.pptNikhilKumarAgarwalK
2 vistas85 diapositivas
Transaction Processing Concept por
Transaction Processing ConceptTransaction Processing Concept
Transaction Processing ConceptNishant Munjal
5.4K vistas26 diapositivas
24904 lecture11 por
24904 lecture1124904 lecture11
24904 lecture11Universitas Bina Darma Palembang
670 vistas77 diapositivas
DBMS 4.pdf por
DBMS 4.pdfDBMS 4.pdf
DBMS 4.pdfNithishReddy90
18 vistas114 diapositivas
Transaction processing por
Transaction processingTransaction processing
Transaction processingSoumyajit Dutta
236 vistas40 diapositivas
UNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdf por
UNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdfUNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdf
UNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdfKavitaShinde26
11 vistas47 diapositivas

Similar a Distributed Database Design and Relational Query Language(20)

Transaction Processing Concept por Nishant Munjal
Transaction Processing ConceptTransaction Processing Concept
Transaction Processing Concept
Nishant Munjal5.4K vistas
UNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdf por KavitaShinde26
UNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdfUNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdf
UNIT 2- TRANSACTION CONCEPTS AND CONCURRENCY CONCEPTS (1).pdf
KavitaShinde2611 vistas
15. Transactions in DBMS por koolkampus
15. Transactions in DBMS15. Transactions in DBMS
15. Transactions in DBMS
koolkampus80.5K vistas
UNIT-IV: Transaction Processing Concepts por Raj vardhan
UNIT-IV: Transaction Processing ConceptsUNIT-IV: Transaction Processing Concepts
UNIT-IV: Transaction Processing Concepts
Raj vardhan148 vistas
Chapter-10 Transaction Processing and Error Recovery por Kunal Anand
Chapter-10 Transaction Processing and Error RecoveryChapter-10 Transaction Processing and Error Recovery
Chapter-10 Transaction Processing and Error Recovery
Kunal Anand190 vistas
Acid Properties In Database Management System por Ashish Kumar
Acid Properties In Database Management SystemAcid Properties In Database Management System
Acid Properties In Database Management System
Ashish Kumar126 vistas

Más de AAKANKSHA JAIN

Random forest and decision tree por
Random forest and decision treeRandom forest and decision tree
Random forest and decision treeAAKANKSHA JAIN
132 vistas31 diapositivas
Dimension reduction techniques[Feature Selection] por
Dimension reduction techniques[Feature Selection]Dimension reduction techniques[Feature Selection]
Dimension reduction techniques[Feature Selection]AAKANKSHA JAIN
274 vistas27 diapositivas
Inheritance in OOPs with java por
Inheritance in OOPs with javaInheritance in OOPs with java
Inheritance in OOPs with javaAAKANKSHA JAIN
231 vistas21 diapositivas
OOPs with java por
OOPs with javaOOPs with java
OOPs with javaAAKANKSHA JAIN
68 vistas18 diapositivas
Probability por
ProbabilityProbability
ProbabilityAAKANKSHA JAIN
209 vistas28 diapositivas
Data Mining & Data Warehousing por
Data Mining & Data WarehousingData Mining & Data Warehousing
Data Mining & Data WarehousingAAKANKSHA JAIN
130 vistas20 diapositivas

Más de AAKANKSHA JAIN(12)

Random forest and decision tree por AAKANKSHA JAIN
Random forest and decision treeRandom forest and decision tree
Random forest and decision tree
AAKANKSHA JAIN132 vistas
Dimension reduction techniques[Feature Selection] por AAKANKSHA JAIN
Dimension reduction techniques[Feature Selection]Dimension reduction techniques[Feature Selection]
Dimension reduction techniques[Feature Selection]
AAKANKSHA JAIN274 vistas
Inheritance in OOPs with java por AAKANKSHA JAIN
Inheritance in OOPs with javaInheritance in OOPs with java
Inheritance in OOPs with java
AAKANKSHA JAIN231 vistas
Data Mining & Data Warehousing por AAKANKSHA JAIN
Data Mining & Data WarehousingData Mining & Data Warehousing
Data Mining & Data Warehousing
AAKANKSHA JAIN130 vistas
DISTRIBUTED DATABASE WITH RECOVERY TECHNIQUES por AAKANKSHA JAIN
DISTRIBUTED DATABASE WITH RECOVERY TECHNIQUESDISTRIBUTED DATABASE WITH RECOVERY TECHNIQUES
DISTRIBUTED DATABASE WITH RECOVERY TECHNIQUES
AAKANKSHA JAIN3.2K vistas
Distributed Database Management System por AAKANKSHA JAIN
Distributed Database Management SystemDistributed Database Management System
Distributed Database Management System
AAKANKSHA JAIN3.4K vistas
DETECTION OF MALICIOUS EXECUTABLES USING RULE BASED CLASSIFICATION ALGORITHMS por AAKANKSHA JAIN
DETECTION OF MALICIOUS EXECUTABLES USING RULE BASED CLASSIFICATION ALGORITHMSDETECTION OF MALICIOUS EXECUTABLES USING RULE BASED CLASSIFICATION ALGORITHMS
DETECTION OF MALICIOUS EXECUTABLES USING RULE BASED CLASSIFICATION ALGORITHMS
AAKANKSHA JAIN176 vistas
Fingerprint matching using ridge count por AAKANKSHA JAIN
Fingerprint matching using ridge countFingerprint matching using ridge count
Fingerprint matching using ridge count
AAKANKSHA JAIN191 vistas
Image processing second unit Notes por AAKANKSHA JAIN
Image processing second unit NotesImage processing second unit Notes
Image processing second unit Notes
AAKANKSHA JAIN3.9K vistas
Advance image processing por AAKANKSHA JAIN
Advance image processingAdvance image processing
Advance image processing
AAKANKSHA JAIN1.2K vistas

Último

MK__Cert.pdf por
MK__Cert.pdfMK__Cert.pdf
MK__Cert.pdfHassan Khan
16 vistas1 diapositiva
802.11 Computer Networks por
802.11 Computer Networks802.11 Computer Networks
802.11 Computer NetworksTusharChoudhary72015
13 vistas33 diapositivas
SPICE PARK DEC2023 (6,625 SPICE Models) por
SPICE PARK DEC2023 (6,625 SPICE Models) SPICE PARK DEC2023 (6,625 SPICE Models)
SPICE PARK DEC2023 (6,625 SPICE Models) Tsuyoshi Horigome
36 vistas218 diapositivas
Renewal Projects in Seismic Construction por
Renewal Projects in Seismic ConstructionRenewal Projects in Seismic Construction
Renewal Projects in Seismic ConstructionEngineering & Seismic Construction
5 vistas8 diapositivas
Web Dev Session 1.pptx por
Web Dev Session 1.pptxWeb Dev Session 1.pptx
Web Dev Session 1.pptxVedVekhande
13 vistas22 diapositivas
Pitchbook Repowerlab.pdf por
Pitchbook Repowerlab.pdfPitchbook Repowerlab.pdf
Pitchbook Repowerlab.pdfVictoriaGaleano
5 vistas12 diapositivas

Último(20)

SPICE PARK DEC2023 (6,625 SPICE Models) por Tsuyoshi Horigome
SPICE PARK DEC2023 (6,625 SPICE Models) SPICE PARK DEC2023 (6,625 SPICE Models)
SPICE PARK DEC2023 (6,625 SPICE Models)
Tsuyoshi Horigome36 vistas
Web Dev Session 1.pptx por VedVekhande
Web Dev Session 1.pptxWeb Dev Session 1.pptx
Web Dev Session 1.pptx
VedVekhande13 vistas
Design of Structures and Foundations for Vibrating Machines, Arya-ONeill-Pinc... por csegroupvn
Design of Structures and Foundations for Vibrating Machines, Arya-ONeill-Pinc...Design of Structures and Foundations for Vibrating Machines, Arya-ONeill-Pinc...
Design of Structures and Foundations for Vibrating Machines, Arya-ONeill-Pinc...
csegroupvn6 vistas
MongoDB.pdf por ArthyR3
MongoDB.pdfMongoDB.pdf
MongoDB.pdf
ArthyR349 vistas
ASSIGNMENTS ON FUZZY LOGIC IN TRAFFIC FLOW.pdf por AlhamduKure
ASSIGNMENTS ON FUZZY LOGIC IN TRAFFIC FLOW.pdfASSIGNMENTS ON FUZZY LOGIC IN TRAFFIC FLOW.pdf
ASSIGNMENTS ON FUZZY LOGIC IN TRAFFIC FLOW.pdf
AlhamduKure6 vistas
_MAKRIADI-FOTEINI_diploma thesis.pptx por fotinimakriadi
_MAKRIADI-FOTEINI_diploma thesis.pptx_MAKRIADI-FOTEINI_diploma thesis.pptx
_MAKRIADI-FOTEINI_diploma thesis.pptx
fotinimakriadi10 vistas
SUMIT SQL PROJECT SUPERSTORE 1.pptx por Sumit Jadhav
SUMIT SQL PROJECT SUPERSTORE 1.pptxSUMIT SQL PROJECT SUPERSTORE 1.pptx
SUMIT SQL PROJECT SUPERSTORE 1.pptx
Sumit Jadhav 22 vistas
2023Dec ASU Wang NETR Group Research Focus and Facility Overview.pptx por lwang78
2023Dec ASU Wang NETR Group Research Focus and Facility Overview.pptx2023Dec ASU Wang NETR Group Research Focus and Facility Overview.pptx
2023Dec ASU Wang NETR Group Research Focus and Facility Overview.pptx
lwang78165 vistas
fakenews_DBDA_Mar23.pptx por deepmitra8
fakenews_DBDA_Mar23.pptxfakenews_DBDA_Mar23.pptx
fakenews_DBDA_Mar23.pptx
deepmitra816 vistas
REACTJS.pdf por ArthyR3
REACTJS.pdfREACTJS.pdf
REACTJS.pdf
ArthyR335 vistas
BCIC - Manufacturing Conclave - Technology-Driven Manufacturing for Growth por Innomantra
BCIC - Manufacturing Conclave -  Technology-Driven Manufacturing for GrowthBCIC - Manufacturing Conclave -  Technology-Driven Manufacturing for Growth
BCIC - Manufacturing Conclave - Technology-Driven Manufacturing for Growth
Innomantra 10 vistas
Design_Discover_Develop_Campaign.pptx por ShivanshSeth6
Design_Discover_Develop_Campaign.pptxDesign_Discover_Develop_Campaign.pptx
Design_Discover_Develop_Campaign.pptx
ShivanshSeth645 vistas
Update 42 models(Diode/General ) in SPICE PARK(DEC2023) por Tsuyoshi Horigome
Update 42 models(Diode/General ) in SPICE PARK(DEC2023)Update 42 models(Diode/General ) in SPICE PARK(DEC2023)
Update 42 models(Diode/General ) in SPICE PARK(DEC2023)
Tsuyoshi Horigome39 vistas

Distributed Database Design and Relational Query Language

  • 1. Distributed database Design & Relational Query Language
  • 2. Content • Transaction Management • Serializability • Blocking • Deadlock • Query Optimization
  • 3. Transaction Management • A transaction is a logical unit of work that contains one or more SQL statements. A transaction is an atomic unit. • A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued. • For example : Lets consider a banking database. When a bank customer transfers money from a savings account to a checking account, the transaction can consist of three separate operations:
  • 5. Transaction States There are the following six states in which a transaction may exist: A) Active: The initial state when the transaction has just started execution. B) Partially Committed: At any given point of time if the transaction is executing properly, then it is going towards it COMMIT POINT. The values generated during the execution are all stored in volatile storage. C) Failed: If the transaction fails for some reason. The temporary values are no longer required, and the transaction is set to ROLLBACK. It means that any change made to the database by this transaction up to the point of the failure must be undone. If the failed transaction has withdrawn Rs. 100/- from account A, then the ROLLBACK operation should add Rs 100/- to account A. D) Aborted: When the ROLLBACK operation is over, the database reaches the BFIM. The transaction is now said to have been aborted.
  • 6. Transaction States Continue.. E) Committed: If no failure occurs then the transaction reaches the COMMIT POINT. All the temporary values are written to the stable storage and the transaction is said to have been committed. F) Terminated: Either committed or aborted, the transaction finally reaches this state. Partially committed Committed Terminated AbortedFailed Active
  • 7. Properties of Transaction A Transaction has four properties, taking the initial letters of these four properties we collectively call them the ACID Properties. 1. Atomicity: This means that either all of the instructions within the transaction will be reflected in the database, or none of them will be reflected. for example, we have two accounts A and B, each containing Rs 1000/-. We now start a transaction to deposit Rs 100/- from account A to Account B. Read A; A = A – 100; Write A; Read B; B = B + 100; Write B;
  • 8. Properties of Transaction 2. Consistency: If we execute a particular transaction in isolation or together with other transaction, (i.e. presumably in a multi- programming environment), the transaction will yield the same expected result. • To give better performance, every database management system supports the execution of multiple transactions at the same time, using CPU Time Sharing. Concurrently executing transactions may have to deal with the problem of sharable resources, i.e. resources that multiple transactions are trying to read/write at the same time. • For example . A transaction which deposits Rs 100/- to account A must deposit the same amount whether it is acting alone or in conjunction with another transaction that may be trying to deposit or withdraw some amount at the same time.
  • 9. Properties of Transaction 3. Isolation: In case multiple transactions are executing concurrently and trying to access a sharable resource at the same time, the system should create an ordering in their execution so that they should not create any anomaly in the value stored at the sharable resource. 4. Durability: It states that once a transaction has been complete the changes it has made should be permanent. • As we have seen in the explanation of the Atomicity property, the transaction, if completes successfully, is committed. Once the COMMIT is done, the changes which the transaction has made to the database are immediately written into permanent storage. So, after the transaction has been committed successfully, there is no question of any loss of information even if the power fails. Committing a transaction guarantees that the AFIM has been reached.
  • 10. Serializability Serializability is a concept that helps to identify which non-serial schedules are correct and will maintain the consistency of the database. Why? When multiple transactions run concurrently, then it may give rise to inconsistency of the database. • Serializable Schedules- If a given schedule of ‘n’ transactions is found to be equivalent to some serial schedule of ‘n’ transactions, then it is called as a serializable schedule.
  • 11. Serializability Continue.. 1. Properties of Serializable Schedules- Serializable schedules behave exactly same as serial schedules. So, they are always-  Consistent  Recoverable  Casacadeless  Strict 2. Difference between Serial Schedules and Serializable Schedules- The only difference between serial schedules and serializable schedules is that-  In serial schedules, only one transaction is allowed to execute at a time i.e. no concurrency is allowed.  Whereas in serializable schedules, multiple transactions can execute simultaneously i.e. concurrency is allowed.
  • 12. Types of Serializability Serializability is mainly of two types- 1. Conflict Serializability 2. View Serializability Figure : Types of serializability
  • 13. Conflict Serializability If a given schedule can be converted into a serial schedule by swapping its non-conflicting operations, then it is called as a conflict serializable schedule. • What are conflicting operations? Two operations are called as conflicting operations if all the following conditions hold true for them- – Both the operations belong to different transactions. – Both the operations are on same data item – At least one of the two operations is a write operation
  • 14. Conflict Serializability Example- Consider the following schedule- In this schedule, W1 (A) and R2 (A) are called as conflicting operations because all the above conditions hold true for them.
  • 15. Checking of conflict serializable schedule 1) Step-01: Find and list all the conflicting operations. 2) Step-02: Start creating a precedence graph by drawing one node for each transaction. 3) Step-03: Draw an edge for each conflict pair such that if Xi (V) and Yj (V) forms a conflict pair then draw an edge from Ti to Tj which ensures that Ti gets executed before Tj. 4) Step-04: Check if there is any cycle formed in the graph. If there is no cycle found, then the schedule is conflict serializable otherwise not.
  • 16. View Serializability- If a given schedule is found to be view equivalent to some serial schedule, then it is called as a view serializable schedule. What are view equivalent schedules? • Consider two schedules S1 and S2 each consisting of two transactions T1 and T2. Schedules S1 and S2 are called view equivalent if the following three conditions hold true for them- Condition-01: If transaction Ti reads a data item X from the database initially in schedule S1, then in schedule S2 also, Ti must perform the initial read of the data item X from the database. The same has to be true for all the data items.
  • 17. View Serializability- Thumb rule “Initial reads must be same for all data items”. Condition-02: • If transaction Ti reads a data item that has been updated by the transaction Tj in schedule S1, then in schedule S2 also, transaction Ti must read the same data item that has been updated by transaction Tj. Thumb rule “Write-read sequence must be same.”.
  • 18. View Serializability- Condition-03: • If data item X has been updated at last by transaction Ti in schedule S1, then in schedule S2 also, the data item X must be updated at last by transaction Ti • The same has to be true for all the data items. Thumb rule “Final writers must be same for all data items”. How to check whether a given schedule is view serializable or not? Method-01: Check whether the given schedule is conflict serializable or not. • If the given schedule is conflict serializable, then it is surely view serializable. Stop and report your answer.
  • 19. Continue.. If the given schedule is not conflict serializable, then it may or may not be view serializable. Go and check using other methods. Thumb rule All conflict serializable schedules are view serializable but all view serializable schedules may or may not be conflict serializable. Method-02: Check if there exists any blind write operation (writing without reading a value is known as a blind write). • If there does not exist any blind write, then the schedule is surely not view serializable. Stop and report your answer.
  • 20. Continue.. • If there exists any blind write, then the schedule may or may not be view serializable. Go and check using other methods. Thumb rule No blind write means not a view serializable schedule. Method-03: • In this method, try finding a view equivalent serial schedule. • By using the three conditions mentioned above, write all the dependencies and then draw a graph using those dependencies. If there exists no cycle, then the schedule is view serializable otherwise not.
  • 21. Deadlock • In a database, a deadlock is an unwanted situation in which two or more transactions are waiting indefinitely for one another to give up locks. • Deadlock is said to be one of the most feared complications in DBMS as it brings the whole system to a Halt. • Example – let us understand the concept of Deadlock with an example : Suppose, Transaction T1 holds a lock on some rows in the Students table and needs to update some rows in the Grades table. Simultaneously, Transaction T2 holds locks on those very rows (Which T1 needs to update) in the Grades table but needs to update the rows in the Student table held by Transaction T1.
  • 23. Deadlock Avoidance • When a database is stuck in a deadlock, It is always better to avoid the deadlock rather than restarting or aborting the database. Deadlock avoidance method is suitable for smaller database whereas deadlock prevention method is suitable for larger database. • One method of avoiding deadlock is using application consistent logic. In the above given example, Transactions that access Students and Grades should always access the tables in the same order. In this way, in the scenario described above, Transaction T1 simply waits for transaction T2 to release the lock on Grades before it begins. When transaction T2 releases the lock, Transaction T1 can proceed freely. • Another method for avoiding deadlock is to apply both row level locking mechanism and READ COMMITTED isolation level. However, It does not guarantee to remove deadlocks completely.
  • 24. Deadlock Detection • Deadlock Detection – When a transaction waits indefinitely to obtain a lock, The database management system should detect whether the transaction is involved in a deadlock or not. • Wait-for-graph is one of the methods for detecting the deadlock situation. This method is suitable for smaller database. In this method a graph is drawn based on the transaction and their lock on the resource. If the graph created has a closed loop or a cycle, then there is a deadlock. • For Example: When a transaction Ti requests for a lock on an item, say X, which is held by some other transaction Tj, a directed edge is created from Ti to Tj. If Tj releases item X, the edge between them is dropped and Ti locks the data item.
  • 26. Deadlock Prevention To prevent any deadlock situation in the system, the DBMS aggressively inspects all the operations, where transactions are about to execute. The DBMS inspects the operations and analyzes if they can create a deadlock situation. If it finds that a deadlock situation might occur, then that transaction is never allowed to be executed. • There are deadlock prevention schemes that use timestamp ordering mechanism of transactions in order to predetermine a deadlock situation.
  • 27. Deadlock Prevention 1. Wound-Wait Scheme • In this scheme, if a transaction requests to lock a resource (data item), which is already held with conflicting lock by some another transaction, one of the two possibilities may occur − • If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is Ti wounds Tj. Tj is restarted later with a random delay but with the same timestamp. • If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available. Note: This scheme, allows the younger transaction to wait; but when an older transaction requests an item held by a younger one, the older transaction forces the younger one to abort and release the item.
  • 28. Deadlock Prevention 2. Wait-Die Scheme • In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur − • If TS(Ti) < TS(Tj) − that is Ti, which is requesting a conflicting lock, is older than Tj − then Ti is allowed to wait until the data-item is available. • If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Tidies. Ti is restarted later with a random delay but with the same timestamp. Note: This scheme allows the older transaction to wait but kills the younger one.