Extendend Notifications: Performance on SWWLOGHIST

[Karl Nietz]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20100121/51efea1f/attachment.htm