Two days ago, I have a yahoo message from my friends about her SAP Production server which un-accidentally have been changed its SAP database owner schema. She uses SAP ECC 5 version and using Oracle Database 10g. After several hours being headache looking for solution, the problem was solved. So the main problem is that SAP logon mechanism using 2 place to save its user and password. SAP save it on Oracle dictionary and SAPUSER table. One of it password hadn’t changed yet.
Here is I have copied some articles from saptechies.com :
1. What are the default database users in the SAP environment?
The following database users exist in the SAP environment:
SAPR3 / SAP<sid> / SAP<xyz> / SAPSR3
The SAPR3 / SAP<sid> / SAP<xyz> / SAPSR3 user is the owner of all R/3 objects. The work processes log on to the database with this user. The SAPR3 user was always used for older R/3 releases. However, since several R/3 systems may be present in the same database within MCOD with current releases, you can replace the SAPR3 user with a system-specific SAP<sid> user here. You can define this during the installation. To avoid confusion during homogeneous system copies, as of 4.7 SR1 you can use an SID-independent username, SAP<xyz>, with “SAP” followed by any three characters (see Note 617444). In the meantime, the system proposes the username SAPSR3 by default – irrespective of the SID that the system actually uses.
SAPR3SHD / SAP<sid>SHD / SAP<xyz>SHD / SAPSR3SHD
This user is used temporarily within an SAP shadow upgrade. This user is not required during normal system operation.
The SYSTEM user is created during the Oracle installation as standard and has extensive authorizations. Some of the objects in the system tablespace belong to this user.
The SYS user is also created during Oracle installation and also has extensive authorizations. Most of the objects in the system tablespace belong to this user.
OPS$<sid>ADM (NT, UNIX) / OPS$SAPSERVICE<sid> (NT)
The OPS$ users are taken from R/3 and used to set up the connection to the R/3 database and to execute sapdba and BR tools and are created as part of the R/3 installation. For more information about these users, see below.
CONNECT INTERNAL is a mechanism that you can use to log onto the database without a password. Therefore, strictly speaking, INTERNAL is not a user. For more information about CONNECT INTERNAL (or SYSDBA and SYSOPER connect), see the section below. As of Oracle 9, CONNECT INTERNAL is no longer available – instead, only the “/ AS SYSDBA” and “/ AS SYSOPER” connects are available.
Stored Outlines are managed in the OUTLN user. If this user is missing, ORA-18008 may occur. See Note 722376, which contains further information.
The DBSNMP user may be created by Oracle, but does not play a role in the R/3 environment.
The CTXSYS user is only used in conjunction with Oracle and has no role in the R/3 environment. This user is only required if you use Requisite/BugsEye. SAP<sid>DB
The TSMSYS user is an Oracle-internal user (Transparent Session Migration) that is automatically created as of 10g, but that is of no importance in the SAP environment.
The DIP user is an Oracle-internal user (Directory Integration Provisioning) that is automatically created as of 10g, but that is of no importance in the SAP environment.
SAP<sid>DB / SAP<xyz>DB / SAPSR3DB
SAP<sid>DB, SAP<xyz> DB or SAPSR3DB is the equivalent to SAPR3 / SAP<sid> / SAP<xyz> / SAPSR3 in the J2EE environment as of Release 6.30.
In the EP environment, the SAPPCD user is owner of the objects of the Portal Content Directories (PCD).
In the EP environment, the SAPWCM user is owner of Content Management objects.
2. Where is information about existing users saved?
The data concerning database users is stored in the Oracle dictionary in the SYSTEM tablespace. One exception here is the SYSDBA or SYSOPER connection which can also be set up without accessing the Oracle dictionary.
3. How can I log on to a stopped database?
Normal connections are not possible with stopped databases, because they require an access to the Oracle dictionary. A logon to the database is only possible in this case by means of a SYSDBA or SYSOPER connection.
4. How can I find out which database users exist on the system?
The following query on DBA_USERS returns all users created in the database:
SELECT USERNAME FROM DBA_USERS;
5. What are the standard passwords for database users?
SAPR3 / SAP<sid> / SAP<xyz> / SAPSR3: sap
OPS$ user: No password required
INTERNAL: No password required
SAP<sid>DB / SAP<xyz>DB / SAPSR3DB: Password is explicitly assigned during installation.
6. How can I change Oracle passwords?
You can use SQLPLUS to convert passwords:
sqlplus “/as sysdba”
ALTER USER <username> IDENTIFIED BY <new_password>;
7. What is the effect for SAP of changing passwords?
Before you change passwords, you should always check whether scripts contain calls with hardcoded passwords. These scripts may have to be adjusted. When you change a password, you should take the following side effects in the standard SAP system into account:
SAPR3 / SAP<sid> / SAP<xyz>DB / SAPSR3DB: To allow continued logon of the R/3 work processes using the OPS$ mechanism, you must also change the password in the SAPUSER table. The simplest way of making a consistent change in the Oracle dictionary and in the SAPUSER table is to use the ” -f chpass” option of brconnect, for example:
brconnect -f chpass -o [sapr3 | sap<sid> | sap<xyz> | sapsr3] -p <new_password>
If the password is only adjusted in the Oracle system and not in the SAPUSER table, the work processes and tools such as R3trans or saplicense fail with ORA-01017.
To avoid unexpected problems (for example, as described in Note 569302), we recommend that you only change the password when R/3 is stopped.
SYSTEM: By default, sapdba and the BR tools are connected to the database with the SYSTEM user and standard password. If you change this now, you can only start the tools by explicitly specifying the user name and password. To do this, use the option “-u <username>/<password>”. Otherwise, calling sapdba, brbackup, brconnect, brarchive and brrestore fails with ORA-01017.
A useful alternative to the SYSTEM user when using the BR*TOOLS is to use the OPS$ mechanism by specifying “-u/”. This mechanism is also used by DB13 actions by default.
SYS: A change to the SYS password does not affect the R/3 System.
INTERNAL: the SYSDBA or SYSOPER connect can be protected in theory with a password stored at the level of the operating system. However, this may cause problems if you want to establish a connection in scripts (for example, startdb) or tools (for example, sapdba) without a password. Therefore, we recommend that you do not activate password protection for the SYSDBA and SYSOPER access.
OUTLN, DBSNMP: Changing the password has no effect on the SAP system.
SAP<sid>DB / SAP<xyz>DB / SAPSR3DB: The J2EE processes can no longer log on to the database and they fail with ORA-01017. To avoid this problem, you must also change the password using the CONFIGTOOL script from the CONFIGTOOL subdirectory of the J2EE installation. Select “Secure Store” and “jdbc/pool/<SID>/Password” to change the password.
8. How can I log on to the database without a password?
Using SYSDBA/SYSOPER connect and the OPS$ user, you can log on to the database without a password. For more information on these connect mechanisms, see below.
9. What happens when I log on with SYSDBA/SYSOPER privileges?
No password is required when you log on with SYSDBA or SYSOPER privileges. Instead of this, the authentication is based on the membership of the calling operating system user to the operating system groups. For more information on this mechanism, see Note 480266.
10. What should I do if the SYSDBA/SYSOPER connect does not work?
If the SYSDBA or SYSOPER connect terminates with an error such as ORA-01017 or ORA-01031, see the causes described in Note 480266.
11. What happens when I log on as an OPS$ user?
You can log on as an OPS$ user without a password. Instead, authentication is based on the name of the relevant operating system user. Only those operating system users that have a relevant OPS$ user in the database can log onto the database with the OPS$ mechanism. For more details, see Note 400241.
12. How can I eliminate problems when logging as an OPS$ user?
Note 400241 describes possible problems in using the OPS$ mechanism and how to solve them.
13. What are the similarities and differences between SYSDBA/SYSOPER connects and the OPS$ mechanism?
- Authentication via operating system
- No password required
- Logon string:SYSDBA/SYSOPER:”CONNECT INTERNAL” / “CONNECT / AS SYSDBA” / “CONNECT / AS SYSOPER”
OPS$: “CONNECT /”
- Authentication method:SYSDBA/SYSOPER: Group membership
OPS$: User name
- Connection during stopped database:SYSDBA/SYSOPER: possible.
OPS$: not possible
- Connection from remote host:SYSDBA/SYSOPER: not possible or only possible with password file
- Use:SYSDBA/SYSOPER: DB start, DB stop, restore, recovery
OPS$: Work process connection, sapdba, BR tools
- Authorizations:SYSDBA/SYSOPER: extensive
- Database user:SYSDBA/SYSOPER: SYS (SYSDBA) / PUBLIC (SYSOPER)
14. How can I define the hosts from which links to the database are allowed?
For security reasons, it may make sense to allow users to log on to the Oracle database only from particular servers (from SAP application servers, for example). You can do this by setting the parameters for protocol.ora as described in Note 186119 (tcp.validnode_checking, tcp.invited_nodes).
15. How can I set up an SYSDBA or SYSOPER connection from a remote host?
For security reasons, a SYSDBA/SYSOPER connection from a remote host is not provided as a default function. However, if this function is required in special cases, you can use orapwd to create a password file as described in Note 168243.
16. Why does “CONNECT INTERNAL” not work with Oracle 9 or higher?
As of Oracle 9, “CONNECT INTERNAL” is completely replaced by more transparent calls, “CONNECT/AS SYSDBA” and “CONNECT/AS SYSOPER”. Scripts that contained “CONNECT INTERNAL” must be adjusted accordingly.
17. What is the situation with the users SAPTRANS, SAPDDIC and SAPHOT?
The SAPTRANS, SAPDDIC and SAPHOT database users were delivered a long time ago (R/3 2.x or lower) and are not used by the SAP system. You can therefore delete them using “DROP USER <username>”.
I hope this article would help you.