Rollback

The AMD multicore CPUs have an interesting feature: the timers of the cores are not synchronized. This is the so-called clock-drifting which can be accountable for a lot of unexpected phenomenons due to the fact that the cores have different times and processes using multiple cores can be badly surprised. During the last year I had the chance to collect a few of the tricks:

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

Már többször telepítettem SQL 2005 clustert, de eddig ezzel a fícsörrel még nem találkoztam. végigballagtunk a telepítővel a mindenféle kérdéseken – ki mit futtasson, mi menjen fel, mi a cluster IP, satöbbi, satöbbi, majd megböktem az install gombot, és elmentem mítingelni, hogy kettőnk közül legalább a gép dolgozzon. Amikor visszajöttem, azt láttam, hogy setup failed. Egész pontosan ezt:

Setup failed to start on the remote machine. Check the Task Scheduler event log on the remote machine.

Hát ennek nem örültem. Megnéztem az event logot a másik node-on, a scheduled tasks menüjében, semmi okosat nem láttam. Aztán interneteztem, és megtaláltam a választ itt: http://support.microsoft.com/kb/910851.
Mint kiderült, ez azért történt, mert be voltam logolva a passzív node-ra is, amit nem szabad ezek szerint. Kilogoltam, újrakezdtem, és tényleg hiba nélkül lement. Szóval kedves szakik, ne installáljatok úgy SQL clustert, hogy valaki be van lépve a passzív node(ok)ra.

A konkurrencia margójára egy érdekes hiba és megoldása:
Error: 7105, Severity: 22, State: 6
Page (1:42521), slot 14 for text, ntext, or image node does not exist.

Ilyet is tud mondani esetenként az SQL Server, és ez elég rosszul néz ki elsőre. Pár perc guglizás után sokkal rosszabbnak tűnik, mert az értelmezés szerint valószínűleg van egy corrupt page (vagy legalábbis referencia) az adatbázisban, de ha futtatunk egy DBCC CHECKDB-t, akkor semmi hiba nem derül ki (ha kiderül, akkor az a B ág, lehet restore-olni :). Aztán pár nap múlva megint előjön, majd semmi hetekig, megint előjön, és az ember kezdi furcsán érezni magát.
A leggyakoribb előidézője ennek az esetnek a csodálatos read uncommitted tranzakciós szint, megoldása pedig a dirty read elkerülése. Mi is történik? A read uncommitted szintről már tudjuk, hogy ő olvas mindent pillanatnyi állapot szerint, függetlenül attól, hogy az a tranzakció, ami előidézte a jelenlegi állapotot, befejeződött-e vagy még nem. A másik fő jellemzőjét a locking hintként elérhető művészneve adja: NOLOCK. Azaz ő nem lockol semmit. Ennek akkor van jelentősége, maikor valaki töröl vagy módosít, mert ilyenkor a “normál” read committed query a shared lockjával nem engedi, hogy kihúzzák alóla a rekordot, de az uncommitted queryvel mindent meg lehet tenni, ezt is. És aztán amikor eljut egy BLOB-hoz a query, ami a rekordban csak egy 16 byte-os pointer képében tárolódik, és valójában egyéb lapokra van “kitéve” az adatbázis fájlban, akkor még az is megeshet, hogy éppen volt valami módosítás a BLOB-ok háza táján, és amit mi a fenti példában a 42521-es lap 14. rekeszében keresünk, az már átugrott valahova máshova, vagy egyszerűen törölve lett. A pointer persze update-elődik a rekordban, de aki uncommitted módon olvas, az pont be tud esni két szék közé ilyenkor.
Az igazi megoldás a snapshot izolációs szint bekapcsolása és használata az alkalmazásból való nolock-os kérdezések helyett.