Ha upgrade-ről van szó, csakis a side-by-side upgrade-et támogatom, azaz az átköltözést egy új verziójú szerverre, szemben az in-place upgrade-del, amikor az ember lefuttatja az upgrade-et az éppen futó szerverére. Miért? Mert üzemeltető vagyok, és szeretem, ha van hova visszatérni probléma esetén. Nem viccből van az oldal tetejére írva az, hogy ROLLBACK. Az üzemeltetésben fontos szempont, hogy legalább rontani ne rontsunk a helyzeten. A fejlesztő megteheti, neki kísérleteznie KELL, ami magában hordja a bukta lehetőségét – az üzemeltető ezt nem teheti meg. És mégis kísérleteznie kell, ezért jó a rollback. Mint minden jófajta stratégiai játékban.

Szóval side-by-side upgrade, vagyis igazából migráció. Ez igen egyszerű dolog esetünkben: tükrözni kell az adatbázist, aztán csak billenteni kell. Meg vinni persze a loginokat meg jobokat. De az már nem nagy szám. A replikáció sem annyira. És ha baj van, csak vissza kell állni a 2005-ös adatbázisra. Tök egyszerű terv, egyetlen apró hibától eltekintve: nem működik. A billenéskor az SQL 2008 megnyitja az adatbázist, és felhozza a saját szintjére. Ez nem a compatibility level, amit lehet állítani, hanem ez bizony egy olyan database version, amit csak tudhatunk, de nem befolyásolhatunk. Az adatbázis belső verziója mindig az adatbázis motorjához passzol, a 611 vagy 612 az SQL 2005-höz, a 655 az SQL 2008-hoz. Ez akadályozza meg például azt, hogy egy SQL 2008-as adatbázis backupot visszaállítsunk SQL 2005-re. A verziószám olyan magas, hogy beint az SQL Server helyből. Ha pedig egy 2005-ös mentést teszünk 2008-ra, akkor rögvest lefut az upgrade, valahogy így:

Processed 121 pages for database ‘Teszt’, file ‘Teszt’ on file 1.
Processed 2 pages for database ‘Teszt’, file ‘Teszt_log’ on file 1.
Converting database ‘Teszt’ from version 611 to the current version 655.
Database ‘Teszt’ running the upgrade step from version 611 to version 621.
Database ‘Teszt’ running the upgrade step from version 621 to version 622.
Database ‘Teszt’ running the upgrade step from version 622 to version 625.
Database ‘Teszt’ running the upgrade step from version 625 to version 626.
Database ‘Teszt’ running the upgrade step from version 626 to version 627.
Database ‘Teszt’ running the upgrade step from version 627 to version 628.
Database ‘Teszt’ running the upgrade step from version 628 to version 629.
Database ‘Teszt’ running the upgrade step from version 629 to version 630.
Database ‘Teszt’ running the upgrade step from version 630 to version 631.
Database ‘Teszt’ running the upgrade step from version 631 to version 632.
Database ‘Teszt’ running the upgrade step from version 632 to version 633.
Database ‘Teszt’ running the upgrade step from version 633 to version 634.
Database ‘Teszt’ running the upgrade step from version 634 to version 635.
Database ‘Teszt’ running the upgrade step from version 635 to version 636.
Database ‘Teszt’ running the upgrade step from version 636 to version 637.
Database ‘Teszt’ running the upgrade step from version 637 to version 638.
Database ‘Teszt’ running the upgrade step from version 638 to version 639.
Database ‘Teszt’ running the upgrade step from version 639 to version 640.
Database ‘Teszt’ running the upgrade step from version 640 to version 641.
Database ‘Teszt’ running the upgrade step from version 641 to version 642.
Database ‘Teszt’ running the upgrade step from version 642 to version 643.
Database ‘Teszt’ running the upgrade step from version 643 to version 644.
Database ‘Teszt’ running the upgrade step from version 644 to version 645.
Database ‘Teszt’ running the upgrade step from version 645 to version 646.
Database ‘Teszt’ running the upgrade step from version 646 to version 647.
Database ‘Teszt’ running the upgrade step from version 647 to version 648.
Database ‘Teszt’ running the upgrade step from version 648 to version 649.
Database ‘Teszt’ running the upgrade step from version 649 to version 650.
Database ‘Teszt’ running the upgrade step from version 650 to version 651.
Database ‘Teszt’ running the upgrade step from version 651 to version 652.
Database ‘Teszt’ running the upgrade step from version 652 to version 653.
Database ‘Teszt’ running the upgrade step from version 653 to version 654.
Database ‘Teszt’ running the upgrade step from version 654 to version 655.
RESTORE DATABASE successfully processed 121 pages in 2.243 seconds (0.497 MB/sec).

