Sdílet prostřednictvím

Přesunutí úlohy určené pouze pro čtení do sekundární repliky skupiny dostupnosti Always On

platí pro:SQL Server

Aktivní sekundární možnosti skupin dostupnosti AlwaysOn zahrnují podporu přístupu jen pro čtení k jedné nebo více sekundárním replikám (čitelných sekundárních replik). Sekundární replika s možností čtení může být buď v režimu dostupnosti synchronního potvrzení, nebo v režimu dostupnosti asynchronního potvrzení. Sekundární replika s možností čtení umožňuje přístup jen pro čtení ke všem jeho sekundárním databázím. Sekundární databáze s možností čtení ale nejsou nastaveny jen pro čtení. Jsou dynamické. Daná sekundární databáze se změní při změnách odpovídající primární databáze na sekundární databázi. U typické sekundární repliky jsou data, včetně tabulek optimalizovaných pro odolnou paměť, v sekundárních databázích téměř v reálném čase. Kromě toho se fulltextové indexy synchronizují se sekundárními databázemi. V mnoha případech je latence dat mezi primární databází a odpovídající sekundární databází jen pár sekund.

Nastavení zabezpečení, ke kterým dochází v primárních databázích, se uchovávají v sekundárních databázích. To zahrnuje uživatele, databázové role a role aplikací společně s příslušnými oprávněními a transparentním šifrováním dat (TDE), pokud je povoleno v primární databázi.

Poznámka:

I když nemůžete zapisovat data do sekundárních databází, můžete zapisovat do databází pro čtení i zápis v instanci serveru, která je hostitelem sekundární repliky, včetně uživatelských databází a systémových databází, jako je databáze tempdb.

Skupiny dostupnosti Always On také podporují opětovné směrování požadavků na připojení s úmyslem pro čtení do čitelné sekundární repliky (směrování jen pro čtení). Informace o směrování pro čtení najdete v části Použití naslouchacího zařízení pro připojení k sekundární replice Read-Only (směrováníRead-Only).

Výhody

Směrování připojení jen pro čtení na sekundární repliky s možností čtení poskytuje následující výhody:

  • Přenáší sekundární úlohy typu jen pro čtení z primární repliky, čímž šetří její prostředky pro vaše kritické úlohy. Pokud máte kritickou úlohu čtení nebo úlohu, která nemůže tolerovat latenci, měli byste ji spustit na primárním serveru.

  • Zlepšuje návratnost investic do systémů, které hostují čitelné sekundární repliky.

Kromě toho čitelné sekundární soubory poskytují robustní podporu pro operace jen pro čtení, a to následujícím způsobem:

  • Automatické dočasné statistiky pro čitelnou sekundární databázi optimalizují dotazy na čtení na tabulkách založených na disku. U tabulek optimalizovaných pro paměť se chybějící statistiky vytvoří automaticky. Neexistuje však žádná automatická aktualizace zastaralých statistik. Statistiky primární repliky budete muset aktualizovat ručně. Další informace naleznete v tématu Statistika pro Access databáze Read-Only, dále v tomto tématu.

  • Úlohy jen pro čtení pro diskové tabulky používají verzování řádků k odstranění blokace v sekundárních databázích. Všechny dotazy, které běží na sekundárních databázích, se automaticky mapují na úroveň transakce izolace snímků, i když jsou explicitně nastaveny jiné úrovně izolace transakcí. Všechny rady pro uzamykání se také ignorují. Tím se eliminuje kolize čtenáře/zapisovače.

  • Úlohy jen pro čtení pro odolné tabulky optimalizované pro paměť přistupují k datům přesně stejným způsobem, jakým se k datům přistupuje v primární databázi, pomocí nativních uložených procedur nebo interoperability SQL se stejnými omezeními na úrovni izolace transakcí (viz Úrovně izolace v databázovém stroji). Úlohy generování sestav nebo dotazy jen pro čtení spuštěné na primární replice je možné spustit na sekundární replice bez nutnosti jakýchkoli změn. Podobně lze úlohy generování sestav nebo dotazy jen pro čtení spuštěné na sekundární replice spustit na primární replice bez nutnosti jakýchkoli změn. Podobně jako u tabulek založených na disku se všechny dotazy, které běží na sekundárních databázích, automaticky mapují na úroveň transakce izolace snímků, i když jsou explicitně nastaveny jiné úrovně izolace transakcí.

  • Operace DML jsou povolené u proměnných tabulek jak pro typy tabulek optimalizovaných pro disky, tak pro typy tabulek optimalizované pro paměť na sekundární replice.

Požadavky pro skupinu dostupnosti

  • Sekundární repliky s možností čtení (povinné)

    Správce databáze musí nakonfigurovat jednu nebo více replik, aby v roli sekundární povolily všechna připojení (pouze pro přístup pro čtení) nebo pouze připojení záměrně pro čtení.

    Poznámka:

    Volitelně může správce databáze nakonfigurovat jakoukoli repliku dostupnosti tak, aby při spouštění v primární roli vyloučila připojení jen pro čtení.

    Pro více informací viz O přístupu klientů k replikám dostupnosti (SQL Server).

    Výstraha

    Budou čitelné pouze repliky, které jsou ve stejném hlavním buildu SQL Serveru. Další informace najdete v tématu Základy postupného upgradu .

  • Posluchač skupiny dostupnosti

    Aby bylo podporováno směrování pro režim pouze pro čtení, skupina dostupnosti musí mít naslouchací službu skupiny dostupnosti. Klient pouze pro čtení musí směrovat požadavky připojení k tomuto naslouchacímu procesu a připojovací řetězec klienta musí zadat záměr aplikace jako "pouze pro čtení". To znamená, že musí být požadavky na připojení s úmyslem pouze pro čtení.

  • Směrování v režimu pouze pro čtení

    Směrování jen pro čtení odkazuje na schopnost SQL Serveru směrovat příchozí žádosti o připojení záměru čtení, které jsou směřovány k posluchači skupiny dostupnosti, do dostupné sekundární čitelné repliky. Požadavky pro směrování jen pro čtení jsou následující:

    • Aby bylo možné podporovat směrování jen pro čtení, sekundární replika vyžaduje adresu URL směrování jen pro čtení. Tato adresa URL se projeví jenom v případě, že je místní replika spuštěná pod sekundární rolí. Adresa URL směrování jen pro čtení musí být zadána podle potřeby pro jednotlivé repliky. Každá adresa URL pro směrování pouze pro čtení se používá ke směrování žádosti o připojení s úmyslem čtení na konkrétní čitelnou sekundární repliku. Každá čitelná sekundární replika má obvykle přiřazenou adresu URL pro směrování jen pro čtení.

    • Každá replika dostupnosti, která podporuje směrování jen pro čtení, pokud je primární replikou, vyžaduje seznam směrování jen pro čtení. Daný seznam směrování pouze pro čtení se uplatní pouze když je místní replika spuštěná jako primární replika. Tento seznam musí být podle potřeby určen individuálně pro každou replikaci. Každý seznam směrování jen pro čtení obvykle obsahuje každou adresu URL směrování jen pro čtení s adresou URL místní repliky na konci seznamu.

      Poznámka:

      Požadavky na připojení pro účely čtení mohou být vyváženy mezi replikami. Další informace najdete v tématu Konfigurace vyrovnávání zatížení mezi replikami jen pro čtení.

    Další informace najdete v tématu Konfigurace směrování Read-Only pro skupinu dostupnosti (SQL Server).

Poznámka:

Informace o naslouchacích procesech skupiny dostupnosti a další informace o směrování jen pro čtení najdete v tématu Naslouchací procesy skupiny dostupnosti, připojení klienta a převzetí služeb při selhání aplikací (SQL Server).

Limitace a omezení

Některé operace nejsou plně podporovány následujícím způsobem:

  • Jakmile je replika pro čtení povolena, může začít přijímat připojení ke svým sekundárním databázím. Pokud však v primární databázi existují nějaké aktivní transakce, verze řádků nebudou plně dostupné v odpovídající sekundární databázi. Všechny aktivní transakce, které existovaly na primární replice, když byla sekundární replika nakonfigurována, musí potvrdit nebo vrátit zpět. Dokud se tento proces nedokončí, mapování na úrovni izolace transakcí v sekundární databázi není úplné a dotazy jsou dočasně blokované.

    Výstraha

    Spouštění dlouhých transakcí má vliv na počet uchováných řádků verzí, a to jak pro tabulky optimalizované pro disky, tak pro tabulky optimalizované pro paměť.

  • V sekundární databázi s tabulkami optimalizovanými pro paměť, i když jsou verze řádků vždy generovány pro tabulky optimalizované pro paměť, dotazy se zablokují, dokud nebudou všechny aktivní transakce, které existovaly v primární replice, když sekundární replika byla povolena pro čtení dokončena. Tím zajistíte, že tabulky optimalizované pro disky i optimalizovány pro paměť budou k dispozici pro úlohy generování sestav a dotazy jen pro čtení najednou.

  • Sledování změn a zachytávání dat změn nejsou podporovány v sekundárních databázích, které patří do čitelné sekundární repliky:

    • Sledování změn je u sekundárních databází explicitně zakázané.

    • Funkci Change Data Capture nelze povolit pouze v databázi sekundární repliky. Funkci Change Data Capture je možné povolit v primární databázi repliky a změny je možné číst z tabulek CDC pomocí funkcí v sekundární databázi repliky.

  • Vzhledem k tomu, že operace čtení jsou mapovány na úroveň transakce izolace snímků, transakce na jedné nebo více sekundárních replikách mohou blokovat vyčištění neviditelných záznamů na primární replice. Úloha vyčištění záznamu duchů automaticky vyčistí záznamy duchů pro tabulky založené na disku na primární replice, pokud je už žádná sekundární replika nepotřebuje. Podobá se tomu, co se provádí při spuštění transakcí na primární replice. V extrémním případě sekundární databáze budete muset zabít dlouhotrvající dotaz pro čtení, který blokuje čištění duchů. Všimněte si, že stínové čištění může být zablokováno, pokud se sekundární replika odpojí nebo když se přesun dat v sekundární databázi pozastaví. Záznamy Ghost používají fyzické místo v datovém souboru. To může způsobit problémy s opětovným použitím místa. Další informace najdete v tématu čištění duchů . Tento stav také zabraňuje zkrácení protokolu, takže pokud tento stav přetrvává, doporučujeme odebrat tuto sekundární databázi ze skupiny dostupnosti. U tabulek optimalizovaných pro paměť neexistuje žádný problém s vyčištěním záznamu ghost, protože verze řádků se uchovávají v paměti a jsou nezávislé na verzích řádků na primární replice.

  • Operace DBCC SHRINKFILE u souborů, které obsahují tabulky ukládané na disku, může selhat na primární replice, pokud soubor obsahuje nepoužité záznamy, které jsou stále potřeba na sekundární replice.

  • Počínaje SQL Serverem 2014 (12.x) mohou sekundární repliky zůstat online, i když je primární replika offline kvůli akci uživatele nebo selhání. Například synchronizace byla pozastavena kvůli příkazu uživatele nebo selhání, nebo replika řeší stav kvůli tomu, že služba WSFC je offline. Směrování pro čtení však v této situaci nefunguje, protože naslouchací služba skupiny dostupnosti je také offline. Klienti se musí přímo připojit k sekundárním replikám pouze pro čtení pro úlohy s možností pouze čtení.

Poznámka:

Pokud provedete dotaz na dynamický pohled na správu sys.dm_db_index_physical_stats na instanci serveru, která hostí repliku určenou pro čtení, můžete narazit na problém blokující proces REDO. Důvodem je, že tento pohled dynamické správy získá zámek IS na zadané uživatelské tabulce nebo zobrazení, což může blokovat požadavky vlákna REDO na zámek X na této uživatelské tabulce nebo zobrazení.

Důležité informace o výkonu

Tato část popisuje několik aspektů výkonu pro čitelné sekundární databáze.

V této části:

Latence dat

Implementace přístupu jen pro čtení do sekundárních replik je užitečná, pokud vaše úlohy jen pro čtení můžou tolerovat určitou latenci dat. V situacích, kdy je latence dat nepřijatelná, zvažte spouštění úloh jen pro čtení u primární repliky.

Primární replika odesílá záznamy protokolů změn v primární databázi do sekundárních replik. V každé sekundární databázi použije vyhrazené vlákno znovu záznamy protokolu. V sekundární databázi s přístupem pro čtení se daná změna dat nezobrazí ve výsledcích dotazu, dokud se na sekundární databázi nepoužije záznam protokolu obsahující změnu a transakce se potvrdí v primární databázi.

To znamená, že mezi primárními a sekundárními replikami existuje určitá latence, obvykle jen několik sekund. V neobvyklých případech ale může být latence důležitá například v případě, že problémy se sítí snižují propustnost. Latence se zvyšuje, když dojde k kritickým bodům vstupně-výstupních operací a když je přesun dat pozastavený. K monitorování pozastaveného přesunu dat můžete použít Řídicí panel Always On nebo dynamické zobrazení správy sys.dm_hadr_database_replica_states.

Latence dat u databází s tabulkami optimalizovanými pro paměť

V systému SQL Server 2014 (12.x) se vyskytly zvláštní aspekty týkající se latence dat u aktivních sekundárních replik – viz SQL Server 2014 (12.x) Aktivní sekundární repliky: Čitelné sekundární repliky. Počínaje SQL Serverem 2016 (13.x) neexistují žádné zvláštní aspekty týkající se latence dat pro tabulky optimalizované pro paměť. Očekávaná latence dat pro tabulky optimalizované pro paměť je srovnatelná s latencí tabulek založených na disku.

