If and when it is desirable to make the standby database the primary database, use the following SQL statement: alter database activate standby database. This will then allow access to the standby database as if it were the primary. I recommend that multiple names be specified in the SQL*Net TNSNAMES.ORA file to point to both the primary and this standby environment.

---

TIP:  
Do not activate the standby database until all of the log files have been applied.

---

It is my recommendation that complete duplicate hardware, including disk drives, be implemented with standby databases. When the standby database is activated, it simply becomes the primary. When the damaged environment is repaired, make it the standby environment, eliminating the need to quickly restore the original environment, and so on.

Backup Schemes

Backup schemes consist of a set of identified processes used to make copies of the targeted media, typically on some kind of removable media, to restore the environment to its original state prior to any hardware or software problem that made the original media inaccessible or unusable.

Oracle supports a variety of backup and recovery processes. These processes can be used in a standalone mode, or combined with other backup processes to provide a tailored, more comprehensive backup scenario for specific business needs.

Overview of Various Backup Schemes

Cold backup is the basis for several of the other backup options. Cold backups (as described earlier in this chapter) should be taken just after an Oracle installation, including the setup of all SQL*Net connectivity, with ARCHIVELOG mode turned on (if desired), online redo logs established and mirrored, and so on. This will give the DBA a solid basis for all the other types of recovery.

Cold backups are also useful in static systems that have a regular window for maintenance. For example, a good time to take a cold backup is right after a large load, possibly even an unprotected direct path load, of data. Incremental exports could be used to supplement object recovery between cold backups.

Hot backups allow for the backup of the physical database files while the database is open and in use. Shops with 24×7 requirement utilize hot backups for their tablespaces that are dynamic in nature. Database design, taking into account the backup and recovery needs, will have the greatest impact on recovery times. It is important that the dynamic objects be stored in separate tablespaces from those that are static in nature. This will allow cold backups to capture all the changes and hot backups to enhance the backup plan by only backing up those tablespaces with changes. As previously discussed in this chapter, the size of the redo logs, archive logs, and the checkpoint intervals has a direct impact on the amount of recovery time.

Figure 23.4 is a typical scenario utilizing ARCHIVELOG mode and a mix of cold and hot backup processes. Point A on the time line is the cold backup. The database is in a shutdown state and all of the files are backed up. Points B, C, and D are archive logs that were created as the online redo logs filled. Point E is a hot backup of the APPL tablespace. If a media failure occurred between Point F and Point G to a file assigned to the APPL tablespace, the files associated with that tablespace would be restored and archive log file 4 would be prompted for and applied during the tablespace recovery process. If a media failure occurred once again between Point F and Point G to a tablespace data file other than the APPL tablespace, the database files from the cold backup at Point A would have to be restored, and each of the archive log files 1, 2, 3, and 4 would be prompted and applied.

FIGURE 23.4  Typical ARCHIVELOG mode scenario.

It is also important to back up tablespaces that have had direct path load or any unprotected DDL/DML commands applied to them. These commands gain their performance enhancements by not utilizing the normal read consistency and redo log recovery features.

Export and Import can play an important role in any development environment, adhoc end-user environment, and most backup scenarios that do not involve large volumes of data.

Standby databases require that the archive log files be applied as soon as they become available. I would recommend doing this task with a script that periodically viewed the DUMP_DEST directory for new archive log files, copied them to the standby system, and ran the command to apply the log to the standby environment. There are also third-party scheduling and monitoring tools that could perform this task automatically. A standby environment really does not need to be backed up itself because it is already a backup of another system. The primary system should have a backup plan in place and what is used for backup of the primary system could be used to re-set up the standby environment.