Use transactions with dedicated SQL pool in Azure Synapse Analytics

Tips for implementing transactions with dedicated SQL pool in Azure Synapse Analytics for developing solutions.

Ne beklenmeli

As you would expect, dedicated SQL pool supports transactions as part of the data warehouse workload. However, to ensure the performance of dedicated SQL pool is maintained at scale some features are limited when compared to SQL Server. This article highlights the differences and lists the others.

İşlem yalıtım düzeyleri

Dedicated SQL pool implements ACID transactions. İşlem desteğinin yalıtım düzeyi varsayılan olarak READ UNCOMMITTED olarak ayarlanır. You can change it to READ COMMITTED SNAPSHOT ISOLATION by turning ON the READ_COMMITTED_SNAPSHOT database option for a user database when connected to the master database.

Etkinleştirildikten sonra, bu veritabanındaki tüm işlemler READ COMMITTED SNAPSHOT ISOLATION altında yürütülür ve oturum düzeyinde READ UNCOMMITTED ayarı uygulanmaz. Ayrıntılar için ALTER DATABASE SET seçeneklerine (Transact-SQL) bakın.

İşlem boyutu

Tek bir veri değiştirme işleminin boyutu sınırlıdır. Sınır, dağıtım başına uygulanır. As such, the total allocation can be calculated by multiplying the limit by the distribution count.

İşlemdeki en fazla satır sayısını yaklaşık olarak ayarlamak için dağıtım üst sınırını her satırın toplam boyutuna bölün. Değişken uzunluklu sütunlar için maksimum boyutu kullanmak yerine ortalama bir sütun uzunluğu almayı göz önünde bulundurun.

In the table below the following assumptions have been made:

Verilerin eşit bir dağıtımı oluştu
Ortalama satır uzunluğu 250 bayttır

Gen2

DWU	Dağıtım başına üst sınır (GB)	Dağıtım Sayısı	MAX işlem boyutu (GB)	# Dağıtım başına satır sayısı	İşlem başına En Fazla Satır
DW100c	1	60	60	4.000.000	240,000,000
DW200c	1.5	60	90	6,000,000	360.000.000
DW300c	2,25	60	135	9,000,000	540,000,000
DW400c	3	60	180	12,000,000	720,000,000
DW500c	3.75	60	225	15.000.000	900,000,000
DW1000c	7.5	60	450	30,000,000	1,800,000,000
DW1500c	11.25	60	675	45,000,000	2,700,000,000
DW2000c	15	60	900	60.000.000	3,600,000,000
DW2500c	18.75	60	1125	75,000,000	4,500,000,000
DW3000c	22.5	60	1,350	90,000,000	5,400,000,000
DW5000c	37,5	60	2,250	150,000,000	9,000,000,000
DW6000c	45	60	2,700	180,000,000	10,800,000,000
DW7500c	56.25	60	3,375	225,000,000	13,500,000,000
DW10000c	75	60	4.500	300,000,000	18,000,000,000
DW15000c	112.5	60	6,750	450,000,000	27,000,000,000
DW30000c	225	60	13,500	900,000,000	54,000,000,000

Gen1

DWU	Dağıtım başına üst sınır (GB)	Dağıtım Sayısı	MAX işlem boyutu (GB)	# Dağıtım başına satır sayısı	İşlem başına En Fazla Satır
DW100	1	60	60	4.000.000	240,000,000
DW200	1.5	60	90	6,000,000	360.000.000
DW300	2,25	60	135	9,000,000	540,000,000
DW400	3	60	180	12,000,000	720,000,000
DW500	3.75	60	225	15.000.000	900,000,000
DW600	4,5	60	270	18.000.000	1,080,000,000
DW1000	7.5	60	450	30,000,000	1,800,000,000
DW1200	9	60	540	36,000,000	2,160,000,000
DW1500	11.25	60	675	45,000,000	2,700,000,000
DW2000	15	60	900	60.000.000	3,600,000,000
DW3000	22.5	60	1,350	90,000,000	5,400,000,000
DW6000	45	60	2,700	180,000,000	10,800,000,000

İşlem boyutu sınırı, işlem veya işlem başına uygulanır. Tüm eşzamanlı işlemlere uygulanmaz. Bu nedenle her işlemin günlüğe bu miktarda veri yazmasına izin verilir.

To optimize and minimize the amount of data written to the log, refer to the Transactions best practices article.

Uyarı

Maksimum işlem boyutu, yalnızca verilerin eşit olarak dağıtıldığı HASH veya ROUND_ROBIN dağıtılmış tablolar için elde edilebilir. İşlem verileri dağıtımlara çarpık bir şekilde yazıyorsa maksimum işlem boyutundan önce sınıra ulaşılması olasıdır.

İşlem durumu

Dedicated SQL pool uses the XACT_STATE() function to report a failed transaction using the value -2. Bu değer, işlemin başarısız olduğu ve yalnızca geri alma için işaretleneceği anlamına gelir.

