Automatyczne ponowne inicjowanie mirrorowanych baz danych Fabric w usłudze Azure SQL Managed Instance

W tym artykule opisano automatyczne ponowne tworzenie kopii danych na potrzeby dublowania bazy danych w usłudze Azure SQL Managed Instance.

W pewnych warunkach, jeśli występuje opóźnienie mieszania do systemu Fabric, zwiększone użycie pliku dziennika transakcji może wystąpić. Dziennik transakcji nie może zostać obcięty do momentu, gdy zatwierdzone zmiany zostaną zreplikowane do dublowanej bazy danych. Gdy rozmiar dziennika transakcji osiągnie maksymalny zdefiniowany limit, zapisy w bazie danych kończą się niepowodzeniem.

Aby zabezpieczyć operacyjne bazy danych przed niepowodzeniami zapisu dla krytycznych transakcji OLTP, mirroring w usłudze Azure SQL Database i Azure SQL Managed Instance korzysta z funkcji autoreseedu, umożliwiającej obcięcie dziennika transakcji i ponowne zainicjowanie mirroringu bazy danych w środowisku Fabric.

Ponowne przełączanie zatrzymuje przepływ transakcji do usługi Microsoft Fabric z dublowanej bazy danych i ponownie inicjuje dublowanie w obecnym stanie. Ponowne inicjowanie obejmuje wygenerowanie nowej początkowej migawki tabel skonfigurowanych do mirroringu i replikowanie ich do usługi Microsoft Fabric. Po wykonaniu migawki replikowane są zmiany przyrostowe.

W usługach Azure SQL Database i Azure SQL Managed Instance, operacja reseed może być przeprowadzana na poziomie bazy danych lub tabeli.

Ponownie ustawiony poziom bazy danych: Ciągłe dublowanie danych jest zatrzymywane dla wszystkich tabel w bazie danych, które są włączone do dublowania, dziennik transakcji jest obcinany, a dublowanie jest ponownie inicjowane dla bazy danych przez ponowne opublikowanie początkowej migawki wszystkich tabel włączonych do dublowania. Następnie zmiany przyrostowe wznawiają ciągłe replikowanie.
Ponownie ustawiony poziom tabeli: Ciągłe dublowanie danych jest zatrzymywane tylko w przypadku tabel, które wymagają ponownego użycia. Dublowanie jest ponownie inicjowane dla dotkniętych tabel przez opublikowanie początkowej migawki ponownie. Następnie zmiany przyrostowe wznawiają ciągłe replikowanie.

Przyczyny automatycznego ponownego zasiewania na poziomie bazy danych

Ponowne inicjowanie na poziomie bazy danych chroni dostępność operacji zapisu, zapewniając, że dziennik transakcji nie zwiększa się do maksymalnego rozmiaru. Maksymalny rozmiar dziennika transakcji jest oparty na Celu poziomu usługi (SLO) dla usługi Azure SQL Database lub Azure SQL Managed Instance. Użycie dziennika transakcji dla bazy danych z włączonym odzwierciedlaniem Fabric może nadal rosnąć i opóźniać przycinanie dziennika. Gdy rozmiar dziennika transakcji osiągnie maksymalny zdefiniowany limit, zapisy w bazie danych kończą się niepowodzeniem.

Uniemożliwiono obcinanie dziennika z powodu dublowania może wystąpić z wielu powodów:
- Opóźnienie w mirroringu danych ze źródła do bazy danych lustrzanej uniemożliwia obcinanie transakcji oczekujących na replikację z dziennika transakcji.
- Długotrwałe transakcje oczekujące na replikację nie mogą być obcięte, zajmując miejsce w dzienniku transakcji.
- Trwałe błędy zapisu w strefie lądowania w usłudze OneLake mogą uniemożliwić replikację.
  - Taka sytuacja może być spowodowana niewystarczającymi uprawnieniami. Odbijanie do struktury Fabric używa tożsamości zarządzanej przypisanej przez system (SAMI) lub przypisanej przez użytkownika (UAMI) do zapisu w strefie docelowej w One Lake. Jeśli ta opcja nie jest prawidłowo skonfigurowana, replikacja transakcji może wielokrotnie wieść się niepowodzeniem.
    
    Uwaga / Notatka
    
    Obsługa tożsamości zarządzanej przypisanej przez użytkownika (UAMI) jest obecnie dostępna w wersji zapoznawczej.
