Transaksi dalam Fabric Data Warehouse

Berlaku untuk:✅ titik akhir analitik SQL dan Warehouse di Microsoft Fabric

Mirip dengan perilaku mereka dalam SQL Server, transaksi memungkinkan Anda mengontrol penerapan atau pembatalan kueri baca dan tulis.

Fabric Data Warehouse mendukung transaksi yang mematuhi ACID. Setiap transaksi bersifat atomik, konsisten, terisolasi, dan tahan lama (ACID). Semua operasi dalam satu transaksi diperlakukan secara atomik, semua berhasil atau semua gagal. Jika ada pernyataan dalam transaksi yang gagal, seluruh transaksi akan digulung balik.

Transaksi eksplisit

Anda dapat memodifikasi data yang disimpan dalam tabel di Gudang menggunakan transaksi eksplisit untuk mengelompokkan perubahan bersama-sama.

Misalnya, Anda dapat menerapkan penyisipan ke beberapa tabel, atau tidak menerapkan pada tabel mana pun jika terjadi kesalahan. Jika Anda mengubah detail tentang pesanan pembelian yang memengaruhi tiga tabel, Anda dapat mengelompokkan perubahan tersebut menjadi satu transaksi. Itu berarti ketika tabel tersebut dikueri, mereka semua memiliki perubahan atau tidak ada yang melakukannya. Transaksi adalah praktik umum ketika Anda perlu memastikan data Anda konsisten di beberapa tabel.

Anda dapat menggunakan mekanisme kontrol sintaks T-SQL (BEGIN TRAN, COMMIT TRAN, dan ROLLBACK TRAN) standar untuk transaksi eksplisit. Untuk informasi selengkapnya, lihat: - BEGIN TRANSACTION - COMMIT TRANSACTION - ROLLBACK TRANSACTION

Misalnya, Fabric Data Warehouse akan memperlakukan perubahan skema ini sebagai satu unit atom:

-- Sample Syntax--- 
BEGIN TRAN; 
ALTER TABLE <table_name> ADD <column_name> <type>; 
ALTER TABLE <table_name> DROP COLUMN <column_name>; 
COMMIT;

Jika ada pernyataan dalam transaksi yang gagal, semua perubahan skema secara otomatis digulung balik.

Fabric Data Warehouse mendukung eksekusi hal-hal berikut di dalam transaksi eksplisit:

  • CREATE TABLE
  • DROP TABLE
  • TRUNCATE TABLE
  • CTAS
  • sp_rename
  • ALTER TABLE menambahkan kolom nullable
  • ALTER TABLE jatuhkan kolom
  • ALTER TABLE tambahkan atau hapus PRIMARY KEY, UNIQUE, dan FOREIGN KEY batasan menggunakan kata kunci NOT ENFORCED
  • Beberapa ALTER TABLE pernyataan
  • ALTER TABLE pada tabel sementara yang terdistribusi

Dukungan transaksi kueri lintas database

Gudang di Microsoft Fabric mendukung transaksi yang melibatkan gudang-gudang dalam ruang kerja yang sama, termasuk pembacaan dari titik akhir analitik SQL dari Lakehouse. Misalnya, lihat Menulis Kueri SQL lintas database.

Memahami penguncian dan pemblokiran di Fabric Data Warehouse

Fabric Data Warehouse menggunakan penguncian pada tingkat tabel, terlepas dari apakah kueri menyentuh satu baris atau banyak. Tabel berikut ini menyediakan daftar kunci apa yang digunakan untuk operasi T-SQL yang berbeda.

Jenis pernyataan Kunci diambil
DML
SELECT Schema-Stability (Sch-S)
INSERT Maksud Eksklusif (IX)
DELETE Maksud Eksklusif (IX)
UPDATE Maksud Eksklusif (IX)
MERGE Maksud Eksklusif (IX)
SALIN KE DALAM Maksud Eksklusif (IX)
DDL
BUAT TABEL Modifikasi Skema (Sch-M)
ALTER TABLE Modifikasi Skema (Sch-M)
DROP TABLE Modifikasi Skema (Sch-M)
TRUNCATE TABEL Modifikasi Skema (Sch-M)
BUAT TABEL SEBAGAI PILIH Modifikasi Skema (Sch-M)
BUAT TABEL SEBAGAI SALINAN DARI Modifikasi Skema (Sch-M)

Anda dapat melakukan kueri kunci yang saat ini disimpan dengan tampilan manajemen dinamis (DMV) sys.dm_tran_locks.

Untuk informasi selengkapnya tentang kunci, eskalasi kunci, dan kompatibilitas kunci, lihat Panduan penguncian transaksi dan penerapan versi baris.