dopad zatížení Read-Only

Když nakonfigurujete sekundární repliku pro přístup jen pro čtení, úlohy jen pro čtení v sekundárních databázích spotřebovávají systémové prostředky, jako jsou procesor a vstupně-výstupní operace (pro diskové tabulky) z vláken opětovného zpracování, zejména pokud úlohy jen pro čtení na diskových tabulkách jsou vysoce náročné na vstupně-výstupní operace. Při přístupu k tabulkám optimalizovaným pro paměť není žádný vliv na vstupně-výstupní operace, protože všechny řádky se nacházejí v paměti.

Úlohy určené pouze pro čtení na sekundárních replikách mohou blokovat změny v jazyce definice dat (DDL), které jsou aplikovány prostřednictvím záznamů protokolu.

  • I když operace čtení nepřebírají sdílené zámky kvůli správě verzí řádků, tyto operace zabírají zámky stability schématu (Sch-S), které můžou blokovat operace opětovného provedení změn DDL. Operace DDL zahrnují ALTER/DROP pro tabulky a zobrazení, ale nikoli DROP nebo ALTER pro uložené procedury. Například, pokud smažete tabulku na disku nebo optimalizovanou pro paměť na primárním serveru. Když vlákno ZNOVU zpracovává záznam protokolu, aby tabulku smazalo, musí získat SCH_M uzamčení na tabulce a může být blokováno běžícím dotazem přistupujícím k tabulce. Toto chování platí pro primární repliku s tím rozdílem, že zrušení tabulky se provádí jako součást relace uživatele, nikoli vlákno REDO.

  • K dispozici jsou další tabulky blokující Memory-Optimized. Pokles nativní uložené procedury může způsobit zablokování vlákna REDO, pokud existuje souběžné spuštění nativní uložené procedury na sekundární replice. Toto chování je stejné u primární repliky, kromě toho, že zrušení uložené procedury se provádí jako součást uživatelské relace, a ne jako součást vlákna REDO.

Mějte na paměti osvědčené postupy týkající se vytváření dotazů a v sekundárních databázích si tyto osvědčené postupy procvičte. Můžete například naplánovat dlouhotrvající dotazy, jako jsou agregace dat v době nízké aktivity.

Poznámka:

Pokud je vlákno redo blokováno dotazy na sekundární repliku, sqlserver.lock_redo_blocked XEvent je vyvolán.

Indexování

Pokud chcete optimalizovat úlohy pouze pro čtení na čitelných sekundárních replikách, možná byste mohli chtít vytvořit indexy v tabulkách sekundárních databází. Vzhledem k tomu, že v sekundárních databázích nemůžete provádět změny schématu nebo dat, vytvořte v primárních databázích indexy a povolte, aby se změny přenášely do sekundární databáze prostřednictvím procesu opětovného provedení.

Pokud chcete monitorovat aktivitu využití indexu na sekundární replice, zadejte dotaz na sloupce user_seeks, user_scans a user_lookups zobrazení dynamické správy sys.dm_db_index_usage_stats .

Statistika pro databáze Read-Only Accessu

Statistiky sloupců tabulek a indexovaných zobrazení slouží k optimalizaci plánů dotazů. U skupin dostupnosti se statistiky vytvořené a udržované v primárních databázích automaticky uchovávají v sekundárních databázích jako součást použití záznamů transakčního protokolu. Úlohy jen pro čtení v sekundárních databázích však mohou potřebovat jiné statistiky než úlohy vytvořené v primárních databázích. Vzhledem k tomu, že sekundární databáze jsou omezené na přístup jen pro čtení, nelze v sekundárních databázích vytvořit statistiky.

Pokud chcete tento problém vyřešit, sekundární replika vytvoří a udržuje dočasné statistiky pro sekundární databáze v databázi tempdb. Přípona _readonly_database_statistic je připojena k názvu dočasných statistik, aby se odlišila od trvalých statistik, které jsou uchovávány z primární databáze.

Pouze SQL Server může vytvářet a aktualizovat dočasné statistiky. Dočasné statistiky ale můžete odstranit a monitorovat jejich vlastnosti pomocí stejných nástrojů, které používáte pro trvalé statistiky:

  • Pomocí příkazu DROP STATISTICS Transact-SQL odstraňte dočasné statistiky.

  • Monitorovat statistiky pomocí sys.stats a sys.stats_columns zobrazení katalogu. sys_stats obsahuje sloupec , is_temporary, který označuje, které statistiky jsou trvalé a které jsou dočasné.

