Database Backup and Recovery Basics

I. Backup and Recovery overview
1. Backup and Recovery Overview
1.1 What is Backup and Recovery?
In general, backup and recovery refer to individual policies and procedures to protect your database against data loss and to rebuild the database after any kind of data loss.

1.1.1 Physical Backups and Logical Backups
A backup is a copy of a database file that can be used for rebuilding data. Backups can be divided into physical and logical backups.
A physical backup is a backup of the physical files that are used to restore and restore the database, such as data files, control files, and archive log files. Ultimately, each physical backup is a copy of the file that holds the database information to another location, whether disk or some offline storage, such as tape.
Logical backups contain logical data (such as tables or stored procedures) exported using an Oracle Export tool, which is stored in a binary file so that it can then be imported into the database using the appropriate Oracle Import tool.
Physical backups are the foundation of any backup and recovery strategy. Logical backups are a useful complement to physical backups in many cases, but only logical backups are not sufficient protection without physical backups.
Unless specifically specified, is used in the backup and recovery documentation: backup references a physical backup, while backing up some or all of the databases is taking multiple physical backups. Focus on backup and recovery documentation is almost just a physical backup.

1.1.2, recovering from backups: errors and failures
Although there are many types of problems that stop the basic operation of a database or affect database I/O operations, only two cases require DBA intervention and media recovery: Media failure and user error

Other failures may require the DBA to intervene to restart the database (after one instance fails) or allocate more disk space, but these situations generally do not cause data loss or need to be restored from backup

Understanding User Errors-
When an error is applied to a logic error or an automated missing step, the data in the database is incorrectly altered or deleted, causing a user error. Data loss due to user errors include: missing steps, drop important tables, or delete/change
The contents of the table. Although the user has been practicing and careful permission management can block the biggest user error, your backup strategy determines how to recover the lost data calmly.

Understanding Media Failure-
A media failure is a read or write failure that requires a disk file to run the database, due to a physical problem with the disk, such as a disk header crash. Any database file is susceptible to media failure damage.
After a media failure, the appropriate recovery technology depends on the affected file and the type of backup available

1.1.3, Oracle Backup and Recovery Solutions:rman and user-managed Backup

To complete backup and recovery based on physical backup, you have two scenarios available:
(1) Recovery manager
It is a tool that integrates with sessions running on an Oracle server to complete a series of backup and recovery activities or to save a database of backup history data
(2) The traditional user-managed backup and recovery
Traditional user-managed backup and recovery, you use mixed operating system commands and Sql*plus backup and recovery capabilities to directly manage the files that comprise the database

Both of these methods can be supported by Oracle and are 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 technology in the rear of the unit Oracle Database Backup and Recovery Advanced User's Guide will be overwritten.

Whether you use Rman or a user-managed approach, you can supplement your physical backups with a logical backup of the Scenario object. After the restore and restore, the saved data is then imported to rebuild the data. However, the logical
Backup to a large extent beyond the scope of backup and recovery documents

1.2. Backup and Recovery: Basic concepts
The physical structure of the database and its role in the database recovery process determine the composition of backup and recovery through user-managed technology or through Rman.

1.2.1, physical Database structures used in Recovering Data
The files and other structures that make up the database hold the data while guarding the database from possible failures. This discussion describes each of the physical structures that make up the database and the role they play in rebuilding a database from a backup. This section includes
Topic:
(1) Data files and data blocks
(2) Redo log
(3) Rollback segment
(4) Control file

Datafiles and Data blocks-
A database consists of one or more logical storage units called table spaces. Each table space in a database consists of one or more files called data files, which are physical files in the operating system that contain the files stored in the
The data in the table space. The simplest Oracle database will also have a table space saved in the database.
A database uses a logical unit called a data block to manage storage space in a data file. A data block is the smallest storage unit that a database can use and allocate.

is changed or the new data is not immediately written to the data file. The update is buffered into memory and is written to the data file over a period of time. If the database does not pass a normal shutdown (but it opens because an instance fails abnormally exits or
Shutdown abort), then in-memory data is typically not written to the data file. Previously restored data files, or data files that were not closed, are usually not completely up-to-date.

A copy of a database's data file is a critical part of any backup. For more information on data files and blocks, refer to Oracle Database concepts.

Redo logs-
Redo logs record changes to all data files for a database. When data is changed at any time, it is recorded in the online redo log before they are written to the data file.
A minimum of two redo log groups are required for an Oracle database, and at least one online redo log member is in each log group. Periodically, the database rotates the online redo log group.
Because the Redo log contains a record of all changes to the data file, if a copy of the data file from a point in time and a complete redo log set forward from that point in time is available,
Then the database can redo the record changes in the redo log. This is only possible if the redo log has been saved.

Therefore, saving the redo log is an important part of many backup strategies. The first level of saving redo logs is through a archive process. 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 a disk or other tape location for long-term storage and later recovery operations.
Without archived logs, your database backup and recovery options are strictly limited. Your database must be offline before it is backed up, and when you restore the data, you can only revert back to that moment of backup.

Control files-
Controls files contain records of the physical structure of the database and state information for those physical structures. Several types of information saved in the control file are related to backup and restore:
(1) database information (resetlogs SCN and timestamp)
(2) Table space and data file records (file name, data file checkpoint, read/write status, Offline category)
(3) Information for the redo thread (current redo log)
(4) logging (log sequence number, SCN range in each log)
(5) corrupted data block information

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