Heinz Gerd Raymans Oracle Programmierung

EDITION Oracle
Oracle 8i und Java - Oracle JDeveloper 2.0 als Entwicklungswerkzeug

Steven Ponndorf / Wolf-Gert Matthäus
Oracle 8 für den DBA - Verwalten, optimieren, vernetzen

Uwe Herrmann / Dierk Lenz / Günter Unbescheid
Oracle 7.3 - Verwalten, optimieren, vernetzen

Uwe Herrmann / Dierk Lenz / Günter Unbescheid
Oracle8 effizient einsetzen - Verteilung und Betrieb

leistungsfähiger Oracle8-Anwendungen
Andreas Christiansen / Michael Höding / Gunter Saake / Claus Rautenstrauch
Oracle-Programmierung - Datenbankprogrammierung und -administration

Heinz-Gerd Raymans
Oracle Designer R 6i und Developer 6i - Professionelle Modulentwicklung

Werner Hasselberg (Erscheinungstermin: Januar 2001)
Oracle Developer 6i - Softwareprojekte für das Internet-Computing

Steven Ponndorf / Wolf-Gert Matthäus (Erscheinungstermin: März 2001)
Heinz-Gerd Raymans
Oracle-Programmierung
Datenbankprogrammierung und -administration
Bitte beachten Sie: Der originalen Printversion liegt eine CD-ROM bei.
In der vorliegenden elektronischen Version ist die Lieferung einer CD-ROM nicht enthalten.
Alle Hinweise und alle Verweise auf die CD-ROM sind ungültig.
ADDISON-WESLEY
An imprint of Pearson Education

München Boston San Francisco Harlow, England
Don Mills, Ontario Sydney Mexico City
Madrid Amsterdam
Die Deutsche Bibliothek CIP-Einheitsaufnahme
Ein Titeldatensatz für diese Publikation ist bei
Der Deutschen Bibliothek erhältlich
Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz
veröffentlicht.
Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.
Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen.
Trotzdem können Fehler nicht vollständig ausgeschlossen werden.
Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine
juristische Verantwortung noch irgendeine Haftung übernehmen.
Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.
Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elek-
tronischen Medien.
Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.
Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleich-
zeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden.
Umwelthinweis:
Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.
Die Einschrumpffolie zum Schutz vor Verschmutzung ist aus umweltverträglichem und
recyclingfähigem PE-Material.
10 9 8 7 6 5 4 3 2 1
04 03 02 01
ISBN 3-8273-1733-9
© 2001 by Addison-Wesley Verlag

Ein Imprint der Pearson Education Deutschland GmbH
Martin-Kollar-Straße 1012, D-81829 München/Germany
Alle Rechte vorbehalten
Einbandgestaltung: Hommer Design, Haar bei München
Lektorat: Martin Asbach, masbach@pearson.de
Herstellung: Elisabeth Egger, eegger@pearson.de
Korrektorat: Christine Depta, Freising
Satz: mediaService, Siegen
Druck und Verarbeitung: Bercker, Kevelaer
Printed in Germany
Inhaltsverzeichnis
Vorwort .................................................................................................... 9
V.1 Zum Inhalt ...............................................................................................10
1 Oracle – erste Schritte ............................................................................ 13
1.1 Grundlagen..............................................................................................13
1.1.1 Klienten und Diener..................................................................14
1.1.2 Aufbau des Oracle-DBMS..........................................................18
1.1.3 Aufbau einer Oracle-Datenbank ................................................20
1.2 Installation ...............................................................................................24
1.2.1 Der Installationsvorgang ...........................................................25
1.2.2 Installation der Version 8 ..........................................................26
1.2.3 Installation von 8i .....................................................................32
1.3 Dienste unter Windows-NT ......................................................................35
1.4 Verbindung zur Datenbank herstellen ......................................................37
1.4.1 Einführung in SQL*Net bzw. Net8 ............................................38
1.4.2 Verbindung zur „Starterdatenbank“ herstellen..........................40
1.4.3 Konfiguration mit Hilfe von Net8 Easy Config ...........................48
1.4.4 Oracle-Networking mit Hilfe des Net8 Assistant ........................53
1.4.5 Ausblick ....................................................................................60
1.5 Erstellen einer Datenbank .........................................................................62
1.5.1 Struktur einer Oracle-Datenbank...............................................62
1.5.2 Das manuelle Verfahren ............................................................65
1.5.3 Der Oracle Database Assistant ..................................................72
1.5.4 Automatische Generierung unter NT ........................................86
1.6 Administrierung der Datenbanken............................................................87
1.6.1 Instanz starten und stoppen .....................................................88
1.6.2 Datenbank öffnen und schließen ..............................................89
1.6.3 Löschen einer Datenbank .........................................................91
1.7 Der Oracle Storage Manager ....................................................................92
1.8 SQL*Plus ..................................................................................................95
1.8.1 Abfragen eingeben und ausführen............................................97
1.8.2 SQL*Plus als Skriptinterpreter..................................................100
1.9 Das SQL-Worksheet................................................................................105
2 Datenbankobjekte in einer Oracle-DB ...................................................109
2.1 Der Oracle-Schema-Manager .................................................................109
2.2 Beschreibung der Objekte ......................................................................113
2.2.1 Array-Typ (Array Types) ..........................................................114
2.2.2 Cluster (Clusters) ....................................................................119
6 Inhaltsverzeichnis
2.2.3 Datenbank-Link (Database Links) ............................................120

2.2.4 Funktion (Functions)...............................................................123
2.2.5 Index (Indexes).......................................................................127
2.2.6 Objekttyp (Object Types) .......................................................132
2.2.7 Paketrumpf (Package bodies)..................................................137
2.2.8 Paket (Packages) .....................................................................138
2.2.9 Prozedur (Procedures) ............................................................149
2.2.10 Warteschlangentabelle (Queue Tables) ...................................151
2.2.11 Abgleichengruppe (Refresh groups)........................................156
2.2.12 Sequenz (Sequences)..............................................................156
2.2.13 Log Materialisierte View (Snapshot logs).................................160
2.2.14 Materialisierte View (Snapshots) .............................................160
2.2.15 Synonym (Synonyms).............................................................170
2.2.16 Tabellentyp (Table Types).......................................................172
2.2.17 Tabelle (Tables) ......................................................................185
2.2.18 Trigger (Triggers) ...................................................................203
2.2.19 Ansicht (Views) .......................................................................212
2.2.20 Zusammenfassung..................................................................216
2.3 Die Beispieldatenbank anlegen ...............................................................218
2.3.1 Anlage des Schema-Eigners ....................................................219
2.3.2 Verwalten der Tablespaces......................................................222
2.3.3 Anlegen des Schemas .............................................................223
2.4 Datenmigration......................................................................................230
2.4.1 Variationsmöglichkeiten..........................................................230
2.4.2 Laden unserer Beispiel-DB.......................................................233
2.4.3 Der Data Manager..................................................................236
2.4.4 Laden der Stammdaten per SQL*Loader .................................239
2.4.5 Wie geht es weiter? ................................................................247
3 Abfragen ...............................................................................................249
3.1 Einfache Auswahlabfragen......................................................................249
3.1.1 Struktur einer Auswahlabfrage ................................................250
3.1.2 Where-Bedingungen...............................................................254
3.1.3 Ergebnisse sortieren ................................................................259
3.1.4 Gruppierungen.......................................................................261
3.1.5 Spalten vertexten ...................................................................265
3.2 Verknüpfungen ......................................................................................266
3.2.1 Inner-Joins ..............................................................................268
3.2.2 Unterabfragen ........................................................................271
3.2.3 Outer-Joins .............................................................................278
3.2.4 Mengenoperationen ...............................................................281
3.2.5 Hierarchische Abfragen...........................................................287
Inhaltsverzeichnis 7
3.3 Änderungsabfragen................................................................................298
3.3.1 Ändern von Daten ..................................................................298
3.3.2 Löschen von Daten .................................................................301
3.3.3 Einfügen von Daten ................................................................303
3.3.4 Sperren von Datensätzen ........................................................306
3.3.5 Erstellen eines Änderungscursors ............................................309
3.3.6 Transaktionen .........................................................................319
3.4 Tuning von Abfragen .............................................................................324
3.4.1 Abfrageoptimierung ...............................................................325
3.4.2 Ausführungspläne...................................................................329
3.4.3 Ein paar Grundregeln für die Erstellung von Abfragen.............336
3.4.4 Verwenden von Hints .............................................................341
3.5 Data Dictionary Views ............................................................................346
3.5.1 Analyse der Datenbankobjekte................................................347
3.5.2 Aktivitäten in der Datenbank abfragen....................................352
3.5.3 Zugriffsrechte entschlüsseln ....................................................355
4 Benutzer und Rollen ..............................................................................357
4.1 Einführung in die Benutzerverwaltung....................................................357
4.1.1 Das Rollenkonzept ..................................................................359
4.1.2 Der Oracle Security Manager ..................................................359
4.2 Benutzerverwaltung mit SQL..................................................................361
4.2.1 Einen Benutzer bearbeiten ......................................................361
4.2.2 Rollen anlegen und bearbeiten ...............................................363
4.2.3 Profile anlegen und bearbeiten ...............................................363
4.3 Rechtevergabe mit SQL ..........................................................................366
4.3.1 Vergabe von Einzelrechten und Rollen ....................................366
4.3.2 Zugriffsschutz auf Datensatzebene..........................................370
4.3.3 Benutzerverwaltung in der Praxis ............................................375
4.4 Auswertung der Benutzerprofile .............................................................375
5 PL/SQL-Programmierung ......................................................................381
5.1 Einführung in PL/SQL .............................................................................381
5.1.1 Allgemeines ............................................................................381
5.1.2 Blockstruktur ..........................................................................384
5.1.3 Datentypen ............................................................................386
5.1.4 Funktionen .............................................................................398
5.1.5 Ausgabe von Meldungen........................................................410
5.1.6 Konditionalbedingungen ........................................................412
5.1.7 Schleifen.................................................................................415
5.1.8 Datenbankabfragen ................................................................418
5.1.9 Fehlerbehandlung ..................................................................429
5.1.10 Dateiverarbeitung...................................................................441
5.1.11 Pipes.......................................................................................446
5.1.12 Verwenden von PL/SQL ..........................................................451
8 Inhaltsverzeichnis
5.2 Anwendungsbeispiele.............................................................................454
5.2.1 Benutzerverwaltung................................................................454
5.2.2 Änderungsprotokollierung ......................................................460
5.2.3 Komplexe Integritätsbedingungen..........................................465
5.2.4 Exporthilfe ..............................................................................475
6 Anwendungsentwicklung ......................................................................481
6.1 Grundlagen............................................................................................481
6.1.1 ODBC-Verbindung .................................................................482
6.1.2 Verwenden der Oracle-Objekte...............................................491
Stichwortverzeichnis .............................................................................495
Vorwort
Noch ein Buch über Oracle?! Nun, in einem haben Sie sicher Recht: Bücher über
Oracle gibt es sicherlich eine ganze Menge. Aber als ich im Sommer 1998 intensi-
veren Kontakt zu diesem Datenbanksystem bekam, hätte ich mir ein solches Buch
gewünscht. Ich habe es gesucht, aber nicht gefunden – das ist einer der Gründe,
warum ich es hier schreibe.
Als ich als freiberuflicher Berater im Rahmen eines PeopleSoft-Projekts engen Kon-
takt zu Oracle bekam, da hatte ich neben umfangreicher Programmiererfahrung
und detaillierten SQL-Kenntnissen auch weitreichende Erfahrungen mit verschie-
denen Datenbanksystemen, beispielsweise Sybase oder dem Microsoft SQL-Server.
Wenn Sie auf mein oben genanntes Datum geachtet haben und sich ein wenig aus-
kennen, dann werden Sie jetzt sagen „damals waren die beiden Server doch nahezu
gleich“. Stimmt genau, und damit sind wir der eingangs genannten Fragestellung
wieder ein Stückchen näher gekommen.
Beim Umgang mit Oracle war nämlich vieles anders, als bei den bisherigen DBMS-
Systemen. Die Werkzeuge sind andere, die Struktur der Datenbank (Schema, Table-
space) ist anders, Abfragen müssen zum Teil anders gestaltet werden. Anders ausge-
drückt: Es gibt andere Restriktionen, aber auch andere Möglichkeiten. Diese auf
einem Blick zu erkennen und umzusetzen ist nicht ganz einfach, und genau hier
soll dieses Buch helfen.
Was hat man denn für Möglichkeiten, wenn man im Rahmen eines Projekts auf
eine Datenbank stößt, mit der man sich bisher noch gar nicht oder zumindest
nicht regelmäßig bzw. nicht so oft beschäftigt hat? Jedes Mal einen Kurs besuchen?
Wohl dem, der diese Möglichkeiten hat. Das Handbuch lesen? Ich wünsche Ihnen
bei Oracle viel Spaß dabei und glauben Sie mir: Die Bibel können Sie leichter lesen;
außerdem ist sie auch noch weniger umfangreich. Die einzige Variante ist, sich mal
wieder möglichst schnell per „Try and Error“ einzuarbeiten. Ein bisschen Hilfe
kann hierbei aber nicht schaden, und genau diese halten Sie gerade in Ihren Hän-
den.
Ich betrachte eine Datenbank immer als Werkzeug, als Mittel zum Zweck, mehr
oder weniger Datensätze irgendwo zu speichern und bei Bedarf auch wiederzufin-
den. Genau wie das komplexe Thema Netzwerk, gehe ich in meinen Projekten
immer davon aus, dass diese Dinge funktionieren und sich kompetente Kollegen
um die Details kümmern. Ich bin eher für die Lösung irgendwelcher Anwenderpro-
bleme zuständig. Ich weiß, was man mit einer Bohrmaschine alles machen kann,
aber muss ich deshalb auch wissen, aus wie vielen Teilen meine Bohrmaschine
besteht, wie man sie in alle Einzelteile zerlegen und wieder zusammensetzen kann?
Ich denke nicht, Stecker rein muss reichen; danach kann ich ein schönes Loch boh-
ren.
10 Vorwort
Genau aus diesem Blickwinkel ist dieses Buch aufgebaut. Bestimmte Themen, für
die es in der Praxis Datenbankadministratoren und Netzwerkbetreuer gibt, werden
ganz bewusst nur grob skizziert oder sogar ganz weggelassen. Gleiches gilt für
Funktionen, die in der Praxis nur selten vorkommen und für die Sie, wenn Sie die
Grundzüge von Oracle erst einmal beherrschen, schnell Informationen in den
Handbüchern finden. Dieser Workshop kooperiert also mit der Dokumentation des
Herstellers, er versteht sich also nicht als Ersatz, sondern lediglich als Ergänzung
der ziemlich umfangreichen Online-Handbücher. Er soll Ihnen helfen, sich in die
wichtigsten Themen schnell und mit Hilfe pragmatischer Beispiele einzuarbeiten.
Abschließend möchte ich in diesem Vorwort natürlich alle erwähnen, die mich zu
diesem Buch inspiriert oder bei der Erstellung unterstützt haben. Da sind zunächst
einmal die netten Kollegen des letzten Deutschen Bank-Projekts: warum soll ich
nicht mal all das aufschreiben, was ich in den letzten dreißig Monaten erzählt
habe. Dem letzten Projekt, der Einführung von PeopleSoft, kommt natürlich insge-
samt eine tragende Rolle zu, denn es lieferte einige der in diesem Buch aufgearbei-
teten Anregungen und Beispiele.
Erwähnen möchte ich auch meine beiden Kinder: euch traf es mal wieder am meis-
ten, als Papa in den letzten Wochen noch weniger Zeit als sonst hatte.
Ich wünsche Ihnen nun viel Spaß und Erfolg beim Lesen und Durcharbeiten dieses
Buches.
Ihr
Heinz-Gerd Raymans
V.1 Zum Inhalt

Bevor ich etwas zum Inhalt sage, möchte ich noch vorwegnehmen, dass alle Bei-
spiele und Erklärungen zunächst mit einer 8er-Version und zum Abschluss noch
einmal mit der Version Oracle8i Release 2 (Version 8.1.6) überprüft wurden. Aus
diesem Grund wurden im Nachhinein noch verschiedene Passagen erweitert, so
dass Sie mit diesem Buch auch ein Vergleichswerk für die beiden zur Zeit noch auf
dem Markt befindlichen Versionen besitzen. Auf der anderen Seite sind viele der
hier angesprochenen Themen relativ versionsstabil und gelten vielleicht abgese-
hen von den Bildern und einigen Programmnamen für alle 8er-Versionen bzw. in
Teilen sogar für eine Datenbank der Version 7.
Das Buch hat also vornehmlich das klassische Datenbankgeschäft in Form von
SQL, Views, Triggern usw. im Auge und überlässt die neuen 8i-Erweiterungen wie
Internet-Integration, JDeveloper und Java anderen Werken, die sich schwerpunkt-
mäßig mit diesen Themen beschäftigen (z.B. Oracle 8i und Java, ADDISON-WES-
LEY, ISBN 3-8273-1485-2).
Im ersten Teil des Workshops „Oracle – erste Schritte “ geht es neben einigen allge-
meinen Grundlagen vor allem um die Installation von Oracle, beispielsweise auf
einem NT-Client (z.B. Notebook) oder Server mit anschließender Erstellung einer
eigenen Datenbank und deren Einbindung in das Oracle-Netzwerk (Net8). Sowohl
Zum Inhalt 11
bei der Erstellung der Datenbank, als auch bei deren Einbindung in das Netzwerk
werden Sie verschiedene Methoden kennen lernen, um diese Aufgaben manuell
oder mit Hilfe des einen oder anderen Werkzeugs zu erledigen.
Mit Hilfe des zweiten Hauptkapitels erhalten Sie einen Überblick über die in Oracle
verfügbaren Datenbankobjekte. Zunächst werden die einzelnen Objekte aufgezählt
bzw. kurz beschrieben und im weiteren Verlauf wird die im Kapitel 1 erstellte
Datenbank mit Leben gefüllt, d.h. die üblicherweise benötigten Tabellen und Indi-
ces werden angelegt. Abschließend wird die Datenbank mit Hilfe der auf der CD
befindlichen Daten gefüllt. Auch hierzu lernen Sie verschiedene Methoden, vor
allem auch mehrere Varianten zur Verwendung des Oracle-Import-Managers ken-
nen.
Der nächste bzw. dritte Teil des Buches widmet sich dem komplexen Thema Abfra-
gen. Ausgehend von einfachen Auswahlabfragen geht der Streifzug weiter durch
die Welt der Verknüpfungen (Joins) und mündet danach in den Komplex der Ände-
rungsabfragen inklusive dem Erstellen von Cursorn zur Durchführung von Daten-
bankänderungen. Abgerundet wird der ganze Themenkomplex mit einigen Aus-
führungen und Tipps zum Thema Abfragetuning und verschiedenen Beispielen zur
Anwendung der verfügbaren Data-Dictionary-Views, mit deren Hilfe Sie das Ora-
cle-System bzw. Ihre Datenbank analysieren können.
Dem Thema Benutzter- und Rollenprofile widmet sich der vierte Teil des Buches.
Hier lernen Sie die wichtigsten Ausprägungen dieser Profile mitsamt verschiedener
Verfahrensweisen zu deren Verwaltung kennen.
Im fünften Buchteil finden Sie eine Einführung in die PL/SQL-Programmierung.
Gleichgültig ob es immer gleich um die Programmierung von Prozeduren oder
Funktionen oder nur um die Erstellung größerer Skripts oder komplexerer Ände-
rungscursors geht: mit PL/SQL haben Sie eine schier unerschöpflichen Menge von
Möglichkeiten. Abgeschlossen wird das Kapitel mit verschiedenen Anwendungs-
beispielen, beispielsweise einer universellen Exportfunktion.
Der letzte Teil des Buches nähert sich noch einmal der Anwendungsentwicklung.
Neben ein paar allgemeinen Hinweisen finden Sie hier auch Beispiele wie Sie mit
Hilfe von ODBC oder den Oracle Objects im Handumdrehen leistungsfähige Front-
End-Anwendungen erstellen können. Als Demonstrationsobjekt finden Sie unter
anderem eine Funktion, mit deren Hilfe Sie von Excel aus Abfragen in der Oracle-
Datenbank starten können.
Nun folgt zum Abschluss noch ein Hinweis in eigener Sache. Die meisten Dinge im
Leben sind nicht perfekt, das gilt vielleicht auch für den einen oder anderen Satz
oder Erklärung in diesem Buch. Bedenken Sie, dass wenn man solche Bücher neben
seiner normalen Arbeit schreibt, der letzte Eintrag im Windows-Ereignisprotokoll
häufig knapp vor oder weit hinter 0:00 liegt. Vielleicht gibt es aber auch ein
Thema, das eigentlich gut in dieses Buchkonzept passt, zur Zeit aber überhaupt
nicht behandelt wird. Was ich eigentlich sagen will ist, dass gute Ideen, konstruk-
tive Kritik, interessante Beispiele aber auch Lob immer willkommen sind und wenn
Sie wollen, dann können Sie mir Ihre Anregungen und Bemerkungen direkt an die
Adresse heinz-gerd.raymans@raymans-consulting.de zusenden, doch nun wünsche
ich Ihnen erst einmal viel Spaß bei der Arbeit.
1 Oracle – erste Schritte
Ich finde, dass auch ein technisches Buch einen Spannungsbogen haben sollte. In
diesem Buch beginnt er im Kapitel „Grundlagen“ mit der Erläuterung verschiede-
ner Konzepte und Grundbegriffe. Sofern Sie schon einmal mit ähnlichen Daten-
banksystemen (z.B. Sybase, Informix oder dem MS SQL-Server) gearbeitet haben,
dann können Sie das Grundlagen-Kapitel natürlich auch getrost übergehen; Sie
werden dort nichts Neues mehr erfahren.
Danach beschäftigen wir uns ein wenig mit der Installation einer Oracle-Datenbank,
inklusive dem Einrichten des Zugriffs über SQL*Net. Hiernach folgen die Erstellung
verschiedener Tabellen und das Laden von Musterdaten, die im weiteren Verlauf des
Buches für Beispiele und Übungen immer wieder benötigt werden. Im Rahmen die-
ser Einführung werden Sie also auch erste Erfahrungen mit Oracle sammeln können
und wichtige Werkzeuge (z.B. SQL-Worksheet, Loader oder SQL*Plus) kennen lernen.
1.1 Grundlagen
Was ist eine Datenbank, was ein Datenbank-Management-System? Wie ist der
schematische Aufbau einer Oracle-Datenbank? Was ist EDV? Nein, die letzte Frage
werde ich hier nicht behandeln, aber zu den anderen beiden Fragen will ich schon
das eine oder andere anmerken.
Die Antwort auf die erste Frage scheint komplex, jedoch ist die Antwort darauf
kurz, prägnant und ziemlich einfach. Eine Datenbank ist eine strukturierte Samm-
lung von Daten – das war schon alles! Um mit diesen Daten bzw. der Datenbank
arbeiten zu können, benötigen wir üblicherweise noch geeignete Software, wobei
man hierbei von einem Datenbank-Management-System (oft und auch hier mit
DBMS abgekürzt) spricht, wenn sie vor allem das anwendungsunabhängige Arbei-
ten mit einer oder mehreren Datenbanken ermöglicht.
Strukturierte Datensammlungen gab es eigentlich schon immer. Aber, und das wis-
sen vor allem diejenigen, die schon länger im EDV-Geschäft tätig sind, der
Umgang mit gespeicherten Daten war nicht immer so komfortabel wie heute, denn
oftmals musste man sich unter anderem auch um Verfahrensweisen zum Einfügen
oder Löschen von Datensätzen oder dem schnellen Wiederfinden von Informatio-
nen kümmern. Ein Ergebnis dieser Verfahrensweisen war meistens eine sehr enge
Verzahnung von Anwendungsprogramm und Datenbasis. Bei einem Datenbank-
Management-System werden solche Detailarbeiten wie das Einfügen, Löschen oder
Finden von Daten von ihm selbst erledigt. Hierzu erhält es vom Anwendungspro-
gramm lediglich bestimmte Kommandos in Form einer speziellen Sprache. Durch
das vorhandene Regelwerk dieser Sprache und der Möglichkeit, das viele verschie-
dene Anwendungsprogramme die zugehörigen Kommandos absetzen können, ent-
steht die gewünschte Anwendungsunabhängigkeit.
1.1.1 Klienten und Diener

Entsprechend der eben erläuterten Definition handelt es sich auch bei dem Pro-
dukt Access von Microsoft also wirklich um ein Datenbank-Management-System.
Zum einen ermöglicht es die strukturierte Speicherung von Datensammlungen
und zum anderen besteht für viele Anwendungen (nicht nur Access selbst) die
Möglichkeit, mit den Daten der Access-Datenbank zu arbeiten. Dennoch gibt es
aber einen gravierenden Unterschied zwischen beispielsweise Access und einem
Oracle-DBMS.
Technisch aber trotzdem vereinfachend betrachtet besteht das DBMS von Access
aus einer „unendlichen“ Anzahl von DLLs (Dynamic Link Libraries = Dynamische
Laufzeitbibliothek), die bei Bedarf in den Speicher Ihres Rechners geladen werden.
Diese DLLs dienen dazu, die benötigten Datenbankkommandos entgegenzuneh-
men, zu interpretieren und in der Datenbank entsprechend auszuführen. Bei der
Datenbank handelt es sich meistens um eine (MDB-) Datei, die sofern man nicht
alleiniger Nutzer ist, auf einem zentralen Dateiserver abgelegt ist. Betrachten Sie
hierzu die zugehörige Abbildung (vgl. Abb. 1.1).
Arbeitsplatz
Server
Win NT, 95, 98, 2000
Excel Access
Access-DBMS
Datenbank
Netzwerk
Abbildung 1.1: Struktur eines „arbeitsplatzorientierten“ DBMS-Systems
Gemäß der Abbildung 1.1 wird eine auf einem Dateiserver gespeicherte Datenbank
von Ihrem Arbeitsplatz aus mit Hilfe des Access-DBMS über das Netzwerk abge-
fragt. Dabei liegen alle an diesem Prozess wesentlich beteiligten Komponenten,
also die beteiligten Anwendungen (Excel, Access oder andere) und das DBMS (in
unserem Beispiel die entsprechenden DLLs), im Speicher des Arbeitsplatzrechners.
Das DBMS ruft die benötigten Daten aus der Datenbank ab bzw. führt dort Ände-
rungen durch. Mit ein wenig Phantasie sollte klar werden, was bei einer solchen
Architektur alles passieren kann:
X Die Anzahl der Anwender entspricht der Anzahl der im Einsatz befindlichen
DBMS-Systeme. Ein solches DBMS-System ist eigentlich immer ein höchst kom-
plexes Gebilde mit einer Unzahl verschiedenster Funktionalitäten. Es sollte so-
mit plausibel sein, dass seine Arbeitsgeschwindigkeit nicht unwesentlich von
Grundlagen 15
den Ressourcen des ausführenden Rechners abhängt. Muss also die Leistungsfä-
higkeit des DBMS-Systems gesteigert werden, so müssen unter Umständen alle
Rechner auf denen es läuft aufgerüstet werden.
X Bestimmte Sachverhalte werden besonders deutlich, wenn man ein wenig
schwarz malt bzw. drastisch übertreibt. Stellen wir uns einfach mal vor, unsere
Datenbank hätte eine Größe von mehreren hundert Megabyte. Mit Hilfe einer
Abfrage suchen wir eine winzige Information, z.B. einen Namen, wobei die
Form der gewählten Abfrage vielleicht dazu führt, dass sie vom DBMS nicht op-
timal ausgeführt werden kann und somit zur Bereitstellung unseres gesuchten
Namens alle Datensätze der Datenbank abgerufen werden müssen. In dem Fall
müssten alle Datensätze der Datenbank über das Netzwerk zu unserem Arbeits-
platzrechner transportiert werden, damit das DBMS uns anschließend als Ergeb-
nis einen – oder noch besser keinen – Namen präsentiert. Ein Phänomen, dass
es in der Praxis wirklich gibt. Eine Abfrage führt zu einer erheblichen Belastung
des Netzwerks und unseres Rechners und am Ende kommt wenig oder sogar
nichts heraus.
X Sie wollen ein Feld einer in der Datenbank gespeicherten Tabelle ändern, und
zwar für jede vorhandene Reihe. Auch in diesem Fall muss das auf Ihrem Rech-
ner laufende DBMS jeden Satz über das Netzwerk anfordern, die Änderung
durchführen und anschließend für die Rückübertragung und die Speicherung
des neuen Wertes sorgen.
Damit keine Missverständnisse entstehen: ich will das Produkt Access hier nicht
kritisieren oder schlecht machen. MS-Access ist lediglich ein - wenn auch ziemlich
bekannter - Vertreter für diese Gruppe von DBMS-Systemen. An dem Beispiel sollte
lediglich verdeutlicht werden, wie diese Klasse von Datenbank-Management-Syste-
men (z.B. auch FoxPro, Paradox, Approach u.a.) funktionieren. In der englischspra-
chigen Literatur wird ein solches DBMS oftmals auch als File Sharing Database Sys-
tem bezeichnet. Die Bezeichnung kommt daher, dass sich hierbei in der Tat alle
Anwendungen die auf dem Server befindliche Datenbank direkt teilen; jede
Anwendung veranlasst beispielsweise indirekt über das DBMS das Öffnen der zuge-
hörigen Datenbankdateien.
Was muss man nun ändern, um die eben genannten Eigenschaften zu verändern
bzw. zu verbessern? Zunächst einmal wäre wünschenswert, das Datenbanksystem
näher an seine Datenbank zu bringen, um Lese- oder Änderungsanforderungen
einfacher und schneller bearbeiten zu können. Mit anderen Worten: das DBMS
muss auf den Server umziehen, wo auch die Datenbank gespeichert ist.
Betrachten Sie einmal die Abbildung 1.2. Durch den Umzug des DBMS ist ein Sys-
tem entstanden, wie Sie es in der heutigen Praxis oftmals vorfinden. Zum einen
haben Sie den Arbeitsplatzrechner, den Client, auf dem die eigentlichen Anwen-
dungen laufen. Diese fordern mit Hilfe von Nachrichten Daten aus der Datenbank
ab oder veranlassen dortige Änderungen. Die Nachrichten werden über das Netz-
werk an das auf dem Server laufende DBMS übermittelt. Das sorgt für die Bereitstel-
lung der gewünschten Daten und veranlasst die Übermittlung der Ergebnisse an
den Client und im Falle von Änderungen werden überhaupt keine Daten mehr
über das Netzwerk transportiert.
Arbeitsplatz
Server
Win NT, 95, 98, 2000
Excel Access DBMS
Nachrichtendienst
Nachrichtendienst
Datenbank
Netzwerk
Abbildung 1.2: DBMS mit einer Client/Server-Struktur
Oftmals kommunizieren die Clients nicht einmal direkt mit dem DBMS, sondern
das leistet sich für diese besondere Aufgabe einen vorgelagerten Prozess, quasi so
eine Art Sekretariat. Solche Prozesse werden üblicherweise als Listener bezeichnet,
und wie man der englischen Bezeichnung ableiten kann, besteht seine Hauptauf-
gabe darin, das Netzwerk permanent nach Nachrichten für sein zugehöriges DBMS
abzuhören. Übrigens, genau wie im richtigen Leben, wo ein Sekretariat durchaus
für mehrere Chefs arbeiten kann, kann auch solch ein Listener Nachrichten für
mehrere installierte DBMS-Instanzen abhören bzw. weiterleiten.
Ein weiterer Unterschied zu den File Sharing Database Systemen ist, dass das auf dem
Server befindliche DBMS die zugehörigen Datenbankdateien üblicherweise exklu-
siv nutzt. Die einzelnen Anwendungen verbinden sich lediglich direkt oder über
den Listener mit dem DBMS; auch bei tausend Anwendern sind die Datenbankda-
teien nur einmal geöffnet.
Sie haben nun auf ziemlich pragmatische Weise die Struktur eines Client/Server-
Systems (CS-System) kennen gelernt. Ich möchte die wesentlichen Eigenschaften
in der folgenden Tabelle noch einmal zusammenfassen:
File Sharing System Client/Server System

Das DBMS befindet sich auf dem Client. Das DBMS befindet sich auf dem Server.
Soll in einer Datenbank jeder Datensatz ak- Der Client schickt eine entsprechende Aktuali-
tualisiert werden, so müssen alle Datensätze sierungsnachricht an das DBMS. Dieses führt
zum Client transportiert werden. Dort wer- anschließend direkt die notwendigen Aktuali-
den die Änderungen durchgeführt und an- sierungen in der Datenbank durch.
schließend müssen alle Datensätze wieder in
die Datenbank auf den Server zurückgeschrie-
ben werden.
Grundlagen 17
File Sharing System Client/Server System

In vielen Anwendungen hängt die Arbeitsge- Der Server muss entsprechend leistungsfähig
schwindigkeit direkt von der Geschwindigkeit ausgelegt werden, damit das dort laufende
des DBMS ab. Daher muss jeder Arbeitsplatz- DBMS die Anforderungen der Clients schnell
rechner entsprechend leistungsfähig sein, da- genug abarbeiten kann. Die auf den Arbeits-
mit das auf ihm laufende DBMS über genü- stationen verfügbaren Ressourcen spielen
gend Ressourcen verfügen kann. (gäbe es nicht Windows) eigentlich keine
Rolle mehr.
Wird die konkrete Anwendung zu langsam In dem Fall muss lediglich der Server entspre-
und liegt dies zum Beispiel an der Größe der chend aufgerüstet werden.
Datenbank, so muss das DBMS und damit alle
Arbeitsplatzrechner aufgerüstet werden.
Tabelle 1.1: Gegenüberstellung File Sharing und Client/Server System
Vielleicht ist bei den bisherigen Erklärungen der Eindruck entstanden, dass die Cli-
ent/Server-Technologie von Datenbanksystemen gepachtet ist. Dem ist natürlich
nicht so, d.h. ein modernes leistungsfähiges DBMS ist nur ein Vertreter vieler ande-
rer CS-Anwendungen. Ganz allgemein gilt bei dieser Technik eigentlich nur, dass
bestimmte Teile der Anwendung auf dem Server und andere Teile auf den Clients
verfügbar sind und das beide Teile in Form von Nachrichten miteinander kommu-
nizieren und der Client die zentral auf dem Server bereitgestellten Dienste bzw.
Anwendungsfunktionen nutzt.
Zurück zu den Datenbanksystemen. Ohne vernünftiges Netzwerk funktionieren
natürlich beide System nicht richtig. Da nützt auch der „dickste“ Server nichts,
wenn die Nachrichten bzw. Ergebnisse zum bzw. vom DBMS nicht vernünftig
transportiert werden und auch der Client mit neuestem Prozessor und hunderten
Megabyte RAM dreht eine Warteschleife nach der anderen, wenn die aus der
Datenbank angeforderten Daten aufgrund des langsamen Netzwerks nur „tröpf-
chenweise“ ankommen.
Bei soviel offenkundiger Werbung für Client/Server möchte ich hier dennoch ein-
mal kurz auf die Bremse treten. Ich werde in meinem weiteren Berufsleben keine
CS-Systeme mehr in Unternehmen einführen, in denen die für einen reibungslo-
sen Betrieb notwendigen Strukturen fehlen. Hiermit meine ich vor allem vorhan-
denes KnowHow über das vorhandene Netzwerk und die eingesetzten Server oder
vor Ort verfügbares Personal, das zumindest bestimmte Grundkenntnisse (z.B.
Datensicherung, Erweitern der Datenbank, Hoch- und Runterfahren des DBMS)
über das neue Datenbanksystem besitzt. Ich habe schon häufiger schlechte Erfah-
rungen damit gemacht, wenn im Rahmen irgendwelcher Softwareprojekte ein
DBMS auf C/S-Basis eingeführt bzw. durchgesetzt wurde, dieses aber in der Soft-
warelandschaft des Kunden einen Fremdkörper darstellte. Solche Projekte laufen
am Anfang meistens sogar ziemlich gut. Die eigene EDV mischt sich kaum ein (weil
keine Ahnung) und alle auftretenden Probleme können, weil man im Rahmen des
Projekts sowieso oft oder permanent vor Ort ist, rasch erledigt werden. Treten dann
im laufenden Betrieb die üblichen Problemchen auf (Server macht Mucken – und
damit auch das DBMS; Sessions hängen usw.), dann kann die Stimmung schnell
drehen, entweder weil man jetzt aufgrund eines anderen Projekts nicht bzw.
schlecht verfügbar ist oder weil der Kunde irgendwann die Lust verliert, immer
neue Wartungsrechnungen zu bezahlen.
Ein solcher Kunde wäre mit einer Anwendung, die ihre benötigten Daten mit Hilfe
einer File Sharing Datenbank verwaltet, besser bedient, da diese im laufenden
Betrieb meistens ohne spezielle Kenntnisse betreut werden kann (DBMS kaputt =
Anwendung auf dem Client neu installieren; Datenbank kaputt = Files von der nor-
malen Datensicherung zurückspielen); klingt einfach und ist es meistens auch.
Wie im Leben, so gibt es auch in der EDV mittlerweile für jede Aufgabe das richtige
Handwerkszeug und um so merkwürdiger ist es allerdings, dass die Auswahlent-
scheidung noch immer so häufig aus einer Bierlaune heraus oder auf dem Tennis-
bzw. Golfplatz getroffen wird. Ich würde diesen Entscheidungsträgern gerne mal
im Privatleben zusehen, wie sie die Heftzwecke für ein neues Kindergartenbild mit
dem Vorschlaghammer in der Wand versenken, anstatt hierfür den kleinen und
handlichen Bastelhammer zu benutzen. Aber schließlich machte der Vorschlag-
hammer im Geschäft den stattlicheren Eindruck, hier bekommt man wirklich was
für sein Geld und daher muss er einfach das richtige Tool für alle denkbaren Aufga-
benstellungen sein.
1.1.2 Aufbau des Oracle-DBMS