Isolasi rekam jepret

Fabric Data Warehouse memberlakukan isolasi rekam jepret pada semua transaksi. Isolasi snapshot adalah tingkat isolasi berbasis baris yang menyediakan konsistensi tingkat transaksi untuk data, dan menggunakan versi baris yang disimpan di tempdb untuk memilih baris yang akan diperbarui. Transaksi menggunakan versi baris data yang ada saat transaksi dimulai. Ini memastikan bahwa setiap transaksi beroperasi pada rekam jepret data yang konsisten seperti yang ada di awal transaksi.

Dalam isolasi rekam jepret, kueri dalam transaksi melihat versi atau rekam jepret yang sama, berdasarkan status database saat transaksi dimulai. Dalam isolasi rekam jepret, transaksi yang memodifikasi data tidak memblokir transaksi yang membaca data, dan transaksi yang membaca data tidak memblokir transaksi yang menulis data. Perilaku optimis dan non-pemblokiran ini juga secara signifikan mengurangi kemungkinan kebuntuan untuk transaksi yang kompleks.

Jika Anda menggunakan T-SQL untuk mengubah tingkat isolasi Anda, perubahan diabaikan pada waktu eksekusi kueri dan isolasi rekam jepret diterapkan.

Dalam isolasi rekam jepret, konflik write-write atau pembaruan dimungkinkan, untuk informasi selengkapnya, lihat Pahami konflik write-write di Fabric Data Warehouse.

Kunci skema

Kunci skema mencegah konflik pada pernyataan DDL, seperti skema tabel yang diubah saat baris sedang diperbarui dalam transaksi. Ketahuilah bahwa operasi DDL, seperti perubahan skema dan migrasi, dapat memblokir atau diblokir oleh beban kerja baca aktif.

  • Selama operasi bahasa definisi data (DDL), Database Engine menggunakan kunci modifikasi skema (Sch-M). Selama waktu dipegang, Sch-M kunci mencegah semua akses bersamaan ke tabel sampai kunci dilepaskan.
  • Selama operasi bahasa manipulasi data (DML), Database Engine menggunakan kunci stabilitas skema (Sch-S). Operasi yang memperoleh kunci Sch-M terhambat oleh kunci Sch-S. Transaksi lain terus berjalan saat kueri sedang dikompilasi, tetapi operasi DDL diblokir hingga mereka bisa mendapatkan akses eksklusif ke skema.
  • Operasi DDL juga memperoleh kunci eksklusif (X) pada baris dalam tampilan sistem seperti sys.tables dan sys.objects terkait dengan tabel target, selama durasi transaksi. Ini memblokir SELECT pernyataan bersamaan pada sys.tables dan sys.objects.

Praktik terbaik untuk menghindari pemblokiran

  • Hindari menjalankan transaksi jangka panjang, atau lakukan selama periode aktivitas rendah atau tanpa aktivitas bersamaan.
  • Jadwalkan operasi DDL hanya selama jendela pemeliharaan untuk meminimalkan pemblokiran.
  • Meskipun pernyataan DDL dapat dijalankan di dalam transaksi pengguna eksplisit (BEGIN TRAN), pernyataan tersebut harus digunakan dengan hati-hati dalam beban kerja bersamaan. Karena perilaku penguncian, DDL dalam transaksi dapat memblokir operasi DML atau SELECT bersamaan pada tabel yang terpengaruh, serta kueri SELECT pada tampilan katalog sistem seperti sys.tables atau sys.objects. Untuk memantau dan memecahkan masalah potensi konflik kunci, gunakan sys.dm_tran_locks.
  • Pantau kunci dan konflik di gudang.

Memahami konflik tulis-tulis di Fabric Data Warehouse

Konflik tulis-tulis dapat terjadi ketika dua transaksi mencoba untuk UPDATE, DELETE, MERGE, atau TRUNCATE tabel yang sama.

Konflik penulisan atau konflik pembaruan dapat terjadi pada level tabel, karena Fabric Data Warehouse menggunakan penguncian tabel. Jika dua transaksi mencoba memodifikasi baris yang berbeda dalam tabel yang sama, transaksi tersebut masih dapat berkonflik.

Konflik tulis-tulis sebagian besar muncul dari dua skenario:

  • Konflik beban kerja yang diinduksi pengguna
    • Beberapa pengguna atau proses secara bersamaan mengubah tabel yang sama.
    • Dapat terjadi dalam alur ETL, pembaruan batch, atau transaksi yang tumpang tindih.
  • Konflik yang diinduksi sistem
    • Tugas sistem latar belakang seperti pemadatan data otomatis menulis ulang file dengan kualitas buruk.
    • Ini dapat bertentangan dengan transaksi pengguna, meskipun pendahuluan pemadatan data secara aktif mencegah konflik tulis-tulis jenis ini.

