Diplomarbeit. Evaluierung einer Datenbankmigration am Beispiel von Oracle Database und Microsoft SQL Server

Transkript

1 Fachhochschule Köln University of Applied Sciences Cologne Campus Gummersbach Fakultät für Informatik und Ingenieurwissenschaften Diplomarbeit zur Erlangung des Diplomgrades Diplom-Informatiker (FH) in der Fachrichtung Informatik Evaluierung einer Datenbankmigration am Beispiel von Oracle Database und Microsoft SQL Server Erstprüfer: Prof. Dr. Heide Faeskorn-Woyke Zweitprüfer: Dipl. Ing. Johannes Ahrends vorgelegt am: von: Erdal Türkeri Gelpestr. 42a Gummersbach Matrikelnummer:

2 Inhaltsverzeichnis 2 Inhaltsverzeichnis ABBILDUNGSVERZEICHNIS...3 TABELLENVERZEICHNIS EINLEITUNG Motivation und Problemstellung Zielsetzung und Vorgehensweise Danksagung ARCHITEKTUR-VERGLEICH Physische Datenbankarchitektur Logische Datenbankarchitektur Logische Speichereinheiten Instanzen DATENBANKOBJEKTE Datentypzuordnungen Unterschiede zwischen ANSI-SQL und ORACLE-SQL Namenskollisionen Maximal zulässige Größen der SQL Server Datenbankmodul- Objekte SPERRKONZEPTE LOCKING LOCKING in SQL Server LOCKING in Oracle Lesekonsistenz Lesekonsistenz in SQL Server Lesekonsistenz in Oracle Isolationsstufen Isolationsstufen in SQL Server Isolationsstufen in Oracle MIGRATION VON ORACLE ZU SQL SERVER Migration mit dem Microsoft SQL Server Migration Assistant (SSMA for Oracle) Assessment Report Probleme Konvertierungsweise Ergebnis MIGRATION VON SQL SERVER ZU ORACLE Migration mit dem Oracle SQL Developer Probleme Ergebnis SCHLUSSBETRACHTUNG...69 LITERATURVERZEICHNIS...71 ANHANG A...74 ANHANG B...78 ERKLÄRUNG...79

3 Abbildungsverzeichnis 3 Abbildungsverzeichnis Abbildung 1: Snapshot TDM mit ER-Modell Oracle-DEMO...38 Abbildung 2: Snapshot des Microsoft Migration Assistant for Oracle...39 Abbildung 3: Snapshot eines Assessment Reports...41 Abbildung 4: Tabelle Personen in Oracle...46 Abbildung 5: Tabelle Personen in SQL Server...46 Abbildung 6: Snapshot TDM mit ER-Modell SQL Server-DEMO...52 Abbildung 7: Snapshot TDM mit ER-Modell SQL Server-WAWI...55 Abbildung 8: Snapshot des Oracle SQL Developers...57 Abbildung 9: Oracle Migration Workbench Architektur...58 Abbildung 10: Snapshot des SQL Developer Script Output-Fensters...58 Abbildung 11: Snapshot Toad for Oracle...59 Abbildung 12: Snapshot TDM mit ER-Modell Oracle-WAWI...68

4 Tabellenverzeichnis 4 Tabellenverzeichnis Tabelle 1: Schema-Objekte von Oracle und SQL-Server...11 Tabelle 2: Datentypzuordnungen von Oracle zu SQL Server...13 Tabelle 3: Datentypzuordnungen von SQL Server zu Oracle...14 Tabelle 4: Datums- und Zeitangaben in SQL Server...15 Tabelle 5: Datums- und Zeitangaben in Oracle...15 Tabelle 6: NULL-Konstrukte in Oracle und SQL Server...17 Tabelle 7: SQL-Syntaxunterschiede...20 Tabelle 8: Syntaxunterschiede von PL/SQL und T-SQL...21 Tabelle 9: Operatorunterschiede...22 Tabelle 10: Reservierte Schlüsselwörter des SQL Server...23 Tabelle 11: Reservierte ODBC-Schlüsselwörter des SQL Server...24 Tabelle 12: Zukünftige Schlüsselwörter des SQL Server...24 Tabelle 13: Automatische Sperrmodi des SQL Server...27 Tabelle 14: Beabsichtigte Sperren des SQL Server...29 Tabelle 15: Automatische Sperrmodi von Oracle...30 Tabelle 16: Manuelle Sperrmodi von Oracle...31 Tabelle 17: Parallelitätsnebeneffekte in SQL Server...35 Tabelle 18: Parallelitätsnebeneffekte in Oracle...36 Tabelle 19: Konvertierungsstatistik des SSMA...40 Tabelle 20: Konvertierungsweise des SSMA...48 Tabelle 21: Maximale Kapazität für SQL Server

5 1 Einleitung 5 1 Einleitung 1.1 Motivation und Problemstellung Zahlreiche Gründe können Unternehmen dazu veranlassen von einem kommerziellen Datenbankmanagementsystem auf das eines anderen Herstellers zu wechseln. Einer der Gründe sind die Kosten. In den letzten Jahren sind bei den kommerziellen Datenbanken Änderungen zu verzeichnen. Dies betrifft sowohl die generelle Leistungsfähigkeit der verschiedenen Systeme als auch die Verschiedenheit der Kosten innerhalb der einzelnen Systeme, ebenso die Kompatibilität der einzelnen Systeme untereinander. Die finanzielle Realität für die meisten Unternehmen ist, dass zu viel ihres Etats durch ihre vorhandene IT-Infrastruktur verbraucht wird und zu wenig für neue IT-Investitionen vorhanden ist. Dementsprechend ist die Senkung der Kosten für die IT- Infrastruktur für viele leitende IT-Manager oberstes Gebot. Datenbanken sind dabei ein lohnenswertes Ziel für geplante Sparmaßnahmen, da hiermit ein erheblicher Aufwand sowohl im Hinblick auf die IT-Arbeitsleistung als auch im Hinblick auf die Personalkosten verbunden ist. Weitere Gründe einer Datenbankmigration können Anforderungen an den Herstellersupport, die Kompatibilität zu anderen Datenbanken oder andere Gründe sein. Hier soll allerdings nicht die genaue Kostenstruktur untersucht werden, sondern die technischen Aspekte einer Umstellung. Datenbankmigrationen stellen im Hinblick auf die Kosten und die Komplexität eine erhebliche Herausforderung dar. Vorhandene Daten aus einem alten System auf ein neues System eines anderen Herstellers zu übertragen ist sehr aufwendig, weil insbesondere system- bzw. herstellerspezifische Besonderheiten nicht übernommen werden können. 1.2 Zielsetzung und Vorgehensweise Ziel dieser Diplomarbeit ist anhand von Praxisbeispielen Migrationen zwischen den beiden kommerziellen Datenbankmanagementsystemen Oracle Database und Microsoft SQL Server durchzuführen und die Ergebnisse zu untersuchen.

6 1 Einleitung 6 Dabei werden Migrationswerkzeuge beider Hersteller verwendet, die nach Herstellerangaben eine schnelle, einfache und akkurate Migration von fremden Datenbankmanagementsystemen auf das eigene System unterstützen sollen. Es soll untersucht werden, ob mit diesen Migrationswerkzeugen die Schema- und Datenmigration automatisiert werden kann. In dieser Diplomarbeit soll zunächst einmal in Kapitel 2 die physische und die logische Datenbankarchitektur von Oracle Database und Microsoft SQL Server gegenübergestellt werden, wobei auch einige theoretische und begriffliche Grundlagen dargelegt werden. Danach werden in Kapitel 3 Datenbankobjekte der beiden Systeme verglichen, wobei unter anderem Datentypzuordnungen und Syntax-Unterschiede aufgeführt werden. In Kapitel 4 werden die unterschiedlichen Sperrkonzepte der beiden Systeme behandelt. In Kapitel 5 wird anhand eines Praxisbeispiels das Ergebnis einer Migration von Oracle zu SQL Server dargelegt. Anschließend wird in Kapitel 6 wiederum anhand eines Praxisbeispiels das Ergebnis einer Migration von SQL Server zu Oracle dargelegt. Schließlich werden in Kapitel 7 die wichtigsten Ergebnisse dieser Diplomarbeit zusammengefasst. 1.3 Danksagung Ich danke Frau Prof. Dr. Heide Faeskorn-Woyke, durch die ich dieses Diplomarbeitsthema gefunden habe und die mich mit Herrn Ahrends in Kontakt gebracht hat. Herrn Dipl. Ing. Johannes Ahrends danke ich dafür, dass er mir einen Arbeitsplatz bei der Quest Software GmbH zur Verfügung gestellt hat und mir immer mit seinem bemerkenswerten Fachwissen mit Rat und Tat zur Seite stand. Ebenso bedanke ich mich ausdrücklich bei Herrn Dipl. Inf. Patrick Schwanke, der mich sehr geduldig mit seinen beeindruckenden PL/SQL Kenntnissen unterstützt hat und auch Herrn Dipl. Inf. Thomas Klughardt, der stets ein offenes Ohr für meine Fragen hatte. Schließlich möchte ich noch allen anderen Quest Mitarbeitern für ihr herzliches Entgegenkommen und ihre Unterstützung danken.

7 2 Architektur-Vergleich 7 2 Architektur-Vergleich Oracle Database und Microsoft SQL Server sind relationale Datenbankmanagementsysteme. Dabei ist Oracle für fast alle heute verwendeten Plattformen verfügbar wohingegen der SQL Server nur auf Basis von Microsoft Windows Plattformen erhältlich ist. Die Database Engine (Datenbankmodul) des SQL Servers ist der eigentliche Kerndienst, mit dem das Speichern, Verarbeiten und Sichern von Daten realisiert wird. Das Datenbankmodul ist ein Teilbereich des SQL Servers. Daneben gibt es noch viele weitere herstellerabhängige Merkmale, die bei einer Migration beachtet werden müssen. Beispielsweise verläuft die Datenspeicherung, die Datensicherung oder die Transaktionsverwaltung der jeweiligen Systeme grundsätzlich unterschiedlich. Aus diesem Grund sollte zunächst einmal verglichen werden, inwieweit bestimmte Konstruktionen in beiden Systemen vorhanden sind. Daher sollen die unterschiedlichen physischen- und logischen Datenbankarchitekturen nachfolgend kurz erläutert werden. Ferner soll dies auch dazu dienen, einen kleinen Überblick über die unterschiedlichen Nomenklaturen, die in beiden Systemen verwendet werden, zu erlangen. 2.1 Physische Datenbankarchitektur Oracle-Dateiarten In einer Oracle-Datenbank werden die folgenden, unverzichtbaren Dateiarten unterschieden 1 2 : Kontrolldateien: Diese Dateien enthalten Informationen über die physische Datenbankstruktur, die u.a. für Backup- und Recovery-Aktionen sowie für die Konsistenzsicherung notwendig sind. Datendateien: Diese Dateien enthalten alle Benutzer- und Metadaten der Datenbank. 1 Vgl. [Ahrends06] Seite Vgl. [Best05] Kapitel 1, Seite 15

8 2 Architektur-Vergleich 8 Online-Redolog-Dateien: Diese Dateien enthalten sämtliche Transaktions- protokollinformationen, die zum Wiederherstellen der Datenbank benötigt werden. SQL Server-Dateiarten SQL Server verwendet drei Arten von Dateien 3 : Primäre Datendateien: Enthält die Startinformationen für die Datenbank und zeigt auf die anderen Dateien in der Datenbank. Sekundäre Datendateien: Sekundäre Datendateien sind optional, benutzerdefiniert und speichern Benutzerdaten. Protokolldateien: Diese Dateien enthalten sämtliche Transaktionsprotokollinformationen, die zum Wiederherstellen der Datenbank benötigt werden. 2.2 Logische Datenbankarchitektur Logische Speichereinheiten Oracle-Tablespaces Oracle-Datenbanken sind in logische Speichereinheiten (Tablespaces) unterteilt, die auf der physikalischen Ebene durch Datendateien repräsentiert werden 4. Durch die Trennung der logischen Architektur und der physikalischen Speicherung wird der gleiche Aufbau der Datenbank auf unterschiedlichen Plattformen ermöglicht. Tablespaces bestehen aus einer oder mehreren Datendateien. Jede Datendatei kann jeweils nur einem Tablespace angehören. Folgende Tablespaces sollten in einer Oracle 10g-Datenbank nicht fehlen: SYSTEM: Speichert die Tabellen, die die Kernfunktionalität der Datenbank unterstützen, beispielsweise Data Dictionary-Tabellen. (Obligatorisch) SYSAUX: Speichert zahlreiche Datenbankkomponenten wie beispielsweise das Enterprise Manager Repository. (Obligatorisch) 3 Vgl. [MSDN1] 4 Vgl. [Ahrends06] Seite 101

9 2 Architektur-Vergleich 9 TEMP: Der temporäre Tablespace wird verwendet, wenn eine SQL- Anweisung ausgeführt wird, bei der temporäre Segmente erstellt werden müssen (z. B. bei einer umfangreichen Sortierung oder einer Indexerstellung) 5. UNDOTBS: Ein Undo-Tablespace beinhaltet ausschließlich Undo-Segmente, deren Aufgabe es ist, den alten Zustand von Feldinhalten (before images) so lange zu speichern, bis der neue Zustand in der Datenbank festgeschrieben wurde. USERS: In diesem Tablespace werden permanente Benutzerobjekte und -daten gespeichert. SQL Server-Dateigruppen Jede Datendatei wird zu Verwaltungs- und Zuordnungszwecken in einer Dateigruppe gespeichert 6. Durch die Aufteilung der Daten auf mehrere Dateien und Dateigruppen können diese separat gesichert (Dateigruppensicherung) und wiederhergestellt werden. Jede Datei kann jeweils nur einer Dateigruppe angehören. Es gibt zwei Arten von Dateigruppen: Primäre Dateigruppe: Enthält die primäre Datendatei und alle anderen Dateien, die nicht explizit einer anderen Dateigruppe zugewiesen sind. Alle Seiten für die Systemtabellen werden in der primären Dateigruppe zugeordnet. Benutzerdefinierte Dateigruppe: Alle Dateigruppen, die mit Hilfe des FILEGROUP-Schlüsselwortes in der Anweisung CREATE DATABASE oder ALTER DATABASE angegeben werden. SQL Server-Systemdatenbanken In SQL Server wird eine Reihe von Datenbanken auf Systemebene verwendet die Systemdatenbanken, die für den Betrieb einer Serverinstanz von entscheidender Bedeutung sind. Jede SQL Server-Datenbank enthält die folgenden Systemdatenbanken: master-datenbank: Zeichnet alle Informationen auf Systemebene für eine Instanz von SQL Server auf. Dazu gehören Metadaten wie Anmeldekonten, Endpunkte, Verbindungsserver und Systemkonfigurationseinstellungen. 5 Vgl. [Best05] Kapitel 5, Seite 15 6 Vgl. [MSOD2]