Aufgrund des letzten Kapitels wissen Sie nun, dass Oracle zur Klasse der Client/Ser-
ver-Datenbank-Management-Systeme (CS-DBMS) gehört und obwohl sich dieses
Buch primär nicht an Techniker richtet, soll im Folgenden der konkrete Aufbau des
Oracle-DBMS ein wenig genauer betrachtet werden. Sollten Ihnen die hier bzw.
auch im nächsten Kapitel gelieferten Informationen zu oberflächlich sein, dann
empfehle ich Ihnen den Genuss eines speziellen Buches für Oracle-Datenbankad-
ministratoren oder Sie schmökern einfach mal ein wenig in den per HTML geliefer-
ten Handbüchern. Im Buch „Oracle8 Server“ finden Sie beispielsweise allein schon
in den Abschnitten „Server Concepts“ oder „Oracle Server Administrator's Guide“
eine schier unerschöpfliche Informationsquelle. Beim 8i-Server finden Sie diese
beiden Kapitel auch wieder, wenn Sie auf der Startseite den Link „Oracle8i Server
and Data Warehousing“ folgen.
In allen Versionen finden Sie die Online-Dokumentation übrigens im \DOC-Ver-
zeichnis, das direkt unter dem Oracle-Homeverzeichnis angeordnet ist.
Schaut man etwas genauer auf die Funktionsweise eines Oracle-DBMS so stellt man
fest, dass es sich in der Architektur ein wenig von unserer bisherigen allgemeingül-
tigen Definition und in diesem Punkt auch in der Tat von andern DBMS-Systemen
unterscheidet. Wir, nein ich, hatte gesagt, dass es sich bei einem DBMS um ein
Stück Software handelt, das ein anwendungsunabhängiges Arbeiten mit einer oder
mehreren Datenbanken ermöglicht. Microsofts SQL-Server arbeitet beispielsweise
nach diesem Prinzip. Bei dieser Datenbank finden Sie auf Ihrem Rechner genau
einen Prozess, repräsentiert durch das Programm SQLSERVR.EXE, können aber
trotzdem mit allen definierten Datenbanken arbeiten.
Grundlagen 19
Im Unterschied hierzu arbeitet bei Oracle ein DBMS (z.B. ORACLE80.EXE unter
NT) immer genau mit einer Datenbank zusammen, was natürlich nicht heißt, dass
Sie nicht mehrere Datenbanken auf einem Rechner betreiben können – Sie müssen
in dem Fall auch einfach nur entsprechend viele Kopien des DBMS im Speicher lau-
fen haben. Das ist also genau so, als würden Sie Excel mehrfach starten und mit
jeder Programmkopie genau eine Tabelle laden, wohingegen die definitionskon-
forme Arbeitsweise des SQL-Servers dem einmaligen Starten von Excel entspricht,
wobei anschließend für jede Tabelle ein Arbeitsfenster geöffnet wird.
Im Oracle-Sprachgebrauch wird eine solche DBMS-Kopie üblicherweise mit dem
Begriff einer Instanz belegt. Technisch betrachtet verbirgt sich hinter einer solchen
Instanz die Menge aller benötigten Prozesse zuzüglich einem Stückchen reservier-
tem Hauptspeicher, der für alle diese Prozesse erreichbar ist. Dieser Hauptspeicher-
bereich wird als System Global Area (SGA) bezeichnet, die Instanz selbst wird durch
einen System-Identifer (SID) gekennzeichnet (vgl. Abb 1.3).
SID=orcl
SGA = System Global Area
Oracle-Systemprozesse
DBWR SMON PMON LGWR CKPT
Abbildung 1.3: Schematischer Aufbau einer Oracle-Instanz mit den wichtigsten Hintergrundpro-
zessen
Sofern es Sie interessiert, finden Sie in der folgenden Aufstellung eine grobe
Beschreibung, welche Funktionen die einzelnen Systemprozesse erfüllen:
X DBWR (Database Writer)
schreibt in der SGA modifizierte Datenblöcke zurück in die Datenbank.
X SMON (System Monitor)
Überwacht die Wiederherstellung der Datenbank bei einem Neustart. Ferner re-
gistriert dieser Prozess freiwerdende Bereiche in der Datenbank und vereinfacht
somit deren Wiederbelegung.
X LGWR (Log Writer)
Schreibt die im Rahmen von Transaktionen anfallenden Protokollinformatio-
nen in die zugehörigen Plattenbereiche (Redo-Log-Einträge).
X CKPT (Checkpoint)
Generiert die sogenannten Checkpoints, zu denen modifizierte Datenblöcke aus
der SGA in die Datenbank zurückgeschrieben werden.
X PMON (Process Monitor)
Überwachung der Benutzerprozesse. Freigabe der Ressource von abgebrochenen
Benutzerprozessen.
Die SGA selbst ist auch in mehrere unterschiedliche Speicherbereiche aufgeteilt.
Diese Speicherbereiche werden während der Initialisierung der Instanz angelegt
und können in der Größe zur Laufzeit nicht geändert werden. In der folgenden
Aufstellung finden Sie eine kurze Beschreibung der wichtigsten Speicherbereiche:
X Database Buffer Cache
In diesem Speicherbereich werden die gerade benötigten Datenblöcke vorgehal-
ten. Da üblicherweise nicht alle Daten gleichzeitig in diesen Puffer passen, fin-
det ein permanenter Ein- und Auslagerungsprozess zwischen aktuell benötigten
und länger nicht mehr gebrauchten Daten statt. Hierbei werden die am längsten
ungenutzten Puffer aus diesem SGA-Bereich ausgelagert (LRU-Algorithmus, LRU
= Least Recently Used). Zur Erinnerung: zum Wegschreiben von Änderungen aus
diesem Puffer war der Prozess DBWR zuständig.
X Redo Log Buffer
Die während einer Transaktion anfallenden Protokollinformationen werden in
diesem Puffer zwischengespeichert.
X Shared Pool
SQL-Befehle jeglicher Art, Funktionen oder Prozeduren werden in diesem Pool
zwischengelagert, wobei diese hier gelagerten Abfragen direkt ausführungsfähig
sind, d.h. sie werden hier mitsamt ihren Ausführungsplänen gespeichert. Ähn-
lich wie beim Database Buffer Cache wird auch dieser Bereich nach dem LRU-
Algorithmus verwaltet, d.h. häufig benutzte Abfragen oder Prozeduren stehen
direkt zur Ausführung zur Verfügung.
Mehr Informationen zu diesen und weiteren Prozessen einer Oracle-Instanz sowie
weitergehende Informationen über den Aufbau der SGA finden Sie in der Oracle-
Dokumentation im Buch „Server Concepts“ im Kapitel „Memory Structure and
Processes“. Um selbst Datenbanken anzulegen bzw. die dazu notwendigen Schritte
besser zu verstehen, reicht allerdings ein grobes Gefühl über den Aufbau einer
Instanz völlig aus.
1.1.3 Aufbau einer Oracle-Datenbank

Nachdem Sie nun ein paar Grundkenntnisse über den Aufbau des Oracle-DBMS
besitzen, möchte ich Ihnen auch noch ein paar Grundlagen über den Aufbau der
Datenbank vermitteln, d.h. es geht jetzt darum mal nachzuschauen, wie sich die
Datenbank auf der Festplatte ausbreitet.
Grundlagen 21
Jedes Datenbanksystem speichert seine Daten in ganz gewöhnlichen Dateien (wie

auch sonst), d.h. spätestens hier finden Sie eine wichtige Nahtstelle zum vorhan-
den Betriebssytem, denn beim Anlegen und Verwalten dieser Dateien muss sich
natürlich auch das DBMS an die vorgegebenen Spielregeln des Betriebssystems hal-
ten. Konkret geht es hierbei beispielsweise um Namenskonventionen (Länge von
Pfad- und Dateinamen, Sonderzeichen) oder eventuell vorhandene Größenbe-
schränkungen von einzelnen Dateien oder des definierten Filesystems (UNIX).
Für uns als Anwender bildet die gesamte Datenbank eine logische Einheit. Physika-
lisch kann das ganz anders aussehen und hängt konkret vom vorhandenen DBMS
ab. Es gibt sowohl Datenbanksysteme, wo die gesamte Datenbank auch immer
genau einer Datei entspricht, als auch Systeme, wo jede Tabelle automatisch in
einer eigenen Datei gespeichert wird. Oracle liegt irgendwo zwischen diesen beiden
Extremem, wobei der genaue Standort sehr stark von Ihrer Datenbankdefinition
abhängt.
Oracle speichert Ihre Anwendungsdaten in Form von Tabellen. Eine solche Tabelle
benötigt hierzu natürlich Platz, der ihr vom Datenbanksystem in Form eines soge-
nannten Tablespace bereitgestellt wird. Dieser Tablespace wird physikalisch – und
jetzt wird es interessant – durch eine oder auch mehrere Dateien gebildet (vgl. Abb.
1.4).
Logisches Modell Datenbank
Tablespaces Tablespace 1 Tablespace 2
Physische Dateien Datei 1 Datei 2 Datei 3
Festplatten
Abbildung 1.4: Schematischer Aufbau einer Oracle-Datenbank
Betrachten Sie den schematischen Aufbau mit Hilfe der Abbildung 1.4. In dem Bei-
spiel wird der Tablespace 2 durch zwei Dateien gebildet, die sogar auf unterschied-
lichen Platten angelegt wurden. In diesen Tablespaces werden nun die benötigten
Tabellen und anderen Datenbankobjekte (z.B. Indices) angelegt, d.h. es besteht bei-
spielsweise die Möglichkeit, den für eine Tabelle zuständigen Tablespace und damit
vielleicht auch die Tabelle auf mehrere Platten zu verteilen, um hierdurch unter
Umständen bessere Zugriffsgeschwindigkeiten zu erreichen.
Früher wurde viel mit diesen Optionen experimentiert, um das Antwortszeitverhal-

ten des Systems und damit natürlich auch der Anwendung zu verbessern. Heute
spielt bei diesen Möglichkeiten der Tuninggedanke eine immer geringere Rolle. Das
liegt aus meiner Sicht vor allem an folgenden drei Gründen. Erstens hat man es
heutzutage oftmals nicht mehr mit einzelnen direkt addressierbaren Platten, son-
dern ganzen Plattenstapeln (Disk-Arrays) zu tun. Hierdurch geht die direkte Kon-
trolle was genau wo gespeichert wird sowieso verloren bzw. das Speichermedium
des Plattenstapels stellt schon von ganz alleine sicher, dass der Zugriff auf große
Dateien optimiert erfolgt.
Zum zweiten bieten manche Betriebssysteme (z.B. UNIX) die Möglichkeit, die phy-
sikalische Plattenstruktur durch ein darüber liegendes sogenanntes Filesystem zu
verschleiern. Die zum Tablespace gehörenden Dateien werden dann in diesem File-
system angelegt, also geht auch hierbei die direkte Kontrolle über die Plattenzuord-
nung verloren.
Der dritte und wesentlichste Grund ist aber, dass sich die Aufwände dieser physika-
lischen Tuningmaßnahmen meistens nicht mehr rechnen. Zum einen ist die
Hebelwirkung dieser Maßnahmen kleiner geworden. Die Rechner und Platten sind
heutzutage so schnell, dass viele Anwendungen auch bei miserabelstem Speicher-
konzept noch ordentlich laufen dürften. Zum anderen zeigt sich der Engpassfaktor
oft gar nicht mehr in der Form der durchgeführten Datenzugriffe, sondern über-
trieben verspielte grafische Oberflächen, hüpfende Büroklammern und ähnliche
Gimmiks.
Die soeben aufgeführten Gründe sollen Sie allerdings auch nicht zum anderen
Extrem, nämlich Datenbanken mit nur einem Tablespace, verleiten. Die folgenden
Regeln können Ihnen vielleicht bei der Strukturierung Ihrer Datenbank helfen,
denn ein allgemeingültiges Patentrezept gibt es auch hier natürlich mal wieder
nicht:
X Viele Anwendungen definieren für die benötigten Indexdateien einen separa-
ten Tablespace. Wenn Sie nun noch versuchen, wenigstens diese zugehörigen
Dateien in ein separates Filesystem bzw. auf anderen Platten zu verlagern, dann
kann Ihr System getrennt auf Index- und Datenbereiche zugreifen. Selbst wenn
dieser Eingriff Ihre Abfragen nur um 0,00x Sec beschleunigt; diese Maßnahme
kostet nichts und es spricht auch ansonsten überhaupt nichts dagegen.
X Logische Gesichtspunkte können für die Gestaltung der Tablespaces ausschlag-
gebend sein. Beispielsweise besteht die Anwendung aus mehreren verschiede-
nen Produkten (z.B. Finanzbuchhaltung, Personalabrechnung und
Reisekosten), dann ist es sicherlich sinnvoll, die produktspezifischen Tabellen
in eigens hierfür angelegte Tablespaces zu speichern. Dies erhöht nicht nur die
Übersicht, sondern kann auch spezielle Wartungsarbeiten vereinfachen, denn
die einzelnen Tablespaces können im laufenden Betrieb ein- oder ausgeschaltet
werden. Auch wäre die Entzerrung der Daten recht einfach, sollte eines der Pro-
dukte mal in eine eigene Datenbank umziehen müssen.
X Verteilen von Tabellen mit unterschiedlichem Wachstumsverhalten. Es kann
durchaus sinnvoll sein, stark wachsende Tabellen von mehr oder weniger stati-
schen Tabellen zu trennen. Es liegt irgendwie auf der Hand, dass der Verwal-
Grundlagen 23
tungsoverhead geringer sein muss, wenn eine stark wachsende Tabelle alleine
in einem Tablespace liegt, als wenn sie zusammen mit anderen Tabellen um
den noch freien Platz „kämpfen“ muss.
X Anforderungen eines besonderen Betriebsablaufs können natürlich auch eine
Rolle spielen. Wie ich schon erwähnte, besteht die Möglichkeit einen einzelnen
Tablespace im laufenden Betrieb ein- bzw. auszuschalten. Solche Praktiken
könnte man im Zusammenhang mit speziellen Programmen nutzen, die eine
Tabelle im Batch komplett verändern, um diese Tabelle vor dem Programmlauf
auf einfache und schnelle Weise zu sichern.
Innerhalb eines Tablespaces werden die Daten in sogenannten Segmenten gespei-
chert. Dabei bildet beispielsweise jede Tabelle oder jeder Index ein eigenes Seg-
ment. Die Segmente selbst bestehen aus einem oder mehreren zusammenhängen-
den Datenblöcken (data block), wobei diese zusammenhängenden Blöcke mit dem
Begriff Extend bezeichnet werden. Ein solcher Datenblock ist die kleinste Speicher-
einheit, die Oracle beim Schreiben oder Lesen der Festplatte bewegt. Die Größe
eines solchen Datenblocks können Sie beim Anlegen der Datenbank festlegen,
indem Sie den Parameter DB_BLOCK_SIZE der Konfigurationsdatei entsprechend
anpassen. Der Standardwert für diese Größe ist betriebssystemabhängig und
beträgt für Windows-NT beispielsweise 2048 Byte.
Festplatte
Segment 1. Extend
2Kb 2Kb 2Kb 2Kb 2Kb 2Kb
Tablespace

2. Extend
Abbildung 1.5: Segmente, Extends und Datenblöcke
Beim Anlegen eines Tablespace können Sie Regeln definieren, wie die einzelnen
Segmente gebildet werden sollen, d.h. welche Größe beispielsweise die erste und
jede weitere Ausdehnung (Extend) besitzen soll. Allerdings können Sie beim Anle-
gen der einzelnen Objekte diese Regel überschreiben und dem Objekt damit eine
individuelle Speicherbelegungsregel mitgeben.
Das bisher Gesagte soll an dieser Stelle über den Aufbau einer Oracle-Datenbank
zunächst einmal reichen. Mehr Informationen über dieses spezielle Thema finden
Sie weiter unten in diesem Buch im Kapitel „1.5 Erstellen einer Datenbank“.
Ansonsten möchte ich natürlich auch wieder auf die Oracle-Dokumentation ver-
weisen. Hier finden Sie weiterführende Informationen zum Beispiel im Buch
„Oracle8“. Folgen Sie dort dem Querverweis „Server Concepts“. Die Informationen
finden Sie im Kapitel „Database Structure and Space Management“. In der 8i-Doku-
mentation finden Sie das Kapitel im Buch „Oracle8i Concepts“, das sich hinter
dem Querverweis „Oracle8i Server and Data Warehousing“ verbirgt.
1.2 Installation
Nun soll sich dieses Buch nicht an DBA’s richten, und trotzdem finden Sie so ziem-
lich am Anfang ein Kapitel über die Installation. Der Grund dafür ist ziemlich ein-
fach: vielleicht haben Sie ja auch als klassischer Anwendungsentwickler oder Bera-
ter einmal Lust, ein Oracle-DBMS zu installieren, beispielsweise weil es auch auf
Ihrem NT-Notebook prima läuft. Sie haben richtig gelesen. Trotz der komplexen
Struktur des Oracle-DBMS funktioniert es auch in primitiven Wohnstuben höchst
zuverlässig. Ein gewöhnlicher Rechner mit Windows-NT (Workstation) reicht völ-
lig aus, um darauf eine lauffähige Installation durchzuführen.
Vielleicht besteht ja im Rahmen des aktuellen Projekts die Möglichkeit, eine Ver-
sion auf Ihrem Rechner zu installieren oder – und das gilt natürlich vor allem für
alle selbständigen Berufskollegen – Sie kaufen sich gleich eine eigene Version. Die
gibt es mittlerweile nämlich in einer Einplatzlizenz für etwa 600_ zu kaufen, wofür
Sie einen ca. zehn Zentimeter dicken CD-Stapel erhalten. Im Übrigen gibt es auch
immer wieder mal spezielle Partnerprogramme, bei deren Teilnahme Sie ebenfalls
die Möglichkeit haben, besonders günstige Test- und Entwicklungslizenzen zu
beziehen.
Was den letzten Satz angeht, da haben sich die Zeiten wirklich sehr zum positiven
geändert. Es ist noch nicht so lange her, da war es für kleine Firmen, Einzelunter-
nehmen oder Freiberufler schon ein bisschen schwieriger, ein Oracle-DBMS zu
erwerben. Dabei war das gar nicht mal eine Frage des Preises, sondern eher so wie
bei Ferrari. Da soll auch nicht jeder ein Auto kriegen, selbst wenn er es bezahlen
kann. Heute ist das anders. Zum einen ist das Produkt in speziellen Konfiguratio-
nen sehr günstig und zum anderen bemüht man sich in den letzten Jahren seitens
Oracle sehr, das Produkt durch spezielle Angebote auch kleinen Softwarehäusern
oder Freiberuflern schmackhaft zu machen.
Immer noch geblieben ist der eine oder andere „AHA“-Effekt während oder nach
der Installation; frei nach dem Motto „Installation gelungen, Patient tot“. Damit
das bei Ihnen nicht passiert, will ich im Folgenden eine kleine Installationshilfe
geben.
Mit dem Begriff „Installation“ habe ich eigentlich eine Reihe von Aktivitäten
gemeint. Zunächst einmal müssen Sie in der Tat die benötigte Software auf Ihren
Rechner kopieren. Der nächste Schritt wäre die Erstellung einer Datenbank und
zum Schluss müssen Sie auch noch Kontakt zu Ihrer Datenbank herstellen.
Installation 25
1.2.1 Der Installationsvorgang

Die primäre Installation der Software ist natürlich stark abhängig vom konkret ein-
gesetzten Betriebssystem und der eingesetzten Oracle-Version. Im Prinzip geht es
natürlich immer um das Gleiche: Sie müssen die benötigten Dateien von der
Oracle-Produkt-CD auf Ihren Rechner kopieren. Prinzipiell muss man auch zwi-
schen der Installation des Oracle-Servers und der benötigten Software für die ein-
zelnen Arbeitsstationen unterscheiden. Manchmal liegen diese beiden Produktpa-
kete auch auf verschiedenen CDs vor (z.B. Oracle8 Server für Sun SPARC und
Oracle8 Client für Windows 95 und NT). In den folgenden Abschnitten erhalten
Sie sowohl Informationen zur Installation einer „normalen“ 8er-Version als auch
zum Installationsvorgang der 8i-Variante.
Wie schon eingangs erwähnt, soll die Installation auf einem NT-Notebook erfol-
gen, d.h. Server und Client laufen auf dem gleichen Rechner. Die Installation
erfolgt unter NT 4.0 (Workstation) mit Service Pack 5 auf einem DELL Latitude CPI-
Notebook mit Pentium II-Prozessor (366 Mhz) und 256 MB Hauptspeicher. Keine
Angst, Sie müssen jetzt nicht sofort aufrüsten. Auf einem Rechner mit nur 64 MB
Hauptspeicher und einem 166 Mhz-Prozessor läuft der Oracle-Server auch ordent-
lich. Selbst mit noch weniger Ressourcen ist eine Installation möglich. Vor ein paar
Jahren habe ich mal einen Oracle-Server (Version 7.3) auf einem Notebook mit nur
32 MB Hauptspeicher installiert, allerdings ging der Betrieb des Servers jetzt schon
stark zu Lasten der Performance anderer Anwendungen.
Das einzigste was einem beim ersten Hinschauen den Atem verschlägt ist der ver-
anlagte Platzbedarf. Die aktuelle 8i-Version beansprucht in der Standardinstalla-
tion immerhin ca. 1 GB Plattenplatz (ohne Starter-Datenbank), wohingegen sich
die normaler 8er-Version inklusive Starterdatenbank mit ein paar hundert MB
freiem Platz installieren lässt. Ebenfalls phänomenal ist der temporäre Platzbedarf
des 8i-Installationsprogramms. Bei meinen Installationsversuchen lief das Pro-
gramm erst dann bis zum Ende durch, nachdem auf meinem Systemlaufwerk ca.
100 MB für Temporärdateien zur Verfügung standen.
Unter Windows erfolgt die Installation von Oracle-Produkten mit Hilfe eines spezi-
ellen Setup-Programms, dem Oracle-Installer. Dieses Programm wird im Übrigen
üblicherweise auch selbst installiert, da Sie mit ihm jederzeit weitere Komponenten
nachinstallieren oder auch überflüssige Programmteile entfernen können. Sollte
sich der Installer nach dem Einlegen der CD nicht automatisch melden, so starten
Sie es einfach selbst, indem Sie das im Hauptverzeichnis der CD befindliche Pro-
gramm SETUP.EXE ausführen.
Das Aussehen und die Funktionsweise des Installers war in den 7er und ersten 8er
Versionen nahezu gleich. Erst mit einen der letzten Versionen bekam das Installa-
tionsprogramm eine neue Garderobe verpasst, wobei die eigentlichen Funktionen
aber immer noch die gleichen sind. Seit einiger Zeit schleicht sich auch in der
Oracle-Produktpalette die typische „Look and Feel“ der unter Windows berühmt
gewordenen Assistenten ein und auch das Installationsprogramm liegt bei der 8i-
Version im Assistentengewand vor.
1.2.2 Installation der Version 8

Nach kurzer Ladezeit des Installationsprogramms erhalten Sie eine kleine Dialog-
box, mit deren Hilfe Sie für die Installation das Zielverzeichnis, die gewünschte
Sprache und einen symbolischen Namen für das Installationsziel auswählen kön-
nen (vgl. Abb. 1.6).
Abbildung 1.6: Auswahl der Sprachoption für die Oracle-Installation
An dieser Stelle können Sie schon den ersten schmerzvollen Fehler machen. Wer
würde an nichts Böses denkend, nicht intuitiv „German“ auswählen, weil das –
wenn es schon angeboten wird – irgendwie am naheliegendsten ist. Vor ein paar
Jahren auf einem Oracle-Seminar war die Aussage des Trainers zu dieser Option
ziemlich eindeutig: „Sie dürfen jede Sprache auswählen, so lange es Englisch ist“.
Nach meinem Kenntnisstand gilt dies auch heute noch. Bei der Installation eines
Servers sowieso und auch beim Client ist die Sprachoption „English“ meistens die
bessere Wahl. Zwar funktioniert der Oracle-Client mit anderen Sprachen einwand-
frei, jedoch kann es bei anderen Anwendungen (z.B. PeopleSoft oder ODBC-Daten-
bankanwendungen) zu seltsamen Anomalien kommen, falls eine andere Sprache
gewählt wurde. Dies äußert sich beispielsweise darin, dass Datums- oder Zahlen-
werte in der Anwendung nicht korrekt formatiert dargestellt werden.
Die hier gewählte Spracheinstellung führt bei Windows-Systemen übrigens zum
Registrierungseintragung NLS_LANG mit dem Wert „AMERICAN_AMERICA.
WE8ISO8859P1“, den Sie in der Registrierungsdatenbank im Verzeichnis \HKEY_
LOCAL_MACHINE\SOFTWARE\ORACLE finden.
Neben der Sprache haben Sie im letzten Dialog das sogenannte Oracle-Homever-
zeichnis f (engl. Home-Directory, z.B. E:\ORANT) festgelegt. Die unter diesem
Homeverzeichnis liegende Struktur ist nur von der eingesetzten Oracle-Version
abhängig, d.h. sie ist ansonsten konstant und allen Systemanwendungen bekannt.
Im Übrigen ist es auch möglich, auf einem Rechner mehrere parallele Installatio-
nen zu erstellen. In dem Fall existieren üblicherweise auch entsprechend viele
Oracle-Homeverzeichnisse. Werden nun auf dem Server irgendwelche Anwendun-
gen gestartet, so holen sich diese zunächst einmal das Homeverzeichnis mit Hilfe
einer Umgebungsvariablen oder eines Registrierungseintrags ab, weshalb beispiels-
Installation 27
weise unter Unix in vielen Skripten immer mal wieder die oracle_home-Umgebung
exportiert wird. Wenn Sie unter NT mehrere Installationen durchführen und dabei
andere Home-Verzeichnisse wählen, dann müssen Sie darauf achten, dass vor dem
Start der Anwendungen das richtige Home-Verzeichnis ausgewählt ist, und falls
nicht, dann müssen Sie es vor dem Programmstart entsprechend einstellen, wofür
Sie nach der Installation in der Oracle-Programmgruppe ein kleines Utility finden.
Was folgt, ist eine weitere Dialogbox (vgl. Abb. 1.7) mit einem Hinweis, den Sie
ebenfalls durchaus ernst nehmen sollten.
Abbildung 1.7: Eintragung des richtigen Suchpfades für DLLs und Programme
Unter Windows werden Informationen über Speicherorte (Home- und andere Ver-
zeichnisse) in der Windows-Registrierungsdatenbank gespeichert. Hier kann also
jede Anwendung Informationen abrufen, die zur Ausführung von bestimmten Pro-
grammen oder zum Laden von DLLs gebraucht werden. Allerdings arbeitet nicht
(oder noch nicht ?) jedes Programm auf diese Weise. Es gibt noch viele Anwendun-
gen, die zum Laden solcher Bibliotheken Hilfestellung in Form von voreingestell-
ten Suchpfaden benötigen. Wenn Sie den Dialog mit der Yes-Schaltfläche verlassen,
dann trägt Oracle den richtigen Suchpfad für Programme und DLLs in die Win-
dows-Systemvariable path ein. Beenden Sie den Dialog mit No sofern Sie sicher
sind, dass Sie keinen solchen Pfad-Eintrag brauchen bzw. Sie die notwendige Ein-
stellung später selbst vornehmen wollen.
Kleine Ursache – große Wirkung. Das gilt unter Umständen auch für diesen Pfad-
Eintrag. Ich habe in meiner Laufbahn schon Trouble-Tickets zu diesem Thema
bearbeitet. Die Oracle-Installation war erfolgreich, die Datenbank konnte ohne
erkennbare Fehler generiert und geladen werden, der Zugriff auf die Datenbank mit
Hilfe von Oracle-Tools (z.B. SQL-Worksheet oder SQL*Plus) funktioniert ebenfalls
und auch die Anwendung wurde ohne Fehler installiert. Trotzdem läuft sie nicht,
d.h. der Zugriff auf die Datenbank klappt nicht. Manchmal war dieser Pfad-Eintrag
die Ursache des Übels. Denken Sie vor allem auch daran: selbst wenn Sie den Client
mit Hilfe des Oracle-Installers installieren und dabei den Pfad setzen lassen - in
machen Firmen existieren eigenwillige Login-Scripts, die diese Pfad-Angabe beim
Anmelden des Benutzers selbst setzen bzw. überschreiben.
Zurück zur Installation. Mit Hilfe des nächsten Dialogs müssen Sie die gewünschte
Art der Installation auswählen. In meiner vorliegenden Version habe ich hierbei
drei verschiedene Varianten zur Auswahl (vgl. Abb. 1.8).
Abbildung 1.8: Was soll installiert werden?
Die voreingestellte Option Oracle8 installiert vorgegebene Komponenten des Ser-

vers und des Clients. Die nächste Option Oracle8 Client wird benötigt, wenn bei-
spielsweise der Oracle-Client auf weiteren Arbeitsstationen installiert werden soll
und die letzte Option ermöglicht Ihnen die manuelle Auswahl aller gewünschten
Komponenten. Da später jederzeit beliebige Komponenten nachinstalliert werden
können, ist gegen eine Standardinstallation eigentlich nichts einzuwenden. Also
klicke ich auf OK und setze den Installationsvorgang damit fort. Für alle möglichen
Installationsvarianten gilt im Übrigen, dass bestimmte ausgewählte Komponenten
während des Installationsvorgangs zu spezifischen kleinen Dialogen führen kön-
nen, in denen dann irgendwelche Einstellungen vorgenommen werden können.
Welche Optionen in an dieser Stelle genau angeboten werden, hängt natürlich
vom Inhalt der eingelegten CD ab. So existieren beispielsweise auch CDs, auf
denen nur der Oracle Client verfügbar ist.
In meinem Beispiel, also der Installation des Oracle-Servers auf einem NT-Laptop,
werden sowohl die Programme des Servers also auch des Clients in das gemeinsame
Oracle-Home-Verzeichnis (z.B. E:\ORANT) installiert. Das wäre bei einem NT-Ser-
ver im Übrigen zunächst einmal nicht anders, denn auch auf einem Server kann
sich ein Anwender theoretisch anmelden und anschließend gewöhnliche Anwen-
dungsprogramme starten.
„ Starterdatenbank““ generieren
Aufgrund der gewählten Installationsmethode erscheint als Nächstes ein Dialog
(Abbildung 1.9), der es mir ermöglicht zusammen mit der Installation auch gleich
eine Datenbank anzulegen. Es gibt viele Wege nach Rom – dies ist sicherlich der
einfachste, eine Oracle-Datenbank zu erhalten. Im Kapitel „Erstellen einer Daten-
bank“ werden Sie einen anderen, weitestgehend manuellen, Weg zur Erstellung
einer Datenbank kennen lernen.
Installation 29
Abbildung 1.9: „ Starterdatenbank“ installieren
Die Option Typical führt zur Installation einer Datenbank mit dem Namen
ORACLE und der Instanzbezeichnung ORCL (=SID). Diese Datenbank ist von ihrem
Aufbau bzw. Konfiguration zum Spielen und Ausprobieren (z.B. für die Übungen in
diesem Buch) gar nicht so schlecht geeignet und im Übrigen kann man ja im Nach-
hinein auch alle fehlenden Parameter ergänzen oder vorhanden Einstellungen
nach Belieben ändern.
Mit der Option None wird nur das Oracle-Softwarepaket installiert. Die mittlere
Option ruft nach der Installation der Software den Oracle-Datenbank Assistenten
auf. Mit Hilfe dieses Assistenten können Sie die benötigte Datenbank direkt erstel-
len oder Sie lassen sich die zur späteren Erstellung benötigten Skripte generieren.
Im Kapitel „Erstellen einer Datenbank“ werden Sie mehr über dieses Werkzeug
erfahren.
Auch nach diesem Dialog ist die Installationsfragestunde noch nicht beendet. Der
nächste Dialog klärt die Frage, ob die Oracle-Dokumentation auf die Festplatte
kopiert oder von der CD aus gestartet werden soll. Eine Kopie beansprucht zur Zeit
zwar immerhin ca. 70MB, aber die lohnen sich allemal. Beenden Sie nun auch die-
sen letzten Dialog, wodurch der Oracle-Installer mit der eigentlichen Installations-
arbeit beginnt. In unserem Fall werden hierbei nicht nur die benötigten Pro-
gramme und Dateien in das vorgegebene Verzeichnis kopiert, sondern während
der Installation wird auch unsere erste Datenbank angelegt (Mehr Informationen
zum Aufbau der Starterdatenbank finden sie übrigens im Kapitel „3 Starter Data-
base Contents“ im Buch „Oracle8 Getting Started for Windows NT“). Nach ein paar
Minuten – das hängt natürlich vom Rechner ab – erscheint dann (hoffentlich) die
folgende Meldung (vgl. Abb. 1.10), die uns die erfolgreich abgeschlossene Installa-
tion quittiert.
Abbildung 1.10: Das war’s, die Installation wurde erfolgreich beendet

Sollten Sie übrigens bei einer Erst- bzw. Vollinstallation Probleme haben, dann ist
neben zu wenig Plattenplatz auch immer ein vorhergehender misslungener Instal-
lationsversuch bzw. eine nicht vollständige Deinstallation ein möglicher Grund
dafür. Etwas weiter unten im Kapitel „Installation entfernen“ finden Sie ein paar
Hinweise, was Sie alles kontrollieren sollten, um dies als Grund auszuschließen.
Die Installation begutachten

Wenn man Oracle zum ersten Mal installiert, dann lohnt es sich schon ein wenig
genauer hinzuschauen, was alles Neues im System und auf der Festplatte verteilt
wurde. Mit Hilfe der Abbildung 1.11 erhalten Sie einen Überblick, was während der
Installation alles auf Ihrem Rechner erstellt wurde.
Abbildung 1.11: Optischer Überblick des Installationsergebnisses
Zunächst einmal liefert die Standardinstallation zwei neue Programmgruppen.

Beide enthalten eine Fülle von Werkzeugen, die Sie zum Teil im weiteren Verlauf
dieses Buches noch kennen lernen werden. Wie Sie in dem Ausschnitt rechts oben
der Abbildung sehen, entsteht in dem vorgegebenen Oracle-Zielverzeichnis eine
ziemlich komplexe Verzeichnisstruktur. Ebenfalls umfangreich sind die in der Win-
dows-Registrierung erstellten Einträge. Interessant ist auch der Ausschnitt im mitt-
leren Teil der Abbildung. Dort sehen Sie, dass auch verschiedene neue Dienste
erstellt wurden. Besonders wichtig hierbei sind vor allem diejenigen, die zum
Betrieb unserer Starterdatenbank benötigt werden (OracleServiceORCL, OracleStart-
ORCL und OracleTNSListener80).
Installation 31
Nachinstallieren
Ein weiteren guten Überblick über soeben installierte Komponenten erhalten Sie
auch, wenn Sie jetzt einfach mal den ebenfalls installierten Oracle-Installer, den Sie
in der Programmgruppe „Oracle for Windows NT“ finden, aufrufen (Abbildung
1.12).
Abbildung 1.12: Hauptfenster des Oracle-Installers
Im Prinzip besteht das Hauptfenster des Installationsprogramms aus zwei Listen. In

