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.

Alapvetően egy éles rendszeren végzett változtatással álltam szemközt, úgyhogy a teszt SQL clusteren megcsináltam a változtatást, felírtam, hogy mit csináltam, és nekiálltam az éles rendszernek is. A feladat mindössze annyi volt, hogy a kivett BUILTIN\Administrators helyett be kellett raknom a DOMAIN\MyTeam csoportot sa-nak, és kész. Hogyan lehet ilyet letesztelni? Mivel clusterről beszélünk, én végigbillentem a SQL-t az összes node-ra, hogy lássam, hogy mindenhol el tud indulni rendesen az új beállításokkal, illetve tudok is hozzá kapcsolódni (ez utóbbira sqlcmd-t használok). Ha az OS-t piszkálom, akkor node reboot után megy ugyanez. Éles négy node-os cluster esetén ez kissé időigényes, és a fél perc helyett négy perc szolgáltatáskiesést okoz, de esküszöm, hogy megéri.

Szóval megcsináltam a változtatást az éles rendszeren is, megnéztem, minden működött, mindenki be tudott lépni, úgyhogy le is zártam az ügyet, és foglalkoztam a többi dologgal. Aztán egy pár hét múlva éjféltájban felhívott az ügyeletesünk, hogy a fent említett cluster nem indul el. Kérdeztem, hogy mi a tünet, és azt mondta, hogy felhívták azzal, hogy piros a monitor, megnézte, a cluster admin szerint el volt dőlve a szolgáltatás, megpróbálta újraindítani, el is indult minden egy időre, aztán egy-két perc után megint elfrakkolt, ezt eljátszotta párszor, azóta meg failed állapotban van. Rutinos üzemeltetőként végigpörgött a fejemben, hogy mi mindent csináltunk a szerverrel az elmúlt időben, és a tünetek alapján rögtön tudtam, hogy mi a baj. Azért megkértem ,hogy nézze meg az errorlogot, amire elmondta az azóta híressé vált mondatot: „valami júzer be akar jelentkezni itt, és nem sikerül neki – de ez most mindegy, amíg nem fut a cluster rendesen”.

Itt egy kicsit röhögtem, és elmondtam neki, hogy a valami júzer a cluster service-t futtató account, és úgy működik a dolog, hogy a cluster service elindítja a clusterezett resource-okat, így például az SQL Server service-t, és pollozza őket, hogy működnek-e. Az SQL Server pollozása pedig úgy néz ki, hogy belogol a cluster service account, és időnként egy select @@servername query-t bedob. Ha ez sikerül, örül, ha nem, akkor egy megadott idő (default 180 másodperc, ha jól rémlik így a vonaton) után betegnek nyilvánítja a SQL Server service-t, és megállítja. Kiderült, hogy egy korábbi bohóckodás miatt a teszt clusteren már hozzá volt adva a cluster service külön SQL accountként, úgyhogy ott nem is volt semmi hiba. Az élesen csak az ütött be, amikor leterhelték a clustert, és megállt a SQL, majd el akart megint indulni, addig ugyanis nem próbált meg belogolni újra a cluster service account, így nem zavarta, hogy dobtam (vagyis droptam) a loginját. Amikor újraindult a SQL, kiválóan működött minden – 180 másodpercig, amikor is a sok hiábavaló próbálkozás után a cluster service betegnek nyilvánította az egyébként makkegészséges szervert, és lelőtte. A baj az volt, hogy megfelelő számú próbálkozás után már el sem jutottunk odáig, hogy elinduljon a SQL és beléphessünk megjavítani. Úgyhogy jött mindenki barátja, a single user mód: sqlservr -c -m, amiben sqlcmd-vel belépve kiválóan meg lehetett pákázni. Ilyenkor persze a SQL tényleg a cluster node-on fut, nem virtual serverként, tehát nem úgy lehet hozzá csatlakozni, mint máskor, hanem (local) vagy . vagy hosztnév. Gyorsan csak ennyit mondtunk:

create login ’DOMAIN\_clusterserviceuser’ from windows

Figyelembe véve, hogy ő a szerver nevén kívül nem kérdez semmit, nagyon boldog a public role-lal, nem kell neki több jog. El is indult, örültünk is.

Tanulságok:

• A teszt és éles rendszereket szinkronban kell tartani.
• A változtatások után mindig meg kell győződni arról, hogy mindent életben hagytunk: újraindítani az érintett service-eket, stb.

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

Illetve igazából nem is ez kerül a logba, hanem valami jobb, de mielőtt ebbe belemegyek, értelmezzük az első sorát az üzenetnek, vagyis az error három numerikus argumentumát: Az első az error number, ez a hiba egyedi azonosítója, a gépek mindig jobban szeretik a számokat, mint a dumát. A második a level vagy severity, azaz mennyire gáz az adott hiba. Minél nagyobb a szám, annál rosszabb a helyzet, severity 20 és 25 között már az is kérdéses, hogy rendesen működik-e a szerver. Az utolsó elem a state, ami egy érdekes állat. Arról adhatunk itt információt, hogy honnan jött az error – például ha van egy általunk definiált hiba, amit több különböző helyen is használunk, akkor a state értékét használhatjuk annak a jelzésére, hogy honnan jött a hiba. És most nézzük azt az errorlogot!

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 'kiscsillag'. [CLIENT: 10.10.10.1]