10 2 Architektur-Vergleich 10 msdb-datenbank: Wird von SQL Server-Agent verwendet, um Termine für Warnungen und Aufträge zu planen. tempdb-datenbank: Ein Arbeitsbereich zum Speichern von temporären Objekten oder Zwischenresultsets. Die tempdb-systemdatenbank ist eine globale Ressource, die für alle Benutzer verfügbar ist, die mit der Instanz von SQL Server verbunden sind. Ressourcendatenbank: Eine schreibgeschützte Datenbank, die alle Systemobjekte enthält, die in SQL Server enthalten sind. model-datenbank: Wird als Vorlage für alle Datenbanken verwendet, die für die Instanz von SQL Server erstellt werden. Schema-Objekte Abschließend werden in der nachfolgenden Tabelle noch einmal einige Schema-Objekte dieser beiden Datenbanken verglichen. Weitere Schema- Objekte werden in Abschnitt 3.2 besprochen: Schema-Objekte von Oracle und SQL-Server Oracle SQL Server Datenbank Datenbank Schema Datenbank und Datenbankbesitzer (DBO) Tablespace Dateigruppe Benutzer Benutzer Rolle Gruppe/Rolle Tabelle Tabelle Temporäre Tabellen Temporäre Tabellen Cluster <nicht unterstützt> Column-level check constraint Column-level check constraint Column default Column default Unique-Schlüssel Unique-Schlüssel oder Identitätsmerkmal für die Zeile Primärschlüssel Primärschlüssel Fremdschlüssel Fremdschlüssel PL/SQL Prozedur T-SQL Gespeicherte Prozedur

11 2 Architektur-Vergleich 11 PL/SQL Funktion T-SQL Funktion Snapshot <nicht unterstützt> View View Tabelle 1: Schema-Objekte von Oracle und SQL-Server Instanzen Oracle-Instanz Ein Oracle-Datenbank-Server besteht aus einer Oracle-Datenbank und einer Oracle-Instanz 7. Oracle-Instanzen bestehen aus Memory-Strukturen, die als System Global Area (SGA) bezeichnet werden, sowie aus Hintergrundprozessen. Die Kombination aus SGA und Oracle- Hintergrundprozessen wird als Oracle-Instanz bezeichnet. Oracle-Instanzen sind immer mit einer einzelnen Datenbank verknüpft. Unter bestimmten Umständen können aber auch Oracle-Datenbanken mehrere Instanzen besitzen. SQL Server-Instanz Jede SQL Server-Instanz besteht aus einem Satz von Diensten mit bestimmten Einstellungen für Sortierungen und andere Optionen 8. Bei der Instanz kann es sich um eine Standardinstanz oder um eine benannte Instanz handeln. SQL Server-Instanzen können mit vielen Datenbanken verknüpft sein, wobei jede Instanz unabhängig von den anderen Instanzen ausgeführt wird. Zwar unterstützt der SQL Server 2005 mehrere Instanzen von SQL Server auf einem einzelnen Server oder Prozessor aber die Standardinstanz kann nur eine Instanz sein, alle anderen Instanzen müssen benannte Instanzen sein. 7 Vgl. [Best05] Kapitel 1, Seite 13 8 Vgl. [MSOD3]

12 3 Datenbankobjekte 12 3 Datenbankobjekte 3.1 Datentypzuordnungen Oracle-Datentypen und SQL Server-Datentypen stimmen nicht immer exakt überein. Für Fälle, in denen eine einzelne Datentypzuordnung unklar ist, gibt es noch alternative Datentypzuordnungen 9. Doch vorerst sollte überprüft werden, ob der SQL Server signifikantere Datentypen anbietet, damit nicht nachteilige Datentypen weiter verwendet werden. Weiterhin ist darauf zu achten, dass die Wertebereiche entweder identisch oder größer als die in Oracle verwendeten Datentypen sein müssen. Die folgende Tabelle zeigt die standardmäßige Zuordnung von Datentypen von Oracle zu SQL Server. Die Spalte "Alternativen" gibt an, ob alternative Zuordnungen verfügbar sind: Datentypzuordnungen von Oracle zu SQL Server Oracle-Datentyp SQL Server-Datentyp Alternativen BFILE VARBINARY(MAX) Ja BLOB VARBINARY(MAX) Ja CHAR([1-2000]) CHAR([1-2000]) Ja CLOB VARCHAR(MAX) Ja DATE DATETIME Ja FLOAT FLOAT Nein FLOAT([1-53]) FLOAT([1-53]) Nein FLOAT([54-126]) FLOAT Nein INT NUMERIC(38) Ja INTERVAL DATETIME Ja LONG VARCHAR(MAX) Ja LONG RAW IMAGE Ja NCHAR([1-1000]) NCHAR([1-1000]) Nein NCLOB NVARCHAR(MAX) Ja 9 [MSDN2]

