Restoring a tenant database to a point in time

You can restore a tenant database to a point in time with the ON-Bar utility.

Before you begin

You must meet the following prerequisites before you start a tenant restore:

  • The tenant database storage spaces must have a physical backup.
  • The database server must be online.
  • All tenant storage spaces that are listed in the tenant definition must exist.
  • Tenant storage spaces must have unique names for existing backups. For example, if a tenant database that has backups is dropped and storage spaces with the same names are used in a new tenant database, the backups of the dropped tenant database must be removed.
  • No other warm restores or tenant restores are in progress.

A tenant database point-in-time restore has the following additional prerequisites if the tenant database is in a high-availability cluster:

  • The cluster cannot include shared-disk secondary servers or updatable secondary servers. The cluster can include only read-only HDR secondary servers and remote stand-alone secondary servers.
  • All secondary servers must be online.
  • You can run the restore command only on the primary server.

    However, during the tenant point in time restore process, internally generated commands are run on the secondary servers to restore the new state of the tenant database spaces on the secondaries. A tenant point in time restore command includes new physical backups of the tenant spaces in their new state. The tenant point in time restore command that is run on the primary server does not return until all secondary servers acknowledge the completion of the automatically generated restores of the new tenant space backups.

About this task

Like other warm restores, the logical logs that are required for the tenant database restore are restored to the temporary spaces that are specified by the DBSPACETEMP configuration parameter. If the DBSPACETEMP configuration parameter is not set, temporary files are created in the root dbspace.

Procedure

To restore a tenant database to a point in time, run the following command: 
onbar -r -T tenant_database -t "time" -O

Substitute tenant_database with the name of the tenant database. Substitute time with the time of the last transaction to be restored from the logical logs.

If you omit the -O option, all the permanent tenant spaces must be marked as down before you run the restore command. Temporary spaces are never backed up or restored.

Results

If the restore fails, fix the problem and run the restore again. Until the restore succeeds, the tenant database is blocked from accepting connections. During the restore, the value of the tenant_state field is set to restoring in the tenant_resources column of the sysadmin:tenant table. When a tenant database is blocked, the value of the tenant_state field is set to blocked. You can view the value of the tenant_state field by running the following query:

SELECT bson_value_lvarchar(tenant_resources, 'tenant_state') AS tenant_state
   FROM sysadmin:tenant
   WHERE tenant_dbsname = 'tenant_dbname';

Substitute tenant_dbname with the name of the tenant database.

Example

The following command restores a tenant database that is named tenant1 to the specified point in time:

onbar -r -T tenant1 -t "2015-10-10 11:35:57" -O