Microsoft SQL Server 2005 im Vergleich zu Oracle Database 10g

Microsoft SQL Server 2005
im Vergleich zu
Oracle Database 10g
Alexander Bittner
07MIM
Datenbanken II
HTWK Leipzig, Fachbereich IMN
Leipzig, den 27 Juni 2008
1 Inhalt 1. Einleitung ............................................................................................................................................ 4 2. Architektur .......................................................................................................................................... 4 2.1 Rechenarchitektur / Host-Systeme ................................................................................................ 4 2.2 Datenspeicherung .......................................................................................................................... 5 2.2.1 Physische Datenspeicherung .................................................................................................. 5 2.2.2 Logische Datenspeicherung ................................................................................................... 5 2.3 Datenbankverbindungen ................................................................................................................ 6 2.3.1 Gemeinsamkeiten beider Systeme .......................................................................................... 6 2.3.2 Neuerungen beim SQL Server ............................................................................................... 6 2.4 Instanzen ........................................................................................................................................ 7 2.4.1 Instanzen in Oracle ................................................................................................................. 7 2.4.2 Instanzen in SQL Server ......................................................................................................... 8 2.5 SQL Standards und Spracherweiterungen ..................................................................................... 8 2.6 Sperren und Nebenläufigkeit ......................................................................................................... 9 2.6.1 Sperrkonzepte in Oracle ......................................................................................................... 9 2.6.2 Sperrkonzepte in SQL Server ............................................................................................... 10 2.7 Lesekonsistenz............................................................................................................................. 10 2.7.1 Lesekonsistenz in Oracle ...................................................................................................... 10 2.7.2 Lesekonsistenz in SQL Server ............................................................................................. 11 2.8 Partitionierung ............................................................................................................................. 11 2.8.1 Partitionierung in Oracle ...................................................................................................... 12 2.8.2 Partitionierung in SQL Server .............................................................................................. 12 2.9 Verfügbarkeit und Skalierbarkeit ................................................................................................ 12 2.9.1 Verfügbarkeit und Skalierbarkeit in Oracle ......................................................................... 13 2.9.2 Verfügbarkeit im SQL Server .............................................................................................. 13 3. Verwaltbarkeit ................................................................................................................................... 14 3.2 Verwaltung des SQL Server ........................................................................................................ 14 3.1 Verwaltung von Oracle ............................................................................................................... 14 4. Data Warehouse und Applikationsentwicklung ............................................................................ 15 4.1 Data Warehouse in Oracle ........................................................................................................... 15 4.1.1 Oracle Data Warehouse Builder ........................................................................................... 16 4.1.2 Oracle Discoverer ................................................................................................................. 16 4.1.3 Oracle Reports ...................................................................................................................... 17 4.2 Data Warehouse in SQL Server .................................................................................................. 17 2 4.2.1 SQL Server und das .NET-Framework ................................................................................ 17 4.2.2 Integration Services .............................................................................................................. 18 4.2.3 Analysis Services ................................................................................................................. 18 4.2.4 Reporting Services ............................................................................................................... 19 4.2.5 Notification Services ............................................................................................................ 19 5. Zusammenfassung ............................................................................................................................. 19 6. Quellen .............................................................................................................................................. 20 3 1. Einleitung
Sowohl Oracle als auch der SQL Server sind führende Produkte auf dem Gebiet der
Datenbanksysteme. Oracle gilt als Marktführer und findet mit seinen Produkten gerade bei
Großunternehmen viele Kunden. Microsoft stößt mit dem SQL Server 2005 verstärkt in
dieses Segment vor und braucht mittlerweile einen Vergleich mit Oracle nicht zu scheuen.
Ziel dieser Ausarbeitung soll ein Vergleich der beiden Datenbanksysteme Oracle 10g und
SQL Server 2005 sein anhand bestimmter Gesichtspunkte sein.
In Kapitel 2 werden vorrangig Aspekte der Architektur beider Systeme untersucht. Dabei geht
es vor allem um hardwareseitige Gesichtspunkte wie unterstützten Rechnerarchitekturen,
Arten der Datenspeicherung, die Verteilung von Datenbanken über Clustering und
Partitionierungsmechanismen. Des Weiteren wird die Arbeitsweise in Hinsicht auf die
Bildung von Instanzen, Verbindungen zur Datenbank, unterstützte SQL Standards sowie
Transaktionskonzepte untersucht.
Das Kapitel 3 beschäftigt sich näher mit der Verwaltbarkeit beider Systeme. Dabei werden die
verfügbaren Werkzeuge vorgestellt und ihre Funktionsweise genauer untersucht. In Kapitel 4
geht es um die von beiden Systemen bereitgestellten Lösungen im Bereich der Business
Intelligence und des Data Warehousing. Die verwendeten Konzepte werden erläutert und
deren Umsetzung untersucht.
Zum Abschluss wird eine Zusammenfassung des Vergleichs gegeben.
2. Architektur
2.1 Rechenarchitektur / Host-Systeme
In der verwendeten Rechenarchitektur unterscheiden sich Oracle und SQL Server kaum.
Beide sind für den Betrieb auf SMP-Systemen (Symmetic Multiprocessing Systems)
ausgelegt. Mithilfe des Oracle RAC (Oracle Real Application Clusters) lässt sich Oracle
jedoch auch auf MMP-Systemen (Massively Parrallel Processing Systems) betreiben.
Beide Datenbanksysteme benötigen ein Host-System, auf dem sie arbeiten können. Dort gibt
es Unterschiede bezüglich der unterstützten Betriebssysteme. Oracle ist weitgehend
plattformunabhängig und kann sowohl in einer UNIX- beziehungsweise LINUX-Umgebung,
als auch in einer Windows-Umgebung betrieben werden. Der SQL Server bringt lediglich
eine Unterstützung für Windows-Betriebssysteme mit.
Man kann daher sagen, dass Oracle vielseitiger in eine IT-Infrastruktur integriert werden
kann. Der SQL Server hat jedoch den Vorteil, auf einem hauseigenen (Microsoft)Betriebssystem ausgeführt zu werden. Daher lässt sich die Integration in das Host-System
besser und tiefgreifender realisieren.
4 2.2 Datenspeicherung
2.2.1 Physische Datenspeicherung
Oracle verwendet für die Speicherung seiner Daten Kontrolldateien, Datendateien und
Online-Redolog-Dateien.
Die Kontrolldateien dienen der Speicherung von Informationen über die physische
Datenbankstruktur, beispielsweise das Backup, Recovery und die Konsistenzsicherung
betreffend. Die Datendateien beinhalten alle Benutzerdaten sowie Metadaten. Die OnlineRedolog-Dateien beherbergen alle Transaktionsprotokollinformationen, die für eine
eventuelle Datenbankwiederherstellung benötigt werden.
Microsofts SQL Server verwendet eine ähnliche Trennung
sekundäre Datendateien und Protokolldateien.
in
primäre Datendateien,
Dabei enthalten die primären Datendateien Startinformationen für die Datenbank und
Verweise auf andere Datendateien. Die sekundären Datendateien sind optional und
benutzerdefiniert. Sie speichern Benutzerdaten. Die Protokolldateien beherbergen ähnlich den
Oracle
Redolog-Dateien
Transaktionsprotokollinformationen
zu
DatenbankWiederherstellung.
2.2.2 Logische Datenspeicherung
Oracle organisiert seine Daten logisch in Tablespaces. Es werden verschiedene Arten von
Tablespaces unterschieden. Tablespaces werden in Datendateien gespeichert, wobei eine
Datendatei mehrere Tablespaces enthalten kann.
Der Oracle SYSTEM-Tablespace dient der Speicherung von Tabellen, die die
Kernfunktionalität des Systems beschreiben, so zum Beispiel das Data Dictionary. Der
SYSAUX-Tablespace speichert Datenbankkomponenten, so zum Beispiel den Enterprise
Resource Manager. Der TEMP-Tablespace beherbergt temporäre Segmente, die bei der
Verarbeitung von SQL-Anfragen erstellt werden. Im UNDO-Tablespace werden UndoSegmente für die Datenbankwiederherstellung gespeichert. Permanente Benutzerdaten- und
Objekte werden im USERS-Tablespace abgelegt.
Der SQL Server kennt zwei Dateigruppen. Die primäre Dateigruppe umfasst die primäre
Datendatei und alle Datendateien, die keiner Gruppe zugeordnet werden können. Des
weiteren gibt es noch eine benutzerdefinierte Dateigruppe, in der sich Datenbanken befinden,
die mit Hilfe des Parameters FILEGROUP im CREATE-Statement einer bestimmten
Dateigruppe zugeordnet werden.
Für die logische Organisation verwendet der SQL Server die Systemdatenbanken „master“, „
msdb“, „tempdb“, „resource“ und „model“. Dabei hält „master“ Informationen auf
Systemebene, so zum Beispiel Metadaten über Anmeldekonten, Verbindungsserver,
Endpunkte und Systemkonfigurationseinstellungen. Die „msdb“ wird vom SQL Agent
verwendet und dient der Planung von Aufträgen und Warnungen. In der „tempdb“ werden
temporäre Objekte und Zwischenergebnisse gespeichert. Es handelt sich dabei um eine
globale Ressource, die für alle Benutzer zugänglich ist. Die Systemdatenbank „resource“ ist
5 schreibgeschützt und dient der Speicherung von Systemobjekten. Die Datenbank „model“
enthält Vorlagen, die für die Erstellung von neuen Datenbanken verwendet werden.
2.3 Datenbankverbindungen
2.3.1 Gemeinsamkeiten beider Systeme
Sowohl Oracle als auch der SQL Server bieten zur Kommunikation mit dem
Datenbanksystem das Client-Server-Modell an. Dabei handelt es sich um ein
Kommunikationsmodell, an dem zwei Prozesse beteiligt sind: der Clientprozess und der
Serverprozess. Das Prinzip besteht darin, dass der Client Anfragen an den Server sendet und
dieser die Anfragen für den Client ausführt. Das Ergebnis einer Anfrage wird an den Client
zurück gesendet.
Das Modell hat sich in vielen Bereichen etabliert und findet nicht nur bei Datenbanken
Anwendung. Das liegt nicht zuletzt an den unbestreitbaren Vorteilen, die das Modell bietet.
Zum einen erhöht es die Zuverlässigkeit, da nur wenige Prozesse kontrollierenden Zugriff auf
Daten haben und diese nicht über viele Anwendungen gestreut werden. Außerdem sichert es
die Integrität, da sich das Regelwerk für die Behandlung der Daten an einer zentralen Stelle
im Kommunikationsprozess, nämlich dem Server, befindet. Des Weiteren bietet es erhebliche
Verbesserungen
bezüglich
der
Sicherheit,
da
in
der
Regel
nur
eine
Kommunikationsverbindung zwischen Client und Server besteht. Dadurch wird die Zahl der
Angriffsziele verringert. Außerdem lassen sich an Servern stärkere Sicherheitsverfahren
anwenden, als es an einem Client möglich wäre. Nicht zuletzt ist das Modell der Leistung des
Gesamtsystems dienlich, da zwischen Client und Server eine Arbeitsteilung stattfindet. Der
Server nimmt dem Client Rechenarbeit ab und präsentiert nur Ergebnisse, die der Client im
Anschluss weiterverarbeiten kann. Außerdem bieten Server auf ihr Anwendungsgebiet
zugeschnittene Hardware sowie Cachingmethoden, die Daten für einen schnellen Abruf bereit
halten. Die Kommunikation der Clients mit dem Server bringt aufgrund der Sterntopologie
auch eine verringerte Netzlast mit sich, da die Kommunikation nur über einen zentralen Punkt
stattfindet.
In die Kommunikation zwischen Client und Server sind serverseitig meist zusätzlich Prozesse
geschaltet, die so genannten Tiers. Sie bilden eine Kombination aus einer Abstraktionsschicht
und einem Regelwerk und haben die Möglichkeit, die bestehende Verbindungen einzugreifen
und diese in bestimmten Situationen umzuleiten. Das ist beispielsweise im Falle eines
Failovers notwendig, um die Verbindungen der Clients im Fehlerfall sauber auf einen anderen
Server umzulenken.
2.3.2 Neuerungen beim SQL Server
Neben der standardmäßigen Unterstützung des Client-Server-Modells wagt Microsoft mit
dem SQL Server die Orientierung in Richtung einer Service Oriented Architecture (SOA).
Diese Technologie für den Zugriff auf den Datenbankserver basiert auf einer standardisierten
Abstraktionsschicht, die der Server verwendet, um mit anderen Anwendungen zu
kommunizieren. Sie beruht auf der Kommunikation über Standard-HTTP-Calls, wodurch die
Datenübertragung über XML, SOAP oder andere Webservices möglich wird.
6 Der SQL Server unterstützt im Speziellen ServeXML für die Erstellung von Data Stores und
bietet darüber hinaus die Möglichkeit ServeXML- und XSLT-Code direkt an einen Browser
zu versenden. Des Weiteren unterstützt die Datenbankengine queryXML sowie Store-, Insertund BulkInsert-Befehle.
Die Technologie erleichtert die Entwicklung von Datenbankapplikationen ungemein, da
Funktionen direkt auf dem Server angesprochen werden können und Daten dank XML in
einer für die Anwendung sofort verwertbaren Form vorliegen. Die Erleichterungen bringen
jedoch auch Nachteile mit sich. Das Hauptproblem liegt in der zusätzlichen
Abstraktionsschicht, die Daten beim Transfer über mehrere Schichten für jede Schicht
übersetzen muss. Das führt zu Performanceeinbußen.
Trotzdem lässt sich sagen, dass die Entwicklung hin zu einer serviceorientierten Architektur
viele Möglichkeiten in sich birgt und auch in der Zukunft von Bedeutung sein wird, speziell
für die zunehmenden Entwicklungen im Bereich der .NET-Programmierung.
2.4 Instanzen
Jedes Datenbanksystem verwendet für den Datenbankzugriff so genannte Instanzen. Dabei
handelt es sich um Konstrukte auf dem Server, die es Benutzern oder Applikationen erlauben,
mit dem Datenbankserver zu interagieren. Je nach verwendetem Datenbanksystem können
Instanzen unterschiedlicher Gestalt sein. So verwendet das Datenbanksystem IDS
beispielsweise Threads, Oracle und auch der SQL Server arbeiten prozessbasiert.
Sowohl Oracle als auch der SQL Server haben diesbezüglich einige Gemeinsamkeiten. So
verfügen beide Systeme über Mechanismen, die Prozessen eine gemeinsame Speichernutzung
und Puffer zum Austausch von Informationen ermöglichen. Prozesse zur Protokollierung
sowie Mechanismen für das Vorauslesen von Daten gehören ebenfalls zur Kernfunktionalität
beider Systeme.
2.4.1 Instanzen in Oracle
Instanzen bestehen in Oracle aus bestimmten Speicherstrukturen, die auch als System Global
Area (SGA) bezeichnet werden, und einer Reihe von Hintergrundprozessen. Dabei kann eine
Instanz immer nur mit einer Datenbank verknüpft sein. Es ist jedoch möglich, dass eine
Datenbank an mehreren Instanzen beteiligt ist.
Alle Prozesse, die an einer Instanz beteiligt sind, teilen sich die SGA. Oracle unterscheidet
zwei Arten von Prozessen: dedizierte Prozesse und gemeinsame Serverprozesse.
Charakteristisch für dedizierte Prozesse ist, dass sie zur Steuerung nur einer Verbindung zur
Datenbank verantwortlich sind. Diese Vorgehensweise eignet sich gut zur parallelen
Verarbeitung, birgt jedoch auch einige Nachteile in sich. So ist Oracle auf eine maximale
Anzahl an ausführbaren Prozessen festgelegt. Diese Grenze legt der Administrator der
Datenbank systemweit fest. Ist diese Schranke zu hoch bemessen, kann es zu einer
Überlastung des Systems kommen, wodurch die Verfügbarkeit des Systems beeinträchtigt
werden kann. Dieser Effekt wird dadurch verstärkt, dass der Wechsel zwischen Prozessen auf
Betriebssystemebene weniger performant ist, als es beispielsweise bei der Verwendung von
Threads der Fall wäre.
7 Um dieses Problem einzudämmen, gibt es in Oracle die Möglichkeit der Verwendung von
gemeinsamen Serverprozessen. Diese sind frei konfigurierbar und können dynamisch zu- und
abgeschalten werden. Sie können mehrere Anfragen entgegennehmen und diese verarbeiten.
Dazu wird ein so genannter Dispatcher verwendet. Er nimmt die Anfrage entgegen und reiht
sie in eine Anforderungswarteschlange ein. Dort wird sie vom nächsten verfügbaren Prozess
entgegengenommen und verarbeitet. Das Ergebnis der Anfrage wird in eine
Antwortwarteschlange eingereiht und wieder an den Dispatcher übergeben, der es an den
Adressaten weiterleitet.
Diese Methode arbeitet sequentiell und kann daher gut zur Stapelverarbeitung verwendet
werden. Dadurch sinkt in Konsequenz aber auch der Grad an möglicher Parallelität. Es gilt
also Anhand der verwendeten Applikationen abzuwiegen, welcher Methode in einem
bestimmten Fall der Vorzug gegeben werden soll.
2.4.2 Instanzen in SQL Server
Der SQL Server arbeitet ebenfalls prozessbasiert und kennt zwei Arten von Instanzen: die
Standardinstanz und benannte Instanzen. Auf einem physischen Server ist es möglich, bis zu
50 Instanzen parallel auszuführen. Wird der Server in einem Failover-Cluster betrieben, so
können 25 Instanzen ausgeführt werden. Die Instanzen arbeiten voneinander unabhängig und
können mit mehreren Datenbanken verknüpft sein. Es kann jedoch nur eine Standardinstanz
pro Server geben.
Eine Instanz besteht im SQL Server neben Speicherstrukturen und verarbeitenden Diensten
aus einer Reihe von zusätzlichen Komponenten, die die Anfrageverarbeitung unterstützen.
Für das Vorauslesen und effiziente Caching von Daten ist der Buffer Manager zuständig. Er
hält häufig benötigte Datenseiten im Cache. Für das Rückschreiben modifizierter Datenseiten
auf die Platte ist der so genannte Lazy Writer zuständig. Um Anfragen zu verbessern gibt es
den Query Optimizer. Er untersucht die zu verarbeitenden Anfragen und versucht sie
gegebenenfalls in eine performantere Form zu bringen. Für eine zusätzliche Optimierung des
Caches ist der Resource Monitor zuständig. Seine Aufgabe ist es, für die Abarbeitung des
Query-Plan s möglichst effizient Datenseiten zu cachen. Dabei werden spezielle intelligente
Algorithmen verwendet, die die zur Verfügung stehenden Ressourcen optimal nutzen sollen.
Des Weiteren gibt es noch den Lock Manager, der sich um die Verwaltung und Vergabe von
Sperren für Transaktionen kümmert.
Microsoft spielt im Kern der Datenbankengine seinen Vorteil aus, der Entwickler des
Betriebssystems zu sein, auf dem der SQL Server läuft. Für den Zugriff auf die Hardware
muss der SQL Server nicht den Umweg über die Abstraktionsschicht des Betriebssystems
gehen, da er seine eigene Abstraktionsschicht namens SQLOS besitzt. Dadurch können die
verfügbaren Ressourcen optimal an die arbeitenden Prozesse zugeteilt werden, ohne dabei
einen nennenswerten Overhead zu erzeugen.
2.5 SQL Standards und Spracherweiterungen
Da SQL als Anfragesprache weitestgehend standardisiert ist, finden sich in der Syntax des
umgesetzten Standards nur geringe Unterschiede bei beiden Systemen. Oracle 10g unterstützt
den ANSI SQL 2003-Standard und bietet daher einige spezielle Funktionen mehr als der SQL
8 Server 2005, der den ANSI SQL 1999-Standard umsetzt. Das betrifft beispielsweise die
Erstellung von verschachtelten Tabellen.
Um datenbankspezifische Funktionen verwenden zu können, verfügen beide Systeme über
eine prozedurale Spracherweiterung des SQL-Standards. Oracle nennt seine Erweiterung
Procedural Language/SQL (PL/SQL), die des SQL Servers heißt Transact-SQL (T-SQL).
Dadurch wird beispielsweise die Erstellung von Server-Variablen und Cursorn, die
Verwendung von Programmkonstrukten wie der Verzweigung (IF…THEN…ELSE) und der
Schleife (WHILE, FOR,…) sowie die Definition von Triggern möglich.
Oracle bietet in PL/SQL darüber hinaus die Möglichkeit, Pakete über „CREATE PACKAGE
xyz“ zu erstellen und Typen zu deklarieren, beispielsweise über „DECLARE gewinn
NUMBER(6,2)“. Des Weiteren ist es in PL/SQL möglich mittels „FOR…END LOOP“
beziehungsweise „LOOP…END LOOP“ eine Schleifenkontrolle zu realisieren.
2.6 Sperren und Nebenläufigkeit
Der Grad an Nebenläufigkeit, den ein Datenbanksystem realisieren kann, ist von vielen
Faktoren abhängig. Zum Einen kommt es darauf an, auf welcher Grundlage das System
Datenbankinstanzen erstellt und verwaltet (Vergleich Kapitel 1.4), zum Anderen wie die
Datenbank physisch organisiert ist. Das betrifft vor allem den Bereich der Tabellen- und
Indexorganisation. Ein weiterer wichtiger Punkt ist die Fähigkeit des Systems,
konkurrierende, also nebenläufige, Anfragen zu verarbeiten. Dafür sind die zu Grunde
liegenden Sperrkonzepte von hoher Bedeutung.
2.6.1 Sperrkonzepte in Oracle
Oracle verfügt sowohl über automatische, als auch über manuelle Sperren. Verlangt eine
Anfrage nicht explizit eine manuelle Sperre, so übernimmt das System die Anforderung von
Sperren. Das Interessante an den automatischen Sperren ist, dass Oracle keine Lesesperren
vergibt. Somit können Transaktionen, die lediglich Daten Lesen wollen, parallel au dieselben
Daten zugreifen. Sollen Daten durch eine Transaktion geändert werden, so vergibt Oracle
entweder eine ROW EXCLUSIV-Sperre, wenn nur bestimmte Tabellenzeilen von der
Änderung betroffen sind, beziehungsweise EXCLUSIV-Sperren, wenn ganze Tabellen
gesperrt werden müssen.
Manuelle Sperren können differenzierter angewendet werden. Auch hier unterscheidet man
zwischen Sperren auf Zeilenebene und Sperren auf Tabellenebene. Will man Tabellen für den
schreibenden Zugriff anderer Transaktionen sperren, das Lesen der Daten jedoch erlauben, so
kann man die Sperre „Shared“ anfordern. Will man auch das Lesen unterbinden, so ist die
Sperre „Exclusiv“ das Mittel der Wahl.
Für das manuelle Sperren auf Zeilenebene gibt es zum Einen die Sperre „Row Share“, mit der
der lesende Zugriff für andere Transaktionen gewährt, der schreibende jedoch blockiert wird.
Es ist anderen Transaktionen außerdem nicht möglich, eine „Exclusiv“-Sperre der ganzen
Tabelle anzufordern. Verwendet man für eine Tabellenzeile die „Row Exclusiv“-Sperre, so
unterbindet man zusätzlich auch „Shared“-Sperren anderer Transaktionen. Noch einen Schritt
weiter geht die „Share Row Exclusiv“-Sperre, die zusätzlich auch Updates auf Daten
verhindert.
9 Das Sperrkonzept von Oracle hat die Eigenschaft, dass Lesesperren Schreibsperren nicht
blockieren. Das wird dadurch ermöglicht, dass Oracle UNDO-Segmente für das Sichern von
Daten vor einem Update vornimmt. Siehe dazu auch Kapitel 1.7 Lesekonsistenz.
2.6.2 Sperrkonzepte in SQL Server
Auch der SQL Server verfügt über automatische Sperrmodule. Im Gegensatz zu Oracle
vergibt der SQL Server jedoch auch Sperren für lesende Zugriffe, beispielsweise für
„SELECT“-Statements. Die zugehörige Sperre heißt „Shared“. Sollen Datensätze aktualisiert
werden, so verwendet SQL Server „Update“-Sperren. Für „INSERT“- und „DELETE“Statements werden „Exclusive“-Sperren vergeben. Für den Anwendungsfall, dass eine große
Menge an Daten in eine Tabelle kopiert werden soll, kennt SQL Server die „Bulk-Update“Sperre.
Außerdem gibt es für Änderungen die DDL betreffend die so genannte „Schema“-Sperre. Sie
findet zum Beispiel bei Hinzufügen oder Entfernen von Tabellenspalten Anwendung. Für
Bereichsanfragen, die nur einen bestimmten Schlüsselbereich betreffen, besteht die
Möglichkeit der Vergabe einer „Schlüsselbereich“-Sperre.
Neben den automatischen Sperren gibt es im SQL Server noch die beabsichtigten Sperren. Sie
dienen dazu, Sperren untergeordneter Ebenen vor Datenänderungen durch Sperren
übergeordneter Ebenen zu unterbinden. Somit dienen beabsichtigte Sperren dem effizienteren
Erkennen von Sperrkonflikten.
So schützt die IS-Sperre (Intended Shared) S-Sperren niederer Hierarchieebenen und die IXSperre (Intended Exclusive) X-Sperren niederer Ebenen. Dabei ist anzumerken, dass die IXSperren eine Obermenge der IS-Sperren bilden und somit auch S-Sperren schützen. Um SSperren und IX-Sperren schützen zu können, werden SIX-Sperren (Shared Intended
Exlcusive) verwendet.
Mit der IU-Sperre (Intended Update) lassen sich Sperren vor Aktualisierungssperren
schützen. Die SIU-Sperre (Shared Intended Update) stellt eine Kombination der S- und der
IU-Sperre dar und entsteht durch die separate Einrichtung dieser beiden Sperren. In Analogie
zu dieser Sperre gibt es noch die UIX-Sperren (Update Intended Exlcusive), die ebenfalls
durch die separate Einrichtung einer U- und einer IX-Sperre entsteht.
2.7 Lesekonsistenz
Konsistenz ist eines der Grundprinzipien relationaler Datenbanksysteme. Lesekonsistenz
beschreibt dabei einen speziellen Sachverhalt. So stellt sich die Frage, auf welche Version
eines Datenbestandes Transaktionen zugreifen. Das ist besonders dann von großem Interesse,
wenn lang laufende Transaktionen auf Daten lesend zugreifen wollen, die zwischenzeitlich
von anderen Transaktionen geändert wurden. Oracle und SQL Server verwenden hier
unterschiedliche Ansätze, um dem Problem Herr zu werden.
2.7.1 Lesekonsistenz in Oracle
Lesekonsistenz ist in Oracle ein transparenter Vorgang, der vom System automatisch
durchgeführt wird. Sie wird über UNDO-Segmente gesichert, die vor jedem Update eines
Datensatzes angelegt werden. Ist eine Transaktion dabei, einen Datensatz zu ändern, so wird
10 er vom System für andere Transaktionen sichtbar als in Bearbeitung stehend gekennzeichnet.
Wollen andere Transaktionen diesen Datensatz lesen, so werden sie automatisch auf den
letzen Eintrag in den Undo-Segmenten umgeleitet. Ist die bearbeitende Transaktion beendet,
so wird der Datensatz mit einem Zeitstempel versehen (SCN). Dadurch wird ein Vergleich für
andere laufende Transaktionen ermöglicht und sie können anhand ihrer Startzeit erkennen, ob
ein Datensatz zu ihrer Laufzeit von anderen Transaktionen geändert wurde.
2.7.2 Lesekonsistenz in SQL Server
Der SQL Server wendet zur Sicherung der Lesekonsistenz die so genannte „HOLDLOCK“Funktion an. Diese fordert gleichzeitig eine „Shared“-Sperre an und ermöglicht dadurch
mehreren Transaktionen gleichzeitig einen Datensatz zu lesen. Will eine Transaktion jedoch
ein Update auf einen diese „Shared“-Sperre betreffenden Datensatz ausführen, so wird sie so
lange blockiert, bis alle an der Sperre beteiligten Transaktionen ein COMMIT ausgeführt
haben.
Um die Nebenläufigkeit von Transaktionen zu erhöhen bietet SQL Server eine Reihe
verschiedener Isolationsstufen (Isolation Levels) für Transaktionen an. Die schwächste Stufe
ist „Read Uncommitted“. Eine aktuell laufende Transaktion darf Daten, auf denen gerade ein
Update durch eine andere Transaktion stattfindet bereits vor dem COMMIT der Transaktion
lesen. Der Level „Read Committed“ setzt für das Lesen solcher Daten ein COMMIT der
laufenden Transaktion voraus. Dieses Vorgehen verhindert das Auftreten von Dirty Reads.
Die Tatsache, dass andere Transaktionen zwischen den einzelnen Anweisung de laufenden
Transaktion allerdings Daten ändern dürfen, kann unter Umständen zu Non-Repeatable Reads
und Phantom Reads führen. Der Level „Repeatable Read“ verschärft dieses Prinzip
dahingehend, dass die laufende Transaktion komplett abgeschlossen sein muss, bevor andere
Transaktionen geänderte Daten lesen können. Der Level „Serializable“ schützt darüber hinaus
auch Schlüsselbereiche laufender Transaktionen, Bis zum Abschluss der laufenden
Transaktion dürfen keine neuen Schlüssel in die Transaktion betreffende Schlüsselbereiche
eingefügt werden.
Der ebenfalls in der Version 2005 neu eingeführte Level „Snapshot“ implementiert eine
ähnliche Funktionalität wie die Sperrkonzepte anderer Datenbanksysteme, die mit einer
Zeilenversionierung arbeiten. Dabei sind für eine Transaktion zum Zeitpunkt ihres Beginns
nur jene Änderungen von Datensätzen sichtbar, für die bis dahin auch ein COMMIT
ausgeführt wurde. Diese Methodik wird auch als „Optimistic Locking“ bezeichnet.
2.8 Partitionierung
Im Bereich der Partitionierung von Tabellen bieten beide Datenbanksysteme Lösungen an.
Das Prinzip ist bei beiden gleich. Tabellen, oft auch Indizes, werden anhand bestimmter
Kriterien in verschiedene Partitionen aufgeteilt und gespeichert. Es ist prinzipiell auch nicht
von Bedeutung, auf welchem Medium die Partitionen liegen. Dadurch wird die physische
Datenunabhängigkeit verbessert. Die Vorteile der Partitionierung liegen aber vor allem im
Performancegewinn.
Unter der Voraussetzung, dass der Index einer Tabelle ebenfalls partitioniert wird, muss bei
einer Reorganisation eines Indexes nur der die Partition betreffende Index reorganisiert
11 werden. Das senkt die Systemlast erheblich. Dasselbe gilt für eine Defragmentierung von
Indizes. Der wohl signifikanteste Vorteil liegt allerdings darin, dass der Datenbankserver in
der Arbeit mit partitionierten Tabellen parallele CPU-Operationen nutzen kann. Es ist jedoch
anzumerken, dass der Performancegewinn häufig erst dann zu Tage tritt, wenn man mit sehr
großen Tabellen arbeitet, die mit mehreren Millionen von Zeilen beinhalten.
Außerdem wird das Management der Datenbank vereinfacht, da einzelne Partitionen für
Wartungszwecke offline genommen werden können, während andere Partitionen verfügbar
bleiben. Es muss also nicht die gesamte Tabelle offline genommen werden.
Es muss jedoch, um die Vorteile der Partitionierung zu nutzen, ein anhand bestimmter
Kriterien analysierbarer Datenbestand vorliegen. Die Analyseergebnisse müssen sich auch in
ein vom Datenbanksystem angebotenen passendes Verfahren umsetzen lassen.
2.8.1 Partitionierung in Oracle
Seit Oracle8 gehört die Partitionierung zum Funktionsumfang von Oracle. In der Version 10g
ist die Partitionierung jedoch nur der Enterprise Edition vorbehalten. Oracle stellt
verschiedene Partitionierungsverfahren zur Verfügung.
Die Bereichspartitionierung ermöglicht das Aufteilen von Tabellen iin Schlüsselbereiche
anhand bestimmter Kriterien. Im Gegensatz dazu ermöglicht es die Hash-Partitionierung, die
Daten mit Hilfe einer speziellen Hash-Funktion auf die Partitionen zu verteilen. Dadurch kann
eine Gleichverteilung der Daten erreicht werden. Beide Verfahren lassen sich auch
kombinieren, indem man Hash-Partitionen in bestimmten Bereichspartitionen erstellt. Dieses
Verfahren wird als kombinierte Partitionierung bezeichnet. Seit Oracle 9i wird auch die
Listenpartitionierung angeboten, mit deren Hilfe sich Daten anhand diskreter Werte, wie zum
Beispiel geographische Daten, auf Partitionen aufteilen lassen.
2.8.2 Partitionierung in SQL Server
Die Partitionierung im SQL Server erfolgt über die Erstellung einer Partitionierungsfunktion,
der Festlegung eine Partitionsschemas, der Erstellung der Tabelle und der anschließenden
Erstellung eines geclusterten Indexes, der die Partitionierungsfunktion und das
Partitionsschema berücksichtigt.
Die Partitionierungsfunktion ist dabei dafür zuständig, die Bereiche zu definieren, in die die
Daten aufgeteilt werden sollen. Der SQL Server beschränkt sich dabei auf die
Bereichspartitionierung, Es lässt sich mittels einiger Workarounds aber eine HashPartitionierung simulieren. Das Partitionierungsschema baut auf der Partitionierungsfunktion
auf und legt den physischen Speicherort für die Datenbereiche fest. Die Partitionen können
alle in derselben Dateigruppe untergebracht oder auf verschiedene Dateigruppen verteilt
werden. Dabei können mehrere Partitionsschemata dieselbe Partitionierungsfunktion
benutzen. Die im Anschluss zu erstellende Tabelle muss einen ungeclusterten Primärschlüssel
haben, der auf die Tabelle gelegte Index muss geclustert sein.
2.9 Verfügbarkeit und Skalierbarkeit
Um die Verfügbarkeit von Datenbanksystemen zu erhöhen gibt es die Möglichkeit des
Clusterings. Ein solcher Cluster erlaubt es mehreren physischen Servern als ein virtueller
12 Server in Erscheinung zu treten. Fällt ein physischer Server aus, wird seine Funktionalität
durch andere Server des Verbundes ersetzt. Oftmals implementieren die Cluster ein
Plattensystem, mit dem jeder Clusterknoten üblicherweise über SCSI oder optische Medien
verbunden ist.
2.9.1 Verfügbarkeit und Skalierbarkeit in Oracle
Oracle bietet schon seit längerem umfangreiche Features für Hochverfügbarkeitslösungen an.
Für die einfache Schaffung von Redundanz gibt es „Oracle Fail Safe“. An dem Konzept sind
zwei Maschinen beteiligt, die sich jedoch nicht in einer Shared-Disk-Umgebung befinden.
Die erste Maschine stellt läuft als aktiver Datenbankserver, die zweite Maschine hat einen
Standby-Zugriff auf die Daten.
Weiterführende Funktionalität wie echte Clusterunterstützung und Skalierbarkeit bietet
„Oracle Real Application Cluster“ (RAC). Die Funktionalität ist nicht neu, sie basiert auf dem
in Oracle 10g abgelösten Feature „Oracle Parallel Server“ (OPS). RAC ist in der Lage, die
Rechenleistung der einzelnen Clusterknoten zu bündeln und dem Gesamtsystem zur
Verfügung zu stellen.
Die Herausforderung liegt dabei in der Kommunikation zwischen den Clusterknoten. Neben
der Verwendung einer Shared-Disk-Umgebung ür den Zugriff gemeinsame Daten ist auch die
gemeinsame Nutzung von Daten im RAM notwendig, um häufige Plattenzugriffe zu
verhindern und damit die I/O-Last zu senken. Letzteres war eine Schwachstelle von OPS, die
im RAC beseitigt wurde. RAC nutzt „Cache Fusion“, um Clusterknoten Daten zur
Verfügung zu stellen, die sich im Cache eines anderen Clusterknotens befinden. Beim
abgelösten OPS mussten dafür noch die Daten zuerst auf Platte geschrieben werden, bevor ein
anderer Knoten sie lesen konnte (Pinging), Cache Fusion ist in der Lage, angeforderte Blöcke
im Cache des einen Knotens via Highspeed-Interconnect direkt in den Cache des anderen
Knoten zu übertragen.
Neben dem Performancegewinn bietet der RAC auch eine Failover-Funktion für jeden
Knoten im Cluster. Da sich alleMaschinen dieselben Ressourcen verwenden kann ein
Umleiten von Verbindungen im Falle eines Serverausfalls problemlaos erfolgen.
2.9.2 Verfügbarkeit im SQL Server
Der SQL Server stellt im Bereich der Hochverfügbarkeit die Funktionalität der Failover
Server durch Clustering bereit. Im Speziellen realisiert wird das Clustering durch den
Windows Cluster Server, also auf Betriebssystemebene. Um einen SQL Cluster zu erstellen,
muss man also zuerst einen Windows Cluster erstellen und auf diesem dann ganz normal den
SQL Server installieren. Es ist wichtig zu erwähnen, dass der SQL Server Cluster lediglich
Redundanz, nicht aber Skalierbarkeit zur Verfügung stellt. Er agiert als reiner Failover
Cluster.
Jeder Server im Cluster kann entweder aktiv oder passiv sein. Die Menge der passiven Server
bietet die Redundanz für die Menge der aktiven Server. Ist ein aktiver Server von einem
Ausfall betroffen, wechselt ein passiver Server in den Aktiv-Modus und übernimmt den
Status des ausgefallenen Servers anhand des gemeinsamen Transaktionsprotokolls und der
Datendateien. Der Benutzer bekommt davon wenig mit, er bemerkt lediglich eine verlorene
13 Verbindung. Ist die Anwendung für den Clusterbetrieb konzipiert, so bemerkt sie den Ausfall
und initiiert die Verbindung neu.
3. Verwaltbarkeit
Die Verwaltbarkeit von Datenbanksystemen spielt angesichts des meist immensen
Funktionsumfangs heutiger Datenbanksysteme eine enorm wichtige Rolle. Sie ist
entscheidend für schnelles Handeln der Administratoren, die Effizienz von
Entwicklungsprozessen sowie für Aspekte der Skalierbarkeit und Sicherheit.
Kennzeichnend für Oracle und den SQL Server ist, dass versucht wird, alle wichtigen
Werkzeuge zur Verwaltung in zentralen Umgebungen zu bündeln.
3.2 Verwaltung des SQL Server
Seit der letzten Version SQL Server 2000 haben sich zahlreiche Änderungen im Bereich der
Verwaltung des SQL Servers ergeben. Die Version 2005 führt das SQL Server Management
Studio (SSMS) ein, das die zentrale Verwaltungskonsole des SQL Servers darstellt und den
Enterprise Manager des SQL Server 2000 ablöst. Das Layout des SSMS ist an das Visual
Studio angelehnt und bietet Zugriff auf die Datenbankengine und auf Business IntelligenceDienste (siehe Kapitel 3.2) wie die Integration Services, die Analysis Services und die
Reporting Services. Außerdem verfügt es über eine Projektverwaltung, Query-Editoren und
eine Anbindung an SourceSafe.
Zur Überwachung der Aktivitäten der Datenbankengine gibt es den „Profiler“. Er liefert
Ausführungszeiten von Anfragen und Daten über die I/O-Last. Die ermittelten Werte können
an Monitoring-.Mechanismen von Windows weitergegeben werden.
Der „Tuning Advisor“ überwacht SQL-Anfragen und erkennt selbständig lang laufende
Transaktionen und bietet Verbesserungsvorschläge bezüglich der Anfrageoptimierung. Diese
betreffen die Änderung von Datenstrukturen, die Datenverteilung auf den physischen
Datenträgern, die Einführung von Indizes sowie Partitionierungsvorschläge.
Mit Hilfe des „Activity Monitors“ lassen sich Benutzersitzungen protokollieren und
analysieren. Er bietet umfangreiche Filteroptionen, eine Sperrenanalyse und unterstützt beim
Aufspüren von Deadlocks.
Über den „Configuration Manager“ lassen sich alle Dienste des SQL Servers verwalten und
viele weitere Parameter einstellen, beispielsweise die Verwaltung sämtlicher
Netzwerkeinstellungen.
Die Shell des SQL Servers bildet SQLCMD, die osql/Isql ablöst. Sie arbeitet über die
Datenbankschnittstelle OLE DB und ermöglicht nun auch dedizierte Verbindungen mit der
Datenbank. Dafür werden im Vorfeld Systemressourcen reserviert, um Administratoren im
Fehlerfall das Eingreifen zu ermöglichen.
3.1 Verwaltung von Oracle
Die zentrale Stelle zur Verwaltung von Oracle ist der „Enterprise Manager“. Er besteht aus
verschiedenen Management-Agents, die es für nahezu alle verfügbaren Betriebssysteme gibt.
14 Weitere Bestandteile ist die „Central Console“, der „Oracle Management Service“ (OMS) und
das „Management-Knowledge Center“ (MKC).
Die zentrale Oberfläche für den Enterprise Manager bildet eine HTML-Oberfläche, die die
Verwaltung zentraler Funktionen wie Backup und Recovery, Export und Import, Instanzen,
Schemata, RAC, OLAP, Data Guard und zahlreicher Sicherheitseinstellungen wie Benutzer,
Rollen und Zugriffsrechte ermöglicht. Ebenfalls über das Webinterface zu erreichen ist iSQL,
eine Java-basierte SQL-Konsole, die neben typischen SQL-Anfragen auch die Einstellung
zahlreicher Datenbankparameter ermöglicht.
Zum Funktionsumfang des Enterprise Managers gehören noch optionale Komponenten,
oftmals auch „Option Packs“ genannt. So erlaubt die „Database Diagnostics Option“ das
Monitoring lokaler und verteilter Datenbanken und hilft dabei, Flaschenhälse der
Datenverarbeitung zu entdecken. Zum Umfang der Option gehören auch einige Tools zur
Problembehebung. Für das Monitoring des Oracle Application Servers ist die „Application
Server Diagnostics Option“ zuständig. Mit Hilfe der „Database Tuning Option“ lassen sich
Transaktionen überwachen und Anfragen optimieren. Über die „Database Change
Management Option“ lassen sich Änderungen an den Datenbankschemata evaluieren und
implementieren. Die „Database Configuration Management Option“ ermöglicht die
Hardware- und Softwareverwaltung des Datenbanksystems sowie eine Patchverwaltung und
Replikationseinstellungen.
4. Data Warehouse und Applikationsentwicklung
Der Bereich des Data Warehousing beschäftigt sich mit der Analyse großer Datenmengen, um
daraus Schlüsse ziehen zu können. Das betrifft zum Beispiel Vergangenheitsanalysen,
Zukunftsprognosen und die daraus resultierende Entwicklung von Verfahren zur
Geschäftsoptimierung.
Die dabei verwendeten Systeme müssen dafür in der Lage sein, große Mengen an Daten
aufzuzeichnen und verlässlich zu speichern. Des Weiteren ist eine konsistente Sicht auf die
Daten notwendig, um im laufenden Betrieb Daten lesen und Berichte erstellen zu können.
Spezielle Analysemethoden ermöglichen die Erstellung von Geschäftstrends. Erreicht wird
das über die Erstellung von Zusammenfassungen und deren gegenseitige Verknüpfung.
Typisch für Data Warehouse-Prozesse ist die strategische Analyse von Trends über einen
großen Datenbestand, weniger das Sammeln von einzelnen Fakten. Außerdem wird auf
Datenbestände, die sich in einem Data Warehouse befinden, meist lesend zugegriffen. Es gibt
seltener Updates auf die Daten. Ein weiterer wichtiger Punkt ist der Fakt, dass die
analysierten Daten nicht zwangsläufig sekundengenaue Aktualität benötigen, da die für Data
Warehouse typischen Anwendungszwecke meist nur Daten eines bestimmten Kriteriums
benötigen, seltener Daten in Echtzeit.
4.1 Data Warehouse in Oracle
Oracle engagiert sich bereits seit längerem im Bereich des Data Warhousing und bietet
umfassende Konzepte zur Erstellung, Verwaltung und Nutzung von Warehouses an. Für die
Datenverwaltung in einem Data Warehouse werden Tabellen nach dem so genannten „StarSchema“ angelegt. Dises ist notwendig, um den Ansprüchen gerecht zu werden, die ein Data
15 Warehouse benötigt und die Performance zu steigern. Der übliche Ansatz der
Datenmodellierung über das Entity Relationship Modell ist dafür ungeeignet, da Warehousetypische Anfragen sich meist über mehrere inhaltliche Bereiche, auch Dimensionen genannt,
erstrecken und damit zu einer hohen Join-Last des ER-modellierten Systems führen würden.
Im Zentrum des Star-Schemas steht die Faktentabelle. Sie enthält zusammenfassende Daten,
die sich je nach dem Anwendungsszenario des Data Warehouses unterscheiden können. Es
können auch mehrere Faktentabellen existieren. Umgeben wird die Faktentabelle von
mehreren Dimensionstabellen, die meist bereichsspezifische Informationen beinhalten. Das
können beispielsweise Informationen über Verkäufe, Abteilungen, räumliche Informationen
oder Zeiträume sein.
Die Daten der Dimensionstabellen werden je nach Anwendungszweck kombiniert und
umgeformt und in entsprechender Form in die Faktentabelle ausgeleitet. Redundanz wird hier
durchaus in Kauf genommen, da der alleinige Zugriff der Warehouse-Benutzer auf die
Faktentabelle unnötige Joins der Dimensionstabellen unterbindet.
4.1.1 Oracle Data Warehouse Builder
Es gibt verschiedene Wege, um Warehouses zu erstellen und zu verwalten. Eine Möglichkeit
wäre die Benutzung von PL/SQL. Oracle stellt aber auch einige Werkzeuge für diesen
Entwicklungsprozess zur Verfügung.
Im Zentrum steht dabei der „Oracle Warehouse Builder“ (OWB). Er ist wie viele andere
Werkzeuge Bestandteil der Oracle Developer Suite und ermöglicht das Design und die
Implementierung von Data Warehouses, Data Marts oder Business IntelligenceAnwendungen. Warehouse-Schemata können zentral verwaltet und der Datenfluss zwischen
Datenquellen- und Senken kontrolliert werden. Des Weiteren lassen sich mit dem OWB
OLAP- und Ad-Hoc-Query-Umgebungen entwickeln. Der gesamte Implementierungsprozess
wird dabei an zentraler Stelle überwacht.
Zur Arbeit mit dem OWB gibt es den OWB-Client, der die Schnittstelle zwischen dem OWB
und dem Entwickler darstellt und auf die Funktionalitäten des OWB zugreift. Die im OWb
erstellten Modelle lassen sich mit Hilfe des Code Generators in Skripte umsetzen, die dann
auf den Daten ausgeführt werden können. Änderungen in den Warehouse-Schemata lassen
sich einfach im OWB vornehmen und durch den automatisch erzeugten Code schnell
implementieren.
4.1.2 Oracle Discoverer
Der Discoverer übernimmt die Aufgabe, Anfragen an das Warheouse abzusetzen und Berichte
zu erstellen. Er ist vorrangig für Endbenutzer gedacht und existiert in vier verschiedenen
Varianten. Zum einen gibt es die Variante „Administrator“. Sie ist dem Namen entsprechend
Administratoren und Power Usern vorbehalten und dient Ihnen dazu, den Benutzern
Discoverer-Umgebungen zu erstellen. Das erfolgt bequem über grafische Oberflächen. Die
Variante „Desktop“ ist für Endbenutzer gedacht un erlaubt diesen ein einfaches und schnelles
Arbeiten mit Daten und Berichten aus dem Data Warehouse.
16 Die Varianten „Administrator“ und „Desktop“ sind echte Desktop-Applikationen,
wohingegen die Varianten „Plus“ und „Viewer“ Webapplikationen darstellen, die auch
einfach über einen normalen Webbrowser genutzt werden können. Dabei stellt „Plus“ eine
webbasierte Erweiterung zu „Desktop“ dar, „Viewer“ bietet dem Nutzer vordefinierte Sichten
auf Berichte, ohne dass Änderungen an den Daten vorgenommen werden können.
Durch eine enge Interaktion des Discoverers mit „Oracle Portal“ ist es möglich, Webseiten zu
erstellen, die direkten Zugriff auf die Berichte des Discoverers haben.
4.1.3 Oracle Reports
Oracle Reports dient ebenso wie Oracle Discoverer zur Erstellung von Berichten. Nur bietet
er eine breitere Unterstützung für Datenquellen und Ausgabeformate.
So lassen sich Daten aus Oracle Datenbanken, Oracle Express, OLAP-Umgebungen, XMLDokumenten, über die JDBC-Schnittstelle oder Textdateien akquirieren. Für die
Berichterstellung bietet Oracle Reports die Möglichkeit, Templates zu verwenden oder auch
eigene Templates zu erstellen. Dabei ist der Integration von Medien wie Diagrammen,
Bildern und ähnlichem kaum Grenzen gesetzt.
Die Ausgabeformate sind ebenfalls sehr vielfältig. Zu diesen Zählen der Versand über Email,
die Erstellung von Dateien beispielsweise im PDF-Format, das Versenden an Drucker und
nicht zuletzt die Erstellung von HTML-Seiten. Im Web-Bereich bietet Oracle Reports auch
Unterstützung für die Skriptsprache JSP. Des Weiteren lassen sich erstellte Webseiten in
Oracle Portal publizieren.
4.2 Data Warehouse in SQL Server
4.2.1 SQL Server und das .NET-Framework
Das neue am SQL Server 2005 ist die Integration der Common Language Runtime in den
Kern des Datenbanksystems. Dadurch werden im Datenbankserver sämtliche
Softwarebasisdienste, die nicht Bestandteil des Betriebssystems sind, verfügbar. Das betrifft
beispielsweise Funktionsgruppen für die Programmierung in ASP.NET, den Dateizugriff, die
Kommunikation und die Programmierung von grafischen Oberflächen mit Hilfe von
Windows Forms.
Signifikant ist die Möglichkeit, Datenbankcode wie zum Beispiel Stored Procedures oder
Trigger in allen verfügbaren .NET-Sprachen schreiben zu können. Das erleichtert die
Erstellung von Anwendungen, da Datenbankanweisungen direkt in Applikationen
eingebunden werden können, ohne externe Schnittstellen nutzen zu müssen. Der erstellte
Code läuft als Managed Code in der Common Language Runtime.
Die Integration des .NET-Frameworks fungiert als Mittler zwischen dem SQL Server und
Microsofts Visual Studio. Entwickler verfügen dadurch über eine einheitliche Oberfläche, mit
der sie in der Lage sind, einheitlichen Code für verschiedene Anwendungszwecke zu
entwerfen. Sei es für den Datenbankserver oder für andere Applikationen. Dieser Schritt von
Microsoft soll zu einem beschleunigten Entwicklungsprozess führen.
17 Das .NET-Framework bildet die Grundlage für Microsofts Business Intelligence und Data
Warehouseing-Angebot.
4.2.2 Integration Services
Die „Integration Services“ sind der Grundbaustein für Microsofts Data Warehouse. Sie haben
die Aufgabe, verschiedene Daten zu einem neuen Datenbestand, den „Data Stores“,
zusammenzuführen. Diese Funktionalität wurde in SQL Server 2000 noch von „Data
Transformation Services“ (DTS), die noch auf ActiveX und DOM beruhten, getragen. Die
Integration Services arbeiten nun mit dem .NET-Framework. Um eine sanfte Migration zu
ermöglichen sind die DTS aber noch parallel benutzbar.
Im Speziellen bestehen die Integration Services aus einer Reihe von Werkzeugen zur
Extraktion von Daten aus verschiedenen Quellen. Dabei kann es sich um
Datenbankschnittstellen wie OLE DB und ODBC, TCP/IP-Protokolle wie HTTP oder FTP,
einfache Dateien auf unterschiedlichen Speichermedien und viele andere Quellen handeln.
Die somit gewonnenen Daten können in ebenso vielfältige Ziele geladen werden.
Der Integrationsablauf wird in Paketen definiert. Um diese zu erstellen gibt es den „SQL
Server Integration Services Designer“ (SSIS Designer). Dieser ermöglicht die Beschreibung
von Projekten über grafische Oberflächen und bietet zahlreiche Debughilfen an.
4.2.3 Analysis Services
Die Analysis Services stellen einen OLAP-Server im Datenbanksystem bereit und bilden
damit eine Entwicklungsplattform. Eine Aufgabe der Analysis Services ist die Bereitstellung
von Basisdaten für andere Anwendungen wie zum Beispiel Microsoft Excel oder den
Scorecard Manager. Sie sind an das Visual Studio angebunden und stellen eine Reihe von
Assistenten und Design-Tools zur Verfügung, mit denen sich beispielsweise Cubes erstellen
lassen, die Fakten- und Dimensionstabellen oder Measures erstellen beinhalten.
Eines der zentralen Werkzeuge der Analysis Services ist der „Data Source Modeller“. Mit
ihm lassen sich Datenmodelle und Relationen aufbauen, die die Grundlage für die Cubes
bilden. Der „Data Mining Assistant“ dient zur Verwaltung eigenständiger Datensammlungen,
die mit Mining-Algorithmen abgeglichen werden können. Dazu werden unter anderem
neuronale Netze und Zeitreihen unterstützt. Die „Key Perfomance Indicators“ (KPI) dienen
der Definition graphisch anpassbarer Geschäftsmetriken und bilden die Grundlage für
Unternehmensbenchmarks.
Die Analysis Services arbeiten als Web-Server, speziell als XMLA-Server. Die
Datenmodelle, die erstellt wurden, werden als Web-Dienste angeboten. Dadurch lassen sie
sich einfacher von anderen Applikationen nutzen. Es werden mehrere Instanzen unterstützt
und eine Failover-Funktionalität bereitgestellt. Für einen schnelleren Zugriff auf Daten
kommt das „proaktive Caching“ zum Einsatz, das Hochgeschwindigkeitsapplikationen
Kopien bestimmter Daten bereitstellt. Durch die freie Konfigurierbarkeit des Caches wird die
Skalierbarkeit der angebotenen Dienste erhöht.
18 4.2.4 Reporting Services
Die Aufgabe der Reporting Services ist die Erstellung und Verwaltung jeglicher Berichte. In
früheren Versionen von SQL Server gab es keine eigene Funktionalität zur Berichterstellung.
Damals wurde auf eine Kooperation mit Crystal Reports gesetzt.
Das .NET-Framework bietet hier Integrationskonzepte zur Einbindung von Berichten in
weitere Anwendungen. Die Reporting Services bieten einen eigenen XML-Dialekt „Report
Definition Language“ (RDL).RDL-Dokumente können zur Laufzeit an die Reporting Services
Engine übergeben werden, die für das Auslesen benötigter Daten und den Aufbau von
Reports zuständig ist. Als Datenquellen für die Reporting Services können OLAP-Dienste wie
die Analytical Services sein, aber auch relationale Daten, angelegte Data Warehouses oder
allgemeine Datenbankschnittstellen wie OLE DB oder ODBC können verwendet werden.
Im Zentrum der Reporting Services steht der „Report Manager“ als WYSIWYG-Editor. Er
steht im Kontext mit dem Visual Studio und ermöglicht die Programmierung von Berichten in
.NET-Sprachen. Dadurch lassen sich unter anderem einfache Auswertungen oder Ad-HocReports erstellen. Das .NET-Framework bietet hier eine einfachere Bereitstellung von Daten
für OLAP-Umgebungen. Mit zahlreichen offenen Schnittstellen wird der Entwickler in die
Lage versetzt, eigene Werkzeuge für die Berichterstellung zu entwickeln.
Für die Verteilung und die Ausgabe von Berichten sind die „Delivery Services“
verantwortlich. Sie ermöglichen den Versand per Email, die Erstellung von PDFs, HTMLSeiten die sich auch in ASP.NET-Anwendungen einbinden lassen sowie die Weitergabe an
Sharpoint-Server und Microsoft Office.
4.2.5 Notification Services
Die Notification Services erlauben die Definition von Benachrichtigungsabläufen und zu
verwendenden Quellen. Sie sind in die Analysis Services und in das SQL Server Management
Studio integriert. Das damit angestrebte Ziel heißt Real-Time.Monitoring, wodurch im
Speziellen eine schnelle Übermittlung der Ergebnisse der Analysis Services angestrebt wird.
5. Zusammenfassung
Der Vergleich beider Systeme anhand der vielfältigen Kriterien hat gezeigt, wie ähnlich beide
Systeme strukturiert sind. Das liegt nicht zuletzt an der vergleichbaren
Zielgruppenausrichtung. Microsoft hat mit dem SQL Server 2005 ein umfassend
überarbeitetes Produkt entwickelt, dass in Hinblick auf die Funktionalitäten ähnlich
leistungsfähig wie Oracle ist.
Microsoft setzt mit der Integration des .NET-Framework stark auf eine Konsolidierung von
Entwicklungsprozessen und kann dadurch entscheidende Vorteile gegenüber Oracle
gewinnen. Oracle hingegen setzt in dieser Richtung sehr stark auf Erfahrung und
Zuverlässigkeit und verbessert seine Konzepte stetig.
Zukunftsentscheidende Aspekte des Erfolgs beider Systeme liegen in der Akzeptanz von
Microsofts Konsolidierungskonzeptes und der Plattformausrichtung der Unternehmen. Dieser
Prozess könnte maßgeblich von den Grundsatzentscheidungen der Kunden in den Bereichen
19 Sicherheit, Stabilität und Performanz und der Umsetzung daraus resultierender gewünschter
Funktionalitäten auf den verschiedenen Rechnerarchitekturen und Betriebssystemen
beeinflusst werden.
6. Quellen
Greenwald, Stackowiak, Stern: „Oracle Essentials: Oracle Database 10g, 3rd Edition“,
O’Reilly 2004
Baumeister: “SQL Server 2005”, Datenbankspektrum 16/2006
Nielsen: “SQL Server 2005 Bible”, Wiley 2007
Hobbs, Hillson, Lawande, Smith: „Oracle Database 10g Data Warehousing“, Elsevier Digital
Press 2005
Roy: „IDS 10 und Oracle 10g im Vergleich“ , 2005
PL/SQL – Wikipedia, http://de.wikipedia.org/wiki/PL/SQL, Abruf 15.6.2008
20