Új adatbázis szerverre váltottunk, ezért szóba jött a compatibility level váltás is. Nem annyira közismert mi ez a fogalom, mi múlik rajta és egyáltalán mi az értelme.
A lényeg az, hogy az adatbázis szerver és az adatbázis verziószáma elválhat egymástól.
Mondjuk ha van egy MSSQL 2014-em és azon létrehoztam egy adatbázist, akkor annak a compatibility levelje ennek megfelelően 120. (Ez az adatbázis szerver verziójából jön.) Ha ezek után ezt az adatbázist backupolom és visszaállítom egy újabb szerveren, akkor a compatibility level nem változik. Tehát akár egy MSSQL 2019-re is feltehetem az adatbázist (restore vagy attach), attól még nem lesz 150-es maga az adatbázis. A szerver vígan kezeli és alapban nem fog gondot okozni. De magát az adatbázist nem konvertáltam ezzel automatikusan 2019-es verzióra, csak az eredetit visszaállítottam egy másik adatbázis szerveren, úgy, ahogy volt.
Ezt az adatbázis Properties paneljének Options részében láthatjátok, de le is kérdezhetitek T-SQL segítségével:
SELECT compatibility_level FROM sys.databases WHERE name = 'adatbazisnev';
Jó, ezt értjük, de ez miért van? És miért kell rá figyelni? A visszafelé kompatibilitás miatt van így és a jövőbeli kompatibilitás miatt kell rá figyelni.
Ha egy újabb verziójú szerverre költözöl és az adatbázist meghagyod az eredeti szinten, akkor elesel az újabb funkciók használatától, de nagyjából ennyi. Lehetnek mondjuk teljesítmény javulások és ritkán teljesítmény romlás is, de általában észrevehetetlen, hogy új MSSQL szerverre költöztél.
Miért kell mégis foglalkozni vele? Mert az adatbázis szerverek nem tartják meg a kompatibilitást a végtelenségig.
Ha előveszek egy MSSQL 2000-es adatbázist valami backupból és fel szeretném tenni az MSSQL 2019-es szerveremre, akkor nem fogom tudni megtenni. A szerver olyasmit fog kiírni, hogy „az adatbázist egy 8.0-ás szerveren készítetted, ami nem kompatibilis a jelenlegi 15.0-ás szervereddel” és csak úgy tudom visszaállítani, hogy felteszek egy 2008-at, mert az még kompatibilis, és ott visszaállítom. Aztán felhúzom az adatbázis szintjét 2008-ra és ezzel tudok tovább dolgozni és menni 2019 felé.
Mondjuk ez a jobb eset, mert az MSSQL szerverek megteszik helyetted, amit csak tudnak. Ez azt jelenti, hogy restore közben átalakítják a régebbi adatbázisokat az általuk ismer minimum szintre és ez gondokat okozhat használat közben. Például ha MSSQL 2017-re (140) próbálunk egy MSSQL 2005-ös (90) adatbázist visszaállítani, akkor nem mondja azt, hogy neki ez túl régi, hanem felhúzza az általa ismert legkisebb (ebben az esetben 100-as) szintre. Tehát nem marad 90-es, de nem is lesz 140-es.
(Megjegyzés: azért ebből látszik, hogy 15 éves adatbázisokat ha nem is közvetlenül, de közvetve még mindig támogatnak. Az sajnálatos, hogy az MSSQL 2000-et már nem támogatják, de egyrészt az már több, mint 20 éves, másrészt egy 2000-es, azóta frissítetlen adatbázis már alapban gyanús kell hogy legyen a legtöbb helyen.)
A váltás egyébként nagyon egyszerű:
- single user mode-ba kell tenni az adatbázist a biztonság kedvéért
- ki kell adni az ALTER DATABASE adatbazisnev SET COMPATIBILITY_LEVEL = 150 (a megfelelő szint)
- multi user mode-ba kell tenni az adatbázist
- az alkalmazás és SQL logokat figyelni egy ideig lehetséges mellékhatások miatt
A szint megváltoztatása azzal jár, hogy az adatbázis megkapja a szintnek megfelelő funkciókat (feature set). Ez lehet összetett: megkapja az új funkciókat, elveszti az általa már nem támogatottakat, és esetleg már régebben használtak átalakulhatnak. Erről az MSDN-en találhattok információkat, mindig az utolsó verzióra kihegyezve.
Ezek lehetnek olyan változások, amik külsőleg nem okoznak igazi változást, mint például hogy a tárolt eljárások újra leszek fordítva. Lehetnek új funkciók, amiket eddig nem is használtunk, hiszen nem léteztek, mint például a Query Store. Aztán lehetnek változások az SQL feldolgozóban, amik kisebb-nagyobb mértékben érintenek, mint például új foglalt kulcsszavak lehetnek vagy egy-egy megszokott módszer már nem teljesen úgy működik.
Ha mindezt nem adatbázis szinten műveljük, hanem az adatbázis szervert upgrade-eljük, akkor a tempdb, model és msdb adatbázisok szintjét megváltoztatja, míg a master adatbázis az eredeti szinten marad, természetesen a fentiek figyelembe vételével.
Teljesítménnyel kapcsolatban általában elmondható, hogy az új szervereknek és az új adatbázis verzióknak jobb a teljesítménye, de ez nem feltétlenül igaz. MSSQL 2014-ben bevezették az új cardinal estimatort, ami gyakorlatilag a query végrehajtását segíti olyan módon, hogy mond egy becslést a végrehajtáshoz, de ha ez a becslés rossz, akkor a teljesítmény romolhat.
Akár manuálisan, szándékosan váltunk szintet az adatbázissal, akár tudjuk, hogy automatikusan váltani fog (mert természetesen teszteltük a visszaállítást is), meg kell tervezni az átállást, át kell nézni az alkalmazást, teljesítmény teszteket kell végezni, hogy esetleg miket kell átírni vagy módosítani az SQL kezelő részeken, hogy rendben lesznek-e és meg kell tenni a megfelelő módosításokat.
