Ansicht
Dokumentation
01700 - 4.6C:SQL913 on D020L after maintenance?
BAL_S_LOG - Application Log: Log header data Addresses (Business Address Services)This documentation is copyright by SAP AG.
4.6C:SQL913 on D020L after maintenance?
Hi Jim,> -----Original Message-----
> From: Jim Doll [mailto:JDOLLZp...]
> Sent: Dienstag, 10. April 2001 16:07
> To: Gueldenpfennig, Volker
> Subject: Re: RE: 4.6C:SQL913 on D020L after
> maintenance?
>
>
> Volker: we've been running our current copy of 4.6C for a
> little over a month. Yesterday, we saw this LCKW condition.
> I ended up cancelling several transactions, and it eventually
> cleared itself up.
>
> From the "waiting for record..." messages, I found that the
> system was trying to generate SAPLCOKO, screen 5115.
> (D010SINF and D020L)
>
> I had originally built this system ("Q46") on 3/10 by
> upgrading a copy of our 3.1H PRD system. I ran SGEN,
> selecting all components that we run.
>
> One of the people that got stuck in LCKW thought that he had
> run this transaction earlier, but wasn't sure.
>
> Question 1: is there some reason that the system would try
> to regenerate a program or a screen (no changes made that I can find)?
To Question 1: Normally the things are regenerated because of changes in
tables or even structures and so on. Every ABAP and Dynpro, that contains a
structure or table that was changed, becomes regenerated automatically and
causes such problems.
This happens very often with records with a low record number, because these
ones were generated first automatically and are used "every second"
automatically. When these ones have to be regenerated SQL0913 is very
likely, because "every WP" needs them and tries to wait for a commit in the
other WP that generated this one. Unfortunately this other one waits mostly
for a generation that was already done in this job. As normally one job wins
in this deadslock-situation, it should clear up after some time because the
winning job will issue a commit soon and then the problem is solved for this
object.
We use the waitrecord-value multiplied by 4 because we use 3 retries. So it
may be helpful to reduce especially the waitrecord of table D020L perhaps
down to 5!
>
> Question 2: As I mentioned, I ran SGEN already on Q46. But
> there are still pieces that are generated after that,
> apparently even after a month. Is there a way to use what
> has been generated on Q46 as input to the SGEN on PRD, in
> order to get a more complete list? Or, even better, but
> probably less likely, can I save the D010 & D020 tables from
> Q46 and restore to PRD and skip SGEN entirely?
To Question 2: Unfortunately I'm not aware of such a solution that you can
use this as input again. I would warn to do a SAVOBJ and RSTOBJ of these 2
tables because the timestamps of the sources in the PRD system are different
of the Q46. So it may occur really random things!
>
> Question 3: It looks like the default for the wait time is
> 120 seconds. Is that a retry value or a timeout value?
> Several of the LCKW transactions were in the 200-300 second
> range--why didn't they time out?
To Question 3: We use 120 seconds and give 3 retries. So SQL0913 in the ST22
should normally show up after about 8 minutes.
>
> Question 4: Related to question 3: if this is a timeout
> value, changing it from 120 to 15 won't fix it, will it? It
> will just fail more quickly, so people can retry, rather than
> just sitting on LCKW, correct?
To Question 4:
That's true!
It is no solution, they just get kicked out earlier (about after 1 minute).
As 1 job wins, the problem shouldn't reoccur on this object again, because
it is generated and comitted then.
>
> Question 5: Can I change these tables ahead of time, and
> just leave them at 15? Will that hurt anything else later?
To Question 5:
It shouldn't hurt you to leave them at 15 or even change D020L down to 5.
>
> Thanks, Volker!
>
> Jim Doll, Perrigo
Regards
Volker
> >>> "Gueldenpfennig, Volker" <volker.gueldenpfennigZs...>
> 01/10 11:57 AM >>>
> Hi all,
>
> we improved the note 357330 and translated it already into
> english. This may
> help in these problems. When there are still problems that the system
> doesn't "clear up" after a few minutes, please open OSS messaages
> for/against this issue.
>
> The interesting tables against the LCKW problems are:
> (Please log on with the SIDOFR beofre and stop the SAP system)
> CHGPF FILE(EUDB) WAITRCD(15)
> CHGPF FILE(D010LINF) WAITRCD(15)
> CHGPF FILE(D010SINF) WAITRCD(15)
> CHGPF FILE(D010L) WAITRCD(15)
> CHGPF FILE(D010Q) WAITRCD(15)
> CHGPF FILE(D010Y) WAITRCD(15)
> CHGPF FILE(D020LINF) WAITRCD(15)
> CHGPF FILE(D020L) WAITRCD(15)
> CHGPF FILE(D021LINF) WAITRCD(15)
> CHGPF FILE(D021L) WAITRCD(15)
>
> Regards
>
> Volker Gueldenpfennig
>
Durban Tours - Südafrika Safari
BAL_S_LOG - Application Log: Log header data Addresses (Business Address Services)
This documentation is copyright by SAP AG.
Length: 5827 Date: 20240520 Time: 222633 sap01-206 ( 3 ms )
