Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwenden des ANTLR-Parse-Cache in Babelfish
Ab den Babelfish-Versionen 5.7.0 und 6.2.0 können Sie einen persistenten ANTLR-Parse-Ergebniscache für T-SQL gespeicherte Routinen (Prozeduren und Funktionen) verwenden, um die Latenz bei der ersten Ausführung zu reduzieren.
**Mit der Prozedur Parse-Cache:**
+ Große T-SQL Routinen (Hunderte bis Tausende von Zeilen) verursachen nicht mehr den vollen T-SQL Analyseaufwand bei der ersten Ausführung in jeder neuen Sitzung.
+ Das analysierte Ergebnis wird einmal zum `ALTER` procedure/function Zeitpunkt`CREATE`/serialisiert, im Katalog gespeichert und sitzungsübergreifend wiederverwendet. Dabei wird das systemweite Caching-Verhalten von SQL Server emuliert.
+ Die Funktion wird durch die GUC auf Sitzungsebene gesteuert, wobei optionale routinemäßige Überschreibungen über möglich sind. `babelfishpg_tsql.enable_antlr_parse_cache` `sys.enable_antlr_parse_cache()`
+ **Standardmäßig ist die Funktion AUS.**
**Leistung:** Bei großen Routinen kann das ANTLR-Parsing mehrere Sekunden dauern. Mit dem ANTLR-Parse-Cache wird die Zeit für die Analyse der ersten Ausführung auf wenige Millisekunden reduziert. Nachfolgende Ausführungen in derselben Sitzung werden aus dem Sitzungs-Cache (unter einer Millisekunde) bedient und sind davon nicht betroffen.
## Den ANTLR-Parse-Cache verstehen
Babelfish muss die T-SQL Syntax validieren, indem es den Hauptteil einer Routine analysiert, wenn sie zum ersten Mal in einer Sitzung ausgeführt wird. Dieses Analyseergebnis wird normalerweise nur für die Dauer dieser Sitzung zwischengespeichert, sodass jede neue Verbindung von Grund auf neu analysiert wird. Der Parse-Cache speichert das Parse-Ergebnis im Katalog, sodass es in neuen Sitzungen wiederverwendet werden kann.
Wie es sich verhält:
+ **Bei`CREATE`/`ALTER`:** Wenn das Caching aktiviert ist, analysiert Babelfish die Routine und speichert das serialisierte Parse-Ergebnis im persistenten Cache.
+ **Erste Ausführung ohne persistenten Eintrag:** Wenn kein zwischengespeicherter Eintrag existiert (zum Beispiel wurde die Routine erstellt, bevor das Caching aktiviert wurde), führt Babelfish den normalen ANTLR-Parse durch und füllt den persistenten Cache.
+ **Erste Ausführung in einer späteren Sitzung:** Babelfish lädt und deserialisiert das zwischengespeicherte Parse-Ergebnis, anstatt es erneut zu parsen — hier liegt die Zeitersparnis.
+ **Nachfolgende Ausführungen in derselben Sitzung: Wird aus dem In-Session-Cache** bedient (unverändertes Verhalten).
+ Wenn ein zwischengespeichertes Ergebnis fehlt oder von einer anderen Babelfish-Version erstellt wurde, führt Babelfish die normale ANTLR-Analyse durch und füllt den persistenten Cache neu, wenn das Caching aktiviert ist.
+ Wenn Babelfish beim Serialisieren oder Deserialisieren eines zwischengespeicherten Ergebnisses auf einen Fehler stößt, schlägt die Anweisung fehl und gibt einen Fehler zurück. Deaktivieren Sie das Caching für die betroffene Routine und wiederholen Sie die Anweisung oder versuchen Sie es in einer neuen Sitzung mit deaktivierter Cache-GUC erneut. Wenn der Fehler weiterhin besteht, wenden Sie sich an den AWS Support.
## Beobachtung der Verbesserung der Analysezeit
Sie können den Effekt mit der Methode messen`SET BABELFISH_STATISTICS PROFILE ON`, die `Babelfish T-SQL Batch Parsing Time` für jede Charge gemeldet wird. Erstellen Sie zunächst eine umfangreiche Prozedur mit aktiviertem Caching, um den persistenten Cache zu füllen. Vergleichen Sie dann die erste Ausführung der Prozedur in zwei separaten neuen Sitzungen: in einer Sitzung mit deaktiviertem Caching, wodurch der persistente Eintrag ignoriert wird, und in einer Sitzung mit aktiviertem Caching, bei der er wiederverwendet wird. Falls die Zwischenspeicherung bei der Erstellung der Prozedur nicht aktiviert war, können Sie sie alternativ in zwei separaten neuen Sitzungen mit aktiviertem Caching ausführen: Bei der ersten Ausführung wird der persistente Cache aufgefüllt, bei der zweiten wird er erneut verwendet.
Erstellen Sie im folgenden Beispiel zunächst die Prozedur mit aktiviertem Caching, um den persistenten Cache zu füllen:
```
-- New session 0: caching ON (at CREATE PROCEDURE time)
SELECT set_config('babelfishpg_tsql.enable_antlr_parse_cache', 'on', false);
GO
CREATE PROCEDURE dbo.updateInformation @region VARCHAR(50)
AS
BEGIN
...
END;
GO
```
Führen Sie als Nächstes in einer neuen Sitzung mit ausgeschaltetem Caching (Standardeinstellung) die Prozedur aus:
```
-- New session 1: caching OFF (default)
SET BABELFISH_STATISTICS PROFILE ON;
GO
EXEC dbo.updateInformation @region = 'EMEA'; -- first call in this session
GO
```
Das Statistikprofil meldet eine hohe Analysezeit:
```
Babelfish T-SQL Batch Parsing Time: 20359.465 ms
```
Führen Sie abschließend in einer weiteren neuen Sitzung mit eingeschaltetem Caching die folgende Prozedur aus:
```
-- New session 2: caching ON
SELECT set_config('babelfishpg_tsql.enable_antlr_parse_cache', 'on', false);
GO
SET BABELFISH_STATISTICS PROFILE ON;
GO
EXEC dbo.updateInformation @region = 'EMEA'; -- first call in this session
GO
```
Das Statistikprofil meldet eine deutlich kürzere Analysezeit:
```
Babelfish T-SQL Batch Parsing Time: 150.927 ms
```
Die erste Ausführung in einer neuen Sitzung sinkt von \~20 s beim Parsen auf \~0,15 s, sobald der zwischengespeicherte Analysebaum wiederverwendet wird. Zweite und spätere Ausführungen innerhalb derselben Sitzung werden in beiden Fällen (im Submillisekundenbereich) aus dem Sitzungs-Cache ausgeführt und sind von der GUC nicht betroffen.
## Den Cache für eine Sitzung aktivieren
**Die Funktion wird durch eine GUC auf Sitzungsebene gesteuert (standardmäßig AUS):**
```
-- Enable parse caching for the current session
SELECT set_config('babelfishpg_tsql.enable_antlr_parse_cache', 'on', false);
GO
-- Disable for the current session
SELECT set_config('babelfishpg_tsql.enable_antlr_parse_cache', 'off', false);
GO
```
**Anmerkung**
Die GUC ist **sitzungsbezogen und wird am Ende der Sitzung auf** die Standardeinstellung (AUS) zurückgesetzt.
**Diese GUC ist derzeit nicht clusterweit über konfigurierbar.** `sp_babelfish_configure`
## Steuerung des Caches pro Routine
Sie können die Sitzungs−GUC für eine einzelne Routine mit`sys.enable_antlr_parse_cache`, die die Objekt-ID der Routine akzeptiert, überschreiben:
```
-- Force caching ON for a specific routine (even if the session GUC is OFF)
SELECT sys.enable_antlr_parse_cache(sys.object_id('dbo.my_proc'), true);
GO
-- Force caching OFF for a specific routine — "kill switch"
-- (clears any cached data and blocks caching even if the session GUC is ON)
SELECT sys.enable_antlr_parse_cache(sys.object_id('dbo.my_proc'), false);
GO
-- Reset to default; the routine follows the session GUC
SELECT sys.enable_antlr_parse_cache(sys.object_id('dbo.my_proc'), NULL);
GO
```
**Anmerkung**
Sie müssen der **Besitzer** der Routine oder ein Mitglied der **Sysadmin-Rolle** sein, um ihre Cache-Einstellung ändern zu können.
Die routinemäßige Einstellung bleibt sitzungsübergreifend bestehen (sie wird im Katalog gespeichert) und bleibt auch während der gesamten Sitzung erhalten. Sie wird entfernt`ALTER`, wenn die Routine gelöscht wird.
## Cache-Statistiken werden überprüft
`sys.antlr_parse_cache_stats()`gibt die Parse-Cache-Aktivität für die aktuelle Sitzung zurück:
```
SELECT * FROM sys.antlr_parse_cache_stats();
GO
```
In der folgenden Tabelle werden die einzelnen Spalten in der Ausgabe beschrieben.
| Spalte | Description |
| --- | --- |
| cache\_hits | Anzahl der Routineausführungen, für die ein zwischengespeichertes Analyseergebnis wiederverwendet wurde. |
| cache\_misses | Anzahl der Routineausführungen, für die das Caching aktiviert war, aber kein verwendbarer Cache-Eintrag gefunden wurde. |
| cache\_writes | Anzahl der erfolgreichen Schreibvorgänge im persistenten Cache. |
| cache\_evictions | Anzahl der zwischengespeicherten Einträge, die ungültig gemacht oder entfernt wurden (z. B. Kill-Switch oder GUC-Toggle). |
| cache\_errors | Anzahl der Serialisierungs- oder Deserialisierungsfehler. |
Die Zähler werden pro Sitzung berechnet und bei einer neuen Verbindung zurückgesetzt.
## Beispielszenario
```
-- Enable caching for this session
SELECT set_config('babelfishpg_tsql.enable_antlr_parse_cache', 'on', false);
GO
CREATE PROCEDURE dbo.report_proc @region VARCHAR(50)
AS
BEGIN
-- large multi-statement T-SQL body ...
SELECT @region;
END;
GO
-- First execution in a brand-new session: served from the persistent cache (fast)
EXEC dbo.report_proc @region = 'APAC';
GO
-- Inspect cache activity for this session
SELECT * FROM sys.antlr_parse_cache_stats();
GO
-- Opt this routine out of caching regardless of the session setting
SELECT sys.enable_antlr_parse_cache(sys.object_id('dbo.report_proc'), false);
GO
```
## Überlegungen zum Upgrade
+ Der ANTLR-Parse-Cache ist an eine bestimmte Babelfish-Version gebunden. Wenn sich die Babelfish-Version ändert, werden zwischengespeicherte Parse-Ergebnisse nicht mehr wiederverwendet. Neue Ausführungen analysieren die Routine erneut und füllen den Cache automatisch neu, wenn das Caching aktiviert ist.
+ Bestehende Routinen, die vor 5.7.0 und 6.2.0 erstellt wurden, werden bei ihrer nächsten Ausführung oder bei der Ausführung in einer Cold-Session zwischengespeichert, sobald das Caching aktiviert ist`CREATE`. `ALTER`
## Wichtige Einschränkungen
+ **Standardmäßig AUS:** Die Funktion muss pro Sitzung explizit aktiviert (oder pro Routine erzwungen) werden.
+ **Verbindungstyp:** Der Cache ist nur für **TDS-Verbindungen (SQL Server-Protokoll)** aktiv, nicht für psql/libpq Verbindungen.
+ **Nicht zwischengespeichert:** **Trigger, Ereignisauslöser und Inline-Tabellenwertfunktionen (ITVFs)** werden in dieser Version nicht zwischengespeichert.
+ **Cluster-wide config:** Die Sitzungs-GUC kann derzeit nicht über eingestellt werden. `sp_babelfish_configure`