Must-share information (formatted with Markdown):
Hey there.
Hi Colin
These are the error from the logs:
org.sonar.server.platform.db.migration.step.MigrationStepExecutionException: Execution of migration step #102024 'Drop 'purge_status' column in 'snapshots' table' failed
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:79)
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:67)
at com.google.common.collect.ImmutableList.forEach(ImmutableList.java:422)
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:52)
at org.sonar.server.platform.db.migration.engine.MigrationEngineImpl.execute(MigrationEngineImpl.java:54)
at org.sonar.server.platform.db.migration.DatabaseMigrationImpl.doUpgradeDb(DatabaseMigrationImpl.java:105)
at org.sonar.server.platform.db.migration.DatabaseMigrationImpl.doDatabaseMigration(DatabaseMigrationImpl.java:80)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.IllegalStateException: Fail to execute ALTER TABLE snapshots DROP COLUMN purge_status
at org.sonar.server.platform.db.migration.step.DdlChange$ContextImpl.execute(DdlChange.java:106)
at org.sonar.server.platform.db.migration.step.DdlChange$ContextImpl.execute(DdlChange.java:86)
at org.sonar.server.platform.db.migration.step.DdlChange$ContextImpl.execute(DdlChange.java:128)
at org.sonar.server.platform.db.migration.step.DropColumnChange.execute(DropColumnChange.java:49)
at org.sonar.server.platform.db.migration.step.DdlChange.execute(DdlChange.java:45)
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:75)
... 9 common frames omitted
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The index 'NCIDX_dbo_snap' is dependent on column 'purge_status'.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:259)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1695)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:920)
at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:814)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7675)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:4137)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:272)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:246)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.execute(SQLServerStatement.java:787)
at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94)
at com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
at org.sonar.server.platform.db.migration.step.DdlChange$ContextImpl.execute(DdlChange.java:91)
... 14 common frames omitted
This NCIDX_dbo_snap index is not one that was created by SonarQube itself (it may have been added by a well-meaning DBA) and should be removed.
Non-default Indexes should not be added to the SonarQube database.
Hi Colin,
I’ve spoken to my team members about it, but no one has made any modifications to the SonarQube database.
In this post it seems like the same thing has happened but with a different index and column.
It’s a strange one, because if no one has made any manual changes then how do those columns get generated?
What I managed to do was go from 9.9.4 directly to 10.1.0 without making any changes to the db, besides running the /setup. That error only came in once attempting to upgrade to 10.4.1. Is it possible that it may have happened somewhere during the first upgrade perhaps?
It’s not a column, but an index.
What’s happening is that the upgrade is trying to drop a column, but can’t because an index relies on it. If a previous upgrade (like 9.9 to 10.1) didn’t touch that column, then it wouldn’t have failed, even in the presence of that index.
The best thing to do at this point would be to manually drop the index, and see if the upgrade progresses further.
