DOCSLIB.ORG

Logging and Recovery Review: the ACID Properties Motivation Assumptions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Logging and Recovery Review: the ACID Properties Motivation Assumptions Motivation • Atomicity: – Transactions may abort (“Rollback”). Logging and • Durability: Recovery – What if DBMS stops running? (Causes?) Chapter 18 Y Desired Behavior after crash! If you are going to be in the system restarts: T1 logging business, one of the – T1, T2 & T3 should be T2 things that you have to do is to durable. T3 learn about heavy equipment. – T4 & T5 should be T4 - Robert VanNatta, aborted (effects not seen). T5 Logging History of Columbia County Review: The ACID properties Assumptions • A tomicity: All actions in the Xact happen, or none happen. • Concurrency control is in effect. • C onsistency: If each Xact is consistent, and the DB starts – Strict 2PL, in particular. consistent, it ends up consistent. • Updates are happening “in place”. • I solation: Execution of one Xact is isolated from that of other – i.e. data is overwritten on (deleted from) the disk. Xacts. • D urability: If a Xact commits, its effects persist. • A simple scheme to guarantee Atomicity & Durability? • The Recovery Manager guarantees Atomicity & Durability. 1 Handling the Buffer Pool Basic Idea: Logging • Force write to disk at • Record REDO and UNDO information, for every commit? No Steal Steal update, in a log. – Poor response time. – Sequential writes to log (put it on a separate disk). – But provides durability. Force Trivial – Minimal info (diff) written to log, so multiple updates • Steal buffer-pool frames fit in a single log page. from uncommited Xacts? • Log: An ordered list of REDO/UNDO actions – If not, poor throughput. No Force Desired – Log record contains: – If so, how can we ensure <XID, pageID, offset, length, old data, new data> atomicity? – and additional control info (which we’ll see soon). More on Steal and Force Write-Ahead Logging (WAL) •STEAL (why enforcing Atomicity is hard) • The Write-Ahead Logging Protocol: – To steal frame F: Current page in F (say P) is c Must force the log record for an update before written to disk; some Xact holds lock on P. the corresponding data page gets to disk. • What if the Xact with the lock on P aborts? d Must write all log records for a Xact before • Must remember the old value of P at steal time (to support UNDOing the write to page P). commit. •NO FORCE(why enforcing Durability is hard) • #1 guarantees Atomicity. – What if system crashes before a modified page is • #2 guarantees Durability. written to disk? – Write as little as possible, in a convenient place, at • Exactly how is logging (and recovery!) done? commit time,to support REDOing modifications. – We’ll study the ARIES algorithms. 2 DB RAM WAL & the Log LSNs pageLSNs flushedLSN Other Log-Related State • Each log record has a unique Log Sequence Number (LSN). Log records • Transaction Table: – LSNs always increasing. flushed to disk – One entry per active Xact. • Each data page contains a pageLSN. –Contains XID, status (running/commited/aborted), – The LSN of the most recent log record and lastLSN. for an update to that page. • Dirty Page Table: • System keeps track of flushedLSN. – One entry per dirty page in buffer pool. – The max LSN flushed so far. –ContainsrecLSN -- the LSN of the log record which pageLSN • WAL: Before a page is written, “Log tail” first caused the page to be dirty. in RAM –pageLSN≤ flushedLSN Log Records Normal Execution of an Xact Possible log record types: LogRecord fields: • Update • Series of reads & writes, followed by commit or abort. prevLSN •Commit XID •Abort – We will assume that page write is atomic on disk. type •End (signifies end of commit • In practice, additional details to deal with non-atomic writes. pageID or abort) • Strict 2PL. update length • Compensation Log Records • STEAL, NO-FORCE buffer management, with Write- records offset (CLRs) Ahead Logging. only before-image – for UNDO actions after-image – (and some other tricks!) 3 Checkpointing Simple Transaction Abort • Periodically, the DBMS creates a checkpoint, in order to minimize the time taken to recover in the event of a system • For now, consider an explicit abort of a Xact. crash. Write to log: –No crash involved. – begin_checkpoint record: Indicates when chkpt began. • We want to “play back” the log in reverse – end_checkpoint record: Contains current Xact table and dirty page order, UNDOing updates. table. This is a `fuzzy checkpoint’: –GetlastLSN of Xact from Xact table. • Other Xacts continue to run; so these tables only known to reflect some mix of state after the time of the begin_checkpoint record. – Can follow chain of log records backward via the • No attempt to force dirty pages to disk; effectiveness of checkpoint prevLSN field. limited by oldest unwritten change to a dirty page. (So it’s a good idea – Note: before starting UNDO, could write an Abort to periodically flush dirty pages to disk!) log record. – Store LSN of chkpt record in a safe place (master record). •Why bother? The Big Picture: What’s Stored Where Abort, cont. LOG DB RAM • To perform UNDO, must have a lock on data! – No problem! LogRecords • Before restoring old value of a page, write a CLR: prevLSN Xact Table Data pages lastLSN – You continue logging while you UNDO!! XID – CLR has one extra field: undonextLSN type each status • Points to the next LSN to undo (i.e. the prevLSN of the record we’re pageID with a pageLSN Dirty Page Table currently undoing). length –CLR contains REDO info recLSN offset –CLRsnever Undone before-image master record flushedLSN • Undo needn’t be idempotent (>1 UNDO won’t happen) after-image • But they might be Redone when repeating history (=1 UNDO guaranteed) • At end of all UNDOs, write an “end” log record. 4 Transaction Commit Recovery: The Analysis Phase • Write commit record to log. • Reconstruct state at checkpoint. • All log records up to Xact’s lastLSN are flushed. –via end_checkpoint record. – Guarantees that flushedLSN ≥ lastLSN. • Scan log forward from begin_checkpoint. – Note that log flushes are sequential, synchronous –Endrecord: Remove Xact from Xact table. writes to disk. – Other records: Add Xact to Xact table, set – Many log records per log page. lastLSN=LSN, change Xact status on commit. • Make transaction visible – Update record: If P not in Dirty Page Table, – Commit() returns, locks dropped, etc. • Add P to D.P.T., set its recLSN=LSN. • Write end record to log. Crash Recovery: Big Picture Recovery: The REDO Phase • We repeat History to reconstruct state at crash: Oldest log –Reapply all updates (even of aborted Xacts!), redo rec. of Xact Y Start from a checkpoint (found active at crash CLRs. via master record). • Scan forward from log rec containing smallest Smallest Y Three phases. Need to: recLSN in D.P.T. For each CLR or update log rec LSN, recLSN in dirty page – Figure out which Xacts REDO the action unless: table after committed since checkpoint, – Affected page is not in the Dirty Page Table, or Analysis which failed (Analysis). – Affected page is in D.P.T., but has recLSN > LSN, or – REDO all actions. –pageLSN(in DB) ≥ LSN. Last chkpt X (repeat history) • To REDO an action: – UNDO effects of failed Xacts. – Reapply logged action. CRASH –SetpageLSN to LSN. No additional logging! A RU 5 Recovery: The UNDO Phase Example: Crash During Restart! LSN LOG ToUndo={ l | l a lastLSN of a “loser” Xact} 00,05 begin_checkpoint, end_checkpoint Repeat: RAM 10 update: T1 writes P5 – Choose largest LSN among ToUndo. 20 update T2 writes P3 undonextLSN – If this LSN is a CLR and undonextLSN==NULL Xact Table 30 T1 abort lastLSN 40,45 CLR: Undo T1 LSN 10, T1 End •Write an End record for this Xact. status – If this LSN is a CLR, and undonextLSN != NULL Dirty Page Table 50 update: T3 writes P1 recLSN 60 update: T2 writes P5 •AddundonextLSN to ToUndo flushedLSN CRASH, RESTART • (Q: what happens to other CLRs?) 70 CLR: Undo T2 LSN 60 ToUndo – Else this LSN is an update. Undo the update, 80,85 CLR: Undo T3 LSN 50, T3 end write a CLR, add prevLSN to ToUndo. CRASH, RESTART Until ToUndo is empty. 90 CLR: Undo T2 LSN 20, T2 end Example of Recovery Additional Crash Issues LSN LOG • What happens if system crashes during Analysis? During REDO? RAM 00 begin_checkpoint 05 end_checkpoint • How do you limit the amount of work in REDO? Xact Table 10 update: T1 writes P5 prevLSNs – Flush asynchronously in the background. lastLSN 20 update T2 writes P3 – Watch “hot spots”! status 30 T1 abort Dirty Page Table • How do you limit the amount of work in UNDO? recLSN 40 CLR: Undo T1 LSN 10 – Avoid long-running Xacts. flushedLSN 45 T1 End 50 update: T3 writes P1 ToUndo 60 update: T2 writes P5 CRASH, RESTART 6 Logical vs. Physical Logging Nested Top Actions • Roughly, ARIES does: • Trick to support physical operations you do not –Physical REDO want to ever be undone –Logical UNDO –Example? • Why? • Basic idea – At end of the nested actions, write a dummy CLR • Nothing to REDO in this CLR – Its UndoNextLSN points to the step before the nested action. Logical vs. Physical Logging, Cont. Summary of Logging/Recovery • Page-oriented REDO logging • Recovery Manager guarantees Atomicity & – Independence of REDO (e.g. indexes & tables) Durability. – Not quite physical, but close • Use WAL to allow STEAL/NO-FORCE w/o • Can have logical operations like increment/decrement sacrificing correctness. (“escrow transactions”) • LSNs identify log records; linked into • Logical UNDO backwards chains per transaction (via – To allow for simple management of physical prevLSN). structures that are invisible to users • pageLSN allows comparison of data page and – To allow for logical operations log records. • Handles escrow transactions 7 Summary, Cont. • Checkpointing: A quick way to limit the amount of log to scan on recovery.
Load more

