Upgraded from 12.2.0.1 to 19.3 rman in crontab stopped working

I get the same error running this from the cmd:

 

rman target / catalog rman/secpwd@rcdb

 

rman target /

also gets the same error

I suggest to fix command line first than move on to crontab.

Show the following output:

$ id

Are you using the oracle account?

Does you account have the appropriate privs, e.g. dba.

Are you setting the environment correctly, e.g. :

$ source oraenv <<< ORACLE_SID

(where ORACLE_SID is the actual SID or your target database".

Hi,

What about sqlplus? Any errors there? if not, first I would try only to recreate rman packages:

@$ORACLE_HOME/rdbms/admin/dbmsrman.sql

@$ORACLE_HOME/rdbms/admin/prvtrmns.plb

If same error then try relink rman ( below is also for executables: oracle, exp, imp, sqlldr, tkprof, mig, dbv, orapwd, rman, svrmgrl, ogms, ogmsctl..)

cd $ORACLE_HOME/rdbms/lib

make -f ins_rdbms.mk install

Regards

Please check if $ORACLE_BASE is set correctly (I had that once as ORACLE_BASE was set to ORACLE_HOME instead of ORACLE_BASE).

Also check for the ORABASETAB configuration file in the install subdirectory - there may be a wrong entry inside.

Hi,

can you provide the shell script in total?

How do you set the Oracle Environment for RMAN?

Do you use .oraenv within your script? Do you set all environment variables one by one?

I normally take the SID as first input parameter for my script, so I do  set:

export ORACLE_SID=$1

ORAENV_ASK=NO

. oraenv 1>/dev/null 2>&1

Regards

Joerg

What happened that you have to relink the Oracle binaries? I can't see how upgrading from 12c to 19c would require to relink the Oracle installation. If this indeed made the difference, then I would think you have much bigger problems, such as filesystem corruption. Did you resize any filesystems to perform the upgrade? If yes, then I would consider the system damaged beyond repair and you are going to run into more strange issues.

There seems to be a common misconception to define the Oracle environment in the login scripts, such as .profile or .bashrc. Some people even execute the login scripts to define the shell environment when needed. This is unnecessary and certainly prone to errors.

Btw,

export ORACLE_SID=$1

ORAENV_ASK=NO

. oraenv 1>/dev/null 2>&1

There's no need to export ORACLE_SID since you're source executing oraenv (dot space)

Crontab does not perform a login, hence won't read the user login script. Crontab only knows of /bin and /usr/bin if I recall correctly, hence it is necessary to specify the path to oraenv.

For example:

source /usr/local/bin/oraenv <<< ORCL &>-

I do set in the script

PATH=$PATH:/usr/local/bin

So the path to oraenv is included in the script before oraenv is called.

And there is no login script or something else involved.

And there is no login script or something else involved

I wasn't talking about you but some people apparently do run the login scripts to set the oracle environment, which is of course sub-optimal.

Have you executed the pre-upgrade checks script before upgrading the database from 12.3 to 19.3?

Regards,

Mandar

Hi

DBUA is the worst tool ever when upgrading Oracle database....historically it had many bugs,please upgrade using "manual" method when upgrading in the future (my recommendation).

have you upgraded your recovery catalog after upgrading the database ?

special permissions are required: https://geodatamaster.com/2019/12/17/oracle-19c-rman-recovery-catalog-upgrade-error-rman-07539/