DOCSLIB.ORG

Transaction Processing, Databases and Fault-Tolerant Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Transaction Processing, Databases and Fault-Tolerant Systems Transaction Processing, Databases, and Fa ult-tolerant Systems Digital Technical Journal Digital Equipment Corporation Volume 3 Number 1 Winter 1991 Editorial Jane C. Blake, Editor Kathleen M. Stetson, Associate Editor Ci.rculation Catherine M. Phillips, Administrator Suzanne). Babineau, Secretary Production Helen L. Patterson, Production Editor Nancy jones, Typographer Peter Woodbury, Illustrator Advisory Board Samuel H. Fuller, Chairman Richard W Beane Robert M. Glorioso Richard). Hollingsworth john W McCredie Alan G. Nemeth Mahendra R. Patel F. Grant Sa viers Robert K. Spitz Victor A. Vyssotsky Gayn B. Winters The Digital Tecbnicaljoumal is published quarterly by Digital Equipment Corporation, 146 Main Street MLO l-3/B68, Maynard, Massachusetts 0175 4-2571. Subscriptions to the journal are $40.00 for four issues and must be prepaid in .S. funds. niversity and college professors and Ph.D. students in the electrical engineering and computer science fields receive complimentary subscriptions upon request. Orders, inquiries, and address changes should be sent to The Digital Tecbn.ical}oumal at the published-by address. Inquiries can also be sent electronically to DTJ®CRJ..DEC.COM. Single copies and back issues are available for $16.00 each from Digital Press of Digital Equipment Corporation, 12 Crosby Drive, Bedford, MA 01730 -1493. Digital employees may send subscription orders on the ENET to RDVAX::JOURNAI. or by interoffice mail to mailstop MLO I-3/B68. Orders should include badge number, cost center, site location code and address. All employees must advise of changes of address. Comn1ents on the content of any paper are welcomed and may be sent to the editor at the published-by or network address. Copyright <D 1991 Digital Equipment Corporation. Copying without fee is permitted provided that such copies are made for use in educational institutions by faculty members and are not distributed for commercial advantage. Abstracting with credit of Digital Equipment Corporation's authorship is permitted. All rights reserved. The information in this journalis subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this journal. ISSN 0898-901 X Documentation Number EY-F588E-DP The following are trademarks of Digital Equipment Corporation: DEC, DECforms, DECintact, DECnet, DECserver, DECtp, Digital, the Cover Design Digital logo, LAT, Rdb/VMS, TA, VAX ACMS, VAX CDD, VAX COBOL, Transaction processing is the common theme for papers in this VAX DBMS, VAX Performance Advisor, VAX RALLY, VAX Rdb/VMS, issue. The automatic teller machine on our cover represents one VAX RMS, VAX SPM, VAX SQL, VAX 6000, VAX 9000, VAXcluster, VA.Xft, VAXserver, VMS. of the many businesses that rely on TP systems. If we could look behind the familiar machine, we would see the products and IBM is a registered trademark of International Business Machines technologies - here symbolized by linked databases - that Corporation. suppo1·treliable and speedy processing of transactions worldwide. TPC Benchmark is a trademark of the Transaction Processing Performance Council. The cover was designed by Dave Bryant of Digital'sMedia Book production was done by Digital's Educational Services Communications Group. Media Communications Group in Bedford, MA. I Contents 8 Foreword Carlos G. Borgialli Transaction Processing, Databases, and Fault-tolerant Systems 10 DECdta-Digital's Distributed Transaction Processing Architecture Philip A. Bernstein, William T. Emberton, and Vi jay Trehan 18 Digital's Transaction Processing Monitors Thomas G. Speer and Mark W Storm 33 Transaction Management Support in the VMS Operating System Kernel William A. Laing, James E. Johnson, and Robert V Landau 45 Peiformance Evaluation of Transaction Processing Systems Walter H. Kohler, Yun-Ping Hsu, Thomas K. Rogers, and Wael H. Bahaa-EI-Din 58 To ols and Techniques for Preliminary Sizing of Transaction Processing Applications William Z. Zahavi, Frances A. Habib, and Kenneth). Omahen 65 Database Availability for Transaction Processing Ananth Raghavan and T. K. Rengarajan 70 Designing an Optimized Transaction Commit Protocol Peter M. Spiro, Ashok M. Joshi, and T. K. Rengarajan 79 Verification of the First Fault-tolerant VAXSystem William F. Bruckert, Carlos Alonso, and James M. Melvin I Editors Introduction ad dition to the operating system kernel and address the problem of integrating data from multiple sys­ tems and databases. The authors describe the three DECdtm components, an optimized implementa­ tion of the two-phase commit protocol, and some VA.Xclu ster-specific optimizations. The next two papers turn to the issue s of measur­ ing TP system performance and of sizing a system to ensure a TP appl ication will run efficient ly. Wal t Kohler, Yun-Ping Hsu, To m Rogers, and Wae l Bahaa­ EI-Din discuss how Digital measures and models TP system performance. They present an overview of Jane C. Blake the industry-standard TPC Benchmark A and Digital's Editor implementation, and then describe an alternative to benchmark measurement- a multilevel analyti­ Digital's transaction processi ng systems are inte­ cal model ofTP system performance that simplifies grated hardware and software products that operate the system's complex behavior to a manageable set in a distributed environment to support commer­ of parameters. The discussion of performance con­ cial applications, such as bank cash withd rawals, tinues but takes a different perspective in the paper credit card transactions, and global trading. For on sizing TP systems. Bill Zahavi, Fran Habib, and these applications, data integrity and continuous Ken Omahen have written about a methodology access to shared resources are necessary system for estimating the appropriate system size fo r a TP characteristics; anything less would jeopardize the application. The tools, techniques and algorithms revenues of business operat ions that depend on they describe are used when an application is still these applications. Papers in this issue ofthe Journal in its early stages of development. look at some of Digital's techologies and products High performance must extend to the database that provide these system characteristics in three system. ln their paper on database availability, areas: distributed transaction processing, database Ananth Raghavan and T. K. Rengarajan exam ine access, and system fau lt tolerance. strategies and novel techniques that minimize the Opening the issue is a discussion of the architec­ affects of downtime situations. The two databases ture, DECdta, which ensures reliable interoperation referenced in their discussion are the VAX Rdb/YMS in a distributed environment. Phil Bernstein, Bill and VA X DBMS systems. Both system s use a database Emberton, and Vijay Trehan define some transaction kernel called KODA, which provides transaction processing terminology and anal yze a TP applica­ capabilities and commit processing. Peter Spiro, tion to illustrate the need fo r separate architectural AshokJoshi, and T.K. Rengarajan explain the impor­ components. They then present overviews of each tance of commit processing relative to throughput of the components and interfaces of the distributed and describe new designs fo r improving the perfo r­ transaction processing architecture, giving partic­ mance of group commit processing. These designs ular attention to transaction management. were tested, and the results of these tests and the Two products, the ACMS and DECi ntact monitors, authors' observations are presented. implement several of the functions defined by the Equal ly as important in TP systems as database DECdta architecture and are the twin topics of a availability is system availability. The topic of the paper by To m Speer and Mark Storm. Although final paper in this issue is a system designed to be based on different implementation strategies, both continously available, the 3000 fault-tolerant ACMS and DECintact provide TP-specific services VAX.ft system. Authors Bill Bruckert, Carlos Alonso, and fo r developing, executing, and managing TP appli­ Jim Melvin give an overview of the system and then cations. To m and Mark discuss the two strategies fo cus on the fo ur-phase ve rification strategy devised and then highlight the functional simi larities and to ensure transparent system recovery from errors. differences of each monitor product. I thank Carlos Borgialli fo r his help in prepari ng The ACMS and DECintact monitors are layered on this issue and fo r writing the issue's Foreword. the VMS operating system, which provides base services for distributed transaction management. Described by Bill Laing, Jim Johnson, and Bob Landau, these VMS services, called DECdtm, are an 2 Biographies I Carlos Alonso A principal software engineer, Carlos Alonso is a team lead er fo r the project to port the System-V operating system to the VAXft 3000. Previously, he was the project leader fo r various VAXft 3000 system validation development efforts. As a member of the research group, Carlos developed the test bed fo r evaluating concurrency control algorithms using the VMS Distributed Lock Manager, and he designed the prototype alternate lock rebuild algorithm fo r cluster transitions. He holds a B.S.E.E. (1979) from Tulane University and an M.S.C.S. (1980) from Boston University. Wael Hilal Bahaa-El-Din Wael Bahaa-EI-Din joined Digital in 1987 as a senior consultant to the Systems Performance Group, Database Systems. He has led a number of studies to evaluate performance database and transaction process­ ing systems under response time constraints. After receiving his Ph.D. (1984) in computer and info rmation science from Ohio State University, Wael sp ent three years as an assistant professor at the University of Houston. He is a member of ACMS and IEEE, and he has written numerous art icles fo r profes­ sional journals and conferences. Philip A. Bernstein As a senior consultant engineer, Philip Bern st ei n is both an architectural consultant in the Transaction Processing Systems Group and a researcher at the Cambridge Research Laboratory.
Load more

