Database Reference
In-Depth Information
Chapter 11
Backup and Recovery
No database solution—hosted or in-house—would be complete without proper backup and recovery procedures.
In fact the importance of getting a system back at any time within the limits of the service level agreements is of
paramount importance. Backup and recovery complement the disaster recovery solution, which you read about in
Chapters 9 and 10. In many ways you cannot have just the one solution—backups or a DR site—since large databases
might take too long to be restored and rolled forward. It is important to keep in mind that the shared hosting platform
is indeed shared, including the backup infrastructure. So if there is a separate tape library available to the shared
platform, then you can almost certainly assume that there are going to be delays accessing it. Depending on your
service level agreement it can be safer to invoke the standby database, and then rebuild the failed primary. For all
other cases the restore and recovery are of course sufficient.
Despite existing standby databases which can be activated in literally no time, backups are essential. Assume for
a moment that the regulator wants a copy of a specific database at a point in time, maybe weeks or months back. How
would you be able to supply the regulator with the data in a straightforward way?
The chapter you are going to read will focus on the most important aspects of the backup infrastructure for a
consolidated database environment. It will specifically focus on Pluggable Databases as explained in Chapter 7 as the
focus of your attention. And again the solution to be put into place has to be simple and mostly automatic. Depending
on your first line support the restore and recovery commands might need to be hidden in a shell script or similar
abstraction layer. The importance of having skilled developers for these scripts cannot be overrated, since the tool will
be rolled out globally. Any bugs in the abstraction layer can potentially mean data loss. The chapter is aimed at these
developers, mainly to be found in engineering, explaining the tools and methods for creating a suitable abstraction
layer for the operations team to use. The resulting script is left as an exercise to the reader.
The primary tool for taking Oracle backups is Recovery Manager, RMAN. While its appeal was little in the
initial 8.x release, RMAN has become very mature and can care for literally any situation. RMAN hides a lot of the
work to be done under the covers from the user. So-called user-managed backups or manual backups on the other
hand are more difficult to take and require more knowledge of Oracle. The use of user-managed backups is strongly
discouraged both for complexity and number of steps required. The more steps to be executed, the higher the
probability of making mistakes.
An introduction to Backups
Backups are fundamental building blocks and the bread and butter for every database administrator. Without a
working backup, or a database recovery based on it even the most prolific tuning expert would struggle to justify
why he or she was there in the first place: if there is no database there is no need for tuning. Speaking more seriously
there is a real need to be able to get your database back, and Oracle's own Recovery Manager is the foremost tool to
address the needs of backup and recovery. After a complete, consistent backup of the database has been taken you are
protected from many types of failures affecting your applications. The most common problems that require a restore
of parts or the entire database are media failures and user errors. Oracle's inability to read or write to a physical file
Search WWH ::
Custom Search