Database Backup and Recovery Basics

I. Backup and Recovery Overview
1. Backup and Recovery Overview
1.1 What is Backup and Recovery?
Generally, backup and recovery references various policies and procedures to protect your database from data loss, and recreate the database after any data loss.

1.1.1 Physical Backups and Logical Backups
A backup is a copy of a database file, which can be used for data reconstruction. Backup can be divided into physical backup and logical backup.
Physical backup is a backup of physical files used to restore and restore databases, such as data files, control files, and archive log files. In the end, each physical backup is a copy of the file that saves the database information to other locations (whether it is a disk or some offline storage such as tape.
Logical backup contains the logical data exported using an oracle export tool (such as tables or stored procedures). They are saved in a binary file so that the corresponding oracle import tool can be used to import the data to the database.
Physical backup is the basis of any backup and recovery policies. Logical backup is a useful supplement to physical backup in many cases, but logical backup is not adequate if there is no physical backup.
Unless otherwise specified, it is used in the backup and recovery documents: Backup references physical backup, and multiple physical backups are used to back up part or all of the databases at the same time. The focus in backup and recovery documentation is almost just physical backup.

1.1.2 recovery from backup: errors and failures
Although there are many types of problems, there are only two situations that require dba intervention and media recovery: media failure and user error.

Other failures may require dba intervention to restart the database (after an instance fails) or allocate more disk space. However, such failures do not cause data loss or Backup recovery.

Understand user errors-
When the application logic is incorrect or the automation lacks a step error, the data in the database is mistakenly changed or deleted, causing a user error. Data loss due to user errors include: Missing steps, dropping important tables, or deleting/changing
Table content. Although you have been practicing and careful permission management to prevent the largest user errors, your backup policy determines how to easily recover lost data.

Failed to Understand media-
A media failure occurs when a read or write operation on the disk file of the database is required. The failure is caused by the physical problems of the disk, such as the crash of the disk header. Any database file is vulnerable to media failure.
After a media failure, the appropriate recovery technology depends on the affected files and available backup types.

1.1.3. Oracle Backup and Recovery Solutions: RMAN and User-Managed Backup

To complete physical backup-based backup and recovery, you have two available solutions:
(1) rediscovery manager
It is a tool that integrates with sessions running on the oracle server to complete a series of backup and recovery activities. It can also save a database for historical backup data.
(2) the traditional user-managed backup and recovery
For traditional user-managed backup and recovery, you can directly manage the files that constitute the database using the hybrid operating system commands and SQL * plus backup and recovery capabilities.

Both methods can be supported by oracle and fully documented. Rman is a more popular solution for database backup and recovery. Many backup and recovery documents focus on rman-based backup and recovery.
User-managed Backup and Recovery technologies will be covered by the Oracle Database Backup and Recovery Advanced User's Guide in the subsequent unit.

Whether you use rman or user management, you can use the logical backup of the solution object to supplement your physical backup. After restoration and recovery, the stored data is then imported to recreate the data. However, logic
The backup is largely out of the scope of the backup and recovery documentation.

1.2. backup and recovery: Basic Concepts
Using user-managed technology or rman, the physical structure of the database and the role in the database recovery process determine the composition of backup and recovery.

1.2.1 Physical Database Structures Used in Recovering Data
The files and other structures that make up the database Save the data while guarding the database from possible failures. This article describes each physical structure of the database and the role they play in the reconstruction of a backup database. This part includes
Theme:
(1) data files and data blocks
(2) redo log
(3) rollback segments
(4) Control File

Datafiles and Data Blocks-
A database consists of one or more logical storage units called tablespaces. Each tablespace in a database is composed of one or more files called data files, which are physical files stored in the operating system.
The data in the tablespace. The simplest oracle database also has a tablespace stored in the database.
Databases Use logical units called data blocks to manage the storage space in data files. Data blocks are the minimum storage units that can be used and allocated by databases.

Changed or new data is not immediately written into the data file. Updates are buffered into the memory and written into the data file for a period of time. If the database does not go through a normal shutdown (but it is opened, it exits due to an instance failure exception or
Shutdown abort), data in the memory is usually not written to the data file. Previously restored data files, or data files that have not been closed, cannot be fully up-to-date.

Copying data files in a database is the critical part of any backup. For more information about data files and data blocks, see Oracle Database Concepts.

Redo Logs-
Redo logs record changes to all data files in a database. When data is changed at any time point, it is recorded in online redo logs before they are written to data files.
An oracle database must have at least two redo log groups. At the same time, each log group must have at least one online redo log member. From time to time, the database cyclically rotates online redo log groups.
Because the redo log contains records of all changes to the data file, if you copy data files from a certain point in time and a complete redo log set from that point in time is available,
Then the database can redo the changes recorded in the redo log. If the redo log has been saved, this is possible.

Therefore, saving redo logs is an important part of many backup policies. The first level for saving redo logs is through an archive process. The database can copy redo log groups that are no longer in use.
To one or more locations. After a redo log file is archived, it can be backed up to another location on the disk or tape for long-term storage and subsequent recovery operations.
Without archiving logs, your database backup and recovery options will be strictly restricted. Your database must be offline before backup, and when you restore data, you can only restore to the backup time.

Control Files-
The control file contains records of the physical structure of the database and the status information of these physical structures. Several types of information stored in the control file are related to backup and recovery:
(1) database information (resetlogs scn and timestamp)
(2) records of tablespaces and data files (file names, data file checkpoints, read/write statuses, and offline categories)
(3) Information of the redo thread (current redo log)
(4) log record (log serial number, scn range in each log)
(5) Information of damaged data blocks

The recovery process for data files is guided by the state information in the control file, such as the database checkpoint, the current redo log file, and the data file header checkpoint. The loss of control files makes data loss recovery more difficult.
Oracle Database Concepts provides more information about control files.

Undo Segments-
Generally, when the data in the data file is updated, the pre-image of the data is written to the rollback segment. If a transaction is rolled back, the rollback information is used to restore the original data file content.
In the context of restoration, once the required redo log is applied to the data file, the oracle database uses the undo information to roll back uncommitted transactions. The database has been opened before the rollback segment is applied. You should not care about undo segments or manage them as part of the backup and recovery processes.

1.3. The Database Recovery Process: Basic Concepts
Rebuilding a database from a backup involves two aspects: Retrieving copies of data files from the backup and modifying backup applications from archiving and redoing logs, so as to bring the database back to the desired scn (regular, current ).
To restore a data file or control file from the backup, retrieve files on disks, tapes, or other media and make them available on the oracle server. To restore the entire database, you must restore each data file.

Scn100: Full backup of a database (data file copy and control file)
Scn100-scn500: redo Log Capture Database Operations, archiving when logs are busy
Scn500: Data File loss caused by media failure
How to restore? Restore the full backup data file to scn100, the application is arrested, and the logs are archived and redone. Finally, the uncommitted transactions are rolled back.

1.4 Forms of Data Recovery
The previous overview outlines the basis for restoring and restoring processes. Several variants in this overview are particularly important for backup and recovery:
This section contains the following topics:
(1) Restoration of data file media: restoration of data files and application logs
(2) complete, incomplete, and time point recovery
(3) Automatic Recovery upon instance failure: crash recovery

1.4.1. Datafile Media Recovery: Restore Datafiles, Apply Redo
Data File media recovery (often referred to as media recovery) is the most basic component of user-initiated data recovery. It is used to recover from a lost or damaged current data file, spfile, or control file.
It can also be used to recover an offline tablespace that does not use the offline normal option from being recorded to the redo log but not the changes to the data file. Whether you use rman or user-managed backup and recovery
Data File media recovery can be completed (for user-managed backup and recovery, media recovery is the main choice)

Restoring data files from backup is not automatically discovered. The first step to restore the media is to manually restore the data file by copying the backup. Once the data file is restored, the database automatically finds that the data file has expired and has undergone media restoration. In the following cases, you must restore the media:
(1) restore a copy of a data file
(2) even if all data files are current, you still need to back up the control files
(3) A data file is offline without the offline normal option
To restore the media to a data file available, do at least one thing:
(1) database data files must not be opened
(2) If the database is open, the data files to be recovered must be offline.

Files that need to be restored can be operated online until the media recovery is complete. You can manage unexpected media recovery continuity as part of your backup and recovery policies. The continuity of media recovery is affected by frequent backup and parallel recovery parameters.

1.4.2, Complete, Incomplete and Point-In-Time Recovery
A time point-based recovery solution for data loss caused by user errors or logical damages
If you need to complete the recovery and find the archive logs between the target scn after the backup is lost, the Restoration Based on the time point is also your only choice.

Scn appears on the FIRST_CHANGE # column of the v $ log table and the CHECKPOINT_CHANGE # column of the V $ DATAFILE table, and the CHECKPOINT_CHANGE # column of the V $ DATABASE table respectively. If the three values are the same,
The database is not synchronized. Otherwise, you must restore the media.
When the data is completely restored to the nearest point in time, there is no loss of committed transactions. Generally, "recovery" is related to full recovery. Occasionally, you need to return the database to the status of a previous time point, such as rolling back a user error, such as drop or delete the content of a table, you want to return the database to the content before the deletion occurs. Incomplete recovery is also called Restoration Based on Time points. The goal is to restore the database to the previous target scn or the current time. Time Point-based recovery is a response to data loss caused by user errors or logical damages.

If you need to complete the recovery and find the archive logs between the target scn after the backup is lost, the Restoration Based on the time point is also your only choice. There are no lost logs. You have not recorded the update data file to the target scn. Your only choice is to recover from the backup time point, as far as there is no corrupted archive log, next, complete an open resetlogs and discard all the changes after the log is lost (if you find the lost archive log and your database is still open, you should make a full backup immediately ).

If only one tablespace is affected due to data loss, you can choose to restore the tablespace based on the time point instead of the whole database. Table space Recovery based on time points is a more Advanced technology, which is documented in the Oracle Database Backup and Recovery Advanced User's Guide

1.4.3. Automatic Recovery After Instance Failure: Crash Recovery-Crash Recovery
Crash recovery process is a special component of recovery. It occurs immediately after the shutdown abort instance is started. The goal of crash recovery is to bring the data file back to the transaction consistency state and save all committed transactions to the moment when the instance fails. The restoration of data file media is the same as that of restoring database integrity. However, there are many important differences between them:

(1) Media recovery must be explicitly initiated by the user. The database does not run the media to restore itself.
(2) Media recovery is a change to the application of data files restored from backup, rather than online data files.
(3) archive logs and online logs are required for media recovery.

Unlike manual recovery, crash recovery only uses online redo logs and currently online data files. Archive logs are never used during crash recovery and data files are never restored. Any pending updates to the data file in the online redo log of the database application. The result is: no matter when the database is restarted after the crash, the data file reflects the moment when the instance crashes (after the database is opened, any changes to uncommitted transactions are rolled back ).

Crash recovery is a process that includes multiple instances to be recovered, starting with the redo logs generated by the redo process from the last check point, and configurable factors: for example, the number and size of redo log files, checkpoint frequency, and parallel recovery settings. You can configure parameters on the database server to adjust the duration of crash recovery. You can also adjust the checkpoint to optimize the recovery time.

Crash recovery in rac occurs when all instances in the cluster fail. For more information about rac crashes and instance recovery, see Oracle Real Application Clusters Quick Start.

1.5. Backup and Recovery with RMAN
Several data backup and recovery technologies and features that can be accessed using rman but cannot be used for user-managed backup and recovery. The most important thing is:
(1) Incremental Backup
It provides compact backup (saving only changed blocks) and faster data file media recovery (reducing application redo needs)
(2) Block Media recovery
No offline or data files need to be restored. Only a small number of corrupted databases are repaired.
(3) block not used for backup
In some cases, rman can skip unused data blocks during Backup.
(4) binary Compression
Reduce the backup size by using the compressor mechanism integrated into the oracle database
(5) encrypted backup
Use the encryption feature integrated into the oracle database to Save backups in encrypted format

Rman reduces the workload associated with the backup policy by administrators. Rman stores a wide range of records about backup, archiving logs, and its own activities, known as the rman database. In restoration operations, rman can use this information to eliminate restoration in most scenarios.
Identifies the backup file for you. You can also use the information in the database to generate backup activity reports.
Rman information is stored in the control file of the production database. You can create an independent recovery catalog, which is a mode object that saves the rman image information for one or more databases in the separaterecovery catalog database.
The rest of this document is Oracle Database Backup and Recovery Basics, which focuses on using rman to implement your Backup and Recovery policies.

1.5.1, Files That RMAN Can Back Up
Rman can back up all database files used for efficient recovery. Rman supports backing up the following file types:
(1) Copying data files and images of data files
(2) control file, control file image copying
(3) archiving log files
(4) current server parameter file
(5) backup slices, including other backups produced by rman

1.5.2. RMAN Backup Destinations: Disk and Media Managers
Rman can create and manage backups on disks and tapes, back up backups originally created on disks and tapes, and restore database files from backups. Devices used for tape backup often reference SBT devices. Rman interacts with SBT devices through media management layer

1.5.2.1. Types of Oracle Database Backup under RMAN
In physical backup, there are several differences:
(1) About Consistent and Inconsistent Backups
Physical backup can also be divided into one to one and an inconsistent backup. Consistent backup is generated when the database is in the consistent State. In this state, all changes in the redo log are applied to the data file. Databases restored from consistent backups can be left open without media restoration. However, consistent backup can only be generated after Database Consistency is disabled, not after a crash or shutdown abort

For availability reasons, the oracle database is designed to operate non-consistent backup, but is in the open state, backup. However, restoring from a non-consistent backup requires media recovery, so the database can change from online and archive log applications before the database is opened. Archive logs are required for media recovery. Inconsistent backup requires your database to run in archive mode.

1.5.2.2, About Full and Incremental Backups
Full backup is a backup that contains all data files. Rman or use the file copy command at the operating system level to create full backup. Incremental backup is based on only copying the changed data blocks in the data file. During restoration, extracting all changed blocks from the Incremental Backup can replace the redo log application, thus shortening the recovery time. Incremental Backup can only be generated using rman.

1.5.2.3, About Image Copies, Backup Sets and Backup Pieces
The database backup created through rman can be an image copy or backup set. An image copy is the same copy of database files. Rman can create an image to copy the backup. However, in the process, rman checks the damaged content, but the local operating system
The file copy tool cannot be used. You can also create an image by using an operating system command such as cp.
Note: if you do not use rman to Create Image copies, you must use the catalog command to record the image information to the rman database before using them.
Rman can also be called a backup set to save the backup in the format specified by rman. A backup set is a collection of backup parts. Each backup part contains a backup of one or more database files. One or more backup sets can be created for backup tasks completed in rman. The backup set information is recorded in the rman database. Backup sets can only be created and accessed through rman.

1.6. Automatic Disk-Based Backup and Recovery: The Flash Recovery Area
Components that create different backup and recovery files do not know the size of each file system. Using Automatic Disk-Based Backup and Recovery, you can create a flash Recovery area to automate the management of Backup files. Select a location on the disk to provide a larger boundary for the bucket, and set a backup policy, in this case, the database is used for backup storage, archiving logs, and other recovery-related files. Oracle recommends that you enable a flash recovery area to simplify Backup management.

1.7. Oracle Flashback Technology: Alternatives to Point-in-Time Recovery
The oracle flash back technology provides a series of features that provide practical things to choose from, for example, you can view the Historical Status of the data and roll back the data (you do not need to restore most databases from the backup or complete restoration based on time points ). The flash back feature of oracle is more efficient than media restoration in many cases, with lower damage.

Many of oracle's flash back features operate at a logical level to view and manipulate database objects, as shown below: