Rollback

A tudásszomjas DBA életében az egyik legnehezebb dolog gyakorlatot szerezni a DBCC CHECKDB által dobott hibák megjavításában. Először is ritkán fordulnak elő, másodszor pedig nincs sok dobása az embernek, amikor előfordul. Játékból meg nehéz sérült adatbázist csinálni, pláne olyat, amiről tudja az ember fia, hogy pontosan mi baja is van.

Persze kis szakismerettel már neki lehet állni, és hexaeditorral belecsapni az adatfájlba, de akkor is maradhatnak homályos részek, pl. akkor most pontosan mit is rontottam el, indexet vagy adatot.

A kényelmes/lusta/mérnöki megoldás pedig az, hogy letöltöd a Paul Randal által nagy gonddal elrontott adatbázis-kollekciót. Ebben többféle, célra rontott adatbázis lakik, van olyan, amin már a CHECKDB sem fut le. SQL 2005-re lettek készítve, mint az Paul cikkéből kiderül…

Aki ott volt a Technet üzemeltetői konferencián vagy letöltötte az internetről valamely darabkáját az előadásomnak, az emlékezhet rá, hogy ajánlottam a maintenance planek használatát mentések készítéséhez. A maintenance planek SQL 2005-ben tulajdonképpen Integration Services csomagok, azok csinálják a mentést, DBCC CHECKDB-t, stb. A wizarddal pikk-pakk össze lehet rakni egyet, és már ülhetünk is nyugodtan a babérjainkon (azért ne felejtsük el beállítani, hogy a jobok elbukása esetén küldjön levelet).

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 :))

Azért szeretek fórumot olvasni, mert mindig tanulok. Vagy vmi hasznosat, vagy azt, hogy nem ezt a fórumot kellene olvasni. Ma délután találkoztam a magyar Technet SQL fórumon egy érdekes kérdéssel:
Miért nem működik a következő script, miért dob a második lépés access denied-ot, mikor explorerből, Total Commanderből megy az átnevezés? Sőt, ha elmásolják és vissza, akkor utána már lehet xp_cmshellel is átnevezni.

exec sp_detach_db 'database'
exec xp_cmdshell 'rename d:\mssql\data\database.mdf database.old.mdf'

Azaz a detach sikerül, utána a cmdshell meg access denied-ot mond. Ez roppantul felkeltette a kíváncsiságomat, és pont volt egy kis időm is, úgyhogy ránéztem a dologra. Kipróbáltam a W2K3-SQL2K8 express asztali gépemen, és pont ezt tapasztaltam. Mivel az express tele van meglepetésekkel, megnéztem a 2K3-SQL2K5 virtuális gépemen is, és dettó. Ezután megnéztem a jogosultságokat az adatbázis fájlokon, ha már access denied a hiba, és azt láttam, hogy az attacsolt fájlokhoz a SQL service-t futtató csoportnak meg az Administrators csoportnak full control joga van, a detacsolt fájlokon meg csak az én saját, nem-adminisztrátor useremnek van full controlja. Ha attacsoltam, visszakerült a SQL service joga is. Szóval kiderült, hogy a DBCC DETACHDB, amit a sp_detach_database hív a lelke mélyén (meg lehet nézni a master adatbázisban a definícióját), kicsit trükkösen kezeli a jogokat. És mivel elvette a SQL userem jogát, az xp_cmdshell elég csúnyán megbukott, mert ugye alapból a SQL user nevében próbálkozik futtatni a parancsokat. Ha bármikor valakinek kételye volna, nagyon egyszerű kideríteni, hogy kinek a nevében futnak a parancsok:

exec xp_cmdshell 'echo %username%'

Ez pont ki fogja írni. Vissza is kaptam a SQL service accountom nevét. Continue reading ‘A detach és az NTFS jogosultság’ »