Configure database integrity checks
Having duplicate or missing information in the database can cause multiple issues in Jira, such as slow performance, unexpected errors, or inaccurate configurations.
Database integrity checks keep your data accurate and consistent by regularly fixing detected inconsistencies in Jira’s database and trying to reset the data to a stable state. This is useful in various situations, for example:
before migrating a project to a new workflow
when an external program is modifying Jira's database
when troubleshooting a server crash
To configure and adjust database integrity checks, you must be logged in as a user with Jira administrator permissions. Overview of global permissions in Jira
Adjust database integrity checks
After you update to the latest version of the Instance optimizer for Jira app, we will automatically enable scheduled database integrity checks for your instance. This means that the app will regularly detect and fix data inconsistencies based on the preconfigured settings.
By default, the checks run every Sunday at 3 a.m. Jira system time. More on system information in Jira
Only a subset of checks is enabled initially, but you can adjust the schedule and the list of checks or disable the feature altogether in the Instance optimizer settings:
In the upper-right corner of your Jira app, select Jira administration, and then select System.
In the sidebar, navigate to Instance optimizer and then select Database integrity checks. This page lists multiple integrity checks that look for and address common inconsistencies in Jira's stored data. Overview of existing checks
In the Schedule section, set the time for running checks automatically. For guidelines on cron syntax, refer to Constructing cron expressions.
Specify an actor that will execute the checks. By default, a valid system administrator is selected as the actor.
Select the checkboxes next to the checks you want to run. To execute all the checks, choose All checks.
Click Save to run the checks regularly according to the specified schedule. You can also run the checks immediately by selecting the Run manually button.
If you’re modifying the list of enabled checks, save your changes before proceeding. Otherwise, only previously saved checks will run.
After being started, all enabled checks will be performed in the background, and appropriate fixes will be made automatically. You can check the actions taken in the advanced audit log by clicking the View logs button.
Each selected database integrity check will produce an audit log entry with the details of what was fixed or removed, regardless of whether the check was initiated manually or automatically. Overview of audit log events in Jira
During the execution, you might notice additional downstream Jira audit events. This is the expected behaviour.
Overview of the integrity checks
This section lists all available database integrity checks and provides details about their execution.
Check issue relations
| Check name | Is it long-running? | What does it check? | How does it fix detected issues? |
|---|---|---|---|
Check issues with no associated projects | Yes | Checks if the project ID on the issue points to an existing project. | Deletes the issue if it has no corresponding project. Also deletes:
This check permanently deletes the issue and all its associated data. The issue is being deindexed, and the delete event is sent. This action doesn't remove attachments stored on disk or Amazon S3. |
Check issues with no workflow steps | Yes | Checks if the workflow ID on the issue points to an existing workflow entry. |
|
Check broken issue links | No | Checks if the source or destination issue ID in the issue link points to an existing issue. | Deletes the broken issue link from the database. |
Check issue links with invalid issue link types | No | Checks if the | Deletes the broken issue link from the database. |
Check search requests
| Check name | Is it long-running? | What does it check? | How does it fix detected issues? |
|---|---|---|---|
Check invalid project references in search requests | Yes | Checks if a search request (search filter) with a non-empty project field points to an existing project. |
|
Check issue permissions
| Check name | Is it long-running? | What does it check? | How does it fix detected issues? |
|---|---|---|---|
Check duplicate permission schemes | Yes | Checks if there are records in the
|
|
Check workflows
| Check name | Is it long-running? | What does it check? | How does it fix detected issues? |
|---|---|---|---|
Check invalid workflow states | No | Checks if there is an issue that has a corresponding workflow entry ID with a status equal to | For all detected issues, sets the corresponding workflow entry state to |
Check the current workflow step for each issue | No | Checks if the issue’s current status in the workflow is correct. This check iterates through all the issues on the instance. Depending on the number of issues, it can be a long-running operation. | Depending on the use case, it can or can’t be fixed. Use case 1. The issue has a Result: this check can't be fixed. Use “Check issues with a null status” instead. Use case 2. The issue’s workflow status ID is null. Result: this check can't be fixed. Use “Check issues with no workflow steps” instead. Use case 3. The issue has a status set, but there is no linked step descriptor for this status in its workflow. Result: this check can't be fixed. Use case 4. We found 0 records in the current step table for the issue with the given workflow entry ID. Result: This check creates a missing current step for the given Issue ID with a given status and workflow entry ID. Use case 5. We found 1 record in the current step table for the issue with the given workflow entry ID, but the step ID is null or differs from the one mapped from the issue status. Result: If the current step record found is invalid, it sets its value in the database. Otherwise, the check skips it. Use case 6. We found 1+ records in the current step table for the issue with the given workflow entry ID. Result: Deletes redundant steps and keeps only one. |
Check issues with null status | No | If the issue’s status is set to |
|
Check field layout schemes
| Check name | Is it long-running? | What does it check? | How does it fix detected issues? |
|---|---|---|---|
Check field layouts with no custom fields | No | Checks if all field layout items are pointing to an existing custom field. A field layout item can specify if a given custom field is required in a given field layout. More about specifying field behavior | Deletes an incorrect record from the field layout item table. |
Check filter subscriptions
| Check name | Is it long-running? | What does it check? | How does it fix detected issues? |
|---|---|---|---|
Check filter subscriptions with no search filter | No | Checks if a filter subscription is linked to a search filter (search request) that doesn't exist. |
|
Check filter subscriptions with a non-existent scheduled job | No | Checks if a filter subscription is linked to a scheduled clustered job that doesn't exist in the clustered job table. | Delete the incorrect record from the filter subscription table. |
Property keys for database integrity checks
Database integrity checks use the following application property keys that can be adjusted via the REST API. More about the application-properties module
Property key | Description | Default value |
|---|---|---|
| A maximum number of fixes to process if the Check is marked as a long-running one. | 1000 |
| Batch size for the check: the current workflow step for each issue. | 1000 |
| Batch size for check: filter subscriptions with no search filter. | 1000 |