InterBase bietet von Haus aus eine Vielzahl von Optimierungsmöglichkeiten mit dem Performance Monitor:
Ich möchte im Performance Monitor zwei Tabs beschreiben:
- Statements
- Tables & Views
Statements
Hier sieht man eine Liste der Abfragen auf der aktuellen Datenbank, die noch nicht abgeschlossen sind (nicht COMMITted).
Eine Übersicht über die Spalten und Zustände findet man hier:
http://docwiki.embarcadero.com/InterBase/2017/en/InterBase_Performance_Monitor_Window#Statements_Tab
Kurz:
- ACTIVE: Aktive Transaktion
- INACTIVE: Nicht mehr aktiv (aber noch nicht COMMITed)
- STALLED: Die Abfrage wurde gestartet, der Client hat aber noch nicht alle Daten angefordert Der Server wartet noch auf die Anforderung der restlichen Daten
- CANCELLED: Abgebrochen
Gut und wichtig, und das ist der erste Optimierungspunkt:
- Welche Abfragen laufen ungewöhnlich lange?
Abfragen, die besonders lange laufen (ich habe bei Kunden schon Abfragen gesehen, die Wochen und gar Monate lang offen waren) erhöhen den allgemeinen Verwaltungsaufwand unter Umständen beträchtlich. - Warum laufen die Abfragen immer noch?
Häufig kommt das durch einen "Amok-laufenden" Client (Absturz, oder einfach nur schlechte Programmierung: Transaktionen werden nie geschlossen/COMMITted) - Über die Schaltfläche "Find Transaction", die nur erscheint, wenn man den "Statement" Tab ausgewählt hat, bekommt man nähere Informationen, wer, wann, wo die Transaktion eröffnet hat (zum aktuellen Statement)
Es lohnt sich also ein regelmäßiger Blick in die aktuellen "Statements" von InterBase.
Tables & Views
Tables & Views geben einen Tabellen-orientierten Ansatz (Tabellen und Views): Hier sieht man, welche Tabellen und Views in einer Datenbank angesprochen werden. Die Standardansicht beinhaltet dabei keine Systemtabellen. Diese lassen sich über Monitor | Show System Tables einschalten:
Zwei Aspekte möchte ich hier herausstellen:
- Indexed selects
- Sequential selects
Indexed selects
Indexed Selects beschreibt die Anzahl der Datensätze, auf die indiziert zugegriffen wurde
Sequential selects
Sequential Selects beschreibt die Anzahl der Datensätze, die nicht über einen Index zugegriffen wurden.
Und da liegt auch wieder Optimierungspotential (abgesehen davon, daß die Index-Erstellung generell auch mit Nachteilen verbunden sein kein (zusätzlicher Overhead)):
Hat man eine Vielzahl von nicht-indizierten Zugriffen, ist es ratsam, diese zu identifizieren:
- Man findet über "Tables & Views" die Tabelle heraus, die häufig im Zugriff steht, deren Zugriff man aber potentiell beschleunigen möchte (hohe Anzahl von "Sequential selects")
- Die Benutzung der Tabelle findet man über die "Statements" Seite heraus (es gibt keine Möglichkeit direkt danach zu suchen
- Dieses Statements testet man dann im iSQL (dort hat man die Möglichkeiten den Query-Plan einzusehen(!)
Bingo:
Bei dieser (sehr simplen) Abfrage sieht man, daß ein Index benutzt worden ist: RDB$PRIMARY22 und INDEX (RDB$FOREIGN25)
Im Gegensatz zu dieser Abfrage:
NATURAL gibt hier an, dass die natürliche Reihenfolge aus der Datenbank stammt (ohne Index).
Es lohnt sich also durchaus, mal seine Abfrage mit dem Performance Monitor und dem iSQL näher zu betrachten.
