Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
platí pro:
SQL Server
Chcete-li zachovat řešení pro zotavení po havárii protokolové zásilky, proveďte upgrade nebo aplikujte servisní aktualizace ve správném pořadí. Servisní aktualizace zahrnují aktualizace Service Pack nebo kumulativní aktualizace.
Poznámka:
Upgradovaná konfigurace přesouvání protokolů používá na úrovni serveru backup compression default možnost konfigurace ke kontrole, zda je pro záložní soubory transakčního protokolu použita komprese zálohování. Pro každou konfiguraci přesouvání protokolů můžete určit, jak se budou komprimovat zálohy protokolů. Další informace najdete v tématu Konfigurace přesouvání protokolů (SQL Server).
Předpoklady
Než začnete, projděte si následující důležité informace.
| Článek | Description |
|---|---|
| Podporované aktualizace verzí a edic | Ověřte, že můžete upgradovat na požadovanou verzi SQL Serveru z existujícího operačního systému Windows a verze SQL Serveru. Například nemůžete upgradovat přímo z instance SQL Serveru 2005 (9.x) na SQL Server 2025 (17.x). |
| Zvolit metodu upgradu databázového systému | Vyberte odpovídající metodu upgradu a kroky na základě kontroly podporovaných upgradů verzí a edic. Zvažte také další komponenty nainstalované ve vašem prostředí a upgradujte komponenty ve správném pořadí. |
| Plánování a testování plánu upgradu databázového stroje | Projděte si poznámky k verzi a známé problémy s upgradem, kontrolní seznam před upgradem a vypracujte a otestujte plán upgradu. |
| Požadavky na hardware a software pro instalaci SQL Serveru | Projděte si požadavky na software pro instalaci SQL Serveru. Pokud se vyžaduje jiný software, před zahájením procesu upgradu ho nainstalujte na každý uzel, abyste minimalizovali případné výpadky. |
| Podpora skupiny s omezenou dostupností přidána do SQL Serveru 2022 (16.x) | Pokud chcete začít používat uzavřené skupiny dostupnosti se zasíláním protokolu, musíte odstranit a znovu vytvořit topologii zasílání protokolu. Pokud ale už používáte uzavřené skupiny dostupnosti s přepravou protokolů, upgrady jsou podporovány. |
| Podpora TDS 8.0 přidaná do SQL Serveru 2025 (17.x) | Pokud chcete použít TDS 8.0 s přesouváním protokolů v SQL 2025 a novějších verzích, musíte nejprve odebrat stávající konfiguraci přesouvání protokolů. |
Ochrana dat před upgradem
Pokud chcete chránit svá data během upgradu přepravy protokolu, postupujte následovně:
Proveďte úplnou zálohu databáze pro každou primární databázi.
Další informace najdete v tématu Vytvoření úplného zálohování databáze (SQL Server).
V každé primární databázi spusťte příkaz DBCC CHECKDB .
Důležité
Ujistěte se, že primární server má dostatek místa pro uložení záložních kopií protokolu po dobu trvání upgrade sekundárních serverů/databází. Pokud přepínáte na sekundární server, platí totéž pro sekundární server (nový primární server).
Upgradeovat instanci monitorovacího serveru (volitelně)
Instanci monitorového serveru můžete kdykoli upgradovat. Při upgradu primárního a sekundárního serveru ale nemusíte upgradovat volitelný server monitorování.
Během upgradu serveru monitorování bude konfigurace přenosu protokolů fungovat i nadále, ale její stav není zaznamenán v tabulkách na monitorovacím serveru. Při upgradu serveru monitorování se neaktivují všechny nakonfigurované výstrahy. Po upgradu můžete aktualizovat informace v tabulkách monitorování spuštěním uložené procedury sp_refresh_log_shipping_monitor systému. Další informace o serveru pro monitorování naleznete v tématu O log shipping (SQL Server).
Upgradovat instance sekundárního serveru
Proces upgradu zahrnuje upgrade sekundárních instancí serveru SQL Serveru před upgradem instance primárního serveru. Nejprve vždy upgradujte sekundární instance SYSTÉMU SQL Server. Přesouvání protokolů pokračuje v průběhu procesu upgradu, protože upgradované sekundární instance serveru i nadále obnovují zálohy protokolů z primární instance serveru.
Pokud upgradujete instanci primárního serveru před sekundární instancí serveru, odeslání protokolu selže, protože zálohování vytvořené v novější verzi SQL Serveru nejde obnovit ve starší verzi SQL Serveru. Sekundární instance můžete upgradovat současně nebo sériově, ale před upgradem primární instance je nutné upgradovat všechny sekundární instance, abyste se vyhnuli selhání přesouvání protokolů.
Při upgradu sekundární instance serveru se úlohy odeslání protokolu a obnovení nespustí. Tato podmínka znamená, že se zálohy nerestorovaných transakčních protokolů hromadí na primární replice a potřebujete dostatek místa pro uložení těchto nerestorovaných záloh. Množství akumulace závisí na frekvenci naplánovaného zálohování na instanci primárního serveru a pořadí, ve kterém upgradujete sekundární instance. Pokud je nakonfigurovaný samostatný monitorovací server, mohou být vygenerovány výstrahy, které značí, že obnovení nebyly provedeny po dobu delší, než nakonfigurovaný interval.
Po upgradu sekundárních instancí serveru budou úlohy agentů odesílání protokolů pokračovat a pokračovat ve kopírování a obnovování záloh protokolů z instance primárního serveru do sekundárních instancí serveru. Doba potřebná pro instance sekundárního serveru, aby se sekundární databáze aktualizovala, se liší v závislosti na době potřebné k upgradu sekundární instance serveru a četnosti záloh na primárním serveru.
Během upgradu serveru se sekundární databáze sama neupgraduje na novou verzi. Aktualizuje se jenom v případě, že se přenese do režimu online přepnutím replikované databáze protokolu. Teoreticky by tento stav mohl trvat neomezeně dlouho. Při spuštění přepnutí při selhání je doba nutná pro upgrade metadat databáze malá.
Důležité
Tato RESTORE WITH STANDBY možnost není podporovaná pro databázi, která vyžaduje upgrade. Pokud je upgradovaná sekundární databáze nakonfigurována pomocí RESTORE WITH STANDBY, transakční protokoly již nelze po upgradu obnovit. Pokud chcete pokračovat v přesouvání protokolů v sekundární databázi, musíte na pohotovostním serveru znovu nastavit expedici protokolu. Další informace o STANDBY této možnosti naleznete v tématu Obnovení zálohy transakčního protokolu (SQL Server).
Upgrade instance primárního serveru
Vzhledem k tomu, že přesouvání protokolů je primárně řešením zotavení po havárii, nejjednodušším a nejběžnějším scénářem je místní upgrade primární instance. Během tohoto upgradu není databáze k dispozici. Po upgradu serveru se databáze automaticky vrátí do režimu online, což způsobí, že se upgraduje. Po upgradu databáze se úlohy přesouvání protokolů obnoví.
Odesílání protokolů také podporuje možnost převzít zátěž na sekundární systém pro odesílání protokolů a volitelně vyměnit role mezi primárními a sekundárními servery pro odesílání protokolů.
Vzhledem k tomu, že se přesouvání protokolů už zřídka konfiguruje jako řešení s vysokou dostupností (novější možnosti jsou mnohem robustnější), převzetí služeb při selhání obecně neznamená minimalizaci výpadků. Systémové databázové objekty nejsou synchronizovány a umožnění klientům snadno nalézt a připojit se k povýšené sekundární replice může být náročné.