Hálótükrözésű adatbázisok automatikus újraeltetése az Azure SQL Database-ből

Ez a cikk az azure SQL Database-ben lévő adatbázisok tükrözéséhez szükséges automatikus újraküldést ismerteti.

Bizonyos feltételek esetén, ha késik a tükrözés a Fabric rendszerbe, a tranzakciónapló-fájlok megnövekedett kihasználtsága fordulhat elő. A tranzakciónaplót csak a véglegesített módosítások tükrözött adatbázisba való replikálása után lehet csonkolni. Ha a tranzakciónapló mérete eléri a maximálisan meghatározott korlátot, az adatbázisba való írás sikertelen lesz.

Az operatív adatbázisok kritikus OLTP-tranzakciók írási hibáinak védelme érdekében az Azure SQL Database-ben és az Azure SQL Managed Instance-ben való tükrözés az automatikusan létrehozott képességet használja, amely lehetővé teszi a tranzakciónapló csonkolását, és újrainicializálja az adatbázis-tükrözést a Fabricbe.

A reseed leállítja a tranzakciók Microsoft Fabricbe való áramlását a tükrözött adatbázisból, és újraincializálja a tükrözést a jelenlegi állapotban. A reseed magában foglalja a tükrözéshez konfigurált táblák új kezdeti pillanatképének generálását és a Microsoft Fabricbe való replikálását. A pillanatkép után a növekményes módosítások replikálódnak.

Az Azure SQL Database-ben és a felügyelt Azure SQL-példányban a reseed az adatbázis szintjén vagy a tábla szintjén fordulhat elő.

Adatbázisszintű újraeltés: Leáll az adatok folyamatos tükrözése az adatbázis összes olyan táblája esetében, amelyek tükrözésre engedélyezettek, a tranzakciónapló csonkolásra kerül, a tükrözés pedig újrainicializálva van az adatbázisban a tükrözéshez engedélyezett táblák kezdeti pillanatképének újbóli közzétételével. Ezután a növekményes módosítások folyamatosan replikálva folytatódnak.
Táblaszintű újraindítás: Az adatok folyamatos tükrözése csak azokra a táblákra szakad meg, amelyek újraindítást igényelnek. A tükrözés újraindul az érintett táblák esetében a kezdeti pillanatkép újbóli közzétételével. Ezután a növekményes módosítások folyamatosan replikálva folytatódnak.

Adatbázisszintű automatikus újraeltetés okai

Az adatbázis szintjén történő újrainicializálás védi az adatbázis írási elérhetőségét, és meggátolja, hogy a tranzakciónapló elérje a maximális méretet. A tranzakciónapló maximális mérete az Azure SQL Database vagy a felügyelt Azure SQL-példány szolgáltatásszint-célkitűzésén alapul. A Fabric tükrözésre engedélyezett adatbázis tranzakciónapló-használata tovább növekedhet, és akadályozhatja a napló csonkolását. Ha a tranzakciónapló mérete eléri a maximálisan meghatározott korlátot, az adatbázisba való írás sikertelen lesz.

A naplók tükrözés miatti csonkolásának megelőzése több okból is történhet:
- A forrásból a tükrözött adatbázisba történő adattükrözés késése megakadályozza, hogy a replikációra váró tranzakciók csonkolódjanak a tranzakciónaplóból.
- A replikációra váró, hosszú ideig futó replikált tranzakciók nem csonkíthatók, és foglalják a tranzakciónapló területet.
- A OneLake-ben a célzónára írt állandó hibák megakadályozhatják a replikációt.
  - Ezt a forgatókönyvet a nem megfelelő engedélyek okozhatják. A Fabricra történő tükrözés rendszer által hozzárendelt felügyelt identitás (SAMI) vagy felhasználó által hozzárendelt felügyelt identitás (UAMI) használatával ír a One Lake kezdőzónájába. Ha ez nincs megfelelően konfigurálva, a tranzakciók replikálása ismétlődően meghiúsulhat.
    
    Megjegyzés:
    
    A felhasználó által hozzárendelt felügyelt identitás (UAMI) támogatása jelenleg előzetes verzióban érhető el.
Ha a Fabric kapacitás szüneteltetve van, majd újraindul, a tükrözött adatbázis állapota felfüggesztve marad. Ennek eredményeképpen a forrásban végrehajtott módosítások nem lesznek replikálva a OneLake-be. A tükrözés folytatásához nyissa meg a tükrözött adatbázist a Háló portálon, és válassza a Replikáció folytatása lehetőséget. A tükrözés onnan folytatódik, ahol a szüneteltetés történt.

