Mit tegyünk a korrupt adatbázisokkal?

Nemrégiben volt szerencsém felfrissíteni DR, vagyis disaster recovery (=füstölgő romokból hozz ki valamit) emlékeimet. Egy kb 50GB-os adatbázisunk összehalta magát. Már írt pár hibát a logba, hogy nem tud olvasni egy page-et, aztán emiatt a backupok sem sikerültek, úgyhogy jött a szerver restart. A szerver pedig aszonta, hogy az adatbázisunk suspect módba került. Ez azt jelenti, hogy nem lehet belépni se, megnézni se, semmise. Mit lehet tenni ilyenkor?

Az első tennivaló, hogy az összes létező tamtamot elkezdjük verni, és lepereg előttünk életünk filmje. Mert ha ez az egy adatbázis megsérült, megsérülhet más is – akár hardver, akár szoftver, akár csillagállás, igaz a többiekre is. Ha van mirror vagy log shipping secondary adatbázis, akkor aktiváljuk, ellenőrizzük, és nézzük meg, hogy ott vannak-e az adatok. Ha nem, akkor vakarjuk meg a fejünket, és olvassunk tovább.

Ezután igyunk egy kávét/kólát/ánizsteát, dohányosok szívjanak el egy cigit, és gondolkodjunk el azon, hogy hogy lehet a legjobban kimászni a helyzetből: itt jön a legutóbbi backupok kérdése,valamint a legutóbbi sikeres DBCC CHECKDB ideje, hogy lehetőleg ne állítsuk vissza mentésből a sérült adatbázist. A korrupt adatbázisra a hozzáértők egybehangzó tanácsa: állítsd vissza mentésből. És ez így igaz. Ez az egyetlen tuti módszer van, ha nincs egy működő tartalékod. Ha meg tudná csinálni tutibiztosan a SQL Server, megcsinálná magától, és nem lenne sérült az adatbázis.

