Reseed otomatis untuk database cermin Fabric dari Azure SQL Managed Instance

Artikel ini membahas reseeding otomatis untuk pencerminan database di Azure SQL Managed Instance.

Dalam kondisi tertentu jika ada keterlambatan pencerminan ke Fabric, peningkatan penggunaan file log transaksi dapat terjadi. Log transaksi tidak dapat dipotong sampai setelah perubahan yang diaplikasikan direplikasi ke database yang dicerminkan. Setelah ukuran log transaksi mencapai batas maksimum yang ditentukan, penulisan ke database gagal.

Untuk melindungi database operasional dari kegagalan penulisan untuk transaksi OLTP penting, pencerminan di Azure SQL Database dan Azure SQL Managed Instance menggunakan kemampuan autoreseed yang memungkinkan log transaksi dapat dipangkas dan mereinisialisasi pencerminan database ke Fabric.

Reseed menghentikan aliran transaksi ke Microsoft Fabric dari database cermin dan menginisialisasi ulang pencerminan pada status saat ini. Reseed melibatkan pembuatan snapshot awal yang baru dari tabel-tabel yang telah dikonfigurasi untuk pencerminan, dan mereplikasikannya ke Microsoft Fabric. Setelah rekam jepret, perubahan bertahap direplikasi.

Di Azure SQL Database dan Azure SQL Managed Instance, reseed dapat terjadi di tingkat database atau di tingkat tabel.

Reseed tingkat basis data: Proses pencerminan data dihentikan untuk semua tabel dalam basis data yang diaktifkan untuk pencerminan, log transaksi dipotong, dan pencerminan diinisialisasi ulang untuk basis data dengan menerbitkan ulang cuplikan awal dari semua tabel yang diaktifkan untuk pencerminan. Kemudian, perubahan bertahap dilanjutkan terus direplikasi.
Menanam ulang tingkat tabel: Pencerminan data yang sedang berlangsung dihentikan hanya untuk tabel yang memerlukan penanaman ulang. Pencerminan diinisialisasi ulang untuk tabel yang terkena dampak dengan menerbitkan ulang rekam jepret awal. Kemudian, perubahan bertahap dilanjutkan terus direplikasi.

Penyebab pengisian ulang otomatis pada tingkat database

Reseed di tingkat database melindungi ketersediaan tulis database dengan memastikan bahwa log transaksi tidak tumbuh hingga ukuran maksimum. Ukuran log transaksi maksimum didasarkan pada Tujuan Tingkat Layanan database dari Azure SQL Database atau Azure SQL Managed Instance. Penggunaan log transaksi untuk basis data yang diaktifkan untuk fabric mirroring dapat terus meningkat sehingga menahan pemotongan log. Setelah ukuran log transaksi mencapai batas maksimum yang ditentukan, penulisan ke database gagal.

Pemotongan log yang dicegah karena pencerminan dapat terjadi karena beberapa alasan:
- Latensi dalam mencerminkan data dari sumber ke database cermin mencegah transaksi yang menunggu replikasi terpotong dari log transaksi.
- Transaksi yang direplikasi yang berjalan lama yang menunggu replikasi tidak dapat dipotong, menahan ruang log transaksi.
- Kesalahan persisten menulis ke zona pendaratan di OneLake dapat mencegah replikasi.
  - Skenario ini dapat disebabkan oleh izin yang tidak mencukupi. Mirroring ke Fabric memakai System Assigned Managed Identity (SAMI) atau User Assigned Managed Identity (UAMI) untuk menulis pada zona pendaratan di One Lake. Jika ini tidak dikonfigurasi dengan benar, replikasi transaksi dapat berulang kali gagal.
    
    Nota
    
    Dukungan untuk User Assigned Managed Identity (UAMI) sedang dalam tahap pratinjau.
Jika kapasitas Fabric dijeda dan dilanjutkan, status database yang dicerminkan tetap Dijeda. Akibatnya, perubahan yang dilakukan di sumber tidak direplikasi ke OneLake. Untuk melanjutkan pencerminan, buka database cermin di portal Fabric, pilih Lanjutkan replikasi. Pencerminan dilanjutkan dari tempatnya dijeda.

Jika kapasitas Fabric tetap dijeda untuk waktu yang lama, replikasi mungkin tidak dilanjutkan dari titik hentinya dan akan mengisi ulang data dari awal. Hal ini disebabkan karena menghentikan proses mirroring untuk waktu yang lama dapat menyebabkan penggunaan log transaksi database sumber meningkat dan menghambat pemangkasan log. Saat pencerminan dalam mode aktif kembali, jika ruang file log transaksi yang digunakan hampir penuh, pengulangan penanaman data pada database akan diinisiasi untuk melepaskan ruang log yang tertahan.

