AutoSys Workload Automation

 View Only
  • 1.  Ramping up autoaggr statistics

    Posted Apr 18, 2018 10:39 AM

    After years of collecting various AutoSys run statistics, we plan to use the built-in features.  It's enabled by default in versions later than our production settings and would likely begin in the background when we upgrade, so we wanted to get a head start.  While the documentation is helpful, learning by doing always reveals more.

     

    Manual statistics collection

     

    The manual suggests one could collect statistics "manually" with sendevent -E AGGREGATE.  I learned that trying to limit that collection to only monthly values didn't work as expected.  The "-l MONTHLY" parameter triggered hourly, daily, and weekly data collection.  I'm okay with that, as I was going to run those afterward, but those dependencies were not obvious from the documentation.

     

    Statistic run times

     

    In a recent askCA session I posed the question of how long the collection would run, as the documentation is necessarily vague here, given the wide range of hardware, software, data volumes and other factors.  For around 1 million job run data records in a test environment, the manual stats roll-up was under 2 hours (Oracle/AIX)

     

    [04/14/2018 09:09:19] CAUAJM_I_40300 Starting manual hourly aggregation of product statistics.
    [04/14/2018 10:43:35] CAUAJM_I_40301 Completed manual monthly aggregation of product statistics.

    Production has many more records; I'll post the duration once we get those done.

     

    Oddities

     

    • Collection included runs back several years; still need to find if these are orphan records or just old jobs not run since then. 
    • The monthly collection stopped on February. (Aggregated monthly statistics from [02/01/2018 00:00:00] to [02/28/2018 23:59:59]).  I'd have expected to see March but not April per the documentation.

     

    Concerns

     

     

    • The "delete statistics" function appears to be all-or-nothing.  It would be helpful to be able to set retention periods, though not that critical as we'd likely pull the values into another system for trending and analyses.
    • Space in the database needs to be managed.  We plan to move the reporting table structures into a separate tablespace to prevent space shortages.
    • Some documented parameters don't make sense, such as the stated requirement for double quotes around the target filename for autoaggr reports:
      • autoaggr -h -c -J -o "/tmp/job.csv"   works just as well as
      • autoaggr -h -c -J -o /tmp/job.csv so maybe quotes only needed if there are spaces in the path?
    • When I looked at the database before starting manual collection, the reporting tables did not exist.  At first I was concerned that the prior install was incomplete, or the feature was only in later versions, but the tables were created in the background without DBA intervention.  In some situations, this might create alerts.  It would be helpful to be able to create the reporting structures in a target tablespace before populating.


  • 2.  Re: Ramping up autoaggr statistics

    Posted Apr 18, 2018 01:35 PM

    Rereading the man page, this looks like a clause in the wrong section:

     

    -o filename
    ( Optional) Defines the path and file name ...

    * You can specify only the file name [...]

    * For readability purposes, ...

    * Enclose the start date and time in double quotation marks.

     

    Hence my comment above about quotes.



  • 3.  Re: Ramping up autoaggr statistics

    Posted Apr 20, 2018 01:04 PM

     I'd have expected to see March ...

     

    Ticket response says this is "Problem Number: 4610".

     



  • 4.  Re: Ramping up autoaggr statistics

    Posted May 08, 2018 09:20 AM

    March statistics rolled up in May (we have an old version with known DST bug).

     

    We found using the command line autoaggr against a different version could trigger errors indicating field mismatch:

     

    GET_STATISTICS failed.

    p->func_ret_code_ = 6

     



  • 5.  Re: Ramping up autoaggr statistics

    Posted May 10, 2018 09:41 AM

    autoaggr is internalized now. But i never found the data overly useful.. myself. i rather just data mine like always or use WCC reports etc.

     

    my big issue are the extended calendar code changes.. *sigh*

     

    just my 3 cents ..

     

    Good luck Jim.. (i am a programmer not a mechanic)