Toward Online Schema Evolution for Non-Stop Systems Amol Deshpande, University of Maryland Michael Hicks, University of Maryland

Intelligent Design Schemas Evolve ! Changing business logic For improved performance …

Current Approach (??) Modify the application(s) to use new schema. Shut down the applications, and stop access to the database. Extract the DDL and authorizations for the table and dependent objects (views, indexes etc). Manually create the new table, re-create dependent objects, and populate the table. Drop the old table. Restart the application(s).

Problems with this approach Time-consuming (mostly) manual process Database unavailable during the process Application soft state (e.g. caches) is lost

What we would like Near-instantaneous online schema changes –Without stopping the access to the database for too long –Without killing the applications using the DB Even if the applications are affected by the change DB2 for z/OS V8 provides some support

Our Goal Provide both by combining: –Dynamic software updating Suite of techniques developed for dynamically updating running applications –Lazy data migration To affect immediate schema changes by delaying populating the new tables

Basic Approach Modify the application(s) to use new schema Create a dynamic patch using old and new copies of applications When all applications reach “safe point”’s: –Apply the patches to dynamically change the (running) applications –Change the schema, and create skeleton tables Convert the data to conform to new schema lazily –May need to use conversion functions for changes –E.g. changing char(15) to char(10)

Details Safe points: –Detected through static analysis –Based on putting constraints on changes that can be made to the schema at various points in applications Function f() performs an SQL query on the Street column of an Address table Can’t change Address to change/remove Street column while executing f() –An application typically has many safe points Static analysis also helps in detecting affected applications

Details Lazy data migration: –Empty skeleton tables are created initially –New tuples are directly inserted into the new tables –When a query is posed, sufficient data is accessed from the old table to populate the new table Use caching techniques to reason about contents of tables –“Drastic” option of converting the whole table anytime –Need to worry about: Integrity constraints ?

Questions, Comments…