La migration de base de données dans une mise à niveau 5.6.1 à 6.5 est exceptionnellement lente

Question

Je tente de mettre à niveau une instance 5.6.1 sonarqube à 6.5, il fonctionne sur linux par rapport à une base de données Oracle.

J'ai ajouté les plugins suivants;

• super 1,5
• ldap 2.2.0.608

pilote d'Oracle est ojdbc6-11.2.0.2.0 jdk est 1.8.0_144

le procédé (s) démarrer mais la bande on se bloque simplement. J'ai ajouté l'enregistrement TRACE et voir

2017.09.07 22:07:02 TRACE web[][o.s.s.p.Platform] level1 started | time=2286ms 
2017.09.07 22:07:02 TRACE web[][o.s.s.p.Platform] level2 configured | time=33ms 

alors rien jusqu'à

2017.09.07 23:47:53 TRACE web[][o.s.c.p.ComponentContainer] org.sonar.server.platform.db.migration.history.MigrationHistoryTableImpl started | time=2139938ms 
2017.09.08 00:27:00 TRACE web[][o.s.c.p.ComponentContainer] org.sonar.server.platform.db.migration.history.MigrationHistoryImpl started | time=2347061ms 
2017.09.08 00:27:00 TRACE web[][sql] time=4ms | sql=select version from schema_migrations 
2017.09.08 00:27:00 TRACE web[][sql] time=2ms | sql=select version from schema_migrations 
2017.09.08 00:27:00 WARN web[][o.s.s.p.DatabaseServerCompatibility] Database must be upgraded. Please backup database and browse /setup 

Cette même lenteur continue une fois que la migration commence, par exemple

2017.09.08 17:06:45 INFO web[][o.s.s.p.d.m.v.v.DropRelatedDashboardTables] Removing tables [widget_properties, widgets, active_dashboards, dashboards] 
2017.09.08 17:06:45 TRACE web[][sql] time=35ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP SEQUENCE widget_properties_seq'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -2289 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=19ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP TRIGGER widget_properties_idt'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -4080 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=87ms | sql=DROP TABLE widget_properties 
2017.09.08 17:06:45 TRACE web[][sql] time=12ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP SEQUENCE widgets_seq'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -2289 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=16ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP TRIGGER widgets_idt'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -4080 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=43ms | sql=DROP TABLE widgets 
2017.09.08 17:06:45 TRACE web[][sql] time=11ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP SEQUENCE active_dashboards_seq'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -2289 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=27ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP TRIGGER active_dashboards_idt'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -4080 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=64ms | sql=DROP TABLE active_dashboards 
2017.09.08 17:06:45 TRACE web[][sql] time=12ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP SEQUENCE dashboards_seq'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -2289 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=19ms | sql=BEGIN EXECUTE IMMEDIATE 'DROP TRIGGER dashboards_idt'; EXCEPTION WHEN OTHERS THEN  IF SQLCODE != -4080 THEN  RAISE;  END IF; END; 
2017.09.08 17:06:45 TRACE web[][sql] time=37ms | sql=DROP TABLE dashboards 
2017.09.08 17:06:45 TRACE web[][sql] time=6ms | sql=insert into schema_migrations(version) values (?) | params=1420 
2017.09.08 17:06:45 INFO web[][DbMigrations] #1420 'Drop tables related to dashboards': success | time=8515237ms 
2017.09.08 17:06:45 INFO web[][DbMigrations] #1421 'Drop tables related to measure filters'... 

-à-dire un nombre important d'opérations semblent prendre heure (s) à effectuer

Qu'est-ce qui pourrait causer une telle lenteur? Il n'y a aucune indication dans les journaux pour donner une idée de ce qu'il fait car le temps réel d'exécution de la requête semble faible.

Answer 1

La cause profonde de ce problème avéré être mal effectuer des requêtes de dictionnaire de données, un exemple a été une requête comme

SELECT NULL AS table_cat, 
    o.owner AS table_schem, 
    o.object_name AS table_name, 
    o.object_type AS table_type, 
    NULL AS remarks 
FROM all_objects o 
WHERE  o.owner LIKE :1 ESCAPE '/' 
    AND o.object_name LIKE :2 ESCAPE '/' 
    AND o.object_type IN ('xxx', 'TABLE') 
ORDER BY table_type, table_schem, table_name 

Cela n'a pas été vu dans sonarqube 5.6.