แชร์ผ่าน

กําหนดค่า reseed อัตโนมัติสําหรับฐานข้อมูลมิเรอร์ Fabric จาก SQL Server

บทความนี้ครอบคลุมถึงการ reseeding อัตโนมัติสําหรับการมิเรอร์ฐานข้อมูลจากอินสแตนซ์ SQL Server

มีบางสถานการณ์ที่ความล่าช้าในการสะท้อนไปยัง Fabric อาจนําไปสู่การใช้แฟ้มบันทึกธุรกรรมที่เพิ่มขึ้น นี่เป็นเพราะบันทึกธุรกรรมไม่สามารถถูกตัดทอนได้จนกว่าการเปลี่ยนแปลงที่คอมมิตจะถูกจําลองแบบไปยังฐานข้อมูลที่มิเรอร์ เมื่อขนาดบันทึกธุรกรรมถึงขีดจํากัดสูงสุดที่กําหนดไว้ เมื่อต้องการปกป้องฐานข้อมูลการดําเนินงานจากความล้มเหลวในการเขียนสําหรับธุรกรรม OLTP ที่สําคัญ คุณสามารถตั้งค่ากลไก autoreseed ที่อนุญาตให้บันทึกธุรกรรมถูกตัดทอน และเริ่มต้นการสะท้อนฐานข้อมูลไปยัง Fabric อีกครั้ง

การ reseed หยุดการไหลของธุรกรรมไปยัง Microsoft Fabric จากฐานข้อมูลที่มิเรอร์ และเริ่มต้นการมิเรอร์ใหม่ที่สถานะปัจจุบัน สิ่งนี้เกี่ยวข้องกับการสร้างสแนปช็อตเริ่มต้นใหม่ของตารางที่กําหนดค่าสําหรับการมิเรอร์ และจําลองแบบไปยัง Microsoft Fabric หลังจากสแนปช็อต การเปลี่ยนแปลงที่เพิ่มขึ้นจะถูกทําซ้ํา

ในระหว่างการ reseed รายการฐานข้อมูลที่มิเรอร์ใน Microsoft Fabric จะพร้อมใช้งาน แต่จะไม่ได้รับการเปลี่ยนแปลงที่เพิ่มขึ้นจนกว่าการ reseed จะเสร็จสมบูรณ์ คอลัมน์ใน reseed_state ระบุ sys.sp_help_change_feed_settings สถานะการรีซีด

คุณลักษณะ autoreseed ถูกปิดใช้งานตามค่าเริ่มต้นใน SQL Server 2025 เมื่อต้องการเปิดใช้งาน ให้ดูที่ เปิดใช้งาน autoreseed คุณลักษณะ autoreseed ถูกเปิดใช้งาน และไม่สามารถจัดการหรือปิดใช้งานใน Azure SQL Database และ Azure SQL Managed Instance ได้

ใน Fabric Mirroring แฟ้มบันทึกธุรกรรมฐานข้อมูล SQL ต้นทางจะถูกตรวจสอบ การรีซีดอัตโนมัติจะทริกเกอร์ก็ต่อเมื่อเงื่อนไขสามข้อต่อไปนี้เป็นจริง:

  • บันทึกธุรกรรมเต็มมากกว่า @autoreseedthreshold เปอร์เซ็นต์ เช่น 70. บน SQL Server กําหนดค่านี้เมื่อคุณเปิดใช้งานคุณลักษณะด้วย sys.sp_change_feed_configure_parameters
  • เหตุผลในการนําบันทึกกลับมาใช้ใหม่คือ REPLICATION.
  • เนื่องจากการ REPLICATION รอการนําบันทึกกลับมาใช้ใหม่สามารถเพิ่มขึ้นสําหรับคุณลักษณะอื่นๆ เช่น การจําลองแบบธุรกรรมหรือ CDC การ autoreseed จะเกิดขึ้นเมื่อ sys.databases.is_data_lake_replication_enabled = 1 เท่านั้น ค่านี้ถูกกําหนดค่าโดย Fabric Mirroring

วินิจฉัย

