10-27-2011 12:43 AM
REFERENCE: https://www-secure.symantec.com/connect/forums/darsdatabaseupdate-job-failed
Hello all!
Did this problem ever get solved?
I'm having the same error.
Same Linux version,
same Oracle version,
libobk.so is linked to the right library: /usr/openv/netbackup/bin/ libobk.so64
What strikes me is the fact that the error only occurs in 1 out of n backupjobs.
Succeeding jobs come with the application backup client name "kespbac" - that's correct.
Failing job comes with the host's client name olga5443bac.
Final errorcode is "23".
Best regards,
Gerald
10-27-2011 12:58 AM
All the errors in Job details are produced by bprd.
Please ensure that you have bprd and bpdbm logs on the master server (restart NBU after creating the folders).
Another helpful log will be the client's dbclient log. If the folder does not exist, remember to 'chmod 777 dbclient' after creating the folder.
Post bprd and dbclient logs (as attachments) to start with.
About the client's two names - which name is hard-coded in the backup script with "NB_ORA_CLIENT" variable? If not specified, CLIENT_NAME in bp.conf will be submitted with backup request.
Can master resolve both client's ip-addresses to correct hostname that appears in policy Client name?
10-27-2011 02:24 AM
@Marianne van den Berg
My basic problem is:
Nobody can tell me what exactly is the DARS database?
I asked our Oracle experts, I asked our SAP experts, none of them ever heard of DARS.
Can you explain, in short words, what it is and what it does?
I'm sure that this would help me to understand why one out of 5 jobs comes with the wrong client name.
Thanks in advance ;)
Gerald
10-27-2011 02:40 AM
DARS is part of NetBackup (that is why I asked for bprd log on the master):
See http://www.symantec.com/docs/TECH126314 :
- dars (Database Agent Request Server)
"why one out of 5 jobs comes with the wrong client name "
Client hostname is sent by the Oracle client. Check script, bp.conf and dbclient log.
10-27-2011 03:33 AM
I've seen that TECH126314.
It tells me that DARS is there.
However, it doesn't tell me what it does.
10-27-2011 05:00 AM
New database in NBU Relational database. Listing on a 7.1 master:
/usr/openv/db/data >ls
BMR_DATA.db DARS_DATA.db EMM_DATA.db NBAZDB.log
BMRDB.db DARS_INDEX.db EMM_INDEX.db NBDB.db
BMRDB.log DBM_DATA.db NBAZDB.db NBDB.log
BMR_INDEX.db DBM_INDEX.db NBAZDB.db.template vxdbms.conf
This database collects and stores Oracle metadata that is needed for "Guided Application Recovery".
10-27-2011 11:44 PM
OK, I'll try to explain DARS, as far as I understand:
DARS (Database Agent Request Server) comes into play where "Guided Application Recovery" is involved.
Guided Application Recovery means, in plain text, that recovery of Oracle databases can be triggered from the OPS-Center application. This comes in handy when a bunch of developers needs a recovery every odd day: now they can do their own recoveries in the OPS-Center.
Wherever this feature is needed, the following entry in bp.conf must be present:
ORACLE_METADATA = YES
Wherever the feature is not needed, the problem addressed in this thread can be worked around by setting ORACLE_METADATA = NO, or simply removing the entry from bp.conf.
This solved the problem in our case: we don't need Guided Application Recovery with the client host in question.
---------------------------------------------
However, there seems to be a little bug in the process of DARS_DATABASE_UPDATE:
It seems to ignore the environment variables passed by the backup script, such as NB_ORA_CLIENT.
Thus, the DARS jobs come with the client name from the bp.conf - and fail.
The normal database backup jobs rely on the NB_ORA_CLIENT variable passed by the backup script - and succeed.
10-28-2011 12:13 AM