Toward Online Schema Evolution for Non-Stop Systems

1
Toward Online Schema Evolution for Non-Stop
Systems

• Amol Deshpande, University of Maryland
• Michael Hicks, University of Maryland

2
Schemas Evolve !

• Changing business logic
• For improved performance

3
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).

4
Problems with this approach

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

5
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

6
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

7
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 points
• 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)

8
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
• Cant 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

9
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 ?

10
Questions, Comments