RelationalDBDesign RelationalDBDesign

Incomplete Recovery   «Prev 

Incomplete database recovery steps in Oracle

  1. Shut down the database and perform a whole closed database backup.
  2. Restore all datafiles.
  3. Open the database in mount mode.
  4. Recover the datafiles to the specified time, redo log file, or change number.
  5. Open the database with the RESETLOGS option.
  6. Perform a whole database backup.

It is again important to perform a whole database backup after a successful incomplete recovery. Only this backup is valid if a recovery is required at a later time.

Oracle RMAN Backup and Recovery

PITR Scenarios

There are occasions where you want to roll the entire database back to a point in time before a logical corruption occurred. If the flashback retention is not sufficient to rewind back as far as you would like, then you have to resort to restoring the entire database and applying incremental backups and archived redo logs to a point in time right before the logical corruption occurred (for example, dropping several large tables or updating hundreds of tables with the wrong date). Therefore, point-in-time recovery (PITR) is a good solution for a PDB tablespace or the entire PDB. As you might expect, all other PDBs and the CDB are unaffected when performing PITR for a PDB. As with a non-CDB PITR, when you perform an incomplete recovery, you have to open the PDB with RESETLOGS. For a tablespace within the PDB, the PDB remains open for the duration of the tablespace PITR.

PDB Tablespace Logging

The logging_clause of the CREATE PLUGGABLE DATABASE statement specifies the logging attribute of the PDB. The logging attribute controls whether certain DML operations are logged in the redo log file (LOGGING) or not (NOLOGGING).
Note: This feature is available starting with Oracle Database 12c Release 1 (
You can use this clause to specify one of the following attributes:
  1. LOGGING, the default, indicates that any future tablespaces created within the PDB will be created with the LOGGING attribute by default.
  2. NOLOGGING indicates that any future tablespaces created within the PDB will be created with the NOLOGGING attribute by default.
You can override the default logging attribute by specifying either LOGGING or NOLOGGING at the schema object level.
For example, in a CREATE TABLE statement. The specified attribute is used to establish the logging attribute of tablespaces created within the PDB if the logging_clause is not specified in the CREATE TABLESPACE statement.