Azure Synapse'da SQL havuzunda işlemleri kullanma

Bu makale, sql havuzunda işlem gerçekleştirmeye ve çözümler geliştirmeye yönelik ipuçları içerir.

Beklentiler

Beklediğiniz gibi SQL havuzu, veri ambarı iş yükünün bir parçası olarak işlemleri destekler. Ancak, SQL havuzunun büyük ölçekte tutulduğ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.

İşlem yalıtım düzeyleri

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 bir kullanıcı SQL havuzu 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 dağıtım sayısıyla çarpılarak 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 sütun uzunluğu almayı göz önünde bulundurun.

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

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

2. Nesil

1. Nesil

İş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 lütfen İşlemler için en iyi yöntemler makalesine bakın.

İşlem durumu

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.

SQL Server, yaygın olmayan işlemde okumalara da izin verir. Ancak, SQL havuzu bunu yapmanıza izin vermez. 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, kodda değişiklik 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ı. Bu sorunun nedeni, yalnızca geri alma durumundaki bir işlemin bir DDL, DML veya SELECT deyiminden önce açıkça geri alınmamasıdır.

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

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

SQL havuzunun ERROR_LINE() işlevini uygulamadığını veya desteklemediğini de belirtmek gerekir. Kodunuzda bu varsa SQL havuzuyla uyumlu olması için bunu kaldırmanız gerekir.

Eşdeğer işlevleri uygulamak için bunun yerine kodunuzda sorgu etiketlerini kullanın. Diğer ayrıntılar için LABEL makalesine bakın.

THROW ve RAISERROR kullanma

THROW, 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

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. Diğer SQL havuzu en iyi yöntemleri hakkında bilgi edinmek için bkz. SQL havuzu en iyi yöntemleri.