Pro tabulky optimalizované pro paměť na primární nebo sekundární replice není podporována automatická aktualizace statistik. Musíte monitorovat výkon dotazů a plány na sekundární replice a v případě potřeby ručně aktualizovat statistiky primární repliky. Chybějící statistiky se ale automaticky vytvoří na primární i sekundární replice.

Další informace o statistikách SQL Serveru naleznete v tématu Statistika.

V této části:

Zastaralé trvalé statistiky sekundárních databází

SQL Server zjistí, kdy jsou trvalé statistiky sekundární databáze zastaralé. Změny v trvalých statistikách ale nelze provést s výjimkou změn v primární databázi. Pro optimalizaci dotazů SQL Server vytvoří dočasné statistiky pro tabulky založené na disku v sekundární databázi a místo zastaralých trvalých statistik použije tyto statistiky.

Při aktualizaci trvalých statistik v primární databázi se automaticky zachovají do sekundární databáze. Sql Server pak používá aktualizovanou trvalou statistiku, která je aktuálnější než dočasná statistika.

Pokud dojde k přepnutí skupiny dostupnosti, dočasné statistiky se odstraní na všech sekundárních replikách.

Limitace a omezení

  • Protože dočasné statistiky jsou uloženy v databázi tempdb, restartování služby SQL Server způsobí, že všechny dočasné statistiky zmizí.

  • Přípona _readonly_database_statistic je vyhrazena pro statistiky generované SQL Serverem. Tuto příponu nelze použít při vytváření statistik primární databáze. Další informace naleznete v tématu Statistika.

Přístup k tabulkám optimalizovaným pro paměť na sekundární replice

Úrovně izolace transakcí, které lze použít s tabulkami optimalizovanými pro paměť na sekundární replice, jsou stejné jako u primární repliky. Doporučujeme nastavit úroveň izolace relace na READ COMMITTED a možnost na úrovni databáze MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT na ZAPNUTO. Například:

ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON  
GO  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
GO  
SELECT SUM(UnitPrice*OrderQty)   
FROM Sales.SalesOrderDetail_inmem  
GO

Aspekty plánování kapacity

  • V případě tabulek založených na disku můžou sekundární repliky pro čtení vyžadovat místo v databázi tempdb ze dvou důvodů:

    • Úroveň izolace snímku kopíruje verze řádků do tempdb.

    • Dočasné statistiky pro sekundární databáze se vytvářejí a udržují v databázi tempdb. Dočasná statistika může způsobit mírné zvýšení velikosti databáze tempdb. Další informace najdete v části Statistika pro Read-Only Access Databases dále v této části.

  • Když nakonfigurujete přístup pro čtení pro jednu nebo více sekundárních replik, primární databáze přidají 14 bajtů režijních nákladů na odstraněné, upravené nebo vložené datové řádky pro ukládání ukazatelů na verze řádků v sekundárních databázích pro diskové tabulky. Režie o velikosti 14 bajtů se přenáší do sekundárních databází. Vzhledem k tomu, že se do řádků dat přidává režijní náklady na 14 bajtů, může dojít k rozdělení stránek.

    Data verze řádku nejsou generována primárními databázemi. Místo toho sekundární databáze generují verze řádků. Správa verzí řádků ale zvyšuje úložiště dat v primární i sekundární databázi.

    Přidání dat verze řádku závisí na nastavení úrovně izolace snímků nebo izolace snímků potvrzené čtením (RCSI) v primární databázi. Následující tabulka popisuje chování správy verzí u čitelné sekundární databáze v různých nastaveních pro tabulky založené na discích.

    Čitelná sekundární replika? Je povolená izolace snímků nebo úroveň RCSI? Primární databáze Sekundární databáze
    Ne Ne Žádné režijní náklady na řádky nebo 14 bajtů Žádné režijní náklady na řádky nebo 14 bajtů
    Ne Ano Režijní náklady na řádky a režijní náklady na 14 bajtů Žádné verze řádků, ale režijní náklady na 14 bajtů
    Ano Ne Žádné verze řádků, ale režijní náklady na 14 bajtů Režijní náklady na řádky a režijní náklady na 14 bajtů
    Ano Ano Režijní náklady na řádky a režijní náklady na 14 bajtů Režijní náklady na řádky a režijní náklady na 14 bajtů

Související úkoly

Související obsah

Viz také

přehled skupin dostupnosti AlwaysOn (SQL Server)
O přístupu klientského připojení k replikám dostupnosti (SQL Server)
Naslouchací služby Skupiny dostupnosti, Připojení klientů a Přepnutí služeb při selhání aplikací (SQL Server)
Statistika

  • Last updated on