der rechten Liste finden Sie eine Aufstellung der bereits installierten Komponenten
und in der linken haben Sie eine Auswahl der installierbaren Komponenten. Der
Rest dürfte eigentlich intuitiv klar sein. Markieren Sie beliebige Einträge in der
rechten Liste, um sie anschließend durch Drücken der Schaltfläche Remove zu ent-
fernen. Oder Sie wählen die benötigten Einträge in der linken Liste aus, um sie mit
Hilfe der Install-Schaltfläche zu installieren. Alle verfügbaren Komponenten sind in
Oracle zu Paketen zusammengefasst, die technisch durch sogenannte „Product
Files“ (*.PRD) repräsentiert werden. Mit Hilfe der From-Schaltfläche haben Sie die
Möglichkeit diese Produktpakete auszuwählen bzw. zu öffnen.
Installation entfernen
Wie einzelne Komponenten installiert oder entfernt werden können, haben Sie im
vorhergehenden Kapitel gesehen. Eigentlich nicht erwähnenswert ist, dass Sie mit
Hilfe des Oracle-Installers die ganze Installation löschen können, indem Sie alle in
der rechten Liste angezeigten Komponenten markieren und danach die Schaltflä-
che Remove betätigen. Allerdings klappt dieser Vorgang nicht immer so reibungs-
los, wie die vorhergehende Installation. Manchmal ist ein manueller Clean-Up not-
wendig; eine Kontrolle ist in jedem Falle empfehlenswert. Im Folgenden finden Sie
einen möglichen Putzplan, um Ihre Oracle-Installation wieder zu entfernen:
X Beenden und Deaktivieren Sie mit Hilfe der Systemsteuerung alle eventuell
noch vorhandenen Oraclexxxx-Dienste.
X Löschen Sie alle installierten Komponenten mit Hilfe des Oracle-Installers.
X Löschen Sie, sofern noch vorhanden, das Oracle-Verzeichnis (z.B. C:\ORANT).
X Löschen Sie ggf. die noch vorhandenen Programmgruppen.
X Kontrollieren Sie die Regestrierungsdatenbank. Löschen Sie ggf. den Eintrag
ORACLE im Verzeichnis HKEY_LOCAL_MACHINE\SOFTWARE. Löschen Sie
diesen Eintrag ebenfalls im Verzeichnis HKEY_CURRENT_USER\SOFTWARE.
X Auch die Einträge der Dienste müssen aus der Windows-Registrierung ver-
schwunden sein oder ansonsten manuell von Ihnen gelöscht werden. Sie fin-
den diese Einträge im Verzeichnis HKEY_LOCAL_MACHINE\SYSTEM\Services.
Löschen Sie hier alle Einträge, die mit „Oracle“ beginnen.
X Starten Sie Ihren Rechner neu.
Bei Klementine war es nicht nur sauber, sondern immer rein. Bei der Registrie-
rungsdatenbank von Windows schafft auch Ariel das nicht immer, aber sofern Sie
die eben genannten Schritte ausführen, dann ist Ihr System so aufgeräumt, dass
eine erneute Installation problemlos möglich sein sollte.
1.2.3 Installation von 8i

Die Installation eines 8i-Servers ist zwar nicht grundsätzlich anders, sieht aber
zumindest völlig anders aus. Das gilt allerdings nicht nur für die Installation, denn
mit dieser Version haben nahezu alle Tools und Werkzeuge neue „Beinkleider“
bekommen.
Schon mit dem ersten Bild des Installationsprogramms werden Ihnen verschiedene
Möglichkeiten angeboten. Beispielsweise können Sie von hier aus die bereits installier-
ten Produkte betrachten oder eine Deinstallation vorhandener Softwarekomponenten
einleiten. Uns interessiert im Augenblick natürlich der Installationsvorgang, weshalb
wir mit Hilfe der Weiter-Schaltfläche den nächsten Installationsschritt einleiten.
Der zweite Arbeitsschritt des Installationsvorgangs entspricht im Prinzip der Abbil-
dung 1.6 und dient im Wesentlichen wieder zur Festlegung des Installationsziels
und zur Vorgabe des Standardverzeichnisses, das wieder mit der Umgebungsvari-
able oracle_home verknüpft ist. Legen Sie also hier das gewünschte Installationsziel
Installation 33
fest und wechseln Sie wieder mit Hilfe der Weiter-Schaltfläche zum nächsten
Arbeitsschritt. Dieser entspricht im Vergleich mit der klassischen Variante der
Abbildung 1.8, d.h. Sie haben hier die Wahl, verschiedene Produktkategorien aus-
zuwählen.
Abbildung 1.13: Auswählen der Produktkategorie bei der 8i-Installation
Ich wähle hier die erste Kategorie „Oracle8i Enterprise Edition“, um einen Daten-
bankserver mit allen benötigten Komponenten zu installieren. Danach geht es mit
der Weiter-Schaltfläche zum nächsten Schritt, in dem die Installationsmethode aus-
gewählt werden muss. Dabei haben Sie wieder die Auswahl zwischen einer Stan-
dardmethode, einem etwas kleiner geschnürten Paketes und der individuellen Aus-
wahl der zu installierenden Komponenten.
Ich habe diesmal die individuelle Variante gewählt (vgl. Abb. 1.14) und mit Hilfe
der dargestellten hierarchischen Liste alle Komponenten ausgewählt, die in etwa
einer klassischen 8er-Installation entsprechen. Natürlich können Sie fehlende
Komponenten wieder jederzeit nachinstallieren. Falls Sie sich überhaupt nicht
sicher sind oder Ihre erste Installation ausführen und genügend Plattenplatz zur
Verfügung haben, dann spricht auch nichts dagegen, die Standardinstallationsme-
thode zu verwenden, so dass auch automatisch wieder eine Starterdatenbank ange-
legt wird.
Bei der manuellen Installationsvariante erhalten Sie im nächsten Arbeitsschritt
einen Dialog, in dem abgefragt wird, ob Sie zusammen mit der Installation eine
Starterdatenbank generieren möchten. Ich lehne diesmal dankend ab und wech-
sele zum nächsten und letzten Dialog des Installationsassistenten, in dem Ihnen
noch einmal das geplante Installationsszenario (vgl. Abb. 1.15) gezeigt wird.
Abbildung 1.14: Manuelle Auswahl der installierbaren Komponenten
Abbildung 1.15: Anzeige der geplanten 8i-Installation

Dienste unter Windows-NT 35
Nach Auswahl der Schaltfläche Installieren beginnt das Programm damit, die benö-
tigten Dateien von der CD zu kopieren. Dabei muss man eindeutig feststellen, dass
die Angelegenheit im Vergleich zu früher eindeutig länger dauert. Außerdem muss
ich hier noch einmal meinen Schrecken über den benötigten Platzbedarf kundtun,
von dem ich mich bis heute noch nicht ganz erholt habe, denn trotz meiner
zurückhaltenden Auswahl hat die Installation ca. 700 MB auf meiner Festplatte
gefressen. Das wäre Stoff für folgende Schlagzeile „der sich vom ersten Schock
leicht erholte Patient verstarb vollends, nachdem er feststellte, dass in dieser
Menge noch keine Datenbank und keine Dokumentation enthalten war“.
1.3 Dienste unter Windows-NT

X Mit Hilfe des eben beschriebenen Installationsprogramms haben Sie nun Oracle
oder Oracle 8i auf Ihrem Rechner installiert und eventuell auch Ihre erste
Oracle-Instanz (SID=orcl) mitsamt zugehöriger Datenbank generiert. Durch die
standardmäßige Installation und die Generierung der Starterdatenbank wurden
in Ihrem Windows-Betriebssystem eine Reihe von Diensten eingetragen, die
den Betrieb der Datenbankinstanz vereinfachen (vgl. Abb. 1.16).
Abbildung 1.16: Wichtige Dienste zum Betrieb der Oracle-Instanz
Von den insgesamt installierten Diensten sind für den Betrieb der Starterdatenbank
aber nur folgende drei notwendig, wobei die vom System konkret vergebenen
Dienstnamen zum einen von der installierten Oracle-Version und zum anderen
von dem von Ihnen vorgegebenen Namen für das Homeverzeichnis abhängt:
X OracleServiceORCL
Dieser Dienst startet die für die Datenbank benötigten Instanz. Entsprechend
den letzten Buchstaben der Dienstbezeichnung wird hierbei die Instanz ORCL
(=SID) gestartet.
X OracleStartORCL
Dieser Dienst veranlasst die Instanz zum Öffnen der zugehörigen Datenbank.
Einmal gestartet, verrichtet dieser Dienst die beschriebene Aufgabe und „frisst
anschließend kein Brot mehr“. Sie können ihn also laufen lassen; Sie könnten
ihn auch beenden, für die Betriebsbereitschaft der Oracle-Datenbank spielt das
keine Rolle.
X OracleTNSListener80
Wenn Sie das Grundlagen-Kapitel vollständig gelesen haben, dann erinnern Sie
sich vielleicht an den schematischen Aufbau eines Client/Server-Systems (Abbil-
dung 1.2). Dieser Dienst repräsentiert genau den auf dem Server beschriebenen
Nachrichtendienst. Er muss also laufen, damit eine Kontaktaufnahme mit der
Datenbank möglich ist.
Wenn Sie eine Installation auf einem NT-Server durchführen, dann ist es sicherlich
sinnvoll alle diese Dienste mit dem Start von NT auch automatisch zu starten, d.h.
als „Startart“ für diese drei Dienste wäre „Automatisch“ – so wie in der Abbildung
1.12 - die richtige Einstellung.
Auf meinem Notebook habe ich aber keine Lust, dass mir im Hintergrund perma-
nent Ressourcen geklaut werden, obwohl ich gerade gar keine Datenbank brauche,
weil ich vielleicht nur einen Brief schreibe. Oder von allen installierten Datenban-
ken braucht man je nach Aufgabenstellung gerade nur eine spezielle Auswahl. In
all diesen Fällen können Sie die nicht benötigten Datenbankinstanzen beenden,
indem Sie die zugehörigen Dienste mit Hilfe der Systemsteuerung beenden. Die
Reihenfolge, in der Sie die einzelnen Dienste beenden ist dabei gleichgültig. Beach-
ten Sie allerdings, dass der Dienst OracleTNSListener80 laufen muss, wenn Sie mit
wenigstens einer Datenbankinstanz arbeiten wollen.
Wenn die Nichtbenutzung der Datenbankdienste eher die Regel als die Ausnahme
ist, dann sollten Sie die Startart dieser Dienste auf „Manuell“ abändern, damit mit
dem Starten Ihres Rechners keine Oracle-Instanzen hochgefahren werden. Bei
Bedarf können Sie die benötigten Datenbankdienste jederzeit mit Hilfe der Win-
dows-Systemsteuerung aktivieren; die Reihenfolge in der Sie die einzelnen Dienste
aktivieren ist dabei gleichgültig. Wenn Sie beispielsweise zuerst den Dienst Oracle-
StartORCL starten, dann werden Sie feststellen, dass diese Aktion im Hintergrund
auch den Start des Dienstes OracleServiceORCL und damit das Hochfahren der zuge-
hörigen Datenbankinstanz bewirkt.
Bei so viel Arbeit macht es vielleicht Sinn, sich für dieses Hoch- und Runterfahren
einen „Liftboy“ anzuschaffen, der einem die Arbeit abnimmt und nur noch auf die
Kommandos „hoch“ bzw. „runter bitte“ hört. Windows-NT bietet Ihnen standard-
mäßig die Möglichkeit, sich einen solchen Diener zu basteln. Mit Hilfe des NET-
Kommandos können Sie jeglichen installierten Dienst hoch- oder runterfahren.
Konkret werden die hier benötigten NET-Befehle in einer Stapelverarbeitungsdatei
(ich finde BATCH klingt besser) zusammengefasst und für diese BATCH-Datei
erstellen Sie einfach eine Verknüpfung in einer Programmgruppe oder sogar direkt
auf Ihrem Desktop.
Die Batchdatei zum Starten der Dienst (CD: \SCRIPT\START_ORCL.BAT) könnte
etwa folgendermaßen aussehen:
Verbindung zur Datenbank herstellen 37
rem Starten des Listeners,

rem Starten der Oracle-Instanz ORCLÖffnen der Datenbank
net start OracleTNSListener80
net start OracleStartORCL
net stop OracleStartORCL
Listing 1.1: Starten der Datenbank mit Hilfe von Net-Kommandos
Ganz ähnlich sieht das benötigte Skript zum Beenden der ORCL-Datenbankinstanz
(CD: \SCRIPT\STOP_ORCL.BAT) aus:
rem Stoppen des Listeners, Stoppen der Datenbank ORCL

net stop OracleTNSListener80
net stop OracleStartORcL
net stop OracleServiceORCL
Listing 1.2: Stoppen einer Datenbank mit Hilfe von Net-Kommandos
Auf ähnliche Weise können Sie sich für jede denkbare Kombination von Daten-
bankdiensten entsprechende Skripte erstellen. Wenn Sie bei deren Ausführung ver-
suchen einen schon laufenden Dienst (z.B. OracleTNSListener80) noch einmal zu
starten, dann ist das nicht weiter schlimm; Sie erhalten in dem Fall lediglich eine
entsprechende Warnmeldung.
1.4 Verbindung zur Datenbank herstellen

Die Installation einer Oracle-Datenbank läuft dank der mitgelieferten Installations-
programme zwischenzeitlich unproblematisch und zeitgemäß. Dennoch gibt es im
Rahmen der ersten Experimente und Gehversuche in der Regel zwei zunächst
unsichtbare Hürden mit erheblichem Frustpotential, die es zu überwinden gilt.
Zum einen haben Sie im Rahmen der Installation jetzt eine Datenbank - nebst
einer Menge Werkzeuge zur Bearbeitung derselben - auf Ihrem Rechner laufen,
jedoch ist die Verfahrensweise zur Kontaktaufnahme noch völlig ungeklärt und
ohne weitere Eingriffe auch nicht möglich. Zum anderen hegen Sie in Ihrem inne-
ren vielleicht den Wunsch, selbständig eine eigene Datenbank zu erstellen. Auf-
grund der Architektur von Oracle (z.B. eine Instanz pro Datenbank) ist das nicht
ganz so einfach wie in manch anderem DBMS-Systemen. Ein Befehl der Form create
database reicht hier alleine jedenfalls nicht aus. Falls Sie an einem dieser beiden
Probleme schon einmal verzweifelt sind, so kann ich Sie trösten: „Willkommen im
Club“, Sie sind nicht der erste, einzigste und sicherlich auch nicht der letzte, der
sich bei diesen Aufgaben irgendwann einmal mit scheinbar unüberwindbaren Pro-
blemen konfrontiert sah. Doof ist eigentlich nur, dass das Ganze eigentlich ganz
einfach ist, aber im Nachhinein ist man ja immer schlauer.
In diesem Kapitel will ich Ihnen im Folgenden die Kontaktaufnahme mit Ihrer
Datenbank etwas näher bringen und im nächsten Kapitel beschäftigen wir uns dann
mit dem Erstellen eigener Datenbanken. Allerdings werde ich Ihnen hierbei nur
soviel technische und theoretische Hintergrundinformationen liefern wie unbedingt
notwendig ist, damit Sie zum einen wissen worum es überhaupt geht und zum ande-
ren in der Lage sind, Ihre eigene Installation oder die Installation in einem kleinen
Netzwerk erfolgreich durchführen zu können. Zum Thema „Oracle Networking“
könnte man mittlerweile ein eigenes umfangreiches Buch erstellen. Ich will daher
gar nicht erst den Versuch unternehmen, dieses komplexe Thema im Rahmen des
Workshops irgendwie umfassend oder zusammenhängend abzuhandeln.
1.4.1 Einführung in SQL*Net bzw. Net8

Das Zauberwort für die Verbindungsherstellung zu einer Oracle-Datenbank heißt
SQL*Net., wobei man entsprechend der aktuellen Version mittlerweile auch nur
noch von Net8 spricht. Dieser Begriff hat aber überhaupt nichts mit SQL zu tun
und die Entscheidung, ob das Ganze „nett“ ist, überlasse ich getrost Ihnen. Viel-
mehr handelt es sich hierbei um eine Art „Überprotokoll“, das zwischen der
Anwendung und dem eigentlichen Netzwerk gelagert ist (vgl. Abb. 1.17).
Client Server
Anwendung Oracle-DBMS
Net8 Net8
Oracle Protokoll-Adapter Oracle Protokoll-Adapter
Netzwerkprotokoll Netzwerkprotokoll
Physisches Netzwerk
Abbildung 1.17: Schema der Net8-Kommunikation
Will eine Anwendung Verbindung mit einer Datenbank aufnehmen, dann fordert
sie diese quasi ganz abstrakt, d.h. ohne Berücksichtigung irgendwelcher physi-
schen Gegebenheiten, über Net8 an. Das Gleiche gilt auch, wenn das Anwendungs-
programm Daten versenden will oder auf den Empfang von Daten vom Server war-
tet. Das Anwendungsprogramm muss sich in keinem Fall selbst um die durch das
Netzwerkprotokoll vorgegebenen Regeln bei der Kommunikation kümmern. Diese
Art der Kommunikation bezeichnet Oracle übrigens mit dem Begriff Transparent
Network Substrate, was an vielen Stellen einfach mit TNS abgekürzt wird.
Die von der Anwendung gestellten Verbindungsanforderungen werden von Net8
mit Hilfe des installierten Oracle-Protokoll-Adapters für das konkret vorhandene
Netzwerk übersetzt bzw. an dieses übergeben. Das Verfahren wird sowohl auf dem
Client als auf dem Server angewendet und funktioniert in beide Richtungen.
Für uns Nichtnetzwerker hat Net8 den Nachteil, dass wir selbst bei der Installation
einer kleinen Spiel- oder Übungsdatenbank bestimmte Konfigurationseinstellun-
gen durchführen müssen, damit das in Abbildung 1.17 dargestellte „Sandwich“
entsprechend durchlässig ist. Aber hören wir auf zu jammern, die Vorteile dieser
Architektur überwiegen mehr als eindeutig:
X Stellen Sie sich einmal vor, jemand erfindet ein neues Netzwerkprotokoll. In
dem Fall müssen Sie nur auf die Verfügbarkeit des passenden Oracle-Protokoll-
Adapters warten. Weder Ihre Anwendung noch der Oracle-Server selbst müssen
in irgendeiner Form angepasst werden.
X Was bei einfachen Strukturen vielleicht ein wenig kopflastig erscheint, zeigt sei-
ne wahren Stärken erst bei komplexeren Netzwerken. Stellen wir uns hierzu
zwei Datenbanken, eine auf einem NT- und die andere auf einem NOVELL-Ser-
ver vor. Jetzt haben wir es üblicherweise mit zwei Netzwerkprotokollen (TCP/IP
und SPX), d.h. wir installieren einfach diese beiden Oracle-Protokoll-Adapter.
Grundsätzlich wird durch Net8 die Verwendung verschiedener Netzwerkproto-
kolle oder einer Server/Server-Verbindung wesentlich vereinfacht.
X Die genaue Arbeitsweise der Verbindungsschicht zwischen Anwendung und
DBMS wird mit Hilfe von Konfigurationsdateien gesteuert. Bei einem Versions-
wechsel müssen Sie in der Regel daher lediglich die entsprechenden Programme
und Bibliotheken austauschen. Die alten Konfigurationsdateien bilden an-
schließend zusammen mit der neuen SQL*Net-Version wieder genau das glei-
che logische Oracle-Netzwerk wie vorher ab.
X Dieser Vorteil gilt im Übrigen auch, wenn Sie mit verschiedenen SQL*Net bzw.
Net8-Versionen parallel arbeiten müssen. Immerhin gibt es noch reichlich klas-
sische (16-Bit) Windows-Anwendungen und diese benötigen für Ihren Betrieb
die Installation des Oracle-Clients für Windows. Gerade der 16-Bit-Client für
Windows und der NT-Client laufen auf einem Rechner problemlos nebeneinan-
der, wobei Sie die Net-Konfigurationsdateien für beide Installationen verwen-
den können.
X Die Net8-Architektur vereinfacht die Bereitstellung zentraler Hilfsmittel, bei-
spielsweise zur Fehleranalyse oder zur Verschlüsselung der übermittelten Daten.
Ein entsprechend benötigter Service wird einfach in der zughörigen Konfigura-
tionsdatei ein- bzw. ausgeschaltet. Bleiben wir mal bei der Verschlüsselung der
übermittelten Daten: Wird eine solche Option gewählt, dann gilt sie automa-
tisch für alle eingesetzten Anwendungsprogramme, ohne das in diesen irgen-
detwas geändert oder angepasst werden muss.
Bei der Verbindungsanforderung von einem Anwendungsprogramm zum Oracle-
DBMS spielt allerdings noch eine weitere Komponente eine Rolle, die Sie bisher
zwar schon gesehen haben, deren genaue Funktion bis jetzt aber noch nicht
besprochen wurde. Es handelt sich hierbei um den auf dem Server laufenden Liste-
ner-Prozess, den Sie bei einer standardmäßigen NT-Installation als Dienst
OracleTNSListener80 kennen gelernt haben. Dieser Dienst hört permanent das Netz-
werk ab und dient quasi als zentrale Empfangsstation aller eingehenden Verbin-
dungsanfragen.
Wie schon gesagt, kann der genaue Name dieses Dienstes variieren, d.h. der stan-
dardmäßig vergebene Name hängt von der verwendeten Version und Ihren Instal-
lationsvorgaben ab. Die Wörtchen TNS und Listener tauchen aber im Regelfall
immer auf, so dass der von mir gemeinte Dienst eigentlich immer zu identifizieren
ist.
Dadurch wird das eigentliche DBMS von dieser Horchaufgabe entlastet. Stellen Sie
sich mal einen Busfahrer (DBMS) vor, der neben seiner Fahrtätigkeit auch noch
permanent auf alle Fahrgäste achten muss, ob an der nächsten Haltestelle jemand
aussteigen will. Während der Fahrt reden sowieso alle Gäste (Clients) durcheinan-
der und trotzdem müsste der Fahrer permanent auf signifikante Begriffe (z.B.
„Stop“) achten. Da ist es doch einfacher, man installiert einen Listener in Form
eines roten Stopknöpfchens und wenn ein Client (Fahrgast) diesen drückt, dann
erhält der Fahrer (DBMS) diese Aufforderung ganz automatisch (weil es bei ihm
vorne klingelt) ohne sich um den Erhalt der Information kümmern zu müssen.
Solche Listener können das Netzwerk für mehr als ein DBMS abhören. Für welche
sie es konkret tun, das muss ebenfalls im Rahmen der Net8-Konfiguration festgelegt
werden.
Für mich sind im Rahmen meiner Beratertätigkeit solche Dinge, genau wie Netz-
werke, Rechnerarchitekturen u.ä., immer Mittel zum Zweck. In der Regel sie genau
wie eine Net8-Installation beim Kunden sowieso von entsprechenden Spezialisten
geplant und konfiguriert. Trotzdem ist es natürlich interessant zu wissen, worum es
eigentlich geht; schließlich will man ja mitreden können und hierzu haben Sie, so
denke ich, jetzt genug Informationen bekommen. Das ganze Spektrum der Net8-
Konfiguration und Möglichkeiten finden Sie natürlich wieder in der Oracle-Doku-
mentation, und zwar im Buch „Oracle8 Networking“ bzw. „Oracle8i Server Net-
working“.
1.4.2 Verbindung zur „ Starterdatenbank““ herstellen

Nun geht es endlich los, wir kümmern uns um die Verbindung zu unserer Starter-
datenbank. Standardmäßig befinden sich die Net8-Konfigurationsdateien im
\NET80\ADMIN-Verzeichnis bzw. bei der 8i-Version im \NETWORK\ADMIN, dass
selbst wiederum unterhalb des Oracle-Homveverzeichnisses (z.B. E:\ORANT)
angelegt ist. Beim alten 16-Bit-Client heißt der zugehörige Pfad übrigens auch
\NETWORK\ADMIN (also „Back to the Roots“) und befindet sich im entsprechen-
den Home-Verzeichnis der 16-Bit-Installation (z.B. C:\ORAWIN).
Keine Regel ohne Ausnahmen, das gilt natürlich auch hier. Gerade in größeren
Unternehmen werden Sie in der Windows-Registrierung öfters den Schlüssel
TNS_ADMIN im Verzeichnis \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE fin-
den. Mit Hilfe dieses Eintrags können Sie den Ort für die Konfigurationsdateien des
Net8-Zugriffs festlegen, beispielsweise um die entsprechenden Dateien zentral
bereitzustellen. Bedenken Sie: Je nach Softwarearchitektur wird der Oracle-Client
ggf. auf jeden Arbeitsplatzrechner installiert. Da sich der Client nicht täglich
ändert und wegen den heutzutage möglichen Verfahrensweisen der automatischen
Softwareverteilung ist das eigentlich auch nicht weiter dramatisch. Aber schnell
reagieren kann man auf diese Weise sicherlich nicht. Bei einer solchen Installation
müssten aber auch alle Konfigurationsdateien auf die lokalen Arbeitsplatzrechner
kopiert werden und wie Sie gleich sehen werden, ändern sich diese, wenn beispiels-
weise eine neue Datenbank angelegt wird oder sich irgendwelche Servernamen
oder Adressen ändern. Die neue Net8-Konfiguration müsste jetzt ebenfalls auf alle
Rechner übertragen werden. Da ist es schon sinnvoll, die Steuerungsdateien des
Net8-Netzwerks auf einem zentralen Dateiserver bereitzustellen; mit Hilfe von
TNS_ADMIN ist das kein Problem.
Den „Listener“ konfigurieren

Beginnen möchte ich mit der Konfiguration des Listeners. Hierzu finden Sie auf
dem Server, ebenfalls im \NET80\ADMIN- bzw. \NETWORK\ADMIN Verzeichnis
die Datei LISTENER.ORA. Der Aufbau der Datei ist meisten relativ einfach bzw. sie
enthält nur wenige Parameter, weshalb eine Anpassung auch per Hand möglich ist.
Im Rahmen der Installation wird übrigens meistens schon eine Beispieldatei mit
verschiedenen Einträgen erstellt und in jedem Fall finden Sie auf der Begleit-CD ein
Muster unter dem Namen \NET80\LISTENER.ORA.
Ähnlich wie eine Windows-Konfigurationsdatei enthält auch die Datei LISTE-
NER.ORA neben Kommentaren verschiedene Einstellungen, die mit Hilfe spezieller
Schlüsselwörter in der Form „Schlüssel = Wert“ festgelegt werden.
# Ich bin ein Kommentar

STARTUP_WAIT_TIME_LISTENER = 0
Die vom Listener abzuhörenden Protokolle und Adressen werden mit Hilfe des
Schlüsselwortes LISTENER in Form einer Adress-Parameter-Liste angegeben. Das
nachfolgende Beispiel zeigt die Konfiguration für einen Listener, der ebenfalls den
Namen „LISTENER“ erhält und auf dem Rechner ray_dell (hier könnte auch eine IP-
Adresse stehen) die Ports 1521 und 1526 überwacht:
LISTENER =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL= TCP) (Host= ray_dell) (Port= 1521) )
)
Listing 1.3: Konfiguration der Ports für den Listener-Prozess
In unserem Beispiel müssen Sie den Rechnernahmen natürlich gegen den Namen
bzw. die Adresse Ihres Datenbankservers austauschen. Wie schon erwähnt, kann so
ein Listener für mehrere Datenbanksysteme zuständig sein. Läuft auf dem Rechner
mehr als eine Datenbankinstanz, so müssen Sie die zum Listener gehhörenden
Instanzen mit Hilfe des Parameters SID_LIST_LISTENER festlegen. Dabei schadet es
natürlich nicht, wenn Sie den Parameter auch bei nur einer Datenbankinstanz ein-
tragen:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = oracle) (SID_NAME = ORCL) )
(SID_DESC = (GLOBAL_DBNAME = datab01) (SID_NAME = db01) )
)
Listing 1.4: Festlegen der „Horchliste“ für den Listener
Wie Sie an dem Beispiel erkennen können, besteht die eben beschriebene Instan-
zenaufzählung im Wesentlichen aus der Benennung des Datenbanknamens nebst
zugehöriger Instanzbezeichnung (SID). Für die Starterdatenbank war der Daten-
bankname oracle und die Instanz wurde mit orcl bezeichnet. Später im Kapitel 1.5
werden Sie erfahren, wie diese Begriffe zustande kommen. Außerdem habe ich dem
Listener schon einmal angewiesen, den Abhördienst auf für die noch zu erstellende
Datenbank (datab01, SID=db01) aufzunehmen.
Wenn Sie Änderungen in der Konfigurationsdatei vornehmen, dann werden die
erst wirksam, wenn Sie den Listener runter und anschließend wieder hochfahren.
Außerdem können Sie mit Hilfe verschiedener Parameter (vgl. nachfolgenden Ver-
weis auf die Dokumentation) die Protokollfunktion des Listeners ein- bzw. ausschal-
ten oder den Namen bzw. den Ort des Protokolls festlegen. Standardmäßig ist die
Protokollfunktion eingeschaltet und Sie finden die Ausgabe LISTENER.LOG in dem
\NET80\LOG- bzw. \NETWORK\LOG-Verzeichnis.
Weitere Informationen über die Parametrierung des Listeners bzw. zu den Einstel-
lungen in der Datei LISTENER.ORA finden Sie wie immer in der Oracle-Dokumen-
tation, vor allem in den Kapiteln des Buches „Net8 Administrator’s Guide“. Eine
vollständige Übersicht aller vorhandenen Parameter finden Sie bei der Version 8
dort im Anhang B „Configuration Parameters“, d.h. genauer im dortigen Kapitel
„B.4 Listener Parameters (LISTENER.ORA)“. Bei der 8i-Version ist aus diesem „B“
ein „C“ geworden, der eigentlich Titel des Anhangs ist aber gleich geblieben.
Listener-Verwaltung
Wie schon gesagt, handelt es sich bei dem Listener um einen Hintergrundprozess,
der unter Windows-NT mit Hilfe eines entsprechenden Dienstes verwaltet wird.
Damit stellt sich die Frage, wie dieser Dienst überhaupt zustande kam, was prinzi-
piell zu tun ist, wenn Sie einen weiteren Listenerprozess installieren möchten oder
wenn aus irgendwelchen Gründen während der Installation kein passender Win-
dows-Dienst generiert wurde.
Zu diesem Zwecke existiert ein Programm, das auf den Namen LSNRCTL80.EXE
bzw. LSNRCTL.EXE bei 8i hört und eine Art Listener-Konsole repräsentiert. Das Pro-
gramm können Sie in einem MS-DOS-Fenster starten, wobei sich nach dem Start
(vgl. Abb. 1.18) zunächst einmal nur der angezeigte Eingabeprompt ändert.
Abbildung 1.18: Starten der Listener-Konsole bei einer 8i-Installation
Das Programm bietet Ihnen eine ganze Reihe von Möglichkeiten, wobei Sie vor-
handene Kommandos angezeigt bekommen, wenn Sie am Prompt den Befehl help
eingeben. Die Bedeutung weiterer wichtiger Kommandos können Sie der Tabelle
1.2 entnehmen.
Kommando Beschreibung
start <listener> startet den spezifizierten Listener. Da die Konfigurationsdatei für den Liste-
ner heißt LISTENER.ORA, und dort wurde durch Eintrag LISTENER= der
Name des Listeners festgelegt. Bei mehreren Listener existieren in dieser Da-
tei auch entsprechend viele Einträge (z.B. LISTENER01= usw.). Durch die
Eingabe des Befehls „start listener“ können Sie also den in der Datei definier-
ten Listener starten. Hierdurch erhalten Sie beispielsweise auch einen verlo-
rengegangenen Windows-Dienst zurück.
stop <listener> stoppt den angegebenen Listener-Prozess.
status zeigt den aktuellen Status des vorgegebenen Listeners am Bildschirm an.
<listener>
reload <liste- aktiviert eine geänderte Listenerkonfiguration.
ner>
exit beendet das Programm.
Tabelle 1.2: Wichtige Kommandos der Listener-Konsole
Den Client konfigurieren

Der Net8-Client wird im Minimum mit Hilfe der Dateien SQLNET.ORA und
TNSNAMES.ORA konfiguriert. Im Unterschied zur Datei LISTENER.ORA befinden
sich diese Dateien meistens nicht nur auf jedem Client, sondern ebenfalls auch auf
dem Server, und zwar in beiden Fällen wieder im \NET80\ADMIN- bzw.
\NETWORK\ADMIN-Unterverzeichnis des Oracle-Homeverzeichnisses. Sofern ein
TNS_ADMIN-Eintrag in der Windows-Registrierung vorliegt befinden sich die
Dateien natürlich an dem dort spezifizierten Ort. Ähnliches gilt auch, wenn wei-
tere Net8-Clients (z.B. 16-Bit Windows) installiert wurden, d.h. in den Fällen müs-
sen die Konfigurationsdateien zusätzlich in alle \NET80\ADMIN- bzw.
\NETWORK\ADMIN-Unterverzeichnisse kopiert werden.
Wenn Sie sich nun fragen, warum diese beiden Dateien, deren Funktion zur Zeit
noch völlig offen ist, auch auf dem Server kopiert werden sollen, dann will ich Sie
in Bezug auf diesen Punkt nicht mehr länger auf die Folter spannen. Innerhalb
einer Oracle-Datenbank besteht die Möglichkeit, beispielsweise mit Hilfe einer
Abfrage Daten aus einer anderen Datenbank abzurufen. Diese Datenbank könnte
mit seinem DBMS auf demselben oder einen völlig anderen Rechner liegen. Wie
auch immer: Wenn eine Oracle-Datenbank Informationen aus einer zweiten
Datenbank anfordert, dann verhält sie sich aus Sicht dieser zweiten Datenbank wie
ein gewöhnlicher Client. Aus dem Grund sollte also auch auf dem Server eine funk-
tionsfähige Client-Konfiguration vorliegen.
Grundeinstellungen via SQLNET.ORA Mit Hilfe der Konfigurationsdatei
SQLNET.ORA können Sie ein sogenanntes Profil erstellen, mit dem Sie verschie-
dene Präferenzen für die Nutzung von Net8 vorgeben können. Das lässt den
Schluss zu, dass diese Datei im Ausnahmefall sogar fehlen könnte, wenn es über-
haupt keine solcher Voreinstellungen gibt. Meistens werden Sie bei der Begutach-
tung vorhandener Installationen allerdings ein definiertes Profil in Form der Datei
SQLNET.ORA finden.
Im Einzelnen können Sie mit Hilfe des Profils
X Parameter zur Namensgebung,
X Verschlüsselungseinstellungen,
X Sicherheitseinstellungen,
X Trace- und oder Log-Einstellungen
und viele weitere Parameter festlegen. Für kleine Installation können Sie die wäh-
rend der Installation als Muster kopierte Version ohne Änderungen verwenden
und selbst bei riesigen Netzwerken gibt es keinen zwingenden Grund für irgend-
welche Eingriffe. Beachten Sie allerdings die fett markierte Einstellung des Parame-
ters names.default_domain, denn der Wert taucht ein paar Absätze tiefer bei der
Behandlung der Dienst- bzw. Servicenamen wieder auf. Der hier eingestellte Wert
sorgt für eine automatische Qualifizierung der definierten Dienstnamen, indem er
ihm automatisch zusammen mit einem Punkt angehängt wird. Möchte ein
Anwender beispielsweise mit dem Dienst „otto“ arbeiten, dann führt dies aufgrund
des abgebildeten Parameters intern zur Anforderung „otto.world“.
TRACE_LEVEL_CLIENT = OFF
sqlnet.authentication_services = (NTS)
names.directory_path = (TNSNAMES, HOSTNAME)
names.default_domain = world
name.default_zone = world
automatic_ipc = off
Listing 1.5: Typisches Net8-Profil

Alle verfügbaren Parameter finden Sie mit einer ausführlichen Beschreibung wieder
im „Net8 Administrator’s Guide“ der Oracle-Dokumentation und dort je nach Ver-
sion im Anhang B oder C. In diesem Buch finden Sie im Übrigen an vielen Stellen
Informationen zu den Profilen mit seinen möglichen Einstellungen. Ansonsten
kann ich Ihnen auch die Seiten „Oracle Net8 Getting Started for Windows NT/95”
empfehlen. Dort finden Sie eine zusammenhängende Beschreibung der Datei
SQLNET.ORA im Anhang B „Configuration File Content“ im Kapitel „Understan-
ding the SQLNET.ORA File”.
Konfiguration der Servicenamen Alle guten Dinge sind drei, und so kommen wir
abschließend zur dritten benötigten Konfigurationsdatei. Immer wenn Sie sich mit
Hilfe einer Anwendung, beispielsweise einem der reichlich mitinstallierten Werk-
zeuge, an eine Oracle-Datenbank anmelden möchten, dann erhalten Sie zunächst
einen kleinen Dialog, in dem Sie neben einer Benutzer-Id und einem Passwort auch
einen Servicenamen bzw. Dienstnamen eintragen müssen (vgl. Abb. 1.19).
Abbildung 1.19: Abfrage des Servicenamens bei einer Datenbankanmeldung
Der Service- oder auch Dienstname repräsentiert eine DBMS-Instanz nebst Daten-
bank, die auf irgendeinem Rechner verfügbar ist. Auf dem Client wird die Verbin-
dung zur Datenbank also noch einmal abstrahiert, in dem Sie hier einen nahezu
völlig frei wählbaren Servicenamen zur Anmeldung eingeben müssen. So wäre es
denkbar, dass Sie sich über den Service DonaldDuck konkret an eine Datenbankin-
stanz TT23 mit der Datenbank AUSKUNFT auf einem Rechner mit der IP-Adresse
1.33.133.8 anmelden. Diese Verbindung zwischen den Dienstnamen und irgend-
welchen auf irgendwelchen Rechnern laufenden Datenbankinstanzen findet in der
Datei TNSNAMES.ORA statt.
GutenMorgen.world =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = ray_dell)
(PORT = 1521)
)
(CONNECT_DATA = (SID = ORCL)
)
)
Listing 1.6: Beispiel der Definition eines Net8-Dienstnamens

