A Brief history of Oracle backup and recovery

A Brief history of Oracle backup and recovery

--http://www.searchdatabase.com.cn/showcontent_90388.htm?info=sinaweibo

Over the years, there have been significant changes in the way Oracle database backup and recovery has taken place, especially after the recovery Manager (RMAN) features have been improved. So next, let's review how the DBA backs up data without Rman, and after Rman, and how Rman can improve the process.

Back to Oracle 5 a long time ago, when the backup was done: Close the database, copy all the related files, and start the database again. This backup method is a cold backup because the database does not run when the backup occurs. This is a backup that ensures consistency, a DBA can use this backup for rollback, usually with no problems, but recovery is a chore and can only be done when the online recovery log is available.

The release of Oracle 6 raises the next evolution of database backups. Its recovery operation changes the vector, rolls back the segment and the table space. This backup is a hot backup and online backup becomes available as well. With Oracle 6, DBAs can perform:

ALTER tablespace <tablespace name> BEGIN BACKUP;

ALTER tablespace <tablespace name> END BACKUP;

Oracle can rebuild and restore table spaces by copying files related to the specified tablespace. Of course Archivelog also need to replicate, in order to "hot" back up the entire database, the two commands shown above need to run in each table space in the database. Of course this is an advantage of the database compared to previous versions, and now the database can continue to run while the backup is in progress. However, this is a manual process that requires the DBA to write a script. The entire database must be rebuilt and restored, and the point-in-time recovery of the tablespace is not available.

With Oracle 8, backup and recovery has been further improved. Table space Point-in-time recovery, incremental backups, parallel backups, and restores are all available. This is the first time a version of the Recovery manager concept has been introduced, but because it is in its early stages, it poses even more problems than it solves, so it has not been widely adopted.

The two major improvements that Oracle 8 provides are table space point-in-time recovery and incremental backups, which are closely related to the two features. It is because of the existence of incremental backup that point-in-time recovery can be used. There is no need to perform a full backup again and again later. It is enough to perform a full backup within one weeks, and the ability to complete a previous full backup with an incremental backup (saving changes since the last full backup) is sufficient. Indeed, there are two types of backups that need to be used to fully recover and rebuild a database, but an incremental backup file is much smaller than a full backup, which allows the Oracle database to be restored to any point in time that an incremental backup was performed. Not only can the database be restored and rebuilt, but the content of the database at a certain point in time (although this process is more complex than it is now) can be cloned. Keep in mind that Rman is not very reliable, so DBAs are not prepared to abandon their backup scripts to support this new backup and recovery technology.

Oracle 9 has ushered in a more reliable recovery Manager, and more DBAs are willing to use Rman to test their capabilities. The interface it provides to DBAs for creating full and incremental backups is more reliable, and it is easier to use it to recover and rebuild a database, using the following commands:

RESTORE DATABASE;

RECOVER DATABASE;

From the rman>prompt.

Oracle 10 and 11 continue to improve rman and improve its reliability by using automated storage Management (ASM) to integrate it into Rman to better manage database space, which provides the ability to create clones from the current target database backup or a running target database. The system network bandwidth supports such operations, and it is entirely possible to make the latest clones. (Of course, clones will never fully synchronize a functioning database, and the clone needs to remain consistent relative to the nearest transaction, at which point the recovery will stop, but the database in the cloned run will allow the recent transaction to continue running at the beginning of the clone.) All of this can be done using the interface provided by Rman, which can execute scripts from the local O/S scheduler. Oracle12 extends these improvements so that Rman can recover and reconstruct individual tables from an Rman backup set, a task that was previously classified in the EXP and imp categories in the old version, which is subsumed in the EXPDP and IMPDP categories after the 9i R2 version.

"Time waits for no man." "This sentence is used in Oracle to improve the database backup, recovery and reconstruction capabilities, and to the database backup and restore the changes brought by the appropriate." Past those who executed manual scripts to shut down the database to create a backup, the days of the database running must be explicitly backed up for each individual tablespace. Rman is now a "everyday" word (if your daily work is running the data center on the Oracle database), and any other type of backup such as manual scripting is no longer necessary. It is easy for Rman to make reliable backups, and DBAs have taken that technology for granted. However, as described here, starting with the earliest versions of Oracle, backup and recovery have gone a long way, and the DBA world should be delighted with such changes, although they may not yet realize it.

A Brief history of Oracle backup and recovery