SQL Server 2005 Express Edition

2 CLR-Integration in den SQL Server 2005 Express (S. 73-74)

Der SQL Server 2005 legt in Bezug auf die Programmierbarkeit gegenüber dem Vorgänger sehr deutlich zu, denn trotz der bisherigen Leistungsfähigkeit lassen sich nicht alle Aufgaben allein mit T-SQL umsetzen. Ab dem SQL Server 7.0 wurden zusätzlich zu T-SQL über das Open Data Services API die Extended Stored Procedures (XP) unterstützt, die in der Regel als Win32-DLL in C++ geschrieben wurden. Wenn eine XP mit den Daten aus der Datenbank arbeiten wollte, musste innerhalb des Servers eine zweite Datenbankverbindung abgespaltet und in einem zusätzlichen Thread ausgeführt werden. Sowohl das Schreiben als auch das Debuggen einer XP gehört nicht gerade zu den trivialen Aufgaben, so dass die meisten dann doch darauf verzichtet haben, zumal eine nicht ausreichend getestete XP den kompletten SQL Server in den Abgrund ziehen konnte. Auf der anderen Seite standen die Automations-Objekte, die über die Prozeduren sp_OACreate, sp_OAMethode usw. auch über T-SQL heraus angesprochen werden konnten. Für das Implementieren eines derartigen Automation- Objekts konnten populäre RAD-Tools wie Visual Basic oder Borland Delphi verwendet werden – so dass diese Option entsprechend häufiger ausgenutzt wurde. Zur Laufzeit hantierte der SQL Server über die späte Bindung mit dem Automation-Objekt, so dass dies entsprechend zeitaufwändig war. Dazu kommen noch die strengen Regeln von COM in Bezug auf die Referenzzählung der Interface-Zeiger – im Worst Case wurde eine Objektinstanz erzeugt, aber nicht mehr freigegeben (in der alten Win32-Welt gab es den automatischen Garbage Collector von .NET noch nicht).

Zu guter Letzt waren da auch noch die undokumentierten Funktionen, mit denen Microsoft intern das ein oder andere Loch im Funktionsumfang geflickt hat. Zum Beispiel ist im Microsoft SQL Server 2000 die undokumentierte (!) Systemprozedur xp_fixeddrives vorhanden, die Informationen über die Festplatten des Rechners liefert. Nun können Sie überall bei erhobenem Zeigefinger nachlesen, dass in einer Produktionsumgebung niemals eine undokumentierte Funktion verwendet werden darf, aber die Verlockungen waren in der Praxis oftmals dann doch zu groß.

Mit dem SQL Server 2005 gehören die Gewissenskonflikte der Vergangenheit an, denn nun lassen sich benötigte Funktionen mit dem bereits vorhandenen Wissen über das .NET Framework selbst nachrüsten, ohne dass man sich damit handfeste Nachteile einhandelt. Es ist kein Geheimnis, dass innerhalb von Microsoft das SQL Server-Team gegenüber dem CLR-Team gravierende Veränderungen am .NET Framework 2.0 durchgesetzt hat. Das Ziel dieser Umbauarbeiten lag darin, das Verhalten des .NET Frameworks in den beiden Kernbereichen Sicherheit und Stabilität zu verbessern. Aus dem Blickwinkel des SQL Server-Teams betrachtet stehen die Anforderungen in der folgenden Reihenfolge:

Sicherheit
Zuverlässigkeit
Performanz

Gerade bei SQL Servern wird aufgrund ihrer Bedeutung eine Verfügbarkeits- Quote von 99,999% erwartet. Damit diese Quote auch in der Praxis erreicht wird, muss die Performanz zwangsläufig eine niedrigere Bedeutung erhalten (obwohl bei den einschlägigen Benchmarks die verschiedenen Datenbanken generell nur nach der Performanz gewichtet werden).

Die sich aus den Erweiterungen ergebenden Vorteile nutzt implizit auch jeder andere Entwickler, wenn er eigene Assemblies in den SQL Server installiert.

2.1 Was ist managed Code?

Das wesentliche Merkmal von .NET besteht darin, dass die Kompiler aus den jeweiligen .NET-Sprachen einen Zwischencode (Intermedia Language) generieren, der erst zur Laufzeit vom Just-In-Time-Kompiler (JIT) der CLR in die CPU-Anweisungen übersetzt wird (aus diesem Grund ist .NET auch Hardware-unabhängig). Solange sich jede einzelne Programmiersprache an die Regeln der Common Language Specification (CLS) hält, können Klassen, Objekte und Daten sprachübergreifend zwischen .NET-Modulen ausgetauscht werden. Da die CLR die Programmanweisungen nur in einer selbst kontrollierten Umgebung von der Microsoft Common Object Runtime Execution Engine (mscoree.dll) ausführen lässt, spricht man von einem verwalteten Programmablauf. In dieses Konzept sind so entscheidende Faktoren wie die Speicherverwaltung und die Zugriffs- und Ausführungs- Sicherheit integriert.