13 3 Datenbankobjekte 13 LONG RAW IMAGE Ja NCHAR([1-1000]) NCHAR([1-1000]) Nein NCLOB NVARCHAR(MAX) Ja NUMBER FLOAT Ja NUMBER([1-38]) NUMERIC([1-38]) Nein NUMBER([0-38],[1-38]) NUMERIC([0-38],[1-38]) Ja NVARCHAR2([1-2000]) NVARCHAR([1-2000]) Nein RAW([1-2000]) VARBINARY([1-2000]) Nein REAL FLOAT Nein ROWID CHAR(18) Nein TIMESTAMP DATETIME Ja UROWID CHAR(18) Nein VARCHAR2([1-4000]) VARCHAR([1-4000]) Ja Tabelle 2: Datentypzuordnungen von Oracle zu SQL Server Die folgende Tabelle zeigt die standardmäßige Zuordnung von Datentypen von SQL Server zu Oracle: Datentypzuordnungen von SQL Server zu Oracle SQL Server-Datentyp Oracle-Datentyp BIGINT NUMBER(19,0) BINARY(1-2000) RAW(1-2000) BINARY( ) BLOB BIT NUMBER(1) CHAR(1-2000) CHAR(1-2000) CHAR( ) VARCHAR2( ) CHAR( ) CLOB DATETIME DATE DECIMAL(1-38, 0-38) NUMBER(1-38, 0-38) DOUBLE PRECISION FLOAT FLOAT FLOAT IMAGE BLOB INT NUMBER(10,0)

14 3 Datenbankobjekte 14 MONEY NUMBER(19,4) NCHAR(1-1000) CHAR(1-1000) NCHAR( ) NCLOB NTEXT NCLOB NUMERIC(1-38, 0-38) NUMBER(1-38, 0-38) NVARCHAR(1-1000) VARCHAR2(1-2000) NVARCHAR( ) NCLOB NVARCHAR(MAX) NCLOB REAL REAL SMALLDATETIME DATE SMALLINT NUMBER(5,0) SMALLMONEY NUMBER(10,4) SQL_VARIANT <nicht unterstützt> SYSNAME VARCHAR2(128) TEXT CLOB TIMESTAMP RAW(8) TINYINT NUMBER(3,0) UNIQUEIDENTIFIER CHAR(38) VARBINARY(1-2000) RAW(1-2000) VARBINARY( ) BLOB VARCHAR(1-4000) VARCHAR2(1-4000) VARCHAR( ) CLOB VARBINARY(MAX) BLOB VARCHAR(MAX) CLOB XML NCLOB Tabelle 3: Datentypzuordnungen von SQL Server zu Oracle Datum Während in SQL Server die Datentypen DATETIME und SMALLDATETIME für Datums- und Tageszeitangaben benutzt werden, stellt Oracle die Datentypen TIMESTAMP und DATE zur Verfügung 10 : 10 [MurDOC]

15 3 Datenbankobjekte 15 Datums- und Zeitangaben in SQL Server Datentyp Bereich Genauigkeit DATETIME SMALL- DATETIME Zwischen dem 1. Januar 1753 und dem 31. Dezember Zwischen dem 1. Januar 1900 und dem 6. Juni ,33 Millisekunden 1 Minute Tabelle 4: Datums- und Zeitangaben in SQL Server Datums- und Zeitangaben in Oracle Datentyp Bereich Genauigkeit TIME- STAMP DATE Zwischen dem 1. Januar 4712 v. Chr. und dem 31. Dezember 9999 n. Chr. Zwischen dem 1. Januar 4712 v. Chr. und dem 31. Dezember 9999 n. Chr. Ein einhundertmillionstel (1/ ) einer Sekunde 1 Sekunde Tabelle 5: Datums- und Zeitangaben in Oracle Datumskonvertierungen sollten manuell erstellt werden, weil Konvertierungsprogramme nicht die Logik hinter einer Tabelle verstehen können. Wenn beispielsweise eine Spalte Geburtstag mit dem Oracle-Datentyp DATE einer Tabelle Personen in eine Spalte mit dem SQL Server-Datentyp DATETIME konvertiert wird, dann werden diese Spalten noch mit überflüssigen Zeitangaben aufgeführt (Siehe Abschnitt 5.3). FLOAT und NUMBER Die Anzahl der Dezimalstellen (scale) und die Genauigkeit (precision), die während der Zuordnung der Datentypen FLOAT und NUMBER angegeben werden, sind von den Parametern abhängig, die in der Spalte der Oracle- Datenbank angegeben wurde, die diese Datentypen verwendet. Die Zahl 123,45 hat z. B. eine Genauigkeit von 5 (Ziffern) und 2 Dezimalstellen. Bei Oracle können Zahlen mit Werten für 'scale' größer als 'precision' definiert werden, z. B. NUMBER(4,5). In SQL Server muss jedoch 'precision' größer oder gleich 'scale' sein. Um sicherzustellen, dass keine Daten abgeschnitten werden, wenn bei Oracle 'scale' größer ist als 'precision', sollte