In dem Beispiel wird der Dienstname GutenMorgen definiert und mit der DBMS-
Instanz orcl auf dem Rechner ray_dell verknüpft. Die Kommunikation erfolgt über
TCP/IP mit Hilfe des Ports 1521. Kommt Ihnen hierbei einiges bekannt vor? Ich habe
die Zusammenhänge der drei Konfigurationsdateien LISTENER.ORA, SQLNET.ORA
und TNSNAMES.ORA in der Abbildung 1.20 noch einmal zusammengefasst.
TNSNAMES.ORA
GutenMorgen.world =
(DESCRIPTION = names.default_domain = world
(ADDRESS =
(PROTOCOL = TCP) SQLNET.ORA
(HOST = ray_dell)
(PORT = 1521)
)
(CONNECT_DATA = (SID = ORCL)
)
)
LISTENER.ORA
LISTENER =
(ADDRESS_LIST =
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = oracle) (SID_NAME = ORCL) )
)
Abbildung 1.20: Verbindungen innerhalb der Konfigurationsdateien
Bei den Dienst- oder Servicenamen handelt es sich also wirklich um willkürliche
Bezeichnungen für konkret existierende Datenbankinstanzen. Demzufolge können
Sie für ein und dieselbe Datenbank auch mehrere verschiedene Dienstnamen in der
Datei TNSNAMES.ORA definieren. Ein Beispiel: In der Datei TNSNAMES.ORA sind
die Dienstnamen Montag, Dienstag ... Freitag definiert. Entsprechend dem Wochen-
tag meldet sich der Benutzer mit Hilfe des zugehörigen Dienstes in der Datenbank
an. Die konkreten Definitionen der Dienste in der Datei TNSNAMES.ORA legen nun
fest, mit welcher Datenbank der Anwender wirklich arbeitet; vielleicht sogar immer
mit derselben.
Verbindung zur „ Starterdatenbank““ herstellen

Wenn Sie möchten und mit einem TCP/IP-Netzwerk arbeiten, dann können Sie
nun die Verbindung zur „Starterdatenbank“ manuell herstellen. Hierzu finden Sie
auf Ihrer CD im \NET80-Unterverzeichnis die drei soeben beschriebenen Konfigu-
rationsdateien. Ansonsten finden Sie in den nächsten beiden Kapiteln Hinweise,
wie Sie die Konfiguration mit Hilfe verschiedener Oracle-Werkzeuge vornehmen
können. Gehen Sie zur manuellen Installation folgendermaßen vor:
X Kopieren Sie die drei Dateien in das \NET80\ADMIN- bzw. \NETWORK\

ADMIN-Verzeichnis auf dem Datenbankserver. In der Datei SQLNET.ORA müs-
sen Sie keine Anpassungen vornehmen.
X Beenden Sie alle laufenden Listenerdienste.
X Ermitteln Sie den Rechnernamen und ggf. die IP-Adresse des Datenbankservers.
Hierzu können Sie auf dem Server in der Netzwerkkonfiguration nachschauen
oder auch folgendermaßen vorgehen:
– Öffnen Sie auf dem Server ein MS-DOS-Fenster. Geben Sie dort den Befehl ip-
config /all (verwenden Sie ipconfig /all | more, wenn Sie nicht alles lesen kön-
nen) ein.
– Notieren bzw. merken Sie sich den Rechnernamen und die IP-Adresse.
X Öffnen Sie auf dem Client ein MS-DOS-Fenster und überprüfen Sie die Netz-
werkkonfiguration. Geben Sie den Befehl ping gefolgt von dem eben ermittelten
Rechnernamen (z.B. ping ray_dell) ein. Erhalten Sie über den Rechnernamen kei-
nen Kontakt zum Server, dann müssen Sie in den folgenden Arbeitsschritten
statt des Namens die zugehörige IP-Adresse verwenden.
X Editieren Sie die Datei LISTENER.ORA mit Hilfe irgendeines Texteditors (z.B.
NOTEPAD.EXE). Die Datei enthält Einträge für die Instanz der Starterdatenbank
(orcl) und die noch zu erstellende Datenbank db01. Tauschen Sie in der Datei
den Namen ray_dell gegen Ihren Servernamen bzw. die eben ermittelte IP-Adres-
se aus.
X Starten Sie die Listener, indem Sie den zugehörigen Dienst wieder aktivieren.
X Editieren Sie die Datei TNSNAMES.ORA. Vorausschauend auf die noch zu erstel-
lende Datenbank finden Sie auch hier schon zwei Diensteinträge (orcl.world und
db01.world). Tauschen Sie jetzt den Namen ray_dell wieder gegen Ihren Server-
namen bzw. dessen IP-Adresse aus.
X Kopieren Sie die Dateien SQLNET.ORA und TNSNAMES.ORA auf einen Client
in das entsprechende \NExx\ADMIN-Unterverzeichnis.
X Testen Sie Ihre Konfiguration. Öffnen Sie hierzu auf dem Client ein MS-DOS-
Fenster Starten Sie das Programm TNSPING80 bzw. TNSPING (bei korrekter In-
stallation sollte ein Pfad-Eintrag auf das \BIN-Unterverzeichnis existieren) ge-
folgt von dem zu überprüfenden Servicenamen (z.B. TNSPING80 orcl; vgl. Abb.
1.21). Aufgrund unserer Einstellungen in der Datei SQLNET.ORA führt die Ein-
gabe des Dienstnamens orcl intern immer zur Verwendung des Dienstes
orcl.world.
Abbildung 1.21: Erfolgreicher Ping zu unserer ORCL- Instanz
Verläuft der Test nicht erfolgreich, so überprüfen Sie noch einmal alle durchgeführ-
ten Arbeitsschritte. Haben Sie die Dateien an die richtigen Stellen kopiert? Über-
prüfen Sie Ihre Änderungen auf Tippfehler. Ist der Datenbank- und Listenerdienst
aktiv? Ein nicht erfolgreicher Test äußert sich in der Anzeige einer Fehlermeldung,
zum Beispiel „TNS-03505: Failed to resolve name“. In der Dokumentation finden
Sie unter „Oracle8 Error Messages“ eine Übersicht aller vorhandenen Fehlermel-
dungen. Neben den Beschreibungen befinden sich hier größtenteils auch brauch-
bare Kochrezepte zu deren Behebung. Die TNS-Fehlermeldungen stehen dort kon-
kret im Kapitel 25.
Natürlich ist es nicht unbedingt notwendig, die Anpassungen an der Net8-Konfi-
guration manuell durchzuführen. Aber wie Sie an den letzten Beispielen gesehen
haben, ist das bei kleinen TCP/IP-Netzwerken durchaus möglich bzw. nicht schwie-
rig. Ansonsten haben Sie die Möglichkeit, zur Anpassung des Net8-Netzwerkes auf
verschiedene Werkzeuge zurückzugreifen, die im Rahmen der Client-Installation
auf Ihren Rechner kopiert werden. In den nächsten zwei Kapiteln möchte ich die
Verwendung dieser beiden Werkzeuge kurz darstellen.
1.4.3 Konfiguration mit Hilfe von Net8 Easy Config

Ein Hilfsmittel zur Konfiguration des Net8-Netzwerkes heißt Net8 Easy Config
(Version 8: N8SW.EXE) und befindet sich üblicherweise in der Programmgruppe
„Oracle for Windows NT“.
Anwendung bei einer 8er-Version

Mit Hilfe dieses Programms können Sie auf besonders einfache Weise die Liste der
Dienstnamen bearbeiten, d.h. hiermit verändern Sie lediglich die Datei
TNSNAMES.ORA, die anderen beiden Konfigurationsdateien (SQLNET.ORA bzw.
LISTENER.ORA) müssen Sie bei Bedarf immer noch manuell anpassen.
Mit der Version 8i haben sich die Programmnamen dieser Werkzeuge alle
geändert bzw. sind gar nicht mehr als eigenständiges Programm vorhanden.
Das liegt ganz einfach daran, dass die Assistenten und Hilfsmittel als Java-
Applikation geliefert werden und somit besondere Klassen zur Ausführung
des benötigten Programms existieren.
Damit ist das Programm zum einen eigentlich nur geeignet, einen neuen Daten-
bankdienst schnell auf einem Arbeitsplatzrechner verfügbar zu machen. Zum
anderen hilft das Programm natürlich auch, Tip- oder Formatfehler zu vermeiden,
die sich beim manuellen Bearbeiten der Datei TNSNAMES.ORA sicherlich leicht
einschleichen können. Im Rahmen der Installation erhalten Sie in Ihrem
\NETxx\ADMIN-Unterverzeichnis eine TNSNAMES-Musterdatei mit verschiede-
nen Dienstnamenseinträgen. Mit Hilfe des Net&Easy-Programms, so will ich dieses
Tool fortan mal nennen, wollen wir diese Datei nun so anpassen, dass wir Zugriff
auf die Starterdatenbank erhalten. Hierzu müssen Sie zunächst die Listener-Konfi-
guration wie im vorherigen Kapitel beschrieben manuell anpassen. Anschließend
müssen Sie den Listener und die ORCL-Datenbankinstanz hochfahren.
Nach dem Start des Programms (vgl. Abb. 1.22) erhalten Sie einen Dialog, mit dem
Sie die Liste der Dienstnamen entsprechend Ihren Anforderungen verändern kön-
nen. Rechts unten im Bild finden Sie eine Liste aller aktuell definierten Dienstna-
men.
Abbildung 1.22: Bearbeiten der TNSNAMES.ORA mit Hilfe von Net8 Easy Config
Im mittleren Teil des Fensters können Sie die durchzuführende Aktion auswählen.
Zunächst wollen wir alle nicht benötigten Dienste aus der Konfiguration entfer-
nen. Also müssen wir die Aktion Delete auswählen und können anschließend den
zu löschenden Dienst in der Liste markieren. Weiter geht es mit der Next-Schaltflä-
che. Jetzt müssen Sie den Löschvorgang nochmals bestätigen und danach erhalten
Sie einen weiteren Dialog (vgl. Abb. 1.23).
Abbildung 1.23: Änderung speichern, verwerfen oder weitere Anpassungen durchführen
An dieser Stelle können Sie Ihre Änderungen speichern, indem Sie das Programm
mit Hilfe der Schaltfläche Finish beenden. Möchten Sie so wie wir allerdings noch
weitere Änderungen durchführen, dann können Sie über die Previous-Schaltfläche
wieder in das Ausgangsbild (Abb. 1.22) zurückkehren. Löschen Sie auf diese Weise
alle Einträge bis auf den Dienst mit dem Namen „TcpExample“.
Den verbleibenden Dienst „TcpExample“ wollen wir entsprechend unseren Bedürf-
nissen anpassen. Wählen Sie hierzu die Aktion Modify und markieren Sie den
Dienst anschließend in der Liste. Danach gelangen Sie nach Betätigen der Next-
Schaltfläche zu weiteren Dialogen zum Bearbeiten der verschiedenen Dienstein-
stellungen.
Im ersten Seite dieser Dialogfolge müssen Sie das zu verwendende Netzwerkproto-
koll auswählen. Danach gelangen Sie wieder mit Hilfe der Next-Schaltfläche zur
nächsten Seite, deren Aussehen sich natürlich in Abhängigkeit des gewählten Netz-
werkprotokolls unterscheidet. Wenn Sie mit TCP/IP arbeiten, dann müssen Sie hier
(vgl. Abb. 1.24) den Namen bzw. die Adresse des Datenbankservers und den zu ver-
wendenden Port eintragen.
Die nächste Seite (Next-Schaltfläche drücken) Dient zur Festlegung der zugehörigen
Datenbankinstanz, d.h. Sie müssen hier die entsprechend SID-Bezeichnung einge-
ben (vgl. Abb. 1.25).
Mit Hilfe der nächsten und letzten Seite können Sie Ihren neuen Diensteintrag tes-
ten. Im Unterschied zum Test via TNSPING80 versucht das Programm Sie jetzt
allerdings mit Hilfe eines vorhandenen Benutzers an der Datenbank anzumelden,
d.h. Sie werden beim Test aufgefordert einen gültigen Benutzernamen nebst Pass-
wort einzugeben. Wenn Sie den Test für die ORCL-Instanz durchführen möchten,
dann können Sie sich als Benutzer „system“ (Passwort „manager“) anmelden.
Abbildung 1.24: Festlegen des Datenbankservers und der Port-Nummer
Abbildung 1.25: Verknüpfen des Dienstnamens mit der Datenbankinstanz
Wie Sie jetzt sicherlich schon gemerkt haben, ist die Änderung des eigentlichen
Dienstnamens mit Hilfe des Programms nicht möglich. Den Dienstnamen müssen
Sie entweder manuell in der Datei TNSNAMES.ORA ändern oder Sie müssen den
alten Dienst löschen und anschließend mit neuen Namen wieder anlegen. Die
Anlage eines neuen Dienstnamens entspricht übrigens weitestgehend der soeben
beim Ändern beschriebenen Vorgehensweise. Neu ist, dass Sie nach Auswahl der
Aktion Add New Service zunächst den neuen Dienstnamen mit Hilfe des entspre-
chenden Eingabefeldes festlegen müssen.
Besonderheiten der 8i-Version

In Bezug auf die Dienstnamen beinhaltet das Programm auch in der 8i-Version die
gleichen Funktionalitäten, sieht in einigen Details nur ein wenig anders aus. Aller-
dings besteht dennoch ein wesentlicher Unterschied zur Vorgängerversion, denn
jetzt können Sie mit diesem Assistenten (vgl. Abb. 1.26) auch den Listener und
wichtige Profileinstellungen konfigurieren, d.h. dieser Assistent ist nun geeignet,
kleinere Netze vollständig zu administrieren.
Abbildung 1.26: Startbild des Net8-Assistenten in der 8i-Version
Im Startbild des Assistenten können Sie auswählen, welchen Dienst des Net8-Pro-
tokolls Sie konfigurieren möchten. Die dritte Auswahl führt zur Konfiguration der
Dienstnamen und entspricht weitestgehend der Verfahrensweise der vorhing
gezeigten 8er-Version. Mit Hilfe der zweiten Auswahlmöglichkeit können Sie Profi-
leinstellungen vornehmen und die erste Auswahl ermöglicht die Konfiguration des
Listeners, wobei ich die Arbeitsweise des Assistenten an diesem Beispiel kurz
demonstrieren möchte.
Mit Hilfe der Weiter-Schaltfläche gelangen Sie auf die zweite Seite, in der Sie wählen
können, ob Sie einen neuen Dienst erstellen oder einen vorhandenen Dienst bear-
beiten, löschen oder umbenennen möchten. Sofern Sie die Musterdatei LISTENER.
ORA in das \NETWORK\ADMIN-Verzeichnis kopiert haben, können Sie sich hier
einmal für das Bearbeiten des Dienstes entscheiden, und sich anschließend die
Darstellung der verschiedenen Einstellungen einmal anschauen. In dieser Datei ist
lediglich ein Listener definiert, der genau wie dieser Prozess nämlich „LISTENER“
heißt, so dass Sie in der auf der dritten Seite angezeigten Auswahlbox auch nur die-
sen Namen wählen können.
Auf der nun folgenden Seite können Sie die gewünschten Netzwerkprotokolle aus-
wählen (vgl. Abb. 1.27) und in den darauffolgenden Seiten müssen Sie je nach aus-
gewähltem Protokoll weitere Einstellungen, beispielsweise die Port-Nummer bei
TCP, vornehmen.
Abbildung 1.27: Auswahl der Protokolle für die Listenerkonfiguration
1.4.4 Oracle-Networking mit Hilfe des Net8 Assistant

Bis einschließlich der Version 7 des Oracle-Servers gab es bisher auch bei NT-
Arbeitsplatzrechnern immer einen Grund, sich neben dem NT-Client auch den
alten 16-Bit Windows-Client zu installieren, da im Rahmen dieser Installation ein
Werkzeug, der Oracle Network Manager, zur komfortablen Konfiguration des
SQL*Nets installiert wurde. Mit Hilfe des Oracle Network Managers konnte man
nicht nur die Dienstnamen verwalten, sondern das Programm konnte weiterhin
alle benötigten Parameterdateien erzeugen.
Heute ist die Installation des Windows-Clients zumindest aus diesem Grund nicht
mehr notwendig, denn mittlerweile wird im Rahmen des NT-Clients das Programm
Oracle Net8 Assistant installiert, mit dem ebenfalls alle benötigten Konfigurations-
dateien erstellt werden können, wobei hierbei vor allem auch alle neuen Features
des Net8-Netzwerkes unterstützt werden. Standardmäßig finden Sie den Oracle
Net8 Assistant in der Programmgruppe „Oracle for Windows NT“.
Nach dem Start des Programms erhalten Sie links im Bild (vgl. Abb. 1.28) eine
Übersicht aller vorhandenen Konfigurationseinstellungen. Wenn Sie mit der Maus
auf einen dieser dargestellten Konfigurationsparameter klicken, dann erhalten Sie
im rechten Arbeitsfenster einen hierzu passenden Dialog. Die Abbildung 1.28 zeigt
den Dialog den Sie erhalten, wenn Sie in der Liste die Konfiguration „Profile“ mar-
kieren.
Dieses Programm ist bei den Versionen 8 bzw. 8i im Übrigen nahezu funktions-
kompatibel und sieht in der 8i-Varianten wie Sie der Abbildung 1.29 entnehmen
können nur anders aus. Aus diesem Grund ist die Behandlung dieses Werkzeugs
diesmal zusammengefasst, und nur die Abbildungen kommen zum Teil doppelt
vor.
Abbildung 1.28: Profilerstellung mit Hilfe des Oracle Net8 Assistant
Abbildung 1.29: Oracle Net8 Assistant in der 8i-Version

Wie Sie schon wissen, entspricht das Profile den Einstellungen aus der Datei
SQLNET.ORA. Als Symbol wird kein Ordner angezeigt, da es immer nur ein Profil
gibt. Die anderen Konfigurationen können mehrfach auftreten (z.B. mehrere Ser-
vice- bzw. Dienstnamen oder mehrere Listener), weshalb Sie hierfür entsprechende
Ordnereinträge finden. Zur grundsätzlichen Bedienung des Programms möchte ich
an dieser Stelle auch nicht viele weitere Worte verlieren. Ich denke, dass man das
Programm weitestgehend intuitiv bedienen kann.
Ein weiterer Unterschied zu dem im vorherigen Kapitel beschriebenen Net&Easy-
Programm ist auch, dass Sie mit Hilfe des Oracle Net8 Assistant Konfigurationsda-
teien in jedem erreichbaren Verzeichnis bearbeiten können. Standardmäßig öffnet
das Programm die im Verzeichnis \NETxx\ADMIN gespeicherten Konfiguratio-
nen, allerdings können Sie mit Hilfe der File- bzw. Datei-Menüeintrage das aktuelle
Verzeichnis wechseln oder geladene Konfigurationen in einem anderen Verzeich-
nis speichern bzw. von dort laden.
Im weiteren Verlauf dieses Kapitels soll nun zum wiederholten Male eine Verbin-
dung zu unserer Starterdatenbank hergestellt werden, wobei diesmal logischer-
weise der Oracle Net8 Assistant verwendet wird. Beginnen wir mit dem Profil, also
mit den Einstellungen in der Datei SQLNET.ORA. Obwohl wir hier nichts ändern
wollen bzw. müssen, können Sie sich die verschiedenen Profileinstellungen ja ein-
mal anschauen, indem Sie mit der Maus auf den entsprechenden Eintrag in der
Liste klicken (vgl. Abb. 1.29 oder Abb. 1.28).
Standardmäßig zeigt der Net8-Assistent für das Profil den Naming-Dialog bzw. die
Namensgebung an, der insgesamt drei Registerkärtchen enthält. Mit Hilfe des ober-
halb dargestellten Kombinationsfeldes können Sie weitere Konfigurationsdialoge
für das Profil einblenden.
Anpassen müssen Sie natürlich wieder die Dienstnamen. Klicken Sie hierzu
zunächst auf das zugehörige Ordnersymbol in der Liste, so dass anschließend alle
vordefinierten Servicenamen angezeigt werden (vgl. Abb. 1.30 und Abb.1.31).
Ähnlich der Vorgehensweise bei der Konfiguration mit Hilfe von Net&Easy können
Sie zunächst alle nicht benötigten Dienstnamen löschen. Markieren Sie hierzu Sie
den entsprechenden Dienst in der Liste und löschen Sie Ihn entweder mit Hilfe der
roten X-Schaltfläche oder Sie verwenden den entsprechenden Eintrag aus dem
Edit- bzw. Bearbeiten-Menü. Das Anlegen eines neuen Dienstes geht genauso
schnell. Mit Hilfe des Edit- bzw. Bearbeiten-Menüs oder durch Klicken auf der grü-
nen +-Schaltfläche können Sie einen neuen Dienstnamen erstellen. Anschließend
erhalten Sie die schon bekannten Seiten des Net&Easy Assistenten zum Erstellen
neuer Dienstseiten.
Für Anwender der 8er-Version ist eigentlich nur die Möglichkeit zur Konfiguration
der Listenersteuerung wirklich neu. Klicken Sie auf das Ordnersymbol des Listeners
und fügen Sie mit Hilfe der entsprechenden Schaltfläche oder des zugehörigen File-
bzw. Bearbeiten-Menüeintrags eine neue Listenerkonfiguration in die Liste ein.
Zunächst erhalten Sie einen Dialog, in dem Sie den Namen des Listeners eintragen
müssen. Standardmäßig heißt der erste und oftmals einzige Horchdienst schlicht
und einfach „LISTENER“ (vgl. Abb. 1.32).
Abbildung 1.30: Bearbeiten der Dienstnamen mit dem Net8-Assistenten
Abbildung 1.31: Bearbeiten der Dienstnamen mit dem Net8-Assistenten unter 8i

Abbildung 1.32: Eingabe des neuen Listenernamens
Wenn Sie den Dialog mit der OK-Schaltfläche beenden, dann erscheint der neue
Eintrag in der Liste und Sie haben die Möglichkeit, die verschiedenen Konfigurati-
onseinstellungen vorzunehmen.
Wählen Sie mit Hilfe des Kombinationsfeldes zunächst den Dialog „Listening Loca-
tions“ bzw. „Listener Adressen“ (vgl. Abb. 1.33 und Abb. 1.34) aus. Anschließend
erhalten Sie einen Dialog, mit dem Sie die abzuhörenden Protokolle nebst weiteren
protokollabhängigen Einstellungen vornehmen können. Die hier spezifizierten
Protokolle und Einstellungen finden Sie später in der Konfigurationsfdatei als
Adress-Parameter-Liste hinter dem Schlüsselwort LISTENER. Mit Hilfe der Schaltflä-
che Add Address können Sie weitere Protokolle hinzufügen, wobei Sie für jedes neue
Protokoll ein weiteres Registerkärtchen erhalten.
Bei unserer manuellen Konfiguration hatten wir den Listener an zwei Ports lau-
schen lassen. Für diesen zweiten Port müssen Sie ebenfalls ein zweites Registerkärt-
chen anlegen, indem Sie den zweiten Port 1526 eintragen.
Abbildung 1.33: Abhördienste des neuen Listeners konfigurieren

Abbildung 1.34: Konfiguration der Listener-Adressen beim 8i-Assistenten
Neben den Protokollen müssen Sie auch noch festlegen, für welche Datenbanken
der Listener das Netzwerk abhorchen soll. Wählen Sie hierzu in dem oberen Kom-
binationsfeld den Eintrag „Database Services“ bzw. „Datenbankdienste“, wodurch
Sie den zugehörigen Konfigurationsschirm erhalten (vgl. Abb. 1.35 bzw. Abb. 1.36).
Abbildung 1.35: Eintragen der Datenbanken, für die das Netz abgehorcht werden
Abbildung 1.36: Einstellung der Datenbankdienste beim 8i-Assistenten

Tragen Sie in dem Bild den System-Identifer (SID) der Datenbankintanz (z.B. orcl)
und den Datenbanknamen (z.B. oracle) ein. Erstellen Sie anschließend mit Hilfe
der Schaltfläche Add Database bzw. Datenbank hinzufügen eine zweite Registerkarte
für die noch zu erstellende Datenbank (SID = db01, Name = datab01).
Zum Schluss müssen Sie Ihre Konfiguration noch mit Hilfe des File- bzw. Datei-
Menüs speichern, wodurch die Konfigurationsdateien in dem gewählten Verzeich-
nis erstellt bzw. aktualisiert werden.
1.4.5 Ausblick
Mit Hilfe der letzten Kapitel haben Sie (hoffentlich) gesehen, dass es zumindest auf
den zweiten Blick gar nicht so schwierig ist, eine Datenbankverbindung mit Hilfe
von Net8 zu konfigurieren. Ich denke, dass wenn man die Zusammenhänge in
etwa kennt, dann ist es mit Hilfe der Assistenten gar nicht so schwierig, die Konfi-
guration auf die benötigten Belage zuzuschneiden.
In diesem letzten Kapitel zu dem Thema Oracle-Networking möchte ich nun noch
einige weitere Konfigurationsmöglichkeiten, die Ihnen die aktuelle Version von
Net8 bietet, kurz ansprechen und damit diesen Themenkomplex abrunden.
Verbindung via Host-Naming

Hierbei handelt es sich um ein neues Verfahren, das allerdings ausschließlich für
TCP/IP-Netzwerke verfügbar ist. Konkret bietet das Verfahren die Möglichkeit, die
Verbindung zur Datenbank über das installierte Verfahren zur Namensauflösung
herzustellen, indem als Servicename der Name des Datenbankrechners verwendet
wird. Hierbei ist es gleichgültig, ob die Namensauflösung im IP-Netzwerk mit Hilfe
irgendwelcher Namensserver oder mit Hilfe simpler Hostnamendateien durchge-
führt wird.
Wie schon gesagt, muss bei dieser Methode kein spezieller Dienstname definiert
werden, d.h. die Erstellung bzw. Anpassung der Datei TNSNAMES.ORA ist nicht
notwendig. Allerdings muss das Verfahren im verwendeten Profil aktiviert sein,
indem der Parameter names.directory_path den Wert HOSTNAME erhält:
names.directory_path = (TNSNAMES, HOSTNAME)
Weiterhin benötigten Sie in der Konfiguration des Listeners eine entsprechende

Einstellung, die den Datenbanknamen mit der zugehörigen Datenbankinstanz ver-
bindet, was allerdings, wie Sie schon wissen, quasi „Listener-Standard“ ist:
(SID_DESC = (GLOBAL_DBNAME = oracle) (SID_NAME = ORCL))
Was jetzt noch fehlt, ist ein Hostname des Datenbankservers, der dem Datenbank-
namen entspricht. Auch wenn Sie Ihren Server nicht „ORACLE“ taufen möchten,
so ist dieser benötigte Name zumindestens als sogenannter Aliasname schnell
erstellt, indem Sie einen entsprechenden Eintrag in Ihrem Netzwerknamensdienst
vornehmen. Sollten Sie keinen speziellen Namensdienst haben, dann suchen Sie
einfach mal nach der Datei HOSTS, denn diese Datei stellt einen Minimalnamens-
dienst zur Verfügung. Tragen Sie in der Datei die IP-Adresse des Datenbankservers
gefolgt von dem zugehörigen Datenbanknamen ein und schon können Sie sich
über den Hostnamen an die Datenbank anmelden.
Das Verfahren funktioniert übrigens auch, wenn auf einem Datenbankserver meh-
rere Instanzen bzw. Datenbanken aktiv sind. In dem Fall müssen Sie einfach für
alle Datenbanken entsprechende Aliasnamen vergeben.
Oracle Names
Hierbei handelt es sich im Prinzip um eine Erweiterung des eben beschriebenen
einfachen Verfahrens des Host-Naming. Konkret wird bei dieser Methode ein zen-
traler Dienst im Netzwerk bereitgestellt, der die Dienstnamen den entsprechenden
Rechneradressen, wodurch sich der Client mit der Datenbank verbinden kann. Ein
wichtige Funktionalität dieser Methode ist beispielsweise die Möglichkeit der dyna-
mischen Registrierung von Servern während des laufenden Betriebes.
Die bei dieser Methode notwendige Konfiguration können Sie mit Hilfe des Oracle
Net8 Assistant durchführen. Genaueres zu der Methode und deren Konfiguration
finden Sie in der Dokumentation im Buch „Net8 Administrator’s Guide“.
Oracle Connection Manager

Dieses Feature wurde ebenfalls neu mit der Version 8 bereitgestellt und bietet im
Wesentlichen folgende Funktionalitäten:
X Verbindungsbündelung
Der Connection Manager ermöglicht die logische Zusammenfassung der Verbin-
dungen mehrerer Client-Sitzungen, die mit demselben Server kommunizieren.
In dem Fall kommuniziert der Server nur noch mit diesem zentralen Knoten, der
die einzelnen Anforderungen sammelt bzw. die erhalten Ergebnisse verteilt.
Hierdurch können die benötigten Netzwerkressourcen reduziert bzw. die Perfor-
mance gesteigert werden.
X Zugriffskontrolle
Durch die Definition verschiedener Regeln besteht die Möglichkeit zu definie-
ren, unter welchen Bedingungen ein Client auf einen Server bzw. eine Daten-
bank zugreifen darf. Wie Sie im Verlauf dieses Kapitels sicherlich schon gemerkt
haben, reicht normalerweise die Kenntnis der IP-Adresse des Datenbankservers
aus, um in der Lage zu sein, zumindest eine Verbindung zum DBMS herzustel-
len. Zwar benötigt man immer noch eine Benutzer-ID und ein Passwort, aber die
Verbindung ist schon einmal hergestellt. Der Connection-Manager kann hier
eine Art Firewall-Funktion wahrnehmen, indem er verhindert, dass nicht expli-
zit zugelassene Clients eine Verbindung aufnehmen können.
1.5 Erstellen einer Datenbank

In diesem Kapitel möchte ich Ihnen zeigen, wie man in Oracle eigene Datenban-
ken erstellen kann. Allein an der Tatsache, dass es für dieses Vorgang ein eigenes
Kapitel gibt, können Sie vielleicht erahnen, dass dieser Prozess im Vergleich zu
anderen Datenbank-Managementsystemen ein wenig aufwendiger ist. Es gibt
Datenbanksysteme (z.B. SYBASE oder MS SQL-Server), da handelt es sich bei der
Anweisung zur Anlage einer Datenbank um einen Befehl wie jeden anderen auch,
d.h. man baut eine Verbindung zum DBMS auf und gibt anschließend einen Befehl
der Art create database mit irgendwelchen Parametern ein. Eine solche Vorgehens-
weise funktioniert in der Regel beim einem DBMS, das nicht nur für eine, sondern
für alle auf dem Rechner laufenden Datenbank zuständig ist.
Nun haben Sie in den einführenden Kapiteln aber schon gesehen, dass sich Oracle
gerade in dieser Architektur von dem einen oder anderen Konkurrenzprodukt
unterscheidet. Für jede Datenbank existiert auch ein eigenes DBMS, also steht vor
der Anlage der Datenbank die Erzeugung einer neuer DBMS-Instanz auf dem Auf-
gabenzettel.
Konkret gibt es für die Anlage einer DBMS-Instanz und der Erstellung der Daten-
bank wie immer mehrere verschiedene Verfahrensweisen; die Bandbreite der mög-
lichen Wege reicht je nach verwendetem Betriebssystem von „do it yourself“ bis
hin zur völlig automatischen Datenbankgenerierung. Dabei werde ich das vollau-
tomatische Verfahren, das beispielsweise unter Windows-NT möglich ist, nur kurz
beschreiben. Das manuelle Verfahren ist wesentlich interessanter. Zum einen ist es
leicht auf alle verfügbaren Betriebsplattformen übertragbar, bietet viele nützliche
Informationen über Oracle und entspricht zum anderen der zur Zeit gängigen Ver-
fahrenspraxis. Zumindest ist mir bisher noch kein Anwender begegnet, bei dem
Datenbanksysteme von irgendwelchen Programmen abstrakt und vollautomatisch
nach manueller Parametereingabe generiert wurden. Stattdessen wurden zunächst
alle zur Generierung benötigten Skripte und Parameterdateien erstellt, mit deren
Hilfe die eigentliche Datenbankerstellung in einem zweiten Schritt erfolgte. Diese
vielleicht altmodisch wirkende Vorgehensweise hat jedoch den Vorteil, dass die
Datenbankerstellung (z.B. auf einem anderen Rechner) jederzeit leicht wiederhol-
bar ist.
Im Übrigen ist das manuelle Verfahren in der aktuellen Oracle-Version gar nicht
mehr so ganz manuell, denn die benötigte Skripte können mit Hilfe eines Assisten-
ten erstellt werden. Für welches Verfahren Sie sich auch entscheiden: in jedem Fall
benötigen Sie bestimmte Informationen über die Struktur einer Oracle-Datenbank,
d.h. an dem folgenden Kapitel führt so oder so kein Weg vorbei.
1.5.1 Struktur einer Oracle-Datenbank

Wie Sie wissen, wird in Oracle eine Datenbank als logische Einheit einer DBMS-
Instanz und den eigentlichen Datenbankdateien gebildet. Diese Instanz vereint
alle für den Betrieb der Datenbank benötigten Prozesse nebst Hauptspeicherberei-
che und holt seine Konfiguration, z.B. die Größe der SGA oder den Namen der
Datenbank beim Starten aus einer speziellen Parameterdatei (vgl. Abb. 1.37) mit
Erstellen einer Datenbank 63
dem Namen INITSID.ORA, wobei Sie den Platzhalter SID durch den konkreten Sys-
tem-Identifer des DBMS ersetzen müssen. Wenn Sie die Starterdatenbank
(SID=orcl) installiert haben, dann finden Sie in Ihrem \DATABASE-Unterverzeich-
nis beispielsweise die zugehörige Konfigurationsdatei INITORCL.ORA.
Die Datenbank selbst besteht aus mindestens einer physikalischen Datei, in der die
zu speichernden Daten mit Hilfe von Tabellen oder andere Datenbankobjekte
abgelegt werden. Wie Sie schon wissen, liegt zwischen der physikalischen Datei
und der Tabelle das logische Tablespace-Konstrukt und somit folgt aus dem bisher
Gesagten, dass jede Datenbank zumindest auch einen Tablespace besitzen muss.
Dieser trägt den Namen SYSTEM und wird beim Anlegen der Datenbank automa-
tisch erzeugt.
Zusätzlich benötigt die Datenbank mindestens zwei Protokolldateien. Oftmals wer-
den Sie in dem Zusammenhang die Bezeichnungen „redo log“ oder „redo log
Dateien“ finden. Diese Log-Dateien werden benötigt, um die Datenbank beispiels-
weise nach einem Systemzusammenbruch (Server wird ausgeschaltet) wiederherzu-
stellen. Konkret werden in den redo log Dateien alle Änderungen mit Hilfe des
LGWR-Prozesses (vgl. Kapitel 1.1.2) protokolliert. Genauer betrachtet werden in
diesen Dateien alle fertiggestellten Änderungstransaktionen in der Form von Low
Level-Änderungsoperationen festgehalten. Erst wenn die Änderungen im redo log
protokolliert wurden, wird eine Transaktion als endgültig erledigt markiert und das
Zurückschreiben der geänderten Daten aus der SGA in die Datendatei erfolgt viel-
leicht sogar noch etwas später.
Wird die Datenbank nach einem versehentlichen Ausschalten oder einem
Stromausfall wieder hochgefahren, dann wird die Datenkonsistenz mit Hilfe dieser
Log-Dateien wieder hergestellt. Der Prozess des Hochfahrens kann somit schon
einmal eine Weile dauern, wenn das notwendige Recovery der Daten entsprechend
aufwendig ist.
Während des Datenbankbetriebs wachsen die einzelnen Log-Dateien allerdings
nicht ins Unendliche, sondern sie werden zyklisch genutzt und somit in regelmä-
ßigen Abständen immer wieder überschrieben. Damit schützen die Log-Dateien
zunächst auch nur vor einem Systemcrash, beispielsweise als Folge unbezahlter
Stromrechnungen. Bei anderen Fehlern, beispielsweise dem Datenbankausfall
wegen defekter Festplatten, müssen Sie zunächst auf die letzte Datensicherung
zurückgreifen. Hätte man nun noch alle Log-Einträge, die seit der letzten Vollsiche-
rung erstellt wurden, dann könnte man sich einen Wiederherstellungsprozess bis
zu jedem beliebigen nachfolgenden Zeitpunkt vorstellen, denn wie gesagt, die Log-
Dateien repräsentieren jede fertiggestellte Transaktion durch die zugehörigen
Änderungsdaten. Damit dies nicht nur ein Wunsch bleibt, besteht die Möglichkeit,
die einzelnen Log-Dateien vor dem Überschreiben zu kopieren. Hierzu müssen Sie
für Ihre Datenbankinstanz den ARCH-Prozess (engl. Archiver) aktivieren, der für die
Archivierung voller Log-Dateien zuständig ist.
So, eigentlich wollte ich nur anmerken, dass Sie bei einer Oracle-Datenbank min-
destens immer zwei Log-Dateien finden, aber Sie sehen ja selbst, wie schnell man
bei diesem komplexen aber auch interessanten Thema vom Wege abkommt. Wenn
Sie weitergehende Informationen zu diesem Themenkomplex suchen, empfehle
ich Ihnen neben den originalen Handbüchern ein Buch, das sich hauptsächlich
mit Themen aus dem Alltag eines Datenbankadministrators beschäftigt. Dort soll-
ten weiterführende Dinge wie Konzepte zur Sicherung und Wiederherstellung von
Datenbanken, Online-Sicherungen oder den 24 Stundenbetrieb einer Datenbank
hinreichend behandelt werden.
Zurück zu unserer Datenbankstruktur. Neben der Konfigurationsdatei für das
DBMS, der eigentlichen Datendatei und den beiden Log-Dateien besitzt jede
Oracle-Datenbank noch mindestens eine sogenannte Kontrolldatei (engl.. Control
File). Diese Kontrolldatei stellt die Achillesverse Ihres Datenbanksystems dar, denn
in ihr werden Informationen über die zur Datenbank gehörenden Dateien gespei-
chert. Ist diese Kontrolldatei zerstört bzw. weg, dann kann die Datenbank, wenn
überhaupt, nur noch mit viel Glück wiederhergestellt werden.
Das ist auch der Grund, warum Oracle grundsätzlich die Anlage von mehreren
(wenigstens zwei) Kontrolldateien empfiehlt, die möglichst auch auf unterschiedli-
chen Festplatten gespeichert werden sollen. Mehr zum Umgang mit diesen Kon-
trolldateien finden Sie in der Oracle-Dokumentation, beispielsweise im Buch „Ser-
ver Administrator’s Guide” im Kapitel „Managing Control Files”.
DBMS SID = DB01
TABLESPACE
SYSTEM
Konfguration
ROLLBACK (INITDB01.ORA)
SYSTEM
Datei (datafile) Log-Datei Kontrolldatei

