Database Collation Health Check fails in Jira Server
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
About the Health Check
This check retrieves the collation of the database and determines if it is within the list of collations supported by Atlassian. The Check will not assess collation when using an embedded (H2/HSQL) database and will fail if it cannot successfully identify the database (MariaDB is being used, for example). It fails if the collation does not match what we expect, or it cannot be retrieved due to an exception checking it. This health check does not report any warnings for Postgres database users. If you experience an error on this health check, the steps in the resolution should be applied.
Understanding the Results
Depending on the type of database being used, you will receive different results:
- Microsoft SQL Server
- MySQL Database
- Oracle Database
- PostgreSQL Database
- H2 / HSQLDB - Embedded Database (see below)
What this means
|JIRA is using the embedded database. Due to this, the collation check has not been done.
We haven't checked the collation as JIRA is using the embedded (H2/HSQL) database. It is recommended to move off this, as detailed in Migrate from HSQL embedded database to external database in Jira server, as this database is only currently supported for evaluation purposes.
This check does not verify the version of the database, only the type.
What this means
|JIRA is not using a supported database.
JIRA is not using one of our supported database (Microsoft SQL Server, MySQL, PostgreSQL or Oracle). Please see our Connecting JIRA to a Database documentation for this.
The severity of using an unsupported collation varies from database-to-database and also collation-to-collation. Best case JIRA will run all OK and have no problems, worse case JIRA will fail when persisting data to the database, or be able to persist some data and not others, leading to integrity problems. Additionally data may be saved to the database, however, JIRA expects the collation to sort it differently and then works incorrectly as the data is returned in the wrong order (JIRA Software ranking, for example). We do not test JIRA using unsupported collations and as a result of this, it's possible to end up in critical situations where the only fix is to either face data loss or rollback to before the problems occur, after correcting the collation.
We set the warnings to critical due to this - it may cause some effort to have to change this if you've gotten into a situation where JIRA has been up and running for some time without any perceived issues. Changing the collation to one that is supported is a preventative strategy to avoid data loss or unexpected outages.
We would much prefer your data to be in a state that is expected, which is why we have implemented this health check. When coming to support it's one of the first things we'll ask you to fix when we identify data problems.