Obnovte databázi ze záložního souboru jiné verze / vydání

Od vývojáře po podnik bude v pořádku, ujistěte se, že pokud používáte licencování procesoru, máte na cílovém serveru licence, které pokrývají všechny procesory. A nestačí je jen skrýt před SQL, pokud jsou fyzicky připojeni k počítači, jste za ně zodpovědní.

Také při přechodu z nižší sestavy na vyšší sestavení se zvýší verze vaší databáze. Existuje několik scénářů, kde to může být problematické - např. Pokud používáte podporu 15 000 oddílů na konkrétní sestavení z roku 2008, nebude fungovat, když upgradujete na konkrétní sestavení z roku 2008 R2. Také se můžete spolehnout na optimalizace (a mít zástupná řešení), která jsou ve skutečnosti chyby ve starší verzi, ale jsou opraveny v nové verzi, což může vést k horšímu výkonu. Je také důležité zkontrolovat všechny příznaky trasování používané u zdroje a zjistit, zda by měly být také povoleny v cílovém umístění. Nevadí úlohy, přihlášení atd.

Samozřejmě nemůžete jít zpět. Nikdy jsem nezkoušel menší downgrade jako 10.0.5512 -> 10.0.5500, ale rozhodně není možné jít dolů v aktualizaci Service Pack nebo verzi. Pokud tedy máte ve své instanci Developer Edition databázi 2012 a chcete ji umístit na svou instanci v roce 2008, budete mít pro vás připravenou práci (viz zde a zde ) - zejména pokud jste použili funkce pro rok 2012.

Ale na pokrytí dalších případů, které by mohly lidem na tuto otázku přistát (např. Někdo chce jít od vývojáře -> Standard nebo Enterprise -> Express nebo co vás) ...

Existují i ​​další aktualizace vydání -> vydání, které nebudou fungovat tak dobře, např. od vývojáře -> Express, pokud jste použili funkce, které nejsou v Express Express podporovány (a totéž platí pro jakékoli jiné vydání než Enterprise). Několik příkladů funkcí, které nebudete moci použít v edicích nižší úrovně (v takovém případě obnovení zemře v okamžiku, kdy se pokusí uvést databázi online):

• Rozdělení
• Změnit sběr dat
• Komprese dat
• Transparentní šifrování dat

Nevím, jestli existuje způsob, jak to říct přímo ze souboru .BAK (jsem si jistý, že existuje nějaké kouzlo, které lze někde získat ze záhlaví stránky, nebo jestli máte víkend vypálit pomocí hex editoru) , ale zatímco databáze je ve zdrojové instanci stále neporušená, můžete vždy provést následující kroky, abyste zjistili, zda používáte nějaké funkce, které jsou dostupné kvůli SKU, ve které se nacházíte:

SELECT feature_name FROM sys.dm_db_persisted_sku_features;

Nejsem si jistý, zda by měl být na tomto seznamu SQL Server Audit - exkluzivita vydání této funkce se změnila, takže to pravděpodobně závisí na tom, co s tím děláte. Existují další věci, které byste mohli používat, ale nezobrazí se v DMV (některé proto, že jsou ve vašem kódu, který DMV nerozebírá, a některé proto, že vaše databáze spoléhá na externí věci, jako je SQL Server Agent , Service Broker atd.):

• zrcadlení
• určité formy replikace
• log shipping
• snímky databáze
• online indexování
• aktualizovatelná distribuovaná zobrazení rozdělená na oddíly
• záložní komprese
• řízení založené na politikách
• průvodce plánem
• pošta databáze
• plány údržby
• fulltextové vyhledávání

Existují také případy, kdy nebudete moci přejít od vývojáře k Express kvůli omezením velikosti souboru (databáze Express jsou omezeny na 10 GB v celkové velikosti datového souboru).

Samozřejmě mohou existovat i jiné gotchy, na které nebudete varováni - nezabrání migraci, ale mohou vést k velmi odlišnému výkonu v cíli. Příklady:

1. Různá omezení paměti/CPU v cílové edici (nebo dokonce základním operačním systému v cíli). Trochu lidí, kteří šli od roku 2008 R2 Enterprise do roku 2012 Enterprise (CAL), kde je služba uměle omezena na prvních 20 jader). To může vést k přímým rozdílům ve výkonu (například nedostatek paměti k uspokojení dotazu nebo mnohem pomalejší výkon paralelního dotazu); jemnější z nich zahrnují výběr plánu, který se provádí kvůli odlišnému základnímu hardwaru.
2. Spoléhání se na funkce, jako je indexované shody zobrazení ve zdroji, nebude v cíli automaticky respektováno bez změny zdrojového kódu pro použití NOEXPAND. A možná si ani neuvědomujete, že tato schopnost je důvodem, proč se vaše dotazy náhle zpomalí.
3. Totéž platí pro operace s paralelním indexem a pravděpodobně spoustu dalších optimalizací, které si v tuto chvíli nevšimnou (naštěstí pracuji téměř výhradně v prostoru Enterprise, takže se nemusím obávat omezení nižších vydání ve většině případů) ).

[~ # ~] aktualizace [~ # ~] na základě tento duplikát :

Mohou se vyskytnout případy, kdy se pokusíte obnovit databázi z určitého vydání na menší vydání (i ve stejné verzi) a dostanete chyby, které jsou méně užitečné :

OBNOVENÍ se nezdařilo pro server 'server\instance'.
RESTORE nemohl spustit databázi 'databasename'.

To není příliš intuitivní. Pokud se však podíváte hlouběji do protokolů událostí serveru SQL, uvidíte další užitečné chyby (pouze jeden příklad):

Databázi 'databasename' nelze spustit, protože některé funkce databáze nejsou k dispozici v aktuálním vydání serveru SQL.
Databáze 'databasename' nelze v tomto vydání serveru SQL spustit, protože obsahuje funkci oddílu '_dta_pf__9987'. Pouze vydání Enterprise Edition serveru SQL podporuje funkce oddílu.

Teď to není úplně pravda - můžete se také vrátit k Evaluation Edition nebo Developer Edition, ale to je mimo to. Chcete-li obnovit tuto databázi, máte v zásadě dvě možnosti:

1. Obnovení do příslušného vydání serveru SQL - což bude znamenat umístění nebo instalaci nové instance.
2. Obnovte zálohu na zdrojovém serveru jako novou databázi s jiným názvem, odstraňte všechny a všechny funkce Enterprise, znovu zálohujte databázi a obnovte ji v menší verzi. (V tomto konkrétním případě jsem v chybové zprávě nechal název funkce oddílu, protože to stejně vypadá jako věc, kterou lze vyřadit - byl vytvořen poradcem pro optimalizaci databázového stroje a mohl tak učinit někdo, kdo tak docela neučinil vědět, co dělali. To není vždy pravda.)

Varianta na (2) by spočívala pouze v odstranění zdrojového oddílu a dalších funkcí ve zdrojové databázi a provedení další zálohy. Ale pokud se to nerozbije ...