An Implementation of Transaction Logging and Recovery in a Main Memory Resident Database System Abstract This report describes an implementation of Transaction Logging and Recovery using Unix Copy-On-Write on spawned processes. The purpose of the work is to extend WS-Iris, a research project on Object Oriented Main Memory Databases, with functionality for failure recovery. The presented work is a Master Thesis for a student of Master of Science in Computer Science and Technology. The work has been commissioned by Tore Risch, Professor of Engineering Databases at Computer Aided Engineering laboratory (CAElab), Linköping University (LiU/LiTH), Sweden. Keywords Transaction logging, logical logging, recovery, main memory database, copy- on-write, process forking Jonas S Karlsson CAElab, IDA, Linköping University CHAPTER 1 Introduction 5 1.1 WS-Iris 5 1.2 Reason & Goal 5 1.3 Contents 6 CHAPTER 2 WS-Iris 7 2.1 Internal Workings 7 2.1.1 The self-contained Lisp 8 2.1.2 Foreign functions 8 2.2 Image 8 2.3 Logging (Histories) 8 CHAPTER 3 Survey on Recovery 9 3.1 Introduction 9 3.2 Saved Images 10 3.2.1 Ping-Pong (Duplex strategy) 10 3.2.2 Fuzzy Checkpointing (Monoplex strategy) 11 3.2.3 Black/White Checkpointing 11 3.2.4 Copy-on-Update Checkpointing 12 3.3 Logging 12 3.3.1 Physical Page Logging 12 3.3.2 Physical Transition Page Logging 13 3.3.3 Transition Access logging 13 3.3.4 Logical Logging on Recordlevel 13 CHAPTER 4 Requirements 14 4.1 Important Facts 14 4.2 Main idea 15 4.2.1 Image 15 4.2.2 Logging 17 4.3 Conclusions 17 CHAPTER 5 Implementation 18 5.1 Symbols 18 5.2 Building a Recovery System 20 5.3 Language 23 5.3.1 Datatypes - Lisp 24 5.3.2 C language - Operating system interface 24 5.4 Storage-system 24 5.5 Image 26 5.5.1 Improvements 26 5.5.2 Algorithm 27 5.5.3 Options 28 Transaction Logging and Recovery for a Main Memory OODB 3 5.6 Logging 29 5.6.1 Improvements 29 5.6.2 Algorithm 29 5.6.3 Options 31 5.7 Recovery 31 5.7.1 Improvements 31 5.7.2 Algorithm for handling files 32 5.7.3 Algorithm for Recovery 33 5.7.4 Lisp Extensions 33 CHAPTER 6 Evaluation 36 6.1 Testing method 36 6.2 The tests 37 6.3 Possible Improvements 39 6.4 Software Engineering aspects 41 6.5 Acknowledgments 41 CHAPTER 7 Definitions 42 CHAPTER 8 References 45 Transaction Logging and Recovery for a Main Memory OODB 4 CHAPTER 1 Introduction In this section, an introduction to theWS-Iris database system and motivation for the work is given. 1.1 WS-Iris WS-Iris [Litwin-92] is a memory resident object oriented database system written by Tore Risch at the Database Technology Depart- ment, Hewlett-Packard Laboratories. 1.2 Reason & Goal The aim of this project is to enhance WS-Iris with recovery functions, which will be responsible for recovery after a crash. The reason for building a recovery-system is to secure data storage in the database. WS-Iris is a main memory resident database and thus there is no database on the disk that is constantly updated. Benefits thereby gained are tremendous at search and update time. The over- head for handling data can be minimized compared to a disk-based system. However, main memory is not stable memory, and the oper- ating system is not stable. Crashes will occur, and information stored in the computers memory will be lost forever. Data has to be saved (backuped) elsewhere, and this is the primary concern of this work. Transaction Logging and Recovery for a Main Memory OODB 5 Introduction The main causes for crashes are programming errors, operating sys- tem faults and hardware failures. These failures often lead to uncon- trolled process termination. This work is focused on handling data that has been committed to the database, and making that data persist- ent. 1.3 Contents Chapter 2 introduces the WS-Iris programming system. Aspects of WS-Iris directly concerned with the problem are described and exem- plified. Chapter 3 provides a short survey of well known methods used in research and commercial systems for recovery processing. In chapter 4 a specification is presented concerning the requirements of the work and the purpose of the work. Chapter 5 presents the chosen implementation and justifies the design decisions. Chapter 6 evaluates the implementation and the achieved results. Possible improvements are also briefly discussed. A compiled list of technical terms used in this thesis may be found in appendix A. Transaction Logging and Recovery for a Main Memory OODB 6 CHAPTER 2 WS-Iris This chapter describes functionality already present within the WS- Iris system that are of use when implementing a Recovery System. Further information about the Iris DBMS can be found in Object-Ori- ented Concepts, Databases, and Applications [Fishman-87]. 2.1 Internal Workings WS-IRIS is written and optimized with memory residency in mind. It is implemented in C giving a special version of Common Lisp under which Database Queries are executed using a transformation into ObjectLog that is interpreted by the Lisp. At the prototype stage, WS-IRIS was entirely written in Common Lisp but has later been migrated towards an implementation in C for reasons of efficiency, the interactive parts are still written with Lisp as a basis, however. Since WS-IRIS partly is implemented in C, and partly implemented in the Lisp that it implements, there is a powerful ”foreign” function interface utilities. This makes it possible to implement OSQL (Object Symbolic Query Language) and Lisp functions in C code. OSQL is used as the main database query language, and it uses the concepts of types, objects, and functions. Transaction Logging and Recovery for a Main Memory OODB 7 WS-Iris 2.1.1 The self-contained Lisp Lisp is good for prototyping and development of a system. One rea- son for not using C in this work, is that data is stored and created in the Lisp and therefore must be accessed using lisp primitives. This would mean that the C-code would not be plain C. So, since most structures and operators are easily accessible from Lisp, but only with effort from within C (one would effectively be writing Lisp in C) there are clearly advantages of using Lisp for implementation of algorithms. 2.1.2 Foreign functions Foreign functions are used as a means of extending the Lisp/OSQL language with various primitives, usually for interfacing to the oper- ating system and outside world. This is further explained in WS-Iris; A Main Memory Object Oriented DBMS [Risch-92]. 2.2 Image The data area called image in the WS-IRiS system contains all of the database and interfacing information for the database implementa- tion. When the image is stored on disk it is called a dump. When WS- Iris is started, a dump (amos.dmp) is automatically loaded. In WS-Iris there are functions for saving and loading a dump of the database. These functions are available from OSQL, Lisp as well as from C. An important issue is the consistency of the dump: a dump should only be performed on a committed database. This is ensured when the routines are called from OSQL, but care has to be exercised when they are called from Lisp. The dump also contains references to foreign functions. These are relocated at load-time. Lisp functions and variables available at save-time are also contained in the dump. 2.3 Logging (Histories) For logging purposes, there are history functionality that can be used. The data stored by the history function are undo and redo information specific for current, non-committed transactions. This information can be used at commit-time for creating a log. Transaction Logging and Recovery for a Main Memory OODB 8 CHAPTER 3 Survey on Recovery There has been quite a lot of work done in the database recovery area, mainly because of the fact that most database system still are manag- ing databases that resides on disk. Lately, however, there has been an amount of research on MMRDB (Main Memory Resident Data- Bases), and an identified problem is that of securing persistency. Dif- ferent systems for research on a variety of recovery algorithms has been written, Principles of Transaction-Oriented Database Recovery [Haerder-83] contains interesting material on the area of Recovery. 3.1 Introduction A MMRDB takes advantage of the residency fact, and can therefore achieve astonishingly fast results for creating and searching data. Also updates can be made at the same high-speed. But there is a prob- lem, since the data is stored in main memory it can also be lost quite easily. Therefore, in order to make sure that the changes made are persistent, they are often saved onto disk. Persistency means that the changes made to the database somehow can be recreated. It is often a a requirement that committed updates are persistent. The simplest way of accomplishing this is by using a log-file on disk on which, at each commit, the updates are written sequentially at the end. Having a log-file is sufficient, but not very economical. The time used for recreating the database, bringing it up-to-date using the log-file, will be linear to the size of the file. Therefore different strategies has been developed, called Checkpointing strategies. The obvious optimi- Transaction Logging and Recovery for a Main Memory OODB 9 Survey on Recovery zation is to try to keep a copy of the database image updated on disk.