Uso di stored procedure per pool SQL dedicati in Azure Synapse Analytics
Questo articolo fornisce suggerimenti per lo sviluppo di soluzioni di pool SQL dedicate 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 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 anche 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 essere ancora più flessibile.
Il pool SQL dedicato offre un'implementazione semplificata e semplificata della 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 consiste nel 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, tradotte 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, il livello di annidamento in SQL Server è 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. Di conseguenza, è necessario tenere traccia del livello di annidamento. È improbabile che si superi il limite di otto livelli di annidamento. In questo caso, tuttavia, è necessario rielaborare il codice per adattare i livelli di annidamento entro questo limite.
INSERT..EXECUTE
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 delle stored procedure Transact-SQL che non sono implementate nel 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.