16 3 Datenbankobjekte 16 'precision' bei der Zuordnung auf denselben Wert festgelegt werden wie 'scale': NUMBER(4,5) wird also beispielsweise NUMERIC(5,5) zugeordnet 11. LOB-Typen (Large Object) Oracle unterstützt bis zu 4 Gigabyte (GB), SQL Server bis zu 2 GB 12. Daten aus Oracle, die über 2 GB sind, müssen deshalb abgeschnitten werden. Indizes Indizes müssen neu generiert werden, wobei geprüft werden sollte, welche Optimierungen in SQL Server möglich sind. NULL-Verhalten Unique Für Spalten, die von Unique-Einschränkungen betroffen sind, muss ein Wert ungleich NULL angegeben sein. Oracle und SQL Server verarbeiten NULL- Werte unterschiedlich: Oracle lässt mehrere Zeilen mit NULL-Werten für Spalten zu, bei denen NULL-Werte zulässig sind und die in UNIQUE- Einschränkungen oder -Indizes eingeschlossen sind. SQL Server erzwingt die Eindeutigkeit, indem nur eine einzige Zeile mit einem NULL-Wert für eine Spalte zulässig ist. ORDER BY-Klauseln Auch hier sollten einige Punkte über die unterschiedliche Behandlung von NULL-Werten in Oracle und SQL Server beachtet werden: o In SQL Server sind NULL-Werte die niedrigsten Werte in einer geordneten Liste. In einer aufsteigenden Liste stehen NULL-Werte an erster Stelle o In Oracle sind NULL-Werte die größten Werte in einer geordneten Liste. Als default stehen NULL-Werte in einer aufsteigenden Liste an erster Stelle [MSDN2]

17 3 Datenbankobjekte 17 ISNULL in String-Konkatenation Oracle und SQL Server geben unterschiedliche Ergebnisse zurück wenn in String-Konkatenationen NULL-Werte enthalten sind. Oracle behandelt die NULL-Werte wie einen leeren Zeichensatz, während der SQL Server NULL zurück gibt. Die folgende Tabelle zeigt, dass in Oracle NULL niemals äquivalent ist mit Null: NULL-Konstrukte in Oracle und SQL Server NULL-Konstrukt SQL Server Oracle where col1 = NULL datenabhängig FALSE where col1!= NULL datenabhängig TRUE where col1 IS NULL datenabhängig datenabhängig where col1 IS NOT NULL datenabhängig datenabhängig where NULL = NULL TRUE FALSE Tabelle 6: NULL-Konstrukte in Oracle und SQL Server Falls solche SQL Server-Abfragen vorliegen WHERE col1 = NULL sollten diese in solche Oracle-Abfragen umgeschrieben werden WHERE col1 IS NULL 3.2 Unterschiede zwischen ANSI-SQL und ORACLE- SQL Syntaxunterschiede Oracle Database 10g unterstützt den ANSI SQL:2003-Standard, während Microsoft SQL Server 2005 den ANSI SQL:1999-Standard unterstützt. Bei Oracle wird aber dennoch in der Praxis meistens die ORACLE-Syntax verwendet, die sich in entscheidenden Punkten von dem ANSI-Standard unterscheidet. Die folgende Tabelle zeigt die in Oracle und SQL Server verwendete unterschiedliche Syntax für dieselbe SQL-Anweisung:

18 3 Datenbankobjekte 18 SQL-Syntaxunterschiede Beschreibung Oracle SQL Server Left Outer Join Bis Oracle 9i nur: WHERE col1 = col2(+) Ab Oracle 9i: FROM tab1 LEFT OUTER JOIN tab2 ON tab1.col1 = tab2.col2 Right Outer Join Bis Oracle 9i nur: WHERE col1(+) = col2 Ab Oracle 9i: FROM tab1 RIGHT OUTER JOIN tab2 ON tab1.col1 = tab2.col2 Full Outer Join Ab Oracle 9i: FROM tab1 FULL OUTER JOIN tab2 ON tab1.col1 = tab2.col2 SELECT ohne SELECT 'hello world' FROM FROM DUAL; (Pseudo-Tabelle DUAL nötig) INSERT INSERT INTO [user.]{table view}[@dblink][(column [, column]...)]{values (expression [, expression]...) query...}; <INTO ist obligatorisch> Transformation CREATE TABLE... AS großer SELECT... Datenmengen Subtraktion SELECT... MINUS zweier SELECT... SELECTS FROM tab1 LEFT OUTER JOIN tab2 ON tab1.col1 = tab2.col2 FROM tab1 RIGHT OUTER JOIN tab2 ON tab1.col1 = tab2.col2 FROM tab1 FULL OUTER JOIN tab2 ON tab1.col1 = tab2.col2 SELECT 'hello world' oder SELECT 3*6 INSERT [INTO] [[database.]owner.] {table view}[(column [, column]...)]{values (expression [,expression]...) query} <INTO ist optional> SELECT... INTO SELECT... EXCEPT SELECT...

