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

0. 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.
1. Elkezdem a restore-t, amilyen gyorsan csak tudom, egy új adatbázisba.
2. 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.
3. 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.
4. 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.

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.

• Oprendszer CPU és memória. Ha ki van ültetve a CPU vagy nincs szabad memória, akkor már világos, hogy a fizikai erőforrás fogyott el. Megosztott gépen kérdés, h mennyi jutott a SQL-nek.
• Ha véletlenül működik az activity monitor, akkor a recent expensive queries gombócot érdemes megnézni, a végrehajtások számával együtt!
• Megnézem, h hova lett az az erőforrás, amiből kifutottunk. Extrém esetekben lehet, h van szabad fizikai erőforrás, ebben az esetben a háromság harmadik lábát, a diszk I/O-t is érdemes megnézni. Azaz perfcounter, Physical disk – Avg Disk (Read/Write) queue Length. Emellett hasznos lehet a % Disk Read/Write time is, DE vegyük be a counterek közé a % Idle time-ot is, mert a % Disk Read/Write time hajlamos többet hazudni, mint a tényleges (azaz az idle a megbízható a történetben).
• A háromból az egyik tuti nem jó. Megnézem hogy ki gyilkolja azt. Ezt különféle DMV-kből lehet kiszippantani, kezdjük barátunkkal, a sys.dm_exec_sessions nevűvel. A memory_usage oszlop adja magát, ez 8KB-os lapokban mondja meg a használatot, és vele a legegyszerűbb dolgozni. A cpu_usage, a reads és writes meg azért nehezebb, mert ott bizony változást kell számolni, mivel az aktuális érték semmitmondó magában. Kétmillió olvasás két hét alatt azért nem olyan sok például. Ezt persze a sysprocessesből is ki lehet venni, majdnem ugyanaz, nekem még erre van egy scriptem:

  if object_id('tempdb..##c1') is not null
  begin
  drop table ##c1 drop table ##c2
  end
  select session_id, login_time, sum(cpu_time) cpu, sum(reads) reads, sum(writes) writes into ##c1 from sys.dm_exec_sessions group by session_id, login_time
  waitfor delay '000:00:10'
  select session_id, login_time, sum(cpu_time) cpu, sum(reads) reads, sum(writes) writes  into ##c2 from sys.dm_exec_sessions s group by session_id, login_time
  select c2.cpu-c1.cpu cpudiff, c2.reads-c1.reads [read], c2.writes-c1.writes write, p.memory_usage/128 mem_used_MB, p.login_name, p.cpu_time, p.*
  from sys.dm_exec_sessions p
  join ##c1 c1
  on p.session_id= c1.session_id
  join ##c2 c2
  on p.session_id= c2.session_id
  where
  c2.cpu > c1.cpu
  or c2.writes > c1.writes
  or c2.reads > c1.reads
  or p.memory_usage > 15*128 -- 15 MB
  order by c2.cpu-c1.cpu desc
  -- majd tessék dropni a temptáblát. Azért nincs itt a végén, hátha bogarászni akarunk még bennük
  

• Ekkorra már nagyjából illene, hogy legyen sejtésünk a drágaság forrásáról, legalább olyasmi, h melyik alkalmazás. Jöhet a DBCC INPUTBUFFER() vagy nekieshetünk profilerrel is, ízlés dolga. Aztán egyszer eljutunk egy objektumhoz. Ha tempdb, akkor valaki valami beteg joinokat csinál általában, nézzünk ilyen szemmel a futtatott kverire. Ha pedig vmi user tábla, akkor vagy full table scan futkos rajta sokat, vagy kéne venni memóriát.
• Személyes tapasztalatom az, hogy az esetek 30%-ában valaki kiülteti a procit, azt a fenti script lokalizálja, aztán a kill paranccsal orvoslom. 70% az erős memóriahiányos állapot, ekkor meg a BOL-ból kiveszek két scriptet, a sys.dm_os_buffer_descriptors oldaláról: az első (azaz A.) megmondja, hogy mennyi memóriát esznek az adatbázisaim:

  		SELECT count(*)AS cached_pages_count
      ,CASE database_id
          WHEN 32767 THEN 'ResourceDb'
          ELSE db_name(database_id)
          END AS Database_name
  FROM sys.dm_os_buffer_descriptors
  GROUP BY db_name(database_id) ,database_id
  ORDER BY cached_pages_count DESC;
  

  Itt nézzük meg, hogy az összeg meg a használt memória stimmelnek-e nagyjából. Pl. elszúrt alkalmazás tele tudja hányni a procedure cache-t, ami meghízik szép csendben két gigára, aztán néz az ember, mert az adatbázis lapoknak nem maradt hely. A B kveri meg ugyanezt tudja, adatbázis szinten. Itt is jól látszik, h ki lakik a memóriában, még az is, h melyik index (vagy a tábla maga). Ilyenkor lehet kiválóan procedure cache-t üríteni (DBCC CLEANPROCCACHE – ez az egész szerverre lefut, szóval odavághat kicsit a teljesítménynek, mert mindent újra kell fordítani, de itt talán már mindegy).

Majd valaki rúgjon oldalba, ha még idén nem írok a latchekről is valamit.

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.

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.

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!

2009-07-27 14:02:02.21 Logon     Error: 18456, Severity: 14, State: 8.
2009-07-27 14:02:02.21 Logon     Login failed for user 'tygger'. [CLIENT: 10.10.10.1]

Feel the difference: that state value is obviously different from what the client saw – and this is intentional. SQL Server won’t disclose any info which may help a malicious person during an attack. But if there’s a real need for help, you can go to the sysadmins and ask them to check the log what was the reason of the failure. They can check for the status values in the errorlog. And here’s the resolution:

ERROR	DESCRIPTION
2, 5	Invalid username
6	SQL authentication was attempted with Windows login name
7	Disabled login
8	Bad password
9	Invalid password
11, 12	correct login but no server access
13	SQL Server service paused
16	Correct login but no access to the selected (or default) database
18	User must change password
23	Server is shutting down, only sysadmins can log in
27	Correct login but server cannot determine an initial database
38	[2008] Opening explicitly specified database failed (16 in SQL 2005)
40	[2008] Opening login default database failed (16 in SQL 2005)

Some of these are not obvious (some of them I have no idea about:), so here’s some help:

State 16 in SQL 2005, 38/40 in 2008 is caused most commonly by auto close databases. This is a great feature – for MSDE or Express but not for production. So I recommend you checking if you have any database with auto close enabled and if you have, turn this off – you have just problems with it. Other than this login issue (which will disappear if you retry as the database will be reopened in a few seconds, so a subsequent user can use it immediately) it pollutes your precious errorlog with messages like this: “Starting up database XYZ” .

State 11/12 are typical Windows login issues: SQL Server knows who tries to log in, authentication is successful, but there’s no SQL login for the Windows login, authorization fails.

This post was written based on the SQL Protocol team blog post and the discussion after it, as it was pretty embarrassing that there’s not a single consolidated list of errors, but many of them should be collected from the comments – so I put the list together.