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

Tip

Microsoft Fabric Data Warehouse geleceğe hazır mimariye, yerleşik yapay zekaya ve yeni özelliklere sahip data lake foundation üzerinde kurumsal ölçekli ilişkisel bir ambardır. Veri ambarı konusunda yeniyseniz Fabric Data Warehouse ile başlayın. Mevcut özel SQL havuzu iş yükleri, veri bilimi, gerçek zamanlı analiz ve raporlama genelinde yeni özelliklere erişmek için Fabric yükseltilebilir.

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

Ne beklenmeli

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 SQL Server ile karşılaştırıldığında bazı özellikler 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şlemlerini uygular. İşlem desteğinin yalıtım düzeyi varsayılan olarak READ UNCOMMITTED olarak ayarlanır. Ana veritabanına bağlıyken 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ı 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. 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 uzunluklu sütunlar için maksimum boyutu kullanmak yerine ortalama bir 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ğı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.

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

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

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.

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. Örneğin SELECT 1/0 , bir hataya neden olur, ancak bir işlemi seyrek karşılaşılan bir duruma zorlamaz. SQL Server ayrıca, tamamlanmamış işlemde okumalara 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'da 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 alınabilir durumda olan 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 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

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 havuzunun işlemlerle ilgili birkaç kısıtlaması daha vardır. Bunlar aşağıdaki gibidir:

  • Dağıtılmış işlem yok
  • İç içe işlemlere izin verilmez
  • Kaydetme noktalarına izin yok
  • 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öntemler kılavuzları da sağlanır.

  • Last updated on