DOCSLIB.ORG

Database Management Systems Introduction Transaction ACID

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Database Management Systems Introduction Transaction ACID Introduction What is Concurrent Process (CP)? • Multiple users access databases and use computer Database Management systems simultaneously. • Example: Airline reservation system. Systems œ An airline reservation system is used by hundreds of travel agents and reservation clerks concurrently. Transaction, Concurrency and Why Concurrent Process? Recovery • Better transaction throughput and response time • Better utilization of resource Adapted from Lecture notes by Goldberg @ Berkeley Transaction ACID Properties of transaction • What is Transaction? • Atomicity: Transaction is either performed in its entirety or not performed at all, this should be DBMS‘ • A sequence of many actions which are responsibility considered to be one atomic unit of work. • Consistency: Transaction must take the database • Basic operations a transaction can include from one consistent state to another if it is executed in —actions“: isolation. It is user‘s responsibility to insure consistency œ Reads, writes • Isolation: Transaction should appear as though it is œ Special actions: commit, abort being executed in isolation from other transactions • Durability: Changes applied to the database by a committed transaction must persist, even if the system fail before all changes reflected on disk Concurrent Transactions Schedules • What is Schedules œ A schedule S of n transactions T1,T2,…Tn is an ordering of the B B operations of the transactions subject to the constraint that, for each transaction Ti that participates in S, the operations of Ti in Smust CPU2 A appear in the same order in which they occur in Ti. CPU A 1 œ Example: Sa: r1(A),r2(A),w1(A),w2(A), a1,c2; CPU1 T1 T2 time Read(A) Read(A) t1 t2 t1 t2 Write(A) interleaved processing parallel processing Write(A) Abort T1 Commit T2 1 Oops, something‘s wrong Another example • Reserving a seat for a flight • Problems can occur when concurrent transactions execute in an uncontrolled manner. • If concurrent access to data in DBMS, two users • Examples of one problem. may try to book the same seat simultaneously œ A original equals to 100, after execute T1 and T2, A is supposed to be 100+10-8=102 Agent 1 finds time seat 35G empty Add 10 To A Minus 8 from A Value of A on Agent 2 finds T1 T2 the disk seat 35G empty Read(A) 100 Agent 1 sets A=A+10 100 seat 35G occupied Read(A) 100 A=A-8 100 Agent 2 sets Write(A) 110 seat 35G occupied Write(A) 92 What Can Go Wrong? Conflict operations • Two operations in a schedule are said to be conflict if they • Concurrent process may end up violating Isolation satisfy all three of the following conditions: property of transaction if not carefully scheduled (1) They belong to different transactions (2) They access the same item A; • Transaction may be aborted before committed (3) at least one of the operations is a write(A) - undo the uncommitted transactions Example in Sa: r1(A),r2(A),w1(A),w2(A), a1,c2; - undo transactions that sees the uncommitted change before the crash œ r1(A),w2(A) conflict, so do r2(A),w1(A), œ r1(A), w1(A) do not conflict because they belong to the same transaction, œ r1(A),r2(A) do not conflict because they are both read operations. Characterizing Schedules Serializabilityof schedules No Yes 1. Avoid cascading abort(ACA) T1 T2 T1 T2 • Serial • Aborting T1 requires aborting T2! Read(A) Read(A) œ A schedule S is serial if, for every transaction T participating in the œ Cascading Abort Write(A) Write(A) schedule, all the operations of T are executed consecutively in the • An ACA (avoids cascading abort) Read(A) commit schedule.( No interleaving occurs in a serial schedule) œ A X act only reads data from Write(A) Read(A) • Serializable committed X acts. Abort Write(A) T1 T2 T1 T2 œ A schedule S of n transactions is serializable if it is equivalent to some 2.recoverable Read(A) Read(A) serialschedule of the same n transactions. • Aborting T1 requires aborting T2! Write(A) Write(A) – But T2 has already committed! • schedules are conflict equivalent if: Read(A) Read(A) œ they have the same sets of actions, and • A recoverable schedule is one in which Write(A) Write(A) this cannot happen. œ each pair of conflicting actions is ordered in the same way Commit Commit – i.e. a X act commits only after all the Commit • Conflict Serializable X acts it “depends on” (i.e. it reads from) Abort commit. T1 T2 œ A schedule is said to be conflict serializable if it is conflict equivalent to – ACA implies recoverable (but not Read(A) a serial schedule vice-versa!). Write(A) Commit 3. strict schedule Read(A) Write(A) Commit 2 Denn Diagram for Schedules Example All Schedules View Serializable Conflict Serializable T1:W(X), T2:R(Y), T1:R(Y), T2:R(X), C2, C1 Recoverable ACA • serializable: Yes, equivalent to T1,T2 Strict • conflict-serializable: Yes, conflict- Serial equivalent to T1,T2 • recoverable: No. Yes, if C1 and C2 are switched. • ACA: No. Yes, if T1 commits before T2 reads X. Sample Transaction (informal) Sample Transaction (Formal) • Example: Move $40 from checking to savings T1 account • To user, appears as one activity t0 read_item(X); • To database: read_item(Y); œ Read balance of checking account: read( X) X:=X-40; œ Read balance of savings account: read (Y) Y:=Y+40; œ Subtract $40 from X œ Add $40 to Y write _item(X); œ Write new value of X back to disk tk write_item(Y); œ Write new value of Y back to disk Focus on concurrency control Concurrency Control Through Locks • Lock:variable associated with each data item œ Describes status of item wrt operations that can • Real DBMS does not test for serializability be performed on it œ Very inefficient since transactions are continuously • Binary locks: Locked/unlocked arriving Multiple-mode locks: Read/write œ Would require a lot of undoing • • Three operations • Solution: concurrency protocols œ read_lock(X) • If followed by every transaction, and œ write_lock(X) enforced by transaction processing system, œ unlock(X) guarantee serializabilityof schedules • Each data item can be in one of three lock states 3 Two Transactions T1 T2 Locks Alone Don’t Do the Trick! read_lock(Y); read_lock(X); Let’s run T1 and T2 in interleafed fashion read_item(Y); read_item(X); Schedule S T1 unlock(Y); unlock(X); T2 write_lock(X); write_lock(Y); read_lock(Y); read_item(X); read_item(Y); read_item(Y); read_lock(X); unlock(Y); read_item(X); X:=X+Y; Y:=X+Y; unlock(X); write_item(X); write_item(Y); write_lock(Y); read_item(Y); unlock(X); unlock(Y); unlocked too early! Y:=X+Y; write_lock(X); write_item(Y); Let’s assume serial schedule S1: T1;T2 read_item(X); unlock(Y); → X:=X+Y; Non-serializable! Initial values: X=20, Y=30 Result: X=50, Y=80 write_item(X); unlock(X); Result: X=50, Y=50 Example Two-Phase Locking (2PL) T1’ T2’ read_lock(Y); read_lock(X); read_item(Y); read_item(X); • Def.: Transaction is said to follow the write_lock(X); write_lock(Y); two-phase-locking protocolif all locking unlock(Y); unlock(X); operations precede the first unlock read_item(X); read_item(Y); Y:=X+Y; operation X:=X+Y; write_item(X); write_item(Y); unlock(X); unlock(Y); • Both T1’ and T2’ follow the 2PL protocol • Any schedule including T1’ and T2’ is guaranteed to be serializable • Limits the amount of concurrency Variations to the Basic Protocol Deadlock in 2PL Write to A, B Read from A, B • Previous technique knows as basic 2PL • Deadlock T1 T2 Conservative 2PL (static) 2PL: Lock all œ T1 waits for • write_lock(A) items needed BEFORE execution begins T2 to unlock B read_lock(B) write_lock(B) by predeclaring its read and write set œ T2 waits for read_lock(A) œ If any of the items in read or write set is T1 to unlock A write(A) already locked (by other transactions), œ Neither can write(B) transaction waits (does not acquire any write(A) locks) proceed! write(B) A deadlock! unlock(A) œ Deadlock free but not very realistic unlock(B) unlock(A) unlock(B) 4 Dariations to the Basic Protocol The Phantom Problem • Strict 2PL: Transaction does not • The concurrency Accounts release its write locks until AFTER it acc_num branch amount control problem for aborts/commits insertion and deletion 99 Easton $100 œ Not deadlock free but guarantees in database 120 Allentown $500 190 Easton $200 recoverable schedules (strict schedule: • Example: A local bank transaction can neither read/write X until Assets last transaction that wrote X has branch assets committed/aborted) Easton $300 œ Most popular variation of 2PL Allentown $500 Two Transactions Schedule following 2PL T1 T2 • T1 wants to verify that the accounts at the read_lock(Accounts[99]); write_lock(Accounts[150]); Easton branch add up to be equal to the read_lock(Accounts[190]); write_item(Accounts[150, ‘Easton’, $50]); total assets of the Easton branch read_item(Accounts[99]); write_lock(Assets[Easton]); read_item(Accounts[190]); write_item(Assets[Easton, $350); • T2 wants to add a new account (150, unlock(Accounts[150]); ‘Easton’, $50) to the accounts table read_lock(Assets[Easton]); unlock(Assets[Easton]); read_item(Assets[Easton]); • Write schedules for both transaction unlock(Accounts[99]); following the 2-phase locking protocol unlock(Accounts[190]); unlock(Assets[Easton]); When Will the Phantom Problem Index Locking Occur? • When T1 and T2 are interleaved, the Phantom • Suppose access to a table is controlled by Problem may occur a B-tree œ See previous slide • Should we use 2PL on B-tree? • Does it mean 2PL is not suitable for insertion œ 2PL says that a transaction must acquire all and deletion in database? the locks before it can release any œ No.
Load more

Recommended publications
  • SQL Server Protection Whitepaper
    SQL Server Protection Whitepaper Contents 1. Introduction ..................................................................................................................................... 2 Documentation .................................................................................................................................................................. 2 Licensing ............................................................................................................................................................................... 2 The benefits of using the SQL Server Add-on ....................................................................................................... 2 Requirements ...................................................................................................................................................................... 2 2. SQL Protection overview ................................................................................................................ 3 User databases ................................................................................................................................................................... 3 System databases .............................................................................................................................................................. 4 Transaction logs ................................................................................................................................................................
    [Show full text]
  • How to Conduct Transaction Log Analysis for Web Searching And
    Search Log Analysis: What is it; what’s been done; how to do it Bernard J. Jansen School of Information Sciences and Technology The Pennsylvania State University 329F IST Building University Park, Pennsylvania 16802 Email: [email protected] Abstract The use of data stored in transaction logs of Web search engines, Intranets, and Web sites can provide valuable insight into understanding the information-searching process of online searchers. This understanding can enlighten information system design, interface development, and devising the information architecture for content collections. This article presents a review and foundation for conducting Web search transaction log analysis. A methodology is outlined consisting of three stages, which are collection, preparation, and analysis. The three stages of the methodology are presented in detail with discussions of goals, metrics, and processes at each stage. Critical terms in transaction log analysis for Web searching are defined. The strengths and limitations of transaction log analysis as a research method are presented. An application to log client-side interactions that supplements transaction logs is reported on, and the application is made available for use by the research community. Suggestions are provided on ways to leverage the strengths of, while addressing the limitations of, transaction log analysis for Web searching research. Finally, a complete flat text transaction log from a commercial search engine is available as supplementary material with this manuscript. Introduction Researchers have used transaction logs for analyzing a variety of Web systems (Croft, Cook, & Wilder, 1995; Jansen, Spink, & Saracevic, 2000; Jones, Cunningham, & McNab, 1998; Wang, 1 of 42 Berry, & Yang, 2003). Web search engine companies use transaction logs (also referred to as search logs) to research searching trends and effects of system improvements (c.f., Google at http://www.google.com/press/zeitgeist.html or Yahoo! at http://buzz.yahoo.com/buzz_log/?fr=fp- buzz-morebuzz).
    [Show full text]
  • Destiny® System Backups
    Destiny® system backups Establishing a backup and restore plan for Destiny Overview It is important to establish a backup and restore plan for your Destiny installation. The plan must be validated and monitored to ensure that your data is sufficiently backed up and can be recovered in the event of hardware failure or other disaster. IMPORTANT Follett recommends deploying a comprehensive backup solution and testing and monitoring all backup processes. There are tradeoff decisions to be made in the backup strategy that will be shaped by your organization’s risk tolerance, technology constraints, and ability to absorb data loss or downtime. This document provides an overview of standard backup and restore for the Destiny system. IMPORTANT This content does not cover high-availability configurations such as clustered servers or log shipping. Please contact Follett School Solutions, Inc. Technical Support should you have any questions about backing up your Destiny installation. For details, see Destiny® system backups. Backing up Destiny: an overview SQL database The heart of the Destiny data resides in the SQL database. These are the main components of SQL data to be backed up: The Destiny SQL database. This database contains the main Destiny data. Proper SQL backup configuration of this database is essential. NOTE If your installation is a consortium, you will have to ensure a proper backup of multiple SQL databases (one per member). The Destiny SQL transaction log. The Master SQL database. This system database is useful when restoring to a replacement server. It is not necessary to back up the tempdb database. This is a SQL Server work area and is recreated automatically.
    [Show full text]
  • Infosphere MDM Collaboration Server: Installation Guide
    IBM InfoSphere Master Data Management Collaboration Server Version 11.6 Fix Pack 15 Installation Guide IBM Note Before using this information and the product that it supports, read the information in “Notices” on page 159. Edition Notice This edition applies to version 11.6 of IBM® InfoSphere® Master Data Management and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2000, 2020. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Chapter 1. Planning to install.................................................................................1 Installation scenarios.................................................................................................................................. 1 Installation and configuration worksheets................................................................................................. 3 Installation directory worksheet............................................................................................................3 IBM Db2 data source worksheet............................................................................................................4 Oracle data source worksheet............................................................................................................... 5 WebSphere Application Server installation worksheet.........................................................................6
    [Show full text]
  • Data Definition Language (Ddl)
    DATA DEFINITION LANGUAGE (DDL) CREATE CREATE SCHEMA AUTHORISATION Authentication: process the DBMS uses to verify that only registered users access the database - If using an enterprise RDBMS, you must be authenticated by the RDBMS - To be authenticated, you must log on to the RDBMS using an ID and password created by the database administrator - Every user ID is associated with a database schema Schema: a logical group of database objects that are related to each other - A schema belongs to a single user or application - A single database can hold multiple schemas that belong to different users or applications - Enforce a level of security by allowing each user to only see the tables that belong to them Syntax: CREATE SCHEMA AUTHORIZATION {creator}; - Command must be issued by the user who owns the schema o Eg. If you log on as JONES, you can only use CREATE SCHEMA AUTHORIZATION JONES; CREATE TABLE Syntax: CREATE TABLE table_name ( column1 data type [constraint], column2 data type [constraint], PRIMARY KEY(column1, column2), FOREIGN KEY(column2) REFERENCES table_name2; ); CREATE TABLE AS You can create a new table based on selected columns and rows of an existing table. The new table will copy the attribute names, data characteristics and rows of the original table. Example of creating a new table from components of another table: CREATE TABLE project AS SELECT emp_proj_code AS proj_code emp_proj_name AS proj_name emp_proj_desc AS proj_description emp_proj_date AS proj_start_date emp_proj_man AS proj_manager FROM employee; 3 CONSTRAINTS There are 2 types of constraints: - Column constraint – created with the column definition o Applies to a single column o Syntactically clearer and more meaningful o Can be expressed as a table constraint - Table constraint – created when you use the CONTRAINT keyword o Can apply to multiple columns in a table o Can be given a meaningful name and therefore modified by referencing its name o Cannot be expressed as a column constraint NOT NULL This constraint can only be a column constraint and cannot be named.
    [Show full text]
  • Transaction Processing System
    Transaction processing system From Wikipedia, the free encyclopedia (Redirected from Transaction processing systems) It has been suggested that this article or section be merged into Transaction processing. (Discuss) Proposed since November 2012. Transaction processing is a style of computing that divides work into individual, indivisible operations, called transactions.[1] Atransaction processing system (TPS) or transaction server is a software system, or software/hardware combination, that supports transaction processing. Contents [hide] 1 History 2 List of transaction processing systems 3 Processing types o 3.1 Batch processing o 3.2 Real-time processing o 3.3 Time-sharing o 3.4 Transaction processing 4 Transaction processing system features o 4.1 Performance o 4.2 Continuous availability o 4.3 Data integrity o 4.4 Ease of use o 4.5 Modular growth 5 Databases and files o 5.1 Data warehouse o 5.2 Backup procedures . 5.2.1 Recovery process . 5.2.2 Types of back-up procedures . 5.2.2.1 Grandfather- father-son . 5.2.2.2 Partial backups . 5.2.3 Updating in a batch . 5.2.4 Updating in real-time 6 See also 7 References 8 Further reading [edit]History One of the first transaction processing systems was American Airline SABRE system, which became operational in 1960. Designed to process up to 83,000 transactions a day, the system ran on two IBM 7090 computers. SABRE was migrated to IBM System/360computers in 1972, and became an IBM product first as Airline control Program (ACP) and later as Transaction Processing Facility (TPF). In addition to airlines TPF is used by large banks, credit card companies, and hotel chains.
    [Show full text]
  • System Administration Guide: Volume 1
    System Administration Guide: Volume 1 SAP® Adaptive Server® Enterprise 16.0 DOCUMENT ID: DC31654-01-1600-01 LAST REVISED: May 2014 Copyright © 2014 by SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/ index.epx#trademark for additional trademark information and notices. Contents CHAPTER 1: Overview of System Administration .......1 Roles Required for System Administration Tasks ..............1 Database Owner .............................................................3
    [Show full text]
  • Transactions – Recovery ACID Properties and Recovery
    Transactions – Recovery CS 317/387 1 ACID Properties and Recovery The Recovery Manager is responsible for ensuring Atomicity and Durability . Atomicity is guaranteed by undoing the actions of the transactions that did not commit (aborted). Durability is guaranteed by making sure that all actions of committed transactions survive crashes and failures. 2 1 Types of Failures System crashes due to hardware or software errors main memory content is lost Transaction failures overflow, interrupt, data not available, explicit rollback, concurrency enforcement, programming errors no memory loss. Media failures problems with disk head, unreadable media surface (parts of ) information on secondary storage may be lost Natural disasters fire, flood, earthquakes, theft, etc. physical loss of all information on all media 3 Strategy If a transaction Ti is aborted (e.g., for concurrency control reasons), all its actions have to be undone . Active transactions at the time of the crash have to be aborted, i.e., their effects have to be undone when the system comes back. DBMS has to maintain enough information to undo actions of transactions (the LOG File) 4 2 Desired Behavior after system restarts: T1, T2 & T3should be durable.– T4 & T5 should be rolled back, i.e., effects undone. 5 Log Sequence of records (sequential file) Modified by appending (no updating) Contains information from which database can be restored Log and database stored on different mass storage devices Often replicated to survive single media failure Contains
    [Show full text]
  • Microsoft SQL Server DBA's Guide to Actifio Copy Data Management
    An SQL Server DBA’s Guide to Actifio Copy Data Management Actifio VDP 10.0 Copyright, Trademarks, and other Legal Matter Copyright © 2021 Google LLC. All rights reserved. Actifio™, OnVault™, and VDP™ are trademarks of Google LLC. All other brands, product names, goods and/or services mentioned herein are trademarks or property of their respective owners. ii An SQL Server DBA’s Guide to Actifio Copy Data Management | actifio.com | | actifio.com | An SQL Server DBA’s Guide to Actifio Copy Data Management iii iv An SQL Server DBA’s Guide to Actifio Copy Data Management | actifio.com | Contents Preface ........................................................................................................................................................................................................................................................................ vii The ActifioNOW Customer Portal...........................................................................................................................................................................................................................vii Actifio Support Centers.....................................................................................................................................................................................................................................................vii Chapter 1 - Introduction ...............................................................................................................................................................................................................................1
    [Show full text]
  • Zz-Cryptoprevent-Do
    REPLAY 4 ADMINISTRATOR’S GUIDE Copyright 2009/2010 by AppAssure Software , Inc. ALL RIGHTS RESERVED. No part of this work covered by the copyright hereon may be reproduced or used in any form or by any means — graphic, electronic, or mechanical, including photocopying, recording, taping, Web distribution or information storage and retrieval systems — without the written permission of the publisher. For permission to use material from this publication, contact AppAssure Software, Inc. 1925 Isaac Newton Square, Suite 440 Reston, VA 20190 +1 703-547-8686 [email protected] Replay 4 Administrator’s Guide ii Contents Chapter One: Introduction ............................................................. 1 REPLAY 4 .......................................................................................................................................................... 1 Chapter One: Introduction ........................................................................................................................ 1 What Is In This Guide ......................................................... 1 About Replay 4 ................................................................... 1 What you get with Replay 4 .............................................. 2 What's New in Replay 4? ................................................... 2 Replication for Off-site Backup and Disaster Recovery .............................................. 2 New Enterprise Console ...........................................................................................................
    [Show full text]
  • Finding Sensitive Data in and Around Microsoft SQL Server
    Technical White Paper Finding Sensitive Data In and Around the Microsoft SQL Server Database Finding Sensitive Data In and Around the Microsoft SQL Server Database Vormetric, Inc. 888.267.3732 408.433.6000 [email protected] www.vormetric.com Technical White Paper Page | 1 Finding Sensitive Data In and Around the Microsoft SQL Server Database Audience This technical document is intended to provide insight into where sensitive data resides in and around a Microsoft® SQL Server® database for the Microsoft® Windows® operating system. The information and concepts in this document apply to all versions of SQL Server (2000, 2005, 2008, 2008 R2, 2012). It also assumes some knowledge of Vormetric’s data encryp- tion and key management technology and its associated vocabulary. Overview At first blush, simply encrypting the database itself would be sufficient to secure data at rest in inside of the Microsoft SQL Server (SQL Server) database software running on Windows server platforms. However, enterprises storing sensitive data in a SQL Server database need to consider the locations around the database where sensitive data relating to SQL Server might reside, even outside the direct control of the Database Administrators (DBAs). For example, it is well within the realm of possibility that a SQL Server database could encounter an error that would cause it to send information containing sensi- tive data into a trace file or the alert log. What follows is a description of the SQL Server database along with a table that includes a list of all types of files and sub- types, along with the function these files provide and why it makes sense to consider protecting these files.
    [Show full text]
  • Data Management 09 Transaction Processing
    1 SCIENCE PASSION TECHNOLOGY Data Management 09 Transaction Processing Matthias Boehm, Arnab Phani Graz University of Technology, Austria Computer Science and Biomedical Engineering Institute of Interactive Systems and Data Science BMK endowed chair for Data Management Last update: Dec 06, 2020 2 Announcements/Org . #1 Video Recording . Link in TeachCenter & TUbe (lectures will be public) . Due to second lockdown: webex recording . #2 Exercise Submissions . Exercise 1: grading done . Exercise 2: in process of being grading . Exercise 3: published on Dec 01, submit by Dec 22 11:59pm . Issues dataset (Nov 19) / expected results (Nov 16, Nov 26) . Two approaches of handling actors . Incorrect expected results 5 extra points INF.01017UF Data Management / 706.010 Databases – 09 Transaction Processing Matthias Boehm, Graz University of Technology, WS 2020/21 3 Transaction (TX) Processing User 2 User 1 User 3 read/write TXs #1 Multiple users Correctness? DBS DBMS #2 Various failures Deadlocks (TX, system, media) Constraint Reliability? violations DBs Network Crash/power failure Disk failure failure . Goal: Basic Understanding of Transaction Processing . Transaction processing from user perspective . Locking and concurrency control to ensure #1 correctness . Logging and recovery to ensure #2 reliability INF.01017UF Data Management / 706.010 Databases – 09 Transaction Processing Matthias Boehm, Graz University of Technology, WS 2020/21 4 Agenda . Overview Transaction Processing . Locking and Concurrency Control . Logging and Recovery . Exercise
    [Show full text]