Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Not Answered
  • Replies replies
    2
  • Subscribers subscribers
    178
  • Views views
    412
  • Users 0 members are here
  • Locked Locked
Related
Options
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

Mihai Apostol ORO

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.

  • 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

  • 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? 

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.