Sometimes beas or SBO may be blocked (Program crash, or hang up. If beas is ended, SBO keeps running. Reason may be a deadlock on the SQL-Server.
Before searching for the error, restart the SQL-Server. Especially after updating SBO a restart of the SQL-Servers is recommended, to release memory.
In Work station settings wizard Current connections it is displayed, which stations are blocked and which SQL-command is currently executed.
If beas cannot be started at all, on the SQL-server using a SQL-command you can determine, which station is causing the deadlock.
select left(sp.hostname,30), sp.program_name, sp.spid, sp.blocked+0 as blocked_from_spid, left((select sp1.hostname+ from master.dbo.sysprocesses sp1 (nolock) where sp1.spid=sp.blocked),30) as blocked_from_station, sp.open_tran from master.dbo.sysprocesses sp (nolock), master.dbo.sysusers su (nolock) where sp.hostname > and sp.uid = su.uid ;
Spid is the connection.
Blocked From Spid shows, that this Spid is blocked by the shown Spid.
It may be, that more than one Spid are affected: if for example Spid (Connect) 50 is blocked by 51, that one can be blocked by 55 and that one by 30. Then, the reason is not Spid 51 but 30.
Use the following statement to find out, which SQL-statement causes the blockage for Spid 30
(returns the SQL-statement of Spid 30)
Before creating a ticket
If a blockage occurs several times:
Find out, which Spid causes the problem (see above)
Determine station name, Program name using the above mentioned SQL-Statements
Use dbcc inputbuffer (spid-Id)" to determine the SQL-Statement
Find out what the user did at last
Spid-Id is the number of the originator (see number 1)
For each blockage information needs to be determined new. Only this way you an find out if it is a hardware or a software problem and what to do.
Important: only the originator is of interest
What could be possible reasons?
Next to software errors the hardware can cause deadlocks:
server or SQL-service overload,
not enough memory or operation in 32-Bit-environment
other processes running in parallel ( eg. backup)
faulty cables, network adapters, broken switch/hub
faulty drivers, wrong configuration, virus
There may be various reasons. It is often not that easy to find the reason, the support can only help, if the client analyzed the problem in detail before. 80% of all cases were related to hardware problems.
Always the same station is the originator although the same operations are performed on other stations. The error causing SQL-statements are different. Then, the actual reason is the work station itself, the connected network cable or the hub.
Various work stations are originators but the blocking SQL-statement is always the same. In this case, one can assume that a software error is the cause.
Troubleshooting without restart of SQL-Server
First, the real cause needs to be determined. Then, the causing statement can be removed using:
Ends the connection for Spid 30.
There is no need to restart the SQL-Server. beas and SBO re-establish the connection immediately. It may be, that on the affected work Station SBO or beas needs to be restarted.
to release the block, use kill command
closes connection for Spid 52. Now, the SQL-Server does not need to be re-started after a malfunction. beas usually re-establishes the connection after issuing an error message.
in case of SQL-error: select isnull(max(eventnumber),0) from beas_event where touser=...
This statement checks regularly, if new messages are available. But many users do not work with the message system of SBO or beas
In this case you can disable per user:
SAP - Administration - System Initialization - General Settings - Services - "Inbox for new messages" please disable for each user.
Alternatively (without guarantee): Deactivation for all users with the following SQL-Statement:
update ousr set shownewmsg='N'
If necessary it can be activated again.