Database Isolation

This feature makes it possible to run multiple instances of the same version of Reality. Each instance runs completely independently of other instances in much the same way as different versions of Reality.

This has two main advantages:

• Application service providers who host Reality databases for a number of separate customers can run these databases in complete isolation.

• Users on one database are unable to disrupt users on other databases by, for example, leaving a transaction open and performing continuous updates, thus filling the raw log.

Each instance of Reality requires the same amount of memory and disk space as a normal (non-isolated) Reality installation.

Creating instances

A new instance cannot be used for creating or accessing databases before starting the Reality central service or daemon as appropriate.

For example, on Windows:

. realroot 3
realserv -s

Or on UNIX with the Korn shell:

. realroot 3
realstart

You create an additional instance of Reality with the realclone host utility. For example, to create a new instance numbered 3 of the currently selected version of Reality, enter:

realclone -c3

Once you have created a new instance, you need to associate one or more databases with it.

• You can associate an existing database with a Reality instance with the realbind host utility. For example, to associate database dbase3 with instance 3 of the current version of Reality, enter.

  realbind -b dbase3 3

• You can select the new instance using the realroot host utility, and then use mkdbase to create a new database. For example, on Windows you might enter the following:

  realroot 5
  mkdbase -S 100M dbase5

  or on UNIX with the Korn shell:

  . realroot 5
  mkdbase -S 100M dbase5

  Each of these creates a database called dbase5 associated with instance 5 of the current version of Reality.

Deleting instances

The realclone host utility also allows you to delete the Reality instances you have created. Before doing this, for each database associated with the instance you must either:

• Use realbind to move the database to another instance. For example, if the database dbase3 is associated with instance 3 of the current version of Reality, you could enter:

  realbind -u dbase3

  This removes the association between the database and the instance of Reality.

• Delete the database - use realroot to select the instance and then run rmdbase to delete the database. For example, on Windows:

realroot 3
rmdbase dbase3

or on UNIX with the Korn shell:

. realroot 3
rmdbase dbase3

You can then run realclone with the -d option to delete the instance:

realclone -d3

Updating the instance software

If you update your Reality software (for instance, by installing a patch), you must also update any additional instances. To do this, shut down the Reality central daemon or service as appropriate for that instance (on UNIX, use killreal; on Windows, realserv -e). Then run realclone with the -u option on the base instance. You can then restart the central daemon or service for the instance using realstart (UNIX) or realserv -s (Windows). Use realroot to select the appropriate instance at each stage.

For example, to upgrade instance 3 to the same software version as the base instance on Windows, run:

realroot 3	< select the instance
realserv -e	< stop the services for the instance
realroot		< select the base instance
realclone -pu3	< update the instance
realroot 3	< re-select the instance
realserv -s	< restart the services for the instance

or on UNIX with the Korn shell:

. realroot 3	< select the instance
killreal		< stop the daemons for the instance
. realroot	< select the base instance
realclone -pu3	< update the instance
. realroot 3	< re-select the instance
realstart		< restart the daemons for the instance

Administering a Reality instance

The realroot host command selects a specified Reality release or instance, by setting the necessary environment variables (REALROOT, PATH, etc.). When using the Reality host utilities, you must first select the required instance.

Using Database Isolation with Resilience

If you are using both Database Isolation and Resilience, the following restrictions apply:

• On Shadow Database, both databases must be associated with the same Reality instance.

• On Failsafe, both databases must either use the base Reality instance or the same instance number.

• On Reality DR, both the master and the slave database must use the same network port number. The easiest way to achieve this is to set the slave to use the same port number as the master - see Configuring Disaster Recovery for details.