Używanie transakcji z dedykowaną pulą SQL w usłudze Azure Synapse Analytics

Porady dotyczące implementowania transakcji z dedykowaną pulą SQL w usłudze Azure Synapse Analytics na potrzeby opracowywania rozwiązań.

Czego można się spodziewać

Zgodnie z oczekiwaniami dedykowana pula SQL obsługuje transakcje w ramach obciążenia magazynu danych. Jednak w celu zapewnienia wydajności dedykowanej puli SQL na dużą skalę niektóre funkcje są ograniczone w porównaniu z programem SQL Server. W tym artykule wyróżniono różnice i wymieniono inne.

Poziomy izolacji transakcji

Dedykowana pula SQL implementuje transakcje ACID. Poziom izolacji obsługi transakcyjnej domyślnie wynosi ODCZYT NIEZATWIERDZONY. Można to zmienić na IZOLACJĘ ZATWIERDZONEJ MIGAWKI ODCZYTU (READ COMMITTED SNAPSHOT ISOLATION), włączając opcję READ_COMMITTED_SNAPSHOT dla bazy danych użytkownika, gdy jest połączona z bazą danych master.

Po włączeniu wszystkie transakcje w tej bazie danych są wykonywane w poziomie izolacji dokumentu READ COMMITTED SNAPSHOT, a ustawienie poziomu izolacji ODCZYT NIEZATWIERDZONY na poziomie sesji nie zostanie uwzględnione. Aby uzyskać szczegółowe informacje, sprawdź ALTER DATABASE SET options (Transact-SQL).

Rozmiar transakcji

Jedna transakcja modyfikacji danych jest ograniczona w rozmiarze. Limit jest stosowany dla każdej dystrybucji. W związku z tym łączna alokacja może być obliczana przez pomnożenie limitu przez liczbę rozkładów.

Aby przybliżyć maksymalną liczbę wierszy w transakcji, podziel limit dystrybucji przez całkowity rozmiar każdego wiersza. W przypadku kolumn o zmiennej długości rozważ użycie średniej długości kolumny zamiast maksymalnego rozmiaru.

W poniższej tabeli zostały przyjęte następujące założenia:

• Wystąpił równomierny rozkład danych
• Średnia długość wiersza to 250 bajtów

Gen2

Generacja 1

Limit rozmiaru transakcji jest stosowany dla transakcji lub operacji. Nie jest ona stosowana we wszystkich równoczesnych transakcjach. W związku z tym każda transakcja może zapisywać tę ilość danych w dzienniku.

Aby zoptymalizować i zminimalizować ilość danych zapisanych w dzienniku, zapoznaj się z artykułem Transactions best practices (Najlepsze rozwiązania dotyczące transakcji).

Stan transakcji

Dedykowana pula SQL używa funkcji XACT_STATE(), aby zgłosić nieudaną transakcję przy użyciu wartości -2. Ta wartość oznacza, że transakcja nie powiodła się i jest oznaczona tylko na potrzeby wycofywania.

Na przykład w programie SQL Server może zostać wyświetlona transakcja, która wygląda następująco:

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;

Powyższy kod zawiera następujący komunikat o błędzie:

Msg 111233, poziom 16, stan 1, wiersz 1 111233; Bieżąca transakcja została przerwana i wszystkie oczekujące zmiany zostały wycofane. Przyczyna: Transakcja w stanie wycofywania nie została jawnie wycofana przed instrukcją DDL, DML lub SELECT.

Nie uzyskasz danych wyjściowych funkcji ERROR_*.

W dedykowanej puli SQL kod musi zostać nieco zmieniony:

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;

Oczekiwane zachowanie jest teraz obserwowane. Błąd transakcji jest zarządzany, a funkcje ERROR_* zapewniają wartości zgodnie z oczekiwaniami.

Wszystko, co się zmieniło, to że wycofanie transakcji musiało nastąpić przed odczytaniem informacji o błędzie w bloku CATCH.

Error_Line(), funkcja

Warto również zauważyć, że dedykowana pula SQL nie implementuje ani nie obsługuje funkcji ERROR_LINE(). Jeśli masz tę funkcję w kodzie, musisz usunąć ją tak, aby była zgodna z dedykowaną pulą SQL. Użyj etykiet zapytań w kodzie, aby zaimplementować równoważne funkcje. Aby uzyskać więcej informacji, zobacz artykuł LABEL.

Korzystanie z funkcji THROW i RAISERROR

THROW to bardziej nowoczesna implementacja do zgłaszania wyjątków w dedykowanej puli SQL, ale jest również obsługiwana funkcja RAISERROR. Istnieje kilka różnic, które warto jednak zwrócić uwagę.

• Liczby komunikatów o błędach zdefiniowanych przez użytkownika nie mogą znajdować się w zakresie od 100 000 do 150 000 dla funkcji THROW
• Komunikaty o błędach RAISERROR zostały naprawione na poziomie 50 000
• Korzystanie z pliku sys.messages nie jest obsługiwane

Ograniczenia

Dedykowana pula SQL ma kilka innych ograniczeń odnoszących się do transakcji. Są one następujące:

• Brak transakcji rozproszonych
• Brak dozwolonych zagnieżdżonych transakcji
• Brak dozwolonych punktów zapisywania
• Brak nazwanych transakcji
• Brak oznaczonych transakcji
• Brak obsługi języka DDL, takiego jak CREATE TABLE wewnątrz transakcji zdefiniowanej przez użytkownika

Następne kroki

Aby dowiedzieć się więcej na temat optymalizowania transakcji, zobacz Transactions best practices. Dodatkowe przewodniki dotyczące najlepszych rozwiązań są również dostępne dla dedykowanej puli SQL oraz bezserwerowej puli SQL.