Re: RMAN conundrum

From: Jared Still <jkstill_at_gmail.com>
Date: Tue, 26 May 2009 16:51:27 -0700
Message-ID: <bf46380905261651w2d093e9dib347aac160315f80_at_mail.gmail.com>

On Tue, May 26, 2009 at 1:18 PM, Jared Still <jkstill_at_gmail.com> wrote:

> On database B, this error occurs after executing the last line of the
> script where the current controlfile is to be backed up:
>
> RMAN-00558: error encountered while parsing input commands
> RMAN-01009: syntax error: found "}": expecting one of: "allocate, alter,
> backup, beginline, blockrecover, catalog, change, connect, copy, convert,
> create, crosscheck, configure, duplicate,

Thanks for all your suggestions.

I found the problem (sort of), and it is not oracle related.

However, there is still something funny going on with oracle.

There is a password server used to retrieve database passwords.

The user setup on the server to retrieve the passwords was authorized for database A, but not for database B.

The command is pwc.pl -instance DB_NAME -username USERNAME

At the command line, it worked for the RMAN repository and database A, but not for database B.

Checking the permissions in the password database showed where the problem was.

A quick change in the local authorization file to use a different users that is authorized
for both databases, and it all works.

Here's what is strange: the backups worked for database B, up until the closing
curly brace of the RUN block.

This is from the log file of a backup of database B that ended with the RMAN-1009 error:

connected to target database: B (DBID=999999) connected to recovery catalog database

So I then set the permissions back to previous. eg. the password needed for database B can no longer be retrieved.

Another backup was run on Database B, and the log file shows that it is indeed connected. This is verified via v$session as well.

The logging was set to show the connection information. This is what is in the logfile for the user used to backup database B:

  backup_user/_at_b.mydomain.com

Notice that the password is missing.

At the command line:

c:\ rman target backup_user/_at_b.mydomain.com nocatalog Recovery Manager: Release 10.2.0.4.0 - Production on Tue May 26 16:41:35 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.

target database Password:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================

RMAN-00554: initialization of internal recovery manager package failed RMAN-04005: error from target database:
ORA-01005: null password given; logon denied

And yet, the script is able to logon without the password.

It is called by the NetBackup service, which is running as Local System

Though I can now 'fix' the problem, questions remain:

• Why does the script end in error, even though the script connected to the database without the password?
• How is the script able to connect without the target db user password?

I've burned a whole on this now, so I probably won't be pursuing it anymore, even though I would like to know what is actually going on.

Too many other things to attend to.

But, if you think you know what is causing this behavior, please chime in!

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

--
http://www.freelists.org/webpage/oracle-l

Received on Tue May 26 2009 - 18:51:27 CDT