Anda di halaman 1dari 10

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

Note Language: English Version: 52 Validity: Valid from 29.10.2008

Summary

Symptom
ORA-01004: default username feature not supported; logon denied
ORA-01017: invalid username/password; logon denied
ORA-01031: insufficient privileges
ORA-01403: no data found
ORA-00942: table or view does not exist
ORA-00980: synonym translation is no longer valid

BR301W SQL error -1017 at location BrDbConnect-1


BR310W Connect to database instance <sid> failed

More Terms

Cause and Prerequisites


Important: This note does NOT provide information about configuring the
OPS$ user for Java-based applications. These do not use an OPS$ user as
standard. However, if you still require an OPS$ user to execute BR*TOOLS,
you can create it in the context of the sapdba_additional.sql script as
described in Note 675940 (6.40 WINDOWS), Note 668604 (6.40 UNIX), and Note
849141 (NW2004S WINDOWS). Generally, you do not have to create the table
SAPUSER and the SAP passwords that are stored in it in Java systems.

R/3 work processes and R/3 tools such as R3trans often require the option
to use the user sapr3 to connect to the database. This can be achieved in
one of the following ways:

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>"

2. If the default password "sap" is still set for sapr3: direct logon to
the database using "connect sapr3/sap@<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

However, in the following three situations, using OPS$ to connect would


fail:

05.02.2009 Page 1 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

OS user: c11adm orac11 c11adm


os_authent_prefix: ops ops$ ops$
DB user: ops$c11adm ops$c11adm ops$prdadm

You can also create more than one OPS$ user in the database.

On NT with Oracle 8.1.5 or higher, ensure that the OPS$ user also contains
the domain name (or the local host, if the database server does not belong
to any domain): OPS$<domain>\<os_user> You can use the WINDOWS environment
variable USERDOMAIN to determine the required domain name or host name.

If the system connected successfully in accordance with 1a) and 1b), the
corresponding log file (for example dev_wX or trans.log) contains the
following entries:

Logon as OPS$-user to get SAPR3's password


Connecting as /@<sid> on connection 0 ... <-- 1a)
Now I'm connected to ORACLE
Got SAPR3's password from table SAPUSER
Disconnecting from connection 0 ...
Now I'm disconnected from ORACLE
Try to connect with the password I got from OPS$-user
Connecting as SAPR3/<pwd>@<sid> on connection 0 ... <-- 1b)
Now I'm connected to ORACLE

If connecting using 1a) and 1b) is not possible, but alternative 2 works,
the log will look as follows:

Logon as OPS$-user to get SAPR3's password <-- 1a)


Connecting as /@<sid> on connection 0 ...
*** ERROR => OCI-call 'olog' failed: rc = 1017 <-- Error!
*** ERROR => CONNECT failed with sql error '1017'
Try to connect with default password
Connecting as SAPR3/<pwd>@<sid> on connection 0 ... <-- 2;
C Now I'm connected to ORACLE

Ensure that the penultimate line looks exactly as in the first example,
even though the sapr3 password from the table SAPUSER was used in the first
case and the standard password "sap" was used in the second case. The
preceding line, which specifies which of the passwords is used to connect,
is important here.

If one of the two connection methods fails, this is generally not a


problem, as long as the other method works. That is, to ensure that the
system connects successfully, either the standard password for sapr3 must
be set, or the mechanism using the OPS$ user must be set up correctly.

Note that the log messages may vary slightly in different R/3 releases. In
addition, the reverse sequence was valid with earlier R/3 releases: first
the system used the standard password to connect and the OPS$ mechanism was
used only if that failed.

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

05.02.2009 Page 2 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

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.

As of R/3 6.10, you CAN also use an alternative user setup and an
alternative tablespace setup. The most important change in this regard is
the use of the SID-dependent SAP<sid> instead of the user SAPR3. You can
use the following query to determine the user to which the R/3 objects
actually belong:

SELECT OWNER FROM DBA_TABLES WHERE TABLE_NAME = 'T000';

