Utilizzo delle stored procedure con i pool SQL dedicati in Azure Synapse Analytics

Questo articolo fornisce suggerimenti per lo sviluppo di soluzioni di pool SQL dedicate implementando stored procedure.

Cosa aspettarsi

Il pool SQL dedicato supporta molte delle funzionalità T-SQL usate in SQL Server. Più importante, sono disponibili funzionalità specifiche di scalabilità orizzontale che è possibile usare per ottimizzare le prestazioni della soluzione.

Inoltre, per mantenere la scalabilità e le prestazioni del pool SQL dedicato, sono disponibili funzionalità e funzionalità aggiuntive che presentano differenze comportamentali.

Introduzione alle stored procedure

Le stored procedure sono un ottimo modo per incapsulare il codice SQL, archiviato vicino ai dati del pool SQL dedicato. Le stored procedure consentono inoltre agli sviluppatori di modularizzare le proprie soluzioni incapsulando il codice in unità gestibili, semplificando così una maggiore riutilizzabilità del codice. Ogni stored procedure può anche accettare parametri per renderli ancora più flessibili.

Il pool SQL dedicato offre un'implementazione semplice e snella delle stored procedure. La differenza principale rispetto a SQL Server è che la stored procedure non è codice precompilato.

In generale, per i data warehouse, il tempo di compilazione è ridotto rispetto al tempo necessario per eseguire query su volumi di dati di grandi dimensioni. È più importante assicurarsi che il codice della stored procedure sia ottimizzato correttamente per le query di grandi dimensioni.

Suggerimento

L'obiettivo è risparmiare ore, minuti e secondi, non millisecondi. È quindi utile considerare le stored procedure come contenitori per la logica SQL.

Quando un pool SQL dedicato esegue la stored procedure, le istruzioni SQL vengono analizzate, convertite e ottimizzate in fase di esecuzione. Durante questo processo, ogni istruzione viene convertita in query distribuite. Il codice SQL eseguito sui dati è diverso dalla query inviata.

Annidamento di procedure memorizzate

Quando le procedure memorizzate chiamano altre procedure memorizzate o eseguono SQL dinamico, la procedura memorizzata interna o l'invocazione del codice viene definita come annidata.

Il pool SQL dedicato supporta un massimo di otto livelli di annidamento. In confronto, il livello di annidamento in SQL Server è 32.

La chiamata di stored procedure al livello superiore corrisponde al livello di annidamento 1.

EXEC prc_nesting

Se la procedura memorizzata esegue anche un'altra chiamata EXEC, il livello di annidamento raggiunge il valore di due.

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

Se la seconda procedura esegue un codice SQL dinamico, il livello di annidamento aumenta a tre.

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

Il pool SQL dedicato attualmente non supporta @@NESTLEVEL. Di conseguenza, è necessario tenere traccia del livello di annidamento. È improbabile che si superi il limite di otto livelli di annidamento. Tuttavia, in questo caso, è necessario rielaborare il codice per adattare i livelli di annidamento entro questo limite.

INSERIRE.. ESEGUIRE

Il pool SQL dedicato non consente di utilizzare il set di risultati di una stored procedure con un'istruzione INSERT. Esiste tuttavia un approccio alternativo che è possibile usare. Per un esempio, vedere l'articolo sulle tabelle temporanee.

Limitazioni

Esistono alcuni aspetti di Transact-SQL stored procedure che non vengono implementate nel pool SQL dedicato, come indicato di seguito:

• stored procedure temporanee
• stored procedure numerata
• extended stored procedure
• Procedure memorizzate CLR
• opzione di crittografia
• opzione di replica
• Parametri con valori di tabella
• parametri di sola lettura
• parametri predefiniti
• contesti di esecuzione
• istruzione return

Passaggi successivi

Per altri suggerimenti sullo sviluppo, vedere Panoramica dello sviluppo.