400241 - Problems with ops$ or sapr3 connect to Oracle

8/11/2019 400241 - Problems with ops$ or sapr3 connect to Oracle

http://slidepdf.com/reader/full/400241-problems-with-ops-or-sapr3-connect-to-oracle 1/6

SAP Security Note

Header Data

Symptom

ORA-01004: default username feature not supported; logon deniedORA-01017: invalid username/password; logon deniedORA-01031: insufficient privilegesORA-01403: no data foundORA-00942: table or view does not existORA-00980: synonym translation is no longer valid

BR301W SQL error -1017 at location BrDbConnect-1BR310W Connect to database instance <sid> failed

Other Terms

Reason and Prerequisites

R/3 work processes and R/3 tools such as R3trans often require the option to use the user sapr3 toconnect 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: "connectsapr3/<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 forsapr3 to be determined. This can then be used in the next step for the actual logon to the databaseusing sapr3. The system can connect using the OPS$ user ("connect /@<sid>") only if a user which iscreated from the concatenation of OS_AUTHENT_PREFIX = ops$ (see init<sid>.ora) and the name of theoperating 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:

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 thelocal host, if the database server does not belong to any domain): OPS$<domain>\<os_user> You canuse 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 (forexample 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$-userConnecting 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

400241 - Problems with ops$ or sapr3 connect to Oracle

Language English

Released On 08.10.2009

Release Status Released for Customer

Component BC-DB-ORA Oracle

BC-DB-ORA-DBA Database Administration with OraclePriority Correction with low priority

Category Help for error analysis

Other Components



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 sapr3password from the table SAPUSER was used in the first case and the standard password "sap" was usedin 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 othermethod works. That is, to ensure that the system connects successfully, either the standard passwordfor 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 reversesequence was valid with earlier R/3 releases: first the system used the standard password to connectand 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 to access the database ifyou also specify the option "-u /". This is always the case from R/3 (for example from transactionDB13). However, unlike the R/3 work processes, the system uses the OPS$ user directly rather thanusing 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 thecurrent 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 useris 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. Themost important change in this regard is the use of the SID-dependent SAP<sid> instead of the userSAPR3. You can use the following query to determine the user to which the R/3 objects actuallybelong:

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 SIDsin one database where each system requires its own user. If the new layout is used, SAPR3 is nolonger used even for the connect, but SAP<sid> is used. To ensure that R3trans / saplicense and thework 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 logentries described above have also slightly changed. However, the basic mechanism remains and you caneasily 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 accessto 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 ofOPS$<sid>ADM) at all points in which the OPS$ user occurs in the following SQL commands. If the useris a non-domain user, the name of the local host replaces the domain name.

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

General checks

l Check whether creating the OPS$ mechanism in accordance with to Note 50088 (WINDOWS) or Note

361641 (UNIX) solves the problem.

l The table SAPUSER must occur in the system only once and it must be assigned to the userOPS$<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 relevantSAPUSER tables:



DROP TABLE "<owner>".SAPUSER;

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

CREATE TABLE "OPS$<sid>ADM".SAPUSER(USERID VARCHAR2(256), PASSWD VARCHAR2(256));

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

l This section applies particularly to NT. However, if more than one OPS$ user is also used onUNIX, 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 avoiddata-consistency problems, it does not make sense to create an additional SAPUSER table that hasthe 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 byOPS$<sid>ADM and SAPUSER. If this is not the case, recreate the synonym after you have deletedit:

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;

To allow access to the synonym (or the associated table), you must execute a grant. Only theOPS$ 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 thefollowing lines:

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

l By default, R3trans uses SAPR3 as the database user. However, you can use the environmentvariable to specify another database user. This makes particular sense with R/3 6.x, if SAPR3 isreplaced 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. Asa result, errors such as ORA-01403 or ORA-01017 occur. Up to and including 4.6D, dbs_ora_schemamust 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:

l Set the following parameter:

REMOTE_OS_AUTHENT = TRUE

in init<sid>.ora.

l 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 asfollows:

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 messageat this point, because the OPS$ mechanism is not required at all and the system connectssuccessfully 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, proceedas follows:

l Check whether the parameter

os_authent_prefix = ops$

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

l On Windows, ensure that the following parameter is set in sqlnet.ora:



SQLNET.AUTHENTICATION_SERVICES = (NTS)

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

l Use SVRMGRL to check whether the user OPS$<os_user> (or OPS$<domain>\<os_user> for NT withOracle 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).

l 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 andthe domain name in the case of NT and W2K). If you do not do this, you will not be able to logonas 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 explicittablespace name. In connection with R/3, this is almost never the case. Therefore, you canspecify any tablespace. Proposal:

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

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

l On NT or Windows 2000, if you have made all of the settings described above correctly but thesystem continues to issue error ORA-01017 during the OPS$ connection, the start user for the SAPservice may be set incorrectly. Switch to the services overview of the operating system andcheck the user that starts the service SAP<sid>_<instance_number>. If the user is notsapservice<sid>, enter sapservice<sid>. Other users (such as the local administrator) do nothave an OPS$ user in the database. Therefore, the system issues ORA-01017. In addition, you mustcheck whether the starting user sapservice<sid> is a local user or a domain user. Domain userscan be identified by the preceding domain name. Depending on this, the following OPS$ user mustexist 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$-userConnecting 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 tableSAPUSER is incorrect. In this situation, proceed as follows:

l Use the following BRCONNECT call (BRCONNECT 6.10 or higher) to set the password consistently inSAPUSER and in the Oracle DDIC:

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

l 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 thisreason, execute the statements mentioned above for OPS$<sid>ADM (regardless of the operatingsystem user that is actually being used). All other OPS$ users can use a synonym to access thetable SAPUSER.

l If the connection still terminates in the same way, check the "General checks" section onceagain.

2) Log entries: Try to connect with default password Connecting as <sapowner>/<pwd>@<sid> on connection 0 *** ERROR => OCI-call 'olog' failed: rc = 1017*** ERROR => CONNECT failed with sql error '1017'

l 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;



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

l 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 asdescribed in the "General checks" section above.

ORA-01403: no data found



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

l Use the following BRCONNECT call (BRCONNECT 6.10 or higher) to set the password consistently inSAPUSER and in the Oracle DDIC:

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

l Alternatively, you can insert it in SAPUSER manually.


Another possible cause is that SAPUSER contains incorrect entries. The system always uses the username 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 variabledbs_ora_schema if SAP<sid> is used.

l If the system continues to issue ORA-01403, see the "General checks"section once again.

ORA-00942: table or view does not exist



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

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

CREATE TABLE "OPS$<sid>ADM".SAPUSER(USERID VARCHAR2(256), PASSWD VARCHAR2(256));


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

ORA-00980: synonym translation is no longer valid



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.

Other Attributes

Validity

This document is not restricted to a software component or software component version

ORACLEDatabase System



Documents

400241 - Problems with ops$ or sapr3 connect to Oracle