Persze lehet, hogy a backup nem épp a legfrissebb (olyat nem írok, hogy nincs), és mégis kell valami adat a beteg db-ből. Ekkor nem ússzuk meg a hősi munkát. Az én általános DR tervem a következő:

  1. Ellenőrzöm, hogy van-e elég szabad helyem ahhoz, amit fogok csinálni: adatfájloknak, tranlognak (jó nagy lesz, amit a #2 csinál), backupnak.
  2. Elkezdem a restore-t, amilyen gyorsan csak tudom, egy új adatbázisba.
  3. A suspect adatbázist felhozom emergency módba (ALTER DATABASE Titanic SET EMERGENCY), és elkezdem kitolni belőle amit csak lehet: a teljes sémát megpróbálom kiscriptelni egy új adatbázisba (indexekkel, foreign keyekkel, default értékekkel, de legfőképpen identity oszlopokkal), aztán megpróbálom az adatokat is átpumpálni bele. Itt jön az izgalom: ha a db korrupt, akkor valahol valami nem fog sikerülni. Jó esetben hibát is dob a SQL. De nekünk itt pl. nem dobott hibát, csak csendben lenyelte az utolsó három napnyi adatot. Tehát mindenképpen kell a humán adatellenőrzés.
  4. Ha a #2 lement, rátolok egy DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS-t a db-re, hátha többet vissza tud utána adni, mint a #2-ben. Persze lehet, hogy kevesebbet.
  5. Ha megvan a működő adatbázisom valahogy a háromból, akkor leellenőrzöm logikailag az adatokat, tolok rá egy DBCC-t, egy backupot, beállítom a backup jobot hozzá, és ráengedem az alkalmazást.

Miért szivatom magamat mind a hárommal egyszerre? Mert a backup-restore jól hangzik, de ha kiderül, hogy baja van már a backupnak is, akkor az az elvesztett idő később fájni fog. Plusz ha nem csináltam az elmúlt pár percben tranlog backupot, akkor még adatot is veszítek tutira. Ha ki tudom szedni a legutolsó adatokat a sérült DB-ből, az lefedheti az így keletkezett hézagot. A #2 egy logikus lépés, a #3 szintén, és mint jeleztem, más adatokra számíthatunk. Pl. ha megsérült egy tábla közepén a clustered index, amit a repair ki tud vágni, akkor egy 10000 soros táblából #2 visszaadhatja az 1-2450 sorokat, #3 pedig az 1-2100 és 2900-10000 sorokat. Igen, hiányzik a közepe. Na és? Ha annyira fontos, akkor tessék mirrorozni.

Itt jegyzem meg, hogy szerintem az egyetlen tuti biztonságos tartalékképzési módszer a High Safety, azaz szinkron mirroring. Itt ugyanis nem a diszkről olvassa vissza az SQL Server, hogy mit is csinált az aktív adatbázis, hanem a memóriából kitolja mindkét helyre. Ez pl. egy esetlegesen felbukkanó hibánál sokat számít, például ha csak időnként ront el valamit a diszk kontroller, és ráadásul egy ideig még érvényes adat is marad a tranzakciós logba került szemét. Na nem mintha láttam volna már ilyet, csak úgy mondom. Cserébe a szinkorn mirroringnak van hatása a teljesítményre is, konkrétan csökkenti, mivel minden commit előtt van egy rövid megbeszélés a principal (aktív) és mirror (passzív) adatbázis szerverek között.

Végül hadd vonjam le a tanulságokat:

  • Legyenek backupjaid, ellenőizd, hogy készülnek-e, teszteld őket időnként.
  • Futtass rendszeresen DBCC CHECKDB-t. Ideális esetben legalább minden full backup előtt, így lényegesen nagyobb esélyed van arra, hogy a backupod jó lesz.
  • Legyen DR terved, és próbáld is ki, amennyire csak tudod.
  • Legyen tartalékod a fontosabb adatbázisaidból. Fantasztikus tud lenni 5 perc alatt megoldani egy DR-nek induló szituációt.

SQL teljesítményelemzés morzsák

Az egyik visszatérő kérdés: mit nézzek, ha baj van? Erre több megközelítés is lehetséges: lehet az Indexet, majd elmúlik a baj; esetleg olvasgatni dokumentációt vagy guglizni; vagy álláskereső portált nézni; netán a szerver teljesítményét megvizsgálni.

Ja, de hogyan? Hát, elmondom, hogy én kb. miket csinálok, amikor döglődik az SQL. Ez részben szisztematikus, részben nem, ugyanis vannak dolgok, amiket lehet párhuzamosan csinálni, vagy felcserélhetőek, vagy esetleg egyik a másikat feleslegessé teszi, vagy valami tök más is beugorhat, ha valami tök mást látok. De mondjuk, hogy az esetek 85%-ában az általam üzemeltetett szerverek 90%-a ilyenekkel kezelhető. Ezek kis ötletgombócok, nem egy script, amit le kell futtatni.

Először is: ne csak performance countert nézzünk, hanem minden mást is. Tipikusan DMV-ket és perfocuntert. Az activity monitort csak indikátornak ajánlom: ha működik, akkor nem lehet nagy baj. Valahogy igen erőforrásigényes szegényke, és amikor jön a terhelés, rendszeresen aszongya, h timeout. Én a következő útvonalon haladok:

Kezdetnek írjuk fel egy papírra, és tegyük a monitor mellé: Memória, CPU, Diszk I/O. Ez a három dolog kell a SQL-nak. Egyszerű rendszer, egyszerű lelkeknek.
Continue reading ‘SQL teljesítményelemzés morzsák’ »

Windows 7 vs AHCI disable

A közkedvelt notebookom múlt héten visszakerült hozzám újabb szervíz-túrája után. Időnként elpukkant a Windows 7 rajta, a minidump elemzés pedig mindig más hibával jött elő, de mind hardverhibát sejtetett. Aztán a memtest 86+ is kifagyott rajta (erről később kierült, hogy T400 típusjelenség), úgyhogy ment a szervízbe. A szervízes srác nemes egyszerűséggel AHCI BIOS állítással oldotta meg a jelenséget a munkalap szerint. Ezen jót derültünk, bár én nem tudom, hogy mi alapján döntött így, mert nem vagyok egy hardveres.

Mindenesetre tegnapelőtt jutottam oda, hogy bekapcsoljam a gépet, és azt találta mondani már bootnál, hogy KÉK. Újabb bootnál már láttam, hogy a diszkkel van baja. Futtattam egy repairt, de nem segített (de legalább 2 perc volt :), a vége a megjavíthatatlan partíciós tábla volt, úgyhogy megsirattam a Win7-et, és elkönyveltem, hogy ez volt az oka a kékhaláloknak: az egész ramatyul volt már. Elővettem a Win2008R2 vinyót, és bebootoltam azt. Kékhalál, diszkprobléma.

Na, itt elkezdtem visszaemlékezni a szervíz munkalapra… AHCI… aha… gyors netszörcs… tényleg, Vista+ oprencert ki tud nyírni a váltás, és le is volt írva csomó helyen, hogy lehet a standardról AHCI-ra váltani. De nekem kikapcsolta ez a derék ember, nem be, azt meg sehol nem írták le. Végül a Microsoft kiváló KB cikkét elolvasva megtaláltam a rejtett varázsigét. A more information szakaszban elmondták, hogy “…pl. van egy Vista vagy Win7 gép, ami a pciide.sys drivert használja, és később a SATA módot AHCI-re állítod…” Fogtam a registry hekkelős megoldást, miszerint az msahci és IastorV drivereket engedélyezzem, és ugyanazzal a módszerrel engedélyeztem a pciide drivert. Szóval gyakorlatilag a következő tartalmú .reg file-t kell letolni a gépen, és utána akár ki, akár bekapcsolod az AHCI-t, bootolni fog.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci]
"Start"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IastorV]
"Start"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\pciide]
"Start"=dword:00000000

