Error ORA-01017 running BRBACKUP on RAC+ASM on Lin...

Former Member · ‎06-29-2013

Hello SAP Experts,

We are having an error (ORA-01017: invalid username/password; logon denied) trying to run the BRBACKUP from the BRTOOLS with the <sid>adm user on Oracle ASM+RAC. The OPS$ mechanism doesn't working correctly.

srv-prd01:prdadm 53> brtools

BR0651I BRTOOLS 7.20 (28)

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.27

BR0656I Choice menu 1 - please make a selection

-------------------------------------------------------------------------------

BR*Tools main menu

1 = Instance management

2 - Space management

3 - Segment management

4 - Backup and database copy

5 - Restore and recovery

6 - Check and verification

7 - Database statistics

8 - Additional functions

9 - Exit program

Standard keys: c - cont, b - back, s - stop, r - refr, h - help

-------------------------------------------------------------------------------

BR0662I Enter your choice:

4

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.36

BR0663I Your choice: '4'

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.36

BR0656I Choice menu 9 - please make a selection

-------------------------------------------------------------------------------

Backup and database copy

1 = Database backup

2 - Archivelog backup

3 - Database copy

4 - Non-database backup

5 - Backup of database disk backup

6 - Verification of database backup

7 - Verification of archivelog backup

8 - Additional functions

9 - Reset program status

Standard keys: c - cont, b - back, s - stop, r - refr, h - help

-------------------------------------------------------------------------------

BR0662I Enter your choice:

1

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.37

BR0663I Your choice: '1'

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.37

BR0657I Input menu 15 - please enter/check input values

-------------------------------------------------------------------------------

BRBACKUP main options for backup and database copy

1 - BRBACKUP profile (profile) ....... [initPRD.sap]

2 - Backup device type (device) ...... [disk]

3 # Tape volumes for backup (volume) . []

4 # BACKINT/Mount profile (parfile) .. []