The reason for this change is to provide the option to keep several R/3
systems with different SIDs in one database where each system requires its
own user. If the new layout is used, SAPR3 is no longer used even for the
connect, but SAP<sid> is used. To ensure that R3trans / saplicense and the
work processes also recognize this, you must set the following environment
variable:

dbs_ora_schema = SAP<sid>

In particular, you must ensure that "SAP<sid>" is written only in


uppercase. With 6.10, the log entries described above have also slightly
changed. However, the basic mechanism remains and you can easily map the
new entries in trans.log or in the dev traces to the logs described in this
note.

The user is also affected by the variable auth_shadow_upgrade = 1 which, in


an upgrade with access to the shadow instance, switches the normal user
"sapr3" to "sapr3shd".
This variable must NEVER (not even during an upgrade) be set in the
environment or in the registry.

Solution
Execute all of the specified SQL statements as ora<sid> (UNIX) or <sid>adm
(NT) with SQLPLUS and "CONNECT / AS SYSDBA".

On NT with Oracle 8.1.5 or higher, add the domain (for example,


OPS$<domain>\<sid>ADM instead of OPS$<sid>ADM) at all points in which the
OPS$ user occurs in the following SQL commands. If the user is a non-domain
user, the name of the local host replaces the domain name.

05.02.2009 Page 3 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

Below, <sapowner> indicates the owner of the R/3 tables, that is, SAPR3 or
SAP<sid> (depending on the setup).

General checks

o Check whether creating the OPS$ mechanism in accordance with to


Note 50088 (WINDOWS) or Note 361641 (UNIX) solves the problem.

o 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>');

o This section applies particularly to NT. However, if more than one


OPS$ user is also used on UNIX, you must perform the checks there
at the same time.

On NT, the user sapservice<sid> must also be able to access the


table SAPUSER. In order to avoid data-consistency problems, it does
not make sense to create an additional SAPUSER table that has the
same contents. Instead, you should specify a synonym. Use the
following command to check whether a suitable synonym exists:

SELECT OWNER, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS


WHERE SYNONYM_NAME = 'SAPUSER';

This call should return either OPS$SAPSERVICE<sid> or PUBLIC as the


first value, followed by OPS$<sid>ADM and SAPUSER. If this is not
the case, recreate the synonym after you have deleted it:

If PUBLIC is returned as the first value:

DROP PUBLIC SYNONYM SAPUSER;

If another name <name> is returned as the first value:

DROP SYNONYM "<name>".SAPUSER;

You can now recreate the synonym (if possible, not PUBLIC):

CREATE SYNONYM "OPS$SAPSERVICE<sid>".SAPUSER FOR


"OPS$<sid>ADM".SAPUSER;

05.02.2009 Page 4 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

To allow access to the synonym (or the associated table), you must
execute a grant. Only the OPS$ user to whom the table belongs has
authorization to do this (in this case, OPS$<sid>ADM). Therefore,
you must logon using the relevant operating system user (<sid>adm)
and execute the following lines:

CONNECT /
GRANT SELECT, UPDATE ON SAPUSER TO "OPS$SAPSERVICE<sid>";

o By default, R3trans uses SAPR3 as the database user. However, you


can use the environment variable to specify another database user.
This makes particular sense with R/3 6.x, if SAPR3 is replaced by
SAP<sid>. In R/3 4.x or lower, if dbs_ora_schema is set to a value
other than SAPR3, the connection fails since this user does not
exist in the database or in the table SAPUSER. As a result, errors
such as ORA-01403 or ORA-01017 occur. Up to and including 4.6D,
dbs_ora_schema must not be set in any user environment.

ORA-01004: default username feature not supported; logon denied

The OPS$ mechanism is not activated in Oracle. To provide the general OPS$
connection option, proceed as follows:

o Set the following parameter:

REMOTE_OS_AUTHENT = TRUE

in init<sid>.ora.

o Restart the database.

On Windows, you must also set the parameter SQLNET.AUTHENTICATION_SERVICE =


(NTS) in sqlnet.ora.

ORA-01017: invalid username/password; logon denied

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:

o Check whether the parameter

05.02.2009 Page 5 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

os_authent_prefix = ops$

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


restart the database afterwards.

o On Windows, ensure that the following parameter is set in


