Verwenden von gespeicherten Prozeduren für dedizierte SQL-Pools in Azure Synapse Analytics

Dieser Artikel enthält Tipps zum Entwickeln dedizierter SQL-Poollösungen durch Implementieren von gespeicherten Prozeduren.

Was dich erwartet

Der dedizierte SQL-Pool unterstützt viele der T-SQL-Features, die in SQL Server verwendet werden. Wichtiger ist, dass es skalierungsspezifische Features gibt, die Sie verwenden können, um die Leistung Ihrer Lösung zu maximieren.

Darüber hinaus gibt es zusätzliche Features und Funktionen, die Verhaltensunterschiede aufweisen, um die Skalierung und Leistung des dedizierten SQL-Pools aufrechtzuerhalten.

Einführung von gespeicherten Prozeduren

Gespeicherte Prozeduren eignen sich hervorragend zum Kapseln des SQL-Codes, der in der Nähe ihrer dedizierten SQL-Pooldaten gespeichert ist. Gespeicherte Prozeduren helfen Entwicklern auch, ihre Lösungen zu modularisieren, indem der Code in verwaltbare Einheiten gekapselt wird, wodurch die Wiederverwendbarkeit von Code erleichtert wird. Jede gespeicherte Prozedur kann auch Parameter akzeptieren, um sie noch flexibler zu gestalten.

Der dedizierte SQL-Pool bietet eine vereinfachte und optimierte Implementierung gespeicherter Prozeduren. Der größte Unterschied im Vergleich zu SQL Server besteht darin, dass die gespeicherte Prozedur kein vorkompilierter Code ist.

Im Allgemeinen ist die Kompilierungszeit für Data Warehouses im Vergleich zu der Zeit, die zum Ausführen von Abfragen für große Datenvolumes benötigt wird, gering. Es ist wichtiger, sicherzustellen, dass der gespeicherte Prozedurcode für große Abfragen ordnungsgemäß optimiert ist.

Tipp

Ziel ist es, Stunden, Minuten und Sekunden zu sparen, nicht Millisekunden. Daher ist es hilfreich, gespeicherte Prozeduren als Container für SQL-Logik zu betrachten.

Wenn ein dedizierter SQL-Pool Ihre gespeicherte Prozedur ausführt, werden die SQL-Anweisungen zur Laufzeit analysiert, übersetzt und optimiert. Während dieses Prozesses wird jede Anweisung in verteilte Abfragen konvertiert. Der SQL-Code, der für die Daten ausgeführt wird, unterscheidet sich von der übermittelten Abfrage.

Verschachtelung gespeicherter Prozeduren

Wenn gespeicherte Prozeduren andere gespeicherte Prozeduren aufrufen oder dynamische SQL ausführen, wird die innere gespeicherte Prozedur oder der Codeaufruf als geschachtelt bezeichnet.

Der dedizierte SQL-Pool unterstützt maximal acht Schachtelungsebenen. Im Gegensatz dazu ist die Schachtelungsebene in SQL Server 32.

Der Aufruf der gespeicherten Prozedur auf oberster Ebene entspricht der Schachtelungsebene 1.

EXEC prc_nesting

Wenn die gespeicherte Prozedur auch einen weiteren EXEC-Aufruf vornimmt, erhöht sich die Schachtelungsebene auf zwei.

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

Wenn die zweite Prozedur dann einige dynamische SQL-Vorgänge ausführt, erhöht sich die Schachtelungsebene auf drei.

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

Dedizierter SQL-Pool unterstützt derzeit keine @@NESTLEVEL. Daher müssen Sie die Schachtelungsebene nachverfolgen. Es ist unwahrscheinlich, dass Sie das acht Schachtelungsebenenlimit überschreiten. Wenn Sie dies tun, müssen Sie daher Ihren Code überarbeiten, um die Schachtelungsebenen innerhalb dieses Grenzwerts anzupassen.

EINFÜGEN.. AUSFÜHREN

Der dedizierte SQL-Pool ermöglicht es Ihnen nicht, das Resultset einer gespeicherten Prozedur mit einer INSERT-Anweisung zu nutzen. Es gibt jedoch einen alternativen Ansatz, den Sie verwenden können. Ein Beispiel finden Sie im Artikel zu temporären Tabellen.

Einschränkungen

Es gibt einige Aspekte von Transact-SQL gespeicherten Prozeduren, die nicht in dediziertem SQL-Pool implementiert sind, die wie folgt sind:

• temporäre gespeicherte Prozeduren
• Nummerierte gespeicherte Prozeduren
• erweiterte gespeicherte Prozeduren
• CLR-gespeicherte Prozeduren
• Verschlüsselungsoption
• Replikationsoption
• Parameter mit Tabellenwert
• schreibgeschützte Parameter
• Standardparameter
• Ausführungskontexte
• return-Anweisung

Nächste Schritte

Weitere Hinweise zur Entwicklung finden Sie in der Entwicklungsübersicht.