(redo log) (controlfile)
Abbildung 1.37: Physische Struktur einer Oracle-Datenbank
Wie Sie in der Abbildung 1.37 erkennen können, wird in dem Datenfile neben dem
SYSTEM-Tablespace auch noch ein sogenanntes Rollback-Segment, ebenfalls mit
dem Namen SYSTEM, angelegt.
Rollback-Segmente
Jede Datenbank enthält mindestens ein sogenanntes Rollback-Segment. In einem
solchen Rollback-Segment werden die während einer Transaktion geänderten
Daten protokolliert. Diese Protokolle werden für das Zurücksetzen von Transak-
tion, dem Recovery beim Öffnen der Datenbank oder auch für die Bereitstellung
lesekonsistenter Abfragen benötigt. Oracle zeigt geänderte Daten erst nach dem
Beenden und Freigeben (commit) einer Transaktion. Während der Transaktion

erhalten andere Abfragen die Daten in dem Zustand vor der Änderung, d.h. die
Werte werden bei Bedarf mit Hilfe der Rollback-Segmente geliefert.
Ohne Rollback-Segment wäre eine Oracle-Datenbank eine reine Leseveranstaltung,
deshalb wird im Rahmen der Datenbankanlage automatisch ein Rollback-Segment
mit dem Namen SYSTEM im gleichnamigen Tablespace angelegt. Das Rollback-Seg-
ment muß seinerseits aus mindestens zwei Erweiterungen (Extends) bestehen, die
im Rahmen der Transaktionen sequentiell beschrieben bzw. im Rahmen neuer
Transaktionen immer wieder überschrieben werden.
Die Größe des Rollback-Segments muss hierbei so dimensioniert werden, dass die
Änderungsdaten der größten benötigten Transaktion dort hineinpassen, wobei es
prinzipiell möglich ist, die Änderungen einer Transaktion gezielt einem speziellen
(besonders großen) Rollback-Segment zuzuordnen. Standardmäßig werden die
freien Rollback-Segemente automatisch zugeordnet, so dass vor allem im Mehrbe-
nutzerbetrieb viele Transaktionen um die Gunst bzw. den Platz der Rollback-Seg-
mente ringen. Die Segmente selbst ringen ggf. konkurrierend mit anderen Objek-
ten um Platz im Tablespace. Aus diesen Gründen empfiehlt Oracle zum einen die
Anlage eigener Rollback-Segmente, möglichst ein einem Tablespace, der auf einer
eigenen Datei basiert.
Nachdem Sie nun die minimale physische Struktur einer Oracle-Datenbank ken-
nen, können wir im nächsten Abschnitt damit beginnen, endlich unsere eigene
Datenbank anzulegen. Hierbei werden sie die eben kennen gelernten Dateien
erstellen oder deren Namen nebst Zugriffspfad festlegen müssen.
1.5.2 Das manuelle Verfahren

In Oracle erfolgt die Anlage einer neuen Datenbank im Prinzip in folgenden Schrit-
ten:
X Erstellen der Konfigurationsdatei INITxxxx.ORA entsprechend dem gewünsch-
ten System Identifer.
X Erstellen der neuen Datenbankinstanz.
X Anlegen der neuen Datenbank.
X Abspielen verschiedener Standardskripte, die in der neuen (noch leeren) Daten-
bank verschiedene Systemobjekte anlegen.
Nach Durchführung dieser einzelnen Arbeitsschritte sind Sie im Besitz einer neuen
Datenbank. Anschließend sind in der Regel noch weitere Aktivitäten, z.B. die
Erweiterung des Net8-Netzwerkes oder die Anlage weiterer Tablespaces oder Daten-
bankdateien, notwendig, was aber genau genommen mit der eigentlichen Daten-
bankerzeugung gar nichts zu tun hat.
Im Folgenden wollen wir die Datenbankinstanz „db01“ und die zugehörige Daten-
bank „datenb01“ erstellen. Alle hierzu benötigten Dateien und Skripte finden Sie
auf der Begleit-CD im \DB01-Unterverzeichnis.
Erstellen der Konfigurationsdatei

Da es sich bei dieser Konfigurationsdatei um eine gewöhnliche Textdatei handelt,
kann sie folglich mit jedem beliebigen Texteditor erstellt werden. Selten werden Sie
dabei in der Praxis die Arbeit mit einer leeren Datei beginnen, sondern die neue
Konfiguration entsteht aus einer Kopie einer schon vorhandenen Datenbank.
Selbst wenn Sie gerade die erste Datenbank erstellen, dann finden Sie in Ihrem
\DATABASE-Unterverzeichnis die Datei INITORCL.ORA, so dass Sie die Konfigura-
tionsdatei der Starterdatenbank als Muster verwenden können.
Diese Musterdatei besteht hauptsächlich aus Kommentaren, denn neben den wirk-
lichen Anmerkungen in der Datei sind auch die meisten Parameter mit Hilfe des
Gatterzeichens (#) auskommentiert. Trotzdem erhalten Sie hierdurch eine Vorstel-
lung über die wichtigsten Konfigurationsparameter, deren genaue Bedeutung Sie in
der Oracle-Dokumentation finden. Folgen Sie im Buch „Server Reference“ bzw.
„Oracle8i Reference“ den Eintrag „1 Initialization Parameters” und dort weiter zum
Abschnitt „Parameter Description“. Hier finden Sie eine alphabetische Liste aller
vorhandenen Konfigurationsparameter zusammen mit der zugehörigen Beschrei-
bung. Im „Server Administrator’s Guide“ finden Sie im Abschnitt „Chapter 2 Crea-
ting an Oracle Database“ im Kapitel „Parameters“ ebenfalls eine Beschreibung der
wichtigsten Konfigurationsmöglichkeiten.
Falls Sie die Musterdatei INITORCL.ORA nicht besitzen, so finden Sie die Datei
übrigens auf der Begleit-CD im \ORCL-Unterverzeichnis. In unserem Beispiel hat
die Konfigurationsdatei den Namen INITDB01.ORA und lediglich folgenden
Inhalt:
db_name=datenb01
db_files = 100
control_files=(E:\ORANT\DATABASE\db01\ctl1db01.ora,E:\ORANT\DATABA-
SE\db01\ctl2db01.ora)
remote_login_passwordfile = shared
#rollback_segments = (RB0, RB1)
Listing 1.7: Minimum einer Instanz-Konfiguration
X db_name
Mit Hilfe dieses Parameters bestimmen Sie den maximal achtstelligen Namen
der Datenbank. Gültige Zeichen sind vor allem Buchstaben, Ziffern und der Un-
terstrich (_). Zwischen Groß- und Kleinschreibung wird nicht unterschieden.
Der hier spezifizierte Name muss auch beim späteren Anlegen der Datenbank
verwendet werden.
X db_files
Maximale Anzahl der möglichen Datenbankdateien. Sowohl der Standard- als
auch der Maximalwert für dieses Parameter ist abhängig vom vorhandenen Be-
triebssystem. Wir wählen den Wert von 100 (das sollte erst einmal reichen) und
müssen diesen Wert später beim Anlegen der Datenbank noch einmal vorgeben.
X control_files
Legen Sie hier den Pfad und Dateinamen der Kontrolldatei(en) fest. Wenn Sie,
wie empfohlen, wenigstens zwei oder mehr Kontrolldateien verwenden, dann
müssen Sie die einzelnen Dateinamen durch Komma trennen und das Ganze
wie in meinem Beispiel in Klammern setzen. Die genaue Spezifizierung der Da-
teinamen hängt natürlich vom jeweiligen Betriebssystem ab.
X remote_login_passwordfile = shared
Dieser Parameter legt fest, ob zur Überprüfung der Anmeldeberechtigung eines
Datenbankadministrators eine spezielle Passwortdatei angelegt werden soll. Die
Passwortdatei wird standardmäßig im \DATABASE-Unterverzeichnis mit dem
Namen PWDSID.ORA erstellt, wobei SID wieder ein Platzhalter der entsprechen-
den Instanz darstellt. Mehr zum Thema der Identifizierung von Administrato-
ren finden Sie in den Oracle-Unterlagen im Buch „Server Administrator's
Guide”, beispielsweise im Kapitel „The Oracle Database Administrator“.
X rollback_segments
Mit dem Parameter legen Sie die zu verwendenden Rollback-Segmente fest. Dies
ist wichtig, wenn Sie neben dem SYSTEM-Tablespace weitere Bereiche definie-
ren und verwenden möchten. Da diese Rollback-Segmente beim Anlegen der
Datenbank jedoch noch nicht definiert sind, ist es wichtig den Parameter zu-
nächst einmal auszukommentieren. Schalten Sie ihn erst ein, nachdem die ge-
samte Datenbank erstellt wurde. Damit er aktiv wird, müssen Sie die Instanz
runter, und anschließend wieder hochfahren.
Warum hat diese Konfiguration im Vergleich zur Starterdatenbank oder im Ver-
gleich zu real existierenden Versionen so wenige Parameter? Zum einen stellen Sie
beim Lesen der Dokumentation fest, dass für die allermeisten Parameter ein fester
oder betriebssystemabhängiger Standardwert existiert, der beim Starten der Daten-
bankinstanz verwendet wird, sofern in der Konfigurationsdatei nichts anderes spe-
zifiziert wurde. Zum anderen finden Sie in der Musterdatei INITORCL.ORA die
wirklich interessanten und wichtigsten Parameter, deren einzelne Bedeutung Sie in
einer ruhigen Stunde durchaus mal nachschlagen sollten, sofern Sie zukünftig häu-
figer Datenbanken erstellen müssen. Auf der anderen Seite möchte ich hier natür-
lich aufzeigen, worauf es wirklich ankommt und das erkennt man meistens am
besten, wenn mal alles Überflüssige bzw. Unnötige einfach mal weglässt.
Erstellen der neuen Datenbankinstanz

Nachdem wir nun unsere neue Konfigurationsdatei für das System DB01 besitzen,
können wir die zugehörige Instanz auf unserem Rechner starten. Wie das genau
geht, hängt allerdings stark vom jeweiligen Betriebssystem ab.
Für Windows NT erhalten Sie mit der Installation das Programm ORADIM80.EXE
(Instanzen-Manager), mit dem eine neue Datenbankinstanz erstellen bzw. starten
können. Das Programm können Sie zum Beispiel in einem MS-DOS-Fenster zusam-
men mit allen benötigten Parametern starten:
ORADIM80 -NEW -SID SID [-INTPWD INTERNAL_PWD] [-SRVC SRVCNAME]

[-STARTMODE AUTO, MANUAL][-PFILE FILENAME]
Unter 8i heißt das Programm einfach nur ORADIM.EXE, und wird ansons-
ten allerdings völlig identisch verwendet.
X SID
System Identifer der neuen Instanz. Entsprechend dem hinteren Teil der Konfi-
gurationsdatei müssen Sie in unserem Beispiel „db01“ als SID vorgeben.
X INTERNAL_PWD
Passwort für die Administrator-ID „internal“. Während der Anlage der neuen
Datenbankinstanz wird hierfür eine Passwortdatei angelegt. Diese Datei befin-
det sich im \DATABASE-Unterverzeichnis und hat den Namen PWDSID.ORA,
wobei SID wieder durch den konkreten System Identifer ersetzt wird.
X SRVCNAME
Wie Sie schon wissen, besteht unter Windows-NT die Möglichkeit, die Daten-
bankinstanz mit Hilfe eines entsprechenden Diensteintrags zu administrieren.
Mit Hilfe dieses Parameters können Sie den Namen dieses Dienstes vorgeben.
Standardmäßig heißt der neue Dienst „OracleServiceSID“, wobei SID wieder für
den System Identifer (z.B. DB01) der neuen Instanz steht.
X AUTO, MANUAL
Legt die Startart des neuen Dienstes fest. Auf einem echten Datenbankserver
wäre „AUTO“ wahrscheinlich die richtige Wahl. Auf meinem NT-Notebook ge-
fällt mir „MANUAL“ besser. Außerdem werden wir im weiteren Verlauf wieder
eine Batchdatei zum Starten der Datenbank erstellen. Beachten Sie aber, dass der
Instanzen-Manager den Service OracleStartSID zum Starten der Datenbank nur
dann einrichtet, wenn Sie den Wert „AUTO“ verwenden.
X FILENAME
Pfad und Name der Konfigurationsdatei INITSID.ORA. Standardmäßig erwartet
das Programm die Konfigurationsdatei im \DATABASE-Unterverzeichnis unter
der eben beschriebenen Namenskonvention, so dass Sie den Parameter in dem
Fall auch weglassen können.
In meinem Beispiel soll die Datenbank db01 angelegt werden. Die Konfigurations-
datei INITDB01.ORA befindet sich im Verzeichnis E:\ORANT\DATABASE\DB01,
so dass die neue Instanz folgendermaßen erstellt werden kann:
oradim80 -new -sid db01 -intpwd oracle -startmode auto

-pfile E:\ORANT\database\db01\initdb01.ora
Das Programm arbeitet stillschweigend, legt den neuen Dienst und die Passwortda-
tei an. Eventuelle Fehler oder Erfolgsmeldungen müssen Sie der zugehörigen Log-
Datei ORADIMxx.LOG entnehmen, die Sie standardmäßig im \RDBMSxx-Unter-
verzeichnis finden. Sofern beim Programmaufruf und in der Konfigurationsdatei
keine Tippfehler vorliegen, dann sollten Sie in der Log-Datei lediglich eine Erfolgs-
meldung über die Anlage der neuen Instanz vorfinden.
Nach dem Einrichten des neuen Dienstes muss dieser, sofern nicht automatisch
geschehen, auch gleich gestartet werden. Dies könnten Sie mit Hilfe der System-
steuerung durchführen, aber da wir gerade im MS-DOS-Fenster sind, erledigen wir
es durch einen erneuten Aufruf des Instanzen-Managers mit folgenden Parame-
tern:
oradim80 -startup -sid db01 -starttype srvc,inst -usrpwd oracle

-pfile E:\ORANT\database\db01\initdb01.ora
Wie gesagt, normalerweise ist das nicht notwendig, da der Dienst wegen des von
uns vergebenen Startmodus nach der Anlage auch sofort gestartet wird. Ansonsten
haben die diesmal verwendeten Parameter folgende Bedeutung: Mit Hilfe des Para-
meters starttype legen Sie fest, ob das Programm den Service (srvc), die Datenbank-
instanz (inst) oder beides starten soll.
Beim Betrachten dieses Programmaufrufs schleicht sich der Verdacht ein, dass man
Oracle-Datenbank auf einem NT-Rechner auch ohne Diensteinträge administrieren
kann. Dem ist in der Tat so und wir werden uns das im weiteren Verlauf auch noch
anschauen. Die Dienste sind unter NT nur ein Hilfsmittel, den Job des Rauf- und
Runterfahrens von Instanz und Datenbank zu vereinfachen.
Mehr Informationen über ORADIM80 finden Sie im Buch „Oracle8 Getting Started
for Windows NT“ im Kapitel „4 Database Tools“ und die 8i-Anwender können die
Informationen im Buch „Oracle8i Administrator's Guide for Windows NT“ nach-
schlagen.
Anlegen der neuen Datenbank

Die Anlage der neuen Datenbank erfolgt mit Hilfe spezieller Befehle, die über die
zugehörige Instanz abgesetzt werden. Zum Absetzen solcher (SQL-) Befehle erhal-
ten Sie im Rahmen der Installation verschiedene Werkzeuge, sogenannte SQL-Edi-
toren wie beispielsweise SQL*Plus oder das SQL-Worksheet. Da wir zur Zeit aber
lediglich ein Halbfertigprodukt besitzen, benötigen wir einen besonders systemna-
hen SQL-Editor, mit dem wir uns an die noch ohne Datenbank laufende Instanz
anmelden können.
Einen solches Werkzeug finden Sie unter Windows NT für Oracle 8 im Programm
SVRMGR30.EXE. Dieser sogenannte Server Manager ist in der Lage, sich auch ohne
Datenbank mit der Datenbankinstanz zu verbinden. Für andere Betriebssysteme
existieren ähnliche Programme, beispielsweise SQLDBA unter AIX.
Auch dieses Programm hat in der 8i-Version einen anderen Namen und
heißt diesmal nur SVRMGRL.EXE.
Diese Programme haben noch eine weitere gemeinsame Eigenschaft, denn Sie
ermöglichen die Verbindung mit dem DBMS ohne spezielle Konfiguration des
Oracle-Netzwerkes Net8, weshalb das jeweilige Programm auf dem Datenbankser-
ver gestartet werden muss. Die Vorgabe, mit welcher Datenbankinstanz sich der
Server-Manager beim Start verbinden soll, erfolgt mit Hilfe einer Umgebungsvari-
ablen bzw. bei NT mit Hilfe eines Eintrags in der Registrierungsdatenbank.
Im Verzeichnis \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE finden Sie den
Eintrag ORACLE_SID. Der zugehörige Wert beschreibt den System Identifer, an
dem sich der Server-Manager anzumelden versucht. Wenn Sie den Wert temporär
ändern möchten, müssen Sie jedoch nicht jedes Mal den Registrierungseintrag
ändern, sondern Sie können ihn mit Hilfe des SET-Kommandos überschreiben.
SET ORACLE_SID=db01
Im Übrigen entspricht auch dies der prinzipiellen Vorgehensweise für andere

Betriebssysteme. Alles, was Sie unter NT in der Registrierung finden oder per SET-
Kommando setzen können, müssen Sie unter UNIX entsprechend exportieren (z.B.
EXPORT ORACLE_SID=db01).
Starten Sie nun den Server-Manager auf Ihrem Datenbankserver, indem Sie
zunächst ein MS-DOS-Fenster öffnen, danach die Umgebungsvariable
ORACLE_SID entsprechend setzen und dann das Programm SVRMGR30.EXE bzw.
SRVMRGL.EXE aufrufen (vgl. Abb. 1.38).
Abbildung 1.38: Starten des Server-Managers zum Anlegen der DB01-Datenbank
Auch nach dem Start des Server-Managers erinnert das Programm immer noch an
ein MS-DOS-Fenster; lediglich der Eingabeprompt hat sich von C:\> auf SVRMGR>
geändert. Da wir später noch wesentlich komfortablere SQL-Eingabewerkzeuge
kennen lernen werden, möchte mit der Bedienung des Server-Managers nicht viel
Zeit verbringen. Am Eingabeprompt können Sie die benötigen Befehle eintippen.
Sofern Sie viel Platz brauchen und der konkrete Befehl dies zulässt, können Sie die
Zeile mit Hilfe der Eingabetaste wechseln. In dem Fall müssen Sie die gesamte
Befehlskette mit einem Semikolon (;) abschließen.
Es gibt aber auch Befehle, die sind sofort scharf, d.h. nach dem Drücken der Einga-
betaste erhalten Sie hier keine zweite Zeile, sondern der Server-Manager beginnt
sofort mit der Verarbeitung Ihrer Eingabe. Am besten verwenden Sie am Eingabe-
prompt des Server-Managers lediglich folgende zwei Befehle:
X Exit
Beendet den Server-Manager, d.h. Sie kehren zum MS-DOS-Eingabefenster zu-
rück.
X @
Schreiben Sie hinter dem Klammeraffen den Pfad und Namen eines Skripts, das
die einzelnen auszuführenden Befehle enthält. Dieses Skript können Sie mit je-
dem beliebigen Texteditor erstellen, so dass Sie die benötigten Befehle wenigs-
tens entsprechend komfortabel erfassen bzw. bearbeiten können.
Noch besser ist vielleicht sogar, Sie verwenden den Server-Manager über-
haupt nicht interaktiv, sondern starten ihn immer zusammen mit einem
Befehlsskript, dessen Namen Sie als Kommandozeilenparameter übergeben:
SVRMGR30 @%oracle_home%\database\db01\credb01_1.sql
Zum Anlegen unserer neuen Datenbank können Sie das folgende Skript verwen-
den, das Sie auch auf der Begleit-CD im \DB01-Verzeichnis unter dem Namen
CREDB01_1.SQL finden:
# Erstellung der Datenbank DB01

spool c:\temp\credb01_1.log
set echo on
connect INTERNAL/oracle
startup nomount pfile=E:\ORANT\database\db01\initdb01.ora
create database datenb01
CONTROLFILE REUSE
LOGFILE 'E:\ORANT\database\db01\logdb011.ora' SIZE 200K,
'E:\ORANT\database\db01\logdb012.ora' SIZE 200K
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXLOGHISTORY 1
DATAFILE 'E:\ORANT\database\db01\Sys1db01.ora' SIZE 50M
MAXDATAFILES 254
MAXINSTANCES 1
CHARACTER SET WE8ISO8859P1
NATIONAL CHARACTER SET WE8ISO8859P1;
spool off
Listing 1.8: Beispiel eines Skripts zum Anlegen einer Datenbank
Zunächst wird in dem Skript mit Hilfe des connect-Kommandos eine Verbindung
zur Datenbankinstanz hergestellt. Danach wird die Instanz durch Verwendung des
startup-Befehls gestartet bzw. initialisiert. Der Parameter nomount sorgt dafür, dass
die Datenbank hierbei nicht geöffnet wird und der pfile-Parameter verweist wieder
auf unsere INITDB01.ORA-Datei.
Wesentlichster Bestandteile der eben abgebildeten Befehlsfolge ist sicherlich die

Anweisung create database, mit dem unsere neue Datenbank datenb01 angelegt
wird. Entsprechend der Übersicht in Abbildung 1.37 legen wir hierbei das erste
Datenfile (SYS1DB01.ORA) und die beiden Logdateien (LOGDB011.ORA bzw.
LOGDB012.ORA) an. Ferner wird automatisch der Tablespace SYSTEM und das
gleichnamige Rollback-Segment angelegt.
Abspielen verschiedener Standardskripte

Nun haben wir endlich eine neue Datenbank, allerdings eine im Miniaturformat.
Damit meine ich nicht die anfängliche Größe des Datenfiles, sondern in der Daten-
bank fehlen eine Menge von Systemobjekten, die teilweise auch für die Arbeit mit
dem ein oder anderen Werkzeug notwendig sind. Außerdem sollte eine Datenbank
mindestens einen weiteren Tablespace für die Anlage und Speicherung von Benut-
zerdaten und weitere Rollback-Segmente (ebenfalls mit eigenem Tablespace)
haben.
Zumindest für die erste der beiden Aufgaben, dem Anlegen der benötigten System-
objekte, liefert Oracle zwei Standardskripte, die Sie im \RDBMSxx-Unterverzeich-
nis finden. Es handelt sich hierbei um die Dateien CATALOG.SQL und
CATPROC.SQL. In der ersten Datei werden mit Hilfe entsprechender SQL-Kom-
mandos eine Reihe von Views und anderen Objekten angelegt. Die zweite Datei ist
scheinbar kürzer, allerdings werden von hier weitere unzählige Skripts gestartet.
Natürlich könnten Sie nun mit Hilfe des Server-Managers diese beiden Skripte
abspielen und anschließend auch mit Hilfe entsprechender SQL-Befehle weitere
Datenfiles, Tablespaces und Rollback-Segmente anlegen. Wir halten aber einen
Moment inne, denn es gibt eine einfache Möglichkeit, ein fertiges Kochrezept für
die notwendige Nachbearbeitung zu erhalten.
1.5.3 Der Oracle Database Assistant

Wie Sie ja schon gemerkt haben, tauchen mit der Version 8 auch bei Oracle mehr
und mehr Assistenten für die Erledigung bestimmter Aufgaben auf. Das gilt im
Übrigen auch bei der Erstellung einer neuen Datenbank, denn auch hierfür bietet
Ihnen das System seine Unterstützung in Form eines Assistenten an. Üblicherweise
finden Sie für diesen Assistenten ein entsprechendes Symbol in Ihrer Programm-
gruppe „Oracle for Windows NT“. Nun muss ich allerdings einschränken, dass in
dem Fall das Wörtchen „üblicherweise“ voraussetzt, dass Sie den Assistenten bei
der Installation von Oracle ausgewählt haben; falls nicht, dann empfiehlt es sich,
das in jedem Fall nachzuholen.
Unter 8i gibt es den „Database Configuration Assistant“ natürlich auch,

wobei die beiden Programme mal wieder nahezu identisch sind bzw. sich
lediglich in Bezug auf die Oberfläche unterscheiden.
Mit Hilfe des „Oracle Database Assistant“ können Sie eigene Oracle-Datenbanken
erstellen. Hierbei haben Sie die Wahl, die Datenbank abstrakt im Hintergrund
erstellen zu lassen, oder Sie erstellen mit Hilfe des Assistenten lediglich die zur
Generierung benötigten Skripte. Wie Sie dem ersten Programmfenster (vbl. Abb.
1.39 bzw. Abb.1.40) übrigens entnehmen können, eignet sich der Assistent auch
zum Löschen vorhandener Datenbanken, wobei er dabei auch in der Windows-Sys-
temumgebung aufräumt und beispielsweise die zugehörigen Dienste löscht.
Abbildung 1.39: Der Oracle Database Assistant
Abbildung 1.40: Datenbank-Konfigurationsassistent unter 8i

Da wir noch immer dabei sind, unsere neue Datenbank zu vervollständigen, geht
es mit der ersten Option „Create a database“ bzw. „Erstellen einer Datenbank“ wei-
ter zur zweiten Seite des Assistenten. Dort haben Sie die Wahl zwischen einer Stan-
dardgenerierung und einer benutzerdefinierten Variante (Custom). Beachten Sie,
dass nur diese zweite Variante die Möglichkeit bietet, die benötigten Befehle in
einem Skript zu speichern, weshalb wir nach Auswahl der Option „Custom“ bzw.
„Benutzerdefiniert“ auf die dritte Assistentenseite wechseln. Mit Hilfe dieser drit-
ten Seite können Sie die Installation verschiedener Zusatzpakete veranlassen, aller-
dings wird die Auswahl nur angeboten, wenn Sie die zugehörigen Features im Rah-
men der Softwareinstallation ausgewählt haben. Beim 8i-Assistenten wählen wir
hier die Option „Mehrzweck“ und danach geht es in jedem Fall gleich weiter zur
vierten Seite (vgl. Abb. 1.41 bzw. Abb. 1.42), in der Sie endlich mal wieder etwas
eingeben müssen.
Abbildung 1.41: Festlegen verschiedener Datenbankparameter
Ich hatte noch nicht verraten, dass auch die benötigten Konfigurationsdatei
(INITSID.ORA) durch den Assistenten erstellt wird. Mit Hilfe der drei Optionen
Small, Medium bzw. Large legen Sie die Größe des Shared Pools (vgl. Kap. 1.1.2) mit
Hilfe des shared_pool_size-Eintrags und weiterer Parameter fest. Oracle empfiehlt
verschiedene Einstellungen in Abhängigkeit der gleichzeitig arbeitenden Benutzer.
Für bis zu 10 Anwender wird „klein“ (Small), zwischen 11 und 100 „mittel“
(Medium) und ab 101 Benutzer die Einstellung „groß“ (Large) empfohlen. In unse-
rer Konfigurationsdatei hatten wir hierfür überhaupt keine Parameter explizit vor-
gegeben, da ihre Standardwerte der Einstellung „klein“ entsprechen.
Entsprechend der Empfehlung, die Größe von den parallel arbeitenden Benutzern
abhängig zu machen, ist die vierte Seite des 8i-Assistenten (vgl. Abb. 1.42) geändert
worden und fragt ganz einfach diese Benutzerzahl ab.
Abbildung 1.42: Festlegen der Größe mit dem 8i-Assistenten
Beachten Sie allerdings, dass die hier getroffene Einstellung noch nicht direkt zu
Einträgen in der Konfigurationsdatei führt. Später auf einer der folgenden Seiten
des Assistenten haben Sie noch die Möglichkeit, die verschiedenen SGA-Parameter
explizit vorzugeben, wobei die dort voreingestellten Werte allerdings von der hier
gemachten Größenvorgabe abhängen.
Wichtig ist auch die Kontrolle des eingestellten Zeichensatzes, da sich dieser nach
Erstellung der Datenbank nicht mehr ändern lässt. Der gewählte Zeichensatz regelt
unter anderem die Darstellung von Tabellennamen und wird ebenfalls beim Spei-
chern von SQL-Programmen herangezogen. Von hier ab laufen die Bilder des 8er-
und 8i-Assistenten allerdings zunächst einmal auseinander. Die Auswahl des Zei-
chensatzes erfolgt erst ein paar Seiten später, wobei der 8i-Assistent bis dahin noch
weitere zusätzliche Parameter abfragt.
Mit Hilfe der Schaltfläche „Change Character Set“ bzw. später „Zeichensatz
ändern“ können Sie die Voreinstellung überprüfen bzw. ändern. Falls nötig, sollten
Sie den Wert auf „WE8ISO8859P1“ ändern. Das steht für „ISO 8859-1 West Euro-
pean“ und hört sich, so finde ich, ziemlich gut an. Übrigens, wenn Sie sich einmal
einer unbekannten Datenbank nähern, dann können Sie diese Einstellung über-
prüfen, indem Sie folgende Abfrage eingeben:
select * from v$nls_parameters
Die nächste Seite des Assistenten bzw. eine der folgenden bei der 8i-Version (vgl.
Abb. 1.43 bzw. Abb. 1.44) ermöglicht Ihnen die Eingabe des Datenbanknamens,
des System Identifers (SID) und weiterer Parameter, die Sie aufgrund des vorherigen
Kapitels alle schon kennen.
Abbildung 1.43: Datenbanknamen, SID und weitere Parameter vorgeben
Abbildung 1.44: Datenbanknamen, SID und Zeichensatz beim 8i-Assistenten vorgeben
Eigentlich wollen wir die Datenbank DB01 fertigstellen, allerdings erhalten Sie bei
entsprechender Eingabe ein kleines Problem in Form einer Fehlermeldung, nach-
dem Sie versuchen, auf die nächste Seite des Assistenten zu wechseln. Der Oracle
Database Assistent merkt nämlich, das die Datenbankinstanz DB01 schon von uns
erstellt wurde und fordert Sie daher auf, eine andere SID einzugeben. Da wir aber
eigentlich nur die zur Nachbearbeitung erforderlichen Skripte wollen, müssen wir
hier ein wenig schummeln und geben im Feld SID „db02“ oder irgendetwas ande-
res ein, um anschließend auf die nächste Seite wechseln zu können.
Auf dieser mittlerweile sechsten (bzw. achten) Seite haben Sie die Möglichkeit, die
Namen der Kontrolldateien sowie die Anzahl der zulässigen Datenfiles vorzugeben.
Das alles hatten wir in unserer manuell erstellten Konfigurationsdatei INITDB01.
ORA bzw. beim Absetzen des create database-Befehls schon festgelegt, so dass Sie
diesmal ohne irgendwelche Eingabe mit der siebten (neunten) Seite fortfahren
können.
Abbildung 1.45: Anlegen zusätzlicher Files, Tablespaces und Rollback-Segmente
Abbildung 1.46: Anlegen zusätzlicher Tablespaces beim 8i-Assistenten

Auf der siebten bzw. neunten Seite (vgl. Abb. 1.45 oder Abb. 1.46) des Assistenten
wird es endlich so richtig interessant. Mit Hilfe der fünf bzw. sechs verschiedenen
Registerkärtchen können Sie sowohl den Systembereich - das ist für uns allerdings
nicht mehr so wichtig - genauer definieren, als auch weitere Dateien, Tablespaces
und Rollback-Segmente anlegen. Die hier gezeigten Möglichkeiten entsprechen im
übrigen auch den von Oracle gemachten Empfehlungen, zumindest noch weitere
Dateien bzw. Tablespaces für Benutzerdaten, Rollback-Segmente, Indizes und einen
speziellen Bereich für temporäre Aktivitäten anzulegen.
Wie Sie beim Vergleich der beiden Abbildungen 1.45 und 1.46 feststellen
können, besitzt die 8i-Datenbank standardmäßig einen zusätzlichen Table-
space mit dem Namen TOOLS.
Tragen Sie für alle Registerkärtchen die gewünschten Dateinamen im Feld File und
die Namen der Tablespaces im Feld Name ein. Achten Sie hierbei darauf, dass alle
Verzeichnisse und Namen zu Ihrer neuen DB01-Instanz gehören, damit das später
erstellte Skript ohne Änderung verwendbar ist. Rechts neben dem Namensfeld
können Sie die anfängliche Größe des Tablespace angeben. Im unteren Bereich des
Bildes haben Sie die Möglichkeit, eine allgemeine Speicherbelegungsregel (vgl. Kap.
1.1.3) für den Tablespace vorzugeben. Wie Sie später noch sehen werden, können
Sie diese Regel bei Bedarf für jede einzelne Tabelle noch ändern.
Besonders interessant ist die Einstellung des Schalters Auto Extend. Ist er so wie in
unserem Beispiel eingeschaltet, dann wird der Tablespace bzw. die zugehörige Datei
bei Bedarf automatisch vergrößert. Wenn Sie diese Funktion ausschalten, dann
müssen Sie die Datei im Bedarfsfall selbst vergrößern oder dem Tablespace ein wei-
teres Datenfile zuweisen. Genaueres zu diesem Thema erfahren Sie allerdings erst
später, wenn wir im weiteren Verlauf noch einmal auf die Administration von
Dateien und Tablespaces zurückkommen werden. Hier und jetzt können Sie die
vom Assistenten vorgeschlagenen Werte zunächst einmal so übernehmen und in
der Parametrierung der benötigten Erstellungsskripte mit der nächsten Seite fort-
fahren.
Die achte (bzw. zehnte) Seite des Assistenten bringt für uns wieder mal nichts
Neues. Hier müssen Sie die Namen der benötigten Log-Dateien festlegen, die wir
allerdings schon bei der create database-Anweisung zugeordnet haben und die im
Rahmen der Ausführung dieses Befehls auch bereits angelegt wurden. Also können
Sie gleich mit der nächsten Seite des Assistenten fortfahren.
Mit Hilfe der neunten (elften) Assistentenseite (vgl. Abb. 1.47 bzw. Abb. 1.48) kön-
nen Sie verschiedene Einstellungen vornehmen, die zu entsprechenden Parame-
tern in der Konfigurationsdatei führen. Mit Hilfe des Kontrollkästchens Archive Log
veranlassen Sie beispielsweise die Archivierung der redo log-Einträge (vgl. Kap.
1.5.1). Das Einschalten dieser Option führt zum Setzen der Parameter log_archive_
dest, log_archive_format, log_archive_buffers und log_archive_buffer_size, mit denen
vor allem das Format und der Zielort der Archivdateien festgelegt werden. Soll die
Archivierung automatisch mit dem Initialisieren der Datenbankinstanz gestartet
werden, dann müssen Sie in der Konfigurationsdatei zusätzlich noch den Parame-
ter log_archive_start = true vorgeben.
Abbildung 1.47: Festlegen weiterer Parameter der Konfigurationsdatei
Abbildung 1.48: Einstellen der Logging-Parameter im 8i-Assistenten
Die anderen beiden Eingabefelder des Dialogs legen die Werte für die Parameter
log_checkpoint_interval bzw. log_checkpoint_timeout fest. Der erste der beiden Werte
regelt, wie häufig zusätzliche Checkpoints generiert werden, wobei der zweite Wert
den notwendigen Abstand zwischen zwei Checkpoints bestimmt. Übernehmen Sie
die beiden vorgeschlagenen Werte ohne Änderung in Ihre neue Konfigurations-
datei und wechseln Sie zur nächsten Seite des Datenbankassistenten.
Abbildung 1.49: Festlegen der SGA-Dimensionierung
Mittlerweile sind wir auf der zehnten (zwölften) Seite (vgl. Abb. 1.49 und Abb.
1.50) des Assistenten angelangt. Mit Hilfe der hier veränderbaren Werte können Sie
die SGA Ihrer Instanz konfigurieren. Die konkret vorgeschlagenen Werte hängen
von der zuvor auf Seite vier vorgegebenen Datenbankgröße ab.
Abbildung 1.50: Festlegen der SGA-Konfiguration beim 8i-Assistenten

Mit Hilfe des ersten Feldes („Shared Pool Size“ bzw. „gemeinsamer Pool“) bestim-
men Sie den Wert für den Parameter shared_pool_size und damit die Größe des
Shared Pools (vgl. Kap. 1.1.2) in Byte. Mehr ist nicht unbedingt immer besser.
Sicherlich gilt im Mehrbenutzerbetrieb, dass der Shared Pool möglichst groß
gewählt werden muss, allerdings sollten Sie darauf achten, dass der geforderte Spei-
cher auf dem Rechner auch permanent verfügbar ist. Der Schuss geht nämlich wie
man so schön sagt nach hinten los, wenn aufgrund der eingestellten Größe sich
bestimmte Teile des Pools häufig im Auslagerungsspeicher befinden bzw. das
Betriebssystem dauernd damit beschäftigt ist, SGA-Teile im Hauptspeicher ein-
bzw. auszulagern. Aus diesem Grund habe ich diesen Wert auf 35 MB geändert.
Das soeben Gesagte gilt natürlich nicht nur für den Shared Pool, sondern für die
gesamte SGA. Auch die anderen Puffer sollten so dimensioniert werden, dass die
gesamte SGA permanent im Hauptspeicher Platz findet.
Das nächste Feld „Block Buffers“ bzw. „Blockpuffer“ legt über den Parameter
db_block_buffers die Anzahl der Blöcke im Database Buffer Cache, das war derjenige
Speicher in dem die gerade benötigten Datenblöcke zwischengespeichert werden,
fest. Zusammen mit dem Parameter db_block_size, der die Größe eines solchen Blo-
ckes festlegt und der mit Hilfe des letzten Eingabefeldes verändert werden kann,
ergibt sich somit die gesamte Größe des Buffer Caches. In unserem Beispiel können
wir mit der Vorgeschlagenen Anzahl von 200 Datenblöcken gut leben. Die Größe
eines solchen Blockes belasse ich auf 2048 Byte, was im Übrigen auch dem Stan-
dardwert dieses Parameters entspricht.
Das dritte Eingabefeld dimensioniert die Größe des Log-Buffers und führt in der
Konfigurationsdatei zum gleichnamigen Parameter (log_buffer). Je größer der zuge-
hörige Wert, um so seltener muss der LGWR-Prozess den Puffer in die aktuelle redo
log-Datei kopieren. In unserem Beispiel belassen wir den Wert unverändert auf
8192 Byte.
Mit Hilfe des Datenfeldes Processes können Sie die maximale Anzahl von Benutzer-
prozessen bestimmen, die sich gleichzeitig an der Oracle-Datenbank anmelden
können. Der Eintrag führt in der Konfiguration zum Parameter processes, dessen
Standardwert 30 beträgt. Der Wert würde für unsere Spiel- und Trainingsdatenbank
sicherlich ausreichen, jedoch ist gegen den vorgeschlagenen Wert von 50 auch
nichts einzuwenden.
Nachdem Sie nun die wesentlichen SGA-Einstellungen der Oracle-Instanz festge-
legt haben, können Sie mit dem Assistenten auf die nächste und vorletzte Seite
wechseln. Dort finden Sie zwei Eingabefelder, in denen Sie Verzeichnisse für die
Erstellung von Tracedateien festlegen können. In der Konfigurationsdatei finden
Sie die hier vorgegebenen Einstellungen in den Parametern user_dump_dest bzw.
background_dump_dest wieder.
Abbildung 1.51: Endlich am Ziel, im nächsten Schritt werden die Skripte erstellt
Mit der nächsten Seite des Assistenten (vgl. Abb. 1.51 bzw. Abb. 1.52) sind wir end-
lich am Ziel bzw. stehen kurz davor. Mit Hilfe der entsprechend Option erhalten Sie
nach Auswahl der Finish- bzw. Fertig-Schaltfläche die Möglichkeit, ein Verzeichnis
und den Namen einer Batchdatei festzulegen. Die Batchdatei (z.B. SQL.BAT) ent-
hält alle Befehle, die zum Anlegen der Instanz und Datenbank notwendig sind.
Einige der dort enthaltenen Schritte hatten wir im Verlauf des vorhergehenden
Kapitels schon ausgeführt. Zusätzlich erhalten Sie zwei SQL-Skripte, deren Namen
der vergebenen Datenbank-SID entsprechen (z.B. DB02.SQL und DB021.SQL).
Abbildung 1.52: Beim 8i-Assistenten sind Sie ebenfalls am Ziel angelangt

Das erste Skript enthält den create database-Befehl, den wir ebenfalls schon ausge-
führt hatten. Das zweite und die eventuell folgenden Skripte vereinen alle notwen-
digen Schritte, um die bisherige Rudimentärdatenbank fertigzustellen. Auf Ihrer
Begleit-CD finden Sie die vom Assistenten erstellte Konfigurationsdatei im \DB01-
Unterverzeichnis unter dem Namen INITDB01A.ORA. Sie können die DB01-
Instanz zukünftig auch mit dieser generierten Konfigurationsdatei hochfahren ,
d.h. in dem Fall müssen Sie Ihre aktuelle Konfigurationsdatei ersetzen. Das zweite
SQL-Skript finden Sie im gleichen Verzeichnis, heißt CREDB01_2.SQL und hat fol-
genden Inhalt:
spool c:\temp\credb01_2.log
set echo on
connect INTERNAL/oracle
1.
ALTER DATABASE DATAFILE 'E:\ORANT\database\db01\Sys1db01.ora' AUTOEXTEND ON;
2.
CREATE ROLLBACK SEGMENT SYSROL TABLESPACE "SYSTEM" STORAGE (INITIAL 100K NEXT 100K);
ALTER ROLLBACK SEGMENT "SYSROL" ONLINE;
@E:\ORANT\Rdbms80\admin\catalog.sql;
@E:\ORANT\Rdbms80\admin\catproc.sql
3.
REM **************TABLESPACE FOR ROLLBACK*****************
CREATE TABLESPACE RBS DATAFILE 'E:\ORANT\database\db01\Rbs1db01.ora' SIZE 10M
DEFAULT STORAGE ( INITIAL 1024K NEXT 1024K MINEXTENTS 2 MAXEXTENTS 121 PCTINCREASE 0);
ALTER DATABASE DATAFILE 'E:\ORANT\database\db01\Rbs1db01.ora' AUTOEXTEND ON;
4.
REM ***********Alter system tablespace ********************
ALTER TABLESPACE SYSTEM
5.
REM **************TABLESPACE FOR USER*********************
CREATE TABLESPACE USR DATAFILE 'E:\ORANT\database\db01\Usr1db01.ora' SIZE 3M
ALTER DATABASE DATAFILE 'E:\ORANT\database\db01\Usr1db01.ora' AUTOEXTEND ON;
REM **************TABLESPACE FOR TEMPORARY*****************

CREATE TABLESPACE TEMPORARY DATAFILE 'E:\ORANT\database\db01\Tmp1db01.ora' SIZE 10M
DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 0)
TEMPORARY;
ALTER DATABASE DATAFILE 'E:\ORANT\database\db01\Tmp1db01.ora' AUTOEXTEND ON;
REM **************TABLESPACE FOR INDEX*********************