sqlnet.ora:

SQLNET.AUTHENTICATION_SERVICES = (NTS)

o 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.

o Use SVRMGRL to check whether the user OPS$<os_user> (or


OPS$<domain>\<os_user> for NT with Oracle 8.1.5 or higher) has been
created at database level:

SELECT * FROM DBA_USERS WHERE USERNAME = 'OPS$<os_user>';


(always enter <os_user> in uppercase).

o If the system does not return an entry, create the user:

CREATE USER "OPS$<os_user>" DEFAULT TABLESPACE <user_tsp>


TEMPORARY TABLESPACE PSAPTEMP IDENTIFIED EXTERNALLY;

Ensure that the name of the OPS$ user is specified entirely in


uppercase (also the host name and the domain name in the case of NT
and W2K). If you do not do this, you will not be able to logon as
the OPS$ user.

Incorrect: CREATE USER "OPS$c11adm" DEFAULT TABLESPACE ...


CREATE USER "OPS$sapdom\C11ADM" DEFAULT TABLESPACE ...
Correct: CREATE USER "OPS$C11ADM" DEFAULT TABLESPACE ...
CREATE USER "OPS$SAPDOM\C11ADM" DEFAULT TABLESPACE ...

The tablespace <user_tsp> is used when you create new objects if


you do not specify an explicit tablespace name. In connection with
R/3, this is almost never the case. Therefore, you can specify any
tablespace. Proposal:

R/3 4.6D or lower: <user_tsp> = PSAPUSER1D


R/3 6.10 or higher: <user_tsp> = PSAP<sid>USR

o Check whether the OPS$ user has sufficient authorizations. The


following statement must return at least CONNECT and RESOURCE:

SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS


WHERE GRANTEE = 'OPS$<os_user>';

If CONNECT or RESOURCE is missing, you can grant these


authorizations as follows:

GRANT CONNECT, RESOURCE TO "OPS$<os_user>";

05.02.2009 Page 6 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

o On NT or Windows 2000, if you have made all of the settings


described above correctly but the system continues to issue error
ORA-01017 during the OPS$ connection, the start user for the SAP
service may be set incorrectly. Switch to the services overview of
the operating system and check the user that starts the service
SAP<sid>_<instance_number>. If the user is not sapservice<sid>,
enter sapservice<sid>. Other users (such as the local
administrator) do not have an OPS$ user in the database. Therefore,
the system issues ORA-01017. In addition, you must check whether
the starting user sapservice<sid> is a local user or a domain user.
Domain users can be identified by the preceding domain name.
Depending on this, the following OPS$ user must exist at database
level:

- Domain user: <domain>\sapservice<sid>


OPS$ user: OPS$<domain>\sapservice<sid>

- Local user: sapservice<sid>


OPS$ user: OPS$<local_host>\sapservice<sid>

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


Connecting as /@<sid> on connection 0 ...
Now I'm connected to ORACLE
Got <sapowner>'s password from table SAPUSER
Disconnecting from connection 0 ...
Now I'm disconnected from ORACLE
Try to connect with the password I got from OPS$-user
Connecting as <sapowner>/<pwd>@<sid> on connection 0
*** ERROR => OCI-call 'olog' failed: rc = 1017
*** ERROR => CONNECT failed with sql error '1017'

If the system issues ORA-01017 at this point, the <sapowner>


password in the table SAPUSER is incorrect. In this situation,
proceed as follows:

o Use the following BRCONNECT call (BRCONNECT 6.10 or higher) to set


the password consistently in SAPUSER and in the Oracle DDIC:

brconnect -u system/<password> -f chpass -o <sapowner> -p


<password>

o Alternatively, change the password in the table SAPUSER:

DELETE FROM "OPS$<sid>ADM".SAPUSER;


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

Important: The table SAPUSER must exist only once in each system
for OPS$<sid>ADM. For this reason, execute the statements mentioned
above for OPS$<sid>ADM (regardless of the operating system user
that is actually being used). All other OPS$ users can use a
synonym to access the table SAPUSER.

o If the connection still terminates in the same way, check the


"General checks" section once again.

