RMAN and Data Guard

 < Day Day Up > 



The relationship between RMAN and Data Guard is based on the technology that underpins the Data Guard product: the standby database. As you learned in Chapter 7, the Standby Database stands at the center of the DG environment: a complete duplicate copy of the production database mirrored to a similar hardware configuration (this, of course, refers to a physical standby database). RMAN backups can be used to build the standby database-in fact, there is functionality built directly into RMAN to do so.

Using RMAN to Build the Standby Database

A common use of Oracle backups in any environment is to move them to a new location and open them as a clone copy of the database for test and development purposes. It's a good way to get some value out of backups, other than merely a 'just in case' fallback. In RMAN, the ability to clone a database has been built into the command-line interface as the duplicate command, and is quite simple:

duplicate target database to <clone_db_name>;

Then this command has been extended to support the creation of a standby database using RMAN backups:

duplicate target database for standby;

Of course, that is the icing on the cake: there is a certain amount of prep work required to create the standby database from RMAN backups. When performing the duplication, RMAN makes the connection to the target database (the primary database) and to the catalog (if you use one), and then a third connection to the auxiliary database. The auxiliary database is the database that will become the standby database. Figure 8-7 shows the topology required for a standby creation, given RMAN backups to a tape media server. What is important to note about the duplication process is that the auxiliary database instance must exist before duplication can start, and the auxiliary instance must have access to the RMAN backups.

click to expand
Figure 8-7: Anatomy of a duplicate for standby operation

If the backups have been taken to a media management server accessible by the target node and the auxiliary node, there is little problem with the requirements. The only trick you must remember involves permissions to backups at the media management server. Typically, computer systems are registered at the media management server as clients and the backups are encoded with a client name at the time of backup. So, when you attempt to access backups at the auxiliary node that were taken from your target node, you might expect the server to respond that 'no such backups exist.' To resolve the issue, you pass the name of the target server from the auxiliary server, like so:

allocate channel sbt1 type sbt parms="env=(nb_ora_server=lnx01,   nb_ora_class=oracle, nb_ora_client=target_node)";

Note 

This example shows the syntax for passing a client name if you are using Veritas NetBackup for Oracle. Other media managers have different ways of handling client to client restores. Consult your media management vendor's documentation.

Flashback Recovery Area and the Standby Database

If you want to use backups that exist in your target node flashback recovery area, things get handled a little differently. To provide access to the FRA, you can NFS mount the FRA at the standby location. If the FRA is on a shared volume formatted with Oracle Clustered File System (OCFS), you can also give direct access to the FRA, so long as the standby node has access to the shared volume. Or, if it makes sense in your environment, you can always copy the entire FRA over from your target node to the standby node.

There are a lot of good reasons to allow sharing of the flashback recovery area between your primary database and your standby database, as noted in Chapter 7. From the configuration perspective, it allows RMAN to have access to disk-based datafile backups, which typically are the most recent and require the least amount of archivelog recovery to bring up to speed with the primary database. This is particularly true if you use incrementally updated backups as described above.

HA Workshop: Use RMAN to Create a Standby Database

start example

Workshop Notes

This exercise creates a standby database on the same server as the primary database. The ORACLE_SID for the standby is stby, but the db_name will be the same as the primary: beta10. We will use both the db_file_name_convert and log_file_name_convert parameters, and we will perform media recovery.

Step 1.  Use RMAN to create a standby controlfile.

ORACLE_SID=beta10 export ORACLE_SID rman RMAN> connect target / RMAN> backup current controlfile for standby    format= '/space/backup/stby_cfile.%U';

You will need to specify a point in time after you created this standby controlfile, so perform a few log switches and then record the last log sequence number from v$archived_log.

SQL> alter system switch logfile; SQL> alter system switch logfile; SQL> select sequence# from v$archived_log;

Step 2.  Build your standby database directory structures.

mkdir /space/oracle_user/OraHome1/oradata/stby mkdir /space/oracle_user/OraHome1/oradata/stby/arch cd /space/oracle_user/OraHome1/admin mkdir stby cd stby mkdir pfile bdump udump cdump ls 

Step 3.  Copy the target init.ora file to the auxiliary location. If your target database uses an spfile, you will need to create a pfile from the spfile in order to capture parameters to move over.

If you use an spfile at your target:

Sql> connect /@beta10 as sysdba create pfile='/space/oracle_user/OraHome1/admin/stby/pfile/init.ora' from spfile;

If you use an init.ora file at your target:

cp /space/oracle_user/OraHome1/admin/beta10/pfile/init.ora    /space/oracle_user/OraHome1/admin/stby/pfile/init.ora

Step 4.  Make all necessary changes to your stby init.ora file.

Control_files=    '/space/oracle_user/OraHome1/oradata/stby/control01.dbf' Background_dump_dest=/space/oracle_user/OraHome1/admin/stby/bdump user_dump_dest=/space/oracle_user/OraHome1/admin/stby/udump log_archive_dest_1=    'location=/space/oracle_user/OraHome1/oradata/stby/arch' standby_archive_dest=    'location=/space/oracle_user/OraHome1/oradata/stby/arch' lock_name_space='stby' remote_login_passwordfile=exclusive db_file_name_convert=('beta10', 'stby') log_file_name_convert=('beta10', 'stby')

Step 5.  Start up the stby instance in nomount mode.

ORACLE_SID=stby export ORACLE_SID sqlplus /nolog sql>connect / as sysdba sql>startup nomount pfile=/space/oracle_user/OraHome1/admin/stby/pfile/init.ora

Step 6.  Configure your network files for connection to stby. After making any changes to your listener.ora file, be sure that you bounce your listener or the change will not take effect.

