oss note 0400241

8/9/2019 Oss Note 0400241

http://slidepdf.com/reader/full/oss-note-0400241 1/10

8/9/2019 Oss Note 0400241


22.04.2007 of 10

SAP Note Number 400241 - Problems with ops$ or sapr3 connect toOracle OS user: c11adm orac11 c11adm

os_authent_prefix: ops ops$ ops$

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

Of course, it is also possible to create more than one OPS$ user in the

database.

On NT with Oracle 8.1.5 or higher, make sure 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 determine the

domain or host name using the WINDOWS environment variable USERDOMAIN.

If the connect in accordance with 1a) and 1b) was successful, 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 looks 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

Make sure that the penultimate line looks exactly as in the first example,

although the sapr3 password from the SAPUSER table was used in the first

case and the standard password sap in the second case. The preceding line,

which specifies which of the passwords is used for the connect, is

important here.

If one of the two connect methods fails, this is usually not a problem, aslong as the other method works. This mean, to ensure that the connect is

successful, either set the standard password for sapr3 or set up the

mechanism correctly using the OPS$ user.

Note that the log messages may vary slightly in the case of different R/3

releases. Besides, the reverse sequence was valid with earlier R/3

releases: first the connect was carried out using the standard password and

the OPS$ mechanism was only used if that failed.

Notes 50088 (NT) and 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, there nowfollows a collection of typical errors and remedies.

8/9/2019 Oss Note 0400241


22.04.2007 of 10

SAP Note Number 400241 - Problems with ops$ or sapr3 connect toOracleBR*TOOLS such as BRBACKUP, BRCONNECT and BRRECOVER also access the database

using the OPS$ user if you also specify the option "-u /". This is always

the case from R/3 (for example, from Transaction DB13). Unlike the R/3 work

processes, however, the system uses the OPS$ user directly, rather than

only using it to determine the sapr3 password. For this reason, the system

only executes step 1a) for these tools (logon as the OPS$ user). After

correctly creating the OPS$ user, the current version of the SAPDBA role

must be imported (as described in Note 134592) to ensure that the BR*TOOLS

function properly.

If the OPS$ user has been set up correctly or the BR*TOOLS, the

corresponding operating system user should be able to log on using "sqlplus

/". In addition, the OPS$ user must have the SAPDBA role assigned. This can

be checked using the following call:

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 and tablespace setup.

The most important change in this regard is the use of the SID-dependent

SAP<sid> instead of 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 the option if keeping several R/3 systems

with different SIDs in one database where each system naturally needs its

own user. If the new layout is used, SAPR3 is no longer used even for the

connect, but SAP<sid> is used. To make this also known to R3trans /

saplicense and the work processes, the following environment variable must

be set:

dbs_ora_schema = SAP<sid>

In particular, make sure that "SAP<sid>" is written in uppercase letters

only. With 6.10, the log entries described above have also slightly

changed. The basic mechanism remains, however, and you can quite easily map

the new entries in trans.log or in the dev traces to the logs described in

this note.

The user is also influenced by variable auth_shadow_upgrade = 1 which, inan 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.

SolutionExecute all of the SQL statements stated as ora<sid> (UNIX) or <sid>adm

(NT) with SQLPLUS and "CONNECT / AS SYSDBA".

On NT with Oracle >= 8.1.5, complete the domain at all places in the

following SQL commands in which the OPS$ user occurs. For example: OPS$<domain>\<sid>ADM rather than OPS$<sid>ADM. In the case of a non-domain

user, the name of the local host replaces the domain name.

8/9/2019 Oss Note 0400241


22.04.2007 of 10

SAP Note Number 400241 - Problems with ops$ or sapr3 connect toOracleBelow, <sapowner> refers to 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 according to Note 50088

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

o Table SAPUSER should occur in the system once only and be assigned

to user OPS$<sid>ADM. To check this, use the following query:

SELECT OWNER FROM DBA_TABLES WHERE TABLE_NAME = 'SAPUSER';

If the system returns an owner <owner> other than OPS$<sid>ADM,

then delete the corresponding SAPUSER tables:

DROP TABLE "<owner>".SAPUSER;

If the system does not return OPS$<sid>ADM, create the SAPUSER

table 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 to NT in particular. But if more than one OPS$

user is used under UNIX as well, the checks need to be carried out

in the same way.

o Under NT, it is required that user sapservice<sid> can also access

the SAPUSER table. In order to avoid problems with the data

consistency, it does not make sense to create an additional SAPUSER

table having the same contents. Instead, you should define a

synonym. Check if a suitable synonym exists by using the following

call:

SELECT OWNER, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS

WHERE SYNONYM_NAME = 'SAPUSER';

As first value, this call should return either OPS$SAPSERVICE<sid>

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

If PUBLIC is returned as first value:

DROP PUBLIC SYNONYM SAPUSER;

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

DROP SYNONYM "<name>".SAPUSER;

Now you can recreate the synonym (It is best not to use PUBLIC):

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

"OPS$<sid>ADM".SAPUSER;

8/9/2019 Oss Note 0400241


22.04.2007 of 10

SAP Note Number 400241 - Problems with ops$ or sapr3 connect toOracle

To allow access to the synonym (or the associated table), a grant

has to be executed. Only the OPS$ user to whom the actual table

belongs has the authorization to do this - that is OPS$<sid>ADM.

Therefore, you must log on with the corresponding operating system

user (<sid>adm) and execute the following commands:

CONNECT /

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

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

environment variable, you can define another database user. This

makes sense in particular with R/3 6.x, if SAPR3 is replaced by

SAP<sid>. If with R/3 <= 4.x, dbs_ora_schema is set to another

value than SAPR3, the connect fails since that user exists neither

in the database nor in the SAPUSER table. Consequences include

errors such as ORA-01403 or ORA-01017. Up to and including 4.6D,

dbs_ora_schema should 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 make the general option

of an OPS$ connect available, proceed as follows:

o Set 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 can occur both in step 1a) and in step 1b) or 2).

Depending on this, the problem can be corrected as follows:

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


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


If you intend to use the standard password for <sapowner> anyway, you can

ignore the error message at this point, as the OPS$ mechanism is not needed

at all and the connect is carried out using <sapowner>/sap successfully

afterwards. Note, however, that BR*TOOLS require a working OPS$ mechanism

when executing via DB13!

Otherwise, make sure that an appropriate OPS$ user is set up. To do

this, proceed as follows:

o Check whether the parameter

8/9/2019 Oss Note 0400241


22.04.2007 of 10


os_authent_prefix = ops$

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

restart the database afterwards.

o On Windows, make sure 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 involves a connect initiated out of the R/3

System (for example, work process connect, DB13 actions), user

<sid>adm is used under UNIX and user sapservice<sid> under NT. If

you manually called the program that executes the connect, the user

you are using is decisive here.

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

OPS$<domain>\ <os_user> for NT with Oracle >= 8.1.5) has beencreated at database level:

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

(for <os_user>, always use upper case)

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;

Note that the name of the OPS$ user must be specified completely in

uppercase letters (also the host and domain names in case of NT and

W2K), since a logon as OPS$ user will not work if it is not:

wrong: 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 ...

Tablespace <user_tsp> is used when newly creating objects, when no

explicit tablespace name is specified. In connection with R/3, this

is almost never the case. Therefore, you can specify any

tablespace. Proposal:

R/3 <= 4.6D: <user_tsp> = PSAPUSER1D R/3 >= 6.10: <user_tsp> = PSAP<sid>USR

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

following statement must at least return CONNECT and RESOURCE:

SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS

WHERE GRANTEE = 'OPS$<os_user>';

If CONNECT and/or RESOURCE is missing, you can grant these

authorizations as follows:

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

