|< Day Day Up >|| |
It is worth spending a moment to come to terms with the underlying architecture of an RMAN backup, and how it is different from an OS copy. To do so, it is best to know exactly what RMAN is: a client utility, like export or SQL*Loader. RMAN comes installed with the Database Utilities suite with every Oracle database. As such, it can be installed at a client system that has no database, and can be used to connect remotely to any number of databases. This is becoming less common, but it is worth pointing out: RMAN makes a SQL*Net connection to the Oracle database that needs to be backed up.
Typically, the connection from RMAN to the database is a local connection, because RMAN is running from the same environment as the database-same ORACLE_HOME, same ORACLE_SID. But there are times that require a tns alias to the database be set up in the tnsnames.ora file, in which case RMAN does not require the same environment as the database-it will connect via the listener, same as a remote SQL*Plus connection, for instance.
Let's get some vocabulary out of the way:
Target database In RMAN, the database you are currently attempting to back up or recover is the target.
RMAN executable The RMAN executable is the client utility itself, made up of both the RMAN executable and the recover.bsq (the library file).
Recovery catalog The recovery catalog is a set of tables, indexes, and packages that are installed into a user schema of an Oracle database. These tables store information about RMAN backups that occur for all the target databases in your enterprise.
Catalog database The catalog database is the database you choose to house the recovery catalog schema.
Auxiliary database In situations where you use RMAN to create a clone of your target database, you will make a connection to the clone as the auxiliary database.
The list above provides a good road map of the components in play during any RMAN operation (say, a backup). The connection topography can be seen in Figure 8-1. From the RMAN prompt, you make a connection to the target. If you use a catalog, you make the connection to the catalog as well; typically, the catalog connection is going to be using a net service name (TNS alias). This is because you cannot make two local connections to two different databases, and you should never put the recovery catalog in the target database. If you are performing a cloning operation, you would also make a connection to the auxiliary database.
Figure 8-1: Network topography of an RMAN operation
The RMAN utility is nothing more, really, than a command syntax interpreter. It takes as input simple commands to back up or restore, and turns them into remote procedural calls that are passed as PL/SQL packages at the target database. These packages, dbms_backup_restore and dbms_rcvman, are found in the sys schema and have complementary duties. dbms_rcvman accesses the controlfile to build file lists and dictates work flow in the backup job. This backup job is then passed to dbms_backup_restore for actual file access for backups or restore. And that is all we need to know about that, for now!
RMAN has unprecedented access to information about the target database, and this access provides the unprecedented features that make RMAN backups so compelling. First and foremost, RMAN makes a server process connection to the target database as a sysdba user; therefore, RMAN has access to the best source of all important information in the database: the controlfile. RMAN checks the controlfile for information about the datafiles, and compiles backup lists based on the number and size of the files. The controlfile also guides RMAN with operations concerning archivelogs: RMAN automatically adjusts for existing archivelogs and backs up only those that are complete. Then RMAN can delete all archivelogs in all destinations (except those that are listed as a service in the database-that is, archivelogs created at a standby system).
In addition to accessing the controlfile for information about what to back up and what to restore, after RMAN performs an operation, it also records the data about the backup itself in the controlfile. This data includes information about what files have been backed up, and when, along with checkpoint information and the names of the backup pieces (the output files created by a backup).
After gathering the required data from the controlfile, RMAN performs a backup by initializing one or more channel processes. These channel processes access the datafiles and stream the Oracle data blocks from the files into memory buffers within the Oracle Process Global Area or PGA (of the target database: the database is backing itself up). Once a buffer is filled, the channel process does a memory-to-memory write of each data block from the input buffer to an output buffer. Once the output buffer fills, the entire buffer is written to the backup location. Figure 8-2 illustrates the RMAN architecture, including controlfile access.
Figure 8-2: RMAN backup architecture
The fact that RMAN has access to the Oracle data block pretty much sums up why RMAN is so invaluable. Nearly everything good that comes from RMAN comes from the fact that the data blocks are pulled through the Oracle memory window and then streamed to the backup location. When the memory write occurs from input buffer to output buffer, RMAN checks the block for corruption and reports all corruptions, aborting the backup-and the result is no corrupt blocks in the backup. At the same time, RMAN checks to see if the block is even worth streaming to backup: if the block has never been initialized, RMAN simply eliminates the block so that it does not take up space in the backup. It is at this time, as well, that RMAN can check the block header for an incremental System Change Number (SCN), and determine if the block should be backed up during an incremental backup (more on this in the section 'Backing Up the Available Database').
There is so much good stuff to say about RMAN, there's simply no room in this chapter to cover all the territory. The basics have already been described:
RMAN uses the controlfile to guide a backup or recovery, and records its own data in it.
RMAN backs up the database at the data block level, streaming them through a memory buffer to perform checks.
From here on out, it's time to concentrate on what RMAN can do for the HADBA.
As a stand-alone client utility, RMAN has an above average command syntax (naysayers, away!). Want proof? You can go to any Oracle database, version 9.0.1 or higher, and do the following:
bash>rman target / rman>backup database;
You will get a backup of your database. Granted, the backup will be in the wrong place-without any parameters, the default location is $ORACLE_HOME/dbs. But you will have a usable backup, after typing four words. Likewise, if you ignored our earlier pleas for no full database restore, you can do the same thing to restore your database (if your database is mounted off a current controlfile):
This command will look at the controlfile to determine which files need to be restored, as well as which backup is best used for the restoring. The simplicity saves you from knowing where the backups are or when they were last taken (or, really, from even knowing what the schematic layout of the datafiles might be at the time of restore).
There are many good sources of RMAN command-line syntax available; we don't have the space to go into the details here. Check out the Oracle Press's own Oracle9i RMAN Backup and Recovery, or the Oracle 10g RMAN reference guide itself.
If you use EM to back up your database, you are using RMAN and you may not even know it. EM puts a GUI, wizardly face on backup and restore operations; if you look behind the curtain, though, EM is merely building RMAN blocks and then executing them from the local copy of RMAN at the target database.
The RMAN interface through Enterprise Manager has had a welcome facelift in Oracle Database 10g, but there still exists functionality for which you must return to the command line in order to harness. We suggest, then, that you familiarize yourself with the RMAN command prompt. Then you can go back to EM and use it for what it is best at: backup job scheduling.
For each database, you can connect to the Enterprise Manager Database Control console and navigate to the maintenance page. There you will see a header entitled 'Backup/Recovery.' Underneath, you will see the different backup and recovery operations that you can do from EM: schedule backups, perform recovery, manage current backups, and configure backup and recovery settings (including recovery catalog settings). One important note: If you are looking for a GUI interface to Oracle Flashback Technologies, Flashback Database can be found under the 'Perform Recovery' heading in Enterprise Manager. More on this in Chapter 9.
Schedule backups From this page, you provide host credentials, and then you can schedule a job to run your RMAN backups based on your provided parameters
Perform recovery This wizard guides you through the steps to perform different types of recovery.
Manage current backups This console provides all of the functionality required to do backup housekeeping, as detailed later in this chapter.
Configure backup settings Here you can make changes to permanent configuration parameters.
Configure recovery settings This interface actually provides an excellent window into the myriad different settings the HADBA can use to tightly control recoverability, from setting a mean time to recovery, to turning on archivelog mode, to configuring for Flashback Database.
Configure recovery catalog settings Here you can specify the location of the recovery catalog and register the target database, if you need to.
HA Workshop: Schedule a Backup Job from Enterprise Manager Database Control
This workshop will go through the steps to schedule a job for backing up a database in archivelog mode using EM.
Step 1. From EM Database Control, go to the maintenance page and click on Schedule Backup Job. The first page wants to know if you will back up to disk or tape, and whether you want to use an Oracle suggested backup strategy or a custom built strategy. In this exercise, we use a custom strategy and will back up to disk, as shown in Figure 8-3. Provide the host credentials-this is the username and password of the OS user who will run the job. We suggest using Oracle, or whatever name you gave to the Oracle software owner. Then click Next.
Figure 8-3: Choosing a backup strategy
Step 2. Outline the backup strategy. Choose a full, online backup; this will take a backup of the entire database while the database is up and running (requires archivelog mode). Also, choose to back up all archivelogs on disk, and choose to delete archivelogs after they are backed up. (Our selections are previewed in Figure 8-4.) Then click Next.
Figure 8-4: Backup strategy
Step 3. Specify a location for the backups on disk. If you have already created a flashback recovery area, it will be the only option here. Click Next.
Step 4. Schedule the backup job. In Figure 8-5, we have created a backup to run at 2:00 A.M. every day, for an indefinite time into the future.
Figure 8-5: Scheduling the backup job
Step 5. Review the backup job details, then submit the job by clicking on Submit. You can review the job immediately by clicking on View Job, or return to it later by going to the bottom of the Maintenance page and, under Related Links, choosing Jobs.
|< Day Day Up >|| |