A különbség jól látható: az a bizonyos state érték eléggé más itt, mint a kliensoldalon volt, és ez nem a véletlen műve. Az SQL Server, ahogyan azt jó rendszertől elvárjuk, nem mond többet a kliensnek, mint amennyi szükséges, nehogy ezzel segítsen egy esetleges támadást. Viszont aki tényleg segítségre szorul, az megkeresheti a sysadminokat, akik a logban láthatják, hogy miért is nem sikerült az a login. A state kódok pedig a következőek:

ERROR	LEÍRÁS
2, 5	Érvénytelen felhasználónév
6	Windows login névvel próbálkoztál SQL autentikációt használni
7	Letiltott login
8	Rossz jelszó
9	Érvénytelen jelszó
11, 12	Helyes login, de nincs szerver hozzáférés
13	SQL Server service paused
16	Helyes login, de nem lehetséges belépni a kért (vagy a default) adatbázisba
18	Jelszót kell változtatni
23	A szerver éppen leáll, nem lehet bejelentkezni (nem sysadminoknak)
27	Helyes login, de a szerver nem tud meghatározni egy kezdeti adatbázist
38	[2008] Nem sikerült az explicit megadott adatbázis megnyitása (16 SQL 2005-ben)
40	[2008] Nem sikerült a felhasználó default adatbázisának a megnyitása (16 SQL 2005-ben)

Van néhány kód, ami nem olyan triviális, hogy mit is jelent, néhányról magam sem tudom :), úgyhogy néhány jellemzőt kiveséznék:

A state 16 (vagy 38/40 SQL 2008-ban) egyik leggyakoribb oka az auto close-os adatbázis. Azaz az SQL szerver becsukja az adatbázist, ha nem használták már egy ideje, és megint megnyitja, ha kell valakinek. Ez egy kiváló ötlet az MSDE-hez meg egyéb asztali gépes világba, de egyébként mindenkinek melegen ajánlom, hogy nézze meg, hogy van-e auto close-os adatbázisa, és ha van, kapcsolja ki ezt az opciót, mert csak szívás van vele. Hogy mi? Például a state 16: éppen be akar lépni a user, erre az SQL elkezdi megnyitni a DB-t neki, de amíg nem sikerül teljesen megnyitnia, addig ugye nem tudja beléptetni az adatbázisába a usert, és elbukik a login. Újrapróbálva valószínűleg jó lesz, mert addigra már kinyitja. A másik gagyi benne (és erről lehet messziről kiszúrni ezeket az adatbázisokat), hogy teleszemeteli az errorlogot “Starting up database XYZ” üzenetekkel.

A 11-12 tipikusan a Windows loginok esete: az SQL Server kiválóan azonosítja a felhasználót, de nincs neki megfelelő login létrehozva az SQL szerveren, úgyhogy emberünk kívül marad.

A blog alapját a SQL Protocol team blogja és a nyomában kialakuló diskurzus adta, mivel nem sikerül összeszedniük az összes kódot egy táblába, és ez engem baromira zavart – úgyhogy összeszedtem.

• master adatbázis data file
• master adatbázis log file
• errorlog

Ha ezt a három fájlt meg tudja nyitni, már boldog. És ha nem? Mindig az errorloggal kezdjük vizsgálódásainkat. Ha nem találjuk az errorlogot, nézzük meg, hogy van-e joga oda írni a SQL-t futtató accountnak. Ha megtaláljuk az errorlogot, akkor meg olvassuk el.
A fenti paraméterek egyébként az SQL Server Configuration Managerben láthatóak és állíthatóak (meg a registryben).

• Negative round-trip time during ping (Windows 2003)
• Excessive amount of events in SQL Server errorlog (W2K3, SQL 2K5)
• find -mtime 0 won’t find the recently created files (Red Hat EL 3)

Given that this is a mostly-SQL blog, I’m going to detail the second one. You can see events like this in the errorlog:

Date 11/25/2008 9:57:47 AM
Log SQL Server (Current – 11/25/2008 12:49:00 PM)

Source Server

Message The time stamp counter of CPU on scheduler id 3 is not synchronized with other CPUs.

And you can see this quite frequently. Now AMD created a fix for the bug but its target audience is not the big tribe of the sysadmins but the desktops. Why do you need a quad-core for a desktop user? Exactly: for gaming. So the fix called AMD Dual-Core Optimizer Version 1.1.4 gives you a chance to minimize the clock drifting by enabling the Game Mode. I gave it a try and installed it onto the server. Unfortunately the issue didn’t disappear, but it dropped by 97% which is a pretty good result – at least for me.

The idea sounds a bit wacky: fix an enterprise production database server with a gamer hotfix, but:

1. It does the job
2. If the Spanish MSFT support team could afford it, then I could as well :)