Automic Technical Help needed (round 2): Manually updating AWA tables...

[Reed Byers]

We tried to make Automic's multiple-client idea happen, so that we could have a long retention period for most jobs, but a short retention period for sleep/wake jobs.

But then we realized that we are relying on the "single run" attribute and SYNC objects, to prevent certain jobs from running at the same time -- and some of those are sleep/wake jobs, and some AREN'T.  We can't move ALL dependent jobs to the sleep/wake client, because:
   1) We want non-sleep/wake job history to stick around for 410 days, and
   2) We can't ask our customers to check a list of jobs to see which client to log into, to run them.

So one more try: Is there an Automic-approved SQL script that would change the official run dates of a workflow in history (and all of its children)?  This would really be a lifesaver for us.  We just can't afford to screw up our AWA database while fumbling around trying to do it ourselves.

Failing that... how bad would things get, if we let 20 jobs that run every 2-3 minutes, pile up in the execution history, for 410 days?  Can AWA cope with that?  Would we slow to a crawl and crash?  (I realize that it's at least partially resource-dependent, but...?)

The best thing, of course, would be a feature that let us have different retention periods for different jobs on a single client.  But that's probably never going to happen.  At least, certainly not anytime soon...

Anyone out there (preferably from Automic) up to rescuing us?

Sorry for the grief, and thank you for any help...

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

[Christoph Rekers]

Hi @Reed Byers,

Instead of ​trying to modify the "run dates" I would consider to set the Archive and Reorg flag (*_archiveflag) via SQL. The DB-Unload just checks for those flags and removes all data sets with a value of 1. 


Cheers
Christoph 


------------------------------
----------------------------------------------------------------
Automic AE Consultant and Trainer since 2000
----------------------------------------------------------------
------------------------------

[Pete Wirfs]

Neat idea!  I might want to use this as well.  I checked my database to see which tables have an ArchiveFlag attribute, and it found them on AH, MELD, RH, and XAO.

------------------------------
Pete
------------------------------

[Krum Ganev]

From the top of my head i could think of a few possible solutions :
1. Using Automic DB utilities on a daily basis:
  - DB Archive - to create an archives of the data in AH, RH and MELD. This archives will be created on the server used for starting the utility and can be transfered afterwards.
- DB Archive Browser - to 'read' the archives
You need to evaluate how big are the archive files for a single day and calculate how much space would be required.
2. Using the basic installation of Analytics (Backend+Datastore).
- The Backend will fetch the data for the object executions from the AE DB and transform it slightly. (Different table names).
- The Datastore (PostgreSQL) will keep that data. You can adjust the retention period independently from the retention period of the AE DB.
Hence you can keep last 30 days in Automic and last 400 days in Analytics.

Out of curiosity - how many executions you have per day and what is the current DB size (used/total)?
As the job reports are the main chunk of the space used you could be able to achieve a higher retention period for the job stats with a low retention period for the job reports with the same amount of space required.