Jika konflik tulis-tulis terjadi, Anda mungkin melihat pesan kesalahan seperti:

  • Kesalahan 24556: Transaksi isolasi rekam jepret dibatalkan karena konflik pembaruan. Menggunakan isolasi rekam jepret untuk mengakses tabel '%.*ls' secara langsung atau tidak langsung dalam database '%.*ls' dapat menyebabkan konflik pembaruan jika baris dalam tabel tersebut telah dihapus atau diperbarui oleh transaksi bersamaan lainnya. Coba lagi transaksi.
  • Kesalahan 24706: Transaksi isolasi rekam jepret dibatalkan karena konflik pembaruan. Anda tidak dapat menggunakan isolasi rekam jepret untuk mengakses tabel '%.*ls' secara langsung atau tidak langsung dalam database '%.*ls' untuk memperbarui, menghapus, atau menyisipkan baris yang telah dimodifikasi atau dihapus oleh transaksi lain. Silakan coba lagi transaksi.

Jika Anda menemukan pesan kesalahan ini, satu atau beberapa transaksi berhasil, dan satu atau beberapa transaksi yang bertentangan gagal. Coba lagi transaksi yang gagal.

Nota

Bahkan ketika MERGE transaksi hanya mengakibatkan perubahan yang hanya bersifat penambahan, transaksi tetap menciptakan konflik tulis-tulis. Ketika MERGE transaksi memengaruhi baris yang berbeda dari transaksi DML bersamaan lainnya, transaksi dapat mengalami galat berikut jika MERGE bukan transaksi pertama yang di-commit: 'Transaksi isolasi snapshot dibatalkan karena konflik pembaruan.'

Praktik terbaik untuk menghindari konflik tulis-tulis

Untuk menghindari konflik tulis-tulis:

  • Hindari UPDATE, DELETE, MERGE operasi bersamaan pada tabel yang sama.
    • Perhatikan dengan cermat operasi UPDATE, DELETE, dan MERGE dalam transaksi multi-langkah.
  • Gunakan Logika Coba Lagi di semua aplikasi dan kueri.
    • Terapkan logika coba lagi dalam prosedur tersimpan dan alur ETL.
    • Tambahkan logika coba lagi dengan penundaan di dalam pipeline atau aplikasi untuk menangani konflik sementara.
      • Gunakan backoff eksponensial untuk menghindari lonjakan percobaan ulang yang dapat memperburuk gangguan jaringan sementara. Untuk informasi selengkapnya, lihat Pola coba lagi.
  • Konflik tulis-tulis dengan layanan pemadatan data latar belakang Fabric Data Warehouse dimungkinkan tetapi biasanya dicegah oleh fitur Data compaction preemption.

Pemblokiran file tabel dan parkket

Konflik dari dua transaksi bersamaan atau lebih yang memperbarui satu atau beberapa baris dalam tabel dievaluasi di akhir transaksi. Transaksi pertama yang berhasil dikomit selesai dengan sukses, sementara transaksi lainnya digulung balik dan mengembalikan kesalahan. Konflik ini dievaluasi di tingkat tabel dan bukan di tingkat file parquet individual.

Pernyataan INSERT selalu membuat file parquet baru, yang berarti mengurangi konflik dengan transaksi lain kecuali DDL karena skema tabel dapat berubah.

Batasan

  • Transaksi terdistribusi tidak didukung, misalnya, BEGIN DISTRIBUTED TRANSACTION.
  • Titik penyimpanan tidak didukung.
  • Transaksi bernama tidak didukung.
  • Transaksi yang ditandai tidak didukung.
  • Saat ini, ada fungsionalitas T-SQL terbatas di gudang. Lihat cakupan T-SQL di Fabric Data Warehouse untuk daftar perintah T-SQL yang saat ini tidak tersedia.
  • Jika transaksi memiliki penyisipan data ke dalam tabel kosong dan menjalankan perintah SELECT sebelum melakukan rollback, statistik yang dihasilkan secara otomatis masih dapat mencerminkan data yang belum dikomit, menyebabkan statistik yang tidak akurat. Statistik yang tidak akurat dapat menyebabkan rencana kueri dan waktu eksekusi yang tidak optimal. Jika Anda mengembalikan transaksi ke kondisi semula dengan SELECT setelah INSERT besar, perbarui statistik untuk kolom yang disebutkan dalam SELECT Anda.

Konten terkait

  • Last updated on