Installing the SonarQube database
Several external database engines are supported. Be sure to follow the requirements listed for your database. They are real requirements not recommendations.
Create an empty schema and a sonarqube
user. Grant this sonarqube
user permissions to create
, update
, and delete
objects for this schema.
Microsoft SQL Server
Collation MUST be case-sensitive (CS) and accent-sensitive (AS).
READ_COMMITED_SNAPSHOT
MUST be set on the SonarQube database.
MS SQL database's shared lock strategy may impact SonarQube runtime. Making sure that is_read_committed_snapshot_on
is set to true
to prevent SonarQube from facing potential deadlocks under heavy loads.
Example of query to check is_read_committed_snapshot_on
:
SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name='YourSonarQubeDatabase';
Example of query to update is_read_committed_snapshot_on
:
ALTER DATABASE YourSonarQubeDatabase SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
Encryption
If your Microsoft SQL Server doesn't support encryption, you must add encrypt=false
to the JDBC URL connection string.
If your Microsoft SQL Server requires encryption but you don't want SonarQube to validate the certificate, you must add trustServerCertificate=true
to the JDBC URL connection string.
Integrated security
To use integrated security:
- Download the Microsoft SQL JDBC Auth 12.4.1 package and copy
mssql-jdbc_auth-12.4.1.x64.dll
to any folder in the path of the SonarQube host. - If you're running SonarQube as a Windows service, make sure the Windows account under which the service is running has permission to connect your SQL server.
- Ensure that
sonar.jdbc.username
orsonar.jdbc.password
properties are commented out or SonarQube will use SQL authentication.
sonar.jdbc.url=jdbc:sqlserver://localhost;databaseName=sonar;integratedSecurity=true
SQL authentication
To use SQL authentication, use the following connection string. Also, ensure that sonar.jdbc.username
and sonar.jdbc.password
are set appropriately:
sonar.jdbc.url=jdbc:sqlserver://localhost;databaseName=sonar
sonar.jdbc.username=sonarqube
sonar.jdbc.password=mypassword
Oracle
If there are two SonarQube schemas on the same Oracle instance, especially if they are for two different versions, SonarQube gets confused and picks the first it finds. To avoid this issue:
- Either privileges associated to the SonarQube Oracle user should be decreased.
- Or a trigger should be defined on the Oracle side to automatically alter the SonarQube Oracle user session when establishing a new connection:
ALTER SESSION SET current_schema="MY_SONARQUBE_SCHEMA"
.
Oracle JDBC driver versions 12.1.0.1 and 12.1.0.2 have major bugs, and are not recommended for use with SonarQube (see more details).
PostgreSQL
If you want to use a custom schema and not the default "public" one, the PostgreSQL search_path
property must be set:
ALTER USER mySonarUser SET search_path to mySonarQubeSchema
Was this page helpful?