SAND CDBMS Administration Guide
Persistent Mode Operations (Time Travel)


Chapter Index
Next Topic:
Configuring a Database for Time Travel Operation



What Is Time Travel?

SAND CDBMS Time Travel is a unique database versioning system that permits multiple different versions or "Snapshots" of a SAND database to be stored and re-used without requiring the creation of multiple physical copies of database files. Any of these database versions can be concurrently accessed and freely updated, without affecting the others. This is possible because SAND CDBMS, when operating in Persistent Mode, records only the changes made to the original data, and can then represent the resulting "updated state" as a new version of the complete database. This new version can later be used as a starting point for database clients, who can make further updates and thereby produce more versions. At any time, selected Time Travel database Snapshots can be merged together (for example, to collapse a series of daily updates into one that represents a week), or used to update the core database.

The Time Travel option enables the following unique functionality for database users:

Figure 1: Example of a Time Travel Environment


The Tree Structure of Database Versions

Normally, updating a database means simply replacing the old state of the database ("before") with a new one ("after") when the update is saved. When set to operate in Persistent mode, however, SAND CDBMS instead preserves the original state of the database and records any alterations in a separate Update File. Taken together, the original database and the Update File represent a new version (or Snapshot) of the database. This new database Snapshot can be started with the nserv database server program: nserv opens the Update File in conjunction with the original database, and reconstructs the appropriate state of the database to be presented to the user. If further alterations are made, they can be saved to a new Update File. This file, when read along with the previous Update File and the original database, will in turn represent another starting point for database clients.

In the Time Travel system, the initial state of the core physical database can be considered as the root node of a tree structure, which grows as each update is performed. Altered database versions (represented by the Update Files) are added to the tree as "child" nodes that are dependent on the Snapshot from which they started. When further changes are made to these new database versions, a new level of nodes is added, forming "branches" that represent the dependencies between the various states (see Figure 2 below).

Figure 2: The Tree Structure of Time Travel Database Versions