1. Flashback query
Introduced with Oracle9i, Flashback Query provides the ability to view the data as it existed in the past. By default, operations on the database use the most recent committed data available. If you want to query the database as it was at some time in the past, you can do so with the Flashback Query feature.
SQL> select dbms_flashback.get_system_change_number from dual;
SQL>select id from hasan.test where id in (100,101);
SQL>delete from hasan.test where id in (100,101);
SQL>commit;
SQL>select id from hasan.test as of timestamp systimestamp - interval '20' minute where id not in (select id from hasan.test);
SQL>insert into hasan.test
select * from hasan.test as of timestamp systimestamp - interval '10' minute
where id not in (select id from hasan.test);
SQL>commit;
2. Flashback Table
When a human or application error occurs, you want to be able to restore the state of one or more tables to a point in time before the problem occurred. Flashback Table provides the DBA the ability to recover a table or a set of tables to a specified point in time quickly, easily, and online. Flashback Table restores the tables while automatically maintaining its associated attributes such as - the current indexes, triggers and constraints
SQL> select dbms_flashback.get_system_change_number from dual;
SQL>select count(*) from hasan.test;
SQL>delete from hasan.test;
SQL>commit;
SQL>alter table hasan.test enable row movement;
SQL>Flashback table hasan.test to SCN ;
SQL>Flashback table hasan.test to timestamp systimestamp - interval '5' minute ;
SQL>select count(*) from hasan.test;
3. Flashback Version Query
Flashback Versions Query provides a way to audit the rows of a table and retrieve information about the transactions that changed the rows. It retrieves all committed versions of the rows that exist or ever existed between the time the query was issued and a point in time in the past. It accomplishes this by utilizing Automatic Undo Management.
SQL> select dbms_flashback.get_system_change_number from dual;
SQL> select password from hasan.test where id in (100,101);
SQL> update hasan.test set password='Bang'where id in (101);
SQL> commit;
SQL> select dbms_flashback.get_system_change_number from dual;
SQL> update hasan.test set password='ladesh'where id in (100);
SQL> commit;
SQL> select dbms_flashback.get_system_change_number from dual;
SQL> delete from hasan.test where id in (100,101);
SQL> select dbms_flashback.get_system_change_number from dual;
SQL> insert into hasan.test
select * from hasan.test as of timestamp systimestamp - interval '20' minute
where id not in (select id from hasan.test);
SQL> commit;
SQL> select dbms_flashback.get_system_change_number from dual;
SQL> SELECT versions_startscn start_scn
, versions_endscn end_scn
, versions_xid transection_id
, DECODE(versions_operation,'I','Insert','U','Update','D','Delete',NULL) oper
, id, password
FROM hasan.test versions between scn 85174629 AND 85186130
WHERE id in (100,101) Order by start_scn;
4. Flashback Transaction Query
You may discover that somehow data in a table has been inappropriately changed. To research this change, you can use multiple flashback queries to view row data at specific points in time. More efficiently, you can use Flashback Versions Query feature to view all changes to a row over a period of time and the associated transaction id's. This feature allows you to append VERSIONS BETWEEN clause to a SELECT statement that specifies an SCN or timestamp range between which you want to view changes to row values. Once you identify an erroneous transaction, you can then use the Flashback Transaction Query feature to identify other changes that were done by the transaction, and to request the undo SQL to reverse those changes.
SQL> sqlplus / as sysdba
SQL> SELECT * FROM flashback_transaction_query x
where x.table_name='LOGIN' AND x.table_owner='HASAN'
AND x.start_timestamp >(systimestamp - interval '10' minute);
5. Flashback Drop
Dropping of objects by accident has always been a problem for users and DBAs alike. Users soon realize their mistake but then it's too late and historically there is no easy way to recover those dropped tables, indexes, constraints, triggers, etc. Flashback Drop provides a safety net when dropping objects in Oracle Database 10g. When a user drops a table, Oracle automatically places it into the Recycle Bin.
SQL> create table table1 (a number(1));
SQL> INSERT INTO table1 values(1);
SQL> INSERT INTO table1 values(2);
SQL> INSERT INTO table1 values(3);
SQL> INSERT INTO table1 values(4);
SQL> commit;
SQL> select dbms_flashback.get_system_change_number from dual;
SQL> DROP TABLE hasan.table1;
SQL> SELECT ur.base_object, ur.object_name,ur.original_name FROM user_recyclebin ur;
SQL> FASHBACK TABLE table1 TO BEFORE DROP;
6.Flashback Database
Flashback Database quickly rewinds an Oracle database to a previous time, to correct any problems caused by logical data corruptions or user errors. Flashback Database is like a 'rewind button' for your database. It provides database point in time recovery without requiring a backup of the database to first be restored. When you eliminate the time it takes to restore a database backup from tape, database point in time recovery is fast
Related Topics:
Showing posts with label Flashback. Show all posts
Showing posts with label Flashback. Show all posts
Saturday, April 18, 2009
Monday, April 28, 2008
Flashback Part #2 Setup and Maintenance
Limitations of Flashback Database
Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation. You must have a flash recovery area enabled, because flashback logs can only be stored in the flash recovery area. For Real Application Clusters databases, the flash recovery area must be stored in a clustered file system or in ASM.
Enabling Logging for Flashback Database
To enable logging for Flashback Database, set the DB_FLASHBACK_RETENTION_TARGET initialization parameter and issue the ALTER DATABASE FLASHBACK ON statement.
1. Start SQL*Plus and ensure that the database is mounted, but not open.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
2. Optionally, set theDB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes:
SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320;
# 4320 = 3 days (By default DB_FLASHBACK_RETENTION_TARGET is set to one day (1440 minutes)).
3. Enable the Flashback Database feature for the whole database:
SQL> ALTER DATABASE FLASHBACK ON;
By default, flashback logs are generated for all permanent tablespaces. If you wish, you can reduce overhead by disabling flashback logging for specific tablespaces:
SQL> ALTER TABLESPACE tbs_3 FLASHBACK OFF;
You can re-enable flashback logging for a tablespace later with this command: SQL> ALTER TABLESPACE tbs_3 FLASHBACK ON;
Note: if you disable Flashback Database for a tablespace, then you must take its datafiles offline before running FLASHBACK DATABASE.
You can disable flashback logging for the entire database with this command: SQL> ALTER DATABASE FLASHBACK OFF;
Creating Normal and Guaranteed Restore Points
To create normal or guaranteed restore points, use the CREATE RESTORE POINT statement in SQL*Plus, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default). The database can be open or mounted when creating restore points. If it is mounted, then it must have been shut down cleanly.
SQL> CREATE RESTORE POINT before_upgrade;
Restore point created.
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
Restore point created.
Listing Restore Points
To see a list of the currently defined restore points, use the V$RESTORE_POINT control file view, by means of the following query:
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT;
You can also use the following query to view only the guaranteed restore points:
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES';
For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points, STORAGE_SIZE indicates the amount of disk space in the flash recovery area used to retain logs required to guarantee FLASHBACK DATABASE to that restore point.
Dropping Restore Points
When you are satisfied that you do not need an existing restore point, or when you want to create a new restore point with the name of an existing restore point, you can drop the restore point, using the DROP RESTORE POINT SQL*Plus statement.
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
The same statement is used to drop both normal and guaranteed restore points. Guaranteed restore points never age out of the control file. They remain until they are explicitly dropped.
Monitoring Space Usage For Guaranteed Restore Points
When guaranteed restore points are defined on your database, you should monitor the amount of space used in your flash recovery area for files required to meet the guarantee. Use the query for viewing guaranteed restore points in "Listing Restore Points" and refer to the STORAGE_SIZE column to determine the space required for files related to each guaranteed restore point. To see the total usage of your flash recovery area, use V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA_USAGE".
Sizing the Flash Recovery Area to Include Flashback Logs
When using Flashback Database, you must add extra space to the flash recovery area to hold the flashback logs, along with the other files stored in the flash recovery area. The setting of the DB_FLASHBACK_RETENTION_TARGET initialization parameter determines, indirectly, how much flashback log data the database retains. The size of flashback logs generated by the database for a given time period can vary considerably, however, depending on the specific database workload. If more blocks are affected by database updates during a given interval, then more disk space is used by the flashback log data generated for that interval.
Estimating Disk Space Requirements for Flashback Database Logs
The V$FLASHBACK_DATABASE_LOG view can help you estimate how much space to add to your flash recovery area for flashback logs. After you have enabled logging for Flashback Database and set a flashback retention target, allow the database to run under a normal workload for a while, to generate a representative sample of flashback logs.
SQL> SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;
The result is an estimate of the disk space needed to meet the current flashback retention target, based on the database workload since Flashback Database was enabled. Add the amount of disk space specified in $FLASHBACK_DATABASE_LOG.ESTIMATED_FLASHBACK_SIZE to your flash recovery area size, to hold the expected database flashback logs.
Managing Space For Flashback Logs in the Flash Recovery Area
You cannot manage the flashback logs in the flash recovery area directly, other than by setting the flashback retention target or using guaranteed restore points. You can, however, manage flash recovery area space as a whole, in order to maximize space available for retention of flashback database logs.
Determining the Current Window for Flashback Database
When flashback logging is enabled, the earliest SCN in the flashback database window can be determined by querying
V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_SCN and V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_TIME.
SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;
Related Topics:
- Flashback Database can only undo changes to a datafile made by an Oracle database. It cannot be used to repair media failures, or to recover from a deletion of datafiles.
- You cannot use Flashback Database to undo a shrink datafile operation.
- If the database control file is restored from backup or re-created, all accumulated flashback log information is discarded. You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file.
- When using Flashback Database with a target time at which a NOLOGGING operation was in progress, block corruption is likely in the database objects and datafiles affected by the NOLOGGING operation. For example, if you perform a direct-path INSERT operation in NOLOGGING mode, and that operation runs from 9:00 to 9:15 on April 3, 2005, and you later need to use Flashback Database to return to the target time 09:07 on that date, the objects and datafiles updated by the direct-path INSERT may be left with block corruption after the Flashback Database operation completes. If possible, avoid using Flashback Database with a target time or SCN that coincides with a NOLOGGING operation. Also, perform a full or incremental backup of the affected datafiles immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use Flashback Database to return to a point in time during an operation such as a direct-path INSERT, consider performing the operation in LOGGING mode.
Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation. You must have a flash recovery area enabled, because flashback logs can only be stored in the flash recovery area. For Real Application Clusters databases, the flash recovery area must be stored in a clustered file system or in ASM.
Enabling Logging for Flashback Database
To enable logging for Flashback Database, set the DB_FLASHBACK_RETENTION_TARGET initialization parameter and issue the ALTER DATABASE FLASHBACK ON statement.
1. Start SQL*Plus and ensure that the database is mounted, but not open.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
2. Optionally, set theDB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes:
SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320;
# 4320 = 3 days (By default DB_FLASHBACK_RETENTION_TARGET is set to one day (1440 minutes)).
3. Enable the Flashback Database feature for the whole database:
SQL> ALTER DATABASE FLASHBACK ON;
By default, flashback logs are generated for all permanent tablespaces. If you wish, you can reduce overhead by disabling flashback logging for specific tablespaces:
SQL> ALTER TABLESPACE tbs_3 FLASHBACK OFF;
You can re-enable flashback logging for a tablespace later with this command: SQL> ALTER TABLESPACE tbs_3 FLASHBACK ON;
Note: if you disable Flashback Database for a tablespace, then you must take its datafiles offline before running FLASHBACK DATABASE.
You can disable flashback logging for the entire database with this command: SQL> ALTER DATABASE FLASHBACK OFF;
Creating Normal and Guaranteed Restore Points
To create normal or guaranteed restore points, use the CREATE RESTORE POINT statement in SQL*Plus, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default). The database can be open or mounted when creating restore points. If it is mounted, then it must have been shut down cleanly.
SQL> CREATE RESTORE POINT before_upgrade;
Restore point created.
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
Restore point created.
Listing Restore Points
To see a list of the currently defined restore points, use the V$RESTORE_POINT control file view, by means of the following query:
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT;
You can also use the following query to view only the guaranteed restore points:
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES';
For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points, STORAGE_SIZE indicates the amount of disk space in the flash recovery area used to retain logs required to guarantee FLASHBACK DATABASE to that restore point.
Dropping Restore Points
When you are satisfied that you do not need an existing restore point, or when you want to create a new restore point with the name of an existing restore point, you can drop the restore point, using the DROP RESTORE POINT SQL*Plus statement.
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
The same statement is used to drop both normal and guaranteed restore points. Guaranteed restore points never age out of the control file. They remain until they are explicitly dropped.
Monitoring Space Usage For Guaranteed Restore Points
When guaranteed restore points are defined on your database, you should monitor the amount of space used in your flash recovery area for files required to meet the guarantee. Use the query for viewing guaranteed restore points in "Listing Restore Points" and refer to the STORAGE_SIZE column to determine the space required for files related to each guaranteed restore point. To see the total usage of your flash recovery area, use V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA_USAGE".
Sizing the Flash Recovery Area to Include Flashback Logs
When using Flashback Database, you must add extra space to the flash recovery area to hold the flashback logs, along with the other files stored in the flash recovery area. The setting of the DB_FLASHBACK_RETENTION_TARGET initialization parameter determines, indirectly, how much flashback log data the database retains. The size of flashback logs generated by the database for a given time period can vary considerably, however, depending on the specific database workload. If more blocks are affected by database updates during a given interval, then more disk space is used by the flashback log data generated for that interval.
Estimating Disk Space Requirements for Flashback Database Logs
The V$FLASHBACK_DATABASE_LOG view can help you estimate how much space to add to your flash recovery area for flashback logs. After you have enabled logging for Flashback Database and set a flashback retention target, allow the database to run under a normal workload for a while, to generate a representative sample of flashback logs.
SQL> SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;
The result is an estimate of the disk space needed to meet the current flashback retention target, based on the database workload since Flashback Database was enabled. Add the amount of disk space specified in $FLASHBACK_DATABASE_LOG.ESTIMATED_FLASHBACK_SIZE to your flash recovery area size, to hold the expected database flashback logs.
Managing Space For Flashback Logs in the Flash Recovery Area
You cannot manage the flashback logs in the flash recovery area directly, other than by setting the flashback retention target or using guaranteed restore points. You can, however, manage flash recovery area space as a whole, in order to maximize space available for retention of flashback database logs.
Determining the Current Window for Flashback Database
When flashback logging is enabled, the earliest SCN in the flashback database window can be determined by querying
V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_SCN and V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_TIME.
SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;
Related Topics:
Flashback Part #1 Basics
Flashback Database
Oracle Flashback Database, accessible from both RMAN and SQL*Plus , lets you quickly recover the entire database from logical data corruptions or user errors. It is similar to conventional point in time recovery in its effects, allowing you to return a database to its state at a time in the recent past. Flashback Database is, however, much faster than point-in-time recovery, because it does not require restoring datafiles from backup and it requires applying fewer changes from the archived redo logs.
Flashback Database uses its own logging mechanism, creating flashback logs which are stored in the flash recovery area. You can only use Flashback Database if flashback logs are available. Therefore, you must set up your database in advance to create flashback logs if you want to take advantage of Flashback Database feature.
To enable Flashback Database, you set up a flash recovery area, and set a flashback retention target , to specify how far back into the past you want to be able to restore your database with Flashback Database.
From that time on, at regular intervals, the database copies images of each altered block in every datafile into the flashback logs. These block images can later be reused to reconstruct the datafile contents as of any moment at which logs were captured. When a database is restored to its state at some past target time using Flashback Database, each block changed since that time is restored from the copy of the block in the flashback logs most immediately prior to the desired target time. The redo log is then used to re-apply changes since the time that block was copied to the flashback logs.
Flashback Database Window
The range of SCNs for which there is currently enough flashback log data to support the FLASHBACK DATABASE command is called the flashback database window. If space in the flash recovery area is low, then flashback logs may be deleted to free space for files required by the configured retention policy. The result is that the flashback database window can be shorter than the flashback retention target, depending upon the size of the flash recovery area, other backups that must be retained and how much flashback logging data is needed.
Normal Restore Points
Creating a normal restore point assigns the restore point name to a specific point in time or SCN, as a kind of alias you can use with commands that recognize a RESTORE POINT clause as a shorthand for specifying an SCN. Before performing any operation that you may have to reverse, you can create a normal restore point. The name of the restore point and the SCN are recorded in the control file. Then, if you later need to use Flashback Database, Flashback Table, or point-in-time recovery, you can refer to the target time using the name of the restore point instead of a time expression or SCN.
Normal restore points are very lightweight. The control file can maintain a record of thousands of normal restore points with no significant impact upon database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.
Guaranteed Restore Points
Like normal restore points, guaranteed restore points can be used as aliases for SCNs in recovery operations. However, they also provide specific functionality related to the use of the Flashback Database feature.
Creating a guaranteed restore point at a particular SCN enforces the requirement that you can perform a Flashback Database operation to return your database to its state at that SCN, even if flashback logging is not enabled for your database. If flashback logging is enabled, creating a guaranteed restore point enforces the retention of flashback logs required for Flashback Database back to any point in time after the creation of the earliest guaranteed restore point.
A guaranteed restore point can be used to revert a whole database to a known good state days or weeks ago, as long as there is enough disk space in flash recovery area to store the needed logs.
Logging for Flashback Database and Guaranteed Restore Points
The logging for Flashback Database and guaranteed restore points is based upon capturing images of datafile blocks before changes are applied, so that these images can be used to return the datafiles to their previous state when a FLASHBACK DATABASE command is executed. The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be
deleted in response to space pressure in the flash recovery area. These differences affect space usage for logs and database performance.
Requirements for Using Guaranteed Restore Points
Related Topics:
Oracle Flashback Database, accessible from both RMAN and SQL*Plus , lets you quickly recover the entire database from logical data corruptions or user errors. It is similar to conventional point in time recovery in its effects, allowing you to return a database to its state at a time in the recent past. Flashback Database is, however, much faster than point-in-time recovery, because it does not require restoring datafiles from backup and it requires applying fewer changes from the archived redo logs.
Flashback Database uses its own logging mechanism, creating flashback logs which are stored in the flash recovery area. You can only use Flashback Database if flashback logs are available. Therefore, you must set up your database in advance to create flashback logs if you want to take advantage of Flashback Database feature.
To enable Flashback Database, you set up a flash recovery area, and set a flashback retention target , to specify how far back into the past you want to be able to restore your database with Flashback Database.
From that time on, at regular intervals, the database copies images of each altered block in every datafile into the flashback logs. These block images can later be reused to reconstruct the datafile contents as of any moment at which logs were captured. When a database is restored to its state at some past target time using Flashback Database, each block changed since that time is restored from the copy of the block in the flashback logs most immediately prior to the desired target time. The redo log is then used to re-apply changes since the time that block was copied to the flashback logs.
Flashback Database Window
The range of SCNs for which there is currently enough flashback log data to support the FLASHBACK DATABASE command is called the flashback database window. If space in the flash recovery area is low, then flashback logs may be deleted to free space for files required by the configured retention policy. The result is that the flashback database window can be shorter than the flashback retention target, depending upon the size of the flash recovery area, other backups that must be retained and how much flashback logging data is needed.
Normal Restore Points
Creating a normal restore point assigns the restore point name to a specific point in time or SCN, as a kind of alias you can use with commands that recognize a RESTORE POINT clause as a shorthand for specifying an SCN. Before performing any operation that you may have to reverse, you can create a normal restore point. The name of the restore point and the SCN are recorded in the control file. Then, if you later need to use Flashback Database, Flashback Table, or point-in-time recovery, you can refer to the target time using the name of the restore point instead of a time expression or SCN.
Normal restore points are very lightweight. The control file can maintain a record of thousands of normal restore points with no significant impact upon database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.
Guaranteed Restore Points
Like normal restore points, guaranteed restore points can be used as aliases for SCNs in recovery operations. However, they also provide specific functionality related to the use of the Flashback Database feature.
Creating a guaranteed restore point at a particular SCN enforces the requirement that you can perform a Flashback Database operation to return your database to its state at that SCN, even if flashback logging is not enabled for your database. If flashback logging is enabled, creating a guaranteed restore point enforces the retention of flashback logs required for Flashback Database back to any point in time after the creation of the earliest guaranteed restore point.
A guaranteed restore point can be used to revert a whole database to a known good state days or weeks ago, as long as there is enough disk space in flash recovery area to store the needed logs.
Logging for Flashback Database and Guaranteed Restore Points
The logging for Flashback Database and guaranteed restore points is based upon capturing images of datafile blocks before changes are applied, so that these images can be used to return the datafiles to their previous state when a FLASHBACK DATABASE command is executed. The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be
deleted in response to space pressure in the flash recovery area. These differences affect space usage for logs and database performance.
Requirements for Using Guaranteed Restore Points
- The COMPATIBLE initialization parameter must be set to 10.2 or greater.
- The database must be running in ARCHIVELOG mode. The FLASHBACK DATABASE operation used to return your database to a guaranteed restore point requires the use of archived redo logs from around the time of the restore point.
- A flash recovery area must be configured. Guaranteed restore points use a mechanism similar to flashback logging, and as with flashback logging, Oracle must store the required logs in the flash recovery area.
- If flashback database is not enabled, then the database must be mounted, not open, when creating the first guaranteed restore point (or if all previously created guaranteed restore points have been dropped).
Related Topics:
Subscribe to:
Posts (Atom)