Restore

This section of the CSI SQL Xchange allows you to restore the backup of a CSI SQL database.

The top dropdown-list presents you with an overview of all CSI databases which are stored on the SQL server to which you are currently connected.

After selecting a database you wish to restore, indicate the folder where the backup was saved and indicate the filename if you did not use the default naming when taking the backup.

Options

• Replace existing database: When this option is checked, the current SQL's database will be overwritten with the backup file.

• Restore database users: Under some circumstances the default database user (required for connecting) might not be accepted because of security reasons (in environments with a very rigid password policy). In order to circumvent this issue you have the option to create a new database user (at the Connect-tab).
  
  When restoring the backup and this user does not exist at the SQL server, activate this option and the CSI SQL Xchange will automatically add this user to the database.

• Activate recursive triggers: Use this option only when the database uses direct recursive triggers. This option is required for CSI Codification Builder and CSI Controls Organizer.

• Shrink database: When this option is checked, the CSI SQL Xchange will compact the database before restoring the backup. When successful this will reduce both the actual database and the backup file. 

• Clear log: When this option is checked, the CSI SQL Xchange will clear the database log in the backup before restoring the backup. This implies that this log file will not be restored to the SQL server.

• Adjust recovery model: The CSI SQL Xchange provides you with the option to change the recovery model used by the SQL server. When this option is not checked, the default model will be used.
  There are 3 recovery models which can be used:

 

Simple recovery: Allows the database to be recovered to the point of the last backup. However, you cannot restore the database to the point of failure or to a specific point in time. In order to do that, choose either Full recovery or Bulk-logged recovery.

 

Full recovery: Uses database backups and transaction log backups to provide complete protection against media failure. If one or more data files is damaged, media recovery can restore all committed transactions. In-process transactions are rolled back.

 

Bulk-logged recovery: Provides protection against media failure combined with the best performance and minimal log space usage for certain large-scale or bulk copy operations. The data loss exposure is greater than in Full recovery model. The copy operations cannot be controlled on an operation-by-operation basis which means that a damaged data file may result in loss of work.
In addition, this model only allows the database to be recovered to the end of a transaction log backup which means that point-in-time recovery is not supported.

 

Note: Use this option with caution, make sure that you understand the risks of your selection.

 

When you have indicated the database you wish to restore, indicated the backup file and adjusted the backup options, double check the Logical name and File location displayed in the overview at the bottom. After making sure that you are restoring the correct data, click the Restore button.

Note: It is not possible to restore a database if the SQL Xchange (tool/module) is not running on the same machine as the SQL server.

Renaming a database.

While restoring a database it is possible to rename the database.

Beware that a renamed common, resource or archive database still has the same link id in the original application database(s) it is related to. Changing the name of a database and restoring it next to the original database will not link it to the application database.

The save methods are :

• Remove the old database from the server and then restore the database under a new name.
• Create a new database from CSI Accelerator, automatically the database will have a new, unique id, regardless its name.
• Restore the database under a new name and use the SQL Xchange tool to give it a new key. The database can then be re-linked to the original application database unequivocally.

The unsafe method is:

• Restore a database under a new name and hope for the best.

Reset unique database identifier: the database will get a new identifier, it will not be recognized by any application database, hence force re-linking.