Uyarı

başarısız bir işlemi belirtmek için XACT_STATE işlevi tarafından -2 kullanılması SQL Server'da farklı bir davranışı temsil eder. SQL Server, taahhüt edilemeyen bir işlemi temsil etmek için -1 değerini kullanır. SQL Server, işlem içindeki bazı hataları, istenmeyen olarak işaretlenmesi gerekmeden tolere edebilir. For example SELECT 1/0 would cause an error but not force a transaction into an uncommittable state. SQL Server ayrıca, tamamlanmamış işlemde okumalara izin verir. However, dedicated SQL pool does not let you do this. If an error occurs inside a dedicated SQL pool transaction it will automatically enter the -2 state and you will not be able to make any further select statements until the statement has been rolled back. It is therefore important to check that your application code to see if it uses XACT_STATE() as you may need to make code modifications.

For example, in SQL Server you might see a transaction that looks like the following:

SET NOCOUNT ON;
DECLARE @xact_state smallint = 0;

BEGIN TRAN
    BEGIN TRY
        DECLARE @i INT;
        SET     @i = CONVERT(INT,'ABC');
    END TRY
    BEGIN CATCH
        SET @xact_state = XACT_STATE();

        SELECT  ERROR_NUMBER()    AS ErrNumber
        ,       ERROR_SEVERITY()  AS ErrSeverity
        ,       ERROR_STATE()     AS ErrState
        ,       ERROR_PROCEDURE() AS ErrProcedure
        ,       ERROR_MESSAGE()   AS ErrMessage
        ;

        IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRAN;
            PRINT 'ROLLBACK';
        END

    END CATCH;

IF @@TRANCOUNT >0
BEGIN
    PRINT 'COMMIT';
    COMMIT TRAN;
END

SELECT @xact_state AS TransactionState;

Yukarıdaki kod aşağıdaki hata iletisini verir:

İleti 111233, Düzey 16, Durum 1, Satır 1 111233; Geçerli işlem durduruldu ve bekleyen değişiklikler geri alındı. Cause: A transaction in a rollback-only state wasn't explicitly rolled back before a DDL, DML, or SELECT statement.

ERROR_* işlevlerinin çıkışını almazsınız.

In dedicated SQL pool, the code needs to be slightly altered:

SET NOCOUNT ON;
DECLARE @xact_state smallint = 0;

BEGIN TRAN
    BEGIN TRY
        DECLARE @i INT;
        SET     @i = CONVERT(INT,'ABC');
    END TRY
    BEGIN CATCH
        SET @xact_state = XACT_STATE();

        IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRAN;
            PRINT 'ROLLBACK';
        END

        SELECT  ERROR_NUMBER()    AS ErrNumber
        ,       ERROR_SEVERITY()  AS ErrSeverity
        ,       ERROR_STATE()     AS ErrState
        ,       ERROR_PROCEDURE() AS ErrProcedure
        ,       ERROR_MESSAGE()   AS ErrMessage
        ;
    END CATCH;

IF @@TRANCOUNT >0
BEGIN
    PRINT 'COMMIT';
    COMMIT TRAN;
END

SELECT @xact_state AS TransactionState;

Beklenen davranış artık gözlemlenmiştir. İşlemdeki hata yönetilir ve ERROR_* işlevleri beklendiği gibi değerler sağlar.

Değişen tek şey, CATCH bloğundaki hata bilgilerinin okunmasından önce ROLLBACK işleminin yapılması gerektiğiydi.

Error_Line() işlevi

It is also worth noting that dedicated SQL pool does not implement or support the ERROR_LINE() function. If you have this function in your code, you need to remove it to be compliant with dedicated SQL pool. Eşdeğer işlevleri uygulamak için bunun yerine kodunuzda sorgu etiketlerini kullanın. For more information, see the LABEL article.

Use of THROW and RAISERROR

THROW is the more modern implementation for raising exceptions in dedicated SQL pool but RAISERROR is also supported. Ancak dikkat etmeye değer birkaç fark vardır.

User-defined error messages numbers can't be in the 100,000 - 150,000 range for THROW
RAISERROR hata iletileri 50.000'de düzeltildi
sys.messages kullanımı desteklenmiyor

Sınırlamalar

Dedicated SQL pool does have a few other restrictions that relate to transactions. Bunlar aşağıdaki gibidir:

Dağıtılmış işlem yok
İç içe işlemlere izin verilmez
No save points allowed
Adlandırılmış işlem yok
İşaretli işlem yok
Kullanıcı tanımlı işlem içinde CREATE TABLE gibi DDL desteği yoktur

Sonraki adımlar

İşlemleri iyileştirme hakkında daha fazla bilgi edinmek için bkz. İşlemler için en iyi yöntemler. Additional best practices guides are also provided for Dedicated SQL pool and serverless SQL pool.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-04-12