Extendend Notifications: Performance on SWWLOGHIST
Florin Wach
florin.wach at gmx.net
Thu Jan 21 07:20:30 EST 2010
Hello Rick,
Hello Karl,
thank you very much for these two valuable replies, as when I put both information together, the problem seemed to be solved now.
Here's the explanation:
I'm already using only DELTA filters, although there is an ALL_FULL filter, but this is not checked at the selection, so it's there, but it's not active.
I have debugged down to the SELECT statement and tracked back to where the timestamp was read. In fact, although the DELTA filter was used, the ALL_FULL still throws in between (probably, when the DELTA filter has no timestamp set itself).
With the hint from Rick I could manually create a time stamp entry for DELTA, using the ABAP OO class CL_SWN_FILTER, create an instance, execute method LOAD_INSTANCE, use ID=WORKLOW, SCENARIO=STANDARD (or whatever was appropriate), then select the interface IF_SWN_FILTER and execute method SET_LAST_APPLIED and... e voila ... enter the TimeStamp number here. (I have written a small report to run in the D-System to write the timestamp to copy it into that field. It's basically the exact format, Rick gave).
After doing so, the runtime went down to a few seconds.
If you don't hear from me any further, the problem was solved.
Thanks for these two ideas, once again.
Florin
-------- Original-Nachricht --------
> Datum: Thu, 21 Jan 2010 11:18:05 +1000
> Von: Karl Nietz <knietz at csc.com.au>
> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
> Betreff: Extendend Notifications: Performance on SWWLOGHIST
> Florin,
>
> I have experienced this issue and it is indeed vexatious. You can set the
> timestamp with the test version of SWN_SELSEN. There are also a couple of
> OSS notes that inadequately address the runtime of the program. The site
> at which I implemented extended notifications also had millions of entries
> in the log history file, and from memory this file is accessed when
> running the program with the FULL filter, but not the DELTA filter. So
> the initial run took over 8 hours, or usually just timed-out. So it
> seemed to me that setting the timestamp had no impact in reducing runtime
> because the program run with FULL filter still read through that ghastly
> log history file. Archiving data would solve the problem but if the site
> is not already using archiving then it is unlikely that it will be
> implemented together with extended notifications. The only way i was able
> to make the funcitonality workable was to dispense with the FULL filter
> alltogether and only use the DELTA filter.
>
> Karl Nietz
>
>
>
>
> From:
> Rick Bakker <rbakker at gmail.com>
> To:
> "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Date:
> 21/01/2010 08:09 AM
> Subject:
> Re: Extendend Notifications: Performance on SWWLOGHIST
>
>
>
> Hello,
>
> The lengthy first-time run of SWN_SELSEN is a one-off so I usually
> just let it go.
>
> I'm pretty sure the timestamp is stored in table SWN_TIMESTAMPS. You
> could always change this manually if you really want to, though of
> course it's not recommended.
>
> Note that the timestamps are stored like this:
> 20,100,109,030,010.8190000
> =
> 2010.01.09.03:00:10 GMT/UTC
> = translate to your own timezone
>
> It certainly would be nice if SAP changed this so that the database
> query would be more selective on the (usually) small number of tasks
> that it's looking for.
>
> regards
> Rick Bakker
> Hanabi Technology
>
>
>
> On Wed, Jan 20, 2010 at 6:19 AM, Florin Wach <florin.wach at gmx.net> wrote:
> > follow-up: I have checked SAP-Note 1105696 which seemed to be promising
> to solve the issue, however, that particular object method is not included
> ... and the note changes the statements from an even worse one to the one,
> which is already used where I have the problems with.
> >
> >
> > -------- Original-Nachricht --------
> >> Datum: Wed, 20 Jan 2010 17:11:30 +0100
> >> Von: "Florin Wach" <florin.wach at gmx.net>
> >> An: sap-wug at mit.edu
> >> Betreff: Extendend Notifications: Performance on SWWLOGHIST
> >
> >> Hi dear wuggers,
> >>
> >> I'm currently running the intial (first) run of SWN_SELSEN in the
> >> production system. There's a filter active, restricting the
> notifications down to a
> >> handful of tasks-ID's. There are relatively few users using the
> >> notifications (as receivers).
> >>
> >> The run takes now 3 hours, where I can trace it down to a large and
> >> time-consuming number of sequential reads on table SWWLOGHIST, which I
> could
> >> track down to ABAP class CL_SWF_RUN_GET_WI_DLT_REQUEST.
> >>
> >> Probably it's the method GET_DELTA_ENTRIES that ... when you run it for
> >> the very first time, obviously gets a huge number of work items... so
> to say.
> >>
> >> Here is a statements that is sticking out:
> >>
> >> SELECT hist~wi_id hist~method hist~timestamp
> >> FROM swwloghist AS hist
> >> INNER JOIN swwwihead AS head ON hist~client = head~client
> >> AND hist~wi_id = head~wi_id
> >> INTO CORRESPONDING FIELDS OF TABLE lt_swwloghist
> >> FOR ALL ENTRIES IN lr_method
> >> WHERE hist~timestamp GE me->im_timestamp
> >> AND hist~method EQ lr_method-low
> >> AND head~wi_type EQ swfco_wi_normal
> >> AND head~wi_rh_task IN lr_task.
> >>
> >> There's a secondary database index existing on SWWLOGHIST~002 for
> >> [ CLIENT , TIMESTAMP , METHOD ]
> >>
> >> The join seems to be okay, since they match on the primary key of
> WI_ID.
> >> Mayhaps the wi_id needs to be included in the database index, making it
> the
> >> database easier to access the joined table w/o reading the record set,
> yet
> >> at that stage.
> >> Furthermore, the swwwihead-table needs to be read fully for each entry
> >> found at the swwloghist table.
> >> Hmm... Since the statement FOR ALL ENTRIES was used, a combined where
> >> clause is generated, grouping about 5 to 10 select-clauses into one
> statement.
> >> To the number of SELECT's is the number work items in the system (since
> >> they're all within the requested me->im_timestamp (which is zeroe at
> that
> >> time)).
> >>
> >> ** Well, did anybody else came across that performance issue?
> >> ** Maybe someone knows the trick to manually set a timestamp, so I can
> >> reduce the number of selects for the initial load?
> >>
> >> We have 3,559,095 work items currently in the system.
> >>
> >> Any ideas, even the most absurd one, are highly appreciated!
> >>
> >> With the very best wishes,
> >> Florin
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> SAP-WUG mailing list
> >> SAP-WUG at mit.edu
> >> http://mailman.mit.edu/mailman/listinfo/sap-wug
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
More information about the SAP-WUG
mailing list