MS SQL Server 2005 im Vergleich zu Oracle Ausarbeitung von
Werbung
MS SQL Server 2005 im Vergleich zu Oracle Ausarbeitung von Robert Münch und Marc Drobek 20. Juni 2007 Prof. T. Kudrass Hochschule für Technik, Wirtschaft und Kultur Leipzig Fachbereich für Informatik, Mathematik und Naturwissenschaften Inhaltsverzeichnis 1 Der Microsoft SQL Server 2005 1.1 2 3 4 5 I 2 Kernmodule . . . . . . . . . . . . . . . . . . . . . . . . . . . Sicherheitsaspekte 2 3 2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Sicherheitsvergleich . . . . . . . . . . . . . . . . . . . . . . . 5 Verfügbarkeit 7 3.1 Ausfallzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Fehlereindämmung zur Steigerung der Verfügbarkeit . . . . . 9 Systemarchitektur 12 4.1 Grundlegende Architektur . . . . . . . . . . . . . . . . . . . 12 4.2 Speicherstrukturen . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Fazit Architektur . . . . . . . . . . . . . . . . . . . . . . . . 14 Administrativer Aufwand 14 5.1 Studie von Alinean, Inc. [5] . . . . . . . . . . . . . . . . . . . 14 5.2 Studie der Edison Group, Inc. [6] . . . . . . . . . . . . . . . 15 5.3 Fazit Administration . . . . . . . . . . . . . . . . . . . . . . 15 Anhang 16 1 1 Der Microsoft SQL Server 2005 In der heutigen Zeit, müssen täglich Unmengen an Daten gespeichert und verwaltet werden. Firmen und Unternehmen reicht es nicht mehr aus, die Daten nur abzulegen. Ein derzeitiges Datenbanksystem muss sowohl die Daten verwalten, als auch analysieren können. Neben der Open Source Lösung MySQL und der kommerziellen Software Oracle steht hier auch der Microsoft SQL Server. Seine grundlegende Funktionalität und ein Vergleich zum Konkurrenten Oracle soll hier kurz abgehandelt werden. 1.1 Kernmodule Die folgenden Inhalte sind entnommen aus [2]. Was bietet der Microsoft SQL Server 2005? • Verfügbarkeit: Replikationserweiterungen und Wiederherstellungsmöglichkeiten • Skalierbarkeit: Partitionierung und 64-Bit Unterstützung • Sicherheit: “Secure-by-default“-Einstellungen und weitere Sicherheitskonzepte • Verwaltbarkeit: Verwaltungstools, Self-Tuning-Möglichkeit • Interoperabilität: .NET Struktur, Unterstützung unterschiedlicher Plattformen • Entwicklungstools: Tools zur Nutzung von XML, Transact-SQL, Integration von Visual Studio • Sprachunterstützung: Hosten der CLR, Anwendung von .NET Sprachen und Transact-SQL • XML- und Webdienste: relationale und XML-Daten • Integrierte Plattformen: Business-Intelligence-Plattformen, OLAP, Data-Mining, ETL-Tools, DataWarehousing, 2 • Entscheidungsfindung: Reporting-Tools zur einfacheren Entscheidungsfindung • Analysemöglichkeiten: Integration und Analyse von heterogenen Informationsquellen 2 2.1 Sicherheitsaspekte Grundlagen Nachfolgend werden einige grundlegende Sicherheitsfeatures erklärt. Authentifizierung Die Authentifizierung stellt sicher, dass ein Benutzer, die entsprechende Erlaubnis besitzt um Zugriff auf das Netzwerk oder die Ressource zu erhalten. Dazu muss der Benutzer dem System gegenüber seine Echtheit beglaubigen. Dies geschieht häufig durch die Eingabe von Nutzername und Passwort. Der Authentifikationsprozess selbst überprüft dann die Richtigkeit der Eingaben und identifiziert den Benutzer somit im Netzwerk. Die Authentifizierung kann verstärkt werden durch den Einsatz von kryptographischen Methoden. Von simplem Hash-Algorithmen über Zertifikate bis hin zu Smartcards findet die komplette Bandbreite der Kryptografie Anwendung. Autorisation Nach dem Authentifizierungsprozess ist das System in der Lage festzustellen, auf welche Ressourcen der Nutzer Zugriff hat. So wird sichergestellt, dass nur bestimmte Benutzer in der Lage sind, sensible Daten einzusehen, und zwar diejenigen, die von den Adminstratoren dazu bevollmächtigt wurden. Somit ist die Autorisation ein einfaches Werkzeug um den Zugriff auf Ressourcen zu kontrollieren. Jedoch benötigt es eine vertrauenswürdige Quelle, in welcher die entsprechenden Zugriffsrechte hinterlegt sind. Wird diese Quelle kompromittiert , kann der Schutz der Ressourcen nicht mehr gewährleistet werden. Daher bieten sich auch hier die Absicherung mittels Verschlüsselung an. Auditierung Die Auditierung dient zur Überwachung und Abspeicherung von Nutzeraktionen. Es hilft somit bei der Fehlersuche bei unerklärlichen Phänomenen oder zeigt die Veränderung der Datenbank auf, wenn man beispielsweise Tabellen erstellt oder löscht. Ein gutes Auditierungssystem erlaubt dem Administrator das Filtern von bestimmten Aktionen, so dass er nicht überhäuft wird mit Informationen. Ein solches Auditierungssystem ist beispielsweise der SQL Profiler (Abb. 1, Seite 4), welches im SQL Server zum Einsatz 3 kommt. Abbildung 1: Der SQL Profiler zur Überwachung von SQL Server Aktionen. [1] Verschlüsselung Die Verschlüsselung dient in erster Linie dazu, um nicht berechtigten Personen die Einsicht in empfindliche Daten zu verbieten. Es haben nur die Nutzer Einblick, die auch den entsprechenden Schlüssel zur Verfügung haben. Bei Datenbankensystemen gibt es 2 wesentliche Schlüsselpunkte, welche ein Sicherheitsrisiko darstellen: Das Senden von Daten über ein Netzwerk und das Abspeichern von Daten in der Datenbank. Datenverschlüsselung Beim SQL Server werden die Daten durch 3 mögliche Verfahren verschlüsselt: • Passwörter durch simple Passphrasen • vorhandene Zertifikate 4 • asymmetrische Schlüssel Diese Verschlüsselung findet direkt in der Datenbank mithilfe des integrierten Zertifizierungsservers statt. Unter Anderem kann der SQL Server Zertifikate auch selbst erstellen und verwalten. Netzwerkverschlüsselung Zur Absicherung des Datenverkehrs kommen hauptsächlich die Standardverfahren zur Verwendung, so etwa IP Security (IP SEC) oder Secure Sockets Layer (SSL). 2.2 Sicherheitsvergleich Der MS SQL Server 2005 kennt 2 Möglichkeiten der Authentifizierung: Die Windows Authentifizierung und die SQL Server Authentifizierung. Windows Authentifizierung Hierbei handelt es sich um die empfohlene Authentifizierung beim MS SQL Server 2005 (Abb. 2, Seite 6. Dabei werden einzelne Windows Accounts für den SQL Server verwendet. Der SQL Server übernimmt somit auch die Sicherheitsrichtlinien der entsprechenden Windows Domaine. Dies sorgt für eine konsistente Passwortverwaltung. Zudem werden hierbei auch die Sicherheitsauthentifizierunsprotokolle von Windows benutzt um die Passwörter verschlüsselt über das Netzwerk zu verschicken. SQL Server Authentifizierung Diese Authentifizierung ist lediglich für Nicht-Windows-Clients oder für Anwendungenentwickler. Diese Authentifizierung kann mit dem hohen Sicherheitssandard der Windows Authentifizierung nicht konkurrieren, und sollte somit von Windows Nutzern nicht verwendet werden.(Abb. 3, Seite 6) Oracle bietet auch die Windows Authentifizierung und eine Oracle basiert Authentifizierung. Oracle basierte Authentifizierung Entgegen des SQL Server 2005 setzt Oracle auf die eigene Authentifizierung und nutzt standardmäßig nicht die Windows Authentifizierung. Legt man Wert auf ein stärkeres Authentifizierungsprotokoll, so muss man entweder manuell die Windows Authentifizierung aktivieren, oder aber die Oracle 5 Abbildung 2: Windows Authentifiezierung für den SQL Server 2005 [1] Abbildung 3: SQL Server Authentifiezierung [1] 6 erweiterten Sicherheitsoptionen in der Enterprise Edition von Oracle 10g installieren. Benutzername und Passwort werden verschlüsselt in der Datenbank abgespeichert. Genau wie beim SQL Server auch, ist es möglich Policies festzulegen, um die Passwörter einfacher handhaben zu können und vor allem eine konsistente Passwortdatenhaltung zu gewährleisten. Bei Oracle 10g Enterprise Edition mit erweiterten Sicherheitsoptionen ist die Verschlüsselung standardmäßig ausgeschaltet, wohingegen beim SQL Server von Beginn an verschlüsselt wird. Zu jedem Zeitpunkt sollte eine Abstimmung zwischen Performance und Verschlüsselung gesucht werden, um maximale Effizienz zu gewährleisten. 3 Verfügbarkeit Verfügbarkeit kann definiert werden als Zeit, die ein bestimmtes System oder eine bestimmte Ressource verfügbar ist. Als hoch verfübar“ wird ein ” System bezeichnet, wenn seine relative Verfügbarkeit eine bestimmte Richtlinie erfüllt, wobei 100 % Verfügbarkeit nur dann erreicht werden kann, wenn das System zu jedem Zeitpunkt erreichbar ist. Diese Schranke kann de facto nicht erreicht werden, da elektronische Bauelemente einem Alterungsprozess unterliegen, und somit irgendwann einen Ausfall verzeichnen. Die Verfügbarkeit wird wie folgt mathemtisch definiert: Verfügbarkeit = (Gesamte Laufzeit - P Ausf allzeit) / Gesamte Laufzeit Dadurch ergibt sich für die Verfügbarkeit folgende Tabelle. Anzahl der Neunen 1 2 3 4 5 Verfügbarkeit 98,9 % 99,0 % 99,9 % 99,99 % 99,999 % Ausfallzeit pro Jahr 3 Tage, 18 Stunden, 20 Minuten 3 Tage, 15 Stunden, 36 Minuten 8 Stunden, 46 Minuten 53 Minuten 5 Minuten Tabelle 1: Verfügbarkeit [3] Ein Tag Ausfallzeit im Monat bedeutet also eine Verfügbarkeit von 98,9 %. Sehr hohe Verfügbarkeit wird in der Praxis mit der 5-Neunen-Regel angegeben, sprich ein System, welches pro Jahr lediglich 5 Minuten Ausfallzeit gewährleisten kann, hat eine Verfgbarkeit von 99,999 %. 7 3.1 Ausfallzeit Trotz technologisch höchstem Niveau und der Beachtung aller Sicherheitsregeln müssen Datenbanken vom Netz genommen werden. Diese Ausfallzeiten sind geplant, und dienen meistens zur Wartung der Datenbank oder zum Einspielen von Backups. Hier unterscheiden sich der MS SQL Server 2005 und Oracle. MS SQL Server 2005: • Simple Recovery Model Mit dieser Einstellung wird der geringste Logging Overhead erzeugt, was jedoch zur Folge hat, dass die Daten nur bis zum letzten Backup wiederhergestellt werden können. • Full Recovery Model Dieses Modell ist am anderen Ende der Skala anzusiedeln. Es erzeugt den meisten Logging Overhead, allerdings können auch alle bis zum Beginn des Fehler zurück wiederhergestellt werden. • Bulk-Logged Recovery Model Hierbei handelt es sich um einen Mittelweg zwischen den beiden oben genannten Modellen. Ein Großteil aller Transaktionen wird mitgeloggt, aber bulk“-Operationen wie etwa SELECT INTO werden ver” nachlässigt. Bei einem Wiederherstellungsprozess sind diese Operationen verloren. Daten können wiederhergestellt werden bis zur letzten Datenbank- bzw. Loggingsicherung. Oracle 10g: • Recovery Manager(RMAN) Der Recovery Manager kümmert sich bei Oracle um das Erstellen von Sicherungen und deren Wiederherstellung. Die Standard RMAN Sicherung beinhaltet Datenblöcke für ein bestimmtes Datenfile, welche komprimiert abgespeichert werden. Im Wiederherstellungsfall wird eine komplette Datei aus den Datenblöcken vom RMAN erstellt. Der Recovery Manager eignet sich hervorragend zum Wiederherstellen größerer Datenmengen. • Flashback Der Flashback gewährt die Möglichkeit die Datenbank zu einem bestimmten Zeitpunkt wiederherzustellen. Dabei wird ein Flash Reco” very“-Gebiet anstatt einer Standardsicherung verwendet. Daher wird diese Strategie im Gegensatz zum RMAN am besten eingesetzt, um einfache Tabellen- oder Spaltendaten, welche kompromittiert wurden, 8 wiederherzustellen. Um diese Strategie verwenden zu können, muss der Datenbankadministrator ein Flash Recovery“-Gebiet einrichten, wel” ches Flashback Datenbanklogs, Redo Archivierungslogs und RMAN Sicherungskopien enthält. Dennoch sollte diese Modell vorsichtig verwendet werden, da Inkonsistenten entstehen können. Dies tritt insbesondere dann auf, wenn man eine Tabelle wiederherstellen will, welche Abhängigkeiten besitzt, und diese abhängigen Objekte wurden verändert. 3.2 Fehlereindämmung zur Steigerung der Verfügbarkeit Ohne Beschränkung der Allgemeinheit gilt immer: Das beste Mittel, um hohe Verfügbarkeit zu gewährleisten, ist der Schutz vor Serverfehlern, also das Vermeiden von ungeplanten Aktionen, die den Server unerreichbar für Anwender machen. Serverfehler können sowohl von der Hardware- als auch von Softwareseite her auftreten. Faktoren die die Ausfallzeit beeinflussen sind unter Anderem: • Hardwarefehler(CPU, RAM, Speicher, E/A, Stromversorgung) • Betriebssystem- oder Gerätetreiberfehler • Datenbankfehler Der erste Schritt zur Minimierung von Hardwarefehlern ist die Investition in hervorragende Systeme, welche die Redundanz von Schlüsselkomponenten gewährleisten können. Beispielsweise sind heutige Standardserver mit mehreren redundaten Netzteilen, USVs oder schnelltauschbaren RAM- bzw. Festplattensteckplätzen ausgestattet. Softwareseitig betrachtet, können Fehler hier oftmals verhindert werden durch die neuesten Updates und Service Packs. Wesentlich zur Serverfehlervermeidung sind aber Datenbankkonzepte, welche speziell darauf ausgelegt wurden. Technologien dieser Art sind beispielsweise das Clustering, Log Shipping, Spiegeln oder Replikation. Im Folgenden sollen einige dieser Strategien kurz vorgestellt und deren Einsatzweise bei Microsoft bzw. Oracle dargelegt werden. SQL Server 2005 N-Way Clustering: Je nach zugrundeliegender Windows Version werden 2-,4- oder 8-Knoten Cluster unterstützt. Jeder physische Knoten im Cluster ist ein Server, welcher in ständigem Kontakt mit den anderen Servern im Cluster steht. Sobald 9 ein Knoten nicht mehr erreichbar ist, übernimmt ein Anderer die Services, die der ausgefallene Knoten angeboten hat, und stellt diese für die Nutzer zur Verfügung. Der Fehlknoten muss einem Wiederherstellungsprozess unterzogen werden, damit ein konsistenter Zustand erreicht wird. Da alle Knoten auf einen gemeinsamen Plattenspeicher zugreifen müssen, stehen diese Geräte physisch meistens dicht zusammen, je nach verwendeter Verbindung(SCSI, Glasfaserkabel,...). Sehr effektiv gestaltet sich diese Strategie beispielsweise für einen 8-Knoten Cluster, indem 7 Server die Arbeit übernehmen, und der letzte Server im Standby Modus verbleibt. Fällt nun ein Knoten aus, so kann der Standby-Server“ dessen Aufgabe übernehmen. ” Abbildung 4: Clustering beim MS SQL Server 2005 [3] Replikation: Bei jeder Replikation gibt es einen Herausgeber (die Quelle der zu replizierenden Daten) einen Empfänger (das Ziel der replizierten Daten) und einen Anbieter (verwaltet das Senden der replizierten Daten vom Herausgeber zum Empfänger). Bei der Transaktionsreplikation wird ein Schnappschuß genutzt, um die Datenbanken initial beim Herausgeber und Empfänger zu synchronisieren. Sobald die Transaktionen beim Herausgeber bestätigt wurden, werden sie zum Empfänger gesendet. Der Vorteil bei der Nutzung der Replikation liegt 10 darin, dass der zweite Server dauerhaft zur Verfügung steht und somit als Reporting-Server genutzt werden kann. Oracle 10g Real Application Clustering (RAC): Hierbei handelt es sich um eine Strategie, welche aus mehreren untereinander verbundenen Computern besteht, die als Knoten bezeichnet werden. Das RAC sorgt nun dafür, dass die einzelnen Computer sich zusammen wie ein einziges Computersystem verhalten. Oracle unterstützt eine maximale Knotenanzahl von 64, je nach zugrundeliegendem Betriebssystem. Im Falle eines Fehlers von einem Knoten, tritt eine kurze Periode ein, in der die Clients das System nicht mehr erreichen können, und sich das System selbst resynchronisiert. Nach dieser Phase wird der Fehlknoten aus dem Gesamtsystem entfernt und schrittweise alle seine blockierten Ressourcen wieder freigegeben. Zum Schluß werden alle im Arbeitsprozess unterbrochenen Queries von Anfang an neugestartet. Abbildung 5: Clustering bei Oracle 10g [3] Data Guard: Ähnlich dem SQL Server 2005 Datenbank-Spiegelungssystem nutzt Oracles Data Guard ein Transaktionslog auf einem Standby-Server“ um immer ei” ne konsistente Kopie der Produktionsdatenbank zur Verfügung zu haben. Falls ein Serverfehler auf der Produktionsdatenbank eintritt, kann der Data Guard die Standby-Datenbank“ in die Produktionsdatenbank umwandeln. ” 11 Insgesamt kann diese Strategie neun unteschiedliche Sicherungskopien der Produktionsdatenbank verwalten. Dabei gibt es drei unterschiedliche Betriebsmodi: • Maximalen Schutz Hierbei wird der Datenfluss kontinuierlich auch zur Standby-Datenbank“ ” geleitet, und keine Transaktion wird bestätigt, bevor die Redodaten auf dem Standby-Server angelangt sind. Falls die Redodaten zu keinem Standby-Server kopiert werden können, stoppt die Primärdatenbank. • Maximale Verfügbarkeit Ähnlich dem Maximalen-Schutz“-Prinzip werden auch hier die Daten ” kopiert. Der Untschied besteht lediglich darin, dass die Primärdatenbank nicht stoppt, falls der Standby-Server nicht erreichbar ist. • Maximale Performance Redodaten werden asynchron von der Primärdatenbank zum Standbyserver kopiert. Die Betätigung der Primärdatenbank wartet nicht auf den Standby-Server. 4 4.1 Systemarchitektur Grundlegende Architektur Der Aufbau des gesamten DB System im SQL Server 2005 ist ähnlich dem von Oracle. Vorab muss man den Unterschied in der Bezeichnung Daten” bank“ in beiden Systemen betrachten. Oracle bezeichnet als Datenbank das gesamte System mit allen Puffern, Tabellen, Logs usw. Im SQL Server 2005 ist eine Datenbank nur die tatsächlichen Tabellen und Daten. Es wird hierbei in System und Benutzer Datenbanken unterschieden. Abbildung 6: Vergleich Tabelspace und Datenbank [4] 12 Die einzelnen Datenbanken im SQL Server 2005 können in filegroups“ ge” gliedert werden. Dies ermöglicht es die Daten der Datenbank in Dateien des Betriebssystems zu gliedern. Vorallem hinsichtlich Backup und I/O ist dies ein wichtes Feature. Auch hinsichtliche des Systemskatalogs gibt es Unterschiede. Bei Oracle werden Informationen zu Benutzern und deren Rechte, sowie Constraints und benutzerdefinierte Datentypen zentral gespeichert. All diese Objekte werden im SQL Server 2005 in jeder Datenbank extra verwaltet. 4.2 Speicherstrukturen Ein großer Unterschied ist in der Organisation des Speichers festzustellen. Während man unter Oracle für jeden Tablespace die Block-Größe festlegen kann ist diese im SQL Server 2005 fix auf 8KB eingestellt. Diese Blöcke bzw. Pages werden immer zu acht in einer Gruppen zusammengefasst, die dann ein Extent ergeben. Auf einem Oracle System müssen mindestens fünf Blöcke zusammengefasst werden um ein Extent zu ergeben. Mehrer Extens bilden dann die Speichereinheiten für die Datenbank Objekte, hier unterscheiden sich Oracle 10g und der SQL Server 2005 nicht. Abbildung 7: Vergleich Speicherstrukturen [4] 13 4.3 Fazit Architektur Es gibt zwischen Oracle 10g und SQL Server 2005 zwar Unterschiede in der Architektur, doch bieten die beiden Systeme am Ende gleiche Eigenschaften und Funktionen. Hierbei muss man beachten, dass die unterschiedlichen Ansätze nicht immer vernachlässigt werden können. Dadurch ist es nötig für jede Anwendung eine genau Analyste der Anforderungen zu erstellen und darauf aufbauen die Entscheidung für ein Datenbanksystem fällen. 5 5.1 Administrativer Aufwand Studie von Alinean, Inc. [5] Nach einer Studie von Alinean, Inc. für Microsoft sind für geplante Wartungen im Jahr 72 Stunden bei SQL Server 2005 notwendig. Bei Oracle sind es 61.9 Stunden. Was die Ursachen für diesen Unterschied ist geht aus der Studie nicht hervor. Es wird aber betont, dass in der Studie Datenbanken mit ähnliche Anwendugen und gleichem Anteil an kritischen Applikationen untersucht wurden. Weiteres Augenmerk wurde auf die Anzahl der Datenbanken pro Administrator gelegt. Hier liegt der SQL Server 2005 klar vorn. Laut der Studien werden 31.2 Datenbanken pro Administrator betreut. Gegenüber stehen 9.9 Oracle Datenbanken. Auch hier ist nicht beleuchtet wurden warum so ein starkes Ungleichgewicht von 3:1 herscht. Eine Grund kann man, unter Berücksichtigung der oben angesprochenen Unterschiede in der Bezeichnung von Datenbanken, suchen. Hierbei ist auch der wöchentliche Administrationsaufwand zu nennen. Es ergibt sich eine ähnlich ungleich verteiltes Bild wie bei der Wartung. Pro Datenbank müssen 4.7 Stunden am SQL Server 2005 investiert werden, aber 11.3 Stunden pro Oracle Datenbank. Hierzu heißt es, dass für eine Aufgabe an einem Oracle System fast 40% mehr Zeit nötig ist. Besonders aber beim Lösen von Problemen wurde an Oracle Systemen annnähernd doppelt soviel lange gearbeitet wie am SQL Server 2005. Eine weitere Größe die untersucht wurde ist die durschnittliche Installationszeit für beide Systeme. Hierbei ergaben sich auch wieder große Unterschiede zu Gunsten des SQL Server 2005. Für eine Installation brauchte man nur 15.1 Stunden, zum Upgrade 23.2 Stunden. Für eine Installation von Oracle waren 24.8 Stunden nötig und zum Upgrad 35.2 Stunden. 14 5.2 Studie der Edison Group, Inc. [6] Um die gerade besprochenen Studie besser einordnen zu können, betrachten wir noch eine Studie von Edison Group, Inc. für Oracle. Dabei wurde vor allem hinsichtlicher des Administrations Aufwandes untersucht. Bei dieser Studie wurde festgestellt, dass man für die üblichen Administrativen Tätigkeiten auf einem Oracle System 38.2% weniger Zeit benötigt als auf einem SQL Server 2005. Bei täglichem Administrations Aufwand wurde auf einem Oralce System immer noch 27% weniger Zeit benötigt als auf einem SQL Server 2005. Auch bei dieser Studie wurde die Installationszeit für beide Systeme untersucht. Im Gegensatz zu der Studie von Alinean wurde hier eine Zeitvorteil von 32% zu Gunsten des Oracle Systems festgestellt. 5.3 Fazit Administration Da die beiden Studien völlig unterschiedliche Ergebnisse liefern ist es schwer ein eindeutiges Fazit zu ziehen. Es ist wohl kaum möglich zu sagen welche Datenbank besser ist. Dies bleibt weiterhin eine Einzelfallentscheidung, welche vor allem durch die Anwendungen, die Systemlandschaft und die persönlichen Vorlieben der Administratoren beeinflußt wird. Hierzu sollte man weitere Studien und White Papers zu den speziellen Einsatzgebieten heranziehen. Dabei lassen sich meist qualifiziertet Ergebnisse finden, als sie ein allgemeiner Vergleich bringen kann. 15 Teil I Anhang Literatur [1] http://www.microsoft.com/sql/prodinfo/compare/oracle/ss2005oracle10gsecuritycompare.mspx. [2] http://download.microsoft.com/download/5/8/8/5889d6c0-ca32-4097807c-dc69603300ac/sql server 2005 datenblatt de.pdf. [3] http://www.microsoft.com/sql/prodinfo/compare/oracle/dbavailability.mspx. [4] http://download.microsoft.com/download/a/4/7/a47b7b0e-976d-4f49b15d-f02ade638ebe/sqlserver2005fororacleprofessionals.pdf. [5] http://www.microsoft.com/sql/prodinfo/compare/oracle/sqlserver2005oracle-tca.mspx. [6] http://www.oracle.com/database/docs/edison10gr2vsss20051.pdf. 16
