Używanie transakcji w puli SQL w usłudze Azure Synapse

Ten artykuł zawiera porady dotyczące implementowania transakcji i opracowywania rozwiązań w puli SQL.

Czego oczekiwać

Jak można się spodziewać, pula SQL obsługuje transakcje jako część obciążenia magazynu danych. Jednak w celu zapewnienia utrzymania puli SQL na dużą skalę niektóre funkcje są ograniczone w porównaniu z programem SQL Server. W tym artykule przedstawiono różnice.

Poziomy izolacji transakcji

Pula SQL implementuje transakcje ACID. Poziom izolacji obsługi transakcyjnej domyślnie wynosi ODCZYT NIEZATWIERDZONY. Można to zmienić na READ COMMITTED SNAPSHOT ISOLATION, włączając opcję READ_COMMITTED_SNAPSHOT dla puli SQL użytkownika po połączeniu 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 dokonano dwóch założeń:

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

Druga generacja

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

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.

Program SQL Server zezwala również na odczyty w transakcjach niezatwierdzalnych. Jednak pula SQL nie pozwala na to. Jeśli wystąpi błąd wewnątrz transakcji puli SQL, automatycznie przejdzie w stan -2 i nie będzie można wykonać żadnych dalszych zapytań SELECT, dopóki transakcja nie zostanie wycofana.

W związku z tym należy sprawdzić, czy kod aplikacji używa XACT_STATE(), ponieważ może być konieczne wprowadzenie modyfikacji kodu.

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 anulowana, a wszystkie oczekujące zmiany zostały cofnięte. Przyczyną tego problemu jest to, że transakcja w stanie przeznaczonym tylko do wycofania nie zostaje jawnie wycofana przed wykonaniem instrukcji DDL, DML lub SELECT.

Nie uzyskasz danych wyjściowych funkcji ERROR_*.

W 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 pula SQL nie implementuje ani nie obsługuje funkcji ERROR_LINE(). Jeśli masz to w kodzie, musisz go usunąć, aby był zgodny z pulą SQL.

Użyj etykiet zapytań w kodzie, aby zaimplementować równoważne funkcje. Aby uzyskać więcej informacji, zobacz artykuł LABEL .

Używanie funkcji THROW i RAISERROR

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

• Liczba komunikatów o błędach zdefiniowanych przez użytkownika nie może mieścić 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

SQL Pool posiada pewne dodatkowe ograniczenia odnoszące się do transakcji.

Są one następujące:

• Brak transakcji rozproszonych
• Niedozwolone zagnieżdżone transakcje
• 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. Aby dowiedzieć się więcej o innych najlepszych rozwiązaniach dotyczących puli SQL, zobacz Najlepsze rozwiązania dotyczące puli SQL.