lsnrctl LSNRCTL>stop LSNRCTL>start The tnsnames.ora file should have an entry like this: STBY =   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = cervantes)(PORT = 1521))     )     (CONNECT_DATA =       (SID = stby)       (SERVER = DEDICATED)     )   )

The listener.ora file should have an entry like this:

SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = beta10)       (ORACLE_HOME = /space/oracle_user/OraHome1/)       (SID_NAME = stby)     )   )

Step 7.  From RMAN, connect to the target and auxiliary instance and run the duplicate command.

ORACLE_SID=beta10 export ORACLE_SID rman RMAN>connect target / RMAN> connect auxiliary sys/password@stby RMAN>run {   set until sequence = 789 thread = 1;   duplicate target database for standby   dorecover;}
end example

RMAN and the Logical Standby Database

As we learned in Chapter 7, it is no longer required in Oracle Database 10g that the primary database be quiesced (inactive) in order to take a backup for a logical standby database. Instead, we create a physical standby database, then make the conversion. See Chapter 7 for more information on creating a logical standby database.

Using the Physical Standby Database to Create Backups

If you have a physical standby database configured, you can put it to work for you. RMAN can connect to the standby database and take the backups at the standby. These backups can then be used to restore files at the primary database. Using this functionality, you can offload the disk I/O and memory utilization associated with running backups at your production server. Doing so provides yet another way to maintain an extremely high level of availability by eliminating the impact of backup processing.

You have to use a recovery catalog in order to back up your database files from the standby. By using the catalog, you can connect to the standby database, take the backups, and have them recorded in the catalog. Then, when you connect to the primary database and the catalog, RMAN will have access to the metadata about the backups taken at the standby.

The trick to performing backups at the standby is to know the nature of the standby databases, and the nature of RMAN backups. A standby database is an exact replica of the primary database, meaning it has the same database ID (DBID) as the primary. RMAN uses the DBID to identify unique databases in the recovery catalog. So, when RMAN connects to the standby, it considers it to be the primary database in most ways, with the same exact file structure and content. So a file backed up at the standby is a file that can be restored to the primary, as they are identical.

Don't let us lead you on thinking that you are somehow 'faking out' RMAN when you connect to the standby. RMAN is standby aware; it knows when it's connected to a standby, and acts accordingly. For instance, if you use a db_file_name_convert parameter at your standby to rename files to new locations, RMAN knows that it backed up a file from, say, /u02/oradata on the standby, but that it must restore the file to, say, /u04/oradata on the primary.

The backups that you need to be mindful of will be archivelog backups. Naturally, a copy of every archivelog must by rule exist at the standby database for recovery. So, you can back up the archivelogs from the standby. That's not the issue. The issue is archivelog cleanup-typically, an archivelog backup strategy employs the delete input option, which removes archivelogs after they have been backed up. But if you back up from the standby, the archivelogs will never be removed from the primary. You will have to employ another script to delete archivelogs from the primary database site.

HA Workshop: Back Up Directly to Tape from the Standby

start example

Workshop Notes

This workshop assumes that you have a physical standby database configured, with archivelogs streamed to the standby site via a Data Guard configuration. This workshop steps through a process of backing up datafiles directly to tape; we also address archivelog backup and cleanup at both sites (primary and standby).

Step 1.  Configure your media management layer, then configure your tape backup channels. For media manager configuration, see 'Media Management Considerations.' This step needs to be performed at both the primary and standby database. You should configure the SBT channels on the standby to reflect the client name of the primary, so that the backups taken at both sites are organized and stored the same at the media management server.

rman target / catalog rman/password@rman_cat_db rman> configure default device type to sbt; rman> configure channel device type sbt parms =     SBT_LIBRARY=/fileloc/libobk.so,     ENV=(NB_ORA_SERV=lnx01, NB_ORA_CLIENT = lnx02)"; rman> configure device type sbt parallelism 4; rman> configure channel device type sbt filesperset=4;

Step 2.  Back up the controlfile and spfile from the primary database site, and then clean out archivelogs based on a time frame of retention.

rman target / catalog rman/password@rman_cat_db rman> backup current controlfile; rman> delete archivelog completed before sysdate-7;

Step 3.  Back up the database and archivelogs from the standby site.

connect target sys/password@standby_db catalog rman/password@rman_cat_db backup database plus archivelogs not backed up 2 times; delete archivelogs completed before sysdate-7;
end example

Backup Using the Standby Database with a Flashback Recovery Area

If you have employed an FRA, the workshop above changes little. If you share an FRA between your standby and primary sites, you get the best of both worlds: you can run the backup at your standby database; the backups end up in your FRA, and are immediately usable by the primary database. You still need to connect to the primary to back up the controlfile and spfile.

If your standby and your primary have separate FRA areas, you lose a lot of functionality of the FRA for the primary site. This is because any backups you take to the standby FRA would have to be manually copied to the primary database FRA prior to restore. Better, in that situation, to take your backups directly to tape, so that you can connect your primary directly to the tape device and run the restore.

Design Your Backup Strategy to Fit Your Specifics

There is considerable room for tweaking your backup strategy to include your standby database as a partner. For example, you could have an FRA on the standby that is not shared by the primary until a restore is actually required; then, you remount the volume at the primary site. This type of solution would require a certain amount of hardware support, obviously, but the options are wide open. So, think through what fits your needs.

A Note on Recovery

When performing a restore operation at your primary using backups taken at the standby, be sure you connect to the primary database as the target, and then the recovery catalog. After doing so, restore and recovery will proceed normally, with no special modifications.



 < Day Day Up > 



Oracle Database 10g. High Availablity with RAC Flashback & Data Guard
Oracle Database 10g. High Availablity with RAC Flashback & Data Guard
ISBN: 71752080
EAN: N/A
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net