Guter Tipp mit dem Aufsplitten der Indexerzeugung, danke!
Außerdem: SKIP_LOCKED ist evtl für Dich interessant. Wir hatten ja mal das Thema, wie man Ressourcenzugriff synct, mit dem Ergebnis select with lock. Über SKIP_LOCKED lassen sich mit Firebird 5 queues umsetzen, die nur da blockieren, wo es unbedingt nötig ist.
Hat jemand von euch mitllerweile Firebird 5 mal getestet? Habe bisher paralleles Backup/Restore getestet, das ist deutlich schneller als bisher, ca Faktor 2 bis 3. Auch hab ich mal zwei große BI-Anwendungen (Desktop und Web) mit komplexem DB-Code mit Firebird 5 betrieben, das lief alles ohne Probleme. Schön auch das minor ODS upgrade, denn damit kann man 4er DBs einfach mit gfix auf ODS 13.1 upgraden und braucht kein backup restore.
Dann wollte ich den profiler testen, das sträubt sich aber noch. Man führt eine profiler-Session so durch
Code: Alles auswählen
select rdb$profiler.start_session('Profile Session 1') from rdb$database -- default current_connection
-- den zu profilenden Code ausführen
execute procedure rdb$profiler.finish_session(true)
Anschließend kann man die profiling views auswerten, deren Basistabellen bei dieser Aktion mit Daten gefüllt wurden,
Code: Alles auswählen
select * from plg$prof_sessions
select * from plg$prof_psql_stats_view
usw, siehe Doku. Löschen der profiledaten mit delete from plg$prof_sessions, das leert über delete cascade auch die zugehörigen Daten in allen anderen snapshot-Tabellen.
Das klappt soweit auch. Die Session bezieht sich immer nur auf das bei start_session genannte attachment - wenn man nix angibt, ist es current_connection.
Beim profiling komplexer SPs scheint es noch zu haken. Während eine einfache SP Profildaten erzeugt, wirkt es bei einigen komplexeren (die genaue Ursache kenne ich noch nicht), als wäre gar keine Session erzeugt worden. Es wurden aber Profildaten in die snapshot-Tabellen geschrieben, Flamerobin zeigt das beim commit von finish_session an:
PLG$PROF_SESSIONS: 1 inserts.
PLG$PROF_STATEMENTS: 19 inserts.
PLG$PROF_CURSORS: 35 inserts.
PLG$PROF_RECORD_SOURCES: 92 inserts.
in firebird.log steht dann sowas:
Code: Alles auswählen
Profiler flush
violation of FOREIGN KEY constraint "PLG$PROF_RECORD_SOURCES_CURSOR_FK" on table "PLG$PROF_RECORD_SOURCES"
Foreign key reference target does not exist
Problematic key value is ("PROFILE_ID" = 12, "STATEMENT_ID" = 62247, "CURSOR_ID" = 3)
Wenn es funktioniert, sieht es hingegen zb so aus:
PLG$PROF_SESSIONS: 1 inserts.
PLG$PROF_STATEMENTS: 5 inserts.
PLG$PROF_CURSORS: 3 inserts.
PLG$PROF_RECORD_SOURCES: 4 inserts.
PLG$PROF_REQUESTS: 5 inserts.
PLG$PROF_PSQL_STATS: 11 inserts.
PLG$PROF_RECORD_SOURCE_STATS: 4 inserts.
Dh, die letzten 3 Snapshot-Tabellen werden im Fehlerfall nicht gefüllt und das ganze nicht committet.