Use > JMX Reference > Administration Methods > History DB Services JMX Methods

History DB Services JMX Methods

History DB Services JMX Method Name Description
alignHistoryForType Updates the history tables of a CI Type class according to the class description. This includes the main history tables, the removed CIs tables and the list attributes tables. If no CI type class is passed as a parameter all history will be aligned.
deleteUnboundHistoryTables

Delete unbound history tables. This method finds DB history tables without appropriate history partition resource in URM or without related class of any customer and then deletes them. The find process is the same as in the findUnboundHistoryTables JMX method.

In preview mode, the table names are only printed in the output of the JMX method, nothing will be deleted.

Caution Always run this JMX method in preview mode first, and check the delete candidates before proceeding to delete any tables!

executeBaselineForClass Executes the baseline process for a CI type class if needed.
executeFullBaseline Executes the baseline process for all CI type classes.
findUnboundHistoryTables Finds the history tables without appropriate history partition resource in URM. This method finds all the history tables from the database and compares them with the history tables from the history partitions URM resources. The method finds unbound tables for all the UCMDB Customers.
getHistoryChanges Get history changes for an Object ID in a specified time frame.
getHistoryChangesCounterByType Get number of changes according to class type and time frame.
getHistoryChangesExtendedCounter Get an extended counter of changes for an Object ID and time frame.
getHistoryLayout Get full history layout for Object ID from a specified date.
getRemovedData Get removed data in a specified time frame.
initializeHistoryDBFromModel Initialize History DB from Data Model. This method deletes all customer data from history tables, deletes URM History partitions, HDM and HDML tables for all history months, HDMR and HDMRL tables and HDM_ROOT table for the specified customer. After history is cleared the align process will recreate the history tables according to the class description and history will be initialized with the current data in the data model.
isHistoryEnabled Determines whether history is enabled according to the settings.
purgeHistoryDBAccordingToInput Purges the history DB according to the specified months to save back.
purgeHistoryDBAccordingToInput
IncludingExtraMonths
Purges the history DB according to the input of how many months to save back and how many extra months to save old removed data.
purgeHistoryDBAccordingToSettings Purges the history DB according to the purge settings.
purgeHistoryFailures In order to easily troubleshoot history issues, last history failures for specific history operation(Baseline, Purge, Alignment etc) are saved inside URM. This JMX method clears the failures from the URM.
showHistoryTableForType Shows the history tables for a specific CI type class.
showLastHistoryFailures Displays a report of last UCMDB History failures for all history operations.
showLastHistoryFailuresForSpecific
HistoryOperation
Displays a report of last UCMDB History failures for specific history operations: 1: BASELINE 2: BASELINE FROM DATA MODEL 3: PURGE 4: PURGE_MODEL_REVISIONS 5: COMPLETE PARTIAL EVENTS 6: DELETE HISTORY TABLES/DATA FROM HISTORY ROOTS 7: ALIGNMENT
startHistoryDB Starts the history database for saving CI history changes. Please note that this method will delete existing history and will recreate the history tables according to the data model.
stopHistoryDB Stop the history database. This method will cause the existing CI history changes to be unusable.

History operations explained

  1. BASELINE

    • Baseline process: Once a month a new history table is created for each CI Type, which will contain all the events that will be created in the next month. These Baseline events are added for each CI instance and will contain the whole CI data at the beginning of the month. This is needed to avoid unnecessary access to previous monthly tables.
    • Baseline Process setting:

      history.baseline.defined.start.date = 10 00

      Format: <day of month(1-28)><space><hour (00-23)>

      For example, by using the default setting, the April monthly table stores events occurred between April 10th at midnight through May 9th at 23:59:59.

      Note

      • The starting time of the Baseline Process should not be the same as the History Purging starting time or Aging process start time.
      • Because the Baseline process affects the population integration performance, make sure you schedule the Baseline Process to run at an appropriate distance from the discovery process time.