SQL 2005 SP3 install és elmozgatott rendszeradatbázisok

Épp eszembe jutott, és gondoltam megosztom mindenkivel: pár hónapja SP3-at installáltunk a SQL-re, és azt találtuk, hogy elfrakkol az install. Újrakezdve is elfrakkolt. Meg kellett nézni a logot (programkönyvtár\Setup Bootstrap könyvtárban laknak ezek az izék), és kiderült a hiba: a distmodel.mdf fájl hiányzott a drágámnak, mert ott kereste, ahol a master.mdf volt, de mi átmozgattuk máshova időközben. Úgyhogy baráti jótanács: ha elmozgatjátok a rendszeradatbázisokat, mozgassátok az összes adatfájlt együtt :) Kicsit deja vu érzésem van – lehet, hogy ezt már megírtam egyszer?

SQL Server login hibák – Error 18456, Level 14, state

(English version here)
Időnként megesik, hogy valaki nem tud belogolni egy SQL Serverbe, mert elgépeli a jelszavát, nincs joga, stb. Ez nem olyan nagy gond egészen addig, amíg tudjuk, hogy miért nem tud belogolni. De mi van, ha valaki azt mondja, hogy nem sikerült neki, 101%, hogy jó jelszóval próbálkozik, jó szerverre, jó felhasználónévvel, jó adatbázisba, minden jó, csak éppen nem tud belépni? A legegyszerűbb megoldás a nagy kedvencem, az errorlog elolvasása, már megint. Amennyiben a szerveren be van állítva a sikertelen belépési kísérletek naplózása (úgy emlékszem ez a default), akkor az errorlogba is bekerül az az üzenet, amit a kliensnek küld a szerver:

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:

ERRORLEÍRÁS
2, 5Érvénytelen felhasználónév
6Windows login névvel próbálkoztál SQL autentikációt használni
7Letiltott login
8Rossz jelszó
9Érvénytelen jelszó
11, 12Helyes login, de nincs szerver hozzáférés
13SQL Server service paused
16Helyes login, de nem lehetséges belépni a kért (vagy a default) adatbázisba
18Jelszót kell változtatni
23A szerver éppen leáll, nem lehet bejelentkezni (nem sysadminoknak)
27Helyes 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.

A very slow SQL Server

A few days ago I found that the replication into a database on one of our SQL 2005 Servers slowed down. The same publisher was replicated to multiple subscribers without any issue. I decided to check the database for blocking processes, because this db was used for reporting:

select * from sysprocesses
where
spid in (select blocked from sysprocesses where spid <> blocked)
and dbid = db_id('MyDatabase')

(The where spid <> blocked clause was needed because from SQL 2000 SP4, the “self-blocking” is also listed as a blocking but it wasn’t interesting in this case.) I expected to spot one of our report writers running a bloated query with massive joins ans sophisticated filters but it wasn’t the case. I found nothing. I had a suspicion that if I restarted the server, this phenomenon would disappear but as the server was still in a usable state, I decided to dig deeper cause I hate mysteries unresolved.

I started to check the distribution agent history in Replication Monitor but the only thing I found was that the agents were very slow. I checked them in the Activity Monitor and noticed that they were spending lot of time in RESOURCE_SEMAPHORE wait state. I checked the excellent white paper about SQL Server wait types, and saw that it usually means that due to high concurrent load, the query should wait for memory grant. So I checked the memory usage a bit.
Continue reading ‘A very slow SQL Server’ »

Lassú cluster failover és network name online pending

(For English version, read this) Elnézést, megvadultam, és elsőre angolul írtam meg ezt a postot, csak most fordul le magyarra.

Szóval kaptam egy kész Microsoft failover clustert, hogy megépítsem rá az SQL clusteremet, és a tesztelés során azt vettem észre, hogy botrányosan lassna billen át a cluster, másfél-két percig is eltart, az idő nagy részében pedig a network name-re várunk, ami online pending állapotban van vagy másfél percig. Némi molyolás után megállapítottam, hogy csak a network name a problémás, ha levittem offline-ba és visszahoztam rögtön ugyanazon a node-on, az is ugyanolyan sokáig tartott. Némi guglizás után találtam még egy csomó embert ugyanilyen problémával, de megoldást igazából nem. Végül kikötöttem egy Exchange 2007 W2K8-on poston, ami segített megtalálni a problémát, ami majd kiverte a szememet. Logikusan végiggondolva rá is jöhettem volna, de persze megint túldimenzionáltam ezt a kutya közönséges problémát, csak azért, mert egy komolyabb környezetben jött elő. Szóval az tartott másfél percig, hogy a hálózati kapcsolat beállításainál a DNS fülön be volt kapcsolva a Register this connection’s addresses in DNS opció, szegény szerver meg mindig nekiugrott a DNS szervernek, aki ignorálta a regisztrációs próbálkozásait. Erre ő elég lassan jött rá, és nem tanult az esetből, legközelebb megint megpróbálta. Kikapcsoltam, láss csodát: egy másodperc alatt felhozta a network name-et. Hepiend és kiváló alkalom volt megint az alázat gyakorlására.

Apropó cluster: a cluster ír egy kedves kis logot a C:\Windows\Cluster\cluster.log fájlba, néha hasznos lehet.

Slow cluster failover waiting for network name in online pending state

After getting a new Microsoft failover cluster, I found during the failover tests that the network name failed over horribly slowly. Otherwise everything was fine, but a complete SQL cluster failover took more than a minute and it was all because the network name remained online pending for ages. After some googling I didn’t find any specific solution, but I found a blog post about Exchange 2007 on Windows 2008 which put me into the right direction (that is, answered my question in a sentence) and gave the “I should have thought of this earlier” feeling (which helps me to exercise humbleness).

The sentence is the following:

In previous versions of Windows Cluster Server, every time a Network Name came online, it would register with DNS.

So I just checked my network settings and found that the Register this connection’s addresses in DNS checkbox was ticked. I cleared it and made a few tests: the network name came online in a second or less.

And I hate all the forums outside because you can’t just answer other’s question, you have to register (your login is already in use/too long/too short/contains invalid character/not complex enough/blocked by the swearword filter – and your password is way worse ) – and you get the confirmation mail the next day. So I left a few guys unanswered, but I hope Google will pick up this post so it’ll help on others.