Full and incomplete Oracle database recovery and user management Backup Recovery

Full and incomplete Oracle database recovery and user management Backup Recovery

Comparison between full recovery and Incomplete recovery:

1. Full recovery: restores the database to the latest status, including all submitted data changes until the request is restored.

2. Incomplete recovery: restores the database to the past time point specified before the request recovery operation.

1. Complete recovery process

The following steps describe the actions to be taken during full recovery:

1. Restore corrupted or lost files through backup.

2. Apply Incremental backup, archive redo log files, and online redo log files as needed. Apply the redo log changes to the data file until the current online log is reached, and re-enter the latest transaction processing. The restored block is generated throughout the process. This is called roll-forward or cache restoration.

3. At this time, the restored data file contains submitted and uncommitted changes.

4. Restore blocks are used to roll back any uncommitted changes. It is also called transaction recovery.

5. At this time, the data file is in the restored State and consistent with other data files in the database.

-------------------------------------- Split line --------------------------------------

Data backup and Database Replication in Oracle user management mode

RMAN: Configure an archive log deletion policy

Basic Oracle tutorial-copying a database through RMAN

Reference for RMAN backup policy formulation

RMAN backup learning notes

Oracle Database Backup encryption RMAN Encryption

-------------------------------------- Split line --------------------------------------

Ii. Incomplete recovery process:

Incomplete recovery or database restoration at a time point use backup to generate a database of a non-current version. That is to say, no redo records generated after the latest backup will be applied. This type of recovery is performed only when absolutely necessary. To perform Incomplete recovery, You need:

Effective offline or online backup of all data files generated before the recovery point

All archived logs from the backup time to the specified recovery time

The incomplete recovery process is listed below:

1. Restore data files from backup: If the recovery point objective is not very new, the backup used may not be the latest. This requires the OS command or the RMAN RESTORE command to copy files.

2. Use the RECOVER command: redo the log file application from the archive, and include as much data as possible to restore the point objective.

3. restored status: At this time, the data file contains some submitted transactions and uncommitted transactions, because redo can contain uncommitted data.

4. Run the alter database open command: the DATABASE is opened before the application restores the block. This is to provide higher availability.

5. Restore data: When an application is redone, it also supports restoring data files. In this way, restoration can be applied to data files to restore any uncommitted transactions. This is the next step.

6. process completed: At this time, the data file has been restored to the selected time point.

If recovery is required and archive logs containing transaction processing are lost, the transaction processing occurs between the backup creation time used for restoration and the target SCN, the time point recovery is the only option. If no log is lost, there is no record for updating the data files during this period. The only option is to restore the database from the backup time point until the time point allowed by the intact archive log series, and then use the RESETLOGS option to open the database. All or subsequent changes in the lost redo log file will be lost.

Backup and recovery types:

Database backup and recovery types include:

User-managed: RMAN is not used.

-- Use OS commands to move files -- DBAs need to manually maintain backup activity records

For Server Management: RMAN

1. Perform User-managed database backup

You can use the OS command to create a copy of the data file to back up the database. The operation process depends on whether the database is in ARCHIVELOG mode. If yes, you can place each tablespace in backup mode before copying the tablespace data file to make the database open and available. Otherwise, you must close the database before copying data files.

1) manually back up the NOARCHIVELOG database:

By disabling the database and copying all data files and control files to the backup directory, you can back up the NOARCHIVELOG database as a whole. Because the file copy operation is completed using the OS command, you must first close the database. This puts the database in a consistent state.

SQL> SHUTDOWN IMMEDIATE

$ Cp $ ORACLE_BASE/ORCL/datafile/*. dbf/u02/backup/datafile

-- Copy the data file to the backup location

$ Cp $ ORACLE_BASE/ORCL/controlfile/*. ctl/u02/backup/controlfile -- copy the control file to the backup location

SQL> STARTUP

2) manually back up the ARCHIVELOG Database

If the database is in ARCHIVELOG mode, you do not have to disable the database before copying files. Eventually, an inconsistent Backup will be obtained, but the application will restore the data to the consistent state after redoing the data.

Start the backup mode:

Before copying a data file, you must place each data file in backup mode. Use the begin backup clause of the alter tablespace and alter database commands to perform this operation. The syntax for each command is as follows:

Alter tablespace <tablespace> begin backup;

-- The alter tablespace command only affects the data files that belong to the TABLESPACE.

Alter database begin backup;

-- Alter database affects all data files in the DATABASE.

End backup mode:

It is important to remove the data file from the backup mode. When the database is shut down, no data files are in backup mode. If you try to shut down the database in this status, you will receive an error. In addition, the backup mode will generate additional redo data, resulting in additional load on the system. If you do not manually back up data files, there is no reason to keep any data files in backup mode.

Specific operations:

Back up data files:

SQL> select file_name, tablespace_name from dba_data_files;

-- View all data file locations and tablespaces

SQL> ALTER TABLESPACE users BEGIN BACKUP;

-- Place the tablespace in backup mode

$ Cp $ ORACLE_HOME/oradata/orcl/users *. dbf/u02/backup/datafile

-- Copy the data file of the tablespace to the backup location

SQL> ALTER TABLESPACE users END BACKUP;

-- Exit the tablespace from the backup mode.

Backup control files can be stored in the following ways:

(1). Create an image copy and write it to the file with the specified name:

SQL> ALTER DATABASE BACKUP CONTROLFILE

'/U01/backup/controlfile. Bak ';

Database altered.

(2) generate a script to recreate the control file and write it to the tracking file:

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Database altered.

-- Re-create the Control File Script in $ ORACLE_BASE/diag/rdbms/prod/PROD/trace

View the generated script file and you will find two ways to create a control file:

Noresetlogs archivelog indicates that the log files are in good condition, and you do not need to resetlog to restart the database;

Resetlogs archivelog; log files are damaged and lost, and cannot be completely restored. The log group number is cleared;

For more details, please continue to read the highlights on the next page:

1 2 3 Next Page