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

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

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

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

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

ในฐานข้อมูล Azure SQL และอินสแตนซ์ที่มีการจัดการของ Azure SQL การ reseed สามารถเกิดขึ้นได้ที่ระดับฐานข้อมูลหรือที่ระดับตาราง

• การเพาะเมล็ดระดับฐานข้อมูลใหม่: การมิเรอร์ข้อมูลอย่างต่อเนื่องจะหยุดลงสําหรับตารางทั้งหมดในฐานข้อมูลที่เปิดใช้งานสําหรับการมิเรอร์ บันทึกธุรกรรมจะถูกตัดทอน และการมิเรอร์จะถูกเตรียมใช้งานใหม่สําหรับฐานข้อมูล โดยการเผยแพร่สแนปช็อตเริ่มต้นของตารางทั้งหมดที่เปิดใช้งานสําหรับการมิเรอร์ จากนั้น การเปลี่ยนแปลงที่เพิ่มขึ้นจะทําซ้ําอย่างต่อเนื่อง

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

สาเหตุของการ reseed อัตโนมัติระดับฐานข้อมูล

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

• การตัดทอนบันทึกที่ป้องกันการละเมิดอาจเกิดขึ้นได้จากหลายสาเหตุ:

  • เวลาแฝงในการมิเรอร์ข้อมูลจากแหล่งที่มาไปยังฐานข้อมูลมิเรอร์จะป้องกันไม่ให้ธุรกรรมที่รอการจําลองแบบถูกตัดทอนจากบันทึกธุรกรรม
  • ธุรกรรมที่จําลองแบบที่ค้างอยู่เป็นเวลานานไม่สามารถตัดทอนได้
  • ข้อผิดพลาดอย่างต่อเนื่องในการเขียนไปยัง Landing Zone ใน OneLake สามารถป้องกันการจําลองแบบได้

    • สถานการณ์นี้อาจเกิดจากสิทธิ์ไม่เพียงพอ การมิเรอร์ไปยัง Fabric ใช้ System Assigned Managed Identity (SAMI) หรือ User Assigned Managed Identity (UAMI) เพื่อเขียนไปยัง Landing Zone ใน One Lake หากไม่ได้กําหนดค่าอย่างถูกต้อง การจําลองแบบธุรกรรมอาจล้มเหลวซ้ําๆ

      Note

      การรองรับข้อมูลประจําตัวที่มีการจัดการที่ผู้ใช้กําหนด (UAMI) อยู่ในการแสดงตัวอย่าง

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

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

สาเหตุของการ reseed อัตโนมัติระดับตาราง

เมื่อการเปลี่ยนแปลง Schema เกิดขึ้นบนตารางต้นทางที่เปิดใช้งานสําหรับการมิเรอร์ Schema สําหรับตารางมิเรอร์เหล่านั้นใน Fabric จะไม่ตรงกับแหล่งที่มาอีกต่อไป ปัญหานี้อาจเกิดขึ้นได้เนื่องจากคําสั่ง T-SQL ของภาษานิยามข้อมูล (DDL) ต่อไปนี้ ALTER TABLE บนแหล่งที่มา:

• เพิ่ม / วาง / เปลี่ยน / เปลี่ยนชื่อคอลัมน์
• ตัดทอน/เปลี่ยนชื่อตาราง
• เพิ่มคีย์หลักที่ไม่ใช่คลัสเตอร์

ระบบจะทริกเกอร์ Reseed สําหรับตารางที่ได้รับผลกระทบเท่านั้น

วินิจฉัย

เมื่อต้องการระบุว่าการมิเรอร์ 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 บันทึกธุรกรรมไม่สามารถล้างธุรกรรมที่ผูกมัดได้ และจะยังคงเติมต่อไป สําหรับการแก้ไขปัญหาเพิ่มเติมของการใช้บันทึกในฐานข้อมูล Azure SQL โปรดดู แก้ไขปัญหาข้อผิดพลาดของบันทึกธุรกรรมด้วยฐานข้อมูล Azure SQL

ใช้สคริปต์ 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];

ระหว่างการเพาะเมล็ดใหม่

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

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

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

ตรวจสอบว่ามีการทริกเกอร์การรีซีทระดับฐานข้อมูลหรือไม่

ถ้าฐานข้อมูลทั้งหมดถูก reseed ให้มองหาเงื่อนไขต่อไปนี้

• 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

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

• สําหรับตารางใดๆ ที่กําลังจะ reseed ให้มองหาค่า of 7 สําหรับ state คอลัมน์ใน sys.sp_help_change_feed_table.

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

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

• แก้ไขปัญหาฐานข้อมูลที่มิเรอร์ Fabric จากฐานข้อมูล Azure SQL