เมื่อต้องการระบุว่าการมิเรอร์ Fabric กําลังป้องกันการตัดทอนบันทึกสําหรับฐานข้อมูลที่มิเรอร์หรือไม่ ให้ตรวจสอบ log_reuse_wait_desc คอลัมน์ใน sys.databases มุมมองแค็ตตาล็อกระบบเพื่อดูว่าเหตุผลคือ REPLICATION. สําหรับข้อมูลเพิ่มเติมเกี่ยวกับชนิดการรอการนําบันทึกกลับมาใช้ใหม่ ให้ดูที่ ปัจจัยที่หน่วงเวลาในการตัดทอนบันทึกธุรกรรม ตัวอย่างเช่น:

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

ถ้าแบบสอบถามแสดงชนิด REPLICATION รอการนําบันทึกกลับมาใช้ใหม่ เนื่องจากการมิเรอร์ Fabric บันทึกธุรกรรมไม่สามารถล้างธุรกรรมที่ผูกมัดได้ และจะยังคงเติมต่อไป

ใช้สคริปต์ T-SQL ต่อไปนี้เพื่อตรวจสอบพื้นที่บันทึกทั้งหมด และการใช้บันทึกปัจจุบันและเนื้อที่ว่าง:


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];

เปิดใช้งาน autoreseed

ถ้าการใช้บันทึกที่ส่งคืนโดยสคริปต์ T-SQL ก่อนหน้านี้ใกล้เคียงกับเต็ม (ตัวอย่างเช่น มากกว่า 70%) ให้พิจารณาการเปิดใช้งานฐานข้อมูลที่มิเรอร์สําหรับการ reseeding อัตโนมัติโดยใช้กระบวนงานที่เก็บไว้ของระบบsys.sp_change_feed_configure_parameters ตัวอย่างเช่น หากต้องการเปิดใช้งานลักษณะการทํางาน autoreseed:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters 
  @autoreseed = 1
, @autoreseedthreshold = 70;

สําหรับข้อมูลเพิ่มเติม โปรดดู sys.sp_change_feed_configure_parameters

ในฐานข้อมูลต้นทาง reseed ควรปล่อยพื้นที่บันทึกธุรกรรมที่เก็บไว้โดยการมิเรอร์ ออกคู่มือ CHECKPOINT บนฐานข้อมูล SQL Server ต้นทางเพื่อบังคับให้ปล่อยพื้นที่บันทึกถ้าเหตุผลที่ระงับยังคงเกิดจาก REPLICATION การสะท้อน สําหรับข้อมูลเพิ่มเติม โปรดดู CHECKPOINT (Transact-SQL)

การเพาะเมล็ดใหม่ด้วยตนเอง

แนวทางปฏิบัติที่ดีที่สุด คุณสามารถทดสอบการ reseed ด้วยตนเองสําหรับฐานข้อมูลเฉพาะโดยใช้กระบวนงานที่เก็บไว้ต่อไปนี้เพื่อทําความเข้าใจผลกระทบก่อนที่จะเปิดฟังก์ชันการ reseed อัตโนมัติ

USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;

สําหรับข้อมูลเพิ่มเติม โปรดดู sys.sp_change_feed_reseed_db_init

ตรวจสอบว่ามีการทริกเกอร์การรีซีดหรือไม่

  • reseed_stateคอลัมน์ในกระบวนงานsys.sp_help_change_feed_settingsที่เก็บไว้ของระบบบนฐานข้อมูล SQL ต้นทางบ่งชี้สถานะ reseed ปัจจุบัน

    • 0 = ปกติ.
    • 1 = ฐานข้อมูลได้เริ่มกระบวนการเริ่มต้นใหม่เป็น Fabric สถานะเปลี่ยนผ่าน
    • 2 = ฐานข้อมูลกําลังถูกเริ่มต้นใหม่เป็น Fabric และรอให้การจําลองแบบรีสตาร์ท สถานะเปลี่ยนผ่าน เมื่อสร้างการจําลองแบบ สถานะ reseed จะย้ายไปที่0

    สําหรับข้อมูลเพิ่มเติม โปรดดู sys.sp_help_change_feed_settings

  • ตารางทั้งหมดที่เปิดใช้งานสําหรับการมิเรอร์ในฐานข้อมูลจะมีค่าของ7stateคอลัมน์ใน sys.sp_help_change_feed_table.

    สําหรับข้อมูลเพิ่มเติม โปรดดู sys.sp_help_change_feed_table

เนื้อหาที่เกี่ยวข้อง

  • Last updated on