Jeśli przepustowość zostanie wstrzymana i wznowiona, status zreplikowanej bazy danych pozostanie wstrzymany. W rezultacie zmiany wprowadzone w źródle nie są replikowane do usługi OneLake. Aby wznowić dublowanie, przejdź do dublowanej bazy danych w portalu sieci szkieletowej, wybierz pozycję Wznów replikację. Mirroring trwa od miejsca wstrzymania.

Jeśli pojemność Fabricu pozostanie wstrzymana przez długi czas, mirroring może nie zostać wznowiony z punktu zatrzymania i będzie przeprowadzony ponownie od początku. Dzieje się tak dlatego, że wstrzymywanie procesu mirrorowania przez długi czas może spowodować wzrost użycia dziennika transakcji źródłowej bazy danych i zablokować obcinanie dziennika. W przypadku wznowienia dublowania, jeśli używane miejsce w pliku dziennika transakcji jest blisko pełne, nastąpi zainicjowanie ponownego uruchomienia bazy danych w celu zwolnienia przechowywanego miejsca w dzienniku.

Przyczyny automatycznego ponownego inicjowania na poziomie tabeli

Gdy zmiany schematu występują w tabelach źródłowych, które są włączone do mirrorowania, schemat dla tych mirrorowanych tabel w Fabric nie jest już zgodny ze źródłem. Może się to zdarzyć z powodu następujących ALTER TABLE instrukcji języka definicji danych (DDL) T-SQL na źródle.

Dodawanie/usuwanie/zmienianie/zmienianie nazwy kolumny
Obcinanie/zmienianie nazwy tabeli
Dodawanie nieklastrowanego klucza podstawowego

Funkcja Reseed jest wyzwalana tylko dla dotkniętych tabel.

Diagnozuj

Aby ustalić, czy odbicie w Fabric uniemożliwia obcinanie dziennika dla zrcynanej bazy danych, sprawdź kolumnę log_reuse_wait_desc w widoku katalogu systemu sys.databases, aby upewnić się, 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 ponownego użycia dziennika, to ze względu na system Fabric dziennik transakcji nie może opróżnić zatwierdzonych transakcji i będzie nadal się zapełniać. Aby uzyskać dodatkowe informacje na temat rozwiązywania problemów z użyciem dziennika w usłudze Azure SQL Database, zobacz Rozwiązywanie problemów z błędami dziennika transakcji w usłudze Azure SQL Database.

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

Podczas ponownego zasiewania

Podczas ponownego zasiewania element zduplikowanej bazy danych w usłudze Microsoft Fabric jest dostępny, ale nie będzie otrzymywać zmian przyrostowych do momentu ukończenia ponownego zasiewania. Kolumna reseed_state w sys.sp_help_change_feed_settings wskazuje stan zresetowania.

W odwzorowaniu w sieci szkieletowej monitorowany jest dziennik transakcji źródłowej bazy danych SQL. Autoreseed zostanie uruchomione tylko wtedy, gdy spełnione są te trzy warunki:

Dziennik transakcji jest pełny w ponad @autoreseedthreshold procentach, na przykład 70.
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.

Sprawdź, czy zainicjowano zresetowanie na poziomie bazy danych

Jeśli cała baza danych jest ponownie przenoszona, poszukaj następujących warunków.

Kolumna reseed_state w procedurze sys.sp_help_change_feed_settings składowanej systemu w źródłowej bazie danych SQL wskazuje bieżący stan ponownej wersji.
- 0 = Normalny.
- 1 = Baza danych rozpoczęła proces ponownego inicjowania do sieci szkieletowej. Stan przejściowy.
- 2 = Baza danych jest ponownie inicjowana do sieci szkieletowej i oczekuje na ponowne uruchomienie replikacji. Stan przejściowy. Po ustanowieniu replikacji stan reseed jest zmieniany na 0.
Aby uzyskać więcej informacji, zobacz sys.sp_help_change_feed_settings.
Wszystkie tabele włączone do mirroringu w bazie danych będą miały wartość 7 dla kolumny state w sys.sp_help_change_feed_table.

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

Sprawdź, czy wyzwolono ponowne ustawienie na poziomie tabeli

W przypadku każdej tabeli, która jest ponownie przenoszona, poszukaj wartości 7 kolumny state w pliku sys.sp_help_change_feed_table.

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

Rozwiązywanie problemów z lustrzanymi bazami danych usługi Fabric na usłudze Azure SQL Managed Instance

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-12-02