A Brief History of Oracle Backup and Recovery

Backup and recovery tasks for an Oracle database have changed over the years, especially with the advent and further improvement of Recovery Manager, or RMAN. Let’s take a look back at how a DBA would backup a database before Oracle 8i without RMAN and how RMAN has improved the process.

Going WAAAAY back in history for Oracle 5 and earlier there was one way to backup a database: shut it down, copy all of the relevant files and start it up again. Such a backup is considered a cold backup since the database is ‘cold’ (not running) when the backup occurs. This does ensure (presuming the DBA copies all of the necessary database files) a consistent backup, one the DBA can restore from (usually without issue) but rolling forward is a chore and can only be done if the online redo logs from before the restore were available.

The next evolution in database backups came with Oracle version 6, where the redo change vector, rollback segments and tablespaces made hot, or online backups, available. With Oracle version 6 the DBA could execute:


and copy the files associated with the specified tablespace and Oracle could restore and recover the tablespace if needed. Of course the archivelogs also needed to be copied, and to ‘hot’ backup an entire database the pair of commands shown above would need to be run for every tablespace in the database. Of course this was a better situation that the previous releases offered since the database could now remain running while the backup was being taken. Still, it was a manual process requiring scripts written by the DBA. And the entire database had to be restored and recovered; there was no point-in-time tablespace recovery available.

Enter Oracle Version 8, the next major release where backup and recovery improvements were offered. Tablespace point-in-time recovery, incremental backups, parallel backup and recovery were all available. This is also the release which introduced Recovery Manager, but as it was in its infancy it offered more problems than solutions so it wasn’t widely adopted. The two greatest improvements offered by Version 8 are tablespace point-in-time recovery and incremental backups, which are inseparable. It’s because of the incremental backup capability that point-in-time recovery was available. It was no longer necessary to perform full backup after full backup; one full backup in a week’s time was enough, with incremental backups (backups that preserved the changes made since the last full backup) supplementing it. Yes, it now took two backups to fully restore and recover a database but the incrementals were much smaller than the full and this allowed Oracle to be restored to any point-in-time covered by any of the incremental backups. Not only could databases be restored and recovered they could also be cloned to a point-in-time (although that process was a bit more complicated than it is today). It’s necessary to remember that RMAN wasn’t very reliable then so DBAs weren’t ready to discard their backup scripts in favor of this new backup and recovery technology.

Oracle Version 9 ushered in a more reliable Recovery Manager and more DBAs were now willing to test RMAN and its features. With a more reliable interface it was easier for the DBA to create full and incremental backups and it was easier to restore and recover a database by using:


from the RMAN> prompt.

Oracle Versions 10 and 11 continued the RMAN improvements and reliability, the former introducing Automatic Storage Management (ASM) and its integration into RMAN to better manage database space and the latter providing the ability to create a clone from the current target database backups or from an active target database. Provided the system had the network bandwidth to support such an operation, making an up-to-the-minute clone was possible. [Of course the clone would never be fully synchronized with the active database since recovery would stop when the clone was in a consistent state with respect to the recent transactions, but cloning an active database would allow for transactions currently running at the start of the clone to be applied to the clone.] All of this was available from the RMAN interface prompt and could be scripted to run from the local O/S scheduler. Oracle Version 12 extends those improvements to allow RMAN to restore and recover a single table from an RMAN backup set, a task once relegated to exp and imp in older releases and to expdp and impdp for releases later than 9iR2.

Geoffrey Chaucer wrote, “Time and tide wait for no man.” This is obviously true with respect to the backup and recovery changes brought forth by Oracle, in an effort to improve backups and allow for successful databases restores and recoveries. Gone are the days of manual scripts, having to shut down the database to create a backup and having to explicitly backup each and every tablespace individually if the database was to remain running while the backup was being taken. RMAN is now a ‘household’ word (if your household is a data center running Oracle databases) and manually scripting any sort of backup is no longer necessary. It’s so easy to take a reliable backup that the DBA may take the technology for granted. But, as presented here, backup and recovery has come a long way since the earliest versions of Oracle and a world full of DBAs is grateful for that, even though they may not have known that until now.

See all articles by David Fitzjarrell

David Fitzjarrell
David Fitzjarrell
David Fitzjarrell has more than 20 years of administration experience with various releases of the Oracle DBMS. He has installed the Oracle software on many platforms, including UNIX, Windows and Linux, and monitored and tuned performance in those environments. He is knowledgeable in the traditional tools for performance tuning – the Oracle Wait Interface, Statspack, event 10046 and 10053 traces, tkprof, explain plan and autotrace – and has used these to great advantage at the U.S. Postal Service, American Airlines/SABRE, ConocoPhilips and SiriusXM Radio, among others, to increase throughput and improve the quality of the production system. He has also set up scripts to regularly monitor available space and set thresholds to notify DBAs of impending space shortages before they affect the production environment. These scripts generate data which can also used to trend database growth over time, aiding in capacity planning. He has used RMAN, Streams, RAC and Data Guard in Oracle installations to ensure full recoverability and failover capabilities as well as high availability, and has configured a 'cascading' set of DR databases using the primary DR databases as the source, managing the archivelog transfers manually and montoring, through scripts, the health of these secondary DR databases. He has also used ASM, ASMM and ASSM to improve performance and manage storage and shared memory.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles