Transcript Toward Online Schema Evolution for Non

Toward Online Schema Evolution for
Non-Stop Systems
Amol Deshpande, University of Maryland
Michael Hicks, University of Maryland
Schemas Evolve !
Changing business logic
 For improved performance
…

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Intelligent Design
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…