Page 585
Page 586
As most of us have learned at some point in our computing lives, data backups are an absolutely essential ingredient in most any computer system that we depend on. Disk head crashes, circuitry failure, and even catastrophic loss of data centers are all facts of life that DBAs must plan for. Fortunately, Oracle is a very robust database system with years of field-proven backup and recovery techniques that can keep your data safe when the inevitable happens. As a professional DBA, you are expected to keep your system running like a well-oiled machine. You must also take measures to ensure that the data contained in your RDBMS is safe from all sorts of threatening hazards.
Imagine that it's two weeks prior to end-of-year processing and your database system has just lost a disk drive. The CEO and CFO are both standing in your office. They want to know how long it will be before the system is back up, and they remind you that they can't lose any data from the financial system. This chapter is designed to give you the information you'll need to tell them "It won't be long" and "Of course there won't be any loss." You'll also learn some common non-emergency uses of the backup system.
It's also worth pointing out that, in this context, backups are used for data recovery both in emergency situations and in controlled situations in which you are simply moving data from one instance into another, switching machines, or just reorganizing a database.
The emphasis of this chapter will be on helping you decide, plan, and test your backup strategy. The ease with which you'll be able to recover your database is directly related to the effort you put into your backup strategy. If you are in an uncomfortable recovery situation, you should work with Oracle support for your specific recovery needs because the details will vary on a case-by-case basis. As you design, implement, and use your backup strategy, please keep these important points in mind:
Page 587
Data loss can be classified as either physical or logical. Physical data loss is the loss of components at the operating system level of a database, such as data files, control files, redo logs, and archived logs. This might be caused by a disk drive crash, someone accidentally deleting a data file, or a configuration change that overwrites any critical database file. Logical data loss is a loss of database-level components such as tables, indexes, or table records. This could be caused by someone accidentally dropping the wrong table, an application going awry, or a shortsighted WHERE clause in a DELETE statement. Not surprisingly, Oracle allows for both physical data and logical data backups. Although each backup solution could be used as a substitute for the other, you'll find out that an effective backup plan must include both to fully protect you from data loss.
The physical data backup is a copy of
If you lose a disk drive or need to move some of the data files around, this is the most straightforward approach to recovery. Physical backups are usually run at scheduled intervals to protect against the physical loss of a database. Indeed, if you want to ensure that you can recover the system to the last commit, you must have a physical backup as a base, as well as the archive and redo logs that have accumulated since the last physical backup.
Physical backups are further categorized into cold and hot backups. Cold backups are used when you have the option of shutting down the database long enough to back up the system. Hot backups provide a physical backup when the database is open and available for use by users. This allows an Oracle database to operate 24 hours a day, 7 days a week (24/7) and still be backed up at regular intervals. Unless you absolutely must have your database running in a 24/7 cycle, you are much better off using cold backups. As you will see, hot backups are not for the meek and must be thoroughly tested before you rely on them.
Please be aware that the term cold backup is synonymous with offline backup, as is hot backup with online backup.
Backup Frequency and ARCHIVELOG Mode
Two essential parts of planning backups are choosing the proper backup frequency for your database and deciding whether to run in ARCHIVELOG mode.
When choosing a backup interval, always ask yourself, "How much data can I afford to lose?" If your database is not running in ARCHIVELOG mode, you could lose all transactions since your last backup. If your business needs allow the database to lose one week's worth of transactions, you would need to back up the database at least once per week.
continues