Konfigurujte distribuované transakce pro skupinu dostupnosti Always On

platí pro:SQL Server

SQL Server 2017 (14.x) a pozdější verze podporují všechny distribuované transakce včetně databází ve skupině dostupnosti. Tento článek vysvětluje, jak nastavit skupinu dostupnosti pro distribuované transakce

Aby byla zajištěna distribuovaná transakce, musí být skupina dostupnosti nakonfigurována tak, aby registrovala databáze jako správce distribuovaných transakčních zdrojů.

Note

SQL Server 2016 (13.x) Service Pack 2 a pozdější verze poskytují plnou podporu distribuovaných transakcí ve skupinách dostupnosti. V SQL Server 2016 (13.x) Service Pack 1 a starších verzích nejsou podporovany transakce napříč databázemi (tedy transakce využívající databáze na stejném SQL Server instance) zahrnující databázi ve skupině dostupnosti. SQL Server 2017 (14.x) toto omezení nemá.

V SQL Server 2016 (13.x) jsou konfigurační kroky stejné jako v SQL Server 2017 (14.x).

Při distribuované transakci klientské aplikace spolupracují s služba MS DTC (Microsoft Distributed Transaction Coordinator) (MSDTC nebo DTC), aby zajistily transakční konzistenci napříč více datovými zdroji. DTC je služba dostupná na podporovaných operačních systémech založených na Windows Server. Pro distribuovanou transakci je DTC koordinátorem transakcí. Obvykle je instance SQL Server správcem zdrojů. Když je databáze ve skupině dostupnosti, každá databáze musí být vlastním správcem zdrojů.

SQL Server nebrání distribuovaným transakcím pro databáze ve skupině dostupnosti – ani když skupina dostupnosti není nakonfigurována pro distribuované transakce. Pokud však skupina dostupnosti není nakonfigurována pro distribuované transakce, failover nemusí v některých situacích uspět. Konkrétně nová primární replika SQL Server instance nemusí být schopna získat výsledek transakce z DTC. Aby instance SQL Server mohla po failoveru získat výsledky indoubt transakcí z DTC, nakonfigurujte skupinu dostupnosti pro distribuované transakce.

DTC se nepodílí na zpracování skupin dostupnosti, pokud databáze není zároveň členem failover clusteru. V rámci skupiny dostupnosti je konzistence mezi replikami udržována logikou skupiny dostupnosti: primární replika nedokončí potvrzení transakce ani je nepotvrdí volajícímu, dokud sekundární replika nepotvrdí, že záznamy protokolu byly trvale uloženy do úložiště. Teprve poté primární prohlásí transakci za dokončenou. V asynchronním režimu nečekáme, až sekundární modul akuje, a je zde explicitní riziko ztráty malého množství dat.

Prerequisites

Než nakonfigurujete skupinu dostupnosti pro podporu distribuovaných transakcí, musíte splnit následující předpoklady:

  • Všechny instance SQL Server, které se účastní distribuované transakce, musí být verze SQL Server 2016 (13.x) nebo novější.

  • Skupiny dostupnosti musí běžet na Windows Server 2012 R2 nebo novějších verzích. Pro Windows Server 2012 R2 je nutné nainstalovat aktualizaci z KB3090973.

Vytvořte skupinu dostupnosti pro distribuované transakce

Nakonfigurujte skupinu dostupnosti pro podporu distribuovaných transakcí. Nastavte skupinu dostupnosti tak, aby každá databáze mohla být registrována jako správce zdrojů. Tento článek vysvětluje, jak nastavit skupinu dostupnosti tak, aby každá databáze mohla být správcem zdrojů v DTC.

Můžete vytvořit skupinu dostupnosti pro distribuované transakce na SQL Server 2016 (13.x) nebo novějších verzích. Pro vytvoření skupiny dostupnosti pro distribuované transakce zahrňte DTC_SUPPORT = PER_DB do definice skupiny dostupnosti. Následující skript vytváří skupinu dostupnosti pro distribuované transakce.

CREATE AVAILABILITY
GROUP MyAG
WITH (DTC_SUPPORT = PER_DB)
FOR DATABASE DB1,
    DB2 REPLICA
ON 'Server1' WITH (
   ENDPOINT_URL = 'TCP://SERVER1.corp.com:5022',
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
   FAILOVER_MODE = AUTOMATIC
),
'Server2' WITH (
   ENDPOINT_URL = 'TCP://SERVER2.corp.com:5022',
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
   FAILOVER_MODE = AUTOMATIC
);

Note

Předchozí skript je jednoduchým příkladem skupiny dostupnosti a není navržen pro žádné konkrétní produkční prostředí.

Upravte skupinu dostupnosti pro distribuované transakce