19 3 Datenbankobjekte 19 SELECT col1, col2, col3 INTO tab1 FROM tab2 WHERE... ALTER TABLE table_name DROP COLUMN column_name <nicht unterstützt> GRANT SELECT... IDENTITY (s, i) S = Anfangswert i = inkrementeller Wert Siehe Abschnitt 5.4 Lösungsmöglichkeit: Siehe Abschnitt 5.4 SAVE TRANSACTION TABLOCK, HOLDLOCK TABLOCKX, HOLDLOCK ROWLOCK, HOLDLOCK ROWLOCK, XLOCK, HOLDLOCK TABLOCK, XLOCK, HOLDLOCK SELECT INTO- INSERT INTO tab1 Anweisung SELECT col1,col2,col3 FROM tab2 WHERE... Spalte löschen Ab Oracle 8i: ALTER TABLE table_name DROP COLUMN column_name UNUSE Verschachtelte Ab Oracle 9i: Tabellen (nested NESTED TABLE tab1 tables) store AS tab2 Readonly VIEW CREATE VIEW... WITH READONLY Sequence CREATE SEQUENCE seq_name... Synonym CREATE SYNONYM s_name FOR obj_name; Sicherungspunkt SAVEPOINT festlegen Lockmodi SHARE EXCLUSIVE ROW SHARE SHARE UPDATE = ROW SHARE ROW EXCLUSIVE SHARE ROW EXCLUSIVE Lockmode- Optionen Zeitspanne zur Aufhebung einer Sperre festlegen Reservierung des Indexbereichs ROW-Level PARTITION, NOWAIT Keine Zeitspannenangabe möglich, außer NOWAIT agiert wie "LOCK_TIMEOUT 0" PCTFREE=0 <keine Entsprechung> <nicht unterstützt> SET LOCK_TIMEOUT timeout_period FILLFACTOR=100

20 3 Datenbankobjekte 20 DESCRIBE DESCRIBE table_name sp_help oder sp_columns (SQLPlus-Befehl) Pseudospalte ROWID SELECT ROWID, SUBSTR(ROWID, 1, 6) object,... <keine Entsprechung> Lösungsmöglichkeit: Siehe Abschnitt 5.4 Pseudospalte ROWNUM SELECT ROWNUM, empno, ename FROM scott.emp e... <keine Entsprechung> Lösungsmöglichkeit: Siehe Abschnitt 5.4 Spalten-Alias SELECT col1 employees FROM table SELECT employees=col1 FROM table Alias SELECT name alias_name SELECT name AS alias_name Tabelle 7: SQL-Syntaxunterschiede 13 Syntaxunterschiede der prozeduralen Spracherweiterungen PL/SQL und T-SQL sind rein herstellerbezogene prozedurale Erweiterungen des SQL-Standards. Sie bieten zwar viele derselben Konstrukte aber haben jedoch außer die Grundkonzeption und Funktionalität betreffend hinsichtlich der Sprachsyntax nicht allzu viele Gemeinsamkeiten. Die folgende Tabelle zeigt einige Syntaxunterschiede von PL/SQL und T-SQL: Syntaxunterschiede von PL/SQL und T-SQL Beschreibung Oracle PL/SQL SQL Server T-SQL Lokale Variable DECLARE var_name type <nicht unterstützt> in DECLARE initialisieren := value; Konstante DECLARE var_name <nicht unterstützt> deklarieren CONSTANT type := value; Variable zuweisen Var_name := value SELECT value INTO = value = value var_name %TYPE DECLARE guthaben NUMBER(7,2); schuld guthaben%type; <nicht unterstützt> 13 Vgl. [MSTN1]

