Glorf IT

Mit der aktuell erschienen Version versucht Sybase offenbar nun verlorenen Boden gut zu machen. Nach so vielen Jahren Stillstand würde ich einen großen Wurf erwarten, aber es kam doch nur eine Minor Version heraus: 15.5

• Version 11.0: 1995
• Version 11.5: 1997
• Version 11.9: 1998
• Version 12.0: 1999
• Version 12.5: 2001
• Version 15.0: 2005
• Version 15.5: 2010

Zuletzt schaute ich die Version 12.0 an und kehrte dem Sybase SQL Server dann enttäuscht den Rücken. Wenn es jetzt mit dem Sybase SQL Server durch den geplanten Kauf durch SAP wieder bergauf geht, dann könnte daraus eine Alternative zum Microsoft SQL-Server erwachsen, dessen Preise mit dem R2 nun erst wieder erhöht wurden. Ohne die Aktion hätte ich die Version 15.5 vermutlich auch einfach ignoriert… Aber wer weiß, vielleicht krempelt SAP den Laden ja mal richtig um. Das würde mir gefallen.

Daher sammele ich mal hier, was mich damals am Sybase Adaptive Server Enterprise enttäuschte. Vielleicht hat sich mit der Version 15.5 hier ja schon etwas getan oder mit SAP geht wirklich etwas voran?
Wer immer hier Erfahrungen beitragen kann, der ist eingeladen das mit Kommentaren zu tun.

• Die Installation war in Java implementiert, kompliziert und fehleranfällig. Man musste echt viel tun. Daher haben wir damals auf einem Referenzsystem installiert und dann den SQL-Server durch Copy und Paste auf die Systeme unserer Kunden aufgebracht. Zum Glück schrieben sie nur wenig in die Registry. Für die Installation war so viel Insiderwissen nötig, das wäre für unsere Kunden niemals tragbar gewesen.
• Die Werkzeuge waren ebenfalls in Java geschrieben: was damals ein Synonym zu "langsam" war. Heute – also 10 Jahre später – sind die Rechner ja zum Glück so schnell, dass das kein Problem mehr sein sollte, oder etwa doch?
• Datenbanken musste man von Hand vergrößern. Es musste sich tatsächlich ein Support-Mitarbeiter per Fernwartung aufschalten und die Datenbank vergrößern, wenn die Grenze erreicht war. Das war einer der Killer und Motor für den Umstieg auf Microsoft. Unsere Kunden haben halt keinen Admin.
• Auch die TempDB wuchs nicht dynamisch. Es kam deswegen regelmäßig vor, dass Datentrafos wegen der TempDB abbrachen. Das war in der Praxis das häufigste Problem.
• Man konnte nicht einfach eine Datenbank verschieben. Wenn es bspw. ein Problem gab, dann konnte man nicht einfach die Datenbank-Dateien von den Kunden reinholen und anschauen. Die Datenbank dann an einen anderen SQL-Server dran zu bringen, war eine größere Wissenschaft, wenn man nicht die Details zu den Devices (Verteilung und Reihenfolge des Anlegens) mitgeliefert bekam. Das war echt krank und ebenfalls ein Killer für uns.
• Jeden Kleinkram musste man konfigurieren: Man musste angeben wie viele parallele Connections erlaubt waren. Dafür wurde der nötige Speicher vorallokiert. Kam dann eine Connection mehr, dann wurde die abgewiesen. Es gab keinerlei Dynamik: Was konfiguriert war, wurde an Speicher benötigt, man musste das Maximum rausfinden und dann einstellen. Das galt für alle wichtigen Dinge: jede Puffergröße wurde manuell eingestellt. Megalästig und für unsere Kunden der Horror.
• Damals begannen wir ODBC zu nutzen. Die mitgelieferten ODBC-Treiber kamen nicht von Sybase, sondern von einem Dritthersteller. Sie waren schlecht. Dito mit OLEDB. Als wir mit .net anfingen und bei Sybase wegen Konnektoren nachfragten, wussten die Entwickler über dem Teich noch nicht mal was ADO.net war und vertrösteten uns darauf, dass sie sich das anschauen würden, wenn das auf dem Markt etabliert sei.
• Die Fehlerbehandlung mit Abfragen von @@ERROR war krude, umständlich und fing nicht alle Fehler ab.
• Die Zeit-Datentypen und -Funktionen waren umständlich und ungenau. Leider war das bei Microsoft ja bis kürzlich auch noch so.
• Das Backup war umständlich. Man musste immer zuerst ein Dump-Device anlegen. Ein Backup direkt in eine Datei ging nicht. Dementsprechend umständlich war die Rücksicherung bzw. das Neuaufsetzen eines alten Systems.
• Der Upgrade einer Version auf die nächste war sehr schwierig und fehleranfällig. eine automatischer Upgrade in place war mit vielen Unwägbarkeiten verbunden.

Ergänzungen und Aktualisierungen sind willkommen…

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?