2) Log entries: Try to connect with default password

05.02.2009 Page 7 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

Connecting as <sapowner>/<pwd>@<sid> on connection 0


*** ERROR => OCI-call 'olog' failed: rc = 1017
*** ERROR => CONNECT failed with sql error '1017'

o If you want to use the standard password "sap" and do not need the
OPS$ mechanism, reset the <sapowner> password to "sap":

ALTER USER <sapowner> IDENTIFIED BY sap;

o If you do not want to use the standard password, you cannot avoid
the error at this stage. Instead, you must set up the OPS$
mechanism as described above.

o If the error ORA-01017 occurs when you set up a secondary database


connection, see Note 569302.

ORA-01031: insufficient privileges

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


Connecting as /@<sid> on connection 0 ...
Now I'm connected to ORACLE
*** ERROR => ORA-1031 when accessing table SAPUSER

Check whether the grants (especially SELECT) on SAPUSER are set correctly
for the OPS$ user as described in the "General checks" section above.

ORA-01403: no data found

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


Connecting as /@<sid> on connection 0 ...
Now I'm connected to ORACLE
*** ERROR => ORA-1403 when accessing table SAPUSER

The main cause of ORA-01403 is that the table SAPUSER does not contain any
entries. Therefore, proceed as follows:

o Use the following BRCONNECT call (BRCONNECT 6.10 or higher) to set


the password consistently in SAPUSER and in the Oracle DDIC:

brconnect -u system/<password> -f chpass -o <sapowner> -p


<password>

o Alternatively, you can insert it in SAPUSER manually.

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


'<password>');

Another possible cause is that SAPUSER contains incorrect entries. The


system always uses the user name to select from SAPUSER. Therefore, you
must ensure that the user name is always uppercase (SAPR3 or SAP<sid>) and
that it corresponds exactly to the value of the environment variable
dbs_ora_schema if SAP<sid> is used.

o If the system continues to issue ORA-01403, see the "General


checks"section once again.

05.02.2009 Page 8 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

ORA-00942: table or view does not exist

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


Connecting as /@<sid> on connection 0 ...
Now I'm connected to ORACLE
*** ERROR => ORA-942 when accessing table SAPUSER

The system issues message ORA-00942 if the table SAPUSER does not exist.
Therefore, proceed as follows:

o Use the following command to create the table SAPUSER as <sid>adm:

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


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

o If the error still occurs, see the "General checks" section once
again.

ORA-00980: synonym translation is no longer valid

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


Connecting as /@<sid> on connection 0 ...
Now I'm connected to ORACLE
*** ERROR => ORA-980 when accessing table SAPUSER

The system issues ORA-00980 if a synonym for SAPUSER exists but is no


longer valid for some reason (for example, because it refers to an object
that does not exist).

Therefore, you must create the synonym for SAPUSER again as described in
the "General checks" section above.

Attention: Do not enter source code here! Enter source code under
"Corrections" -> "Correction instructions".
Lines entered here are deleted automatically when saving!

Header Data
Release Status: Released for Customer
Released on: 29.10.2008 07:27:35
Priority: Recommendations/additional info
Category: Help for error analysis

Main Component BC-DB-ORA Oracle


Additional Components:
BC-DB-ORA-DBA Database Administration with Oracle

05.02.2009 Page 9 of 10
Note 400241 - Problems with ops$ or sapr3 connect to Oracle

The note is not release-dependent.

Related Notes
Number Short Text
969519 6.20/6.40 Patch Collection Installation : Oracle/UNIX
951167 ORA-28000: the account is locked
700548 FAQ: Oracle authorizations
675940 SAP Web AS 6.40 Installation on Windows: Oracle
662644 Composite SAP Note: ORA-00942
650796 Composite Note: ORA-00980
569302 Loading data in BW fails with ORA-01017
562863 FAQ: Logon mechanisms
437648 DB13: External program terminated with exit code 1/2
403004 Database connect using R3trans fails
361641 Creating OPS$ users on UNIX
134592 Importing the SAPDBA role (sapdba_role.sql)

Attributes
Attribute Value
Database system ORACLE

05.02.2009 Page 10 of 10