2011. ápr. 30.

SQL backup visszatöltése korábbi verzióra


Tegnap este az MS SQL szerver egy kellemetlen tulajdonságával szembesült kolléganőm.

Egész napját azzal töltötte, hogy egy több éves vállalati adatbázist az SAP Business One új 8.81-es verziójára átállítsa és egy kicsit gatyába rázzon, mert össze-vissza voltak a cikkszámok és partnerkódok.

A műveletet az egyszerűség miatt a saját gépén, a saját SQL 2008 szerverén végezte. Este felé, amikor elkészült mindennel és gondolta, itt az idő, hogy visszatöltse a produktív szerverre az adatbázist, azzal szembesült, hogy az SQL Management Studio inkompatibilitásra hivatkozva nem hajlandó ezt megtenni. Nem igazán értette a helyzetet, hisz a saját és az ügyfél szerverén is MS SQL 2008 van.

Ezen a ponton léptem be a képbe, majd rövid diskurzus után kiderítettem, hogy 2008 van mindkettőn az igaz, viszont a saját gépén már az újabb R2-es verzió.


Ez a helyzet sajnos nem sok jóval kecsegtetett, amit kolléganőm félig megtört - "Na, akkor már tudom mivel töltöm a hétvégét: kezdem előlről náluk." - mondata is jelzett.

Aki már volt ilyen helyzetben, az tudhatja, hogy egy jó informatikus olyan mint egy bűvész: amikor szembetalálja magát egy problémával, amit első próbálkozással nem tud elhárítani, akkor felkiált: "Nem volt jó ez az ötlet?? Sebaj, van másik!"

Aki ismeri az SQL adatbázis rendszereket, az tudja, hogy az adatok mellett az adatbázisban egyéb más jószágok is vannak: view-k, tárolt eljárások, függvények, stb. Ha nem bírunk egy mentést visszatölteni, akkor a feladatunk az, hogy ezeket az objektumokat és az adatokat átvarázsoljuk valahogy a cél rendszer egy üres adatbázisába.

Egy olyan összetett rendszer, mint amilyen a SAP Business One, rengeteg ilyen objektumot tartalmaz, sőt ezek közül sok titkosított, így gyakorlatilag másolhatatlan. Ezért azt a módszert választottuk, hogy az adatbázis szerkezetét az SAP B1 új vállalat létrehozó funkciójával készítjük el, majd az adattáblákat kiürítjük és szkripttel benyomjuk az adatokat az R2-es adatbázisból.

Első feladat annak az 1200 táblának a teljes kiürítése volt, ami az új adatbázisban megtalálható. Természetesen ezek között a legtöbb üres volt, de hogy melyik nem, azt nagyon nehéz megmondani. Több mint ezer táblát megnyitni és megnézni, hogy van-e benne adat, az legalább 200 perc, ami rengeteg idő.

Sebaj! Írjunk egy szkriptet, ami elkészíti az összes tábla törlő szkriptjét és így fél perc alatt mindent kitörölhetünk. MS SQL esetében ez a script így néz ki:
select 'truncate table ['+name+']' from sysobjects where xtype = 'U'
az eredmény:
truncate table [@BFEXT]
truncate table [@BFEXTDBVERSION]
truncate table [@BOEMAIL]
.
.
truncate table [XRXML]
Az elkészített szkripteket már csak futtatni kell és kész is az üres adatbázis!

Második lépés az adatok kimentése az R2-es adatbázisból. Szerencsére ehhez használható a Management Studio "Generate Scripts..." funkciója, amely megfelelően paraméterezve elkészíti az adatok másolásához szükséges INSERT INTO szkripteket.

Amikor ezzel is megvagyunk, már kezdünk reménykedni benne, hogy a hévégét mégis valami mással tölthetjük. De... de egy újabb problémával kell szembenéznünk: az elkészített szkript 500MB, amit nem tud betölteni a Management Studio. Mit is mond ilyenkor egy jó informatikus?

Sebaj! Biztos van valami parancssori feldolgozó, amivel be lehet tölteni a szkripteket. És tényleg, hisz mi másra szolgálna az SQLCMD.exe?! Megfelelően paraméterezve már el is kezdi a fájl betöltését:
sqlcmd -S server -d database -U user -P pass -i bemeno.sql -o log.txt
Mivel a 30 perces futás alatt még kiderült, hogy milyen felhasználói mezőket felejtettünk el létrehozni az új adatbázisban, néhányszor futtatni kellett a törlő szkripteket is, de 00:50 perckor már megjött a nap végét jelentő hír a kolléganőtől: "Működik!!! Köszi!"

Te kerültél már hasonló kutyarszorítóba, hogy amikor azt gondoltad már csak öt perc és vége az aznapi munkának, akkor egy technikai probléma miatt több órán át kellett még törni a fejed, hogy is old meg a kialakult helyzetet?

Nincsenek megjegyzések:

Megjegyzés küldése