Following are the physical data structures relevant for oracle backup and recovery.
- Every Oracle database has one or more physical data-files that belong to logical structures called tables-paces.
- The data-file is divided into smaller units called data blocks.
- The data of logical database structures, such as tables and indexes, is physically located in the blocks of the data-files.
- Data-files may automatically extend when the database runs out of space.
- The first block of every data-file is the header. The header includes important information such as file size, block size, table-space, and creation timestamp.
- Whenever the database is opened, Oracle checks to see that the data-file header information matches the information stored in the control file. If it does not, then recovery is necessary.
- Oracle reads the data in a data-file during normal operation and stores it in the buffer cache. For example, a user wants to access some data in a table. If the requested information is not already in the buffer cache, Oracle reads it from the appropriate data-files and stores it in memory.
- Updates are buffered in memory and written to data-files at intervals
Contains the record of physical structure of the DB and their status such as:
- Database name
- Timestamp of database creation
- Names of the database's data-files and online and archived redo log files
- Checkpoint, a record indicating the point in the redo log where all database changes prior to this point have been saved in the data-files
- Recovery Manager (RMAN) backup meta-data
- Information about corrupt data blocks.
- Control files can be multiplex.
- If the operating system supports disk mirroring, the control file can also be mirrored,
- Every time when DB is mounted, its control file is used to identify the data-files and online redo log files that must be opened for database operation.
- If the physical makeup of the database changes, such as a new data-file or redo log file is created, Oracle then modifies the database's control file to reflect the change.
- The control file should be backed up whenever the structure of the database changes. include adding, dropping, or altering data-files or tables-paces and adding or dropping online redo logs.
- Every Oracle database contains a set of two or more online redo log files. Oracle assigns every redo log file a log sequence number to uniquely identify it. The set of redo log files for a database is collectively known as the database's redo log.
- Oracle uses the redo log to record all changes made to the database. Oracle records every change in a redo record, an entry in the redo buffer describing what has changed. For example, assume a user updates a column value in a payroll table from 5 to 7. Oracle records the old value in undo and the new value in a redo record. Since the redo log stores every change to the database, the redo record for this transaction actually contains three parts:
- The change to the transaction table of the undo
- The change to the undo data block
- The change to the payroll table data block
If the user then commits the update to the payroll table - to make permanent the changes executed by SQL statements - Oracle generates another redo record. In this way, the system maintains a careful watch over everything that occurs in the database.
Log Writer (LGWR) writes redo log entries to disk. Redo log data is generated in the redo log buffer of the system global area. As transactions commit and the log buffer fills, LGWR writes redo log entries into an online redo log file. LGWR writes to online redo log files in a circular fashion: when it fills the current online redo log file, called the active file, LGWR writes to the next available inactive redo log file. LGWR cycles through the online redo log files in the database, writing over old redo data. Filled redo log files are available for reuse depending on whether archiving is enabled:
- If archiving is disabled, a filled online redo log is available once the changes recorded in the log have been saved to the data-files.
- If archiving is enabled, a filled online redo log is available once the changes have been saved to the data-files and the file has been archived.
Archived log files are redo logs that Oracle has filled with redo entries, rendered inactive, and copied to one or more log archive destinations. Oracle can be run in either of two modes:
- ARCHIVELOG - Oracle archives the filled online redo log files before reusing them in the cycle.
- NOARCHIVELOG - Oracle does not archive the filled online redo log files before reusing them in the cycle.
Running the database in ARCHIVELOG mode has the following benefits:
- The database can be completely recovered from both instance and media failure.
- The user can perform online backups, i.e., back up tablespaces while the database is open and available for use.
- Archived redo logs can be transmitted and applied to the standby database
- Oracle supports multiplexed archive logs to avoid any possible single point of failure on the archive logs.
- The user has more recovery options, such as the ability to perform tablespace-point-in-time recovery (TSPITR)
Running the database in NOARCHIVELOG mode has the following consequences:
- The user can only back up the database while it is completely closed after a clean shutdown.
- Typically, the only media recovery option is to restore the whole database, which causes the loss of all transactions issued since the last backup.
Every Oracle database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. Oracle refers to these records collectively as undo. Historically, Oracle has used rollback segments to store undo. Space management for these rollback segments has proven to be quite complex. Oracle now offers another method of storing undo that eliminates the complexities of managing rollback segment space, and allows DBAs to exert control over how long undo is retained before being overwritten. This method uses an undo tablespace. Undo records are used to:
- Roll back transactions when a ROLLBACK statement is issued
- Recover the database
- Provide read consistency
When a rollback statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.