Ha a Szövet kapacitása hosszú ideig szüneteltetve marad, előfordulhat, hogy a tükrözés nem folytatódik a leállítási pontról, és újrakezdődik az adatok újraküldése az elejétől. Azért, mert a tükrözés hosszú ideig történő szüneteltetése miatt a forrásadatbázis tranzakciónaplójának kapacitás használata növekedhet, és akadályozhatja a napló csonkolását. Ha a tükrözés folytatódik, ha a tranzakciónapló fájlterülete majdnem megtelt, a rendszer kezdeményezi az adatbázis újraküldését a tárolt naplóterület felszabadításához.

A táblaszintű automatikus újravetés okai

Ha sémamódosítások történnek a tükrözéshez engedélyezett forrástáblákon, a Hálóban lévő tükrözött táblák sémája már nem egyezik a forrással. Ez a következő ALTER TABLE adatdefiníciós nyelv (DDL) T-SQL-utasítások miatt fordulhat elő a forráson:

Oszlop hozzáadása/elvetése/módosítása/átnevezése
Tábla csonkálása/átnevezése
Nem klaszterezett elsődleges kulcs hozzáadása

A reseed csak az érintett táblák esetében kerül végrehajtásra.

Diagnosztizálás

Annak megállapításához, hogy a Háló tükrözése megakadályozza-e a tükrözött adatbázisok naplók csonkolását, ellenőrizze az log_reuse_wait_desc oszlopot a sys.databases rendszerkatalógus nézetben, és ellenőrizze, hogy ennek oka van-e REPLICATION. A napló újrahasználati várakozási típusairól további információt a tranzakciónapló csonkolását késleltető tényezők című témakörben talál. Például:

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

Ha a lekérdezés a napló újrafelhasználási várakozási típusát jeleníti meg REPLICATION , akkor a Háló tükrözése miatt a tranzakciónapló nem ürítheti ki a véglegesített tranzakciókat, és továbbra is ki lesz töltve. Az Azure SQL Database naplóhasználatának további hibaelhárítását az Azure SQL Database tranzakciónapló-hibáinak elhárítása című témakörben találja.

A következő T-SQL-szkripttel ellenőrizze a teljes naplóterületet, valamint az aktuális naplóhasználatot és a rendelkezésre álló területet:


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

A reseed során

Az újrabemenet során a Tükrözött adatbáziselem elérhető a Microsoft Fabricben, de csak az újraelemmel kapcsolatos növekményes módosításokat kapja meg. A reseed_state benne lévő sys.sp_help_change_feed_settings oszlop a reseed állapotot jelzi.

A Fabric Mirroringben a rendszer figyeli a forrás SQL Database tranzakciónaplót. Az automatikus beírás csak akkor aktiválódik, ha a következő három feltétel teljesül:

A tranzakciónapló például több mint @autoreseedthreshold százalékban megtelt 70.
A napló újrafelhasználásának oka a következő REPLICATION: .
Mivel a REPLICATION napló újrahasználati várakozása más funkciókra, például tranzakciós replikációra vagy CDC-re is beállítható, az automatikus újraküldés csak akkor történik meg, ha sys.databases.is_data_lake_replication_enabled = 1. Ezt az értéket a Hálótükrözés konfigurálja.

Ellenőrizze, hogy egy adatbázisszintű újraindítás aktiválva lett-e

Ha a teljes adatbázis újratöltés alatt áll, figyelje a következő feltételeket.

A reseed_state oszlopa a forrás SQL-adatbázis rendszer-tárolt eljárásában az aktuális újraindítást jelzi.
- 0 = Normál.
- 1 = Az adatbázis megkezdte a Fabricbe való újrainicializálás folyamatát. Átmeneti állapot.
- 2 = Az adatbázis újrainicializálása folyamatban van a Hálóba, és a replikáció újraindítására vár. Átmeneti állapot. A replikáció létrehozásakor az újraelt állapot a gombra 0kerül.
További információ: sys.sp_help_change_feed_settings.
Az adatbázisban tükrözésre engedélyezett összes táblának 7 értéke lesz a state oszlopban sys.sp_help_change_feed_table esetén.

További információ: sys.sp_help_change_feed_table.

Ellenőrizze, hogy egy táblaszintű újraindítás el lett-e indítva

Az újraindított táblák esetében keresse meg 7 oszlopban az state értéket az sys.sp_help_change_feed_table oszlophoz.

További információ: sys.sp_help_change_feed_table.

Hálótükrözésű adatbázisok hibaelhárítása az Azure SQL Database-ből

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-12-02