Mit dem SQL Server 2008 und dem SP3 für SQL Server 2005 hat Microsoft den Fehler beseitigt, der auf CPUs mit Stromsparfunktionen regelmäßig zu Timingproblemen führte. Die Meldungen sahen dann etwa so aus:
CPU time stamp frequency has changed from 191469 to 1794177 ticks per millisecond. The new frequency will be used
Das war nicht wirklich schlimm, die dauernden Fehlermeldungen in der Ereignisanzeige nervten aber ausgesprochen. Betroffen waren nur Performancemessungen. Auch wir bekamen regelmäßig beunruhigte Nachfragen seitens unserer Kunden zu diesen Fehlermeldungen. Details zum behobenen Problem stehen in KB931279: der SQL Server 2005 entnimmt seit SP3 die Zeiten nicht der dem CPU-Counter (RDTSC), sondern ähnlich wie die Multimedia-Time. Details zu den genauen Unterschieden beschreibt Bob Dorr (Microsoft) im Artikel "How It Works: SQL Server No Longer Uses RDTSC For Timings in SQL 2008 and SQL 2005 Service Pack 3 (SP3)".
Risiken und Nebenwirkungen
Manchmal haben Änderungen in der Software Risiken und Nebenwirkungen, die man so nicht erwarten würden. So ging es Microsoft an dieser Stelle offenbar. Ein netter Kollege machte mich auf den kürzlich dazu erschienen Artikel von HP aufmerksam:
ProLiant servers that have multiple processor cores and that are running Microsoft SQL Server 2005 SP3 or SQL Server 2008 may stop responding when under a heavy I/O processing load. If Automatic Server Recovery (ASR) is enabled on these servers, the server may reboot when the server stops responding.
SQL Server 2005 SP3 and SQL Server 2008 use mmtimer (Multimedia) timer rather than the RDTSC timer, which changes the clock granularity (to 1ms). This change may result in clock-drift or an unresponsive server if the server uses enhanced power management technologies that change CPU frequencies.
Weitere Details siehe HP Customer Advisory c02110402. Ich persönlich denke, dass es nicht nur HP-Server treffen kann, sondern auch andere Server mit "enhanced power management technologies that change CPU frequencies". Ich hörte noch von keinem konkreten Problem in meinem Umfeld, aber kann jetzt gezielt nach solchen Symptomen Ausschau halten.
Abhilfe
Das als Abhilfe vorgeschlagene, undokumentierte Trace-Flag 8038 scheint nur Auswirkungen auf die Tracing-Ausgaben und Timing-Features zu haben, die SQL-Zeitfunktionern arbeiten wie gehabt auf Basis von 14ms-Ticks. Hat jemand schon Erfahrungen mit diesem Traceflag gesammelt?