21 3 Datenbankobjekte 21 Collection Cursor deklarieren Cursor in eine Variable zuweisen Cursor öffnen Cursorverweis entfernen If-Anweisung TYPE type_name IS TABLE OF element_type [NOT NULL]; CURSOR cur_name (params) IS SELECT; FETCH cur_name INTO var_name OPEN cur_name (params); <nicht erforderlich> IF... THEN, ELSIF... THEN, ELSE, ENDIF; <nicht unterstützt> Lösungsmöglichkeit: Siehe Abschnitt 5.3 DECLARE cur_name CURSOR (params) FOR SELECT FETCH (params) FROM cur_name OPEN cur_name DEALLOCATE cur_name IF... [BEGIN... END] ELSE... [BEGIN... END] ELSE IF... CASE... While-Schleife Schleifenkontrolle Schleifenabbruch While-Schleifen- Neustart Print output Raise error Pakete Trigger Alternativ: CASE WHEN... THEN...; ELSE... ; END CASE; WHILE... LOOP END LOOP; FOR... END LOOP; LOOP... END LOOP; EXIT, EXIT WHEN <nicht unterstützt> Realisiert über die Funktion: DBMS_OUTPUT.PUT_LINE RAISE_APPLICATION_ERRO R CREATE OR REPLACE PACKAGE package_name BEFORE TRIGGER AFTER TRIGGER INSTEAD OF TRIGGER ROW LEVEL TRIGGER WHILE... [BEGIN... END] <nicht unterstützt> BREAK CONTINUE PRINT RAISERROR <nicht unterstützt> Siehe Abschnitt 5.4 INSTEAD OF TRIGGER AFTER TRIGGER INSTEAD OF TRIGGER imitiert durch CURSOR Abschlusszeichen Semikolon (;) <nicht erforderlich> Tabelle 8: Syntaxunterschiede von PL/SQL und T-SQL

22 3 Datenbankobjekte 22 Über weitere Möglichkeiten für Syntaxzuordnungen und Lösungsmöglichkeiten für einige in SQL Server nicht unterstützte Syntaxzuordnungen sei nochmals auf Abschnitt 5.4 verwiesen. Operatoren Die meisten Operatoren in Oracle und SQL Server stimmen überein. Hier nur ein Operator, der sich unterscheidet 14 : Operatorunterschiede Beschreibung Oracle SQL Server Konkatenation string1 string2 string1 + string2 Tabelle 9: Operatorunterschiede 3.3 Namenskollisionen Reservierte Schlüsselwörter Beide Datenbankmanagementsysteme verwenden eine Fülle von reservierten Schlüsselwörtern zum Definieren, Bearbeiten und Zugreifen auf Datenbanken 15. Keine dieser reservierten Schlüsselwörter sollten für Objektnamen (Tabellen, Indizes, Views, ) und Objektbezeichner verwendet werden. Doch einige Objekte, die ursprünglich in Oracle erstellt wurden, könnten Benennungen aufweisen, die für reservierte Schlüsselwörter in SQL Server verwendet werden. Damit keine Namenskollisionen auftreten, sollten diese Objektnamen und Objektbezeichner vor einer Migration umbenannt werden. Die folgende Tabelle führt reservierte Schlüsselwörter von SQL Server auf, die aber in Oracle als Objektnamen und bezeichner verwendet werden dürfen, da sie in Oracle nicht als reservierte Schlüsselwörter deklariert wurden 16 : 14 Vgl. [MSTN1] 15 Vgl. [MSDN3] 16 Vergleiche hierzu alle reservierten Schlüsselwörter in der Oracle-Onlinedokumentation unter [OraDOC1] und [OraDOC2]

23 3 Datenbankobjekte 23 Reservierte Schlüsselwörter des SQL Server BROWSE IDENTITY READTEXT CLUSTERED IDENTITY_INSERT RECONFIGURE COLLATE IDENTITYCOL REPLICATION COMPUTE INNER RESTORE CONTAINS KILL RESTRICT CONTAINSTABLE LEFT REVERT CROSS LINENO ROWCOUNT CURRENT_DATE LOAD ROWGUIDCOL CURRENT_TIME NOCHECK RULE CURRENT_TIMESTAMP NONCLUSTERED SESSION_USER CURRENT_USER OFFSETS SETUSER DBCC OPENDATASOURCE SYSTEM_USER DEALLOCATE OPENQUERY TABLESAMPLE DENY OPENROWSET TEXTSIZE DISK OPENXML TOP DISTRIBUTED OUTER TRAN DUMMYRECONFIGURE OVER TSEQUAL FILLFACTOR PERCENT UNPIVOT FREETEXT PIVOT UPDATETEXT FREETEXTTABLE PRINT WAITFOR FULL PROC WRITETEXT HOLDLOCK RAISERROR Tabelle 10: Reservierte Schlüsselwörter des SQL Server Reservierte ODBC-Schlüsselwörter Die folgenden Wörter sind für die Verwendung in ODBC-Funktionsaufrufen reserviert. Damit in SQL Server die Kompatibilität mit Treibern sichergestellt ist, die die zentrale (core) SQL-Grammatik unterstützen, sollten diese Schlüsselwörter nicht in dem Quellsystem als Objektnamen und bezeichner auftauchen 17. Diese Tabelle listet die reservierten ODBC-Schlüsselwörter des SQL Server auf, die in Oracle nicht als reservierte Schlüsselwörter auftreten: Reservierte ODBC-Schlüsselwörter des SQL Server ABSOLUTE DIAGNOSTICS PAD ACTION DISCONNECT PARTIAL ADA DOMAIN POSITION ARE END-EXEC PREPARE 17 [MSDN3]