Administration Archives » Page 2 of 2 » Musings of an IT Implementor

SAP note 830576 – PGA_AGGREGATE_TARGET on Oracle 10gR2

SAP note 830576 “Parameter Recommendations for Oracle 10g” is quite a popular one for me.
It lists all the SAP recommended Oracle 10g parameter settings for Oracle 10.2.0.4 and 10.2.0.5.
It’s a good point of reference and I’d recommend you implement it as a baseline before tuning the system further.
It has a buddy note, 1289199 “Information About Oracle Parameters” which describes some of the parameters in more detail.

Unfortunately, there is a major flaw on note 830576. When setting PGA_AGGREGATE_TARGET the SAP note says 20% of available memory. It fails to mention that this should be 20% of the SGA size, not O/S memory.
The Oracle docs (see MYOS note 153367.1) say that the value should be:

Syntax PGA_AGGREGATE_TARGET = integer [K | M | G]
Default value 10 MB or 20% of the size of the SGA, whichever is greater
Modifiable ALTER SYSTEM
Range of values Minimum: 10 MB
Maximum: 4096 GB – 1

The Oracle note goes on to say that when sizing the Oracle database memory areas, you should consider the SGA size first, then assign any spare memory to PGA.
Now in an SAP landscape with a single Central Instance + Dialog Instance on the same server as the database, you may wish to use the SAP 70/30 rule (70% to SAP, 30% to Oracle).

My order of sizing would look something like this:
1, Determine number of users of SAP system.
2, Determine number of DIALOG work processes + Background work processes + Update processes (~= Oracle “processes”).
3, Determine leftover memory for Oracle SGA (split between pools, SAP doesn’t support automatic memory management).
4, Determine leftover memory for PGA + overheads.

If you get to step 4 and you have diddly squat RAM left (hardly any), then consider adding more RAM to your server. Remember, we don’t like pageing.

SAP note 789011 “FAQ: Oracle Memory Areas”, provides a range of SQL statements for checking the actual size of the PGA. Since PGA_AGGREGATE_TARGET is only telling Oracle what you would like the maximum PGA allocation to be.

When you set PGA_AGGREGATE_TARGET, you also allow Oracle to release PGA memory back to the O/S. Using the *_AREA_SIZE parameters and setting PGA_AGGREGATE_TARGET to 0, forces a specific size of PGA which does not release the memory to the O/S.
/* Actual PGA consumption */ SELECT VALUE FROM V$PGASTAT WHERE NAME = 'total PGA allocated';

/* Chronological PGA allocation (needs AWR license) */ SELECT SUBSTR(S.END_INTERVAL_TIME, 1, 40) TIME, P.VALUE PGA_ALLOCATION FROM DBA_HIST_SNAPSHOT S, DBA_HIST_PGASTAT P WHERE P.NAME = 'total PGA allocated' AND S.SNAP_ID = P.SNAP_ID ORDER BY P.SNAP_ID;

Oracle states:
Memory Area Dedicated Server Shared Server
Nature of session memory Private Shared
Location of the persistent area PGA SGA
Location of part of the runtime area for SELECT statements PGA PGA
Location of the runtime area for DML/DDL statements PGA PGA

When installing Oracle for SAP, by default it uses DEDICATED server mode (see note 70197).

To Delete or Not To Delete (an SAP user account)

Having read around the SDN forum recently, I was surprised that no one had done any particular research into the consequences of deleting SAP user accounts.
This is probably quite a common question when you first get your shiny new SAP system implemented.
Generally, auditors prefer that you delete IT accounts. It’s a nice catch-all and means that they can tick the box that says “done”, knowing that what happened was the most secure option. But it might not be the best option.
Most procedures require locking the account for 1-2 months before eventually deleting it, therefore catching rogue background jobs etc.

After some heavy procrastination I have come up with the following reasons why it might always be better (safer) and actually more audit-friendly to just lock the account and not actually delete it:

– Adding a new user of the same user id as the one just deleted, will attempt to re-use the old address details.
This is really bad and could cause awful confusion. It could also cause a problem with regards to auditing.

– Customer modifications/code in programs and workflows that utilise the user id.
If the user is deleted, then re-created later on for a new employee of the same name, that new user may inherit authority, receive SAP Office emails or any other actions that were previously meant for the old owner of the user id.

– When a user creates a transport, this is recorded in the code version history for the objects transported and the transport co-file and a file in one of the the /usr/sap/trans sub-directories (off-hand I think it’s called sapnames…).
Deleting the user removes the tie between the user id that created the code version, and their real name/details. In a large organisation it can be difficult to find the right “Smith” that made that change.

– When a user is deleted, you can not see what authorisations the account used to have.
Once again, how can you prove that some malicious action happened if the account has been deleted, removing the evidence that the user had access to perform the crime.
Alternatively, someone may have legitamately left the company, but recruiting didn’t find a replacement for 6months. Guess who will need to create a new user id where the request form says “same roles as Joe who left 6 months ago“.

– If you delete a user account after they leave, then re-create a new one for a new employee, what if you’ve missed an account on a system somewhere. Nobody will know if it should be for the user who currently exists. This is a major security risk.

This may lead you to thinking about a better user id naming scheme that could provide a unique name for every account created.
That really would be a worthwhile exercise.

Don’t forget, locking the account does not mean that you need to pay a license cost for it, it’s not usable.

Enable SAP* in Netweaver 7.0

If you’ve lost the Administrator password or you want to log in as SAP* in your pure Java stack environment, this can be a little tricky as the way to set the password for the SAP* user in configtool is not as user friendly as you might think.

Log into configtool by opening an X-Windows session (on UNIX), and then execute: /usr/sap/<SID>/JC<SYS#>/j2ee/configtool/configtool.sh (.bat on Windows).

NOTE: Once you enable the SAP* user, you will not be able to log into the system as any other users e.g. Administrator or J2EE_ADMIN.

In the configtool screen, expand the “Global server configuration -> services” branches:

Click the “com.sap.security.core.ume.service” item:

On the right hand side, scroll down to the ume.superadmin.activated option:

Set the “Value:” field to “TRUE”:

Now single click the “ume.superadmin.password” item:

You can’t see the password and the “Value:” field looks like it doesn’t accept input, but it does.
Type the new password in to the “Value:” field at the bottom (even though the cursor doesn’t move):

Now click “Set” on the right:

You will be prompted to re-enter the password:

Click Save:

You should restart the J2EE stack before trying to log in as SAP*.

SAP User Groups

Apart from the roles, profiles and authorisation objects involved in SAP security controls, there is also an additional level. User groups.
The user groups in an SAP system can be used to control access to certain authorisation objects (i.e as a restriction in a profile), or used as a method of tagging different types of users to permit certain types of administrative delegation.
Therefore permitting a super set of users to administer passwords for a smaller sub-set of users of a certain user group.

So how do you create user groups? Use transaction SUGR to define the groups, then assign the users in SU01 or SU10.
Take a look at authorisation object S_USER_GRP.