Workflow Event Trace Leave On or Turn Off

[Kjetil Kilhavn]

Fredag 7. mars 2014 11.51.50 skrev Morris, Eddie:
> Hi Rick,
> 
> On most occasions the reason was pure volume...so I guess extremely large
> installations where the trace was left on (Accidently on some occasions)
> and the system just ground to a halt. You would see all dialog processes
> consumed by the trace functions and tables.

I would suspect that even on a not so large system it could bring it to its 
knees if there were a high volume of transactions that triggered events, 
especially if these events also started workflows that consumed dialog 
processes too.

I never leave it on in production without restricting to at least a set of 
object types. In practice it is not left on in production unless we either 
have a problem to investigate or we forgot to turn if off :-)

> 
> Regards,
> Eddie
> 
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of
> Rick Bakker Sent: 06 March 2014 22:49
> To: SAP Workflow Users' Group
> Subject: Re: Workflow Event Trace Leave On or Turn Off
> 
> Hi Eddie,
> 
> Thanks for sharing your (formidable) experience. Could you tell us more
> about the situations where this brought the system down? Luckily I haven't
> encountered such a problem yet but I sure would like to know about it.
> 
> I have found the event trace to be extremely useful in many cases. In the
> most trivial case it's good for convincing a user that yes, they did indeed
> press the Cancel button.
> 
> regards
> Rick Bakker
> 
> 
> On Thu, Mar 6, 2014 at 11:33 PM, Morris, Eddie
> <eddie.morris at sap.com<mailto:eddie.morris at sap.com>> wrote: Hi Rick,
> 
> Speaking from experience I have seen this take systems down on quite a few
> occasions so it can go horribly wrong. If you have someone who can monitor
> it and delete trace data when needed then I guess it is workable. Also use
> the trace restrictions when switching it on so only monitor a select number
> of events.
> 
> Also with note 1905199 a syslog entry (SM21) is written when an event
> linkage is deactivated so this can be used to check when the event linkage
> deactivation occurs. Then use the event trace to get specific information
> about the deactivation itself.
> 
> Regards,
> Eddie
> 
> From: sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>
> [mailto:sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>] On Behalf
> Of Rick Bakker Sent: 05 March 2014 22:17
> To: SAP Workflow Users' Group
> Subject: Re: Workflow Event Trace Leave On or Turn Off
> 
> Hi David,
> 
> I like to leave the event trace turned on. I have found this to be the case
> at most sites. Also, most workflow people I have worked with agree with
> this approach. The overhead is minuscule compared to the information it
> adds.
> 
> regards
> Rick Bakker
> 
> On Thu, Mar 6, 2014 at 3:29 AM, Edward Diehl
> <edwarddiehl at hotmail.com<mailto:edwarddiehl at hotmail.com>> wrote: It's not
> whether or not the trace is running, it's how often you delete "old"
> entries and reorg it.  Having said that, we have stopped using it to test
> for duplicate events and now check for duplicate workflows in a check
> function.
> 
> 
> Ed Diehl
> "Success consists of going from failure to failure without loss of
> enthusiasm."
> 
> ________________________________
> To: sap-wug at mit.edu<mailto:sap-wug at mit.edu>
> From: davidcooper06 at icloud.com<mailto:davidcooper06 at icloud.com>
> Subject: Workflow Event Trace Leave On or Turn Off
> Date: Wed, 5 Mar 2014 06:55:50 +0000
> 
> Hi All,
> 
> The following is more a discussion item!
> 
> I have read in various texts and heard from several workflow administrators
> that it is recommended to turn the workflow trace off in production.
> 
> Reasons:
> 1) The trace adds an overhead to the application and database servers, and
> 2) The trace fills up the event table(s) with data that is not needed over
> time.
> 
> My argument for leaving the trace running, is more for diagnostic reasons
> when problems occur in production.  It becomes another source for tracking
> down what happened.  Yes the overhead is a given, but I feel this is
> justified to capture the diagnostic information.  As for the database table
> being filled, implement a deletion strategy which purges the data from the
> table after a period of say 3 ,6, 9, or 12 months.
> 
> Kind Regards
> 
> David Cooper
> 
> Linked-In: http://www.linkedin.com/pub/david-cooper/47/616/36a
> 
> 
> 
> _______________________________________________ SAP-WUG mailing list
> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug

-- 
Kjetil Kilhavn / Vettug AS (http://www.vettug.no)