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
# [tape | tape_auto | tape_box | pipe | pipe_auto | pipe_box | disk
# | disk_copy | disk_standby | stage | stage_copy | stage_standby
# | util_file | util_file_online | util_vol | util_vol_online
# | rman_util | rman_disk | rman_stage | rman_prep]
# default: tape
backup_dev_type = disk
# disk copy command [copy | copy_gnu | dd | dd_gnu | rman | rman_gnu
# | 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
Copyright (c) 1982, 2011, Oracle. All rights reserved.
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