CREATE TABLESPACE INDX DATAFILE 'E:\ORANT\database\db01\Indx1db01.ora' SIZE 10M

ALTER DATABASE DATAFILE 'E:\ORANT\database\db01\Indx1db01.ora' AUTOEXTEND ON;
6.
REM **** Creating two rollback segments ****************
CREATE ROLLBACK SEGMENT RB0 TABLESPACE "RBS"
STORAGE ( INITIAL 50K NEXT 50K MINEXTENTS 2 MAXEXTENTS 121 );
CREATE ROLLBACK SEGMENT RB1 TABLESPACE "RBS"
STORAGE ( INITIAL 50K NEXT 50K MINEXTENTS 2 MAXEXTENTS 121 );
ALTER ROLLBACK SEGMENT "RB0" ONLINE;
ALTER ROLLBACK SEGMENT "RB1" ONLINE;
7.
alter user sys temporary tablespace TEMPORARY;
alter user system default tablespace USR;
alter rollback segment "SYSROL" offline;
spool off
Listing 1.9: Typisches „Nachlauf“ Skript zum Fertigstellen einer Datenbank
Bei der Erstellung einer Datenbank für die 8i-Version enthält das Skript
natürlich auch die Erstellung des zusätzlichen Tablespaces TOOLS. Auf der
CD finden Sie daher auch noch die Datei CREDB01_2I.SQL als Muster für ein
solches Skript bei der 8i-Version.
Das Skript können Sie wieder mit Hilfe des Server-Managers starten, in dem Sie in
einem MS-DOS-Fenster Folgendes eingeben:
Set oracle_sid=db01
svrmgr30 @e:\orant\database\db01\credb01_2.sql
Den Pfad und Namen des Skriptes müssen Sie natürlich Ihren individuellen Gege-
benheiten anpassen. Die Ausführung des Skripts kann je nach Rechner durchaus 30
bis 60 Minuten dauern; das liegt vor allem an der Datei CATPROC.SQL, aus der
endlos viele weitere SQL-Befehlsdateien gestartet werden. Während der Ausfüh-
rung können Sie die verschiedenen Aktionen am Bildschirm mitverfolgen, zumin-
dest wenn Sie schnell genug lesen können; gut, dass alle Aktivitäten in dem mit der
spool-Anweisung vorgegebenen Datei protokolliert werden.
In den folgenden Abschnitten finden Sie eine kurze Beschreibung der verschiede-
nen Passagen des SQL-Skripts. Die im Listing abgedruckten Nummern sind in der
Originaldatei natürlich nicht enthalten. Außerdem finden Sie weitergehende Infor-
mationen zu den einzelnen Befehlen entweder am Ende des Kapitels „5. Daten-
bankprogrammierung“ oder in der „SQL-Reference“ der Oracle-Dokumentation.
Nun zu den einzelnen Passagen des abgedruckten Skripts:
1. Für das Datenfile des Systembereichs wird die autoextend-Eigenschaft einge-
schaltet, damit es anschließend beliebig wachsen kann.
2. Im SYSTEM-Tablespace wird ein weiteres Rollback-Segment angelegt. Dieses

Rollback-Segment ist von der Größe her so dimensioniert, dass alle nachfolgen-
den Statements ausgeführt werden können. Anschließend wird das Rollback-
Segment aktiviert und danach werden nacheinander die beiden Skripte CATA-
LOG.SQL und CATPROC.SQL aufgerufen.
3. In dem Schritt wird der Tablespace RBS im Datenfile RBS1DB01.ORA angelegt.
Hierbei werden die im Assistenten spezifizierten Regeln zur Speicherbelegung
(storage-Klausel) verwendet. Anschließend wird der Autoextend-Modus für die
Datei eingeschaltet.
4. Das Verfahren zur Speicherbelegung wird für den SYSTEM-Tablespace ange-
passt.
5. Ähnlich wie im Punkt 3 werden die Tablespaces USR, TEMPORY und INDX mit-
samt den Dateien USRLDB01.ORA, TMP1DB01.ORA und INDX1DB01.ORA ent-
sprechend den im Assistenten gemachten Vorgaben angelegt.
6. Es werden zwei neue Rollback-Segmente RB0 und RB1 im RBS-Tablespace ange-
legt und anschließend aktiviert. Beachten Sie nochmals, dass Sie die Verwen-
dung der beiden Rollback-Segmente in der Konfigurationsdatei der Instanz
noch einschalten müssen:
rollback_segments = (RB0, RB1)
7. Für die angelegten Benutzer sys und system wird die jeweilige Standard-Table-
space-Zuordnungen geändert. Anschließend wird das am Anfang angelegte Roll-
back-Segment SYSROL deaktiviert.
Endlich fertig; Sie sind im Besitz einer eigenen voll funktionsfähigen Datenbank.
Neben der Benutzer-Id INTERNAL mit dem während der Installation vorgegebenen
Passwort legt Oracle während der Datenbankanlage weitere Benutzer-Id’s an. Wir
werden später im Workshop bei der Behandlung von Benutzer- und Rollenprofilen
sehen, welche ID’s alle schon in der Datenbank vorhanden sind. Vorab schon mal
eine kleine Übersicht der vorhandenen Benutzer mit Administratorrechten:
Benutzer-ID Passwort
INTERNAL
SYS CHANGE_ON_INSTALL
SYSTEM MANAGER
Tabelle 1.3: Übersicht der standardmäßig vorhandenen DBA-Accounts
Die insgesamt generierten oder aufgerufenen Skripte hängen konkret von

der verwendeten Datenbankversion und von den installierten Zusatzoptio-
nen ab. Von daher ist es natürlich nicht besonders empfehlenswert, bei der
Anlage einer Datenbank die auf der CD befindlichen Muster zu verwenden,
sondern sich mit Hilfe der Assistenten einen individuellen Ablauf zu gene-
rieren und unter NT vielleicht auch automatisch abzuspielen.
1.5.4 Automatische Generierung unter NT

Wie Sie im bisherigen Verlauf des Buches vielleicht schon gemerkt haben, führen
in Oracle meistens nicht nur mehrere, sondern immer gleich viele Wege zum Ziel.
Dabei geht es gar nicht unbedingt immer nur um die Abwägung zwischen einem
manuellen oder abstraktem vollautomatischen Verfahren, sondern viele vorhan-
dene Werkzeuge haben einen sich überschneidenden Aktionsbereich, so dass es
manchmal reine Geschmacksache ist, ob man eine Aufgabe mit diesem oder jenem
Hilfsmittel bewerkstelligt.
Ein Beispiel für diese Aufgabenüberlappung stellt auch die Möglichkeit dar, eine
neue Datenbankinstanz nebst Datenbank mit Hilfe des schon bekannten Pro-
gramms ORADIM80.EXE zu generieren, was allerdings in der hier beschriebenen
Form unter 8i nicht mehr bzw. in anderer Form mit Hilfe des neuen Assistenten
funktioniert. Dieses Programm, das es in der entsprechenden Vorgängerversion
auch schon unter Version 7 gab, habe ich vor allem früher immer ganz gerne
genutzt, um einfach und schnell einen neue Datenbank zu erzeugen. Starten Sie
hierzu einfach das Programm ORADIM80.EXE ohne weitere Parameter. Als Ergeb-
nis erhalten Sie ein kleines Programmfenster, in dem alle auf dem Rechner vorhan-
denen Datenbankinstanzen angezeigt werden. Wählen Sie hier die Schaltfläche
New, um die Erstellung einer neuen Datenbankinstanz einzuleiten.
Abbildung 1.53: Anlegen einer neuen Datenbankinstanz
Auf der ersten Seite (vgl. Abb. 1.53) zur neuen Datenbankinstanz müssen Sie als
Erstes den System-Identifer (SID) der neuen Datenbank (z.B. db01) angeben.
Anschließend trägt das Programm den Namen der zugehörigen Initialisierungdatei
(INTIDB01.ORA) automatisch rechts unten in das zugehörige Eingabefeld ein.
Legen Sie als Nächstes das Passwort für den Benutzer INTERNAL fest, das Sie im fol-
genden Feld noch einmal bestätigen müssen. Danach wechseln Sie mit Hilfe der
Schaltfläche Advanced auf die zweite Seite, um weitere Einstellungen für die Gene-
rierung vorzunehmen.
Administrierung der Datenbanken 87
Abbildung 1.54: Anlegen weiterer Generierungsparameter für die neue Datenbank
Auf der zweiten Seite (vgl. Abb. 1.54) müssen Sie den Datenbanknamen vorgeben,
der dem Namen aus der Initialisierungsdatei entsprechen muss. Anschließend
müssen Sie mindestens noch die Namen und Verzeichnisse der Logdateien und des
Systembereichs festlegen. Danach können Sie den Dialog mit Hilfe der OK-Schalt-
fläche beenden, wodurch Sie zum vorhergehenden Dialog zurückkehren. Beenden
Sie auch diesen jetzt mittels OK, wonach das Programm mit der Erstellung der
Datenbankinstanz und anschließend mit der Generierung der Datenbank beginnt.
Nach ein paar Minuten, die genaue Zeit hängt natürlich mal wieder vom Rechner
ab, erscheint ein Hinweis, der es Ihnen ermöglicht, ein spezielles Skript abzuspie-
len. Dieses Skript wurde während der Generierung erstellt und enthält im Wesent-
lichen wieder den Aufruf der schon bekannten Dateien CATALOG.SQL und
CATPROC.SQL. Das war schon alles; auch jetzt sind Sie wieder im Besitz einer
neuen Datenbank. Alles was Sie zusätzlich benötigen (Benutzer, Tablespaces usw.),
können bzw. müssen Sie in weiteren Arbeitsschritten anlegen.
1.6 Administrierung der Datenbanken

Wie Sie im Kapitel „1.3 Dienste unter Windows-NT“ schon lesen konnten, werden
die Komponenten einer Oracledatenbank unter Windows am einfachsten mit Hilfe
sogenannter Dienste administriert. So einfach dieses Verfahren auch ist, es lässt auf
den ersten Blick keinen direkten Vergleich zur Vorgehensweise auf andere Systeme
(z.B. UNIX) zu.
Dabei gibt es, zumindest was die prinzipielle Vorgehensweise angeht, eigentlich
kaum Unterschiede. Auf einem Server läuft die Oracle-Datenbankinstanz üblicher-
weise als Hintergrundprozess und damit schlagen wir auch schon die Brücke zu
den Windows-Diensten, denn diese Dienste sind nur ein Hilfsmittel, um solche
Hintergrundprozesse zu verwalten.
Eigentlich geht es nur darum, auf Ihrem Rechner das Programm ORACLE80.EXE
(unter vielen anderen Systemen wie auch 8i einfach nur ORACLE) zu aktivieren.
Öffnen Sie doch einmal ein MS-DOS-Fenster (vgl. Abb. 1.55) und geben Sie am
Prompt folgenden Befehl ein:
Abbildung 1.55: Starten des Oracle-Servers im Vordergrund
Hierdurch starten Sie das Programm ORACLE80.EXE, dem Sie die zugehörige SID
als Kommandozeilenparameter übergeben und – boom – nach wenigen Sekunden
erhalten Sie die abgebildete Nachricht und auf Ihrem Rechner läuft die DB01-
Datenbankinstanz. Einen Nachteil hat das Ganze natürlich: sobald Sie das MS-
DOS-Fenster schließen oder dort irgendeine Taste drücken, ist die Datenbank-
instanz wieder weg, da das zugehörige ORACLE80-Programm beendet wird.
1.6.1 Instanz starten und stoppen

Um nun das ORACLE-Programm im Hintergrund zu starten, können Sie unter NT
das schon bekannte Programm ORADIM80.EXE folgendermaßen verwenden:
oradim80 -startup -sid db01 -starttype srvc

oradim -startup -sid db01 -starttype srvc
Die verschiedenen Schalter und Parameter haben dabei folgende Bedeutung:

X -startup
Der Schalter gibt an, dass ORADIM eine Datenbankinstanz auf Ihrem Rechner
(im Hintergrund) starten soll.
X -sid
Verwenden Sie den Schalter zusammen mit dem System Identifer derjenigen In-
stanz, die Sie auf dem Rechner starten wollen.
X -starttype srvc
Mit Hilfe dieses Schalters müssen Sie festlegen, wie die Datenbankinstanz gestar-
tet werden soll. Wie Sie noch sehen werden, stehen Ihnen hierbei verschiedene
Varianten zu Verfügung. Der Wert srvc führt zum Starten der Datenbankinstanz.
Nach Eingabe des eben beschriebenen Befehls sollte die Prozess-Liste Ihres Win-
dows Task-Managers einen weiteren Eintrag mit dem Namen ORACLE80.EXE (bzw.
ORACEL80.EXE) aufweisen. In jedem Fall finden Sie Hinweise oder Fehler zum
Start der Instanz in der Datei ORADIMxx.LOG, die Sie im \RDBMSxx-Unterver-
zeichnis Ihrer Oracle-Installation finden. Übrigens eignet sich ORADIM auch zum
Beenden einer laufenden Instanz. In dem Fall müssen Sie das Programm folgender-
maßen aufrufen:
oradim80 -shutdown -sid db01 -shuttype srvc -shutmode N

oradim -shutdown -sid db01 -shuttype srvc -shutmode N
X -shutdown
legt fest, dass Sie eine Datenbankinstanz beenden möchten.
X -sid
identifiziert die zu schließende Instanz, d.h. geben Sie hier den zugehörigen
System Identifer ein.
X -shuttype
Verwenden Sie srvc, um die Datenbankinstanz zu beenden.
X -shutmode
Mit diesem Schlüssel können Sie die Modus für das Herunterfahren vorgeben.
Das übliche Verfahren ist das sogenannte „normale“ Beenden der Instanz, wes-
halb Sie den Schalter zusammen mit dem Buchstaben „N“ verwenden.
Beim Beenden der Datenbankinstanz wird eine eventuell geöffnete Datenbank
ebenfalls geschlossen. Wird die Instanz normal beendet (-shutmode N), dann wird
mit dem Heruntergefahren gewartet, bis aktuell laufende Prozesse (z.B. eine
Datenänderung) beendet sind. Die anderen Beendigungsmethoden z.B. „I“ (für
IMMEDIATE, engl. immediately) erzwingen ein sofortiges Beendigen der Instanz,
was in der Regel zu entsprechenden Recovery-Aktivitäten beim nächsten Hochfah-
ren der Datenbank zur Folge hat.
Eine vollständige Übersicht aller vorhandenen Parameter und Schalter des Pro-
gramms ORADIM80.EXE erhalten Sie, wenn Sie das Programm zusammen mit dem
Schalter „-?“ oder „/H“ aufrufen. Weitere Verwendungsformen finden Sie auch im
nächsten Kapitel, denn mit dem Programm können Sie auch die zur Instanz gehö-
rende Datenbank öffnen oder schließen.
1.6.2 Datenbank öffnen und schließen

Nach dem Hochfahren der Datenbankinstanz ist ein Arbeiten mit der zugehörigen
Datenbank noch nicht möglich. Hierzu muss sie nämlich zunächst einmal noch
geöffnet werden. Unter NT haben Sie auch hierfür einen entsprechenden Dienst-
eintrag, doch wie funktioniert das Verfahren ohne Dienste bzw. unter anderen
Betriebssytemen?
Beginnen wir auch diesmal zunächst mit einem leicht übertragbaren Verfahren,
das ich in ähnlicher Form schon in so manchen Start- bzw. Bootskripts gefunden
habe. Konkret geht es darum, die Datenbank mit Hilfe des Server-Managers zu star-
ten, indem Sie mit seiner Hilfe beispielsweise folgendes Skript abspielen:
connect internal/oracle
startup pfile=e:\orant\database\db01\initdb01.ora
Nach dem Anmelden and die noch untätige Datenbankinstanz, wird die Daten-
bank mit Hilfe des startup-Befehls und der Vorgabe der zugehörigen Konfigura-
tionsdatei geöffnet. Ähnlich einfach lässt sich auch das Herunterfahren bzw.
Schließen der Datenbank bewerkstelligen:
connect internal/oracle
shutdown normal
Der Zusatz „normal“ ist übrigens die standardmäßige Variante des shutdown-
Befehls, d.h. Sie können diesen Teil der Anweisung auch weglassen. Falls Sie wis-
sen, dass gleich der Strom ausfällt, dann sollten Sie besser den Befehl shutdown
immediate verwenden, damit alle aktiven Benutzer sofort abgehängt, alle laufenden
Transaktionen zurückgerollt und die Datenbank unverzüglich geschlossen wird.
Diese shutdown-Variante wird im Übrigen auch angewendet, wenn Sie mit
ORADIM80 die Instanz in der Form „–shutmode I“ herunterfahren.
Öffnen und Schließen mit ORADIM

Wie ich schon angedeutet hatte, besteht auch die Möglichkeit, eine Datenbank mit
Hilfe des Programms ORADIMxx.EXE zu öffnen oder zu schließen. Sie erleben also
gerade mal wieder ein Beispiel für die Vielfalt der möglichen Wege, um zum Ziel zu
kommen. Das Öffnen der Datenbank erfolgt bei schon laufender Instanz beispiels-
weise folgendermaßen:
oradim80 -startup -sid db01 -starttype inst -usrpwd oracle -pfile

e:\orant\database\db01\initdb01.ora
Bei Verwendung der Version 8i müssen Sie jetzt anstelle von oradim80
natürlich nur wieder oradim eingeben, da das Programm entsprechend
umbenannt wurde.
Neu bei dem Aufruf ist zunächst einmal der verwendete Starttyp „inst“, der das Pro-
gramm zum Öffnen der zugehörigen Datenbank veranlasst. Die Starttypen inst und
svrc können im Übrigen auch gemeinsam verwendet werden („svrc, inst“), um das
Laden der Instanz mit dem Öffnen der Datenbank zu verbinden. Dabei muss das
Programm natürlich dieselben Aktivitäten durchführen, die Sie vorhin zusammen
mit dem Server-Manager manuell durchgeführt haben. Aus dem Grund benötigen
Sie zwei weitere Parameter „-usrpwd“ und „-pfile“, um mit deren Hilfe das Kenn-
wort für den Internal-Benutzer und den Pfad und Namen der Konfigurationsdatei
vorzugeben.
Ebenfalls möglich ist auch das Schließen der Datenbank via ORADIM, indem Sie
das Programm beispielsweise folgendermaßen aufrufen:
oradim80 -shutdown -sid db01 -usrpwd oracle -shuttype inst, -shutmode N
1.6.3 Löschen einer Datenbank

Aufgrund der Oracle-Architektur sind für das Löschen einer Datenbank keine spe-
ziellen Befehle (z.B. drop database) notwenig, da die zu löschende Datenbank ja
nicht in irgendeiner Systemdatenbank des DBMS eingetragen ist, sondern zusam-
men mit seinem DBMS eine logische Einheit bildet. Außerdem kann man ja auch
kaputtmachen, was man gleich sowieso löschen möchte. Aus dem Grund wäre fol-
gende Holzhammermethode zum Entfernen einer Oracle-Datenbank denkbar:
X Beenden Sie den zugehörigen ORACLE-Hintergrundprozess, beispielsweise
durch ein entsprechendes KILL-Kommando (z.B. UNIX) oder indem Sie das Pro-
gramm unter Windows mit Hilfe des Task-Managers aus der Prozessliste schmei-
ßen.
X Entfernen Sie den Aufruf der Datenbank aus allen Startup- bzw. Boot-Skripten.
Löschen Sie unter NT in der Registrierung alle eventuell vorhandenen Dienst-
einträge.
X Löschen Sie alle zugehörigen Dateien (Daten-, Log-, Kontroll- und Konfigura-
tionsdateien).
Der Nachteil dieses Verfahrens ist natürlich, dass man hierbei genau wissen muss,
was man im Einzelnen abschießen bzw. löschen darf. Schnell hat man mal dane-
ben gegriffen und beispielsweise den falschen Prozess abgewürgt oder in der Regist-
rierung leider den darüber liegenden Dienst markiert und entfernt. Aus diesem
Grund gibt es auch für das Entfernen einer Datenbank die eine oder andere Hilfe-
stellung.
Zunächst einmal sollten Sie sich einen Überblick über die vorhandene Dateistruk-
tur der Datenbank machen. Identifizieren Sie zunächst die verwendete Konfigura-
tionsdatei, denn in ihr finden Sie einen Verweis auf die zur Datenbank gehörenden
Kontrolldateien:
control_files = (E:\ORANT\DATABASE\db01\ctl1db01.ora,E:\ORANT\DATABA-
SE\db01\ctl2db01.ora)
Führen Sie mit Hilfe eines SQL-Editors, beispeilsweise dem Server-Manager, fol-
gende Abfragen aus, um eine Übersicht der zugehörigen Datendateien (vgl. Listing
1.10) und Log-Dateien (vgl. Listing 1.11) zu erhalten.
SVRMGR> select name from v$datafile;

NAME
-------------------------------------------
E:\ORANT\DATABASE\DB01\SYS1DB01.ORA
E:\ORANT\DATABASE\DB01\RBS1DB01.ORA
E:\ORANT\DATABASE\DB01\USR1DB01.ORA
E:\ORANT\DATABASE\DB01\TMP1DB01.ORA
E:\ORANT\DATABASE\DB01\INDX1DB01.ORA
5 rows selected.
SVRMGR>
Listing 1.10: Abfrage der Datenfiles mit Hilfe der View v$datafile
SVRMGR> connect internal/oracle

Connected.
SVRMGR> select member from v$logfile;
MEMBER
------------------------------------------------
E:\ORANT\DATABASE\DB01\LOGDB011.ORA
E:\ORANT\DATABASE\DB01\LOGDB012.ORA
2 rows selected.
SVRMGR>
Listing 1.11: Ermittlung der Log-Dateien durch Abfrage der View v$logfile
Nachdem Sie nun alle Dateien kennen, können Sie die Datenbank zusammen mit
der Instanz herunterfahren; hierzu haben Sie in den beiden vorhergehenden Kapi-
teln genügend Beispiele kennen gelernt. Als Nächstes müssen Sie dafür sorgen, dass
die Instanz nebst Datenbank beim nächsten Durchstarten des Rechners nicht wie-
der hochgefahren wird, indem Sie eventuell vorhandene Bootskripts kontrollieren.
Unter NT müssen Sie im nächsten Schritt die zugehörigen Diensteinträge aus der
Registrierungsdatenbank entfernen. Hierzu können Sie übrigens auch das Pro-
gramm ORADIMxx.EXE verwenden:
oradim80 -delete -sid db01

oradim80 -delete -srvc OracleStartDB01
Der erste Aufruf des Programms entfernt den zur Instanz gehörenden Diensteintrag
(OracleServiceDB01) und der zweite Aufruf entfernt den Dienst, mit dem Sie die
Datenbank automatisch öffnen konnten. Nun ist nur noch Datenmüll übrig, d.h.
Sie können im letzten Schritt alle zugehörigen Dateien löschen.
1.7 Der Oracle Storage Manager

Während der Erstellung der DB01-Datenbank (vgl. Kap. 1.5.3) haben Sie gesehen,
wie man mit Hilfe spezieller SQL-Befehle Tablespaces, Datenfiles oder Rollback-Seg-
mente anlegt. Dieses Verfahren, eventuell notwendige Strukturänderungen mit
Hilfe geeigneter Skripts durchzuführen, entspricht übrigens oftmals der gängigen
Praxis für produktive Datenbanksysteme. Die einzelnen Skripte werden hierbei
archiviert, so dass man bei Bedarf, z.B. nach einem Rechnercrash oder für den Auf-
Der Oracle Storage Manager 93
bau eines Backup-Systems, eine exakt gleich konfigurierte Datenbank nahezu auto-
matisch generieren kann, indem nach dem Erstellskript einfach auch alle Ände-
rungsskripts nacheinander eingespielt werden.
Wie Sie im letzten Kapitel erfahren haben, ist aber nicht nur die Erstellung der Spei-
cherobjekte via SQL möglich, sondern auch die Abfrage der vorhandenen Objekte
mitsamt ihren Eigenschaften ist mit Hilfe spezieller Views möglich. Sofern Sie aller-
dings unter Windows arbeiten, dann gibt es aber mittlerweile für nahezu jegliche
Aufgabenstellung auch ein entsprechendes Tool mit grafischer Oberfläche.
Oracle8 Storage-Manager
Zwecks Analyse oder Bearbeitung der Datenbankstruktur finden Sie hierzu in der
klassischen 8er-Version den Oracle Storage Manager (VAG.EXE, vlg. Abb. 1.56), der
im Rahmen des Oracle Enterprise Managers auf Ihrem Rechner installiert wird.
Abbildung 1.56: Der Oracle Storage Manager
Im weiteren Verlauf des Workshops werden Sie noch weitere ähnliche Werkzeuge
kennenlernen, d.h. die verschiedenen Tools haben einen ähnlichen Aufbau, funk-
tionieren sehr ähnlich, unterscheiden sich aber durch ein jeweils spezielles Einsatz-
gebiet. Im linken Teil des Fensters finden Sie immer eine Übersicht der vorhandenen
Objekte. Wenn Sie eines dieser Objekte markieren, dann erhalten Sie im rechten Teil
ein Fenster mit einem oder mehreren Registerkärtchen, in denen Sie die vorhande-
nen Eigenschaften des markierten Objekts betrachten oder ändern können.
Im letzteren Fall können Sie die neuen Einstellungen mit Hilfe der Apply-Schaltflä-
che speichern bzw. aktivieren oder Sie verwenden die Schaltfläche Show SQL, um
ein Fenster mit den zugehörigen SQL-Befehlen zu erhalten. Ein Programm mit Trai-
nerqualitäten also.
Ansonsten denke ich, dass uns die Bedienung des Programms als mittlerweile
Explorer und Windows gewöhnten Anwender, keine größeren Schwierigkeiten
bescheren sollte. In der links dargestellten Übersichtsliste können Sie übrigens
auch mit der rechten Maustaste agieren. Das ist hilfreich, wenn Sie neue Objekte
anlegen oder vorhandene kopieren bzw. löschen wollen.
Damit bin ich mit meinen Ausführungen zu diesem Werkzeug auch schon fast am
Ende. Bemerkenswert ist lediglich noch eine besondere Funktionalität, die dieses
und alle weiteren Manager-Werkzeuge besitzen. Mit Hilfe des Eintrags Record aus
dem Log-Menü haben Sie die Möglichkeit, alle Ihre Aktivitäten aufzuzeichen, d.h.
hierbei werden die zugehörigen SQL-Kommandos protokolliert. Damit ist die Brü-
cke geschlossen, zum einen die notwendigen Arbeiten mit Hilfe eines grafischen
Tools komfortabel erledigen zu können und zum anderen alle Änderungen in Form
eines SQL-Befehlsskripts aufzuheben bzw. zu archivieren.
Wählen Sie den Eintrag Stop aus dem Log-Menü, um die Aufzeichnungsaktiviäten
zu beenden, wobei Sie jetzt die Möglichkeit erhalten, das Protokoll unter einem
beliebigen Namen zu speichern. Probieren Sie das Ganze doch einfach mal aus.
Wie Sie sich vielleicht erinnern, haben wir beim Anlagen der DB01-Datenbank im
Rahmen der Nachbearbeitung das Rollback-Segment SYSROL angelegt. Dabei
wurde dieses Segment am Ende der Verarbeitung inaktiviert, so dass es jetzt eigent-
lich gelöscht werden könnte.
Führen Sie diese Aktion mit Hilfe des Storage Managers durch. Da wir aber wissen
wollen, welche SQL-Anweisung sich dahinter verbirgt, schalten wir vorher die Pro-
tokoll-Funktion ein. Danach markieren Sie das Rollback-Segment SYSROL, drücken
anschließend die Taste (Entf), oder wählen im Kontext-Menü (rechte Maustaste)
den Eintrag Remove oder Sie verwenden den gleichen Eintrag im Rollback-Menü.
Bestätigen Sie jetzt alle erscheinenden Sicherheitsabfragen, so dass das Segment aus
der Datenbank entfernt wird. Anschließend beenden Sie die Protokollierung mit
Hilfe des Log-Menüs und Speichern das Protokoll unter irgendeinem Namen ab.
Öffnen Sie jetzt das Protokoll mit einem beliebigen Texteditor, um den zugehöri-
gen SQL-Befehl abzulesen:
DROP ROLLBACK SEGMENT "SYSROL"
Storage-Manager für Oracle8i

