Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation du cache d'analyse ANTLR dans Babelfish

À partir des versions 5.7.0 et 6.2.0 de Babelfish, vous pouvez utiliser un cache de résultats d'analyse ANTLR persistant pour les routines T-SQL stockées (procédures et fonctions) afin de réduire la latence de première exécution.

Avec la procédure parse cache :

Performance : pour les routines volumineuses, l'analyse ANTLR peut prendre plusieurs secondes. Avec le cache d'analyse ANTLR, le temps d'analyse de la première exécution est réduit à quelques millisecondes. Les exécutions suivantes au cours de la même session sont diffusées à partir du cache en cours de session (moins d'une milliseconde) et ne sont pas affectées.

Comprendre le cache d'analyse ANTLR

Babelfish doit valider T-SQL la syntaxe en analysant le corps d'une routine lors de sa première exécution dans une session. Ce résultat d'analyse n'est normalement mis en cache que pendant la durée de vie de cette session, de sorte que chaque nouvelle connexion est réanalysée à partir de zéro. Le cache d'analyse conserve le résultat de l'analyse dans le catalogue afin que les nouvelles sessions puissent le réutiliser.

Comment il se comporte :

Observation de l'amélioration du temps d'analyse

Vous pouvez mesurer l'effet en utilisantSET BABELFISH_STATISTICS PROFILE ON, qui indique le Babelfish T-SQL Batch Parsing Time pour chaque lot. Créez d'abord une procédure volumineuse avec la mise en cache activée pour remplir le cache persistant. Comparez ensuite la première exécution de la procédure dans deux nouvelles sessions distinctes : l'une avec la mise en cache désactivée, qui ignore l'entrée persistante, et l'autre avec la mise en cache activée, qui la réutilise. Sinon, si la mise en cache n'était pas activée lors de la création de la procédure, exécutez-la dans deux nouvelles sessions distinctes avec la mise en cache activée : la première exécution remplit le cache persistant et la seconde le réutilise.

Dans l'exemple suivant, créez d'abord la procédure avec la mise en cache activée pour remplir le cache persistant :

-- 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

Ensuite, dans une nouvelle session avec la mise en cache désactivée (valeur par défaut), exécutez la procédure :

-- New session 1: caching OFF (default)
SET BABELFISH_STATISTICS PROFILE ON;
GO
EXEC dbo.updateInformation @region = 'EMEA';   -- first call in this session
GO

Le profil statistique indique un temps d'analyse élevé :

Babelfish T-SQL Batch Parsing Time: 20359.465 ms

Enfin, dans une autre nouvelle session avec la mise en cache activée, exécutez la procédure :

-- 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

Le profil des statistiques indique un temps d'analyse significativement plus court :

Babelfish T-SQL Batch Parsing Time: 150.927 ms

La première exécution d'une nouvelle session passe d'environ 20 s d'analyse à environ 0,15 s une fois que l'arbre d'analyse mis en cache est réutilisé. Les deuxièmes exécutions et les exécutions ultérieures au cours de la même session sont effectuées à partir du cache de session dans les deux cas (en moins d'une milliseconde) et ne sont pas affectées par le GUC.

Activation du cache pour une session

La fonctionnalité est contrôlée par un GUC au niveau de la session (par défaut OFF) :

-- 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

Contrôle du cache par routine

Vous pouvez remplacer le GUC de session pour une routine individuelle en utilisantsys.enable_antlr_parse_cache, qui accepte l'identifiant d'objet de la routine :

-- 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

Vérification des statistiques du cache

sys.antlr_parse_cache_stats()renvoie l'activité du cache d'analyse pour la session en cours :

SELECT * FROM sys.antlr_parse_cache_stats();
GO

Le tableau suivant décrit chaque colonne de la sortie.

Les compteurs sont établis par session et réinitialisés lors d'une nouvelle connexion.

Exemple de scénario

-- 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

Considérations relatives aux mises à niveau

Limitations importantes