Recommended publications
  • Rainblock: Faster Transaction Processing in Public Blockchains
    RainBlock: Faster Transaction Processing in Public Blockchains Soujanya Ponnapalli1, Aashaka Shah1, Souvik Banerjee1, Dahlia Malkhi2, Amy Tai3, Vijay Chidambaram1,3, and Michael Wei3 1University of Texas at Austin, 2Diem Association and Novi Financial, 3VMware Research Abstract Metric No state State: 10M Ratio We present RAINBLOCK, a public blockchain that achieves Time taken to mine txs (s) 1047 6340 6× " high transaction throughput without modifying the proof-of- # Txs per block 2150 833 2.5× # work consensus. The chief insight behind RAINBLOCK is that Tx throughput (txs/s) 28.6 4.7 6× # while consensus controls the rate at which new blocks are added to the blockchain, the number of transactions in each Table 1: Impact of system state on blockchain throughput. block is limited by I/O bottlenecks. Public blockchains like This table shows the throughput of Ethereum with proof-of- Ethereum keep the number of transactions in each block low work consensus when 30K txs are mined using three miners, so that all participating servers (miners) have enough time to in two scenarios: first, there are no accounts on the blockchain, process a block before the next block is created. By removing and in the second, 10M accounts have been added. Despite the I/O bottlenecks in transaction processing, RAINBLOCK al- no other difference, tx throughput is 6× lower in the second lows miners to process more transactions in the same amount scenario; we trace this to the I/O involved in processing txs. of time. RAINBLOCK makes two novel contributions: the RAIN- BLOCK architecture that removes I/O from the critical path of processing transactions (txs), and the distributed, multi- Bitcoin [1] and Ethereum, process only tens of transactions versioned DSM-TREE data structure that stores the system per second, limiting their applications [33, 65].
    [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]
  • What Is a Database Management System? What Is a Transaction
    What is a Database? Collection of data central to some enterprise Overview of Databases and Essential to operation of enterprise Transaction Processing Contains the only record of enterprise activity An asset in its own right Chapter 1 Historical data can guide enterprise strategy Of interest to other enterprises State of database mirrors state of enterprise Database is persistent 2 What is a Database Management What is a Transaction? System? When an event in the real world changes the A Database Management System (DBMS) state of the enterprise, a transaction is is a program that manages a database: executed to cause the corresponding change in the database state Supports a high-level access language (e.g. With an on-line database, the event causes the SQL). transaction to be executed in real time Application describes database accesses using A transaction is an application program that language. with special properties - discussed later - to DBMS interprets statements of language to guarantee it maintains database correctness perform requested database access. 3 4 What is a Transaction Processing Transaction Processing System System? Transaction execution is controlled by a TP monitor s DBMS database n o i Creates the abstraction of a transaction, t c a analogous to the way an operating system s n a r creates the abstraction of a process t DBMS database TP monitor and DBMS together guarantee the special properties of transactions TP Monitor A Transaction Processing System consists of TP monitor, databases, and transactions 5 6 1 System
    [Show full text]
  • Transaction Processing Monitors
    Chapter 24: Advanced Transaction Processing ! Transaction-Processing Monitors ! Transactional Workflows ! High-Performance Transaction Systems ! Main memory databases ! Real-Time Transaction Systems ! Long-Duration Transactions ! Transaction management in multidatabase systems 1 Database System Concepts 24.1 ©Silberschatz, Korth and Sudarshan Transaction Processing Monitors ! TP monitors initially developed as multithreaded servers to support large numbers of terminals from a single process. ! Provide infrastructure for building and administering complex transaction processing systems with a large number of clients and multiple servers. ! Provide services such as: ! Presentation facilities to simplify creating user interfaces ! Persistent queuing of client requests and server responses ! Routing of client messages to servers ! Coordination of two-phase commit when transactions access multiple servers. ! Some commercial TP monitors: CICS from IBM, Pathway from Tandem, Top End from NCR, and Encina from Transarc 2 Database System Concepts 24.2 ©Silberschatz, Korth and Sudarshan 1 TP Monitor Architectures 3 Database System Concepts 24.3 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures (Cont.) ! Process per client model - instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions. ! Memory requirements are high ! Multitasking- high CPU overhead for context switching between processes ! Single process model - all remote terminals connect to a single server process. ! Used in client-server environments ! Server process is multi-threaded; low cost for thread switching ! No protection between applications ! Not suited for parallel or distributed databases 4 Database System Concepts 24.4 ©Silberschatz, Korth and Sudarshan 2 TP Monitor Architectures (Cont.) ! Many-server single-router model - multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.
    [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]
  • I Txso C~T Dc~ 5 SPD / LETTER FC~R
    i DIGITAL Digital Equipm~t3t Corporation SOFTW~►,RE Digital Drive SILL OF MATERIALS Westminster, Massachusetts 01473-0471 Option Number Option Title Date Page ~ QA-10 OAA-W55.6 ~rAX FORTF~? V5.6 UPD TK5 0 28-Feb-91 1 of 1 ~TY PICK LOCATION PART NLJL~ER PART DESCRIPTION .~_ -.. 1 *FS* 36-28231-07 TRE~I~ZA~L S~~RCODE LABEL 1 *FS* 99-08545-02 BOOKT~IRAP 1 t UR) AQ-FP 8 6N-BN ~irAX FORTP~AN V5.6 BIN TK5 0 1 ~ DP ~ AV-PF4FA-TK SUP REPLACEMENT LETTER 1 EN-01044-07 SFT'WR PERFOF~!~ANCE REPORT FORM 1 ***** NS ~~~ QA-10 OAA-WZ 5.6 ~irAX FORTF~AN V5.6 UPD DOC 1 *FS* 36-28231-0? THEF~!zA,L P.~ARCODE LABEL 1 *FS* 99-08545-02 BOOKT~IRAP 1 (UR} AE-JF8?L-TE ~irAX FORTP►AN V5.6 SPD 2 5.16.3 6 1 - t~~ AE-LT36H-TE ~irAX FORTP;AN SSA 2 5.16.3 6 -A 1 SDP ) AE -1~tA,5 OA- TK SOFTWARE W TY ADDENDUM 1 tUR~ AV-N672V-TE V'AX FORTP►AN V5.6 PAD FIRS T 1 EN-02512-05 C~3LANGE OF ADDRESS CARD ilk.~ r~~i~li~ilpirfi~~ra~~reis~-~-~~~------~----~~~~ t~ii~~l~+~r~~~-~~~--~--~.r~.~ i Txso c~t Dc~ 5 SPD / LETTER FC~R : AV-PF4FA- TK October, 1990 d 9 Dear Service Customer, Enclosed is a software product update/maintenance release supplied as part of your software maintenance agreement. As part of its planned License Management Zbols program, Digital has initiated replacement of all Service Update PAKs (SUPs) for licensed software product with License Product Authorization Keys (PAKs).
    [Show full text]
  • Openvms DCL Dictionary: N–Z
    OpenVMS DCL Dictionary: N–Z Order Number: AA–PV5LG–TK April 2001 This manual provides detailed reference information and examples for Compaq OpenVMS DCL commands and lexical functions. Revision/Update Information: This manual supersedes the OpenVMS DCL Dictionary, Version 7.2. Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, VAX, VMS, and the Compaq logo Registered in U.S. Patent and Trademark Office. OpenVMS and Tru64 are trademarks of Compaq Information Technologies Group, L.P in the United States and other countries. Microsoft, MS-DOS, Visual C++, Windows, and Windows NT are trademarks of Microsoft Corporation in the United States and other countries. Intel, Intel Inside, and Pentium are trademarks of Intel Corporation in the United States and other countries. Motif, OSF/1, and UNIX are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products.
    [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]
  • Concurrency Control and Recovery ACID • Transactions • Recovery Transaction Model Concurency Control Recovery
    Data Management Systems • Transaction Processing • Concurrency control and recovery ACID • Transactions • Recovery Transaction model Concurency Control Recovery Gustavo Alonso Institute of Computing Platforms Department of Computer Science ETH Zürich Transactions-CC&R 1 A bit of theory • Before discussing implementations, we will cover the theoretical underpinning behind concurrency control and recovery • Discussion at an abstract level, without relation to implementations • No consideration of how the concepts map to real elements (tuples, pages, blocks, buffers, etc.) • Theoretical background important to understand variations in implementations and what is considered to be correct • Theoretical background also key to understand how system have evolved over the years Transactions-CC&R 2 Reference Concurrency Control and Recovery in Database Systems Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman • https://www.microsoft.com/en- us/research/people/philbe/book/ Transactions-CC&R 3 ACID Transactions-CC&R 4 Conventional notion of database correctness • ACID: • Atomicity: the notion that an operation or a group of operations must take place in their entirety or not at all • Consistency: operations should take the database from a correct state to another correct state • Isolation: concurrent execution of operations should yield results that are predictable and correct • Durability: the database needs to remember the state it is in at all moments, even when failures occur • Like all acronyms, more effort in making it sound cute than in
    [Show full text]
  • VAX-Computer
    wdv-notes Stand: 24.JUL.1993 (4.) 188 VAX Computer: Modell-Übersicht. Wiss.Datenverarbeitung © 1980–1993 Karl-Heinz Dittberner FREIE UNIVERSITÄT BERLIN Hard Mit der folgenden Liste wird versucht, die ID-Bezeichnung, die relative (auf die Als Quellen wurden diverse DEC-Pu- alle von der Firma Digital Equipment VAX-11/780 bezogene) Leistungsfähig- blikationen verwendet sowie die Beschrei- Corporation (DEC) produzierten Modelle keit in VUPS, die in etwa dem MIPS bungen von SYS$GETSYI in der VMS- der Computer-Familien der VAX und der entspricht, die Typen der vorhandenen I/ Dokumentation und von $PRDEF, $VAX- Alpha AXP in einer konzentrierten Form O-Busse, der Modell-Name sowie der DEF und $ALPHADEF in der System zu erfassen. Tarnname (code name). Macro Library. Das Verzeichnis wurde im Die Übersicht ist nach Prozessor-Fa- Bei den Bus-Bezeichnungen bedeu- März 1993 der im UseNET von Paul Hardy milien und innerhalb dieser nach Subtypen ten: U = UniBus, M = MassBus, C = CI- (Email: [email protected]) veröffentlichten (X bzw. S) gegliedert. Angegeben sind für Bus, Q = Q-Bus, B = BI-Bus, D = DSSI, X Liste angepaßt. Alle zur Zeit noch aktuel- die einzelnen Computer-Modelle die SID- = XMI, T = TurboChannel, S = SCSI, F = len Modelle sind hinter dem Code-Namen Bezeichnung, die den CPU-Typ enthält, FutureBus+, E = EISA-Bus. mit einem * versehen. SID X ID VUPS Bus Model Name Code Name SID X ID VUPS Bus Model Name Code Name —— 1977: 700 series ———————————————————————————— —— 1991: NVAX+ chip series ———– Decimal SID = 385875968 ———————— 0100xxxx – 780 1.0
    [Show full text]
  • Transactions and Failure Recovery
    Transactions and Failure Recovery Instructor: Matei Zaharia cs245.stanford.edu Outline Defining correctness Transaction model Hardware failures Recovery with logs CS 245 2 Outline Defining correctness Transaction model Hardware failures Recovery with logs CS 245 3 Focus of This Part of Course Correctness in case of failures & concurrency » There’s no point running queries quickly if the input data is wrong! CS 245 4 Correctness of Data Would like all data in our system to be “accurate” or “correct” at all times » Both logical data model and physical structs Employees Name Age Smith 52 Green 3421 Chen 1 CS 245 5 Idea: Integrity or Consistency Constraints Predicates that data structures must satisfy Examples: » X is an attribute of relation R » Domain(X) = {student, prof, staff} » If X = prof in a record then office != NULL in it » T is valid B-tree index for attribute X of R » No staff member should make more than twice the average salary CS 245 6 Definition Consistent state: satisfies all constraints Consistent DB: DB in consistent state CS 245 7 Constraints (As We Use Here) May Not Capture All Issues Example 1: transaction constraints When a salary is updated, new salary > old salary When an account record is deleted, balance = 0 CS 245 8 Constraints (As We Use Here) May Not Capture All Issues Note: some transaction constraints could be “emulated” by simple constraints, e.g., account acct # … balance is_deleted CS 245 9 Constraints (As We Use Here) May Not Capture All Issues Example 2: database should reflect real world DB Reality CS 245 10 Constraints (As We Use Here) May Not Capture All Issues Example 2: database should reflect real world DB Reality CS 245 11 In Any Case, Continue with Constraints..
    [Show full text]
  • Best Practices and Sizing Guidelines for Transaction Processing Applications with Microsoft SQL Server 2012 Using Equallogic PS Series Storage
    Best Practices and Sizing Guidelines for Transaction Processing Applications with Microsoft SQL Server 2012 using EqualLogic PS Series Storage A Dell EqualLogic Best Practices Technical White Paper Dell Storage Engineering March 2013 Revisions Date Description March 13, 2013 Initial release March 18, 2013 Corrected links © 2013 Dell Inc. All Rights Reserved. Dell, the Dell logo, and other Dell names and marks are trademarks of Dell Inc. in the US and worldwide. All other trademarks mentioned herein are the property of their respective owners. 2 BP1032 | Best Practices and Sizing Guidelines for Transaction Processing Applications with Microsoft SQL Server 2012 using EqualLogic PS Series Storage Table of contents Acknowledgements .......................................................................................................................................................................... 5 Feedback ............................................................................................................................................................................................ 5 Executive summary .......................................................................................................................................................................... 6 1 Introduction ................................................................................................................................................................................ 7 1.1 Objective..........................................................................................................................................................................
    [Show full text]