This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Running UCMDB server without caching TQL results

I would like to try running the UCMDB server with all TQLs uncached (views tqls, enrichment rules tqls, discovery job trigger queries, etc).

I mean every TQL to be run against the live database (Oracle on a physical server) at the time of request (when scheduled or ad-hoc calculated / refreshed).

And also, UCMDB probes running without cache.

Are all or some of the above even possible?

I know it would imply a performance degradation, but data consistency and be in real-time is of more importance than performance.

I have over 50 scheduled discovery and integration jobs and over 150 enrichment rules that augment or change or remove elements from topology/CMDB.

All of them need to run on live data triggers when scheduled, not cached because topology is frequently modified.

There is no documentation about the JMX method ‚setTqlResultUncached’

I just tried it, but it seems that not all tqls can be set uncached (discovery job trigger queries used in active jobs).

The reason is that I keep encountering many reconciliation errors of type "Couldn't update object/s (in strict mode) that don't exist in CMDB topology"

And support is still unable to solve my issue for over a year now!

And I need to ask you guys with many thanks in advance for any suggestion / idea / advice / solution.

Parents
  • 0  

    Dear Mihai,

    from your description I am not sure whether the Cache you have to look after is the "TQL Cache".

    With trigger TQLs you have to keep in mind that the resultset (better the part that has been dispatched to a certain probe MYPROBE) is stored in the Probe Postgres database. This cache is updated when the trigger TQL is reexecuted (discovery job is restarted or you perform a rediscovery) or when CIs are deleted (then the UCMDB server notifies the probe of the deletion). It is needed that the probe can run its jobs autonomously (even if the UCMDB server is down).

    It can happen, that there probe-stored trigger CI information gets out of sync with the server and then you might start discovery on outdated or even deleted trigger CI information.

    Stopping the discovery job clears the probe-stored trigger CIs for this job.

    Other "caches" that could come into your way are the probe result cache and how this is linked with UCMDB object ids.
    A radical $UCMDB_PROBE_BASEDIR/tools/clearProbeData.sh (followed by a supervised rediscovery) might help here.

    But there are situations where change dynamics is very high and you NEED to ensure that you never use outdated trigger CI information.

    In this case I made good experience with writing an adapter, that gets fresh information by a REST call from UCMDB at the time it is running.

    Best regards

    Kai

Reply
  • 0  

    Dear Mihai,

    from your description I am not sure whether the Cache you have to look after is the "TQL Cache".

    With trigger TQLs you have to keep in mind that the resultset (better the part that has been dispatched to a certain probe MYPROBE) is stored in the Probe Postgres database. This cache is updated when the trigger TQL is reexecuted (discovery job is restarted or you perform a rediscovery) or when CIs are deleted (then the UCMDB server notifies the probe of the deletion). It is needed that the probe can run its jobs autonomously (even if the UCMDB server is down).

    It can happen, that there probe-stored trigger CI information gets out of sync with the server and then you might start discovery on outdated or even deleted trigger CI information.

    Stopping the discovery job clears the probe-stored trigger CIs for this job.

    Other "caches" that could come into your way are the probe result cache and how this is linked with UCMDB object ids.
    A radical $UCMDB_PROBE_BASEDIR/tools/clearProbeData.sh (followed by a supervised rediscovery) might help here.

    But there are situations where change dynamics is very high and you NEED to ensure that you never use outdated trigger CI information.

    In this case I made good experience with writing an adapter, that gets fresh information by a REST call from UCMDB at the time it is running.

    Best regards

    Kai

Children
  • 0 in reply to   

    What happens when a discovery job is executed regularly (daily schedule), but not deactivated/reactivated?

    You said the trigger TQL is reexecuted when a discovery job is restarted or you perform a rediscovery.
    Does my case means "job restart" or "restarted" means deactivate and reactivate again the job?