Extendend Notifications: Performance on SWWLOGHIST
Mike Pokraka
wug at workflowconnections.com
Mon Feb 8 10:51:10 EST 2010
There is a mention somewhere either in an OSS notes or in the documentation
that the first run will take a long time, so I've never been too worried
about it since it's a once off.
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Florin Wach
> Sent: 21 January 2010 12:21
> To: SAP Workflow Users' Group
> Subject: Re: Extendend Notifications: Performance on SWWLOGHIST
>
> 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
> >
> >
> _______________________________________________
> 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