Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

CFS Multiple Tape Drive Backup

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.


If the RAC setup includes a tape drive on each node or the backup is to a disk on each node, the backup can be parallel, which will make it go faster, utilizing the entire available instance for the backup operation. For the example 2-node RAC setup, after connecting to the RMAN catalog and the target instance, these commands would be issued:

CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
CONFIGURE DEFAULT DEVICE TYPE sbt;
CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT 'SYS/kr87m@ault1';
CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT 'SYS/kr87m@ault2';

If a device type of DISK is in use, substitute DISK for SBT and specify the path to the backup directory as a part of the CHANNEL configuration. For example:

CONFIGURE CHANNEL 1 TYPE disk FORMAT '/u01/backup/ault_rac1/b_%u_%p_%c' CONNECT 'sys/kr87m@ault1';

This configuration need only be specified once unless something happens to the RMAN catalog. Once the configuration is set, the command to perform the backup is fairly simple:

BACKUP DATABASE PLUS ARCHIVELOG delete INPUT;

There is also provision for a control file backup:

BACKUP DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVE LOG delete INPUT;

RMAN Backup: Raw File Systems To a Single Tape Drive

The major problem with RAW file system setups is that each node only sees the archive logs it has produced. In order for the node to see the other archive logs from the other nodes, the archive log directories must be NFS-mounted to the backup node. The NFS mounts must be read/write in order to specify DELETE ALL INPUT or DELETE ALL.

The script to perform the backup of a RAW file system would resemble:

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
BACKUP DATABASE PLUS ARCHIVELOG delete INPUT;

The above commands will only work if the backup node has read/write access to the archive log directories for all nodes in the RAC database cluster.

RMAN Backup:  Raw File Systems to Multiple Tape Drives

The script to perform this backup would resemble:

CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT 'SYS/kr87m@ault1';
CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT 'SYS/kr87m@ault2';


If a device type of DISK is in use, substitute DISK for SBT and specify the path to the backup directory as a part of the CHANNEL configuration. For example:

CONFIGURE CHANNEL 1 DEVICE TYPE disk FORMAT '/u01/backup/v10g_rac1/b_%u_%p_%c' CONNECT 'sys/kr87m@v10g1';

As mentioned, this configuration only has to be specified once, unless something happens to the RMAN catalog. Once the configuration is set, the command to perform the backup is fairly simple:

BACKUP DATABASE PLUS ARCHIVELOG delete INPUT;

There is also provision for a control file backup.

BACKUP DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG delete INPUT;

The DELETE INPUT clause was used in this case. This is because the process performing the backup is local to each node and has read/write access to the archive log directory.

Example Configuration and Backup Using Grid Control/EM and RMAN

This section will show actual screen shots of the configuration and execution of a backup. This example uses a SUN environment using The Grid Control (EM) interface for RMAN.

First, the Schedule Backup: Strategy screen is called from the Maintenance section of Grid Control. Figure 13.6 shows the Grid Control Job Strategy screen.

Figure 13.6: Grid/EM Schedule Backup: Strategy

The selection of the Backup Strategy list box offers the choice of Oracle suggested methodology or custom methodology. Figure 13.7 shows the use of the customized screen. On the custom screen, pick lists are used to customize the backup.

Figure 13.7: Grid/EM Screen for Customized Backup

Once the user decides whether to use Oracle suggested or customized backup, the Next button is used to advance to the next window. The Grid/EM interface will then show a summary of the script used for backup and allows it to be approved. This is shown in Figure 13.8.

Figure 13.8: Grid/EM Schedule Backup: Review Screen

Once the RMAN script has been reviewed, the job is submitted using the Submit Job button. The status of the job can be monitored using the Grid/EM Job Status screen from the Jobs tab. The Job Status screen is shown in Figure 13.9.

Figure 13.9: Grid/EM Job Status Screen

The screen in Figure 13.9 shows the status of all jobs, not just the backup job. The example above shows the results of a SQL job run. By clicking on the various steps of the job process, any output generated can be displayed.

 


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.

http://www.rampant-books.com/book_2004_1_10g_grid.htm


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational