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.

Impact

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.

Resolution 

• Microsoft SQL Server
• MySQL Database
• Oracle Database
• PostgreSQL Database