OptimalGrid represents a new style of middleware for computing large connected problems in a distributed computing environment. Previous techniques have employed the "toolkit" approach, where the application writers would manually parallelize their problems, employing the programming interface of a specific parallel or distributed system. OptimalGrid removes that burden from the programmer by automating the problem partitioning, the problem deployment, the runtime management and the dynamic rebalancing/redeployment of the problem in the event of faults or performance problems. With OptimalGrid, the programmer is responsible only for the description of the problem, the problem algorithm, and the data; the rest is handled by the middleware.

Previous versions of DB2 Common Server had large objects (LOBs) that were neither large nor functional. Their size was limited to 32,700 bytes and, until recently when support for SUBSTR and CONCAT was added, there was no function available on these objects at all. DB2 LOBs were infants. However, with the latest release of DB2 Common Server, Version 2.1, LOBs have matured considerably supporting significantly larger sizes and many new language features. To give the reader a feeling for the extent of this new language support, we compare our new SQL LOB language features with that of three other major relational database competitors: Sybase, Informix and Oracle. Users will find the new DB2 LOBS easy to load and store, easy to search, and easy to integrate into the DB2 user-defined functions (UDFs) and user-defined types (UDTs). In addition, when used in serial mode, the performance of LOB I/O rivals that of file systems and, when used in parallel mode, is a clear winner. DB2 LOBs have now entered the teenage years.

Once considered a novelty, object oriented systems have now entered the mainstream. Their impressive performance and rich type systems have created a demand for object oriented features in other areas, such as relational database systems. We believe the current efforts to combine object oriented and relational features into a single hybrid system will fall short of the mark, whereas our approach, the co-existence approach, has the distinction of requiring far less work, but at the same time promising both the desired functionality and performance. We describe the attributes of our co-existing systems, an object oriented system (C++) and a relational system (Starburst), and show how this combination supports the desired features of both object-oriented and relational systems.

As part of the Starburst extensible database project, the authors have designed and implemented a memory resident storage component that can coexist along side traditional disk-oriented storage components. The memory resident storage component shares the code of Starburst's common services, such as query optimization, plan generation, query evaluation, record manipulation, and transaction management. The design of Starburst's memory resident storage component is discussed, contrasted with Starburst's default disk-oriented storage component, and compared to the performance of the two storage components using the Wisconsin Benchmarks. The results show that a memory resident storage component can perform significantly better than a disk-oriented storage component, even when the disk-oriented storage component has all of its data cached in memory. The benchmark results show that, by using memory resident techniques, overall query execution can be improved by up to a factor of four.>

No abstract available.

With memory prices dropping and memory sizes increasing accordingly, a number of researchers are addressing the problem of designing high-performance database systems for managing memory-resident data. In this paper we address the recovery problem in the context of such a system. We argue that existing database recovery schemes fall short of meeting the requirements of such a system, and we present a new recovery mechanism which is designed to overcome their shortcomings. The proposed mechanism takes advantage of a few megabytes of reliable memory in order to organize recovery information on a per “object” basis. As a result, it is able to amortize the cost of checkpoints over a controllable number of updates, and it is also able to separate post-crash recovery into two phases—high-speed recovery of data which is needed immediately by transactions, and background recovery of the remaining portions of the database. A simple performance analysis is undertaken, and the results suggest our mechanism should perform well in a high-performance, memory-resident database environment.

Most previous work in the area of main memory database systems has focused on the problem of developing query processing techniques that work well with a very large buffer pool. In this paper, we address query processing issues for memory resident relational databases, an environment with a very different set of costs and priorities. We present an architecture for a main memory DBMS, discussing the ways in which a memory resident database differs from a disk-based database. We then address the problem of processing relational queries in this architecture, considering alternative algorithms for selection, projection, and join operations and studying their performance. We show that a new index structure, the T Tree, works well for selection and join processing in memory resident databases. We also show that hashing methods work well for processing projections and joins, and that an old join method, sort-merge, still has a place in main memory.

We identify the roles played by design versions and alternatives in an engineering database. The obvious way to implement versions is to maintain each in a separate collection of files. Because several versions must be kept on line in a design environment, the approach leads to large disk requirements. We develop B-tree-based storage structures to encode versions as ``negative'' differential files. Our objective is to keep the disk requirements small. We discuss the effect of enormous amounts of cheap archival storage (write-once optical digital disks) on the proposed structures. We have implemented versions in the Wisconsin storage system (WiSS), an experimental database component developed at the University of Wisconsin-Madison.