The SYSCS_UTIL.SYSCS_RESTORE_SCHEMA system procedure restores a schema that was previously backed up with the SYSCS_UTIL.SYSCS_BACKUP_SCHEMA procedure. You can restore the schema to another schema on the same cluster, or on a different cluster. The schema and all of its tables and other objects are created anew in your database.

The schema to which you are restoring must not already exist in the database; if it does, RESTORE_SCHEMA will not proceed.

ENTERPRISE ONLY: This feature is available only for the Splice Machine Enterprise version of our On-Premise Database product; contact Splice Machine Sales for information.


                                 VARCHAR sourceSchema,
                                 VARCHAR directory,
                                 BIGINT  backupId,
                                 BOOLEAN validate );


The name of the schema to which you want the table restored.


The name of the schema that was previously backed up.


Specifies the path to the directory containing the backup from which you want to restore your schema. This can be a local directory if you’re using the standalone version of Splice Machine, or a directory in your cluster’s file system (HDFS or MapR-FS).

Relative paths are resolved based on the current user directory. To avoid confusion, we strongly recommend that you use an absolute path when specifying the backup location.

You must specify the backup’s directory when you call this procedure because, if your database has become corrupted and needs to be restored, the data in the BACKUP.BACKUP table (which includes the location of each backup) may also be corrupted.


The ID of the backup job from which you want to restore the schema.


A Boolean value that specifies whether to validate the schema backup before restoring from it:

  • If validate is false, the restore proceeds without any pre-validation.
  • If validate is true, the backup is validated before the restoration is started. If the validation check finds inconsistencies, the errors are reported to the user, and the schema is not restored. If the inconsistencies are minor, you can choose to re-run this procedure with validate set to false.

Backup and Restore Compatibility

Note that you can only use specific restore procedures with specific types of backups. For example, you can use the RESTORE_TABLE procedure to restore from a backup created by BACKUP_TABLE, but you cannot use RESTORE_TABLE to restore from a backup created by BACKUP_DATABASE. The following table summarizes backup-restore compatibility:

If you backed up with this procedure: You can restore with these procedures:




Backing Up and Restoring Statistics

Note that statistics are also backed up and restored as of version (August 5, 2019) or later of Splice Machine. This means that if you restore a backup created with or later and the statistics were accurate when the backup was done, you do not need to use analyze to generate fresh statistics for the table immediately after restoring it. If the statistics were not accurate, you can run analyze to refresh them.

If you’ve restored from a table or schema backup and aren’t sure if statistics were restored, you can use the following query to determine if statistics are available, replacing <mySchemaName> and <myTableName> with the appropriate names:

WHERE schemaname='<mySchemaName>' and tablename='<myTableName>'


This procedure does not return a result.

Execute Privileges

If authentication and SQL authorization are both enabled, only the database owner has execute privileges on this function by default. The database owner can grant access to other users.

SQL Example: Backup, and Restore a Schema

This example shows you how to back up a schema, then restore it, in these steps:

Backing Up the Schema

This command line performs a full backup of the TPCH1 schema to the /backup directory on HDFS:

splice> CALL SYSCS_UTIL.SYSCS_BACKUP_SCHEMA('TPCH1', '/backup', 'full');
FULL backup to /backup

1 row selected

See the reference page for the SYSCS_UTIL.SYSCS_BACKUP_SCHEMA system procedure for more information about backing up a schema.

Examining the Backup

After the backup completes, you can examine the sys.sysbackup table to find the ID of your new backup:

splice> SELECT * FROM sys.sysbackup;
125953         |2018-10-26 00:12:33.896  |2018-10-26 00:42:53.546  |SUCCESS    |SCHEMA    |false|-1                  |3

You can use the ID of your backup job to examine the sys.sysbackupitems and verify that the base table and two indexes have been backed up:

splice> SELECT * FROM sys.sysbackupitems WHERE backup_Id=125953 ;
125953      |splice:292000    |2018-10-26 00:12:40.512   |2018-10-26 00:32:14.856
125953      |splice:292033    |2018-10-26 00:12:40.513   |2018-10-26 00:42:48.573
125953      |splice:292017    |2018-10-26 00:12:40.512   |2018-10-26 00:41:25.683

3 rows selected

Restoring the Backup

You can restore the schema to another schema on the same cluster, or on a different cluster. You can optionally specify that you want the backup validated before it is restored; the validation process checks for inconsistencies and missing files.

This command first validates the backed-up schema, and then restores it to a different schema named NEWTPCH1:

splice> CALL SYSCS_UTIL.SYSCS_RESTORE_SCHEMA('NEWTPCH1', 'TPCH1', '/backup', 125953, true);
Statement executed.

See Also