<br><font size=2 face="sans-serif">Florin,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Karl Nietz<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Rick Bakker <rbakker@gmail.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">"SAP Workflow Users' Group"
<sap-wug@mit.edu></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">21/01/2010 08:09 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: Extendend Notifications: Performance
on SWWLOGHIST</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hello,<br>
<br>
The lengthy first-time run of SWN_SELSEN is a one-off so I usually<br>
just let it go.<br>
<br>
I'm pretty sure the timestamp is stored in table SWN_TIMESTAMPS. You<br>
could always change this manually if you really want to, though of<br>
course it's not recommended.<br>
<br>
Note that the timestamps are stored like this:<br>
20,100,109,030,010.8190000<br>
=<br>
2010.01.09.03:00:10 GMT/UTC<br>
= translate to your own timezone<br>
<br>
It certainly would be nice if SAP changed this so that the database<br>
query would be more selective on the (usually) small number of tasks<br>
that it's looking for.<br>
<br>
regards<br>
Rick Bakker<br>
Hanabi Technology<br>
<br>
<br>
<br>
On Wed, Jan 20, 2010 at 6:19 AM, Florin Wach <florin.wach@gmx.net>
wrote:<br>
> 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.<br>
><br>
><br>
> -------- Original-Nachricht --------<br>
>> Datum: Wed, 20 Jan 2010 17:11:30 +0100<br>
>> Von: "Florin Wach" <florin.wach@gmx.net><br>
>> An: sap-wug@mit.edu<br>
>> Betreff: Extendend Notifications: Performance on SWWLOGHIST<br>
><br>
>> Hi dear wuggers,<br>
>><br>
>> I'm currently running the intial (first) run of SWN_SELSEN in
the<br>
>> production system. There's a filter active, restricting the notifications
down to a<br>
>> handful of tasks-ID's. There are relatively few users using the<br>
>> notifications (as receivers).<br>
>><br>
>> The run takes now 3 hours, where I can trace it down to a large
and<br>
>> time-consuming number of sequential reads on table SWWLOGHIST,
which I could<br>
>> track down to ABAP class CL_SWF_RUN_GET_WI_DLT_REQUEST.<br>
>><br>
>> Probably it's the method GET_DELTA_ENTRIES that ... when you run
it for<br>
>> the very first time, obviously gets a huge number of work items...
so to say.<br>
>><br>
>> Here is a statements that is sticking out:<br>
>><br>
>> SELECT hist~wi_id hist~method hist~timestamp<br>
>> FROM swwloghist
AS hist<br>
>> INNER JOIN swwwihead
AS head ON hist~client = head~client<br>
>> AND hist~wi_id
= head~wi_id<br>
>> INTO CORRESPONDING
FIELDS OF TABLE lt_swwloghist<br>
>> FOR ALL ENTRIES
IN lr_method<br>
>> WHERE hist~timestamp
GE me->im_timestamp<br>
>> AND hist~method
EQ lr_method-low<br>
>> AND head~wi_type
EQ swfco_wi_normal<br>
>> AND head~wi_rh_task
IN lr_task.<br>
>><br>
>> There's a secondary database index existing on SWWLOGHIST~002
for<br>
>> [ CLIENT , TIMESTAMP , METHOD ]<br>
>><br>
>> The join seems to be okay, since they match on the primary key
of WI_ID.<br>
>> Mayhaps the wi_id needs to be included in the database index,
making it the<br>
>> database easier to access the joined table w/o reading the record
set, yet<br>
>> at that stage.<br>
>> Furthermore, the swwwihead-table needs to be read fully for each
entry<br>
>> found at the swwloghist table.<br>
>> Hmm... Since the statement FOR ALL ENTRIES was used, a combined
where<br>
>> clause is generated, grouping about 5 to 10 select-clauses into
one statement.<br>
>> To the number of SELECT's is the number work items in the system
(since<br>
>> they're all within the requested me->im_timestamp (which is
zeroe at that<br>
>> time)).<br>
>><br>
>> ** Well, did anybody else came across that performance issue?<br>
>> ** Maybe someone knows the trick to manually set a timestamp,
so I can<br>
>> reduce the number of selects for the initial load?<br>
>><br>
>> We have 3,559,095 work items currently in the system.<br>
>><br>
>> Any ideas, even the most absurd one, are highly appreciated!<br>
>><br>
>> With the very best wishes,<br>
>> Florin<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> SAP-WUG mailing list<br>
>> SAP-WUG@mit.edu<br>
>> </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
><br>
<br>
_______________________________________________<br>
SAP-WUG mailing list<br>
SAP-WUG@mit.edu<br>
</font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>