The Repair section of the administrator console at KB Management > Repair allows you to perform a range of integrity tests and repairing functions for the knowledgebases in your system. Select a KB from the list and perform the checks or repairs by clicking the relevant buttons. 

In these sections, the Check option performs an integrity test on that area of the database and presents you with a report of all found problems, and the Repair option uses the system's automated repair queries to fix them. Several of these functions will take a long time to complete, as they are carrying out computationally intensive database tasks, so it is often best to schedule them at a time when the load will not diminish the performance of your knowledgebase. 

The repair options available for system KBs are:

History

The system History data can be repaired using the following options:

• Check - Performs an integrity check on history records and returns a list of problems with history synchronization for each table. 
• Quick Repair/Full Repair - Repairs the history records so that synchronization problems are resolved. The quick repair uses a similar set of queries to the full repair, with the exception of the following items:
  
  • In quick repair the DDL (Data Definition Language) structure is not fully repaired; if for example there are differences between field lengths in the DDL, the quick repair will not fix length inconsistencies. Quick repair will synchronize the DDL structure to the extent that all columns marked as tracked are actually tracked, and adds missing history columns or deletes non-tracked history columns. It checks that history columns are of the correct data type and updates history system indices - for example, if the indices are old or non-optimized versions, it automatically repairs them. 
  • Full repair checks that every history log record refers to an existing user. 
  • Full repair checks that every history log of Record Added, Record Modified or Record Removed type corresponds to an existing history record. 
  • Full repair checks that every history record corresponds to an existing history log record, to ensure consistency with history entries, for internal  Agiloft history tables. 
• Check Count - Performs a count of the history records, giving averages and max numbers of records in the knowledgebase. 

Saved Search

The Saved Searches Check/Fix option performs an integrity check on all saved searches and attempts to repair errors. 

Billings

The options in this section check and repair the Billing Compound Field, which is available in all tables in a KB, and uses the Billings table. For more information, see List of Data Types. 

Linked Fields and Database Schema

The options in the LF & Schema section enable you to check and repair the linked fields and database schemas for each knowledgebase, by checking for inconsistencies such as whether all fields that are marked as added were really added to the linked fields, and deleting orphaned fields that were marked to be deleted or created but not completed. It also resolves issues with max length in linked fields, such as if a donor field has a new max length of 1000, but the target field in a sync still has a max length of 100, it will updated the target max length to 1000. 

Actions

The options in this section enable you to check and repair synchronization issues with the actions in a knowledgebase. 

Calculations on multiple linked record columns

The options in this section allow you to check and repair the integrity of the calculations that are used to create linked record columns. For example, if column A.A is a sum of columns B.B, the Check function ensures that column B.B exists, in case it was removed due to an error, and the Repair function can repair the settings that damaged the integrity of the calculations to create linked record columns. 

Local source

The options in this section allow you to check and repair attachment errors caused by duplicated attachment fields. 

DB Maintain

The Analyze Tables button allows admins to force the database to analyze/recollect indexes statistics. After selecting the desired KB(s), the system checks if there are any import processes running, and if not, will start the analysis process. The results of the analysis can be found at  <installation>/wildfly/standalone/log/server.log. If a project is in the process of importing, a confirmation pop-up will appear stating: "It is not recommended to run analyze table at the same time when any project is in importing state. Continue?". It is recommended the user cancels the analysis process and waits until any import is finished.

Note that table analysis is typically performed automatically by background services. By default, this automatic analysis occurs once a week between 11 pm and 4 am after a period of 180 seconds of system inactivity. To change the frequency and time at which automatic table analysis is performed by background services, edit the Analyze Table Frequency and Analyze Tables Period global variables. To change the amount of time of inactivity (in seconds) that the system waits before performing automatic table analysis, edit the Analyze table start protection period of system inactivity global variable.