Uso di stored procedure per pool SQL dedicati in Azure Synapse Analytics

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

Risultati previsti

Il pool SQL dedicato supporta molte delle funzionalità T-SQL usate in SQL Server. Ancora più importanti sono le funzionalità di scale-out specifiche, che si possono usare per migliorare le prestazioni della soluzione.

Inoltre, per mantenere la scalabilità e le prestazioni del pool SQL dedicato, sono disponibili caratteristiche 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 rendere modulari le soluzioni incapsulando il codice in unità gestibili, facilitano così il riutilizzo del codice stesso. Ogni stored procedure può anche accettare parametri per essere ancora più flessibile.

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

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

Suggerimento

L'obiettivo consiste nel risparmiare ore, minuti e secondi, non millisecondi. È quindi utile pensare alle stored procedure come contenitori per la logica di 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 stored procedure

Quando le stored procedure chiamano altre stored procedure o eseguono istruzioni SQL dinamiche, la stored procedure o la chiamata di codice interna è detta annidata.

Il pool SQL dedicato supporta un massimo di otto livelli di annidamento. Al contrario, in SQL Server i livelli di annidamento sono 32.

La chiamata di stored procedure di massimo livello equivale al livello di annidamento 1.

EXEC prc_nesting

Se la stored procedure effettua anche un'altra chiamata EXEC, il livello di annidamento aumenta a due.

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

Se la seconda routine esegue poi istruzioni in SQL dinamico, il livello di annidamento aumenterà 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. Pertanto, è necessario tenere traccia del livello di annidamento. È improbabile che il limite di otto livelli di annidamento venga superato. Tuttavia, in questo caso, è necessario rielaborare il codice per adattare i livelli di annidamento entro questo limite.

INSERT..EXECUTE

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

Limiti

Esistono alcuni aspetti delle stored procedure Transact-SQL che non sono implementate in un pool SQL dedicato, come indicato di seguito:

• Stored procedure temporanee
• Stored procedure numerate
• Stored procedure estese
• Stored procedure 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 la panoramica dello sviluppo.