Note for Database Management System - DBMS By Durga Puja
- Database Management System - DBMS
- Note
- Dr. A.P.J. Abdul Kalam Technical University - AKTU
- Master of Computer Applications
- 309 Views
- 2 Offline Downloads
- Uploaded 1 year ago
Text from page-1
NOTES OF DATABASE MANAGEMENT SYSTEM RCA 401 (AKTU) MCA 2ND YR (IV SEM) DURGA PUJA A.P. CS & E B.S.A College of Engineering & Technology, Mathura EST. & Governed By: SHRI AGRAWAL SHIKSHA MANDAL (Regd.), Mathura 1
Text from page-2
Unit – 5 UNIT V - FAILURE RECOVERY AND CONCURRENCY CONTROL:-Issues and Models for Resilient Operation -Undo/Redo Logging-Protecting against Media Failures CONCURRENCY CONTROL: Serial and Serializable Schedules-Conflict Serializability-Enforcing Serializability by Locks-Locking Systems with Several Lock Modes-Concurrency Control by Timestamps, validation. TRANSACTION MANAGEMENT: Serializability and Recoverability-View Serializability- Resolving, Deadlocks-Distributed Databases: Commit and Lock Transaction: A transaction is a unit of program execution that accesses and possibly updates various data items. Transaction Management is a core operation in a DBMS. ACID Properties: It is requires that a DBMS maintain the following properties of transactions: Atomicity: Either all operations of the transaction are properly reflected in the database or none are. Consistency: Execution of a transaction in isolation preserves the consistency of the database. Isolation: Although multiple transactions may execute concurrently, each transaction must be unaware of other concurrently executing transactions. Intermediate transaction results must be hidden from other concurrently executed transactions. That is, for every pair of transactions Ti and Tj, it appears to Ti that either Tj, finished execution before Ti started, or Tj started execution after Ti finished. Durability: After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. Transaction State Active – the initial state; the transaction stays in this state while it is executing Partially committed – after the final statement has been executed. Failed -- after the discovery that normal execution can no longer proceed. Aborted – after the transaction has been rolled back and the database restored to its state prior to the start of the transaction. Two options after it have been aborted: 1. Restart the transaction: can be done only if no internal logical error 2. Kill the transaction Committed – after successful completion. Issues and Models for Resilient Operation : A computer system, like any other mechanical or electrical device is subject to failure. There are many causes of such failure, such as disk 2
Text from page-3
crash, power failure, software error, etc. In each of these cases, information may be lost. Therefore, the database system maintains an integral part known as recovery manager. It is responsible for the restore of the database to a consistent state that existed prior to the occurrence of the failures. The recovery manager of a DBMS is responsible for ensuring transaction atomicity and durability. It ensures atomicity by undoing the actions of transactions, that do not commit and durability by making sure that all actions of committed transactions survive system crashes and media failures. When a DBMS is restarted after crashes, the recovery manager is given control and must bring the database to a consistent state. The recovery manager is also responsible for undoing the actions of an aborted transaction. System Failure classifications: 1) Transaction Failure: There are two types of errors that may cause a transaction failure. i) Logical Error: The transaction can do longer continue with its normal execution with some internal conditions such as bad input, data not found, overflow or resource limits exceeded. ii) System Error: The system has entered an undesirable state (deadlock) as a result of which a transaction cannot continue with its normal execution. This transaction can be reexecuted at a later time. 2) System Crash: There is a hardware failure or an error in the database software or the operating system that causes the loss of the content of temporary storage and brings transaction processing to a halt. The content of permanent storage remains same and is not corrupted. 3) Disk failure: A disk block loses its content as a result of either a head crash or failure during a data transfer operation. Copies of the data on other disks or backups on tapes are used to recover from the failure. Causes of failures: Some failures might cause the database to go down, some others might be trivial. On the other hand, if a data file has been lost, recovery requires additional steps. Some common causes of failures include: 1) System Crashes: It can be happen due to hardware or software errors resulting in loss of main memory. 2) User error: It can be happen due to a user inadvertently deleting a row or dropping a table. 3) Carelessness: It can be happen due to the destruction of data or facilities by operators/users because of lack of concentration. 4) Sabotage: It can be happen due to the intentional corruption or destruction of data, hardware or software facilities. 5) Statement failure: It can be happen due to the inability by the database to execute an SQL statement. 6) Application software errors: It can be happen due to the logical errors in the program to access the database, which causes one or more transactions to fail. 7) Network failure: It can be happen due to a network failure / communication software failure / aborted asynchronous connections. 3
Text from page-4
8) Media failure: It can be happen due to the disk controller failure / disk head crash / disk to be lost. It is ht most dangerous failure. 9) Natural physical disasters: It can be happen due to the natural disasters like fires, floods, earthquakes, power failure, etc. More about Transactions: The transaction is the unit of execution of database operations. Assuring that transactions are executed correctly is the job of a transaction manager, a subsystem that performs several functions, including: 1. Issuing signals to the log manager (described below) so that necessary information in the form of ―log records‖ can be stored on the log. 2. Assuring that concurrently executing transactions do not interfere with each other in ways that introduce errors. (a) The transaction manager: It will send messages about actions of transactions to the log manager, to the buffer manager about when it is possible or necessary to copy the buffer back to disk, and to the query processor to execute the queries and other database operations that comprise the transaction. (b) The log manager: it maintains the log. It must deal with the buffer manager, since space for the log initially appears in main-memory buffers, and at certain times these buffers must be copied to disk. (c) The recovery manager : When there is a crash, the recovery manager is activated. It examines the log and uses it to repair the data, if necessary. As always, access to the disk is through the buffer manager. A fundamental assumption about transactions is: Correctness Principle: If a transaction executes in the absence of any other transactions or system errors, and it starts with the database in a consistent state, then the database is also in a consistent state when the transaction ends. Operations of Transactions: 1. INPUT(X): Copy the disk block containing database element X to a memory buffer. 2. READ(X, t): Copy the database element X to the transaction’s local variable t from memory buffer then first execute 3. WRITE (X. t): Copy the value of local variable t to database element X in a memory buffer. 4. OUTPUT (X): Copy the block containing X from its buffer to disk. 4
Leave your Comments