This collective note describes several related problems:
(note version: 1/12/1995)
P1) No SysLog is written (Transaction SM21)
Instead, the SysLog messages appear in unedited form in
"stderr" files in the SAP WORK directory (also see Lx). It
is possible that only a few processes are affected by this
problem, and that other processes write to the SysLog correctly.
=>L01, =>U5
P2) The trace cannot be activated (Transactions ST01, ST05)
The system issues the error message "SCSA.SWB missing".
=>L09
P3) The system writes the following to stderr (or the appropriate
file):
sapscsa(1): shmget(SCSA): Invalid argument
sapscsa(5): recursive call
SysLog:dE07199308260903430014472 0TTDISPLAY0BENUTZER noTC
:sapcscsa001022Invalid argument
=>U3c
P4) The system writes the following to stderr (or the appropriate
file):
sapscsa(1): shmget(SCSA): No space left on device
=>U1
P5) The SysLog says:
E07 SCSA could not be generated
But it is there and appears to function properly.
=>U5
P6) The system writes the following to stderr (or the appropriate
file):
sapscsa(7): magis is ... but should be ...
sapscsa(8): version is ... but should be ...
=>U4
P7) When you shut down R/3, error messages appear in stderr
(also see L90) that come from modules whose name contains the
abbreviations "scsa", "scs", or "csa" (but not "zcsa").
=>U6
This note replaces the following notes: 143, 544, 2406, 3260, 5214,
10321
Cause and prerequisites
The SCSA is the "shared common system area", and is a small
shared memory segment accessed by all SAP programs.
What can happen to the SCSA?
U1) The SCSA cannot be defined because the operating system does not
have the necessary resources. Either too many (number) shared
memory segments have already been defined, or the defined segments
are too large (memory space). There are three limits you may
encounter:
U1a) Total size of all existing shared memory segments
Because the SCSA is very small, it is improbable that you
will exceed this limit.
U1b) Number of all shared memory segments in operating system.=>L40
U1c) Number of shared memory segments that can attach
a process simultaneously. =>L50
U2) The SCSA cannot be defined because R/3 has been installed or
configured poorly.
U2a) The "sapmscsa" program is not running =>L03,L04
U2b) Lengths or key values are poor (incorrect) =>L03
U3) The SCSA exists, but no connection can be established at C level.
U3a) It is owned by a different UNIX user and is protected
=>L03,L41.
U3b) The number of shared memory segments that can connect
to a process simultaneously is limited. =>L50
U3c) An old SCSA is shorter than expected (UNIX does not allow
connection) =>L03,L20
U4) The SCSA exists, a connection is established at C level, but
the SAP software does not like the SCSA:
U4a) The magic number (check digit, "eye-catcher") is incorrect
. =>L20
U4b) The version number is incompatible. =>L20
If L20 does not solve the problem, or only some of the programs report
this error, the reason for this may be that not all of the programs
have been included in an upgrade. =>70
U5) The SCSA does not appear to exist at first, but then appears.
Unfortunately, many R/3 Systems are configured in such a way that
the SCSA is regularly deleted, but is never generated properly.
Then, during system startup, all the programs start at once.
As a result, several programs may notice at the same time that
the SCSA is missing and needs to be created (also see L03).
One of them actually creates the SCSA, the others get an error
message when they attempt to create it, because it now exists.
In most cases, the system uses a combination of waits and
renewed attempts with the result that everything is ok in the end.
Unfortunately, during this activity, several processes may fail
in their access to the SCSA. =>L60
U6) The SCSA was deleted during operation.
What then happens depends on the operating system. Most
operating systems flag delete requests for shared memory and
do not perform them until the last user process has detached.
Therefore, once access is established, it is usually not
terminated.
However, if new processes are then started, they no longer see
the old SCSA and may create a new SCSA (depending on the flag
"scsa/shm/autocreate"). From this point, overwrites may
occur in the SysLog, as well as other, more serious problems.
There are two possible causes to this problem:
U6a) Incorrect use of delete tools like "cleanipc", "ipcrm", ...
U6b) "cleanipc" or "sapmscsa -r" is called as a stop action in
the STARTUP profile.
In the current situation, when the R/3 System is shut
down, it informs all the running processes that they
should stop processing, and the stop actions are then
performed one after another. Therefore, the first stop
actions are initiated while the system is still cleaning up.
=>L60
U7) The SCSA is overwritten during operation.
Can be tested with =>L08, L09
Two causes for this have been discovered:
U7a) The calendar buffer (factory calendar) was too small,
and its administration software wrote to the end.
U7b) Incorrect parameters used during the generation of ULTRIX
created a UNIX kernel that did not always separate the
address areas for the process-local memory (malloc)
and shared memory.
Ideal configuration:
a) The STARTUP profile first defines the SCSA and then starts all
other SAP programs. (If it already/still exists, it is
used further.)
b) The SCSA remains when the R/3 system is shut down.
c) During a release upgrade, the SCSA is deleted before the new
executables are used the first time.
d) The profile parameter "install/uid" contains the name of the UNIX
user who normally starts R/3 (e.g. "c11adm").
Different solution steps:
L01) Can a dialog work process access the SCSA?
Transaction ST01:
A date and time appears for the "Last change": o.k.
Otherwise, "SCSA.SWB missing" is displayed =>L09,L60
L02) Can SAP processes access the SCSA?
Almost all SAP processes write a SysLog message when they are
started.
When this message appears is in the SysLog (also see L91): o.k.
When this message was written after standard error,
(also see L90), the problem exists. =>L08,L60
L03) Have profile values been changed?
(also see L92)
scsa/create_daemon/exe_file are not normally changed!
scsa/shm/file
scsa/shm/key
scsa/shm/size
scsa/shm/start
scsa/autocreate
Value 0 : SCSA is always (and only) generated by the STARTUP
profile with 'sapmscsa'.
Value 1 : Every program that is missing the SCSA should attempt
to generate it.
install/uid
UNIX user, that normally starts R/3 (e.g. 'c11adm').
L04) Do programs exist?
The profile value (also see L92) of "scsa/create__daemon/exe_file"
contains the name of program "sapmscsa".
Does the program exist and is it part of the current R/3 release?
L05) Does the SCSA exist?
SAP command 'showipc
(also see L93, L94, L95)
L06) If the SCSA exists, how long is it?
UNIX command 'ipcs -a -m'
The key is taken from profile parameter "scsa/shm/key" and
normally has the value 58900100 + instance number
(hexadecimal number between 382BE84 and 382BEE7).
Also check the owners and authorization bits.
L07) Is the length of the SCSA correct?
The length is in profile parameter "scsa/shm/size"; in
Release 0.4 to 2.0 : 1024
Release 2.1 onwards : 4096
If the existing SCSA is too short (e.g. after release upgrade
from 2.0x to 2.1x), it cannot be used, and must be removed =>L20
L08) Can the SCSA be used for the SysLog?
SAP command (also see L93)
rslglscs pf=...
If problems occur with the magic number or the version number,
you should remove the SCSA. =>L20
L09) Can the SCSA be used for the trace?
SAP command (also see L93)
rstrlscs pf=...
If problems occur with the magic number or the version number,
you should remove the SCSA. =>L20
L20) Removing a bad SCSA:
+ Shut down R/3
+ Remove the SCSA: (either or)
- SAP command sapmscsa pf=... -r
- SAP command cleanipc
- UNIX command ipcrm -M
- reboot the operating system
+ redefine SCSA: (also see L30)
- SAP command sapmscsa pf=...
+ Restart R/3
L30) Defining a new SCSA
SAP command sapmscsa pf=...
If error messages are issued:
shmget(scsa):No space left on device =>U1
shmget(scsa):Invalid argument =>L07
other error message:
try again with unix command man shmget ...
L40) Check whether other shared memory segments can be deleted:
Use UNIX command ipcs -m or ipcs -a -m
to view the list of all shared memory segments.
Do shared memory segments still exist from old SAP instances
that were not shut down properly? Yes: =>L42
Do shared memory segments exist that were created by test
programs and that can be deleted? If yes: UNIX command ipcrm
Otherwise: =>L41
L41) Completely clearing out the shared memory:
+ Save the ipcs in a file or print out
+ properly shut down all the applications on that computer
+ shut down all databases and similar services
+ Reboot the operating system. The system now starts with
empty shared memory.
+ Restart all required databases, services, and applications
+ Does the ipcs list look better now?
Yes: ok.
No: Machine is overloaded. (either/or)
- Leave out several applications or services
- Configure a larger shared memory in the operating system
(no. of segments, no. of open segments, no. of bytes)
=> Information on "uxgen"
=>Note 2813
L42) Removing shared memory from an SAP instance that terminated:
+ Find out which instance number was involved
+ Is this instance really no longer running?
+ Use SAP command showipc
+ Use SAP command cleanipc
or cleanipc
L50) Reduce the number of shared memory segments that are open at once:
For most shared memory segments of the SAP system, there is an
option to assign them to more or fewer SAP shared memory pools.
Then, only those (few) pools will appear to the operating system
as "segments".
For more information, please refer to: =>Note 05076
=>Note 12655
=>Note 07178
=>Note 06512
The SCSA itself cannot be pooled. However, when the number
of other segments is reduced, this will help.
L60) Many R/3 Systems were configured such that they
regularly delete the SCSA, but never properly generate it
(also see U5). In the STARTUP profile, the first SAP program
that is started should be "sapmscsa pf=...". The system should
then wait for the program to end. Example:
_PF = $(DIR_PROFILE)/DVBMGS00
Execute_01 = local $(DIR_EXECUTABLE)/sapmscsa pf=$(PF)
You will then no longer have to set profile flag
"scsa/autocreate" to 1.
"cleanipc" or "sapmscsa -r" should not be called at all
in regular STARTUP profiles (also see U7b)
You should only call "sapmscsa -r pf=..." during an upgrade,
after R/3 has been shut down.
L70) Check whether all SAP programs have the same release:
Unfortunately this is not easy. You can look at the files
in the SAP-EXE directory:
cd /usr/sap/C11/SYS/EXE/RUN
ls -l disp+work dwora rslgsend rslgcoll sapmscsa
Usually the date when the programs were copied during the
installation or during an upgrade is displayed.
L90) The SAP processes are normally started in such a way that their
error output is written to files called "stder1", stderr2", etc.
These can be found in the work directory at operating system
level (e.g. /usr/sap/C11/DBVMSG00/work/ ).
They can be displayed in R/3 with transaction ST11.
L91) Analyzing the SysLog:
Transaction SM21, select "local SysLog",
enter other times on the selection screen when necessary.
If R/3 is not active, you can also use the (much less user-
friendly) SAP program "rslgview pf=..." to view the SysLog.
L92) Analyzing profile values:
Report RSPFPAR, check the second half of the list.
Outside R/3, use command
sapparar pf=... all or
sapparar pf=... all
L93) "SAP commands" are SAP programs that are started at operating
system level. They are all in one directory, which is
called '/usr/sap/C11/SYS/exe/run/' or similar.
In addition to other parameters, you normally have to
specify the name of the SAP profile for pf=...
L94) The "Instance number" is two digits, often "00", and is,
unfortunately, also sometimes called the "system number".
It may appear in the profile. For most programs, however,
it can also be specified with nr=.. (next to pf=...)
Manche Kommandos untersuchen auch die Environmentvariable
'SAPSYSTEM'.
L95) SAP command "cleanipc" (also see L93)
"IPC" stands for "inter-process communication", and includes
shared memory as well as semaphores and message queues.
Also see L93. "Cleanipc" does not require a profile.
The command "cleanipc
To Release 2.1C: deletes all IPCs in the instance
From Release 2.1D: displays all IPCs in the instance
The command 'cleanipc
From Release 2.1D: deletes all IPCs in the instance.
Important: an active R/3 requires IPC like a person needs blood.
Only delete it after you have shut down the system.
Related SAP commands: "showipc" and "ipclimits"
Related UNIX commands: "ipcs" and "ipcrm".
L96) Determine the key for 'SCSA Shared Memory' and 'SCSA Semaphore'
as user
- 1. The R/3 System must be stopped, or must be stopped prior to the actions
- 2. showipc all
we are interested in all lines with SCSA as text for example,
OsKey: 58900100 0x0382be84 SCSA Shared Memory
OsKey: 58900200 0x0382bee4 SCSA Semaphore
- 3. ipcs | grep 0x0382be84
specifies owner and ID of Shared Memory
m 22 0x0382be84 --rw-rw-rw h21adm sapsys
in this example ID 22 and owner h21adm
- 4. ipcs | grep 0x0382bee4
specifies owner and ID of Semaphore
s 21 0x0382bee4 --ra-ra-ra h21adm sapsys
in this example ID 21 and owner h21adm
- 5. deleting Shared Memory and Semaphores:
ipcrm -m 22 or ipcrm -M 0x0382be84
ipcrm -s 21 or ipcrm -S 0x0382bee4
- 6. Subsequently check with showipc, whether the action was successful.
No comments:
Post a Comment