Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Tips untuk menerapkan transaksi dengan kumpulan SQL khusus di Azure Synapse Analytics untuk mengembangkan solusi.
Apa yang diharapkan
Seperti yang Anda harapkan, kumpulan SQL khusus mendukung transaksi sebagai bagian dari beban kerja gudang data. Namun, untuk memastikan performa kumpulan SQL khusus dipertahankan dalam skala besar beberapa fitur dibatasi jika dibandingkan dengan SQL Server. Artikel ini menyoroti perbedaan dan mencantumkan yang lain.
Tingkat isolasi transaksi
Kumpulan SQL khusus 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 database 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. Dengan demikian, total alokasi dapat dihitung dengan mengalikan batas maksimum dengan jumlah pendistribusian.
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 di bawah asumsi berikut 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 khusus 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 khusus tidak memungkinkan Anda melakukan ini. Jika terjadi kesalahan di dalam transaksi kumpulan SQL khusus, itu akan secara otomatis memasuki status -2 dan Anda tidak akan dapat membuat pernyataan pemilihan lebih lanjut sampai pernyataan telah digulung balik. Oleh karena itu 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: Transaksi dalam status rollback-only tidak secara eksplisit digulung balik sebelum pernyataan DDL, DML, atau SELECT.
Anda tidak akan mendapatkan output fungsi ERROR_*.
Dalam kumpulan SQL khusus, 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 khusus tidak mengimplementasikan atau mendukung fungsi ERROR_LINE(). Jika Anda memiliki fungsi ini dalam kode, Anda perlu menghapusnya agar sesuai dengan kumpulan SQL khusus. Gunakan label kueri dalam kode Anda sebagai gantinya untuk menerapkan fungsionalitas yang setara. Untuk informasi selengkapnya, lihat artikel LABEL .
Penggunaan THROW dan RAISERROR
THROW adalah implementasi yang lebih modern untuk meningkatkan pengecualian di kumpulan SQL khusus 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
Kumpulan SQL khusus 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. Panduan praktik terbaik tambahan juga disediakan untuk kumpulan SQL Khusus dan kumpulan SQL tanpa server.