8/9/2019 Oss Note 0400241


22.04.2007 of 10


o If all the settings described above have been made correctly on NT/

Windows 2000, but the error ORA-01017 is still displayed during the

OPS$ Connect, the cause may be a start user set incorrectly for the

SAP Service. Change to the services overview of the operating

system and check the user who 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, which

leads to error ORA-01017. Check also whether the start 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 should exist on 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



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



An ORA-01017 message at this point indicates an incorrect

<sapowner> password in the SAPUSER table. In this situation,

proceed as follows.

o Set the password consistently in SAPUSER and in the Oracle DDIC

using the following BRCONNECT call (BRCONNECT >= 6.10):

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

<password>

o Otherwise, change the password in the SAPUSER table:

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


'<password>');

Important: The SAPUSER table should only exist once in every

system: for OPS$<sid>ADM. For this reason, only execute the

above-mentioned statements for OPS$<sid>ADM - irrespective of the

operating system user actually being used. All other OPS$ users can

access the SAPUSER table using a synonym.

o If the connect still terminates in the same way, check once morethe section "General checks".

8/9/2019 Oss Note 0400241


22.04.2007 of 10

SAP Note Number 400241 - Problems with ops$ or sapr3 connect toOracle2) log entries: Try to connect with default password

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



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, the error cannot

be avoided at this point. Set up the OPS$ mechanism as described

above instead.

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

connection, refer to Note 569302.

ORA-01031: insufficient privileges

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



*** 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 above section "General checks".

ORA-01403: No data found





The main cause for the ORA-01403 message is that table SAPUSER does not

contain any entries. Proceed as follows:

o Set the password consistently in SAPUSER and the Oracle Dictionary

using the following BRCONNECT call (BRCONNECT >= 6.10):

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

<password>

o Alternatively, you can add it to SAPUSER manually.


'<password>');

Another possible cause is that incorrect entries are contained in SAPUSER.

Selection from SAPUSER is always made using the user name. For this reason,

make sure that the user name is always written in uppercase (SAPR3 or

SAP<sid>) and that it exactly corresponds to the value of the environment

variable dbs_ora_schema if SAP<sid> is used.

o If the ORA-01403 still occurs, check once more the above-mentioned

8/9/2019 Oss Note 0400241


22.04.2007 of 10


section "General checks".

ORA-00942: Table or view does not exist





Message ORA-00942 is issued when table SAPUSER does not exist. Proceed as

follows:

o Create the SAPUSER table as <sid>adm using the following command:

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

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


'<password>');

o If the error still occurs, check once more the above-mentioned


ORA-00980: synonym translation is no longer valid





ORA-00980 occurs, if a synonym for SAPUSER exists but is no longer valid

for any reason (for example because it points to a non-existant object).

Therefore, create the synonym for SAPUSER again as described in the above


Header DataRelease Status: Released for CustomerReleased on: 29.03.2006 06:39:00Priority: Recommendations/additional infoCategory: Help for error analysis

Main Component BC-DB-ORA OracleAdditional Components:

BC-DB-ORA-DBA Database Administration with Oracle

The SAP Note is release-independent

8/9/2019 Oss Note 0400241


22.04.2007 of 10


Related NotesNumber Short Text

969519 6.20/6.40 Patch Collection Installation : Oracle/UNIX

951167 ORA-28000: the account is locked

851169 Inst: SAP NetWeaver2004s - UNIX:Oracle

849141 SAP NetWeaver 2004s Installation on Windows: Oracle

700548 FAQ: Oracle authorizations

675940 SAP Web AS 6.40 Installation on Windows: Oracle

668604 SAP Web AS 6.40 ABAB/Java Installation on UNIX: Oracle

662644 Composite SAP Note: ORA-00942

650796 Composite Note: ORA-00980569302 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 ValueDatabase system ORACLE

weitere Komponenten BC-DB-ORA-DBA

oss note 0400241

Documents