Menggunakan transaksi dalam kumpulan SQL di Azure Synapse

Artikel ini mencakup tips untuk menerapkan transaksi dan mengembangkan solusi di kumpulan SQL.

Apa yang diharapkan

Seperti yang Anda harapkan, kumpulan SQL mendukung transaksi sebagai bagian dari beban kerja gudang data. Namun, untuk memastikan kumpulan SQL dipertahankan dalam skala besar, beberapa fitur dibatasi jika dibandingkan dengan SQL Server. Artikel ini menyoroti perbedaannya.

Tingkat isolasi transaksi

Kumpulan SQL mengimplementasikan transaksi ACID. Tingkat isolasi dukungan transaksi secara default adalah BACA TANPA KOMITMEN. Anda dapat mengubahnya menjadi READ COMMITTED SNAPSHOT ISOLATION dengan mengaktifkan opsi database READ_COMMITTED_SNAPSHOT untuk kumpulan SQL pengguna saat tersambung ke database master.

Setelah diaktifkan, semua transaksi dalam database ini dijalankan di bagian READ COMMITTED SNAPSHOT ISOLATION dan pengaturan READ UNCOMMITTED pada tingkat sesi tidak akan diindahkan. Periksa opsi ALTER DATABASE SET (Transact-SQL) untuk detailnya.

Ukuran transaksi

Satu transaksi modifikasi data berukuran terbatas. Batas diterapkan per distribusi. Oleh karena itu, total alokasi dapat dihitung dengan mengalikan batas dengan jumlah distribusi.

Untuk memperkirakan jumlah maksimum baris dalam sebuah transaksi, bagi batas distribusi dengan ukuran total setiap baris. Untuk kolom panjang variabel, pertimbangkan untuk mengambil panjang kolom rata-rata daripada menggunakan ukuran maksimum.

Dalam tabel berikut, dua asumsi telah dibuat:

Distribusi data yang merata telah terjadi
Panjang baris rata-rata adalah 250 byte

Gen2

DWU	Batas maksimum per distribusi (GB)	Jumlah Distribusi	Ukuran transaksi MAX (GB)	Jumlah baris per distribusi	Baris Maks per transaksi
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	Batas maksimum per distribusi (GB)	Jumlah Distribusi	Ukuran transaksi MAX (GB)	Jumlah baris per distribusi	Baris Maks per transaksi
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

Batas ukuran transaksi diterapkan per transaksi atau operasi. Ini tidak diterapkan di semua transaksi bersamaan. Oleh karena itu, setiap transaksi diizinkan untuk menulis jumlah data ini ke log.

Untuk mengoptimalkan dan meminimalkan jumlah data yang ditulis ke log, lihat artikel Praktik terbaik Transaksi .

Peringatan

Ukuran transaksi maksimum hanya dapat dicapai untuk HASH atau tabel terdistribusi ROUND_ROBIN di mana penyebaran data merata. Jika transaksi menulis data dengan cara yang tidak merata pada distribusi, maka batas kemungkinan akan tercapai sebelum ukuran transaksi maksimum.

Status transaksi

Kumpulan SQL menggunakan fungsi XACT_STATE() untuk melaporkan transaksi yang gagal menggunakan nilai -2. Nilai ini berarti transaksi telah gagal dan hanya ditandai untuk pembatalan.

Nota

Penggunaan -2 oleh fungsi XACT_STATE untuk menunjukkan transaksi yang gagal mewakili perilaku yang berbeda dengan SQL Server. SQL Server menggunakan nilai -1 untuk mewakili transaksi yang tidak dapat diselesaikan. SQL Server dapat mentolerir beberapa kesalahan di dalam transaksi tanpa harus ditandai sebagai tidak dapat dikomit. Misalnya, SELECT 1/0 akan menyebabkan kesalahan tetapi tidak memaksa transaksi ke dalam status yang tidak dapat diterapkan.

SQL Server juga mengizinkan pembacaan dalam transaksi yang belum dikomit. Namun, kumpulan SQL tidak memungkinkan Anda melakukan ini. Jika kesalahan terjadi di dalam transaksi kumpulan SQL, itu akan secara otomatis memasuki status -2 dan Anda tidak akan dapat membuat pernyataan pemilihan lebih lanjut sampai pernyataan telah digulung balik.

Dengan demikian, penting untuk memeriksa apakah kode aplikasi Anda untuk melihat apakah kode tersebut menggunakan XACT_STATE() karena Anda mungkin perlu melakukan modifikasi kode.

Misalnya, di SQL Server, Anda mungkin melihat transaksi yang terlihat seperti berikut ini:

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;

Kode sebelumnya memberikan pesan kesalahan berikut:

Msg 111233, Level 16, State 1, Line 1 111233; Transaksi saat ini telah dibatalkan, dan setiap perubahan yang tertunda telah digulung balik. Penyebab masalah ini adalah bahwa transaksi dalam status rollback-only tidak secara eksplisit digulung balik sebelum pernyataan DDL, DML, atau SELECT.

Anda tidak akan mendapatkan output fungsi ERROR_*.

Di kumpulan SQL kode perlu sedikit diubah:

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;

Perilaku yang diharapkan sekarang diamati. Kesalahan dalam transaksi dikelola dan fungsi ERROR_* memberikan nilai seperti yang diharapkan.

Yang telah berubah hanya bahwa ROLLBACK dari transaksi harus terjadi sebelum pembacaan informasi kesalahan tersebut pada blok CATCH.

fungsi Error_Line()

Perlu juga dicatat bahwa kumpulan SQL tidak mengimplementasikan atau mendukung fungsi ERROR_LINE(). Jika Anda memiliki ini dalam kode, Anda perlu menghapusnya agar sesuai dengan kumpulan SQL.

Gunakan label kueri dalam kode Anda sebagai gantinya untuk menerapkan fungsionalitas yang setara. Untuk detail selengkapnya, lihat artikel LABEL .

Menggunakan THROW dan RAISERROR

THROW adalah implementasi yang lebih modern untuk meningkatkan pengecualian di kumpulan SQL tetapi RAISERROR juga didukung. Namun, ada beberapa perbedaan yang patut diperhatikan.

Nomor pesan kesalahan yang ditentukan pengguna tidak boleh berada dalam rentang 100.000 - 150.000 untuk THROW
Pesan kesalahan RAISERROR ditetapkan pada 50.000
Penggunaan sys.messages tidak didukung

Keterbatasan

"SQL pool" memang memiliki beberapa batasan lain yang terkait dengan transaksi.

Mereka adalah sebagai berikut:

Tidak ada transaksi terdistribusi
Tidak ada transaksi berlapis yang diizinkan
Tidak ada titik penyimpanan yang diizinkan
Tidak ada transaksi yang diberi nama
Tidak ada transaksi yang ditandai
Tidak ada dukungan untuk DDL seperti CREATE TABLE di dalam transaksi yang ditentukan pengguna

Langkah berikutnya

Untuk mempelajari selengkapnya tentang mengoptimalkan transaksi, lihat Praktik terbaik transaksi. Untuk mempelajari praktik terbaik kumpulan SQL lainnya, lihat Praktik terbaik kumpulan SQL.

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-04-04