Microsoft SQL Server 2005 im Vergleich zu Oracle
Werbung
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
