DOCSLIB.ORG

Damage Management in Database Management Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Damage Management in Database Management Systems The Pennsylvania State University The Graduate School Department of Information Sciences and Technology Damage Management in Database Management Systems A Dissertation in Information Sciences and Technology by Kun Bai °c 2010 Kun Bai Submitted in Partial Ful¯llment of the Requirements for the Degree of Doctor of Philosophy May 2010 The dissertation of Kun Bai was reviewed and approved1 by the following: Peng Liu Associate Professor of Information Sciences and Technology Dissertation Adviser Chair of Committee Chao-Hsien Chu Professor of Information Sciences and Technology Thomas La Porta Distinguished Professor of Computer Science and Engineering Sencun Zhu Assistant Professor of Computer Science and Engineering Frederico Fonseca Associate Professor of Information Sciences and Technology Associate Dean, College of Information Sciences and Technology 1Signatures on ¯le in the Graduate School. iii Abstract In the past two decades there have been many advances in the ¯eld of computer security. However, since vulnerabilities cannot be completely removed from a system, successful attacks often occur and cause damage to the system. Despite numerous tech- nological advances in both security software and hardware, there are many challenging problems that still limit e®ectiveness and practicality of existing security measures. As Web applications gain popularity in today's world, surviving Database Man- agement System (DBMS) from an attack is becoming even more crucial than before because of the increasingly critical role that DBMS is playing in business/life/mission- critical applications. Although signi¯cant progress has been achieved to protect the DBMS, such as the existing database security techniques (e.g., access control, integrity constraint and failure recovery, etc.,), the buniness/life/mission-critical applications still can be hit due to some new threats towards the back-end DBMS. For example, in addition to the vulnerabilities exploited by attacks (e.g., the SQL injections attack), databases can be damaged in several ways such as the fraudulent transactions (e.g., identity theft) launched by malicious outsiders, erroneous transactions issued by the in- siders by mistakes. When the database is under such a circumstance (attack), rolling back and re-executing the damaged transactions are the most used mechanisms dur- ing the system recovery. This kind of mechanism either stops (or greatly restricts) the database service during repair, which causes unacceptable data availability loss or denial- of-service for mission critical applications, or may cause serious damage spreading during iv on-the-fly recovery where many clean data items are accidentally corrupted by legitimate new transactions. In this study, we address database damage management (DBDM), a very important problem faced today by a large number of mission/life/business-critical applications and information systems that must manage risk, business continuity, and assurance in the presence of severe cyber attacks. Although a number of research projects have been done to tackle the emerging data corruption threats, existing mechanisms are still limited in meeting four highly de- sired requirements: near-zero-run-time overhead, zero-system-down time, zero-blocking- time for read-only transactions, minimal-delay-time for read-write transactions. Firstly, to achieve the four highly desired requirements, we propose TRACE, a zero-system- down-time database damage tracking, quarantine, and recovery solution with negligible run time overhead. TRACE consists of a family of new database damage tracking, quarantine, and cleansing techniques. We built TRACE into the kernel of PostgreSQL. Secondly, motivated by the limitation of TRACE mechanism, we propose a novel proac- tive damage management approach denoted database ¯rewalling. This approach deals with transaction level attacks. Pattern mining and Bayesian network techniques are adopted in the ¯rewalling framework to mine frequent damage spreading patterns and to predict the data integrity in the face of attack when certain type of attack occurs repeatedly. This pattern mining and Bayesian inference approach provides a probability based strategy to estimate the data integrity on the fly. With this probabilistic feature, the database ¯rewalling approach is able to enforce a policy of transaction ¯ltering to dynamically ¯lter out the potential damage spreading transactions. v Table of Contents List of Tables :::::::::::::::::::::::::::::::::::::: x List of Figures ::::::::::::::::::::::::::::::::::::: xi Acknowledgments ::::::::::::::::::::::::::::::::::: xiii Chapter 1. Introduction :::::::::::::::::::::::::::::::: 1 1.1 Problems in This Study . 4 1.1.1 Light Weighted Damage Quarantine and Recovery System . 4 1.1.2 Preventive Damage Management Approach . 5 1.2 Contributions of This Work . 7 1.3 Outline . 8 Chapter 2. Related Works :::::::::::::::::::::::::::::: 10 2.1 Traditional Database Security Research . 11 2.2 Failure Handling Research . 16 2.3 Intrusion Detection System (IDS) Research . 20 2.4 Intrusion Tolerant Database Research . 27 2.4.1 Self-Healing Software Systems . 27 2.4.2 Intrusion Tolerant Database Systems . 32 Chapter 3. The TRACE Damage Management System :::::::::::::: 42 3.1 Introduction . 42 vi 3.2 Background . 44 3.2.1 Existing Solutions and Their Limitations . 45 3.3 Preliminaries and Problem Statement . 47 3.3.1 The Threat Model . 47 3.3.2 An Motivated Example using SQL Injection Attack . 48 3.3.3 Basic Concepts of the Database System . 49 3.3.4 Problem Statement . 50 3.3.4.1 Dependency Relations . 50 3.3.4.2 Problem Statement . 52 3.4 Overview of Approach . 53 3.4.1 Assumptions . 54 3.4.2 The Standby Mode . 55 3.4.3 The Cleansing Mode . 58 3.4.3.1 Damage Quarantine . 58 3.4.3.2 Damage Assessment . 60 3.4.3.3 Valid Data De-Quarantine . 61 3.4.3.4 Repairing On-The-Fly . 64 3.5 Design and Implementation of TRACE atop PostgreSQL . 65 3.5.1 Implementing the Marking Scheme . 66 3.5.2 Maintaining Before Images . 68 3.5.3 Damage Assessment Module . 68 3.5.4 Quarantine/De-Quarantine Module . 69 3.5.5 On-The-Fly Repairing . 71 vii 3.5.6 Garbage collection . 72 3.6 TRACE-FG: A Fine-Grained Damage Management Scheme . 75 3.6.1 A Fine-grained Version-data-status-identi¯cation Method . 75 3.6.2 Fine-grained De-quarantine and Repair . 78 3.7 Experimental Results . 79 3.7.1 Evaluation of TRACE System . 79 3.7.1.1 System Overhead . 80 3.7.1.2 Zero System Down Time . 81 3.7.1.3 TRACE vs. `point-in-time' recovery . 83 3.7.1.4 System CPU Time Distribution . 86 3.7.1.5 Reduced Service Delay Time and Saved Legitimate Transactions . 87 3.7.1.6 IDS Impacts on TRACE System . 90 3.7.2 Evaluation of TRACE-FG System . 93 3.7.2.1 Saved Data Versions . 95 3.7.2.2 Reduced Delay Time/Saved De-committed Transac- tions . 98 3.7.2.3 TRACE-FG vs. TRACE and `point-in-time' on Sys- tem Throughput . 100 3.8 Discussion . 101 3.9 Appendix . 102 3.9.1 TPC-C Transaction Read/Write Set Template . 102 3.9.2 Clinic OLTP Application Transaction Read/Write Template . 105 viii Chapter 4. Preventive Damage Management through Filtering of Damage Spread- ing Transactions ::::::::::::::::::::::::::::: 109 4.1 Introduction . 109 4.2 Background and Preliminaries . 111 4.2.1 The Threat Model . 111 4.2.2 The System Model . 112 4.3 Overview of Approach . 113 4.3.1 Rational . 114 4.3.2 Database Firewall Architecture . 115 4.4 Mining Damage Spreading Patterns . 118 4.4.1 Two Types of Damage Spreading Patterns . 118 4.4.2 Mining The Damage Spreading Patterns . 119 4.4.2.1 Basic De¯nitions . 120 4.4.2.2 Finding One-Hop Spreading Patterns . 122 4.4.2.3 Finding Multi-Hop Spreading Patterns . 123 4.5 Integrity Level Estimator . 124 4.5.1 Bayesian Network Based Analysis on Data Integrity . 126 4.5.2 Integrity Estimation Using Bayesian Network . 128 4.5.3 Algorithm of Integrity Estimation . 131 4.5.4 Updating the Filtering Rules On-The-Fly . 131 4.6 Experimental Results . 133 4.6.1 Experiment Settings . 134 4.6.2 Mining Algorithms Testing . 135 ix 4.6.3 System Integrity Analysis . 137 4.6.4 System Availability Analysis . 139 4.6.5 System Throughput Analysis . 141 Chapter 5. Conclusion ::::::::::::::::::::::::::::::::: 145 5.1 Summary . 145 5.2 Future Work . 148 5.2.1 Research Plan . 148 5.2.1.1 Task 1. Non-Blocking Repair Using a Shadow Database. 149 5.2.1.2 Task 2. Machine Learning based Preventive Damage Management. 150 Bibliography :::::::::::::::::::::::::::::::::::::: 151 x List of Tables 3.1 Existing Approaches and Their Limitations. 44 3.2 TPC-C Parameters and Their Values . 80 A 4.1 An Example of Attack History Hi . 112 A 4.2 An Example of An Attack History Hi Grouped By Patient ID and Sorted By Transaction Time . 113 4.3 One-Hop Spreading Pattern Mapping . 121 A0 4.4 An Example of Attack Histories Hi After Mapping . 121 4.5 An Example of Using Attack Histories to Mine One-Hop Spreading Patterns 121 4.6 TPC-C Parameters and Their Values . 135 4.7 Parameters of the synthetic datasets . 135 4.8 Parameter values of the datasets . 136 4.9 Measurement of the Mining Algorithm of One-hop Patterns . 136 4.10 Speed of System Integrity Estimation . 138 xi List of Figures 3.1 An Example of Damage Spreading . 46 3.2 The TRACE System Workflow . 55 3.3 An Example of the Causality Table Construction . 56 3.4 Identify/Repair Corrupted Data Records Overview . 59 3.5 Example of Repairing Corrupted Data Records . 62 3.6 Data Record Structure with Marking Bits . 67 3.7 TRACE Assessment/Repair with Causality Table in PostgreSQL . 70 3.8 An Example of the relationship between the process window and the missing probability . 74 3.9 Cases of Assessment Procedure Limitations .
Load more

Recommended publications
  • ACID, Transactions
    ECE 650 Systems Programming & Engineering Spring 2018 Database Transaction Processing Tyler Bletsch Duke University Slides are adapted from Brian Rogers (Duke) Transaction Processing Systems • Systems with large DB’s; many concurrent users – As a result, many concurrent database transactions – E.g. Reservation systems, banking, credit card processing, stock markets, supermarket checkout • Need high availability and fast response time • Concepts – Concurrency control and recovery – Transactions and transaction processing – ACID properties (desirable for transactions) – Schedules of transactions and recoverability – Serializability – Transactions in SQL 2 Single-User vs. Multi-User • DBMS can be single-user or multi-user – How many users can use the system concurrently? – Most DBMSs are multi-user (e.g. airline reservation system) • Recall our concurrency lectures (similar issues here) – Multiprogramming – Interleaved execution of multiple processes – Parallel processing (if multiple processor cores or HW threads) A A B B C CPU1 D CPU2 t1 t2 t3 t4 time Interleaved concurrency is model we will assume 3 Transactions • Transaction is logical unit of database processing – Contains ≥ 1 access operation – Operations: insertion, deletion, modification, retrieval • E.g. things that happen as part of the queries we’ve learned • Specifying database operations of a transaction: – Can be embedded in an application program – Can be specified interactively via a query language like SQL – May mark transaction boundaries by enclosing operations with: • “begin transaction” and “end transaction” • Read-only transaction: – No database update operations; only retrieval operations 4 Database Model for Transactions • Database represented as collection of named data items – Size of data item is its “granularity” – E.g. May be field of a record (row) in a database – E.g.
    [Show full text]
  • Cohesity Dataplatform Protecting Individual MS SQL Databases Solution Guide
    Cohesity DataPlatform Protecting Individual MS SQL Databases Solution Guide Abstract This solution guide outlines the workflow for creating backups with Microsoft SQL Server databases and Cohesity Data Platform. Table of Contents About this Guide..................................................................................................................................................................2 Intended Audience..............................................................................................................................................2 Configuration Overview.....................................................................................................................................................2 Feature Overview.................................................................................................................................................................2 Installing Cohesity Windows Agent..............................................................................................................................2 Downloading Cohesity Agent.........................................................................................................................2 Select Coheisty Windows Agent Type.........................................................................................................3 Install the Cohesity Agent.................................................................................................................................3 Cohesity Agent Setup........................................................................................................................................4
    [Show full text]
  • Django-Transaction-Hooks Documentation Release 0.2.1.Dev1
    django-transaction-hooks Documentation Release 0.2.1.dev1 Carl Meyer December 12, 2016 Contents 1 Prerequisites 3 2 Installation 5 3 Setup 7 3.1 Using the mixin.............................................7 4 Usage 9 4.1 Notes...................................................9 5 Contributing 13 i ii django-transaction-hooks Documentation, Release 0.2.1.dev1 A better alternative to the transaction signals Django will never have. Sometimes you need to fire off an action related to the current database transaction, but only if the transaction success- fully commits. Examples: a Celery task, an email notification, or a cache invalidation. Doing this correctly while accounting for savepoints that might be individually rolled back, closed/dropped connec- tions, and idiosyncrasies of various databases, is non-trivial. Transaction signals just make it easier to do it wrong. django-transaction-hooks does the heavy lifting so you don’t have to. Contents 1 django-transaction-hooks Documentation, Release 0.2.1.dev1 2 Contents CHAPTER 1 Prerequisites django-transaction-hooks supports Django 1.6.x through 1.8.x on Python 2.6, 2.7, 3.2, 3.3 and 3.4. django-transaction-hooks has been merged into Django 1.9 and is now a built-in feature, so this third-party library should not be used with Django 1.9+. SQLite3, PostgreSQL (+ PostGIS), and MySQL are currently the only databases with built-in support; you can exper- iment with whether it works for your favorite database backend with just a few lines of code. 3 django-transaction-hooks Documentation, Release 0.2.1.dev1 4 Chapter 1.
    [Show full text]
  • Transactions.Pdf
    BIT 4514: Database Technology for Business Fall 2019 Database transactions 1 1 Database transactions • A database transaction is any (possibly multi-step) action that reads from and/or writes to a database – It may consist of a single SQL statement or a collection of related SQL statements ex: Adding a new lunch to the class database – requires two related INSERT statements 2 2 Transactions (cont.) • A successful transaction is one in which all of the SQL statements are completed successfully – A consistent database state is one in which all data integrity constraints are satisfied – A successful transaction changes the database from one consistent state to another 3 3 1 Transaction management • Improper or incomplete transactions can have a devastating effect on database integrity Ex: INSERT only items into the Lunch_item table • If a DBMS supports transaction management, it will roll back an inconsistent database (i.e., the result of an unsuccessful transaction) to a previous consistent state. 4 4 Properties of a transaction • Atomicity • Consistency • Isolation • Durability • Every transaction MUST exhibit these four properties 5 5 Properties of a transaction • Atomicity – The "all or nothing" property – All transaction operations must be completed i.e. a transaction is treated as a single, indivisible, logical unit of work • Consistency – When a transaction is completed, the database must be in a consistent state 6 6 2 Properties of a transaction • Isolation – Data used during the execution of a transaction cannot be used by a second
    [Show full text]
  • Database Systems 09 Transaction Processing
    1 SCIENCE PASSION TECHNOLOGY Database Systems 09 Transaction Processing Matthias Boehm Graz University of Technology, Austria Computer Science and Biomedical Engineering Institute of Interactive Systems and Data Science BMVIT endowed chair for Data Management Last update: May 13, 2019 2 Announcements/Org . #1 Video Recording . Since lecture 03, video/audio recording . Link in TeachCenter & TUbe . #2 Exercises . Exercise 1 graded, feedback in TC in next days 77.4% . Exercise 2 still open until May 14 11.50pm (incl. 7 late days, no submission is a mistake) 53.7% . Exercise 3 published and introduced today . #3 CS Talks x4 (Jun 17 2019, 5pm, Aula Alte Technik) . Claudia Wagner (University Koblenz‐Landau, Leibnitz Institute for the Social Sciences) . Title: Minorities in Social and Information Networks . Dinner opportunity for interested female students! INF.01014UF Databases / 706.004 Databases 1 – 09 Transaction Processing Matthias Boehm, Graz University of Technology, SS 2019 3 Announcements/Org, cont. #4 Infineon Summer School 2019 Sensor Systems . Where: Infineon Technologies Austria, Villach Carinthia, Austria . Who: BSc, MSc, PhD students from different fields including business informatics, computer science, and electrical engineering . When: Aug 26 through 30, 2019 . Application deadline: Jun 16, 2019 . #5 Poll: Date of Final Exam . We’ll move Exercise 4 to Jun 25 . Current date: Jun 24, 6pm . Alternatives: Jun 27, 4pm / 7.30pm, or week starting Jul 8 (Erasmus?) INF.01014UF Databases / 706.004 Databases 1 – 09 Transaction Processing Matthias Boehm, Graz University of Technology, SS 2019 4 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 .
    [Show full text]
  • A Dictionary of DBMS Terms
    A Dictionary of DBMS Terms Access Plan Access plans are generated by the optimization component to implement queries submitted by users. ACID Properties ACID properties are transaction properties supported by DBMSs. ACID is an acronym for atomic, consistent, isolated, and durable. Address A location in memory where data are stored and can be retrieved. Aggregation Aggregation is the process of compiling information on an object, thereby abstracting a higher-level object. Aggregate Function A function that produces a single result based on the contents of an entire set of table rows. Alias Alias refers to the process of renaming a record. It is alternative name used for an attribute. 700 A Dictionary of DBMS Terms Anomaly The inconsistency that may result when a user attempts to update a table that contains redundant data. ANSI American National Standards Institute, one of the groups responsible for SQL standards. Application Program Interface (API) A set of functions in a particular programming language is used by a client that interfaces to a software system. ARIES ARIES is a recovery algorithm used by the recovery manager which is invoked after a crash. Armstrong’s Axioms Set of inference rules based on set of axioms that permit the algebraic mani- pulation of dependencies. Armstrong’s axioms enable the discovery of minimal cover of a set of functional dependencies. Associative Entity Type A weak entity type that depends on two or more entity types for its primary key. Attribute The differing data items within a relation. An attribute is a named column of a relation. Authorization The operation that verifies the permissions and access rights granted to a user.
    [Show full text]
  • PL/SQL Transactions
    PPLL//SSQQLL -- TTRRAANNSSAACCTTIIOONNSS http://www.tutorialspoint.com/plsql/plsql_transactions.htm Copyright © tutorialspoint.com A database transaction is an atomic unit of work that may consist of one or more related SQL statements. It is called atomic because the database modifications brought about by the SQL statements that constitute a transaction can collectively be either committed, i.e., made permanent to the database or rolled back undone from the database. A successfully executed SQL statement and a committed transaction are not same. Even if an SQL statement is executed successfully, unless the transaction containing the statement is committed, it can be rolled back and all changes made by the statements can be undone. Starting an Ending a Transaction A transaction has a beginning and an end. A transaction starts when one of the following events take place: The first SQL statement is performed after connecting to the database. At each new SQL statement issued after a transaction is completed. A transaction ends when one of the following events take place: A COMMIT or a ROLLBACK statement is issued. A DDL statement, like CREATE TABLE statement, is issued; because in that case a COMMIT is automatically performed. A DCL statement, such as a GRANT statement, is issued; because in that case a COMMIT is automatically performed. User disconnects from the database. User exits from SQL*PLUS by issuing the EXIT command, a COMMIT is automatically performed. SQL*Plus terminates abnormally, a ROLLBACK is automatically performed. A DML statement fails; in that case a ROLLBACK is automatically performed for undoing that DML statement.
    [Show full text]
  • Benchmarking Mongodb Multi-Document Transactions in a Sharded Cluster
    San Jose State University SJSU ScholarWorks Master's Projects Master's Theses and Graduate Research Spring 5-14-2020 Benchmarking MongoDB multi-document transactions in a sharded cluster Tushar Panpaliya San Jose State University Follow this and additional works at: https://scholarworks.sjsu.edu/etd_projects Part of the Databases and Information Systems Commons Recommended Citation Panpaliya, Tushar, "Benchmarking MongoDB multi-document transactions in a sharded cluster" (2020). Master's Projects. 910. DOI: https://doi.org/10.31979/etd.ykxw-rr89 https://scholarworks.sjsu.edu/etd_projects/910 This Master's Project is brought to you for free and open access by the Master's Theses and Graduate Research at SJSU ScholarWorks. It has been accepted for inclusion in Master's Projects by an authorized administrator of SJSU ScholarWorks. For more information, please contact [email protected]. Benchmarking MongoDB multi-document transactions in a sharded cluster A Project Presented to The Faculty of the Department of Computer Science San José State University In Partial Fulfillment of the Requirements for the Degree Master of Science by Tushar Panpaliya May 2020 © 2020 Tushar Panpaliya ALL RIGHTS RESERVED The Designated Project Committee Approves the Project Titled Benchmarking MongoDB multi-document transactions in a sharded cluster by Tushar Panpaliya APPROVED FOR THE DEPARTMENT OF COMPUTER SCIENCE SAN JOSÉ STATE UNIVERSITY May 2020 Dr. Suneuy Kim Department of Computer Science Dr. Robert Chun Department of Computer Science Dr. Thomas Austin Department of Computer Science ABSTRACT Benchmarking MongoDB multi-document transactions in a sharded cluster by Tushar Panpaliya Relational databases like Oracle, MySQL, and Microsoft SQL Server offer trans- action processing as an integral part of their design.
    [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]
  • Cs6302 Database Management System Two Marks Unit I Introduction to Dbms
    CS6302 DATABASE MANAGEMENT SYSTEM TWO MARKS UNIT I INTRODUCTION TO DBMS 1. Who is a DBA? What are the responsibilities of a DBA? April/May-2011 A database administrator (short form DBA) is a person responsible for the design, implementation, maintenance and repair of an organization's database. They are also known by the titles Database Coordinator or Database Programmer, and is closely related to the Database Analyst, Database Modeller, Programmer Analyst, and Systems Manager. The role includes the development and design of database strategies, monitoring and improving database performance and capacity, and planning for future expansion requirements. They may also plan, co-ordinate and implement security measures to safeguard the database 2. What is a data model? List the types of data model used. April/May-2011 A database model is the theoretical foundation of a database and fundamentally determines in which manner data can be stored, organized, and manipulated in a database system. It thereby defines the infrastructure offered by a particular database system. The most popular example of a database model is the relational model. types of data model used Hierarchical model Network model Relational model Entity-relationship Object-relational model Object model 3.Define database management system. Database management system (DBMS) is a collection of interrelated data and a set of programs to access those data. 4.What is data base management system? A database management system (DBMS) is a software package with computer programs that control the creation, maintenance, and the use of a database. It allows organizations to conveniently develop databases for various applications by database administrators (DBAs) and other specialists.
    [Show full text]
  • DB2 12 for Z/OS Technical Overview and Highlights
    Front cover DB2 12 for z/OS Technical Overview and Highlights Gareth Jones John Campbell Redpaper Introduction This paper provides a high-level overview of the functions, features, and improvements that were introduced in IBM DB2® 12 for z/OS®. These businesses gain a competitive advantage, improve business efficiency and effectiveness, and discover business insights from their existing data. The paper is intended for DB2 system administrators, database administrators, and application programmers, but might also be of interest to IT managers and executives. A more detailed description of DB2 12 is available in IBM DB2 12 for z/OS Technical Overview, SG24-8383. The purpose of this paper is to provide the reader with an understanding of some of the key changes that were introduced in DB2 12 for z/OS, including the following topics: Performance for traditional workloads Performance enablers for modern applications Application Enablement Reliability, availability, and scalability Security Migration and prerequisites Before looking at those areas in detail, it is important to put the benefits DB2 12 delivers in the context in terms of four themes for this release: Application enablement DBA productivity OLTP performance Query performance Application enablement Each release of DB2 has included several application enablement features, and DB2 12 is no exception. It addresses a number of key customer requirements: Expand the use of the existing features of DB2 Make DB2 more available to modern applications by delivering mobile, hybrid cloud and DevOps enablement Enhance IDAA functionality by supporting a wider range of use cases Provide incremental improvements in the SQL and SQL/PL areas © Copyright IBM Corp.
    [Show full text]
  • Database Transactions
    lecture 10: Database transactions course: Database Systems (NDBI025) SS2011/12 doc. RNDr. Tomáš Skopal, Ph.D. Department of Software Engineering, Faculty of Mathematics and Physics, Charles University in Prague Today’s lecture outline • motivation and the ACID properties • schedules („interleaved“ transaction execution) – serializability – conflicts – (non)recoverable schedule • locking protocols – 2PL, strict 2PL, conservative 2PL – deadlock and prevention – phantom • alternative protocols Database transactions (NDBI025, Lect. 10) Motivation • need to execute complex database operations – like stored procedures, triggers, etc. – multi-user and parallel environment • database transaction – sequence of actions on database objects (+ others like arithmetic, etc.) • example – Let’s have a bank database with table Accounts and the following transaction to transfer money (pseudocode): transaction PaymentOrder(amount, fromAcc, toAcc) { 1. SELECT Balance INTO X FROM Accounts WHERE accNr = fromAcc 2. if (X < amount) AbortTransaction(“Not enough money!”); 3. UPDATE Accounts SET Balance = Balance – amount WHERE čÚčtu = fromAcc; 4. UPDATE Accounts SET Balance = Balance + amount WHERE čÚčtu = toAcc; 5. CommitTransaction; } Database transactions (NDBI025, Lect. 10) Transaction management in DBMS • application launches transactions • transaction manager executes transactions • scheduler dynamically schedules the parallel transaction execution, producing a schedule (history) • data manager executes partial operation of transactions DBMS transaction
    [Show full text]