Skupinu dostupnosti pro distribuované transakce můžete upravit na SQL Server 2017 (14.x) nebo novějších verzích. Pro změnu skupiny dostupnosti pro distribuované transakce zahrňte DTC_SUPPORT = PER_DB do skriptu ALTER AVAILABILITY GROUP . Ukázkový skript mění skupinu dostupnosti tak, aby podporovala distribuované transakce.

ALTER AVAILABILITY GROUP MyaAG
SET (DTC_SUPPORT = PER_DB);

Note

V SQL Server 2016 (13.x) Service Pack 2 a novějších verzích můžete změnit skupinu dostupnosti pro distribuované transakce. U verzí SQL Server 2016 (13.x) před Service Pack 2 je potřeba skupinu dostupnosti vyřadit a znovu vytvořit s tímto DTC_SUPPORT = PER_DB nastavením.

Pro deaktivaci distribuovaných transakcí použijte následující příkaz Transact-SQL:

ALTER AVAILABILITY GROUP MyaAG
SET (DTC_SUPPORT = NONE);

Distribuované transakce – technické koncepty

Distribuovaná transakce zahrnuje dvě nebo více databází. Jako správce transakcí DTC koordinuje transakce mezi instancemi SQL Server a dalšími zdroji dat. Každá instance databázového enginu SQL Server může fungovat jako správce zdrojů. Když je skupina dostupnosti nakonfigurována s , DTC_SUPPORT = PER_DBmohou databáze fungovat jako správci zdrojů. Pro více informací viz dokumentaci MSDTC.

Transakce se dvěma nebo více databázemi v jedné instanci databázového enginu je ve skutečnosti distribuovaná transakce. Instance spravuje distribuovanou transakci interně; uživateli funguje jako místní transakce. SQL Server 2017 (14.x) povyšuje všechny transakce mezi databázemi na transakce DTC, pokud jsou databáze ve skupině dostupnosti nakonfigurované pomocí DTC_SUPPORT = PER_DB, a to i v rámci jediné instance SQL Serveru.

V aplikaci je distribuovaná transakce spravována podobně jako lokální transakce. Na konci transakce aplikace požaduje, aby transakce byla potvrzena nebo vrácena zpět. Správce transakcí musí distribuované potvrzení řídit jinak, aby minimalizoval riziko, že selhání sítě povede k tomu, že někteří správci zdrojů transakci úspěšně potvrdí, zatímco jiní ji vrátí zpět. Toho se dosahuje správou procesu potvrzení ve dvou fázích (fáze přípravy a fáze potvrzení), která se označuje jako dvoufázové potvrzení.

  • Fáze přípravy

    Když správce transakcí obdrží žádost o potvrzení, odešle příkaz prepare všem správcům prostředků zapojeným do transakce. Každý správce zdrojů pak udělá vše potřebné pro trvalost transakce a všechny buffery obsahující logové obrazy transakce jsou vymazány na disk. Jak každý správce zdrojů dokončí fázi přípravy, vrací manažerovi transakcí úspěch nebo neúspěch fáze přípravy.

  • Fáze potvrzení

    Pokud správce transakcí obdrží úspěšné přípravy od všech správců prostředků, odešle příkazy potvrzení každému správci prostředků. Správci prostředků pak můžou potvrzení dokončit. Pokud všichni správci prostředků nahlásí úspěšné potvrzení, správce transakcí odešle do aplikace oznámení o úspěchu. Pokud některý správce prostředků nahlásil selhání přípravy, správce transakcí odešle každému správci prostředků příkaz vrácení zpět a indikuje selhání potvrzení do aplikace.

Podrobné kroky

Následující seznam vysvětluje, jak aplikace spolupracuje s DTC při dokončení distribuovaných transakcí.

  1. Instance serveru SQL Server se účastní transakce DTC. To se může stát, když je v transakci více než jeden správce zdrojů nebo pokud klient požádá o povýšení transakce na DTC transakci.
  2. Klient vykonává nějakou práci v instanci SQL Server v rámci DTC transakce.
  3. Klient provede commit nebo abort transakce DTC.
    • Pokud klient vydá přerušení, transakce je okamžitě přerušena.
    • Pokud klient vydá commit, DTC zahájí protokol dvoufázového commitu tím, že požádá všechny správce zdrojů v transakci, aby transakci připravili.
  4. DTC informuje všechny správce zdrojů, aby transakci potvrdili poté, co všichni správci úspěšně potvrdí fázi přípravy. Pokud něco brání úspěšnému potvrzení, DTC transakci zruší.

Dopady konfigurace skupiny dostupnosti pro distribuované transakce