Persze jön a kérdés, h mér ilyen láma az MS. Mert nem akartak feleslegesen vackokat betölteni (pl. IDE drivert AHCI-s gépen), amitől gyorsabb lett, viszont hagyhattak volna egy fallback hardver detection opciót, ami frakk esetén megpróbál mindent detektálni.

És az én fejemben jön a kérdés, hogy egy Vista certified logós notebookon hogy gondolja a szervízes srác, hogy kikapcsolja az AHCI-t, ami kinyírja a supported oprencert. De ez messze vezet. Meg az is, hogy miért kapcsolta vissza a touchpadot, amit gyűlölök, és a sörhasam kattogtatni szokott vele.

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.
Continue reading ‘SQL 2005-2008 upgrade, játékosan’ »

Error 18456, Level 14, state – SQL Server login errors

(Magyarul itt)
Occasionally it happens that someone is unable to log in to SQL Server because they mistyped the password, have no permission, etc. This is not a problem – as long as we know what is the blocking issue. But how about someone being cocksure they’re trying the correct user, password ,server, etc and still failing? The most straightforward solution is my favorite, reading the SQL errorlog, once again. If the server is set to audit failed logins (and this is the default), you can find the error in the errorlog as well, not on the client side only:

Msg 18456, Level 14, State 1, Server DEMOSQL1, Line 1
Login failed for user ‘tygger’

Actually, something better gets in to the log, but first, let’s analyze the first line, that is ,the first three numbers of the error. the first one is the error number, the identifier of the error; the second is the severity, that is, how bad it is. The bigger the number the worse it is. If you see something above 19, you might be in real trouble. The third number is the state, which is an interesting species. This can be used to provide diagnostic information, like throwing an error with state 1 from an SP and with state 2 from parameterized query. It can make DBAs (and developers) life easier. Now back to that errorlog!
Continue reading ‘Error 18456, Level 14, state – SQL Server login errors’ »