Oracle Rac with Recovery

Hi As you are doing or configuring oracle rac with backup exec for first time please check below link just to be sure everything you have setup is correct http://www.symantec.com/docs/HOWTO12569 http://www.symantec.com/docs/HOWTO12577 it´s taking TOO long to start the backup. Is it normal ? Until your backup is running successfully it should not be an issue. Also if you are keen to know why if it is taking long time only one one node and other node it is working fine you can use below link to debug the backup on both the node and compare the debug log too see were is the issue. http://www.symantec.com/docs/TECH67247 Thanks

Thx, i will take a look at the debug note.

About the config, it´s not the first time with Oracle Rac, only with using recovery catalog.

 

 

Hi

 

Few thing need to be cleared here

 

1 Is recovery catalog really required in your enviorment

2 If yes then as per best practisces it will be good to have it on both the nodes instead of keeping it on one node

3 Finally to Isolate the issue please try following

From the second node, using the sqlplus connect to the recovery database and check how much time it takes to connect & see how much time it takes ,if it is taking long time ,it is not a backupexec issue then

 

Hi,

Just to understand better, is your recovery catalog database a rac or normal single node database?

In BEOratab you should only add the oracle rac node that you want to backup, try removing the recovery catalog database entry from the BEoratab file, unless recovery catalog database is also a rac configuration and you plan to backup recovery catalog database like your primary oracle rac database.

Is AgentConfig on all oracle rac nodes configured by providing the recovery catalog database?

Thanks,

Hi

 

Backup_Exec :

Yes, it´s required because the DBA team wants it, so it´s not my call.

Will try to isolate it

Sameer Kapadia :

Yes , my Recovery Catalog database is a Rac, that´s why its added in the beoratab, because without it, the Backup Fail.

Yes, both nodes are configured with the same settings.

It´s just taking longer to start, maybe because of some verification ? I´m not an "oracle guy".

The questions is : with a big database, Backup Exec take a long time to check ? For example, in SQL, it does a physical_check by default.

 

 

 

Hi Thanks and once you isolate and see the vxbsa logs you will come to know difference between working and not working. Regards.

Well, i saw the logs and it´s say its working. The job logs in Rman say it´s working.

 

But in my Example, the database is about 550 GB, and the backup is doing only 1.6 GB.

Database total = 550

Backup = 1.6

Type of backup = Full

Backup Exec 2012 with latest Hotfix (including Ralus agent)

Here´s the Job log(i only changed the name of database to XXXXX)

 

Recovery Manager: Release 11.2.0.3.0 - Production on Mon Aug 20 17:12:06 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

 
connected to target database: XXXXXX (DBID=531030218)

 
connected to recovery catalog database

 
 
 # -----------------------------------------------------------------
 # RMAN command section
 # -----------------------------------------------------------------
 
 RUN {
 ALLOCATE CHANNEL ch0
     TYPE 'SBT_TAPE';
 SEND 'BSA_SERVICE_HOST=xx.x.x.x,NBBSA_TOTAL_STREAMS=1,NBBSA_JOB_COOKIE={BC565ED4-8A4B-41A6-A375-A33B374C1B9B},NBBSA_DB_DEVICE_NAME=Oracle-Linux::\\RAC-XXXXX-531030218\XXXXXX';
 BACKUP
     FORMAT 'BE_U'
     ARCHIVELOG ALL FORCE NOT BACKED UP;
 BACKUP CURRENT CONTROLFILE
     FORMAT 'BE_U';
 
 RELEASE CHANNEL ch0;
 }
starting full resync of recovery catalog
full resync complete
allocated channel: ch0
channel ch0: SID=167 instance=XXXXX2 device type=SBT_TAPE
channel ch0: Symantec/BackupExec/1.1.0

sent command to channel: ch0

Starting backup at 20-AUG-12
current log archived
skipping archived logs of thread 1 from sequence 75 to 79; already backed up
skipping archived logs of thread 2 from sequence 15 to 21; already backed up
channel ch0: starting archived log backup set
channel ch0: specifying archived log(s) in backup set
input archived log thread=2 sequence=22 RECID=14 STAMP=791760378
input archived log thread=1 sequence=80 RECID=13 STAMP=791744446
input archived log thread=1 sequence=81 RECID=16 STAMP=791804657
input archived log thread=2 sequence=23 RECID=15 STAMP=791769883
input archived log thread=2 sequence=24 RECID=17 STAMP=791831606
input archived log thread=1 sequence=82 RECID=18 STAMP=791831613
channel ch0: starting piece 1 at 20-AUG-12
channel ch0: finished piece 1 at 20-AUG-12
piece handle=BE_0jnj4p26_1_1 tag=TAG20120820T171335 comment=API Version 2.0,MMS Version 1.1.0.0
channel ch0: backup set complete, elapsed time: 00:01:55
Finished backup at 20-AUG-12

Starting backup at 20-AUG-12
channel ch0: starting full datafile backup set
channel ch0: specifying datafile(s) in backup set
including current control file in backup set
channel ch0: starting piece 1 at 20-AUG-12
channel ch0: finished piece 1 at 20-AUG-12
piece handle=BE_0knj4p65_1_1 tag=TAG20120820T171545 comment=API Version 2.0,MMS Version 1.1.0.0
channel ch0: backup set complete, elapsed time: 00:00:03
Finished backup at 20-AUG-12

released channel: ch0

 EXIT

Recovery Manager complete.