Backup
Backup and recovery are like safety nets for your database. They're all about making sure your data is safe and can be put back together if something goes wrong.
Backup is like taking a snapshot of your data at a specific time. It's like making a copy of all your important files so that if something happens to the original files, you can use the backup copy to restore them.
Recovery is what you do when you need to use those backup copies. If something goes wrong and you lose your data, recovery helps you put things back together. It involves steps like restoring the backup files, applying any changes that were made after the backup.
It's like making a copy of all your important files so that if something happens to the original files, you can use the backup copy to restore them.
We can divide Backups into physical backups and logical backups.
Physical backups, which are the primary concern in a backup and recovery strategy, are copies of physical database files. You can make physical backups with either the Recovery Manager (RMAN) utility or operating system utilities.
Logical backups, contain logical data (for example, tables and stored procedures) extracted with the Oracle Export utility and stored in a binary file. You can use logical backups to supplement physical backups.
Consistent backup
When database close , during the backup is called Consistent backup. where all the data in the backup reflects the database's state at a single point in time, ensuring that the backup is valid and usable. Cold backup is called Consistent backup.
Inconsistent backup
An inconsistent backup is a type of backup where the data copied is not synchronized or aligned at a specific point in time. In simpler words, it's like taking a snapshot of a moving target without stopping it first. RMAN backup and user managed hot backup are called Inconsistent backup.
A restore is, if you want, the opposite of a backup: the backed up files (that is: the backup) are copied back to their original location. ---is called restore.
Usually, a file is restored after a media failure. However, there are other situations where a file is restored, for example a point in time recovery.
Full Backups
Incremental Backups
Multilevel Incremental Backups
Differential Incremental Backups
Cumulative Incremental Backups
A full backup reads the entire file and copies all blocks into the backup set, only skipping datafile blocks that have never been used.
Incremental Backup create only changed blocks since a previous backup. We can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database.
Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. RMAN reads the entire file every time whether or not the blocks have been used.
The parent backup is the backup that RMAN uses for comparing the SCNs. If the current incremental is a differential backup at level n, then the parent is the most recent incremental of level n or less. If the current incremental is a cumulative backup at level n, then the parent is the most recent incremental of level n-1 or less. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block.
RMAN can create multilevel incremental backups. Each incremental level is denoted by an integer, for example, 0, 1, 2, and so forth. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only difference between a level 0 backup and a full backup is that a full backup is never included in an incremental strategy.
If no level 0 backup exists when you run a level 1 or higher backup, RMAN makes a level 0 backup automatically to serve as the base.
The benefit of performing multilevel incremental backups is that RMAN does not back up all blocks all of the time.
In a differential level n incremental backup, RMAN backs up all blocks that have changed since the most recent backup at level n or lower.
For example, in a differential level 2 backup, RMAN determines which level 2 or level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup. If no level 0 backup is available, RMAN makes a new base level 0 backup for this file.
RMAN provides an option to make cumulative incremental backups at level 1 or greater. In a cumulative level n backup, RMAN backs up all the blocks used since the most recent backup at level n-1 or lower.
For example, in cumulative level 2 backups, RMAN determines which level 1 backup occurred most recently and copies all blocks changed since that backup. If no level 1 backups are available, RMAN copies all blocks changed since the base level 0 backup.
Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.
RMAN will determine the incremental SCN for each datafile find the backup with highest checkpoint scn that belongs to the incarnation of datafile matches the given file# is an incremental backup/copy at level N or less if noncumulative or is an incremental backup/copy at level N-1 or less if cumulative belongs to an available backup set if backup
You can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 backup is taken weekly, and a cumulative level 2 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery. When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate.
By default, RMAN connects to the target database in NOCATALOG mode, meaning that it uses the control file in the target database as the sole repository of RMAN metadata. Perhaps the most important decision you make when using RMAN is whether to create a recovery catalog as the RMAN repository for normal production operations. A recovery catalog is a schema created in a separate database that contains metadata obtained from the target control file.
When you use a recovery catalog, RMAN can perform a wider variety of automated backup and recovery functions than when you use the control file in the target database as the sole repository of metadata.
The following features are available only with a catalog:
• You can store metadata about multiple target databases in a single catalog.
• You can store metadata about multiple incarnations of a single target database in the catalog. Hence, you can restore backups from any incarnation.
• Resynchronizing the recovery catalog at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
• You can report the target database schema at a noncurrent time.
• You can store RMAN scripts in the recovery catalog.
• When restoring and recovering to a time when the database files that exist in the database are different from the files recorded in the mounted control file, the recovery catalog specifies which files that are needed. Without a catalog, you must first restore a control file backup that lists the correct set of database files.
• If the control file is lost and must be restored from backup, and if persistent configurations have been made to automate the tape channel allocation, these configurations are still available when the database is not mounted.
(Operating system command are used to make backups when database is closed or open in this terminology)
Whole database backup refer to a backup of all data file, control file and log file of the database. Whole database backup can be perform when database open or closed.
The backup takes when database is closed called consistent backup. (Because database file header are consistent with the control file and when restore completely the database can be opened without any recovery.)
The backup takes when database is opened and operational called inconsistent backup. (Because database file header are not consistent with the control file.)
Important:
1. If Database is in No Archive log mode, We can not perform user managed hot backup / inconsistent backup
2. If Database is in No Archive log mode and we don’t want to change mode then we can only perform clod backup/consistent backup
3. If Database is in No Archive log mode, we can perform only Restore and not possible to recover database to the point of failure. Means, restore to the point of the last backup
4. If Database is in Archive log mode , then we can recover to the point of failure