Každá entita účastní se distribuované transakce se nazývá správce zdrojů. Příklady správců zdrojů zahrnují:

  • Instance serveru SQL Server.
  • Databáze ve skupině dostupnosti, která je nakonfigurována pro distribuované transakce.
  • DTC služba – může být také správcem transakcí.
  • Další zdroje dat.

Pro účast na distribuovaných transakcích se instance SQL Server přihlásí do DTC. Instance SQL Serveru se obvykle zaregistruje u DTC na místním serveru. Každá instance SQL Server vytváří správce zdrojů s unikátním identifikátorem správce zdrojů (RMID) a registruje jej v DTC. Ve výchozím nastavení používají všechny databáze na instanci SQL Server stejný RMID.

Když je databáze ve skupině dostupnosti, kopie databáze pro čtení a zápis – nebo primární replika – může být přesunuta do jiné instance SQL Server. Pro podporu distribuovaných transakcí během tohoto pohybu by každá databáze měla fungovat jako samostatný správce zdrojů a mít jedinečný RMID. Když skupina dostupnosti obsahuje DTC_SUPPORT = PER_DB, SQL Server vytvoří správce prostředků pro každou databázi a zaregistruje se u DTC pomocí jedinečného RMID. V této konfiguraci je databáze správcem zdrojů pro DTC transakce.

Important

DTC má limit 32 zápisů na distribuovanou transakci. Protože každá databáze v rámci skupiny dostupnosti se zapisuje do DTC zvlášť, pokud vaše transakce zahrnuje více než 32 databází, můžete při pokusu SQL Server o zařazení 33. databáze dostat následující chybu:

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server couldn't register with Microsoft Distributed Transaction Coordinator (MSDTC) as a resource manager for this transaction. The transaction might have been stopped by the client or the resource manager.

Další podrobnosti o distribuovaných transakcích na SQL Serveru najdete v tématu Distribuované transakce

Spravujte nevyřešené transakce

Výsledek aktivních transakcí, které existují během změny RMID, nelze obnovit po failoveru. Je to proto, že server RMID SQL Server použitý pro registraci a server RMID SQL Server použitý pro obnovení jsou odlišné. Změna RMID může nastat v následujících případech:

  • Změňte DTC_SUPPORT pro skupinu dostupnosti.
  • Přidejte nebo odeberte databázi ze skupiny dostupnosti.
  • Zrušte skupinu dostupnosti.

V předchozích případech, pokud primární replika selže na novou instanci SQL Server, instance se pokusí kontaktovat DTC a zjistit výsledek transakce. DTC nemůže vrátit výsledek, protože RMID, které databáze používá k získání výsledků u nejistých transakcí během obnovy, nebylo dříve uvedeno. Databáze proto přechází do stavu SUSPECT.

Nový chybový log SQL Server obsahuje záznam podobný následujícímu příkladu:

Microsoft Distributed Transaction Coordinator (MSDTC)
failed to reenlist citing that the database RMID does
not match the RMID [xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]
associated with the transaction.  Please manually resolve
the transaction.

SQL Server detected a DTC/KTM in-doubt transaction with UOW
{yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy}.Please resolve it
following the guideline for Troubleshooting DTC Transactions.

Předchozí příklad ukazuje, že DTC nemohla znovu zaregistrovat databázi z nové primární repliky v transakci vytvořené po failoveru. Instance SQL Server nemůže určit výsledek distribuované transakce, takže označí databázi jako podezřelou. Transakce je označena jako jednotka práce (UOW) a identifikována pomocí identifikátoru GUID. Chcete-li obnovit databázi, ručně transakci buď potvrďte, nebo vraťte zpět.

Warning

Když transakci manuálně potvrzujete nebo vrátíte zpět, může to ovlivnit aplikaci. Ověřte, že akt commit nebo rollback odpovídá požadavkům vaší aplikace.

Spusť pouze jeden z následujících skriptů:

  • Pro potvrzení transakce aktualizujte a spusťte následující skript – nahraďte yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy identifikátorem UOW nevyřešené transakce z předchozí chybové zprávy a poté spusťte:

    KILL 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' WITH COMMIT;

  • Chcete-li vrátit transakci zpět, aktualizujte a spusťte následující skript – nahraďte yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy UOW nejednoznačné transakce z předchozí chybové zprávy a spusťte:

    KILL 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' WITH ROLLBACK;

Po potvrzení nebo vrácení transakce můžete použít ALTER DATABASE k nastavení databáze online. Aktualizujte a spusť následující skript – nastavte název databáze pro název podezřelé databáze:

ALTER DATABASE [DB1] SET ONLINE;

Pro více informací o řešení pochybných transakcí viz Vyřešit transakce ručně.

Související obsah

  • Last updated on