Mit der Version 8i wurden verschiedene Administrationsprogramme zum Oracle
DBA Studio zusammengefasst, wobei Sie auch die Funktionen des Storage-Mana-
gers im DBA Studio (vgl. Abb. 1.57) wiederfinden. Mann kann sich das im Prinzip
so vorstellen, dass der jeweils links im Bild angezeigte Baum um weitere Blätter
erweitert wurde, die für die jeweils unterschiedlichen Administratorwerkzeuge ste-
hen. Konkret verbergen sich die Storage-Funktionalitäten unter dem Eintrag „Spei-
cher“ und was Sie von dort aus aufklappen können, ist völlig identisch mit der in
Abbildung 1.56 gezeigten Struktur.
SQL*Plus 95
Abbildung 1.57: Storage Manager im neuen Gewand des DBA Studios
Ich denke, dass man auch hier eigentlich kein Wort über die prinzipielle Bedin-
gung des Programms verlieren muss, wobei ich einmal anmerken möchte, dass mir
persönlich die neuen 8i-Oberflächen sogar besser gefallen. Sie finden im DBA Stu-
dio in Bezug auf das Speichermanagement alle Funktionen wieder, die Ihnen bisher
vom Storage Manager geboten wurden. So richtig neu ist eigentlich nur die Art-
und Weise, Ihre Arbeit gegebenenfalls in einem Protokoll zu speichern.
Im Unterschied zum Storage Manager verfügt das DBA Studio über ein permanentes
Protokoll aller ausgeführten SQL-Anweisungen, d.h. Sie finden hier auch eine Auf-
zeichnungen aller Abfragen, die das Programm zur Anzeige der einzelnen Objekte
und deren Eigenschaften absenden muss. Sie erhalten dieses Protokoll, indem Sie im
Ansicht-Menü den Eintrag „SQL-Historie der Anwendung“ auswählen. Hierdurch
erhalten Sie ein Fenster, indem alle vom Programm abgesetzten SQL-Anweisungen
angezeigt werden. Ich finde das ist wirklich eine tolle Sache und ermöglicht Ihnen
den einfachen Zugriff auf viele technische Informationen Ihrer Oracle-Datenbank.
1.8 SQL*Plus
Wie Sie schon gesehen haben, benötigt man zum Arbeiten mit einer Datenbank,
neben den eigentlichen Anwendungsprogrammen (z.B. PeopleSoft oder SAP), oft-
mals ein Werkzeug, mit dem man SQL-Befehle abschicken und die entsprechenden
Ergebnisse empfangen kann. Am Beispiel des Server-Managers haben Sie bereits ein
solches Werkzeug, einen SQL-Editor, kennengelernt. Allerdings macht es meistens
wenig Spaß, die Erstellung von Abfragen oder die Entwicklung von SQL-Program-
men im Serverraum durchzuführen. Zwar hindert die Pelzmütze nicht unbedingt
bei der Arbeit, aber mit dem Fäustlingen aus dem letzten Skiurlaub kann man halt
doch nur schlecht tippen.
Wir benötigen also ein ähnliches Werkzeug, das nicht auf die Ausführung auf dem
Datenbankserver beschränkt ist, sondern das wir an unseren normalen Arbeitsplatz
benutzen können. Wer die Wahl hat, hat die Qual, denn Oracle bietet hierfür mal
wieder gleich mehrere verschiedene Möglichkeiten.
Beginnen wir zunächst mit dem Klassiker, den Sie im Rahmen der gewöhnlichen
Installation des Oracle-Clients erhalten. Wie Sie der Überschrift entnehmen kön-
nen, meine ich hiermit das Programm SQL*Plus, das je nach Betriebssystem und
Installation als PLUS80.EXE, PLUS80W.EXE, SQLPLUSW.EXE oder lediglich SQL-
PLUS vorliegt.
Über Geschmack kann man bekanntlich streiten und in Bezug auf dieses Tool gibt
es, zumindest nach meiner Erkenntnis, wirklich genau zwei Lager: entweder man
liebt oder hasst es (ich gehöre eher zur zweiten Gruppe). Aber lassen wir den
Geschmack mal außen vor. Für das etwas angestaubt wirkende Tool gibt es in
jedem Fall eine Daseinsberechtigung, denn im Unterschied zum später beschriebe-
nen SQL-Worksheet, finden Sie SQL*Plus in jeder Betriebsumgebung. Benötigen Sie
beispielsweise auf einem AIX-Server einen SQL-Editor zum Abspielen eines Skripts,
so ist das dank SQL*Plus überhaupt kein Problem. Tippen Sie innerhalb einer Tel-
net-Session das Kommando sqlplus ein, um den SQL-Editor zu starten (vgl. Abb.
1.58).
Abbildung 1.58: UNIX-Variante des SQL*Plus-Programms
Unter Windows heißt das Programm der aktuellen 8er-Version PLUS80W.EXE (vgl.
Abb. 1.59) und befindet sich üblicherweise im /BIN-Unterverzeichnis der Client-
Installation. Das zugehörige Programm-Icon finden Sie in der Programmgruppe
„Oracle for Windows NT“. Auch bei der Installation des 8i-Clients erhalten Sie
SQL*Plus 97
natürlich wieder ein SQL*Plus, wobei das Programm diesmal SQLPLUSW.EXE

heißt, sich diesmal aber überhaupt nicht von den bisherigen Windows-Varianten
unterscheidet.
Abbildung 1.59: SQL*Plus unter Windows
Sie müssen zugeben, dass sich die beiden „SQL*Plusse“ ziemlich ähnlich sehen. In
echt funktionieren Sie auch gleich, d.h. wer sich irgendwo mit SQL*Plus auskennt,
kommt unter jeder Betriebsumgebung mit diesem Produkt zurecht; das ist sicher-
lich ein nicht zu vernachlässigender Vorteil. Falls Sie es auch unter Windows noch
proprietärer mögen, dann können Sie SQL*Plus auch in einem MS-DOS-Fenster
starten, in dem Sie dort das Programm PLUS80.EXE bzw. SQLPLUS.EXE beim 8i-
Client starten.
Sie sehen also, warum so viele Installationsbeschreibungen immer noch auf
SQL*Plus abstellen. Dieses Tool gibt es zum einen überall und funktioniert zum
anderen immer gleich. Ansonsten gilt nicht nur bei Ikea: „Entdecke die Möglich-
keiten“. Das Thema SQL*Plus ist so umfangreich, dass es hierzu in der Oracle-
Dokumentation sogar ein eigenes Buch „SQL*Plus User’s Guide and Reference“
gibt. Dort finden Sie in dem Kapitel „Command Reference” eine vollständige Über-
sicht der vorhandenen Befehle mit vielen Beispielen. Ich möchte im Rahmen die-
ses Buches nur einen Überblick über die vorhandenen Möglichkeiten geben und
habe hierzu die nachfolgenden Häppchen ausgewählt.
1.8.1 Abfragen eingeben und ausführen

Ähnlich wie der Server-Manager arbeitet auch SQL*Plus zeilenorientiert, d.h. es
erwartet Ihre Eingaben am Prompt (SQL>) und mit Hilfe der Eingabezeile erhalten
Sie eine neue Zeile. Ihre Eingabe bzw. Zeilen werden innerhalb von SQL*Plus in
einem internen Puffer zwischengespeichert und erst nach Abschluss Ihrer Einga-
ben an die Datenbank geschickt. Um die Eingabe abzuschließen haben Sie ver-
schiedene Möglichkeiten:
X Sie beenden die Zeile mit einem Semikolon (;) und drücken danach die Einga-
betaste. Hierdurch werden die im SQL-Puffer gespeicherten Befehle sofort an die
Datenbank gesendet.
X Sie betätigen die Eingabetaste zweimal hintereinander. SQL*Plus beendet näm-
lich das Füllen des Puffers, wenn Sie in einer Leerzeile die Eingabetaste verwen-
den. Allerdings wird in dem Fall der Pufferinhalt nicht an den Server geschickt.
Dies müssen Sie anschließend noch durch Eingabe des Befehls run bzw. exec,
wenn sich im Puffer ein PL/SQL-Programmblock befindet, veranlassen.
Der SQL-Puffer
Erinnern Sie sich noch an Edlin oder arbeiten Sie regelmäßig mit UNIX-Systemen
und kennen sich mit Befehlen wie ed oder vi bestens aus? Falls ja, dann willkom-
men Zuhause. Auch unter SQL*Plus stehen Ihnen ähnliche zeilenorientierte
Befehle zur Verfügung, um den im SQL-Puffer gespeicherten Text nachträglich zu
bearbeiten. So können Sie beispielsweise durch die Eingabe des Buchstabens „l“,
den kompletten Inhalt des Puffers anlisten. Durch Eingabe eines „i“ können Sie so
lange weitere Zeilen am Puffer anfügen, bis Sie wieder zweimal Eingabe drücken
und damit die Editierung beenden. Die wichtigsten Befehl zum Bearbeiten des
SQL-Puffers können Sie der Tabelle 1.3 entnehmen:
Befehl Beschreibung
a <Text> fügt den spezifizierten Text am Ende der aktuellen Zeile an, vgl. auch Hin-
weise zu l <n>.
c /<alt>/<neu> ändert in der aktuellen Zeile den Text <alt> in den Text <neu>, z.B. c /
fromm/from, um „fromm“ in „from“ zu ändern.
c /<alt> löscht den Text <alt> aus der aktuellen Zeile.
cl buff löscht den SQL-Puffer.
del löscht die aktuelle Zeile, vgl. zu l <n>.
del <n> löscht die Zeile <n> aus dem SQL-Puffer.
del <n> * löscht den Puffer von der Zeile <n> bis zur aktuellen Zeile.
del <n> <m> löscht die Zeilen <n> bis <m> aus dem Puffer.
edit ruft den per define_editor definierten Texteditor auf (vgl. nächsten Ab-
schnitt).
exec startet den im Puffer befindlichen PL/SQL-Block.
i fügt weitere Zeilen hinter der aktuellen Zeile des SQL-Puffers ein.
i <text> fügt eine Zeile hinter der aktuellen Zeile eine neue mit dem Inhalt <text> ein.
l führt zur Anzeige des SQL-Puffers
l <n> zeigt die Zeile <n> des SQL-Puffers an und macht diese zur aktuellen Zeile.
l <n> * zeigt den Puffer von der Zeile <n> bis zu aktuellen Zeile.
l <n> <m> listet die Zeilen <n> bis <m> aus dem Puffer.
run startet die im Puffer befindliche SQL-Anweisung.
Tabelle 1.4: SQL*Plus-Befehle zum Bearbeiten des SQL-Puffers

SQL*Plus 99
Verwenden eines Texteditors

Dieses zeilenorientierte Editieren ist ehrlich gesagt nicht so nach meinem
Geschmack. Da ist es schon gut, dass SQL*Plus den Inhalt des SQL-Puffers mit Hilfe
einer temporären Datei, die standardmäßig den Namen AFIEDT.BUF besitzt, zwi-
schenspeichern und zur weiteren Bearbeitung an andere Programme, vor allem
Editoren, übergeben kann. Welchen Editor Sie hierbei verwenden möchten, kön-
nen Sie durch Ändern der Einstellung define_editor selbst festlegen:
define_editor=C:\Programme\pfe\PFE32.EXE
Wenn Sie anschließend am SQL-Prompt den Befehl edit eingeben, dann setzt
SQL*Plus das Kommando „C:\Programme\pfe\PFE32.EXE AFIEDT.BUF“ in Form
eines Kindprozesses ab, so dass in dem Beispiel der PFE-Editor zusammen mit der
Pufferdatei wie ein modales Kindfenster von SQL*Plus erscheint. Nun, was will
Ihnen der Autor hiermit sagen? So lange Sie das Fenster des Editors geöffnet lassen,
wird die SQL*Plus-Anwendung gesperrt, d.h. Sie können in SQL*Plus erst weiterar-
beiten, nachdem Sie den Texteditor wieder geschlossen haben.
Laden und Speichern von Dateien

Unter Windows finden Sie im File-Menü die Einträge Open, Save und Save as, um
eine als Datei gespeicherte Abfrage in den Puffer zu laden bzw. die dort zwischen-
gespeicherten Anweisungen in einer Datei abzulegen.
Je nach Betriebssystem besitzt die zugehörige SQL*Plus-Version ein solches Menü
aber gar nicht. Dennoch ist das Laden oder Speichern von Dateien in bzw. aus dem
SQL-Puffer möglich, indem Sie am SQL-Prompt die Anweisungen get bzw. save ver-
wenden:
get file_name [lis[t]|nol[ist]]
X file_name
Geben Sie hier den Pfad und Namen der zu ladenden Datei ein.
X lis[t]|nol[ist]
Mit dieser Zusatzoption können Sie vorgeben, ob die Datei nach dem Laden an-
gezeigt wird (list = Standard) oder nicht (nolist).
sav[e] file_name [rep[lace]|app[end]]
X file_name
Geben Sie hier den Pfad und Namen der zu speichernden Datei ein.
X rep[lace]|app[end]
Standardmäßig versucht SQL*Plus die angegebene Datei zu erstellen. Ist die
schon vorhanden, dann erhalten Sie eine Fehlermeldung und müssen dann die
Option replace verwenden, um die Datei zu überschreiben. Mit der Option
append wird der aktuelle SQL-Puffer an die vorgegebene Datei angehängt.
1.8.2 SQL*Plus als Skriptinterpreter

Genau wie beim Server-Manager können Sie auch mit Hilfe von SQL*Plus soge-
nannte SQL-Skripte ablaufen lassen. In einem solchen Skript werden vielleicht ver-
schiedene Abfragen oder spezielle SQL-Befehle ausgeführt oder sogar komplexe PL/
SQL-Programme aufgerufen.
Vielleicht verwenden Sie auf Ihrem Rechner ja auch gelegentlich oder sogar regel-
mäßig Batch-Dateien, um mit deren Hilfe regelmäßige Aufgaben, wie z.B.
X die Durchführung von Sicherungen,
X einen Dateiversand via FTP,
X das automatische Löschen bestimmter Dateien oder Verzeichnisse,
X oder sogar das sequentielle Starten verschiedener Programme
zu automatisieren. Die Befehle solcher Batch-Dateien werden eigentlich immer
nicht direkt vom Recher bzw. dessen Betriebssystem, sondern immer mit Hilfe
eines speziellen Kommandointerpreters, z.B. einem MS-DOS-Fenster unter NT, aus-
geführt. In Analogie hierzu können Sie SQL*Plus als Kommandointerpreter zur
Oracle-Datenbank einsetzen. Hierzu können Sie SQL*Plus zusammen mit einem
Skript starten, das dann automatisch ausgeführt wird.
Dieses Verfahren findet in der Praxis häufig Verwendung. Zum einen kann man
hierfür spezielle Verknüpfungen auf dem Desktop oder in einer Programm-Gruppe
anlegen, um dann per Mausklick immer wiederkehrende Abläufe (z.B. Reorganisa-
tionsarbeiten, Füllen von Arbeitstabellen etc.) zu starten. Zum anderen finden Sie
diese Methode aber in den Batchabläufen von Produktionsumgebungen. Da wer-
den im Rahmen der Nachtverarbeitung, gesteuert durch UNIX-Shell-Skripte,
immer wieder verschiedene Abfragen oder PL/SQL-Programme gestartet. Zwischen-
durch laufen andere Programme wie zum Beispiel Datensicherungen oder andere
Cobol- oder SQR-Anwendungen. Klar ist, dass in dem zuletzt genannten Beispiel
die gesamte Verarbeitung auf dem UNIX-Server bleibt, was aufgrund der auch dort
vorhandenen SQL*Plus-Version kein Problem ist.
Kommanodzeilenparameter
Um SQL*Plus in der eben beschriebenen Weise zu verwenden, müssen Sie das Pro-
gramm zusammen mit verschiedenen Kommoandozeilenparametern verwenden.
Diese Kommondozeilenparameter dienen vor allem zum Anmelden an die Daten-
bank bzw. zur Übergabe des zu startenden SQL-Skriptes. Im Einzelnen können Sie
hinter dem Programmnamen folgende Parameter verwenden:
[-s] [Logon] [Skript] [Argumente]
X -s
Dieser „ruhige Modus“ sorgt dafür, dass zum einen das Fenster von SQL*Plus im
Hintergrund bleibt und zum anderen in dem Fenster keine Meldungen ausgege-
ben werden. Dieser Modus ist damit vor allem geeignet, wenn Sie SQL*Plus aus
SQL*Plus 101
einem anderen Programm heraus starten und alle benötigten Anmeldeinforma-

tionen vorhanden sind.
X Logon
Mit diesem Parameter müssen Sie die benötigten Anmeldeinformationen über-
geben. Diese Anmeldeinformationen bestehen aus dem Benutzernamen, gefolgt
von einem Schrägstrich (/) und dem zugehörigen Passwort und wird mit einem
Klammeraffen (@) gefolgt von der Datenbankinstanz abgeschlossen (z.B. sys-
tem/manager@db01). Dabei besteht auch die Möglichkeit, das Passwort wegzu-
lassen, damit es nach dem Start von SQL*Plus abgefragt wird (z.B. sys-
tem@db01).
X Skript
Mit diesem Parameter können Sie das zu startende SQL-Skript vorgeben. Begin-
nen Sie Ihre Eingabe hierbei mit einem Klammeraffen (@) und spezifizieren Sie
anschließend das Skript mit geeignetem Zugriffspfad und Namen (z.B.
@c:\temp\test.sql).
X Argumente
Sofern Ihr Skript selbst weitere Argumente benötigt, dann können Sie diese jetzt
vorgeben. Die im Skript verwendeten Platzhalter werden durch die übergebenen
Argumente ersetzt. Dabei müssen Sie für das erste Argument den Platzhalter &1
und für alle weiteren Argumente die Platzhalter &2, &3 usw. verwenden.
Vervollständigen wir diesen Abschnitt durch ein kleines Beispiel. Betrachten Sie
hierzu zunächst das kleine nachfolgende Listing (1.12), das Sie auf der Begleit-CD
im \SQLPLUS-Unterverzeichnis unter dem Namen PLUS01.SQL finden.
set termout off;

spool &1;
select name from v$datafile;
spool off;
set termout on;
exit;
Listing 1.12: Beispiel für ein kleines SQL*Plus-Skript
In dem Skript wird zunächst einmal mit Hilfe des Befehls set termout off die Ausgabe
von Meldungen im SQL*Plus-Arbeitsfenster ausgeschaltet. Danach werden alle
Ausgaben in die Datei &1 umgeleitet (spool). Da es sich hierbei um einen Platzhal-
ter handelt, muss der konkrete Dateiname beim Start des Skripts als Argument
übergeben werden. Danach erfolgt mit Hilfe der schon bekannten Abfrage die Aus-
gabe der Namen der zur Datenbank gehörenden Datenfiles. Zum Schluss wird die
Ausgabeumleitung wieder aus- (spool off) und die Ausgabe im SQL*Plus-Fenster wie-
der eingeschaltet. Danach wird das Plus-Programm mittels Exit-Befehl beendet.
Starten Sie nun, beispielsweise mit Hilfe des Ausführen-Eintrags, aus dem Windows-
Start-Menü folgenden Befehl (vgl. Abb. 1.42):
plus80w -s system/manager@db01 @c:\temp\plus01.sql c:\temp\ausgabe.dat

sqlplusw -s system/manager@db01 @c:\temp\plus01.sql c:\temp\ausgabe.dat
Abbildung 1.60: Starten von SQL*Plus mit Parametern
Als Ergebnis dieses Aufrufs erhalten Sie in dem vorgegebenen Verzeichnis die Datei
AUSGABE.DAT, in der Sie die Namen aller Dateibankdateien finden. Experimentie-
ren Sie einfach mal mit den verschiedenen Startmöglichkeiten, indem Sie beispiels-
weise mal den Schalter –s weglassen. Variieren Sie außerdem die verwendeten
Logon-Informationen, indem Sie zum Beispiel nur system@db01 verwenden, um die
Passworteingabe nach dem Programmstart zu erzwingen.
Benutzereingaben
Manchmal kann es sinnvoll sein, während der Ausführung eines Skripts weitere
Eingaben vom Anwender abzufragen. Ein prädestiniertes Beispiel hierfür sind
Installationsskripte, in denen am Anfang verschiedene Installationsparameter
abgefragt werden. Solche Eingaben können Sie zur Laufzeit mit Hilfe des Accept-
Befehls vom Benutzer einfordern:
acc[ept] variable [num[ber]|char|date] [for[mat] format] [def[ault] default]

[prompt text]
X variable
legt den Namen der Variable fest, in der die Eingabe gespeichert wird. Innerhalb
des Skripts können Sie die Variable test über die Zeichenfolge &test ansprechen.
X num[ber]|char|date
Legen Sie hier bei Bedarf den Datentyp Ihrer Variablen fest. Wenn Sie nichts
vorgeben, dann wird der Typ char angenommen.
X for[mat] format
Legen Sie hier bei Bedarf das Format für Ihre Eingabe fest. Bei Zeichenfolgen
(char) haben Sie hierbei die Möglichkeit die maximale Länge der Eingabe festzu-
legen, indem Sie als Format beispielsweise A10 für eine maximal zehnstellige
Eingabe verwenden.
Bei Datums- oder Zeitwerten (date) können Sie das Eingabeformat mit Hilfe der
Buchstaben „DD“ (Tage), „MM“ (Monate) und „YY“ bzw. „YYYY“ für das Jahr
(z.B. DD.MM.YYYY) oder „HH24“ (Zeit im 24-Stundenmodus), ‚MI“ (Minuten)
und „SS“ für die Sekunden (z.B. HH24:MI:SS) festlegen.
SQL*Plus 103
Beim Eingabeformat numerische Werte legen Sie mit Hilfe der Ziffer 9 und dem
Punkt (.) als Dezimaltrennzeichen vor allem wieder die maximale Länge der
Zahl bzw. die Anzahl der Nachkommastellen fest (z.B. 999.99).
X def[ault] default
Legen Sie hier einen Standardwert fest, der genommen wird, wenn Sie die Ein-
gabeaufforderung mit Hilfe der Eingabetaste übergehen.
X prompt text
Geben Sie hier den Text ein, der während der Eingabeaufforderung am Bild-
schirm angezeigt wird.
Wir wollen nun unser kleines Beispiel erweitern, in dem wir die in einem vom
Benutzer vorgegebenen Tablespace angelegte Tabellen ausgeben (vgl. Listing 1.13,
PLUS02.SQL).
acc tname char format 'A20' default 'SYSTEM' prompt 'Name des Tablespace: ';
set termout off;
spool &1;
select table_name from dba_tables
where tablespace_name = '&tname';
spool off;
set termout on;
exit;
Listing 1.13: Benutzereingaben während des Skripts abfragen
Am Anfang des Listings wird die Eingabe des Benutzers in der Variablen tname
gespeichert, die etwas später in einer Abfrage als &tname Verwendung findet. Mit
Hilfe des Objekts dba_tables werden die Namen der Tabellen angezeigt, die in dem
vorgegebenen Tablespace gespeichert sind; ansonsten entspricht das Beispiel der
Datei PLUS01.SQL.
Befehle des Betriebssystems verwenden

Wie Sie mittlerweile wissen, können Sie SQL*Plus innerhalb eines Betriebssys-
temskripts verwenden, um eine Abfrage oder ein SQL-Programm zu starten. Das
Ganze geht auch umgekehrt, d.h. Sie können innerhalb eines SQL-Skripts einen
Betriebssystembefehl absetzen bzw. ein entsprechendes Skript starten. Testen Sie
das doch gleich einmal und geben Sie am SQL-Prompt die folgende Anweisung ein:
ho[st] calc.exe
Hierdurch starten Sie aus SQL*Plus heraus den Windows-Taschenrechner. Genau

wie beim Start des Editors wird das aufgerufene Programm hierbei wieder synchron
aufgerufen, d.h. SQL*Plus wartet so lange mit der weiteren Ausführung der restli-
chen Zeilen im SQL-Puffer, bis das gestartete Programm wieder beendet wurde.
Für dieses Verfahren gibt es in der Praxis eine Menge Einsatzmöglichkeiten. Zum
Beispiel können Sie hierdurch das Kopieren oder den Ftp-Versand einer erstellten
Ausgabedatei aus Ihrem SQL-Programm heraus veranlassen. Oder Sie verschicken
automatisch ein E-Mail, nachdem Sie mit Hilfe verschiedener Abfragen eine spezi-
elle Arbeitstabelle erstellt haben. Eine weitere Möglichkeit besteht in der Erstel-
lung einer Datensicherung, bevor Sie eine komplexe Änderungsabfrage starten,
indem Sie zunächst den zugehörigen Tablespace inaktivieren und anschließend die
zugehörigen Dateien kopieren. Danach aktivieren Sie den Tablespace wieder und
führen Ihre Änderungsabfragen durch.
Hier und jetzt möchte ich diese Möglichkeit jedoch nur mit Hilfe eines einfachen
Beispiels demonstrieren und hierzu das letzte Beispiel noch einmal ein wenig
erweitern (vgl. Listing 1.14, PLUS03.SQL und 1.15, NACHLAUF.BAT).
acc tname char format 'A20' default 'SYSTEM' prompt 'Name des Tablespace: ';
set termout off;
spool &1;
select table_name from dba_tables
where tablespace_name = '&tname';
spool off;
set termout on;
ho c:\temp\nachlauf.bat &1;
Listing 1.14: Starten der Batchdatei NACHLAUF.BAT
In dem Beispiel neu hinzugekommen ist lediglich die letzte Zeile mit dem ho bzw.
host-Befehl. Dieses Kommando erlaubt den Aufruf eines beliebigen Betriebssystem-
befehls, also auch den Start einer ganzen Batch- bzw. Shellskripts. In unserem Bei-
spiel wird die Batchdatei NACHLAUF.BAT, der beim Aufruf der Name der Ausgabe-
datei in Form des Parameters &1 übergeben wird.
echo jetzt läuft die Batchdatei

copy %1 c:\temp\protokoll.txt
dir c:\temp
rem ... beliebige weitere Kommandos
pause
Listing 1.15: Ausdruck der Batchdatei NACHLAUF.BAT
In dieser Batchdatei können Sie natürlich alle möglichen Befehle des jeweiligen
Betriebssystems verwenden. In unserem Beispiel verwenden wir verschiedenen
DOS-Befehle, so dass Sie es ohne große Anpassungen auf jedem Windows-Rechner
verwenden können. Während der Ausführung wird die im SQL-Skript erstellte Aus-
gabedatei, die dem Batch als Parameter übergeben und dort mit Hilfe der Variablen
%1 angesprochen werden kann, zur Datei PROTOKOLL.TXT kopiert. Am Ende
wird die Batchausführung durch den Befehl pause angehalten, so dass das zugehö-
rige MS-DOS-Fenster erst nach einem Tastendruck geschlossen wird, wonach Sie
nach SQL*Plus zurückkehren.
Das SQL-Worksheet 105
1.9 Das SQL-Worksheet

Im Rahmen der Installation des „Oracle Enterprise Managers” erhalten Sie mit dem
SQL-Worksheet einen weiteren SQL-Editor (vgl. Abb. 1.61 oder 1.62), der in der 8i-
Version wieder in einem neuen Layout vorliegt. Zwar lässt dieser Editor ein kom-
fortableres Bearbeiten von Programmen oder Abfragen zu, aber dennoch ist er kein
vollständiger Ersatz für SQL*Plus, weil ihm vor allem die im Kapitel 1.8.2 beschrie-
benen Fähigkeiten fehlen, als Batchschnittstelle zwischen Datenbank und exter-
nen Abläufen zu fungieren.
Abbildung 1.61: Das SQL-Worksheet der 8er-Version
Nach dem Start des Programms erscheint zunächst ein kleines Fenster, mit dessen
Hilfe Sie sich an einer Oracle-Datenbank anmelden können. Danach, d.h. nach
erfolgreicher Datenbankanmeldung, erhalten Sie mit dem SQL-Worksheet im Prin-
zip zwei Fenster. Bei der 8er-Version dient das untere Eingabefenster als Fullscreen-
Editor zum Eingeben bzw. Bearbeiten der benötigten Befehle und nach deren Aus-
führung werden die Ergebnisse im oberen Ausgabefenster dargestellt. In der 8i-Ver-
sion ist das genau umgekehrt, d.h. im oberen Fenster wird getippt und im unteren
geschaut. Die beiden Arbeitsfenster werden in der Mitte des Programmfensters
durch eine Linie getrennt und sind standardmäßig gleich groß, wobei Sie deren
Aufteilung mit Hilfe dieser Linie und der Maus beliebig verändern können.
Abbildung 1.62: SQL-Worksheet im neuen 8i-Look
Der prinzipielle Umgang mit dem SQL-Worksheet sollte eigentliche überhaupt

keine Probleme bereiten. Besondere oder verborgene Funktionalitäten gibt es
eigentlich nicht, deshalb möchte ich mich an dieser Stelle auch ziemlich kurz fas-
sen. Alle Funktionen lassen sich entweder mit Hilfe des vorhandenen Menüs oder
der beispielsweise links unten bzw. oben sichtbaren Icons aufrufen. Besonders
praktisch ist, dass das Ausführen- bzw. Execute-Menü mit der Funktionstaste F5 ver-
knüpft wurde, so dass Sie die erfassten SQL-Anweisungen quasi auf Knopfdruck
starten können.
Mit Hilfe der File- bzw. Datei-Menüeinträge können Sie den Inhalt des Eingabefens-
ters löschen, eine SQL-Datei in dieses Fenster hineinladen oder den aktuellen
Inhalt speichern bzw. unter einem neuen Namen abspeichern.
Besonders praktisch ist auch, dass die zuletzt ausgeführten SQL-Anweisungen im
SQL-Worksheet gepuffert werden und bei Bedarf jederzeit wieder mit Hilfe der
Befehlshistorie wieder abgerufen werden können. Hierzu finden Sie im Worksheet-
bzw. Arbeitsblatt-Menü entsprechende Menüeinträge.
Mit Hilfe des Clear All- bzw. Alles löschen-Eintrags aus dem Edit- bzw. Bearbeiten-
Menü können Sie den Inhalt des Eingabe- oder Ausgabefensters löschen. Welches
Fenster hierbei gelöscht wird, das hängt davon ab, in welchem der beiden Fenster
Ihr Cursor stand bevor Sie den entsprechenden Menüeintrag ausgewählt haben.
Klicken Sie also zunächst in das jeweilige Eingabe- oder Ausgabefenster und wählen
Das SQL-Worksheet 107
Sie danach den eben beschriebnen Menüeintrag, um das Fenster bzw. seinen Inhalt
zu löschen.
Ich glaube, das waren genug Informationen, um mit der Arbeit des SQL-Work-
sheets problemlos zurecht zu kommen. Falls nicht, dann finden Sie in der Doku-
mentation des Oracle Enterprise Managers noch ein paar weitere Informationen.
2 Datenbankobjekte in einer
Oracle-DB
Ich denke, dass ich kein großes Geheimnis lüfte, wenn ich sage, dass Oracle genau
wie zumindest auch alle anderen relationalen Datenbank seine Daten mit Hilfe
von Tabellen speichert. Aber genau wie in den anderen Datenbanksystemen auch
sind Tabellen natürlich nicht das Einzige, was Sie bei genauerem Hinschauen fin-
den werden. In diesem Teil des Buches werden ich zunächst alle vorhandenen
Datenbankobjekte kurz vorstellen bzw. erklären. Im weiteren Verlauf werden die
für unsere Beispieldatenbank benötigten Objekte angelegt und danach werden die
auf der CD befindlichen Daten in die angelegten Tabellen geladen.
2.1 Der Oracle-Schema-Manager

Im Rahmen der Installation des Oracle Enterprise-Managers erhalten Sie ein Werk-
zeug, mit dem Sie alle verfügbaren Datenbankobjekte anlegen bzw. bearbeiten kön-
nen. Es handelt sich bei der Version 8 hierbei um den Oracle Schema Manager
(VAS.EXE), dessen Programmsymbol Sie üblicherweise in der Programmgruppe
„Oracle Enterprise Manager“ finden (vgl. Abb. 2.1). Sofern Sie eine 8i-Datenbank
verwenden, dann finden Sie die gleichen Funktionalitäten jetzt im neuen DBA-Stu-
dio (vgl. Abb. 2.2).
Nun kann man sich streiten, ob es sinnvoll ist, irgendwelche Datenbankdefinitio-
nen mit Hilfe eines solchen Werkzeugs durchzuführen. Betrachten Sie einmal die
Abbildung 2.1, in der das Fenster zum Bearbeiten des Programmcodes einer Oracle-
Datenbankprozedur gezeigt wird. Ich glaube, man braucht nicht viel Phantasie um
sich vorstellen zu können, dass der zugehörige Programmeditor in Form des klei-
nen Textfensters schon bei Programmen mit wenigen Zeilen alles andere als hilf-
reich ist.
110 Datenbankobjekte in einer Oracle-DB
Abbildung 2.1: Übersicht der Objekte mit Hilfe des Oracle-Schema-Managers
Abbildung 2.2: Darstellung des Schema-Managers im DBA Studio der 8i-Version

Der Oracle-Schema-Manager 111
Des weiteren ist es in vielen Unternehmen nicht üblich, Datenbankdefinitionen

auf Basis manueller, nicht nachvollziehbarer und vor allem nicht automatisch wie-
derherstellbarer Einzelschritte durchzuführen. Entweder ist das konkrete Anwen-
dungsprogramm aufgrund dort gespeicherter Definitionen in der Lage, die Daten-
bank mit Hilfe entsprechender SQL-Befehle oder eines generierten Skripts zu
erzeugen oder die zur Erstellung der einzelnen Objekte benötigten Statements wer-
den manuell in einem oder mehreren SQL-Skripts gesammelt.
In jedem Fall hat diese Vorgehensweise gegenüber der manuellen Erstellung über
den Schema Manager bzw. dem DBA-Studio den Vorteil, dass die gesamte Daten-
bank im Bedarfsfall automatisch generiert werden kann, indem beispielsweise ein-
fach alle gesammelten Erstell- bzw. Änderungsskripts nacheinander abgespielt wer-
den. Trotzdem hat das hier kurz beschriebene Programm natürlich seine
Daseinsberechtigung:
Der Oracle-Schema-Manager bzw. das DBA-Studio bietet eine Visualisierung

aller in der Datenbank enthaltenen Objekte. Dies ist unendlich komfortabe-
ler, als sich beispielsweise alle Einzelheiten mit Hilfe diverser Abfragen aus
den Systemtabellen herauszufummeln.
Sie können das Programm als Hilfstrainer verwenden. Immer wenn Sie ein Objekt
erstellen oder bearbeiten, finden Sie unterhalb des zugehörigen Dialogs die Schalt-
fläche Show SQL bzw. SQL anzeigen, die Sie auch schon vom Oracle Storage Manager
her kennen. Genau wie dort, führt zu einem Dialog, in dem Sie die zu Ihrer Erstel-
lung oder Änderung passende SQL-Anweisung finden. Nicht zu verachten sind
auch die sich hinter der Help- bzw. Hilfe-Schaltfläche verbergenden Informationen.
Die zugehörige Online-Hilfe enthält zeigt nämlich nicht lapidare Hinweise zur Pro-
grammbedienung, sondern erklärt die Ausprägungen der verschiedenen Eigen-
schaften des aktuell geöffneten Objekts.
Zur grundsätzlichen Bedienung gibt es eigentlich nicht viel zu sagen, das Pro-
gramm entspricht im Aussehen und in der Funktionsweise dem schon vorgestell-
ten Storage Manager. Außerdem fühlen wir Windows-Explorer gewöhnten Anwen-
der uns gleich zu Hause: links der Baum, rechts die zum Blatt gehörenden Details.
Ein letzter Hinweis zu dem Programm muss allerdings noch sein. Mit Hilfe der
links im Bild befindlichen Liste werden alle Objekte katalogisiert, die in der zuge-
hörigen Oracle-Datenbank möglich sind. Wundern Sie sich jedoch nicht, falls Sie
im konkreten Fall mal weniger oder vielleicht auch mal mehr sehen. Die zur Verfü-
gung stehenden Objekte hängen zum Teil nämlich von besonderen Zusatzfeatures
ab, d.h. sie sind erst verfügbar, wenn Sie die entsprechenden Zusatzpakete instal-
liert haben.
Dies gilt vor allem für die neuen objektorientierten Elemente, wie zum Beispiel die
Array Types, Object Types oder Table Types. Sollten Sie die zugehörigen Kategorien in
der Übersicht Ihres Schema-Managers vermissen, dann müssen Sie nicht nach
einem Installationsfehler suchen oder unbedingt nach einer neueren Version fahn-
den, denn sie sind nur dann verfügbar, wenn auf dem Datenbankserver die Oracle-
Objekte installiert wurden, wobei es sich hierbei früher um ein extra zu beziehen-
des und damit meistens wohl auch kostenpflichtiges Erweiterungspaket handelte.

Nach meinem Kenntnisstand sind die Objekte heute in aktuellen 8er-Versionen
immer enthalten aber es gibt auch noch andere Features wie zum Beispiel „Advan-
ced replication“ oder „Parallel Server“, die nicht in jeder Version verfügbar sind.
Fragen Sie im Zweifel direkt bei Oracle nach, wenn Sie gerade darüber nachdenken
eine eigene Oracle-Lizenz zu erwerben und unbedingt Wert auf die Objekt-Optionen
legen. Ich werde dieses Feature im Rahmen der gleich folgenden Schema-Übersicht
abschließend abhandeln, d.h. sowohl bei der Anlage unserer Musterdatenbank als
auch in den noch folgenden Kapitel werden die vorgestellten Beispiele keine
Objekte beinhalten. Auch wenn diese Features zum heutigen Stand zumindest für
ein Datenbanksystem beeindruckend sind, so spielen sie im Zusammenhang mit
Standardsoftware im Augenblick noch keine Rolle. Solche Standardpakete nutzen
meistens sowieso nur wenige spezielle Funktionen, da sie darauf ausgelegt sind, auf
möglichst vielen unterschiedlichen Datenbanksystemen zu laufen.
Aber zurück zum Thema. Wollen Sie nun ganz sicher gehen, ob Sie diese Objekt-
Option haben oder nicht, dann können Sie dies mit Hilfe einer Abfrage der View
v$option klären:
SQLWKS> select * from v$option;

PARAMETER VALUE
---------------------------------------------------------------- ------
Partitioning TRUE
Objects TRUE
Parallel Server FALSE
Advanced replication TRUE
Bit-mapped indexes TRUE
Connection multiplexing TRUE
Connection pooling TRUE
Database queuing TRUE
Incremental backup and recovery TRUE
Instead-of triggers TRUE
Parallel backup and recovery TRUE
Parallel execution TRUE
Parallel load TRUE
Point-in-time tablespace recovery TRUE
14 rows selected.
Listing 2.1: Abfrage der installierten bzw. verfügbaren Optionen
Was ist ein Schema?

Was ist überhaupt ein Schema? Ich habe den Begriff bisher selbst schon ein paar
Mal verwendet, aber bisher noch nicht erklärt. Sofern Sie bisher nur mit anderen
Datenbanksystemen gearbeitet haben, dann hören Sie diesen Begriff hier vielleicht
zum ersten Mal, obwohl Sie das damit gemeinte Prinzip mit Sicherheit kennen.
Hinter diesem Begriff verbirgt sich eigentlich nur die logische Zusammenfassung
Beschreibung der Objekte 113
von Datenbankobjekten wie Tabellen, Indizes oder Prozeduren zu einer Einheit,

