Utilisation de procédures stockées pour les pools SQL dédiés dans Azure Synapse Analytics

Cet article fournit des conseils pour développer des solutions de pool SQL dédiées en implémentant des procédures stockées.

À quoi s’attendre

Le pool SQL dédié prend en charge la plupart des fonctionnalités T-SQL utilisées dans SQL Server. Plus important encore, il existe des fonctionnalités spécifiques de scale-out que vous pouvez utiliser pour optimiser les performances de votre solution.

En outre, pour vous aider à maintenir la mise à l’échelle et les performances du pool SQL dédié, il existe des fonctionnalités et des fonctionnalités supplémentaires qui présentent des différences comportementales.

Présentation des procédures stockées

Les procédures stockées constituent un excellent moyen d’encapsuler votre code SQL, qui est stocké près de vos données de pool SQL dédiées. Les procédures stockées aident également les développeurs à modulariser leurs solutions en encapsulant le code en unités gérables, ce qui facilite la réutilisation du code. Chaque procédure stockée peut également accepter des paramètres pour les rendre encore plus flexibles.

Le pool SQL dédié propose une implémentation simplifiée et optimisée des procédures stockées. La plus grande différence par rapport à SQL Server est que la procédure stockée n’est pas du code précompilé.

En général, pour les entrepôts de données, le temps de compilation est faible par rapport au temps nécessaire pour exécuter des requêtes sur de grands volumes de données. Il est plus important de s’assurer que le code de procédure stockée est correctement optimisé pour les requêtes volumineuses.

Lorsqu’un pool SQL dédié exécute votre procédure stockée, les instructions SQL sont analysées, traduites et optimisées au moment de l’exécution. Pendant ce processus, chaque instruction est convertie en requêtes distribuées. Le code SQL exécuté sur les données est différent de la requête envoyée.

Imbrication des procédures stockées

Lorsque des procédures stockées appellent d’autres procédures stockées ou exécutent du SQL dynamique, l'appel de la procédure stockée interne ou de code est considéré comme imbriqué.

Le pool SQL dédié prend en charge un maximum de huit niveaux d’imbrication. À l’inverse, le niveau d’imbrication dans SQL Server est de 32.

L’appel de procédure stockée de premier niveau correspond au niveau d’imbrication 1.

EXEC prc_nesting

Si la procédure stockée effectue également un autre appel EXEC, le niveau d’imbrication passe à 2.

CREATE PROCEDURE prc_nesting
AS
EXEC prc_nesting_2  -- This call is nest level 2
GO
EXEC prc_nesting

Si la deuxième procédure exécute du code SQL dynamique, ce niveau monte à 3.

CREATE PROCEDURE prc_nesting_2
AS
EXEC sp_executesql 'SELECT 'another nest level'  -- This call is nest level 2
GO
EXEC prc_nesting

Le pool SQL dédié ne prend actuellement pas en charge @@NESTLEVEL. Par conséquent, vous devez suivre le niveau d’imbrication. Il est peu probable que vous dépassiez la limite de huit niveaux d’imbrication. Toutefois, si vous le faites, vous devez retravailler votre code pour qu’il s'adapte aux niveaux d’imbrication imposés par cette limite.

INSÉRER.. EXÉCUTER

Le pool SQL dédié ne vous permet pas d’utiliser le jeu de résultats d’une procédure stockée avec une instruction INSERT. Toutefois, il existe une autre approche que vous pouvez utiliser. Pour obtenir un exemple, consultez l’article sur les tables temporaires.

Limites

Il existe certains aspects de Transact-SQL procédures stockées qui ne sont pas implémentées dans un pool SQL dédié, comme suit :

• procédures stockées temporaires
• procédures stockées numérotées
• procédures stockées étendues
• Procédures stockées CLR
• option de chiffrement
• option de réplication
• paramètres de type table
• Paramètres en lecture seule
• paramètres par défaut
• contextes d’exécution
• return, instruction

Étapes suivantes

Pour obtenir des conseils supplémentaires, consultez la vue d’ensemble du développement.