Use the RMAN BACKUP command to create both consistent and inconsistent backups.
The
RMAN BACKUP command supports backing up the following types of files:
- Data files and control files
- Server parameter file
- Archived redo logs
- RMAN backups
Although the
database depends on other types of files, such as network configuration files,
password files, and the contents of the Oracle home, you cannot back up these
files with RMAN. Likewise, some features of Oracle Database, such as external
tables, may depend upon files other than the data files, control files, and
redo log. RMAN cannot back up these files. Use general-purpose backup software
such as Oracle Secure Backup to protect files that RMAN does not support.
When you
execute the BACKUP command in RMAN, the output is always either one
or more backup sets or one or more image copies. A backup set is an
RMAN-specific proprietary format, whereas an image copy is a bit-for-bit copy
of a file. By default, RMAN creates backup sets.
A consistent
backup occurs when the database is in a consistent state. You can use
the BACKUP command to make consistent backups of the database.
A database is in a consistent state after being shut down with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown guarantees that all redo has been applied to the data files. If you mount the database and make a backup at this point, then you can restore the database backup later and open it without performing media recovery.
.But you will, of course, lose all transactions that occurred after the backup was created.
About
Inconsistent RMAN Backups
Any database
backup that is not consistent is an inconsistent backup. A backup made when the
database is open is inconsistent, as is a backup made after an instance failure
or SHUTDOWN ABORT command.
When a
database is restored from an inconsistent backup, Oracle Database must perform
media recovery before the database can be opened, applying changes from the
redo logs that took place after the backup was created.
Note:
RMAN does
not permit you to make inconsistent backups when the database is
in NOARCHIVELOG mode. If you employ user-managed backup techniques
for a NOARCHIVELOG database, then you must not make inconsistent
backups of this database.
If the
database runs in ARCHIVELOG mode, and you back up the archived redo
logs and data files, inconsistent backups can be the foundation for a sound
backup and recovery strategy. Inconsistent backups offer superior availability
because you do not have to shut down the database to make backups that fully
protect the database.
About
Online Backups and Backup Mode
You can
create RMAN backups or user-managed backups.
When
performing a user-managed backup of an online tablespace or database, an
operating system utility can back up a data file at the same time that the
database writer (DBWR) is updating the file. It is possible for the utility to
read a block in a half-updated state, so that the block that is copied to the
backup media is updated in its first half,
while the
second half contains older data. This type of logical corruption is known as a
fractured block, that is, a block that is not consistent with an SCN. If this
backup must be
restored and
the block requires recovery, then recovery fails because the block is not
usable.
For
third-party snapshot technologies, you must use one of the following techniques
to eliminate the risk of creating fractured blocks:
- Ensure that the snapshot
technology complies with Oracle requirements for online backups
- Take the database or data files
offline
- Place the database in backup
mode before using a third-party snapshot backup
The RECOVER…SNAPSHOT
TIME method of recovering a database to a point in time using a particular
snapshot is desupported in Oracle AI Database 26ai.
Instead
of RECOVER…SNAPSHOT TIME, Oracle recommends that you use ALTER
DATABASE BEGIN/END BACKUP before and after creating the storage snapshot
of the data files and then use RECOVER …. UNTIL TIME to a specific
timestamp or system change number (SCN) after the END
BACKUP completion time. Oracle recommends that ALTER DATABASE
BEGIN/END BACKUP always be used when performing snapshots on a running
database to ensure data recovery integrity. Archived log redo logs must be
separately backed up and restored for recovery operations.
Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks. During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block. If the same fracture is found, then the block is considered permanently corrupt. Also, RMAN does not need to freeze the data file header checkpoint because it knows the order in which the blocks are read, which enables it to capture a known good checkpoint for the file.
About Backup Sets
When you execute the BACKUP command in RMAN, you create one or more backup sets or image copies. By default, RMAN creates backup sets regardless of whether the destination is disk or a media manager.
Note:
Data file
backup sets are typically smaller than data file image copies and take less
time to write.
Ø how
RMAN can take a consistent backup of a running (open) database even when
heavy DML is happening??
1. Key idea — “Consistent image through
SCN”
Every Oracle
block (in datafiles, undo, etc.) carries a System Change Number (SCN) —
a monotonically increasing version stamp of the database at that moment.
RMAN uses these SCNs to guarantee that every block in the backup reflects a
consistent point in time (a checkpoint-consistent image).
When you
run:
BACKUP
DATABASE;
on an open database, RMAN is really performing an online (hot) backup, meaning users can continue DMLs (INSERT, UPDATE, DELETE, COMMIT).
When RMAN
reads a block from a datafile:
- If that block has already been
modified after the backup started (its SCN > backup checkpoint
SCN),
- RMAN does not use that
dirty block directly,
- Instead, it asks Oracle’s block recovery mechanism (via the DBWR and redo apply engine) to reconstruct the block image as of the backup SCN using the redo + undo information.
This is done
by Oracle’s “read-consistent block” mechanism.
So, each block RMAN writes to the backup set is the version that was valid at the backup’s checkpoint SCN — even if users were modifying it at that very moment.
3. How redo logs ensure recoverability
During
online backup:
- Oracle continuously writes redo
entries for all DMLs.
- RMAN keeps track of the lowest
SCN of all datafile backups (the checkpoint SCN) and also ensures all
redo up to that SCN is included in the backup.
So, when you
later restore and recover:
1.
RMAN restores the datafiles from the backup sets
(consistent as of checkpoint SCN).
2. Then applies archived + online redo logs to bring the database forward to the desired point in time (for example, until last committed transaction).
4. Backup checkpoint concept
Each
datafile backup has a checkpoint SCN (start/end):
- Checkpoint SCN = point in time
that file content is consistent with.
- RMAN records these in the controlfile
and catalog.
During
restore:
- Oracle uses these SCNs to know which redo must be applied to make all files consistent with each other.
5. Internal protection (CKPT, LGWR, DBWR,
SMON)
Internally:
- CKPT updates headers with checkpoint
SCNs.
- DBWR writes dirty buffers to disk
regularly.
- LGWR ensures redo is flushed before
commit.
- SMON coordinates instance recovery
if needed.
RMAN leverages all of this to maintain backup consistency — it does not “freeze” datafiles, but logically guarantees consistency via SCN management and redo.
6. Summary – The consistency triangle
|
Component |
Role |
Purpose |
|
SCN |
Global
timestamp |
Defines
backup consistency point |
|
Redo |
Transaction
log |
Replays
changes to make blocks consistent |
|
Undo |
Old versions |
Used to
reconstruct consistent read image |
|
RMAN |
Orchestrator |
Reads blocks,
manages checkpoint SCNs, invokes kernel consistency logic |
7. Example of timeline
T1: RMAN
begins backup, notes checkpoint SCN = 1000
T2: User
commits a transaction (SCN 1005)
T3: RMAN
reads block that was updated at SCN 1005
-> Oracle reconstructs block as it was
at SCN 1000
T4: RMAN
writes the consistent block to backup set
So final backup is a point-in-time image as of SCN 1000, even though DML continued during the backup.
8. Notes:
- This mechanism is much safer
than user-managed hot backups (which require BEGIN/END BACKUP mode).
- Works only in ARCHIVELOG
mode.
- RMAN uses block-level media
recovery and backup optimization to minimize overhead.
No comments:
Post a Comment