Azure Synapse Analytics'te ayrılmış SQL havuzuyla işlemleri kullanma

Makale
06/01/2023

Çözüm geliştirmek için Azure Synapse Analytics'te ayrılmış SQL havuzuyla işlem gerçekleştirmeye yönelik ipuçları.

Beklentiler

Beklediğiniz gibi ayrılmış SQL havuzu, veri ambarı iş yükünün bir parçası olarak işlemleri destekler. Ancak, ayrılmış SQL havuzunun performansının büyük ölçekte korunduğundan emin olmak için bazı özellikler SQL Server karşılaştırıldığında sınırlıdır. Bu makalede farklar vurgulanır ve diğerleri listelenir.

İşlem yalıtım düzeyleri

Ayrılmış SQL havuzu ACID işlemleri uygular. İşlem desteğinin yalıtım düzeyi varsayılan olarak READ UNCOMMITTED şeklindedir. Ana veritabanına bağlıyken bir kullanıcı veritabanı için READ_COMMITTED_SNAPSHOT veritabanı seçeneğini AÇARAK BUNU READ COMMITTED SNAPSHOT ISOLATION olarak değiştirebilirsiniz.

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ı dikkate alınmaz. Ayrıntılar için ALTER DATABASE SET seçeneklerini (Transact-SQL) denetleyin.

İş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. Bu nedenle, toplam ayırma, sınırın dağıtım sayısıyla çarpılmasıyla hesaplanabilir.

İş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 uzunluktaki sütunlar için en büyük boyutu kullanmak yerine ortalama sütun uzunluğu almayı göz önünde bulundurun.

Aşağıdaki tabloda aşağıdaki varsayımlar yapılmıştır:

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

2. Nesil

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 Sayısı
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'yi seçin	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

1. Nesil

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 Sayısı
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.

Günlüğe yazılan veri miktarını iyileştirmek ve en aza indirmek için İşlemler için en iyi yöntemler makalesine bakın.

Uyarı

Maksimum işlem boyutu yalnızca karma veya verilerin yayılmasının eşit olduğu dağıtılmış tablolar ROUND_ROBIN elde edilebilir. İşlem verileri dağıtımlara eğilmiş bir şekilde yazıyorsa maksimum işlem boyutundan önce sınıra ulaşılma olasılığı yüksektir.

İşlem durumu

Ayrılmış SQL havuzu, -2 değerini kullanarak başarısız bir işlemi raporlamak için XACT_STATE() işlevini kullanır. Bu değer, işlemin başarısız olduğu ve yalnızca geri alma için işaretleneceği anlamına gelir.

Not

Başarısız bir işlemi belirtmek için XACT_STATE işlevi tarafından -2 kullanılması, SQL Server farklı davranışı temsil eder. SQL Server, yaygın olmayan bir işlemi temsil etmek için -1 değerini kullanır. SQL Server, işlem içindeki bazı hataların nadir olarak işaretlenmesi gerekmeden tolere edilebilir. Örneğin SELECT 1/0 , bir hataya neden olabilir ancak bir işlemi yaygın olmayan bir duruma zorlamaz. SQL Server, yaygın olmayan işlemde okumalara da izin verir. Ancak, ayrılmış SQL havuzu bunu yapmanıza izin vermez. Ayrılmış bir SQL havuzu işlemi içinde hata oluşursa otomatik olarak -2 durumuna girer ve deyimi geri alınana kadar başka seçme deyimi yapamazsınız. Bu nedenle, kod değişiklikleri yapmanız gerekebileceği için uygulama kodunuzun XACT_STATE() kullanıp kullanmadığını denetlemek önemlidir.

Örneğin, SQL Server aşağıdakine benzer bir işlem görebilirsiniz:

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ı. Neden: Yalnızca geri alma durumundaki bir işlem DDL, DML veya SELECT deyimi öncesinde açıkça geri alınmadı.

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

Ayrılmış SQL havuzunda kodun biraz değiştirilmesi gerekir:

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 beklenen değerleri sağlar.

Değişen tek şey, CATCH bloğundaki hata bilgilerinin okunmasından önce işlemin ROLLBACK işleminin gerçekleşmesi olmasıdır.

Error_Line() işlevi

Ayrılmış SQL havuzunun ERROR_LINE() işlevini uygulamadığını veya desteklemediğini de belirtmek gerekir. Kodunuzda bu işlev varsa, ayrılmış SQL havuzuyla uyumlu olması için bu işlevi kaldırmanız gerekir. Eşdeğer işlevleri uygulamak için bunun yerine kodunuzda sorgu etiketlerini kullanın. Daha fazla bilgi için LABEL makalesine bakın.

THROW ve RAISERROR kullanımı

THROW, ayrılmış SQL havuzunda özel durumlar oluşturmak için daha modern bir uygulamadır, ancak RAISERROR da desteklenir. Ancak dikkat etmeye değer birkaç fark vardır.

Kullanıcı tanımlı hata iletileri numaraları THROW için 100.000 - 150.000 aralığında olamaz
RAISERROR hata iletileri 50.000'de düzeltildi
sys.messages kullanımı desteklenmiyor

Sınırlamalar

Ayrılmış SQL havuzu, işlemlerle ilgili diğer birkaç kısıtlamaya sahiptir. Bunlar şu şekildedir:

Dağıtılmış işlem yok
İç içe işlemlere izin verilmez
Kaydetme puanına izin verilmiyor
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. Ayrılmış SQL havuzu ve sunucusuz SQL havuzu için ek en iyi yöntem kılavuzları da sağlanır.

Aracılığıyla paylaş