Symptom
1. What are the default database users in the SAP environment?
2. Where is information about existing users saved?
3. How can I log on to a stopped database?
4. How can I find out which database users exist on the system?
5. What are the standard passwords for database users?
6. How can I change Oracle passwords?
7. What is the effect for SAP of changing passwords?
8. How can I log on to the database without a password?
9. What happens when I log on with SYSDBA/SYSOPER privileges?
10. What should I do if the SYSDBA/SYSOPER connect does not work?
11. What happens when I log on as an OPS$ user?
12. How can I eliminate problems when logging as an OPS$ user?
13. What are the similarities and differences between SYSDBA/SYSOPER connects and the OPS$ mechanism?
14. How can I define the hosts from which links to the database are allowed?
15. How can I set up an SYSDBA or SYSOPER connection from a remote host?
16. Why does "CONNECT INTERNAL" not work with Oracle 9 or higher?
17. What is the situation with the users SAPTRANS, SAPDDIC and SAPHOT?
Other terms
FAQ
Solution
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.
The
ORACLE_OCM user is required for the Oracle Configuration Manager (see
Note 974781), which is not used in the SAP environment and, therefore,
is not critical.
The
APPQOSSYS user is required for saving and administering the Quality of
Service data. This user is irrelevant 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
- 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
OPS$: possible.
- Use:
SYSDBA/SYSOPER: DB start, DB stop, restore, recovery
OPS$: Work process connection, sapdba, BR tools
- Authorizations:
SYSDBA/SYSOPER: extensive
OPS$: restricted
- Database user:
SYSDBA/SYSOPER: SYS (SYSDBA) / PUBLIC (SYSOPER)
OPS$: OPS$<osuser>
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?
If
required, you can use the tool orapwd to create a password file on a
remote host in accordance with Note 168243 and on the basis of this
password file, you can set up a remote connection with SYSDBA or SYSOPER
privileges. As part of the current SAP installations, a password file
is already created automatically.
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>". |
No comments:
Post a Comment