Automic Workload Automation

Expand all | Collapse all

DB Revision Report

  • 1.  DB Revision Report

    Posted 11-13-2015 07:37 AM
    Hi all,

    For audit reasons we are considering to enable logging for the Revision Report in our UC4 Systems.

    My concern so far is, how much burden this will have on the overall performance of the system. And how much more disk space will be required ?

    Have you enabled logging for revision report (OBJECT_AUDIT = "Y" in UC_CLIENT_SETTINGS), then please share your experiences.

    Thanks in advance !

  • 2.  DB Revision Report

    Posted 11-30-2015 06:24 PM
    Enabling Auditing for your system shouldn't impact performance unless users are running a large number of queries through the UI.
    The reason the DB Utilities are built as separate components is to lessen the impact on system performance by separating the process from the core AE.

    How much more Disk space is hard to judge, it depends on how active your system is and how long you keep records in the DB for.

  • 3.  DB Revision Report

    Posted 01-11-2016 08:20 AM
    >@</p>Jennifer Jinhong" 
    Do you know in which tables "Object Audit data" are stored ? The reason I ask, is that we will have to set up some kind of monitoring of those tables to avoid any unpleasant surprises due to this.

  • 4.  DB Revision Report

    Posted 09-14-2016 06:49 AM

    Hello Keld_Mollnitz  

    This question cannot be answered with a single sentence. So I would like to know if you still need answers or if you know already what you need to know.

    KR, Josef

  • 5.  DB Revision Report

    Posted 09-14-2016 06:58 AM
    Hi Josef,

    It's stored in the XAO table, right ?


  • 6.  DB Revision Report

    Posted 09-14-2016 07:14 AM

    Well, that’s right, but it’s not the whole story. I’ll try to give a complete picture in the next days ... 

  • 7.  DB Revision Report

    Posted 09-20-2016 02:09 AM

    The AE DB Revision Report can create detailed information reports on:

    • Task starts
    • Modifications at runtime
    • Task abortions
    • Imported objects
    • Deleted objects
    • Object modifications
    • Accesses of any kind

    Some of the underlying data is collected automatically anyway.

    Task start for example, is basically theStatisticwhich is stored in theAH table. So the Revision Report takes this data from the AH table.

    For tracking object modifications there is already another feature, theVersion Management for Objects, which is stored in thetables OH and OX. Version Management is automatically activated when the logging for the Revision Report is activated.

    Information which is not available so far, is stored in theXAO table.


    When a report in created using the UCYBDBRR program, it will collect data from the tables mentioned above, based on the parameters given.

    Note:Only when the start parameter –A is used the archive flags are set. The DB Reorg process will only remove entries from the database where the archive flag is set.

    For example:If a system is sowing the effect that Version Management Objects are not deleted after 30 days, which is set for the DB Reorg process (and it's running ok), the reason can be that no Revision Report was created so far (or the –A parameter was not used).


    In the end the AE DB Revision Report is a very powerful feature, however when is swicht on, it’s recommended to run reports regularly to avoid growing DB tables.

    Enjoy the Revision Report!
    KR, Josef

  • 8.  Re: DB Revision Report

    Posted 04-15-2019 01:14 PM

    Hi Josef_Scharl_103.  I am not quite clear on what you mean about the -A flag.  I'm contemplating turning on the revision report as well.  We currently keep AH records for 400 days and RH, MELD records for 125. If we enable the revision report (object_audit = y in UC_CLIENT_SETTINGS) then we would also probably set it in the UC_UTILITY_REORG to keep 125 days for OBJECT_AUDIT as well.  Where does -A flag come in.  I'm not quite sure.  Thanks.

  • 9.  Re: DB Revision Report

    Posted 04-17-2019 04:15 AM

    Hi Laura,

    The parameter –A of the UCYBDBRR program marks the entry in the XAO table as “Reversion Report was created – therefore it’s ok to reorganize the record”. I think this should prevent the UC4 DB.Reorg / DB.Unload from removing XAO entries before a Revision Report was created.


    I’ve seen many environments where Object Audit was switched on, but no / not all Reversion Reports were created ==> this causes a growing XAO table …


    However there is also the “Only reorg revised Object Audits” option at the DB.Reorg utility. I think when it’s not activated it will remove XAO entries, regardless if they were already used for a Report or not:


    I hope this makes it clearer.
    Anyhow, I would recommend to keep an eye on the XAO table after activating Object Audit.


  • 10.  Re: DB Revision Report

    Posted 04-28-2019 08:19 PM

    Hi Laura,


    Basically the Audit records are in the DB, mainly in the XAO table. And they will stay forever depending on the settings you make in the UC_UTILITY_REORG variable for the client where Audit is activated.


    As Josef indicates, the parameter for the "Reorg Object Audit" is indicating how many days you want to keep the audit records in the DB. Then the reorg process will take care of them, with the possibility to check if they have been "revised" first a.k.a. archived in a csv file. This what the ucybdbrr is doing, extracting the records and saving them into a csv file (Windows format regardless if the utility runs on windows or unix/linux ....) and "flagging" or not the archive flag on them.


    The only small detail is that the "archive" flag must be set using the -A option with the ucybdrr utility and another parameter is the start timestamp and end timestamp of the scope of the action of the ucybdrr. If you are not limitating the scope, you will extract the whole audit information in the DB. And if you are not setting the -A option, you will not remove the records from the DB if you have set the option "Only reorg revised Object Audits".


    Fortunately someone, for once, has been to the end of the logic and there is another parameter -X that allows for the ucybdbrr output. to select only records that have not the "archive" flag set . So if you want to extract all audit records to save an archive in csv format every day, you can use the command ucybdbrr -F* -A -X to do it. and set the retention to 125 days to be able to do some reports in csv for specific dates or audit types in this 125 days time window.


    Personnally I would recommend also to run this command ucybdbrr -F<audit type> -X  for every audit type before running the command ucybdbrr -F* -A -X that is doing a global extract and flag records. Makes search easier when looking for one type of action specifically, like a move from one folder to another or a load from a transport.


    Hope this can help you to decide how, when and how long you want to keep the audit records.



  • 11.  DB Revision Report

    Posted 09-20-2016 08:55 AM
    Thanks, Josef