behind the FRA is to simplify the management of your backup and recovery duties by consolidating the requisite files into a single location that Oracle and RMAN can then micromanage, while the DBA moves on to other important duties. This simplification is based on some underlying principles of a solid backup strategy that focuses on availability:
■ At least one copy of important datafiles, if not the entire database, should be kept on disks that are locally accessible to the database.
■ Backups past a certain age should be moved to tape based on storage pressure on local disks.
■ Long-term backup management should be almost completely automatic, based on business rules.
The FRA that you set up can be either a directory on a normal disk volume or an Automatic Storage Management (ASM) disk group. The FRA is determined by two initialization parameters: DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. The first determines the location and the second, the size. These can be set in your init.ora file, if you still use one, or in the SPFILE via an alter system set command.
Chapter 2: Introduction to the RMAN Architecture 57
With an FRA configured, you are not required to set any other LOG_ARCHIVE_DEST_ n parameter for archive logs; by default, with an FRA, Oracle will default LOG_ARCHIVE_DEST_10
to the FRA. It should also be noted that with an FRA in use, you cannot use LOG_ARCHIVE_DEST
or LOG_ARCHIVE_DUPLEX_DEST—but, of course, you rid yourself of these outdated parameters long ago…right?
The FRA manages recovery files internally, first based on database name, then on types of files, and then by the dates the files are generated. The files themselves are named according to the Oracle Managed Files (OMF) format. As such, the files are hard to decipher (except for archive logs, which still maintain the structure you give them with the LOG_ARCHIVE_FORMAT parameter).
Significant internal directory structures exist for file management. However, the point of an FRA is that you don’t need to spend much time worrying about the files. That being said, it’s worth taking note of the internal structure and familiarizing yourself with where the files go. Sooner or later, you will end up digging for a particular file manually. Trust us.
The same FRA can be used by multiple databases. This can provide significant advantages, particularly for a Data Guard configuration, but also if you have a large ASM disk group and multiple databases on the same system. It can come in handy, as well, when it comes time to clone production for test purposes. Here’s the catch: all the databases that share the FRA either have a different value for DB_NAME or have a different name for the value DB_UNIQUE_NAME.
Summary
In this chapter, we discussed the underlying architecture employed by RMAN to perform backups of an Oracle Database 11 g database . We covered the RMAN executable, the target database packages, and the control file. We discussed in detail the process architecture and how memory is allocated for RMAN backups. We discussed the usage of an RMAN recovery catalog and how to connect to an auxiliary database. After discussing the different architectural components, we gave a brief run-through of a typical backup operation to show the different components in use.
This page intentionally left blank
PART
II
Setup Principles and
Practices
This page intentionally left blank
CHAPTER
3
RMAN Setup and
Configuration
62 Part II: Setup Principles and Practices
et’s get started with this RMAN thing, shall we? Let’s just reach down, pull on the handle, I said, pull on the handle…and, it doesn’t start. We first need to set up RMAN and our database for backup and recovery operations before we can actually do anything. In this chapter, we look at initial RMAN setup requirements and options. First, we dive into Oracle redo logs a little deeper than we did in Chapter 1.
These are critical structures in the Oracle
■ At least one copy of important datafiles, if not the entire database, should be kept on disks that are locally accessible to the database.
■ Backups past a certain age should be moved to tape based on storage pressure on local disks.
■ Long-term backup management should be almost completely automatic, based on business rules.
The FRA that you set up can be either a directory on a normal disk volume or an Automatic Storage Management (ASM) disk group. The FRA is determined by two initialization parameters: DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. The first determines the location and the second, the size. These can be set in your init.ora file, if you still use one, or in the SPFILE via an alter system set command.
Chapter 2: Introduction to the RMAN Architecture 57
With an FRA configured, you are not required to set any other LOG_ARCHIVE_DEST_ n parameter for archive logs; by default, with an FRA, Oracle will default LOG_ARCHIVE_DEST_10
to the FRA. It should also be noted that with an FRA in use, you cannot use LOG_ARCHIVE_DEST
or LOG_ARCHIVE_DUPLEX_DEST—but, of course, you rid yourself of these outdated parameters long ago…right?
The FRA manages recovery files internally, first based on database name, then on types of files, and then by the dates the files are generated. The files themselves are named according to the Oracle Managed Files (OMF) format. As such, the files are hard to decipher (except for archive logs, which still maintain the structure you give them with the LOG_ARCHIVE_FORMAT parameter).
Significant internal directory structures exist for file management. However, the point of an FRA is that you don’t need to spend much time worrying about the files. That being said, it’s worth taking note of the internal structure and familiarizing yourself with where the files go. Sooner or later, you will end up digging for a particular file manually. Trust us.
The same FRA can be used by multiple databases. This can provide significant advantages, particularly for a Data Guard configuration, but also if you have a large ASM disk group and multiple databases on the same system. It can come in handy, as well, when it comes time to clone production for test purposes. Here’s the catch: all the databases that share the FRA either have a different value for DB_NAME or have a different name for the value DB_UNIQUE_NAME.
Summary
In this chapter, we discussed the underlying architecture employed by RMAN to perform backups of an Oracle Database 11 g database . We covered the RMAN executable, the target database packages, and the control file. We discussed in detail the process architecture and how memory is allocated for RMAN backups. We discussed the usage of an RMAN recovery catalog and how to connect to an auxiliary database. After discussing the different architectural components, we gave a brief run-through of a typical backup operation to show the different components in use.
This page intentionally left blank
PART
II
Setup Principles and
Practices
This page intentionally left blank
CHAPTER
3
RMAN Setup and
Configuration
62 Part II: Setup Principles and Practices
et’s get started with this RMAN thing, shall we? Let’s just reach down, pull on the handle, I said, pull on the handle…and, it doesn’t start. We first need to set up RMAN and our database for backup and recovery operations before we can actually do anything. In this chapter, we look at initial RMAN setup requirements and options. First, we dive into Oracle redo logs a little deeper than we did in Chapter 1.
These are critical structures in the Oracle
Similar Books