5 - Database user/password (user) .... [system/*******]

6 - Backup type (type) ............... [online]

7 # Disk backup for backup (backup) .. [no]

8 # Delete disk backup (delete) ...... [no]

9 ~ Files for backup (mode) .......... [all]

Standard keys: c - cont, b - back, s - stop, r - refr, h - help

-------------------------------------------------------------------------------

BR0662I Enter your choice:

c

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.39

BR0663I Your choice: 'c'

BR0259I Program execution will be continued...

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.39

BR0657I Input menu 16 - please enter/check input values

-------------------------------------------------------------------------------

Additional BRBACKUP options for backup and database copy

1 - Confirmation mode (confirm) ....... [yes]

2 - Query mode (query) ................ [no]

3 - Compression mode (compress) ....... [no]

4 - Verification mode (verify) ........ [no]

5 - Fill-up previous backups (fillup) . [no]

6 - Parallel execution (execute) ...... [0]

7 - Additional output (output) ........ [no]

8 - Message language (language) ....... [E]

9 - BRBACKUP command line (command) ... [-p initPRD.sap -d disk -t online -m all -k no -e 0 -l E]

Standard keys: c - cont, b - back, s - stop, r - refr, h - help

-------------------------------------------------------------------------------

BR0662I Enter your choice:

c

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.40

BR0663I Your choice: 'c'

BR0259I Program execution will be continued...

BR0291I BRBACKUP will be started with options '-p initPRD.sap -d disk -t online -m all -k no -e 0 -l E'

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.40

BR0670I Enter 'c[ont]' to continue, 'b[ack]' to go back, 's[top]' to abort:

c

BR0280I BRTOOLS time stamp: 2013-05-28 21.44.41

BR0257I Your reply: 'c'

BR0259I Program execution will be continued...

###############################################################################

BR0051I BRBACKUP 7.20 (28)

BR0055I Start of database backup: belhnuab.and 2013-05-28 21.44.41

BR0484I BRBACKUP log file: /oracle/PRD/sapbackup/belhnuab.and

BR0280I BRBACKUP time stamp: 2013-05-28 21.44.41

BR0301E SQL error -1017 at location BrDbConnect-2, SQL statement:

'CONNECT system/*******'

ORA-01017: invalid username/password; logon denied

BR0310E Connect to database instance PRD001 failed

BR0280I BRBACKUP time stamp: 2013-05-28 21.44.41

BR0301E SQL error -1017 at location BrDbConnect-2, SQL statement:

'CONNECT system/*******'

ORA-01017: invalid username/password; logon denied

BR0310E Connect to database instance PRD001 failed

BR0056I End of database backup: belhnuab.and 2013-05-28 21.44.41

BR0280I BRBACKUP time stamp: 2013-05-28 21.44.41

BR0054I BRBACKUP terminated with errors

------------------------------- END OF ERROR -------------------------------

Our ERP PRD system is on Oracle ASM+RAC on Linux. We configured the BRTOOLS according to the following OSS Notes:

---> SAP Note 1627541 - BR*Tools support for Oracle ASM and Exadata

3.1 Backup, Restore, Recovery

-----------------------------

ASM database files (data files and archive log files) can only be backed up with Oracle Recovery Manager (RMAN). For this reason, BR*Tools only support

the following backup types in the ASM environment:

backup_dev_type = rman_util | rman_disk | rman_stage

backup_dev_type = disk

disk_copy_cmd = rman | rman_set

backup_dev_type = tape | pipe

tape_copy_cmd = rman

Our System:

# backup device type

# | util_file | util_file_online | util_vol | util_vol_online

# | rman_util | rman_disk | rman_stage | rman_prep]

# default: tape

backup_dev_type = disk

# | rman_set | rman_set_gnu | ocopy]

# default: copy

disk_copy_cmd = rman

---> SAP Note 1598594 - BR*Tools configuration for Oracle inst. under "oracle" user

I. Common prerequisites and configuration of the BR*Tools for Oracle installations under the UNIX user "oracle" for non-ASM and ASM

2. Required version of BR*Tools

Only BR*Tools 7.20 patch level 14 or higher can be used in this environment without ASM. BR*Tools 7.20 patch level 18 includes full support for Oracle

ASM (see Note 1627541).

Our system:

srv-prd01:prdadm 51> brtools -version

BR0651I BRTOOLS 7.20 (28)

Patch Date Info

1 2010-01-26 BR*Tools support for Oracle 11g (note 1430669)

9 2010-10-27 BR*Tools support for eSourcing databases (note 1523205)

18 2011-09-07 BR*Tools support for Oracle ASM and Exadata (note 1627541)

25 2012-06-28 Corrections in BR*Tools 7.20 patch 25 (note 1735811)

26 2012-09-12 Corrections in BR*Tools 7.20 patch 26 (note 1763972)

27 2012-09-12 Support for secure storage in BR*Tools (note 1764043)

28 2012-10-25 Corrections in BR*Tools 7.20 patch 28 (note 1780057)

release note 1428529

kernel release 720

patch date 2012-10-25

patch level 28

make platform linuxx86_64

make mode OCI_102

make date Nov 10 2012

3. Configuration of the BR executables

BR*Tools are installed in the "sap-exe" directory (default: /usr/sap/<SAPSID>/SYS/exe/run) and have the following permissions (note the owner and S-

Bits):

-rwsrwsr-- 1 oracle oinstall 7732338 May 31 16:30 brarchive

-rwsrwsr-- 1 oracle oinstall 7908129 May 31 16:30 brbackup

-rwsrwsr-- 1 oracle oinstall 9970354 May 31 16:30 brconnect

-rwsrwsr-- 1 oracle oinstall 8376747 May 31 16:31 brrecover

-rwsrwsr-- 1 oracle oinstall 2783544 May 31 16:31 brrestore

-rwsrwsr-- 1 oracle oinstall 10479944 May 31 16:31 brspace

-rwxr-xr-x 1 <sid>adm sapsys 4103679 May 31 16:31 brtools

Our system:

[root@srv-prd01 ~]# cd /usr/sap/PRD/SYS/exe/run

[root@srv-prd01 run]# ls -l br*

-rwsrwsr-x 1 oracle oinstall 9377368 Nov 12 2012 brarchive

-rwsrwsr-x 1 oracle oinstall 9504899 Nov 12 2012 brbackup

-rwsrwsr-x 1 oracle oinstall 11385238 Nov 12 2012 brconnect

-rwsrwsr-x 1 oracle oinstall 9960168 Nov 12 2012 brrecover

-rwsrwsr-x 1 oracle oinstall 6308418 Nov 12 2012 brrestore

-rwsrwsr-x 1 oracle oinstall 11817020 Nov 12 2012 brspace

-rwxrwxrwx 1 prdadm sapsys 6886755 Nov 12 2012 brtools

The "SAPEXE" environment variable points to this directory. For example: SAPEXE = /usr/sap/PRD/SYS/exe/run

Our system:

srv-prd01:prdadm 52> echo $SAPEXE

/usr/sap/PRD/SYS/exe/run

4. Sapdata home directory

The Sapdata home directory (default: /oracle/<DBNAME>) contains the Oracle home directory and the BR*Tools log directories (note the permissions) among

other things.

lrwxrwxrwx 7 oracle oinstall 4096 May 31 14:56 112 -> 11202

drwxr-xr-x 7 oracle oinstall 4096 May 31 14:56 11202

drwxrwxr-x 2 oracle oinstall 4096 May 31 17:07 saparch

drwxrwxr-x 2 oracle oinstall 4096 May 31 17:14 sapbackup

drwxrwxr-x 2 oracle oinstall 4096 May 31 17:07 sapcheck

drwxrwxr-x 2 oracle oinstall 4096 May 31 17:12 sapprof

drwxrwxr-x 2 oracle oinstall 4096 May 31 17:12 sapreorg

drwxrwxr-x 2 oracle oinstall 4096 May 31 17:12 saptrace

Our system:

lrwxrwxrwx 1 oracle oinstall 5 Dec 8 20:02 112 -> 11203

drwxrwxr-x 83 oracle oinstall 12288 Jan 29 16:03 11203

drwxrwxrwx 3 oracle oinstall 3896 Mar 13 17:03 saparch

drwxrwxrwx 4 oracle oinstall 3896 May 28 21:44 sapbackup

drwxrwxrwx 3 oracle oinstall 3896 May 26 21:53 sapcheck

drwxrwxrwx 4 oracle oinstall 3896 May 27 08:15 sapprof

drwxrwxrwx 3 oracle oinstall 3896 Mar 13 17:03 sapreorg

drwxr-xr-x 7 oracle oinstall 3896 Dec 2 01:18 saptrace

6. Runtime environment of BR*Tools

All BR*Tools programs are started only under the OS user <sapsid>adm. Use the environment variables ORACLE_SID and ORACLE_HOME (plus ORACLE_BASE if

necessary) to define the DB instance uniquely for this user. Under the user "oracle", you must set these environment variables and BR*Tools-specific

variables (such as SAPDATA_HOME) before you start BR*Tools. (For more information, see Note 1554661.) You must no longer execute BR*Tools under the OS

user ora<dbname>. You can delete the user ora<dbname>.

Important: In the ASM/RAC environment, you must use the OS user <sapsid>adm to start BR*Tools if several RAC database instances are located on one node

and if BRBACKUP or BRARCHIVE are to be started without a password (see Note 914174, page 4.). In this configuration, BR*Tools execute internal actions on

the remote nodes. These actions would then fail under the "oracle" user due to an incorrect environment.

Our System:

srv-prd01:prdadm 57> echo $ORACLE_SID

PRD001

srv-prd01:prdadm 58> echo $ORACLE_HOME

/oracle/PRD/112

srv-prd01:prdadm 59> echo $ORACLE_BASE

/oracle/BASE

7. OPS$ORACLE database user

If the user OPS$ORACLE does not exist, create it in the database as follows:

SQL> connect / as sysdba

SQL> create user ops$oracle identified externally;

SQL> grant sapdba to ops$oracle;

Our system:

The oracle user exist in the database with the SAPDBA role:

SQL> select USERNAME from dba_users where USERNAME='OPS$ORACLE';

USERNAME

------------------------------

OPS$ORACLE

SQL> SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'OPS$ORACLE';

GRANTED_ROLE

------------------------------

SAPDBA

CONNECT

III. Additional prerequisites and configuration of the BR*Tools for Oracle installations under the UNIX user "oracle" for ASM

1. Group assignment of<sapsid>adm OS user

In addition to the standard groups (such as sapsys, dba, oper, sapinst), <sapsid>adm also belongs to the OS groups "asmdba", "asmoper", and "oinstall".

srv-prd01:prdadm 61> more /etc/passwd

prdadm:x:501:506::/home/prdadm:/bin/csh

srv-prd01:prdadm 63> more /etc/group

asmdba:x:504:oracle,prdadm,oraprd

asmoper:x:505:oracle,prdadm,oraprd

oinstall:x:501:prdadm

2. Parameters for ASM installations

For ASM installations, set the following parameters in the init<DBSID>.sap profile (adjust the entries):

# Oracle system id of ASM instance

# default: +ASM

asm_ora_sid = +ASM

# Oracle home of ASM instance

# no default

asm_ora_home = /oracle/GRID/11202

# Oracle ASM root directory name

# default: ASM

asm_root_dir = ASM

For ASM/RAC installations, asm_ora_sid and asm_ora_home can be defined for each instance:

asm_ora_sid = (<db_inst1>:<asm_inst1>, <db_inst2>:<asm_inst2>, ...)

asm_ora_home = (<db_inst1>:<asm_home1>, <db_inst2>:<asm_home2>, ...)

For example:

asm_ora_sid = (RAC001:+ASM1, RAC002:+ASM2, RAC003:+ASM3, RAC004:+ASM4)

asm_ora_home = (RAC001:/oracle/GRID/11203, RAC002:/oracle/GRID/11203, RAC003:/oracle/GRID/11202, RAC004:/oracle/GRID/11202)

Our system:

# Oracle system id of ASM instance

# default: +ASM

asm_ora_sid = (PRD001:+ASM1, PRD002:+ASM2)

# Oracle home of ASM instance

# no default

asm_ora_home = (PRD001:/oracle/GRID/11203, PRD002:/oracle/GRID/11203)

# Oracle ASM root directory name

# default: ASM

asm_root_dir = ASM

------------------------------- END OF BRTOOLS Configuration Notes -------------------------------

Troubleshooting trough SAP Notes:

---> Note 131610 - Database logon using standby/backup machine or Oracle RAC

Symptom

A BRBACKUP call on the standby database host or on the backup host in the split mirror disk scenario (without database password), as follows, fails:

The system outputs the following error messages:

BR278E Command output of '/oracle/C11/bin/sqlplus':

...

SQL> ORA-01017: invalid username/password; logon denied

SQL> ORA-01012: not logged on

1. Create an Oracle password file:

Unix:

orapwd file=$ORACLE_HOME/dbs/orapw<DBSID> password=<internal_password> entries=10

Windows:

orapwd file=%ORACLE_HOME%\database\PWD<DBSID>.ORA password=<internal_password> entries=10

Caution:

For RAC installations, omit <DBSID> from the name of the password file. The name of the file is restricted to "orpaw" in Unix and to "PWD.ORA" in

Windows.

Our System: The orapw file exist:

srv-prd01:prdadm 65> cd $ORACLE_HOME/dbs

srv-prd01:prdadm 66> ll

-rw-r----- 1 oracle oinstall 2560 May 18 12:06 orapw

2. Enter the following parameter in the init<DBSID>.ora Oracle profile or in the Spfile:

remote_login_passwordfile = exclusive

Our system:

SQL> show parameter remote_login_passwordfile;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

remote_login_passwordfile string EXCLUSIVE

3. Assign SYSOPER authorization to <User> (SYSTEM):

SQL> connect / as sysdba

SQL> grant sysoper to system;

You can also assign SYSDBA authorization to <User> (SYSTEM), if you so wish:

SQL> grant sysdba to system;

This authorization is obligatory during split-mirror backups of a standby database and for RAC databases.

SQL> connect / as sysdba

Connected.

SQL> grant sysoper to system;

Grant succeeded.

SQL> grant sysdba to system;

Grant succeeded.

Caution 3:

----------

See point 4 in Note 914174 for a description of a workaround that allows you to start BR*Tools without specifying a password in these configurations too.

---> Note 408000 - Starting BR* tools and SAPDBA without specifying a password

Caution:

========

An important option for creating backups from remote databases without specifying a password is described in Note 914174 under point 4.

Our System:

Was configured to use the OPS$ mechanism, but in the brtools steps the display the system/password option. The 408000 OSS note says "The OPS$ mechanism

is already activated for the Unix and NT user <sid>adm."

---> Note 914174 - Minor functional enhancements in BR*Tools

4. Backups of RAC databases without password specification

---------------------------------------------------------

It is usually necessary to always specify a database user and password in the option "-u" (for example, "-u system/<password>") on Unix systems, when

backing up RAC databases using BRBACKUP and BRARCHIVE or during offline split-mirror backups using BRBACKUP. A backup with the OPS$ user (" -u / ") was

not possible due to Oracle restrictions (these restrictions do not apply to Windows systems).

BRBACKUP and BRARCHIVE (see the patch levels specified under "Solution") can now carry out backups of remote databases with the OPS$ user on Unix

systems. The prerequisite for this is a remote/secure shell access without specifying a password to all other RAC nodes from the node on which BRBACKUP

or BRARCHIVE is started. Configure the remote shell (.rhosts file) or the secure shell on the nodes accordingly.

Important: For RAC databases as of Oracle 11g, where we have to deal with the new Oracle software owner "oracle" (see SAP Note 1598594), the remote shell

connection or secure shell connection without a password between "<sid>adm", "oracle", and "oracle" -> "<sid>adm" must work on all RAC nodes.

To activate the new function, set the following environment variable:

BR_RSC = 1

Alternatively, you can use the command option "-RSC" or the following init<DBSID>.sap special parameter for BRBACKUP and BRARCHIVE. _rem_sql_call = yes

If you want to use the secure shell/copy, configure the secure shell for a command execution without a password, and set the following environment

variables, for example:

BR_RSH_CMD = /usr/am/ssh

BR_RCP_CMD = /usr/bin/scp

Alternatively, you can use the following init<DBSID>.sap special parameters:

_remote_exec = ssh

_remote_copy = scp

This also allows standard backups using transaction DB13.

Our system:

srv-prd01:prdadm 68> echo $BR_RSC

1

srv-prd01:prdadm 69> echo $BR_RSH_CMD

/usr/bin/ssh

srv-prd01:prdadm 70> echo $BR_RCP_CMD

/usr/bin/scp

Additional, in the init<DBSID>.sap we added the special parameters:

_remote_exec = ssh

_remote_copy = scp

---> Note 776505 - BR*Tools fail with ORA-01017 / ORA-01031 on Linux

Symptom

1. BRBACKUP, BRARCHIVE, or BRCONNECT, started under the <sid>adm user when using the OPS$ connection (option "-u /"), terminate on Linux with the

following error messages:

BR0301E SQL error -1017 at location BrDbConnect-2

ORA-01017: invalid username/password; logon denied

BR0310E Connect to database instance QO1 failed

eason and Prerequisites

The BR executables are assigned an s-bit. The problem is related to the special processing of the s-bit by Linux operating systems.

1. The problem does not occur if the BR*Tools are called with the SYSTEM database user, for example:

brbackup -u SYSTEM/<password> -q

Solution

1. Although the BR*Tools are called under the Linux user <sid>adm, the relevant database user for the OPS$ connection must be called OPS$ORA<SID>. If it

does not exist yet, create it as follows:

sqlplus /nolog

SQL> connect / as sysdba

SQL> create user ops$ora<sid> identified externally temporary tablespace psaptemp;

SQL> grant connect, sapdba to ops$ora<sid>;

Our System:

SQL> SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'OPS$ORAPRD';

GRANTED_ROLE

------------------------------

SAPDBA

CONNECT

---> Note 905359 - Using BR*Tools for Oracle RAC databases

8. On Unix systems, BR*Tools use a shared Oracle password file named "orapw" (not orapw<DBSID>) as standard for remote database connection. All RAC instances use this password file. For more information, see Note 131610.

Our System: This is the orapw file, above was displayed.

9. If you want to use the Oracle password file described above in Unix systems, you should set the option "-u <user>/<password>" with a specific user (for example, SYSTEM) when you call BR* tools (see Note 131610). You can avoid this with BRARCHIVE, BRBACKUP and BRCONNECT, but not with BRSPACE and BRRECOVER. You can find more information about this in Note 914174 point 4. As is the case for standard installations BRSPACE, BRRESTORE and BRRECOVER can only be called on Unix under ora<dbsid>.

Our System: This is the OPS$ mechanism, above was displayed.

---> Note 400241 - Problems with ops$ or sapr3 connect to Oracle

Customer message: In this OSS note we can validate the OPS$ mechanism is correctly configured:

1. Connect via OPS$ user

a) Logon using the OPS$ user ("connect /@<sid>") to determine the sapr3 password that is stored in the database table SAPUSER.

b) Logon as sapr3 using the password specified if 1a) was successful: "connect sapr3/<password>@<sid>"

Therefore, the OPS$ user is a safety mechanism, which allows a password stored in the database for sapr3 to be determined. This can then be used in the next step for the actual logon to the database using sapr3. The system can connect using the OPS$ user ("connect /@<sid>") only if a user which is created from the concatenation of OS_AUTHENT_PREFIX = ops$ (see init<sid>.ora) and the name of the operating system user being used exists in the database. For example:

OS user: c11adm

OS_AUTHENT_PREFIX: ops$

DB user: ops$c11adm

Our System:

srv-prd01:prdadm 52> sqlplus /

SQL*Plus: Release 11.2.0.3.0 Production on Tue May 28 21:14:38 2013

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Data Mining and Real Application Testing options

SQL> connect /@PRD001

Connected.

SQL> connect /@PRD002

Connected.

SQL> connect sapsr3/<password>@PRD001

Connected.

SQL> connect sapsr3/<password>@PRD002

Connected.

SQL> CONNECT / AS SYSDBA;

Connected.

SQL> show parameter OS_AUTHENT_PREFIX;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

os_authent_prefix string ops$

Note 50088 (NT) and Note 361641 (UNIX) describe ways of setting up the OPS$ mechanism. However, problems often occur that cannot be corrected without background knowledge of the available tools. For this reason, a description of common errors and solutions is provided below.

BR*TOOLS such as BRBACKUP, BRCONNECT, and BRRECOVER also use the OPS$ user to access the database if you also specify the option "-u /". This is always the case from R/3 (for example from transaction DB13). However, unlike the R/3 work processes, the system uses the OPS$ user directly rather than using it only to determine the sapr3 password. For this reason, the system executes only step 1a) for these tools (logon as OPS$user). After the OPS$ user is created correctly, you must import the current version of the SAPDBA role as described in Note 134592 to ensure that the BR*TOOLS function correctly.

If the OPS$ user has been set up correctly for the BR*TOOLS, the corresponding operating system user is able to log on using "sqlplus /". In addition, the role SAPDBA must be assigned to the OPS$ user. You can use the following command to check this:

CONNECT / AS SYSDBA;

SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = '<ops$_user>';

The result must contain a line with SAPDBA.

Our system:

SQL> SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'OPS$PRDADM';

GRANTED_ROLE

------------------------------

SAPDBA

CONNECT

SQL> SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'OPS$ORAPRD';

GRANTED_ROLE

------------------------------

SAPDBA

CONNECT

General checks:

The table SAPUSER must occur in the system only once and it must be assigned to the user OPS$<sid>ADM. Use the following query to check this:

SELECT OWNER FROM DBA_TABLES WHERE TABLE_NAME = 'SAPUSER';

If the system returns an owner <owner> other than OPS$<sid>ADM, you must delete the relevant SAPUSER tables:

DROP TABLE "<owner>".SAPUSER;

If the system does not return OPS$<sid>ADM, you must create the table SAPUSER as <sid>adm and enter the password:

CREATE TABLE "OPS$<sid>ADM".SAPUSER

(USERID VARCHAR2(256), PASSWD VARCHAR2(256));

INSERT INTO "OPS$<sid>ADM".SAPUSER VALUES ('<sapowner>', '<password>');

Our System:

SQL> SELECT OWNER FROM DBA_TABLES WHERE TABLE_NAME = 'SAPUSER';

OWNER

------------------------------

OPS$PRDADM

ORA-01017: invalid username/password; logon denied (bold in the oss note)

Message ORA-01017 may occur in step 1a), 1b), or 2). Depending on this, the problem can be solved as follows:

1a) Log entries: Logon as OPS$ user to get <sapowner>'s password

Connecting as /@<sid> on connection 0 ...

*** ERROR => OCI-call 'olog' failed: rc = 1017

*** ERROR => CONNECT failed with sql error '1017'

If you intend to use the standard password for <sapowner> anyway, you can ignore the error message at this point, because the OPS$ mechanism is not required at all and the system connects successfully using <sapowner>/sap. However, note that that BR*TOOLS do require a working OPS$ mechanism when using DB13 to execute.

Otherwise, you must ensure that an appropriate OPS$ user is set up. To do this, proceed as follows:

Check whether the parameter

os_authent_prefix = ops$

is set correctly in init<sid>.ora. If you have to make any changes, restart the database afterwards.

Determine which operating system user <os_user> wants to create the connection. If this is a connection that was initiated from the R/3 System (for example, work process connection, DB13 actions), the system uses the user <sid>adm on UNIX and the user sapservice<sid> on NT. If you manually called the program that executes the connection, the user that you used is decisive.

Customer Message: The test connection was sucessfully displayed at the beginning of the this note.

Thanks in advanced!

Johan Gonzalez

thiago_cavalheiro · ‎06-30-2013

Hi Johan,

Have you tried running the backup with "-u /". Using only the slash for authentication. From the logs we can see that the error is thrown while using system/<password>, that's why I am asking that.

Let me know.

Best regards,

Thiago

Error ORA-01017 running BRBACKUP on RAC+ASM on Linux

Accepted Solutions (0)

Answers (1)

Answers (1)

Re: Redirecting to Build Apps when trying to open ...

Re: Signavio process insights starter pack 1 time ...

SAP API Hub EDMX - Integration suite

Destination error Couldn't check at the moment, pl...

Re: Update task in RAP model API