Restore completion state
|
After a restore completes, you can leave an SQL
database in any of the following states:
-
Operational
-
Read-only
-
Non-operational
To bring the Enterprise Vault SQL database to the
required Point in time (PIT) or end-of-log (EOL), the SQL database
restore consists of a set of restores. An example set of restores
consists of the following:
In other scenarios, the set of restores may require a subset of
restores, such as a FULL or a FULL and cumulative restore. If the
set contains incremental restores, the initial restores should
leave the database in a "Restore pending" state so future restores
append to the database. Thus, you should use the option only in the
last restore job of the restore set. Once the database is brought
online, the user cannot make any further cumulative or differential
(database differential or transaction log) restores on that
database. If you want to perform any further restores, you must
start from a FULL database restore.
Note:
|
Given a PIT or EOL, the NetBackup SQL Agent
has the capacity to find the SQL restore set (FULL, database
differential, and transaction logs). However, the Enterprise Vault
agent does not have this capability; therefore, the user must find
and sequence the SQL restore set manually.
|
|
Consistency check after restore
|
You can check the consistency of the database after restores are
complete.
To check the consistency of the database, select
one of the following consistency checks when you select the
option:
-
Select this option to exclude indexes from the consistency
check. If indexes are not checked, the consistency check runs
significantly faster but is not as thorough. Only the data pages
and clustered index pages for each user table are included in the
consistency check. The consistency of the nonclustered index pages
is not checked.
-
Select this option to include indexes in the consistency check.
Any errors are logged. This option is selected by default.
-
Select this option to perform a low overhead check of the
physical consistency of the SQL Server 2000 database. This option
only checks the following:
-
The integrity of the physical structure of the page and record
headers
-
The consistency between the pages' object ID and index ID
-
The allocation structures
-
Select this option to ensure that no consistency check occurs
after a restore.
Note:
|
Any option other than is effective only in the restore job that
brings the database to an operational state.
|
|
Point-in-time recovery
|
To recover the Enterprise Vault SQL database to a PIT, select a
restore set that includes the immediate DIFFERENTIAL (transaction
log) backup after the PIT. In addition, while restoring this backup
you must select the "PIT" option and specify the PIT.
You must ensure that you use the PIT option only with the last
differential backup restore. You must select the option in the user
interface to enable you to select the PIT option.
|
Redirected restore
|
Select this option and specify the new <SQL INSTANCE\SQL database
name> to restore to an alternate client, alternate SQL
instance, or alternate SQL database. You must do that for each
restore in the restore set. The destination SQL database should not
be present. If it is present, a chance of data loss in the
destination database is possible.
Note:
|
You can change the SQL INSTANCE name, however do not change the
SQL database name. If you change the
SQL database name Enterprise Vault does
not automatically recognize the new name. If you chose to change
the SQL database name then you must also
update your Enterprise Vault configuration.
|
Note:
|
A redirected restore of an auditing database
must be made to the same SQL instance where the directory database
resides.
|
|
Take
database offline |
Select this option to disconnect all the connections to the
destination SQL database (including Enterprise Vault connections)
before it is restored. You should use this option only with the
full restore .
|