RT table getting HUGE

[Reed Byers]

I see this topic has been addressed before, but not necessarily from the perspective I'm coming from.

We are in the process of bringing up AWA in Production for the first time (having migrated from Appworx/Application Manager).

We are using a large number of PSETs in an Include file, for constants that we want every job to have access to -- and our RT table is growing HUGE as a result of all the log messages.

Yes, in hindsight, we should have used a static VARA for our constants, but at this point we'd be looking at a LOT of code to change and retest...

And yes, we really prefer to keep our logs in the database, if at all possible.

What we're hoping for is:

1) Some way to tell AWA "don't log all those PSETs in RT".
or
2) Some way to safely prune RT of all these PSET log messages.  (i.e. something like DELETE from RT where RT_MSGNR = 20206)

We GREATLY prefer not monkeying with the AWA database... but RT will soon become unmanageable if we don't do something.

NOTE: We run database maintenance weekly.

Any thoughts/suggestions?

Thanks...

------------------------------
Reed Byers
Programmer/Analyst
Oregon State University
------------------------------

[Frank Muffke]

Hi

1) no possibility to my knowledge
2) no possibility to my knowledge

=> Best solution is tuning your REORG/Unload parameters, reduce amount of kept statistics, reports to a minimum - or run REORG/unload more often then RT content should be (a bit) more stable

KR Wolfgang

------------------------------
Support Info:
if you are using one of the latest version of UC4 / AWA / One Automation please get in contact with Support to open a ticket.
Otherwise update/upgrade your system and check if the problem still exists.
------------------------------

[Tony Ferraro]

You could the archive/reorg/unload more than once a week as its an online activity.

[Patrick Tiller]

We have the same situation, we use includes and psets on every job and workflow. Our solution was to only save seven days of reports in non-prod and 30 days in prod, then run the DB maintenance workflow on a daily basis - that keeps our RT table under control.

[Carsten Schmitz]

Hi.

I think most things about this have been said - i.e. pretty much the only option is the pruning of RT with the cleanup process and rather aggressive cleanup settings. We also clean aggressively here, not because of PSET but regular reports; yes, this means sometimes we don't have reports when we'd like to, but it's a trade-off between performance and audit capability.

But one more thing: You say you use constants. If these are constants, that means they will only be read. That's probably fine (apart from the RT growth). I strongly advise you not to go overboard with variables that get read and written by all or many jobs though. It's easy to go over board with this, some of our people have written a sort of "job locking" and elaborate frameworks like this. And it leads to horrible DB deadlocks when one job still holds the variable and another tries to update it.

Best regards.