eben diesem sogenannten Schema.
Technisch wird das in Oracle, wie übrigens in den meisten anderen Datenbanken
auch, durch einen speziellen Benutzer (engl. User) realisiert, dem alle zum Schema
gehörenden Objekte gehören, also Eigentümer dieser Objekte ist. Aus technischer
Sicht kann man also Schema und Benutzer gleichsetzen, d.h. wenn Sie im Rahmen
einer Installationsanleitung lesen, dass Sie zunächst ein bestimmtes Schema anle-
gen müssen, dann ist damit die Anlage eines sicherlich meistens mit speziellen
Rechten ausgestatteten Users gemeint, der Eigentümer der während der Installation
anzulegenden Objekte wird.
Oftmals handelt es sich bei einem solchen Schema um einen speziellen techni-
schen Benutzer, d.h. mit Hilfe der zugehörigen Benutzer-Id wird nicht wirklich in
der Datenbank gearbeitet, sondern diese Id dient nur zum Vorhalten der benötig-
ten Datenbankobjekte oder wird auch zu deren Wartung bzw. Änderung verwen-
det. Wenn man dieses Konzept durchhält, dann entsteht zwangsläufig eine gewisse
Ordnung in der Datenbank. Dies gilt vor allem dann, wenn mehrere verschiedene
Produkte in einer Oracle-Datenbank installiert wurden.
Nehmen wir einfach mal an, die Tabellen und sonstigen Objekte der HR-Software
PeopleSoft werden mit Hilfe des Benutzers psoft, die Objekte des Weiterbildungs-
produkts Pisa unter Verwendung des gleichnamigen Benutzers und schließlich
auch noch eine SAP-Anwendung, über den User saphr installiert. Jedes dieser Pro-
dukte generiert für sich zum Teil mehr als tausend verschiedene Datenbankobjekte,
die allerdings wegen der drei unterschiedlichen Schematas jederzeit den einzelnen
Anwendungen zugeordnet werden können.
Betrachten Sie unter diesem Eindruck noch einmal das Bild des Schema-Managers
(vgl. Abb. 2.1 oder 2.2). Die in der Datenbank vorhandenen Prozeduren werden
mit Hilfe des links im Bild befindlichen Baums den jeweiligen Eigentümern, sprich
dem Schema, zugeordnet, so dass eine sehr gute Übersicht entsteht.
Zum Schluss möchte ich noch auf ein weiteres kleines Schmankerl hinweisen, das
dieses Schema-Konzept mit sich bringt. Nichts währt für die Ewigkeit, und so
kommt irgendwann zwangsläufig die Stunde, in der eine Anwendung gelöscht wer-
den soll, d.h. es müssen alle zugehörigen Objekte aus der Datenbank entfernt wer-
den. Nichts einfacher als das, denn Sie müssen in dem Fall lediglich das entspre-
chende Schema, also den zugehörigen Benutzer, aus der Datenbank löschen. Hier
gibt es nichts zu erben, d.h. mit dem Ableben des Besitzers verschwinden auch alle
dessen Besitztümer.
2.2 Beschreibung der Objekte

Ich weiß nicht, wie es Ihnen geht, aber ich bin immer froh, wenn ich beim erstma-
ligen Kontakt mit einer neuen Datenbank eine Übersicht der vorhandenen Mög-
lichkeiten finde, um rasch den Brückenschlag aus der alten in die neue Datenbank-
welt hinzukriegen. Mit Möglichkeiten beschränke ich mich hierbei natürlich auf
die Fragestellung, was Sie alles in einer Oracle-Datenbank anlegen können. Auch
wenn eine solche Übersicht zunächst immer nur einen oberflächlichen Eindruck
hinterlässt, so hilft Sie dennoch, die folgenden ersten Gehversuche zu vereinfa-
chen bzw. beschleunigen. Bestimmte Themen klassifiziert man sofort als wichtig
und arbeitet sich folglich tiefer in die entsprechende Materie ein. Andere Themen
bleiben im Hinterkopf und können bei Bedarf weitergehender erforscht werden.
Mit Hilfe der folgenden Abschnitte will ich versuchen eine solche Übersicht zu
erstellen, in dem ich alle Objekttypen, die Sie mit Hilfe des Oracle Schema Mana-
gers erstellen können kurz beschreibe und auf die SQL-Befehle, die Sie zum Erstel-
len bzw. Bearbeiten der Objekte benötigen verweise, bzw. diese in den beschriebe-
nen Beispielen verwende.
Wie Sie im Verlauf des ersten Kapitels schon bemerkt haben dürften, halte ich mich
mit der Darstellung und Erklärung umfangreicher Syntax-Diagramme zu den ein-
zelnen Oracle-Befehlen sehr zurück. Dies wird sich auch hier bzw. im weiteren Ver-
lauf des Workshops nicht ändern. Die genaue Syntax eines Befehls können Sie mit
all seinen Varianten am besten in den Unterlagen des Herstellers nachlesen und
würde in diesem Buch nur kostbaren Platz verbrauchen. Das größere Problem liegt
zumindest nach meiner Erfahrung meistens darin, in Erfahrung zu bringen, welche
Befehl einem bei dem aktuellen Vorhaben bzw. Problem weiterhelfen könnte.
Kennt man erst einmal den Befehl, dann kann man die genaue Verwendung und
Kodierung leicht mit Hilfe der Programmdokumentation nachschlagen.
Weitergehende Informationen zur genauen Syntax bzw. Verwendung eines Befehls
finden Sie in der Oracle-Dokumentation im Buch „Oracle8 SQL Reference“ und tie-
fergehende Beschreibungen über die Verwendung der einzelnen Objekte verbergen
sich hinter dem Link „Oracle8 Concepts“.
Bezüglich der Programmierobjekte (Funktionen, Prozeduren und Trigger) finden
Sie auch in diesem Buch, und zwar im fünften Kapitel Kapitel „PL/SQL-Program-
mierung“, weitergehende Informationen. Dort finden Sie neben weiteren Beispie-
len auch eine systematische Einführung in PL/SQL.
Die nachfolgenden Beispiele (Listings) finden Sie alle auf der zum Buch gehören-
den Begleit-CD. Sofern nichts anderes angegeben ist, dann finden Sie die Beispiele
dieses Kapitels im \SCHEMA-Unterverzeichnis finden, wobei die Dateinamen den
Listing entsprechend, d.h. die Datei für das Listing 2.1 heißt entsprechend
LISTING21.SQL. Bei allen Beispielen müssen Sie natürlich beachten, dass Sie vor
deren Anwendung spezielle individuelle Einstellungen wie beispielsweise Table-
spacenamen überprüfen und ggf. anpassen müssen.
2.2.1 Array-Typ (Array Types)

Wie ich schon eingangs erwähnt habe, handelt es sich hier um eine Kategorie, die
Sie nur verwenden können, wenn auf Ihrem Datenbankserver die Objekt-Erweite-
rungen installiert wurden. Worum geht es aber nun bei diesen Array Types. Wenn
Sie aus der Programmierung kommen, dann sagt Ihnen wahrscheinlich alleine
schon der Begriff Array ziemlich deutlich, worum es hier geht. In deutschen Über-
setzungen spricht man in dem Zusammenhang meistens von Datenfeldern, und
damit wir alle über das gleiche Sprechen, habe ich mal eine Definition des Begriffs
Datenfeld ausgegraben:
Datenfeld: Ein Satz aufeinanderfolgender, indizierter Elemente, die den glei-

chen Datentyp besitzen. Jedes Element eines solchen Feldes wird durch eine
eindeutige Index-Nummer identifiziert.
Würde ich ein Buch zu einer Programmiersprache erstellen, dann hätte ich zur Ver-
anschaulichung des Arrays bzw. Datenfeldes vielleicht sogar den Begriff der Tabelle
ins Spiel gebracht, aber Tabellen sind in einer relationalen Datenbank wirklich
etwas ganz anderes.
Mit Hilfe der Array Types haben Sie nun die Möglichkeit neue (eigene) Datentypen
in Form von Datenfeldern zu definieren. Ein solcher selbstdefinierter Datentyp
kann anschließend innerhalb eines SQL-Programms, das alleine wäre gar nicht so
aufregend, und auch bei der Anlage von Tabellen verwendet werden.
Beispiele
Nehmen wir an, Sie möchten oder müssen eine Mitarbeitertabelle entwerfen, in
der die individuelle Wochenarbeitszeit gespeichert werden kann. Da wir ja mittler-
weile alle flexibel sind, reicht hierfür ein einfaches numerisches Feld zum Spei-
chern der Wochenstundenzahl meistens nicht mehr aus. Stattdessen benötigen wir
eher sieben numerische Felder, um die festgelegte Arbeitszeit pro Wochentag abzu-
speichern (vgl. Listing 2.2).
drop table ma_arbeitszeit;

/
create table ma_arbeitszeit (
persnr varchar2(11) not null,
sonntag number,
montag number,
dienstag number,
mittwoch number,
donnerstag number,
freitag number,
samstag number )
tablespace usr storage
(initial 10000 next 10000 maxextents unlimited pctincrease 0)
/
commit;
Listing 2.2: Anlegen einer Tabelle zum Speichern der Wochenstundenzahl
Mit Hilfe einer solchen Tabelle könnten Sie nun für jeden Mitarbeiter die individu-
elle Wochenarbeitszeit abspeichern. Betrachtet man nun die sieben Einzelfelder
zum Speichern der Tagesstunden, so ist das gemäß der eben beschriebenen Defini-
tion ein erstklassiger Kandidat für ein Datenfeld. Statt Sonntag, Montag, Dienstag
usw. sprechen wir dann nur noch von Tag(0), Tag(1), Tag(2), d.h. der Index des Tag
-Datenfeldes legt den genauen Wochentag fest.
Das Feature der Array Types ermöglichen Ihnen nun genau ein solches Datenfeld
anzulegen, indem Sie folgende Anweisung eingeben:
create type tag as varray(7) of number;

/
commit;
Listing 2.3: Anlegen des Datenfeld-Datentyps „tag“
Anschließend können Sie die Arbeitszeittabelle dann mit Hilfe des nun folgenden
Skripts definieren:
drop table ma_arbeitszeit;

/
create table ma_arbeitszeit (
persnr varchar2(11) not null,
az_tag tag )
tablespace usr storage
(initial 10000 next 10000 maxextents unlimited pctincrease 0)
/
commit;
Listing 2.4: Anlegen der Tabelle unter Verwendung des neuen Datentyps
Der wesentliche Unterschied zur vorhergehenden Version dieser Tabelle ist die Ver-
wendung des neuen Datentyps tag anstelle der sieben numerischen Felder. Das hat
natürlich Auswirkungen auf die Verwendung der Tabelle beim Einfügen oder Ände-
rung der dort gespeicherten Daten (CD: LISTING24A.SQL).
insert into ma_arbeitszeit

values ('4711',tag(0, 7.5, 7.5, 7.5, 7.5, 7.5, 0));
values ('4712',tag(0, 0, 9, 7.5, 7.5, 4.5, 2));
values ('4713',tag(3, 7.5, 7.5, 0, 0, 0, 0));
commit;
update ma_arbeitszeit
set az_tag=tag(3, 7.5, 7.5, 4, 0, 0, 0)
where persnr='4713';
commit;
Sowohl beim Einfügen neuer Datensätze als auch bei deren Änderung müssen Sie
für das neue Feld az_tag das komplette Datenfeld vorgeben. Hierbei müssen Sie den
Namen des Datentyps und danach alle Werte des Datenfeldes in Klammern und
durch Komma getrennt spezifizieren.
Wollen Sie das Datenfeld jedoch im Rahmen eines SQL-Ausdrucks oder für die Aus-
gabe innerhalb einer Auswahlabfrage verwenden, dann haben Sie allerdings noch
ein kleines Problem, denn hierbei können Datenfelder nicht direkt eingesetzt wer-
den, sondern Sie benötigen hierzu PL/SQL-Sprachelemente. In unserem Beispiel
könnte wir als Abhilfe also eine kleine Funktion schreiben, mit der die gewünsch-
ten Elemente aus dem Datenfeld herauskopiert werden (vgl. Listing 2.5). Im Vor-
griff auf das übernächste Kapitel soll die Funktion hier schon einmal erstellt wer-
den.
create or replace function get_az(in_arr in tag, in_tag in number)

return number is
begin
return in_arr(in_tag);
end;
/
show errors;
commit;
Listing 2.5: Erstellen einer Funktion zur Abfrage des Datenfeldes
Zur Funktion selbst möchte ich an dieser Stelle nicht allzu viel sagen. Im weiteren
Verlauf dieses Streifzugs durch die Schema-Objekte der Oracle-Datenbank werden
Sie weitergehende Hinweise über die Erstellung und Verwendung von Funktionen
finden. Das Problem war, dass Oracle beispielsweise im Rahmen des select-Befehls
keine Datenfelder zulässt. Allerdings können Sie dort Funktionen verwenden und
diese können wiederum Datenfelder als Parameter übernehmen, so dass wir unser
Problem über diesen Umweg lösen können.
Insgesamt übergeben wir unserer Funktion get_az zwei Parameter. Der erste Para-
meter erwartet das Datenfeld und mit Hilfe des zweiten Wertes übergeben wir der
Funktion den Index, für den die Funktion den Wert aus dem Feld zurückliefern
soll. Zur Vereinfachung verzichten wir innerhalb der Funktion auf jeglichen Kom-
fort beispielsweise einer Wertebereichsprüfung für den übergebenen Index.
Warum die direkte Verwendung des varray-Feldes im select-Ausdruck zu Problemen
führt wird klar, wenn man sich einmal die Tabellenbeschreibung anschaut:
SQLWKS> desc ma_arbeitszeit

Column Name Null? Type
------------------------------ -------- ----
PERSNR NOT NULL VARCHAR2(11)
AZ_TAG RAW(192)
Wie Sie sehen, wird das Datenfeld intern mit Hilfe des Datentyps raw gespeichert.
Normalerweise werden mit diesem Typ jegliche Binärdaten bzw. Bytekette wie zum
Beispiel Grafiken oder Klänge gespeichert, d.h. die dort gespeicherten Daten sind
in jedem Fall interpretationsbedürftig und damit nicht ohne weiteres anzeigefähig.
Schreiten wir also zur Verwendung unsere neuen Funktion und listen alle Mitarbei-
ter mit ihrer jeweiligen Dienstagsarbeitszeit an:
SQLWKS> select persnr, get_az(persnr, 2)

from ma_arbeitszeit;
PERSNR GET_AZ(PER
----------- ----------
4711 7.5
4712 0
4713 7.5
3 rows selected.
Mit Hilfe des nächsten Abfragebeispiels suchen wir in unserer Tabelle Mitarbeiter,
die am 12.07.2000 zumindest laut der vereinbarten Arbeitszeit anwesend sind:
SQLWKS> select persnr

2> from ma_arbeitszeit
3> where get_az(persnr,
to_number(to_char(to_date('2000.07.12','YYYY.DD.MM'),'d'))) > 0;
PERSNR
-----------
4711
4712
2 rows selected.
Diesmal verwenden wir unsere neue Funktion get_az innerhalb der where-Klausel
der SQL-Abfrage. Das sieht zugegebener Weise auf den ersten Blick nicht so einfach
aus, ist aber in Wirklichkeit gar nicht so schlimm wie es vielleicht scheint. Machen
wir uns also die Mühe, und lösen die verwendete Schachtelfunktion einmal auf
(vgl. Abb. 2.3).
get_az(persnr, 4)
to_number(‘4’)
to_char(2000.07.12,'d')
to_date('2000.07.12','YYYY.DD.MM')
Abbildung 2.3: Entschachteln der verwendeten Funktionskette
Der innerste Funktionsaufruf verwendet die Standardfunktion to_date, um eine Zei-

chenfolge entsprechend der vorgegebenen Formatierung in ein Datum umzuwan-
deln. Dieses Datum erhält die Standardfunktion to_char als Eingabeparameter und
wandelt das Datum wieder in eine Zeichenkette um. Aufgrund des diesmal verwen-
deten Formatcodes erhalten wir hierbei den Tag der Woche (Sonntag = ‚0’, Montag
= ‚1’ usw.), den wir der Funktion to_number als Eingabeparameter übergeben, und
die das übergebene Zeichen als Zahl zurückliefert.
Noch ein Hinweis: Bei der Anlage solcher Datenfelder können Sie nicht nur die
standardmäßig in Oracle enthaltenen Datentypen (Zeichen, Zahlen, Datumswerte
usw.), sondern auch alle selbstdefinierten Typen bzw. Objekte verwenden.
2.2.2 Cluster (Clusters)

Die sogenannten Cluster bieten in Oracle eine Methode zusammengehörige Daten
in einem gemeinsamen Bereich, eben diesem Cluster, zu speichern. Die im Cluster
gespeicherten Tabellen sollten also gemeinsame Spalten aufweisen, wobei als wei-
teres Kriterium hinzukommt, dass die Tabellen meistens auch zusammen gelesen
werden. Letzteres ist der Fall, wenn die Tabellen immer wieder über die gemeinsa-
men Felder verknüpft werden oder mit Hilfe dieser Felder referentielle Integritäts-
bedingungen definiert wurden. Potentielle Kandidaten für das Anlegen solcher
Cluster sind damit Tabellen, die als Referenz in vielen andere Tabellen vorkommen.
Technisch betrachtet stellt ein solcher Cluster zunächst einmal einen abgegrenzten
Speicherbereich innerhalb eines vorhandenen Tablespaces dar und wird mit Hilfe
der Anweisung create cluster erstellt bzw. mit alter cluster geändert und via drop clus-
ter gelöscht. Beim Anlegen der einzelnen Tabellen werden dann für die gemeinsa-
men Daten zusätzlich die zu verwendenden Cluster vorgegeben.
Nehmen wir als Beispiel mal ein Abrechnungssystem und betrachten dort das Feld
„Kostenstelle“. Dieses Feld ist zum einen der Primärschlüssel der zugehörigen
Tabelle „Kostenstellen“, in der die zugehörigen Stammdaten (Bezeichnung, Gültig-
keit, Vorgesetzter usw.) gespeichert werden. Weiterhin enthält auch der Mitarbei-
terstamm eine Kostenstelle und auch in der Tabelle der Abrechnungsergebnisse ist
eine Kostenstelle enthalten. Wird nun die Mitarbeiterkostenstelle ausgewertet, so
benötigt man fast immer auch die Kostenstellentabelle selbst, um beispielsweise
auch die Kostenstellenbezeichnung anzuzeigen oder die Auswertung nach Vorge-
setzten zu sortieren.
Zusammen mit der Kostenstelle werden die Tabellen Mitarbeiterdaten und Kosten-
stellen also meistens gemeinsam benötigt. Das Gleiche gilt auch bei den Abrech-
nungsergebnissen. Spielt hier bei einer Auswertung die Kostenstelle eine Rolle,
dann benötigt man aus den eben genannten Gründen meistens auch noch die Kos-
tenstellentabelle. Folglich könnte man in dem Fall einen Cluster für das Feld Kos-
tenstelle anlegen und anschließend die drei Tabellen diesem Cluster zuordnen.
Auch wenn man spontan einen anderen Eindruck bekommen könnte: Das Clus-
tern von Tabellen hat keinen Einfluss auf deren sonstige Verwendbarkeit. Sie müs-
sen also bei einer Abfrage nicht wissen oder berücksichtigen, ob eine Tabelle
geclustert wurde oder nicht.
Eine Gesamtübersicht über die in der Datenbank vorhandenen Cluster erhalten Sie
außer mit dem Schema-Manger oder DBA Studio durch eine Abfrage der View
all_clusters.
2.2.3 Datenbank-Link (Database Links)

Wie Sie mittlerweile wissen, stellen verschiedene Oracle-Datenbanken selbst auf
einem Rechnerknoten eigenständige und voneinander abgeschottete Datensamm-
lungen dar. In manch anderen Datenbanksystem ist das anders und entsprechend
einfach ist es, beispielsweise innerhalb einer Abfrage auch Daten aus einer anderen,
aber in dem DBMS registrierten, Datenbank zu verwenden. Dafür wird es meistens
sehr viel schwieriger, wenn sich die benötigte Datenbank nicht auf dem gleichen
Rechnerknoten bzw. unter Hoheit des gleichen DBMS befindet.
Unter Oracle benötigen Sie für den Zugriff auf eine weitere Datenbank immer eine
Art Wegweiser, den Sie mit Hilfe der hier beschriebenen Datenbankverknüpfung
(Database Link) erstellen können. Dabei ist es dann allerdings gleichgültig, wo sich
die benötigten Datenbank auf dieser Welt befindet. Einzige Voraussetzung ist, dass
die benötigte Oracle-Datenbank über das Net8-Netzwerk erreichbar ist (vgl. Abb.
2.4).
Zwecks Anlage einer solchen Datenbankverknüpfung benötigen Sie für die Zielda-
tenbank eine geeignete Benutzer-Id nebst zugehörigem Passwort. Des weiteren
muss auf dem Server der primären Datenbank ein Dienstname für die Zieldaten-
bank existieren, beispielsweise mit Hilfe einer entsprechend konfigurierten Datei
TNSNAMES.ORA. Der letzte Satz verdient noch einmal eine Verstärkung: der Client
muss nicht in der Lage sein, sich selbst an die zu verknüpfende Datenbank anzu-
melden, d.h. die Instanz, in der Client gerade arbeitet, stellt die Verbindung zu der
verknüpften Datenbank her.
Wenn Sie MS-Access kennen, dann wissen Sie, dass Sie dort beispielsweise ähnliche
Möglichkeiten haben, indem Sie in der aktuellen Datenbank eine Tabelle aus einer
anderen Datenbank einbinden bzw. verknüpfen. So wie das Ganze in MS-Access
wirklich den Namen „Table Link“ verdient, beschreibt der hier verwendete Begriff
Database Link zutreffend, worum es sich bei Oracle handelt, nämlich um ein uni-
verselles Tor zu einer anderen Datenbank. Bleiben wir bei diesen Bildern. Das per
Link geöffnete Tor zur fremden Welt (Datenbank) kann zwar in der Tat recht uni-
versell sein, aber es ist in jedem Fall auch recht schmal. Damit will ich sagen, dass
Sie bei datenbankübergreifenden Abfragen die Ausführungsgeschwindigkeit ein
wenig im Auge behalten sollten, doch hierzu erfahren Sie erst am Ende des dritten
Kapitel mehr.
In dem skizzierten Beispiel der Abbildung 2.4 ist der Client über das Netzwerk mit
dem Server „Frankfurt“ verbunden und hat über das Net8-Netzwerk Zugriff auf die
dort laufende Datenbank „einkauf“, wobei er hierfür den in seiner Konfigurations-
datei TNSNAMES.ORA definierten Dienstnamen „eink“ verwendet. Mehr Dienst-
nameneinträge hat der Client nicht, d.h. die Vertriebsdatenbank in München ist
für ihn direkt nicht erreichbar.
connect hugo@eink
Client select * from
ver_mitarb@ein2
Netzwerk
München
Datenbank: vertrieb
Frankfurt
Datenbank: einkauf
Link ein2 = ver0
vert
eink ver0.world = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)
(HOST = muenchen))
(CONNECT_DATA = (SID = vert)))
Abbildung 2.4: Verwenden von Datenbankverknüpfungen
Auf dem Frankfurt-Server ist ebenfalls eine TNSNAMES-Konfiguration gespeichert.

Mit Hilfe dieser Konfiguration wird der Dienstname „ver0“ definiert, der auf die
Datenbankinstanz „vert“ auf dem Server „Muenchen“ verweist. Außerdem existiert
in der Datenbank „einkauf“ ein Link mit dem Namen „ein2“, der den Zugriffspfad
zu irgendeiner Datenbank mit Hilfe des Dientsnamens „ver0“ beschreibt.
Zugegeben, die in dem Beispiel verwendeten Kürzel sind ein wenig abenteuerlich.
In der Praxis hätte man sowohl für den Linknamen als auch für den Dienstnamen
auf dem Server sicherlich die Zeichenfolge „vert“ verwendet, um den Zugriff trans-
parent zu gestalten. Aber dann hätten Sie nicht auf einem Blick gesehen, wie die
Zusammenhänge sind. So aber ist ziemlich klar, welche Möglichkeiten Sie bei der
Namensgebung haben und was wie heißen darf bzw. was wie heißen muss.
Innerhalb einer Abfrage werden nun alle Tabellen, die mit Hilfe dieses Links aus der
angebundenen Datenbank verwendet werden sollen, mit einem Klammeraffen (@)
und dem Linknamen erweitert (z.B. select ... from xxxx@ein2).
Erstellt werden solche Datenbankverknüpfungen mit Hilfe des Befehls create data-
base link, und mit Hilfe der Anweisung drop database link kann eben beschriebene
Verbindungstür wieder geschlossen werden. Welche Möglichkeiten das Tor zur
Abfrage der entfernten Tabellen wirklich bietet, hängt vor allem davon ab, mit wel-
chem Benutzer sich die Datenbankinstanz an der Zieldatenbank anmeldet. Dieses
Verfahren müssen Sie beim Erstellen des Links festlegen. Hierbei können Sie bei-
spielsweise eine feste Benutzer-Id mit Passwort vorgeben oder der Zugriff soll mit
dem Benutzer nebst den zugehörigen Rechten erfolgen, der die Abfrage mit dem
Link ausführt.
Beispiele
Wenn Sie Lust auf ein Beispiel haben und entsprechend dem ersten Kapitel die
Datenbanken „orcl“ und „db01“ besitzen, dann können Sie das eben Beschriebene
leicht einmal ausprobieren und zwischen den beiden Datenbank einen Verknüp-
fung erstellen. Erweitern Sie hierzu zunächst auf dem Server die Dienstnamenkon-
figuration TNSNAMES.ORA um folgenden Eintrag:
orcl-l.world =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = ray_dell)
(PORT = 1521)
)
(CONNECT_DATA = (SID = orcl)
)
)
Listing 2.6: Erweitern TNSNAMES.ORA für den Database Link
Hierdurch erstellen Sie den Dienstnamen „orcl-l”, der für den Zugriff auf die Orcl-
Instanz genutzt werden kann. Melden Sie sich anschließend als Administrator
(Benutzer-ID system oder internal) an der Datenbankinstanz db01 an, und geben Sie
dort folgende Anweisung ein:
create database link oralink connect to system identified by manager using 'orcl-l';
commit;
Listing 2.7: Erstellen des Database Links „oralink“
Dieser Befehl erstellt die Datenbankverknüpfung mit dem Namen „oralink“ und
weist diese an, über den Dienstnamen „orcl-l“ eine Verbindung als Benutzer „sys-
tem“ mit dem Passwort „manager“ aufzubauen. Der commit-Befehl in der zweiten
Zeile schließt diese Transaktion ab, wodurch der neue Link verfügbar wird.
Geben Sie nun die folgende Abfrage (Listing 2.8) ein, um Informationen über die
Struktur der „entfernten“ Datanbank zu erhalten.
SQL> select name from v$datafile@oralink;
NAME
-----------------------------------------------------
E:\ORANT\DATABASE\SYS1ORCL.ORA
E:\ORANT\DATABASE\USR1ORCL.ORA
E:\ORANT\DATABASE\RBS1ORCL.ORA
E:\ORANT\DATABASE\TMP1ORCL.ORA
SQL>
Listing 2.8: Abfrage der Dateinamen der orcl-Datenbank

Mit Hilfe einer Abfrage der View all_db_links können Sie sich übrigens eine Über-
sicht aller in der Datenbank definierten Datenbanklinks erzeugen.
2.2.4 Funktion (Functions)

Wenn Sie schon einmal mit einer moderneren Programmiersprache oder mit einer
Tabellenkalkulation wie zum Beispiel MS-Excel gearbeitet haben, dann ist Ihnen
die Verwendung einer Funktion sicherlich vertraut. Funktionen stellen üblicher-
weise spezielle Miniprogramme zur Verfügung, mit deren Hilfe Sie bestimmte Auf-
gaben erledigen können. Dabei werden diese Funktionen üblicherweise mit einem
oder mehreren Parametern aufgerufen und liefern als Ergebnis genau einen Wert
zurück.
Auch innerhalb einer relationalen Datenbank spielen Funktionen heute eine wich-
tige Rolle. Eigentlich jeder ernstzunehmende Vertreter dieser Datenbankgattung
stellt in seinem SQL-Sprachumfang eine umfangreiche Funktionssammlung zur
Verfügung, mit deren Hilfe Sie verschiedene Aufgaben, wie zum Beispiel das Forma-
tieren von Datumswerten, die Durchführung spezieller Berechnungen oder das
Bearbeiten von Zeichenketten erledigen können. Des weiteren werden die benötig-
ten Methoden der noch zu besprechenden Objekte mit Hilfe solcher selbstdefinier-
ten Funktionen realisiert.
So weit - so gut, doch eigentlich rede bzw. schreibe ich die ganze Zeit am eigentli-
chen Thema vorbei, oder einigen wir uns darauf, das ich mich nicht geradlinig,
sonder kreisförmig dem eigentlichen Kern der Sache nähere. Hier und jetzt geht es
nämlich nicht um die Verwendung irgendwelcher vorgefertigten Programme, son-
dern unter Oracle haben Sie die Möglichkeit auch eigene Funktionen zu erstellen,
deren spätere Verwendung sich in keiner Weise von den vom Hersteller gelieferten
Vorbildern unterscheidet. Das ist eine Option, die zur Zeit in vielen anderen Daten-
banksystemen noch ihresgleichen sucht.
Eigene Funktionen werden in Oracle mit Hilfe des Schlüsselwortes create function
angelegt und mit Hilfe des Befehls drop function wieder gelöscht. Um das Bearbeiten
einer schon bestehenden Funktion zu vereinfachen, wurde die create-Anweisung
um eine replace-Option erweitert, mit der Sie die bestehende Funktion ersetzen
können. Diese Ersetzungsoption existiert im Übrigen für viele Objekte und erspart
Ihnen das bei vielen anderen DB-Systemen notwendige vorherige Löschen (drop-
pen). Das hat unter Umständen wiederum weitreichende Konsequenzen auf die
Benutzeradministration, denn üblicherweise gehen beim drop die individuell auf
dieses Objekt zugewiesenen Rechte verloren, wohingegen sie beim replace erhalten
bleiben, d.h. hinter dem replace steckt doch mehr als ein bisschen Benutzerkomfort
dahinter.
Beispiele
Zur Demonstration wollen wir eine Funktion basteln, die den übergebenen Para-
meter anders formatiert zurückliefert. Konkret erwartet die Funktionen einen Text
und liefert diesen rückwärts gelesen wieder zurück.
create or replace function spiegeln (in_c varchar2)

return varchar is
begin
return '{' || in_c || '}';
end;
/
show errors;
commit;
Listing 2.9: Erstellen eines einfachen Funktionsgerüsts
Betrachten Sie zunächst das Listing 2.9. Die hier gezeigte Funktion löst zwar nicht
die eben beschriebene Aufgabenstellung, sondern sie demonstriert nur die Erstel-
lung des benötigten und noch leeren Funktionsgerüsts.
Beim Anlegen oder Bearbeiten von Funktionen müssen Sie hinter der create-Anwei-
sung den Funktionsnamen, in unserem Fall „spiegeln“, angeben. Dahinter folgt in
Klammern die durch Komma getrennte Aufzählung der übergebenen Parameter
nebst zugehörigem Datentyp. Hierbei können neben den vordefinierten Standard-
datentypen (z.B. date, number oder varchar2) auch alle selbstdefinierten Typen ver-
wenden.
Nach dieser Parameterleiste folgt eingeleitet durch das Schlüsselwort return die
Definition des von der Funktion zurückgelieferten Datentyps und abschließend lei-
tet das Wörtchen is (oder as) die Beschreibung des eigentlichen Funktionsrumpfes
ein. Ähnlich wie in Pascal, C und weiteren Programmiersprachen wird auch PL/
SQL blockorientiert kodiert. Solche Programmblöcke beginnen mit dem Schlüssel-
wort begin und enden mit einer end-Anweisung, wobei ein solcher Block auch
immer mit einem Semikolon (;) abgeschlossen wird. Innerhalb eines solchen Blo-
ckes werden die einzelnen Anweisungen oder gegebenenfalls weitere Blöcke
kodiert, die ebenfalls durch ein Semikolon beendet werden.
Wie schon gesagt, ist das Besondere an einer Funktion eben, dass sie einen berech-
neten Wert zurückliefert. Innerhalb des Funktionsrumpfes passiert dies mit Hilfe
der Anweisung return. In unserem einfachen Beispiel folgt dieser Anweisung ein
Ausdruck, mit dessen Hilfe der übergebene Ausdruck in geschweiften Klammern
eingefasst wird. Dieses Einfassen erfolgt mit Hilfe des Operators ||, mit dem Sie Zei-
chenfolgen aneinanderhängen (konkatenieren) können.
Nach der Kodierung der gesamten Funktion finden Sie in dem Beispiel noch die
Verwendung der Anweisung show errors, bevor die ganze Transaktion mit Hilfe der
commit-Anweisung abgeschlossen wird. Dieser Befehl tut eigentlich genau das, was
er verheißt, d.h. im Falle einer fehlerhaften Kodierung erhalten Sie hierdurch eine
Anzeige der suspekten Programmstellen nebst zusätzlicher Informationen.
Nachdem Sie nun das Grundgerüst einer Funktion kennen, wollen wir es im zwei-
ten Schritt entsprechend der einstmals beschriebenen Aufgabenstellung erweitern
(vgl. Listing 2.10).
Beschreibu

Sprache

Heinz Gerd Raymans Oracle Programmierung

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Heinz Gerd Raymans Oracle Programmierung

Hochgeladen von

Copyright:

Verfügbare Formate

EDITION Oracle

Oracle 8i und Java - Oracle JDeveloper 2.0 als Entwicklungswerkzeug

Oracle 8 für den DBA - Verwalten, optimieren, vernetzen

Oracle 7.3 - Verwalten, optimieren, vernetzen

Oracle8 effizient einsetzen - Verteilung und Betrieb

Oracle-Programmierung - Datenbankprogrammierung und -administration

Oracle Designer R 6i und Developer 6i - Professionelle Modulentwicklung

Oracle Developer 6i - Softwareprojekte für das Internet-Computing

An imprint of Pearson Education

© 2001 by Addison-Wesley Verlag

2.2.3 Datenbank-Link (Database Links) ............................................120

V.1 Zum Inhalt

1.1.1 Klienten und Diener

Abbildung 1.1: Struktur eines „arbeitsplatzorientierten“ DBMS-Systems

Abbildung 1.2: DBMS mit einer Client/Server-Struktur

File Sharing System Client/Server System

File Sharing System Client/Server System

Tabelle 1.1: Gegenüberstellung File Sharing und Client/Server System

1.1.2 Aufbau des Oracle-DBMS

SGA = System Global Area

1.1.3 Aufbau einer Oracle-Datenbank

Jedes Datenbanksystem speichert seine Daten in ganz gewöhnlichen Dateien (wie

Logisches Modell Datenbank

Tablespaces Tablespace 1 Tablespace 2

Physische Dateien Datei 1 Datei 2 Datei 3

Abbildung 1.4: Schematischer Aufbau einer Oracle-Datenbank

Früher wurde viel mit diesen Optionen experimentiert, um das Antwortszeitverhal-

2Kb 2Kb 2Kb 2Kb 2Kb 2Kb

Abbildung 1.5: Segmente, Extends und Datenblöcke

1.2.1 Der Installationsvorgang

1.2.2 Installation der Version 8

Abbildung 1.6: Auswahl der Sprachoption für die Oracle-Installation

Abbildung 1.8: Was soll installiert werden?

Die voreingestellte Option Oracle8 installiert vorgegebene Komponenten des Ser-

Abbildung 1.9: „ Starterdatenbank“ installieren

Abbildung 1.10: Das war’s, die Installation wurde erfolgreich beendet

Die Installation begutachten

Abbildung 1.11: Optischer Überblick des Installationsergebnisses

Zunächst einmal liefert die Standardinstallation zwei neue Programmgruppen.

Abbildung 1.12: Hauptfenster des Oracle-Installers

Im Prinzip besteht das Hauptfenster des Installationsprogramms aus zwei Listen. In

1.2.3 Installation von 8i

Abbildung 1.13: Auswählen der Produktkategorie bei der 8i-Installation

Abbildung 1.14: Manuelle Auswahl der installierbaren Komponenten

Abbildung 1.15: Anzeige der geplanten 8i-Installation

1.3 Dienste unter Windows-NT

Abbildung 1.16: Wichtige Dienste zum Betrieb der Oracle-Instanz

rem Starten des Listeners,

Listing 1.1: Starten der Datenbank mit Hilfe von Net-Kommandos

rem Stoppen des Listeners, Stoppen der Datenbank ORCL

Listing 1.2: Stoppen einer Datenbank mit Hilfe von Net-Kommandos

1.4 Verbindung zur Datenbank herstellen

1.4.1 Einführung in SQL*Net bzw. Net8

Oracle Protokoll-Adapter Oracle Protokoll-Adapter

Abbildung 1.17: Schema der Net8-Kommunikation

1.4.2 Verbindung zur „ Starterdatenbank““ herstellen

Den „Listener“ konfigurieren

# Ich bin ein Kommentar

Listing 1.3: Konfiguration der Ports für den Listener-Prozess

Listing 1.4: Festlegen der „Horchliste“ für den Listener

Abbildung 1.18: Starten der Listener-Konsole bei einer 8i-Installation

Tabelle 1.2: Wichtige Kommandos der Listener-Konsole

Den Client konfigurieren

REM TABLESPACE FOR TEMPORARY***

REM TABLESPACE FOR INDEX*******