SQL 2005-2008 upgrade, játékosan

Alig használt SQL 2005 szerverünket SQL 2008-ra cseréljük, gariban. Jó az a 2005 Enterprise, az online minden félelmetesen jól működik, de hát az ember vérszemet kap, és akar filtered indexet meg tömörítést meg policy managementet meg mindenféle rettenetet, ha már fizetett érte…

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.

9 Comments

  1. cstibor:

    Szia Erik,

    mi a helyzet SQL 2000 és 2005 upgrade esetén?

    Pont egy ilyen vár rám és ha jól tudom, ha átállunk SQL2005-re és élesben megy a szerver, akkor nincs visszatérési lehetőség a 2000-es verzióra.

    Várom válaszod.
    Kösz
    Tibor

  2. Erik:

    Szia!

    A helyzet gyakorlatilag ugyanez. Pont a downgrade lehetetlensége (meg nem mellesleg a rövidebb szolgáltatáskiesés) miatt a side-by-side upgrade-et javaslom. Itt megmarad a régi adatbázisod, pont úgy, ahogy akkor kinézett, amikor átálltál. Ha vissza kell állnod, akkor az adatokat sajnos kézzel kell visszatolnod, de szerintem ez még elfogadható kompromisszum. Ha nagyon kritikus rendszerről van szó, akkor lehet olyat játszani, hogy replikációval visszatolod az adatokat a régi rendszerbe, de mivel ez elég komplex is lehet, és garantáltan nagyon időigényes (ki kell tesztelni előtte, többször), én a scriptelt megoldást választottam mindig. Szerencsére nem kellett visszaállnom soha :).

    A nehezítés annyi, hogy nincs támogatott adatbázis-mozgatás SQL 2000 és 2005 között. Én anno írtam egy (illetve két) Powershell scriptet, ami tulajdonképpen megcsinálta a log shippinget.

    A legfontosabb a tesztelés a 2000-2005 upgrade-ben. Mi fél évig futtatuk a fejlesztői tesztkörnyezetet 2005-ön, a production tesztet két hónapig, terhelésteszteltük, meg minden. Az egyik rendszert meg simán áttolták, és irgalmatlanul leesett a teljesítménye, mert eléggé megváltozott a lekérdezésfeldolgozás.

    Egy keresztkérdésem van még: miért 2005 és nem 2008? kockázatok szempontjából pont ugyanakkora kaland, viszont van benne pár új cuki dolog.

    Ha valamit nem válaszoltam meg, szólj.
    Erik

  3. cstibor:

    Szia Erik!

    köszönöm a gyors választ.

    Hát a helyzet adott: van egy SQL 2005 Clusterünk, két darab izom, Integrity processzoros vassal és erre szeretnénk átköltöztetni az ominózus SQL 2000 szervert, ami x86-os gyengébb szerveren fut.

    Most éppen a tesztelés fázisában vagyunk, és bármilyen fura, jó pár dologba bele kellett nyúlni a fejlesztőknek, mert sokkal lassabban futottak SQL 2005-ön, mint a jóval gyengébb vason, SQL 2000-es környezetben.

    Igazából, mi úgy próbáljuk megoldani a helyzetet, hogy addig nem állunk át élesben, addig tesztelünk, amíg minden tökéletes nem lesz. (Egy elég kritikus rendszerről van szó)

    Azért kíváncsi lennék a Te scripted-re, legalább példa szinten, örülnék ha közkinccsé tennéd, lehet másoknak is hasznos lenne :))

    Előre is köszönöm (a nép nevében)
    Üdv.:
    Tibor

  4. Erik:

    Mivel úgy olvasom ki leveledből, hogy a dolog nem extra égetően sürgős, jövő hétre (március elejére) ígérném a scriptet, mivel most még Seattle-ben csövezek, és elég sok mindent kell csinálnom, amíg itt vagyok. Ha nem jelenik meg a script az oldalon március első hetében, akkor dobjál ide még egy postot, én majd restellem magam.

  5. cstibor:

    Köszi, addig is jó “csövezést”

    Üdv.:
    Tibor

  6. cstibor:

    Szia Erik, közben sikeresen átálltunk, de script nem jelent meg az oldalon.

  7. cstibor:

    Szia Erik,

    köszönöm a script-et, ígérem ki fogom próbálni, bár úgynéz ki félre értettük egymást, mert nekem a fordított irányra lett volna szükségem, szóval ha átálltunk SQL2005-re és éles üzem közben valami gáz lesz, akkor mi legyen a rollback?

    Az én esetemben ráadásul az átállás során sok tárolt eljárásba, függvénybe belenyúltak a programozók, hogy SQL 2005-ön gyorsan fusson az alkalmazás.

    Szóval tényleg csak az adatokat kellett volna visszatolni 2005-ről 2000-re. (szerencsére nem kellett)

    Egyébként teszt környezetben kipróbáltam ehhez az SQL replikációt, és szépen működött az adatok mozgatása a 2005-ös szerverről, a 2000-re.

    Üdv.:
    Tibor

  8. Robi:

    Szia Erik,

    Kipróbáltam az általad leírt módszert.
    sql 2005-ön mirror felállítása principalként, mirror sql 2008 r2-re. Billentés előtt snapshot.
    Billentés után az sql 2008 r2-en feláll az adatbázis rendesen, Majd leszedem a mirrort. Így sql 2005-nél restoring állapotba kerül a db.
    Próbáltam visszahozni a snapshot alapján de a következő hibaüzenetet kapom:
    Msg 911, Level 16, State 4, Line 1
    Could not locate entry in sysdatabases for database ‘g:\backups\AdventureWorks.ss’. No entry found with that name. Make sure that the name is entered correctly.
    Msg 3013, Level 16, State 1, Line 1
    RESTORE DATABASE is terminating abnormally.

    Hol ronthattam el?

    Robi

  9. Robi:

    Szia Erik,

    Bocsi az előbbiért, én vagyok a láma. Benéztem a parancsot.

    Robi

Leave a comment