IBM Support

IV71896: ITIC query to TADDM findChangesForDeltaSyncing can take several minutes to run.

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • ITIC runs findChangesForDeltaSyncing for each class that had
    changes. This method can take a long time if
    change_history_table is larger as the query it runs is slow;
    
    select id, object_id, class_name  from change_history_table
    WHERE
    CLASS_NAME IN ('<classname>')
    AND PERSIST_TIME >= <start time> AND
    PERSIST_TIME <= <stop time> AND ACTUAL_CHANGE_TYPE in (1) AND
    HANDLED_BY _STATE_MANAGER = 9 AND (TYPE_OF_EVENT=15 or
    (type_of_event=14 and actual_change_type=1))
    
    
    For example, in the ITIC fusion.log you can see several minute
    gaps between the start and return of this method;
    
    
    15 mar 2015 19:11:48:324 [DEBUG]
    TADDMActualCI.callTaddmFindChanges()
    calling TADDM findChangesForDeltaSyncing -query: select distinct
    guid
    from com.collation.platform.model.topology.sys.DNSService start
    time
    1423838769949 end time 1426442735745
    .....
    15 mar 2015 19:15:39:862 [DEBUG]
    TADDMActualCI.callTaddmFindChanges()
    Returned from TADDM findChangesForDeltaSyncing -query: select
    distinct
    guid from com.collation.platform.model.topology.sys.DNSService
    start
    time Fri Feb 13 15:46:09 CET 2015 end time Sun Mar 15 19:05:35
    CET 2015
    found 2 deleted CIs.
    

Local fix

  • Manually create this index to improve the performance of the
    query;
    
    
    CREATE INDEX CH_CLASS_PERSIST_INDEX ON CHANGE_HISTORY_TABLE
    (CLASS_NAME
    ASC,
    PERSIST_TIME ASC, ACTUAL_CHANGE_TYPE ASC,
    HANDLED_BY_STATE_MANAGER ASC,
    TYPE_OF_EVENT ASC, ID ASC, OBJECT_ID ASC);
    
    Run stats on change_history_table after creating the index.
    
    
    
    If running with a DB2 database, you must also change the run
    stats format as gen_db_stats is not creating them properly, the
    syntax must be;
    
    
    runstats on table db2inst1.change_history_table with
    distribution on all columns and columns( CLASS_NAME
    num_freqvalues 0 num_quantiles 0) and indexes all;
    
    
    (change db2inst1 to proper db2 user for your installation)
    

Problem summary

  • ITIC runs findChangesForDeltaSyncing for each class that had
    changes. This method can take a long time if
    change_history_table is larger as the query it runs is slow;
    
    select id, object_id, class_name  from change_history_table
    WHERE
    CLASS_NAME IN ('<classname>')
    AND PERSIST_TIME >= <start time> AND
    PERSIST_TIME <= <stop time> AND ACTUAL_CHANGE_TYPE in (1) AND
    HANDLED_BY _STATE_MANAGER = 9 AND (TYPE_OF_EVENT=15 or
    (type_of_event=14 and actual_change_type=1))
    
    
    For example, in the ITIC fusion.log you can see several minute
    gaps between the start and return of this method;
    
    
    15 mar 2015 19:11:48:324 íDEBUG
    TADDMActualCI.callTaddmFindChanges()
    calling TADDM findChangesForDeltaSyncing -query: select distinct
    guid
    from com.collation.platform.model.topology.sys.DNSService start
    time
    1423838769949 end time 1426442735745
    .....
    15 mar 2015 19:15:39:862 íDEBUG
    TADDMActualCI.callTaddmFindChanges()
    Returned from TADDM findChangesForDeltaSyncing -query: select
    distinct
    guid from com.collation.platform.model.topology.sys.DNSService
    start
    time Fri Feb 13 15:46:09 CET 2015 end time Sun Mar 15 19:05:35
    CET 2015
    found 2 deleted CIs.
    

Problem conclusion

  • The fix for this APAR is contained in the following maintenance
    packages:
    | Fix Pack | 7.2.2-TIV-ITADDM-FP0004
    | Fix Pack | 7.3.0-TIV-ITADDM-FP0002
    Check the IBM Software Support web site for availability of the
    above maintenance packages.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IV71896

  • Reported component name

    APP DEPENDENCY

  • Reported component ID

    5724N5500

  • Reported release

    722

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2015-04-07

  • Closed date

    2015-05-11

  • Last modified date

    2015-05-11

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    APP DEPENDENCY

  • Fixed component ID

    5724N5500

Applicable component levels

  • R722 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSPLFC","label":"Tivoli Application Dependency Discovery Manager"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"722","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
11 May 2015