So lets get started - about database logon mechanisms in SAPsystemsOne quite common problem is lost connectivity to the da...
If it works - great, chances are that the workprocesses will also be able to perform the connect.If not it will have gener...
Nevertheless there are also exceptions to this separation - the DBM users are allowed to access the databasecatalog and so...
25591 - Changing the DBM, SYSDBA andDBA user passwords
Upcoming SlideShare
Loading in …5

Database logon mechanisms in sap


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Database logon mechanisms in sap

  1. 1. So lets get started - about database logon mechanisms in SAPsystemsOne quite common problem is lost connectivity to the database. There are not too many SAP Basis administratorsaround that never got across a situation where the workprocesses were not able to connect to the databaseanymore.In such a situation it is good to know how the workproceses actually perform the connect to the database.1 How it works with Oracle...For Oracle systems the SAP workprocesses make use of an operation-system (OS) authentication called OPS$-mechanism.One creates a user in the database and sets it up in a way with the flag "identified externally".Now whenever this OS-user tries to connect without specifying username and password (e.g. "sqlplus /") thedatabase asks back to the OS if this user is known.If so, the access is granted.Once the workprocesses have done this successfully, they have access to just one table called SAPUSER thatcontains the password for the SAP-schema user.With that password the workprocesses then perform the final connect as the SAP-user against the database - thistime with a username and a password.That approach allows storing the logon data for the actual SAP-schema user inside the database and relies(obviously) on the authentication of the users by the OS.Of course, one has to know for sure, which OS-users run the SAP workprocesses in this case.Anyhow, to make this mechanism work correctly the sqlnet configuration has to be done correctly (sqlnet.ora,tnsnames.ora, ORACLE_SID environment etc.) and of course, the OS-based authentication has to work properly(which might be difficult in some Windows Active Directory setups).2 ... and with MaxDBMaxDB uses stored logon data as well, but it does not store them in the database.Instead it is stored them on OS-level for every user on every server separately and encrypted.The facility that MaxDB uses for this is called XUSER.Therefore, for the OS-users that run the workprocesses (<sid>adm on UNIX/LINUX and SAPSERVICE<SID> on MSWindows) it is necessary to setup and store the logon data.A XUSER-entry consists of all information needed to connect to the database, that is username, password, databaseSID, hostname of the database and some other "special" settings.Once the data has been setup correctly, the workprocesses (or any other process like e.g. sqlcli or dbmcli) canlogon to the database just by specifying the KEY under which the logon data is stored.For the SAP schema user the key is usually SAP<SID>, so if your SAP System Identifier is SDB it would bepossible to connect just via: sqlcli -U SAPSDBNo need to specify the database or the host on which it runs, just the XUSER-key, thats it.*) ok, in the area of CCMS there we have something called "central authorization" where the logon data is storedwithin the database. However, this is just used by the CCMS.3 Checking the ConnectivityAnother important thing to know is how to check if the logon mechanism was configured correctly.Since it is time consuming to try the "startsap"-option repeatedly, a shortcut is using R3trans.It uses the same logon mechanisms as the workprocesses do, but has a much smaller startup overhead (justone process, no memory initialization etc.).Use R3trans -dto try a connect to the database including the read access to some internal tables.
  2. 2. If it works - great, chances are that the workprocesses will also be able to perform the connect.If not it will have generated a trace file named "trans.log" in the current directory containing detailed informationabout what went wrong with the logon.Since R3trans is database-dependent is knows how to use the OPS$-mechanism for Oracle and how to use theXUSER-mechanism with MaxDB.ATTENTION: mind the user context you are running R3trans in!It might well be that you test it on e.g. Windows as the <sid>adm user and it works and still the workprocesses failto connect as they are running in the SAPSERVICE<SID> context (VERY popular mistake!).4 User conceptsThe second part of my blog is about a drier topic: user concepts.Both database systems know different kinds of users that are required in different contexts.5 SQL-usersLets start with the easy to understand SQL-user first.This database user is used most.It can logon to the database, create and drop database objects and query and update data.Just what a database user is all about concerning working with the database itself. The workprocesses use this typeof user to connect to the databases.What these users usually are not able to do are actions like backup, recovery, shutdown and (of course not)startup the database.Since SQL-users only exist within the database, it is necessary that the database is up and running to use them.Therefore, these users are just not there to start the database instance...6 DBA-users ...The second kind of user is the administrative (dba) user. This user type is focused on performing dba tasks likebackup, recovery, shutdown and startup (!) the database. It is the "magic database god" straight away as it cancreate the database instance.This distinction between the both user types is present in both MaxDB and Oracle. Nevertheless, there are againimportant differences.7 ... in OracleWith Oracle there is the SYSDBA user. This user (called SYS) can do anything - really anything in the database.Permission checking just does not exist for this user. Beside any DBA actions it can also access any data in thedatabase. It is really the "almighty" on Oracle instances.This comes in very handy, as this user is also os-authenticated.Just put the os-level user you are starting sqlplus with into the dba-group and all you have to type in is sqlplus "/as sysdba"to connect to the database instance.With every light there is a shadow: this approach does not protect you from any mistakes. If you are about to messthings up - this user makes possible the worst. (Amazing how quick you can drop a multi-GB-tablespace... just onecommand...)8 ... and in MaxDBMaxDB on the other side strictly separates SQL-users and DBAs (called Database Manager Operators in MaxDB-speech).As such a DBM user (usually named CONTROL) you can also do anything you like with the database instance -except accessing the data in the database. (I here praises of SOX-consultants rising in the background...).
  3. 3. Nevertheless there are also exceptions to this separation - the DBM users are allowed to access the databasecatalog and some internal tables to get information about the database instance when it is up and running.To enable this "double-life" the user-logon information are stored twice: in a special file (user profile container orupc-file) and in the database (table users).In former versions of MaxDB it was possible to change the password of a user in just one of both location and thuscreate an inconsistency. Nowadays this is past - so a change of the password for e.g. CONTROL or SUPERDBA inone of the locations automatically updates the other.9 My view to itTo me this strict distinction has been one of the major obstacles when I first got hands on MaxDB after developingon Oracle for quite some time.However, I have to say, "I like that!"Like most people, I tend to get lazy and sometimes thoughtless in the hurry of the day and then it is easy to issuejust that catastrophic command that kills your database.Concerning that Oracle pushes the "learn through pain"-approach where MaxDB just do not do anything until youdo it right (sometimes it is even too quiet about what exactly was not right...)When it comes to flexibility with the setup of logon mechanisms Oracle is clearly in the lead - so many options, somany parameters than can be set.However, on the few thousand Oracle installations of SAP systems that I have seen in the last years most often justthe standard setup was used. Sometimes not even the recommendations had been followed.Viewed from that angle MaxDBs logon mechanism has everything required for a SAP installation and is much easierto configure.10 The cheat sheet ------------- 8< ------------ cut here ------------ 8< ------------To reward you for your endurance and reading this so far, heres a short cheat sheet that provides the quickoverview over the differences and the similarities between the both DBMS. Oracle MaxDBsuperuser called SYS superuser called CONTROLworkprocesses use OPS$- and workprocesses use the XUSER data tousername/password to logon to the logon to the databasedatabaseSYS can do anything, including CONTROL can only access the databaseaccessing SAP-data instance, but not the SAP-dataslight distinction between DBA and strict distinction between DBA and SQL-SQL-user (SYS is both) Usernotes to know: notes to know:562863 - FAQ: Logon mechanisms 39439 - XUSER entries for SAP DB 6.x and 7.x
  4. 4. 25591 - Changing the DBM, SYSDBA andDBA user passwords