Penyebab penyemaian ulang otomatis pada level tabel

Ketika perubahan skema terjadi pada tabel sumber yang diaktifkan untuk pencerminan, skema untuk tabel cermin tersebut di Fabric tidak lagi cocok dengan sumbernya. Ini bisa terjadi karena pernyataan bahasa definisi data (DDL) T-SQL berikut ALTER TABLE pada sumbernya.

Tambahkan/letakkan/ubah/ganti nama kolom
Potong/ganti nama tabel
Menambahkan kunci primer tidak terkelompok

Reseed hanya dipicu untuk tabel yang terkena dampak.

Diagnosis

Untuk menentukan apakah pencerminan Fabric menghalangi pemotongan log untuk database yang sedang dicerminkan, periksa kolom log_reuse_wait_desc pada tampilan katalog sistem sys.databases untuk melihat apakah alasannya adalah REPLICATION. Untuk informasi selengkapnya tentang jenis tunggu penggunaan kembali log, lihat Faktor-faktor yang menunda pemotongan log transaksi. Contohnya:

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

Jika kueri memperlihatkan REPLICATION jenis penantian penggunaan ulang log, maka karena Fabric mencerminkan log transaksi tidak dapat mengosongkan transaksi yang telah dikomit dan terus terisi. Untuk pemecahan masalah tambahan penggunaan log di Azure SQL Database, lihat Memecahkan masalah kesalahan log transaksi dengan Azure SQL Database.

Gunakan skrip T-SQL berikut untuk memeriksa total ruang log, dan penggunaan log saat ini dan ruang yang tersedia:


USE <Mirrored database name>
GO 
--initialize variables
DECLARE @total_log_size bigint = 0; 
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;

--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
            max_size*1.0*8192/1024/1024 AS [max size in MB],
            growth
FROM sys.database_files
WHERE TYPE = 1 
OPEN sdf 
FETCH NEXT FROM sdf INTO @size,
                @max_size,
                @growth 
WHILE @@FETCH_STATUS = 0 
BEGIN
SELECT @total_log_size = @total_log_size + 
CASE @growth
        WHEN 0 THEN @size
        ELSE @max_size
END 
FETCH NEXT FROM sdf INTO @size,
              @max_size,
              @growth 
END 
CLOSE sdf;
DEALLOCATE sdf;

--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;

-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
       @total_log_size AS [total log space in MB],
       @used_log_size/@total_log_size AS [used log space in percentage];

Selama proses reseed

Selama proses reseed, item database yang tercermin di Microsoft Fabric tetap tersedia tetapi tidak akan menerima perubahan inkremental hingga reseed selesai. Kolom reseed_state dalam sys.sp_help_change_feed_settings menunjukkan status reseed.

Dalam Fabric Mirroring, log transaksi database SQL sumber dipantau. Pemulihan otomatis hanya akan aktif ketika ketiga kondisi berikut benar:

Log transaksi sudah terisi lebih dari @autoreseedthreshold persen; contohnya, 70.
Alasan penggunaan kembali log adalah REPLICATION.
REPLICATION Karena waktu tunggu penggunaan kembali log dapat ditingkatkan untuk fitur lain seperti replikasi transaksional atau CDC, pembuatan ulang otomatis hanya terjadi ketika sys.databases.is_data_lake_replication_enabled = 1. Nilai ini dikonfigurasi oleh Fabric Mirroring.

Periksa apakah pemulihan ulang pada tingkat basis data telah dipicu.

Jika seluruh database sedang di-reseeded, cari kondisi berikut.

Kolom reseed_state dalam prosedur sistem yang tersimpan sys.sp_help_change_feed_settings pada database SQL sumber menandakan status reseed saat ini.
- 0 = Biasa.
- 1 = Database telah memulai proses reinisialisasi ke Fabric. Status transisi.
- 2 = Database sedang diinisialisasi ulang ke Fabric dan menunggu replikasi dimulai ulang. Status transisi. Ketika replikasi ditetapkan, status reseed berpindah ke 0.
Untuk informasi selengkapnya, lihat sys.sp_help_change_feed_settings.
Semua tabel yang diaktifkan untuk pencerminan dalam database akan memiliki nilai 7 untuk state kolom di sys.sp_help_change_feed_table.

Untuk informasi selengkapnya, lihat sys.sp_help_change_feed_table.

Periksa apakah inisialisasi ulang pada level tabel telah dipicu

Untuk tabel apa pun yang sedang diatur ulang, cari nilai 7 dalam kolom state di sys.sp_help_change_feed_table.

Untuk informasi selengkapnya, lihat sys.sp_help_change_feed_table.

Memecahkan masalah database cermin Fabric dari Azure SQL Managed Instance

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-12-02