Recommended publications
  • Let's Talk About Storage & Recovery Methods for Non-Volatile Memory
    Let’s Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems Joy Arulraj Andrew Pavlo Subramanya R. Dulloor [email protected] [email protected] [email protected] Carnegie Mellon University Carnegie Mellon University Intel Labs ABSTRACT of power, the DBMS must write that data to a non-volatile device, The advent of non-volatile memory (NVM) will fundamentally such as a SSD or HDD. Such devices only support slow, bulk data change the dichotomy between memory and durable storage in transfers as blocks. Contrast this with volatile DRAM, where a database management systems (DBMSs). These new NVM devices DBMS can quickly read and write a single byte from these devices, are almost as fast as DRAM, but all writes to it are potentially but all data is lost once power is lost. persistent even after power loss. Existing DBMSs are unable to take In addition, there are inherent physical limitations that prevent full advantage of this technology because their internal architectures DRAM from scaling to capacities beyond today’s levels [46]. Using are predicated on the assumption that memory is volatile. With a large amount of DRAM also consumes a lot of energy since it NVM, many of the components of legacy DBMSs are unnecessary requires periodic refreshing to preserve data even if it is not actively and will degrade the performance of data intensive applications. used. Studies have shown that DRAM consumes about 40% of the To better understand these issues, we implemented three engines overall power consumed by a server [42]. in a modular DBMS testbed that are based on different storage Although flash-based SSDs have better storage capacities and use management architectures: (1) in-place updates, (2) copy-on-write less energy than DRAM, they have other issues that make them less updates, and (3) log-structured updates.
    [Show full text]
  • Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains
    Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual.
    [Show full text]
  • Failures in DBMS
    Chapter 11 Database Recovery 1 Failures in DBMS Two common kinds of failures StSystem filfailure (t)(e.g. power outage) ‒ affects all transactions currently in progress but does not physically damage the data (soft crash) Media failures (e.g. Head crash on the disk) ‒ damagg()e to the database (hard crash) ‒ need backup data Recoveryyp scheme responsible for handling failures and restoring database to consistent state 2 Recovery Recovering the database itself Recovery algorithm has two parts ‒ Actions taken during normal operation to ensure system can recover from failure (e.g., backup, log file) ‒ Actions taken after a failure to restore database to consistent state We will discuss (briefly) ‒ Transactions/Transaction recovery ‒ System Recovery 3 Transactions A database is updated by processing transactions that result in changes to one or more records. A user’s program may carry out many operations on the data retrieved from the database, but the DBMS is only concerned with data read/written from/to the database. The DBMS’s abstract view of a user program is a sequence of transactions (reads and writes). To understand database recovery, we must first understand the concept of transaction integrity. 4 Transactions A transaction is considered a logical unit of work ‒ START Statement: BEGIN TRANSACTION ‒ END Statement: COMMIT ‒ Execution errors: ROLLBACK Assume we want to transfer $100 from one bank (A) account to another (B): UPDATE Account_A SET Balance= Balance -100; UPDATE Account_B SET Balance= Balance +100; We want these two operations to appear as a single atomic action 5 Transactions We want these two operations to appear as a single atomic action ‒ To avoid inconsistent states of the database in-between the two updates ‒ And obviously we cannot allow the first UPDATE to be executed and the second not or vice versa.
    [Show full text]
  • What Is Nosql? the Only Thing That All Nosql Solutions Providers Generally Agree on Is That the Term “Nosql” Isn’T Perfect, but It Is Catchy
    NoSQL GREG SYSADMINBURD Greg Burd is a Developer Choosing between databases used to boil down to examining the differences Advocate for Basho between the available commercial and open source relational databases . The term Technologies, makers of Riak. “database” had become synonymous with SQL, and for a while not much else came Before Basho, Greg spent close to being a viable solution for data storage . But recently there has been a shift nearly ten years as the product manager for in the database landscape . When considering options for data storage, there is a Berkeley DB at Sleepycat Software and then new game in town: NoSQL databases . In this article I’ll introduce this new cat- at Oracle. Previously, Greg worked for NeXT egory of databases, examine where they came from and what they are good for, and Computer, Sun Microsystems, and KnowNow. help you understand whether you, too, should be considering a NoSQL solution in Greg has long been an avid supporter of open place of, or in addition to, your RDBMS database . source software. [email protected] What Is NoSQL? The only thing that all NoSQL solutions providers generally agree on is that the term “NoSQL” isn’t perfect, but it is catchy . Most agree that the “no” stands for “not only”—an admission that the goal is not to reject SQL but, rather, to compensate for the technical limitations shared by the majority of relational database implemen- tations . In fact, NoSQL is more a rejection of a particular software and hardware architecture for databases than of any single technology, language, or product .
    [Show full text]
  • Oracle Nosql Database
    An Oracle White Paper November 2012 Oracle NoSQL Database Oracle NoSQL Database Table of Contents Introduction ........................................................................................ 2 Technical Overview ............................................................................ 4 Data Model ..................................................................................... 4 API ................................................................................................. 5 Create, Remove, Update, and Delete..................................................... 5 Iteration ................................................................................................... 6 Bulk Operation API ................................................................................. 7 Administration .................................................................................... 7 Architecture ........................................................................................ 8 Implementation ................................................................................... 9 Storage Nodes ............................................................................... 9 Client Driver ................................................................................. 10 Performance ..................................................................................... 11 Conclusion ....................................................................................... 12 1 Oracle NoSQL Database Introduction NoSQL databases
    [Show full text]
  • The Integration of Database Systems
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1993 The Integration of Database Systems Tony Schaller Omran A. Bukhres Ahmed K. Elmagarmid Purdue University, [email protected] Xiangning Liu Report Number: 93-046 Schaller, Tony; Bukhres, Omran A.; Elmagarmid, Ahmed K.; and Liu, Xiangning, "The Integration of Database Systems" (1993). Department of Computer Science Technical Reports. Paper 1061. https://docs.lib.purdue.edu/cstech/1061 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. The Integration of Database Systems Tony Schaller, Omran A. Bukhres, Ahmed K. Elmagarmid and Xiangning Liu CSD-TR-93-046 July 1993 I I The Integration of Database Systems Tony Schaller Molecular Design Ltd. 2132 Farallon Drive San Leandro, CA 94577 Omran A. Bukhres, Ahmed K. Elmagarmid and Xiangning Liu DeparLment of Computer Sciences Purdue University West Lafayette, IN 47907 eJIlail: {bukhres,ake,xl} .es.purdue.edu 1 Introduction A database system is composed of two elements: a software program, called a database management system, and a set of data, called a database. The data in a database is organized according to some data model, such as the relational model used in a DB2 database [DW88] or the hierarchical model found with IMS databases [Dat77] . Users access the data through an interface (the query language) provided by the database management system. A schema describes the actual data structures and organization within the system. During the decade ofthe nineteen-seventies, centralized databases were predominant, but recent innovations in communications and database technologies have engendered a revolution in data processing, giving rlse to a new generation of decentralized database systems.
    [Show full text]
  • High-Performance Transaction Processing in SAP HANA
    High-Performance Transaction Processing in SAP HANA Juchang Lee1, Michael Muehle1, Norman May1, Franz Faerber1, Vishal Sikka1, Hasso Plattner2, Jens Krueger2, Martin Grund3 1SAP AG 2Hasso Plattner Insitute, Potsdam, Germany, 3eXascale Infolab, University of Fribourg, Switzerland Abstract Modern enterprise applications are currently undergoing a complete paradigm shift away from tradi- tional transactional processing to combined analytical and transactional processing. This challenge of combining two opposing query types in a single database management system results in additional re- quirements for transaction management as well. In this paper, we discuss our approach to achieve high throughput for transactional query processing while allowing concurrent analytical queries. We present our approach to distributed snapshot isolation and optimized two-phase commit protocols. 1 Introduction An efficient and holistic data management infrastructure is one of the key requirements for making the right deci- sions at an operational, tactical, and strategic level and is core to support all kinds of enterprise applications[12]. In contrast to traditional architectures of database systems, the SAP HANA database takes a different approach to provide support for a wide range of data management tasks. The system is organized in a main-memory centric fashion to reflect the shift within the memory hierarchy[2] and to consistently provide high perfor- mance without prohibitively slow disk interactions. Completely transparent for the application, data is orga- nized along its life cycle either in column or row format, providing the best performance for different workload characteristics[11, 1]. Transactional workloads with a high update rate and point queries can be routed against a row store; analytical workloads with range scans over large datasets are supported by column oriented data struc- tures.
    [Show full text]
  • SQL Vs Nosql: a Performance Comparison
    SQL vs NoSQL: A Performance Comparison Ruihan Wang Zongyan Yang University of Rochester University of Rochester [email protected] [email protected] Abstract 2. ACID Properties and CAP Theorem We always hear some statements like ‘SQL is outdated’, 2.1. ACID Properties ‘This is the world of NoSQL’, ‘SQL is still used a lot by We need to refer the ACID properties[12]: most of companies.’ Which one is accurate? Has NoSQL completely replace SQL? Or is NoSQL just a hype? SQL Atomicity (Structured Query Language) is a standard query language A transaction is an atomic unit of processing; it should for relational database management system. The most popu- either be performed in its entirety or not performed at lar types of RDBMS(Relational Database Management Sys- all. tems) like Oracle, MySQL, SQL Server, uses SQL as their Consistency preservation standard database query language.[3] NoSQL means Not A transaction should be consistency preserving, meaning Only SQL, which is a collection of non-relational data stor- that if it is completely executed from beginning to end age systems. The important character of NoSQL is that it re- without interference from other transactions, it should laxes one or more of the ACID properties for a better perfor- take the database from one consistent state to another. mance in desired fields. Some of the NOSQL databases most Isolation companies using are Cassandra, CouchDB, Hadoop Hbase, A transaction should appear as though it is being exe- MongoDB. In this paper, we’ll outline the general differences cuted in iso- lation from other transactions, even though between the SQL and NoSQL, discuss if Relational Database many transactions are execut- ing concurrently.
    [Show full text]
  • APPENDIX G Acid Dissociation Constants
    harxxxxx_App-G.qxd 3/8/10 1:34 PM Page AP11 APPENDIX G Acid Dissociation Constants §␮ ϭ 0.1 M 0 ؍ (Ionic strength (␮ † ‡ † Name Structure* pKa Ka pKa ϫ Ϫ5 Acetic acid CH3CO2H 4.756 1.75 10 4.56 (ethanoic acid) N ϩ H3 ϫ Ϫ3 Alanine CHCH3 2.344 (CO2H) 4.53 10 2.33 ϫ Ϫ10 9.868 (NH3) 1.36 10 9.71 CO2H ϩ Ϫ5 Aminobenzene NH3 4.601 2.51 ϫ 10 4.64 (aniline) ϪO SNϩ Ϫ4 4-Aminobenzenesulfonic acid 3 H3 3.232 5.86 ϫ 10 3.01 (sulfanilic acid) ϩ NH3 ϫ Ϫ3 2-Aminobenzoic acid 2.08 (CO2H) 8.3 10 2.01 ϫ Ϫ5 (anthranilic acid) 4.96 (NH3) 1.10 10 4.78 CO2H ϩ 2-Aminoethanethiol HSCH2CH2NH3 —— 8.21 (SH) (2-mercaptoethylamine) —— 10.73 (NH3) ϩ ϫ Ϫ10 2-Aminoethanol HOCH2CH2NH3 9.498 3.18 10 9.52 (ethanolamine) O H ϫ Ϫ5 4.70 (NH3) (20°) 2.0 10 4.74 2-Aminophenol Ϫ 9.97 (OH) (20°) 1.05 ϫ 10 10 9.87 ϩ NH3 ϩ ϫ Ϫ10 Ammonia NH4 9.245 5.69 10 9.26 N ϩ H3 N ϩ H2 ϫ Ϫ2 1.823 (CO2H) 1.50 10 2.03 CHCH CH CH NHC ϫ Ϫ9 Arginine 2 2 2 8.991 (NH3) 1.02 10 9.00 NH —— (NH2) —— (12.1) CO2H 2 O Ϫ 2.24 5.8 ϫ 10 3 2.15 Ϫ Arsenic acid HO As OH 6.96 1.10 ϫ 10 7 6.65 Ϫ (hydrogen arsenate) (11.50) 3.2 ϫ 10 12 (11.18) OH ϫ Ϫ10 Arsenious acid As(OH)3 9.29 5.1 10 9.14 (hydrogen arsenite) N ϩ O H3 Asparagine CHCH2CNH2 —— —— 2.16 (CO2H) —— —— 8.73 (NH3) CO2H *Each acid is written in its protonated form.
    [Show full text]
  • Drugs and Acid Dissociation Constants Ionisation of Drug Molecules Most Drugs Ionise in Aqueous Solution.1 They Are Weak Acids Or Weak Bases
    Drugs and acid dissociation constants Ionisation of drug molecules Most drugs ionise in aqueous solution.1 They are weak acids or weak bases. Those that are weak acids ionise in water to give acidic solutions while those that are weak bases ionise to give basic solutions. Drug molecules that are weak acids Drug molecules that are weak bases where, HA = acid (the drug molecule) where, B = base (the drug molecule) H2O = base H2O = acid A− = conjugate base (the drug anion) OH− = conjugate base (the drug anion) + + H3O = conjugate acid BH = conjugate acid Acid dissociation constant, Ka For a drug molecule that is a weak acid The equilibrium constant for this ionisation is given by the equation + − where [H3O ], [A ], [HA] and [H2O] are the concentrations at equilibrium. In a dilute solution the concentration of water is to all intents and purposes constant. So the equation is simplified to: where Ka is the acid dissociation constant for the weak acid + + Also, H3O is often written simply as H and the equation for Ka is usually written as: Values for Ka are extremely small and, therefore, pKa values are given (similar to the reason pH is used rather than [H+]. The relationship between pKa and pH is given by the Henderson–Hasselbalch equation: or This relationship is important when determining pKa values from pH measurements. Base dissociation constant, Kb For a drug molecule that is a weak base: 1 Ionisation of drug molecules. 1 Following the same logic as for deriving Ka, base dissociation constant, Kb, is given by: and Ionisation of water Water ionises very slightly.
    [Show full text]
  • High Volume Transaction Processing Without Concurrency Control, Two Phase Commit, SQL Or
    High Volume Transaction Pro cessing Without Concurrency Control Two Phase Commit SQL or C Arthur Whitney Dennis Shasha Stevan Apter KX Systems Courant Institute NYU Union Bank of Switzerland Harker Avenue Mercer Street Park Avenue Palo Alto CA New York NY New York NY Abstract Imagine an application environment in which subsecond response to thousands of events gives the user a distinct competitive advantage yet transactional guarantees are important Imag ine also that the data ts comfortably into a few gigabytes of Random Access Memory These attributes characterize many nancial trading applications Which engine should one use in such a case IBM FastPath Sybase Oracle or Object Store We argue that an unconventional approach is cal led for we use a listbased language cal led K having optimized support for bulk array operators and that integrates networking and a graphical user interface Locking is unnecessary when singlethreading such applications because the data ts into memory obviating the need to go to disk except for logging purposes Multithreading can be hand led for OLTP applications by analyzing the arguments to transactions The result is a private sizereduced TPCB benchmark that achieves transactions per second with ful l recoverability and TCPIP overhead on an Megahertz UltraSparc I Further hot disaster recovery can be done with far less overhead than required by two phase commit by using a sequential state machine approach We show how to exploit multiple processors without complicating the language or our basic framework
    [Show full text]
  • A Transaction Processing Method for Distributed Database
    Advances in Computer Science Research, volume 87 3rd International Conference on Mechatronics Engineering and Information Technology (ICMEIT 2019) A Transaction Processing Method for Distributed Database Zhian Lin a, Chi Zhang b School of Computer and Cyberspace Security, Communication University of China, Beijing, China [email protected], [email protected] Abstract. This paper introduces the distributed transaction processing model and two-phase commit protocol, and analyses the shortcomings of the two-phase commit protocol. And then we proposed a new distributed transaction processing method which adds heartbeat mechanism into the two- phase commit protocol. Using the method can improve reliability and reduce blocking in distributed transaction processing. Keywords: distributed transaction, two-phase commit protocol, heartbeat mechanism. 1. Introduction Most database services of application systems will be distributed on several servers, especially in some large-scale systems. Distributed transaction processing will be involved in the execution of business logic. At present, two-phase commit protocol is one of the methods to distributed transaction processing in distributed database systems. The two-phase commit protocol includes coordinator (transaction manager) and several participants (databases). In the process of communication between the coordinator and the participants, if the participants without reply for fail, the coordinator can only wait all the time, which can easily cause system blocking. In this paper, heartbeat mechanism is introduced to monitor participants, which avoid the risk of blocking of two-phase commit protocol, and improve the reliability and efficiency of distributed database system. 2. Distributed Transactions 2.1 Distributed Transaction Processing Model In a distributed system, each node is physically independent and they communicates and coordinates each other through the network.
    [Show full text]