Konfigurowanie automatycznego ponownego przełączania dla dublowanych baz danych sieci szkieletowej z programu SQL Server

W tym artykule opisano automatyczne ponowne tworzenie kopii danych na potrzeby dublowania bazy danych z wystąpienia programu SQL Server.

W niektórych sytuacjach opóźnienia w replikacji lustrzanej w usłudze Microsoft Fabric mogą prowadzić do zwiększonego użycia pliku dziennika transakcji. Wzrost ten następuje, ponieważ dziennik transakcji nie może zostać obcięty, dopóki zatwierdzone zmiany nie zostaną zreplikowane do lustrzanej bazy danych. Po osiągnięciu maksymalnego zdefiniowanego limitu rozmiaru dziennika transakcyjnego operacje zapisu do bazy danych kończą się niepowodzeniem. Aby zabezpieczyć operacyjne bazy danych przed błędami zapisu dla krytycznych transakcji OLTP, można skonfigurować mechanizm autoreseeding, który umożliwia przycięcie dziennika transakcji i ponowne zainicjowanie mirroringu bazy danych do Fabric.

Reseed zatrzymuje przepływ transakcji do Fabric z lustrzanej bazy danych i ponownie inicjalizuje mirroring w obecnym stanie. Proces ten polega na wygenerowaniu nowej migawki początkowej tabel skonfigurowanych do dublowania oraz zreplikowaniu tej migawki do usługi Fabric. Po wykonaniu migawki replikowane są zmiany przyrostowe.

Podczas ponownego inicjowania element dublowanej bazy danych w usłudze Fabric jest dostępny, ale nie odbiera zmian przyrostowych do czasu zakończenia ponownego inicjowania. Kolumna reseed_state w sys.sp_help_change_feed_settings wskazuje stan zresetowania.

Funkcja automatycznego ponownego obsiewania jest domyślnie wyłączona w SQL Server 2025. Aby ją włączyć, zobacz Włącz autoreseed. W Azure SQL Database i Azure SQL Managed Instance ta funkcja jest włączona i nie można jej zarządzać ani wyłączać.

W odwzorowaniu w sieci szkieletowej monitorowany jest dziennik transakcji źródłowej bazy danych SQL. Autoseed uruchamia się tylko wtedy, gdy spełnione są następujące trzy warunki:

  • Dziennik transakcji jest pełny w ponad @autoreseedthreshold procentach, na przykład 70. Na SQL Server konfiguruj tę wartość podczas włączania funkcji, używając sys.sp_change_feed_configure_parameters.
  • Przyczyną ponownego użycia dziennika jest REPLICATION.
  • Ponieważ oczekiwanie na ponowne użycie dziennika może być spowodowane przez inne funkcje, takie jak replikacja transakcyjna lub CDC, autoreseed występuje tylko wtedy, gdy REPLICATION = 1. Ta wartość jest konfigurowana przez dublowanie sieci szkieletowej.

Diagnose

Aby ustalić, czy mirroring Fabric uniemożliwia obcinanie dziennika transakcji w bazie danych objętej mirroringiem, sprawdź kolumnę log_reuse_wait_desc w widoku katalogowym systemu sys.databases, aby określić, czy przyczyną jest REPLICATION. Aby uzyskać więcej informacji na temat oczekiwania na ponowne użycie dziennika, zobacz Czynniki opóźniające obcinanie dziennika transakcji. Przykład:

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

Jeśli zapytanie pokazuje REPLICATION typ oczekiwania na ponowne użycie logu, to z powodu mirroringu Fabric dziennik transakcji nie może opróżnić zadeklarowanych transakcji i nadal się wypełnia.

Użyj następującego skryptu języka T-SQL, aby sprawdzić łączną ilość miejsca w dzienniku oraz bieżące użycie dziennika i dostępne miejsce:


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

Włącz autoreseed

Jeśli stopień użycia dziennika zwracany przez poprzedni skrypt T-SQL jest bliski zapełnienia (na przykład przekracza 70%), rozważ włączenie bazy danych dublowanej na potrzeby automatycznego ponownego inicjowania przy użyciu systemowej procedury składowanej sys.sp_change_feed_configure_parameters. Na przykład, aby włączyć funkcję automatycznego ponownego rozdzielenia:

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

Aby uzyskać więcej informacji, zobacz sys.sp_change_feed_configure_parameters.

W źródłowej bazie danych proces ponownego inicjowania powinien zwolnić przestrzeń dziennika transakcji zajmowaną przez dublowanie. Jeśli przyczyną opóźnienia nadal jest REPLICATION z powodu dublowania, ręcznie wykonaj CHECKPOINT w źródłowej bazie danych SQL Server, aby wymusić zwolnienie miejsca w dzienniku transakcji. Aby uzyskać więcej informacji, zobacz CHECKPOINT (Transact-SQL).

Ponowne przełączenie ręczne

Zalecamy przetestowanie ręcznego ponownego inicjowania w przypadku określonej bazy danych przy użyciu następującej procedury składowanej, aby zrozumieć jego wpływ przed włączeniem automatycznego ponownego inicjowania.

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

Aby uzyskać więcej informacji, zobacz sys.sp_change_feed_reseed_db_init.

Sprawdź, czy wyzwolono ponowne losowanie

  • Kolumna reseed_state w systemowej procedurze składowanej sys.sp_help_change_feed_settings w źródłowej bazie danych SQL pokazuje bieżący stan ponownego inicjowania.

    • 0 = Normalny.
    • 1 = Baza danych rozpoczęła proces ponownej inicjalizacji do Fabric. Stan przejściowy.
      • 2 = Baza danych jest ponownie inicjalizowana w usłudze Fabric i oczekuje na ponowne uruchomienie replikacji. Stan przejściowy. Po ustanowieniu replikacji stan ponownego inicjowania zmienia się na 0.

    Aby uzyskać więcej informacji, zobacz sys.sp_help_change_feed_settings.

  • Wszystkie tabele z włączonym dublowaniem w bazie danych mają wartość 7 w kolumnie state w sys.sp_help_change_feed_table.

    Aby uzyskać więcej informacji, zobacz sys.sp_help_change_feed_table.

Treści powiązane

  • Last updated on