Reseed otomatis untuk database cermin Fabric dari Azure SQL Database

Artikel ini membahas reseeding otomatis untuk penggandaan basis data di Azure SQL Database.

Dalam kondisi tertentu, jika ada penundaan dalam replikasi ke Fabric, penggunaan file log transaksi yang meningkat dapat terjadi. Log transaksi tidak dapat dipangkas hingga setelah perubahan yang dikomitmenkan direplikasi ke basis data cermin. 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. Penanaman ulang melibatkan pembuatan cuplikan awal baru dari tabel yang disusun untuk pencerminan, dan kemudian mereplikasi cuplikan tersebut 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.

Menanam ulang tingkat database: Pencerminan data yang sedang berlangsung dihentikan untuk semua tabel dalam database yang diaktifkan untuk pencerminan, log transaksi dipangkas, dan pencerminan diinisialisasi ulang untuk database dengan memublikasikan ulang cuplikan awal semua tabel yang diaktifkan untuk pencerminan. Kemudian, perubahan bertahap akan dilanjutkan mereplikasi secara terus-menerus.
Penanaman ulang tingkat tabel: Pencerminan data yang 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 akan dilanjutkan mereplikasi secara terus-menerus.

Penyebab reseed otomatis pada tingkat basis data

Reseed di tingkat database melindungi ketersediaan penulisan database dengan memastikan bahwa log transaksi tidak tumbuh hingga ukuran maksimum yang diperbolehkan. Ukuran log transaksi maksimum didasarkan pada Tujuan Tingkat Layanan database dari Azure SQL Database atau Azure SQL Managed Instance. Penggunaan log transaksi untuk database yang diaktifkan dengan pencerminan Fabric dapat terus meningkat dan menghambat pemangkasan 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 pencerminan data dari sumber ke database cermin mencegah transaksi yang tertunda replikasinya untuk dipangkas dari catatan transaksi.
- Transaksi yang direplikasi yang berjalan lama dan tertunda untuk replikasi tidak dapat dipotong, menghabiskan 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 cermin 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, proses mirroring mungkin tidak dilanjutkan dari titik hentinya dan akan memulai 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 dilanjutkan, jika ruang file log transaksi yang digunakan hampir penuh, pengaturan ulang database akan dimulai untuk membebaskan ruang log yang terblokir.

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 T-SQL bahasa definisi data (DDL) berikut ALTER TABLE pada sumbernya:

Tambahkan/letakkan/ubah/ganti nama kolom
Potong/ganti nama tabel
Tambahkan kunci primer non-kluster

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 penyetelan ulang tingkat database telah dipicu

Jika seluruh database sedang diisi ulang, cari kondisi berikut.

Kolom reseed_state dalam prosedur sys.sp_help_change_feed_settings tersimpan sistem pada database SQL sumber menunjukkan 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 pengulangan penomoran ulang tingkat tabel telah dipicu

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

Untuk informasi selengkapnya, lihat sys.sp_help_change_feed_table.

Memecahkan masalah basis data mirror Fabric dari Azure SQL Database

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-12-02