És ez az adatbázis már soha nem tud 2005-ön futni. Amikor megbillentjük a mirrort a 2005-2008 felállásban, egy nagyon mókás dolog történik: az addig passzív 2008 aktív lesz, felhozza az adatbázist a 2008-as verzióra, ezt a mirroring átviszi a 2005-ös szerverre, és az innentől kezdve nem tud mit kezdeni az adatbázissal. Ott van, látjuk, de a mirroring eltörött (az utolsó mozdulat az volt, hogy megnőtt az adatbázis verziója, és itt véget ért a történet, gyakorlatilag megvakította magát). Ha megpróbáljuk recoverelni a RESTORE DATABASE Teszt WITH RECOVERY paranccsal, akkor elkezd panaszkodni, hogy ő ezt már nem ismeri. Valami ilyesmit köhög:

Msg 948, Level 20, State 1, Line 1
The database ‘Teszt’ cannot be opened because it is version 655. This server supports version 611 and earlier. A downgrade path is not supported.

Hát ez kellemetlen… Pedig olyan jó ötletnek tűnt… De itt jön az enterprájz-élmény: a database snapshot. Csináljunk egy olyan mentést az adatbázisról, ami hamar kész van, és hamar vissza lehet rá állni, és nincs rá sokáig szükségünk – ez a kívánság database snapshotért kiált. És valóban: a mirror billentése előtt készítünk egy snapshotot a 2005-ös szerveren, a billentés után meg levesszük a (mellesleg törött) tükröt, és már lehet is visszaállni a snapshot által ábrázolt állapotra. Snapshotot persze csak T-SQL-ből lehet csinálni, de onnan egyszerű:

CREATE DATABASE TesztSnapshot ON (NAME = 'Teszt_Data', FILENAME = 'C:\sql\Teszt_Data.SS'), (Name = 'Teszt_Data2', FILENAME = 'C:\sql\Teszt_Data2.SS') AS SNAPSHOT OF Teszt;

Aztán zajlik az élet, a snapshot meg kicsit eleszi a performanciát (azért nem szabad orrba-szájba gyártani), de ilyen esetekben ez teljesen belefér. Ha vissza akarunk állni rá, akkor ezt mondjuk:

RESTORE DATABASE Teszt
FROM DATABASE_SNAPSHOT = 'Tesztsnapshot';

És kész. De miért fér hozzá most a SQL Server a 2008-as adatbázishoz, ha az előbb nem fért? Azért, mert ez egy restore: nem logikailag, objektumszinten, hanem fizikailag, lapszinten nyúl hozzá. A bájtok meg bájtok. Amikorra pedig logikailag kell hozzányúlnia, addigra már megint 2005-ös az adatbázis.

Ez mind jól hangzik, de: én nem szeretem, ha az ember dolgozik a gép helyett, tehát az adatbázis létrehozást is automatizáltam – mivel sorban töltöm fel a szerveket, mindig van egy olyan, amelyikre az új adatbázisok kerülnek. Úgyhogy írtam egy scriptet, amelyik létrehozza a teszt és/vagy éles adatbázist, a hozzá tartozó userrel együtt, akinek beállít egy 20 karakteres random jelszót, és íme: a linuxos kollégáim meg tudják csinálni az új adatbázisokat, nem kell várniuk arra, hogy egy DBA megcsinálja, a DBA-nak meg nem kell izgulnia, hogy mit rontott el a sysadmin :) Ebből már csak egy dolog hiányzik: a karbantartás és a mentés. Úgyhogy nekiálltam automatikusan legyártani az Integration Services csomagokat. Hadd fogalmazzak finoman: az egyik legsötétebb zsákutca volt, ahol valaha jártam. Végül eljutottam oda, hogy valami irgalmatlan nagy gányolással meg lehet oldani, és még így is marad benne némi homály. És ez nekem betett.

Úgyhogy szemléletet váltottam: a Transact-SQL kiválóan alkalmas backupok készítésére, akár időbélyeggel is, és mióta feltalálták a powershellt, a régi backup fájlok törlése sem okoz gondot. A full backup előtt természetesen lefut egy DBCC CHECKDB, ez pont plusz egy sor a T-SQL scriptben, és örülhetek, hogy mindig jó mentést teszek el. Az összes egyé karbantartást is meg lehet oldani T-SQL-lel (sp_updatestats, index javítás/újraépítés), úgyhogy nagyon kicsit sajnálkozva, ugyanakkor örülve az automatizált környezetemnek jelentem: kidobtuk a maintenance planeket. Majd ha lehet egyszerűen generálni őket, visszanézek.

(ja, nemsokára felteszem a scripteket is :))