Last Access Time not being updated by vCenter Topology job


We're currently experiencing which i think is an unusual behavior regarding the "last access time" attribute on CIs.

Since one week a lot of CIs are not being updated (i mean this attribute and also the "last discovered time" attribute since there is no change on these CIs) , despite still existing on our vCenter for example, therefore the aging mechanism starts to kick in (candidate / deletion time set to 3 / 7) and we're losing lots of CIs.

I've tried restarting multiple times vCenter Topology by VIM jobs on our vCenters, i can see all CIs being added to the vector/results in communication logs but nothing is updated on the CI,

I've also tried reducing the "touch time" to 12H according to this post but no luck either : /it_ops_mgt/ucmdb/f/sws-cms_sup/86496/ucmdb-support-tip-discovery-not-updating-ci-attributes---last-access-time-and-last-discovered-time

Also concerned nodes are not being accessed through host connection jobs, so we need them to be updated by the vCenter at least.

We're on 2019.11.

Thanks for your help,
Best regards,
Yann Pingot

Parents Reply Children
  • Verified Answer

    They are on 2019.11. There is nowhere to upgrade to. 

    However in the release notes of 2019.05 it says:


    UCMDB Server - DatabaseQCCR1H125137

    After synchronizing CIs through the CSV Import adapter and DBEnhancedAdapter, the CIs are not touched by the probe anymore. The "failed to insertTouchResultQueue" error seen in the probe-error.log is caused by the local PostgreSQL on the probe failing to insert a record in the touchqueue table. If the CIs are not touched, they start to be subject to aging and subsequently will be deleted from UCMDB unless a full synchronization is performed again.

    The issue is now fixed by applying a code change to the installation script. This fix is applicable to new install of CMS 2019.05 only.

    For CMS environment upgraded from an older version, you need to execute the alter table query in UCMDB database as follows:

    ALTER TABLE ddm_discovery_touch_results_queue ALTER COLUMN JOBID DROP NOT NULL;


    That is what I am trying to verify - whether the issue matches this case.


  • Hi,
    Apparently it keep going on my problem. I had the same problem again. But after upgrading, the problem seemed to be resolved, so i take it back.
    By the way we're on 10.33.