Oracle-Programmierung. Datenbankprogrammierung und -administration GERMAN

Oracle-Programmierung EDITION Oracle Oracle 8i und Java - Oracle JDeveloper 2.0 als Entwicklungswerkzeug Steven Ponndo...

Author: Heinz-Gerd Raymans

112 downloads 2072 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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 elektronischen 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 gleichzeitig 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: Lektorat: Herstellung: Korrektorat: Satz: Druck und Verarbeitung: Printed in Germany

Hommer Design, Haar bei München Martin Asbach, [email protected] Elisabeth Egger, [email protected] Christine Depta, Freising mediaService, Siegen Bercker, Kevelaer

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.3

2.4

3

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 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 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

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

3.3

3.4

3.5

7

Ä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 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 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

6

Anwendungsbeispiele.............................................................................454 5.2.1 Benutzerverwaltung................................................................454 5.2.2 Änderungsprotokollierung ......................................................460 5.2.3 Komplexe Integritätsbedingungen..........................................465 5.2.4 Exporthilfe ..............................................................................475

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 intensiveren 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 Kontakt zu Oracle bekam, da hatte ich neben umfangreicher Programmiererfahrung und detaillierten SQL-Kenntnissen auch weitreichende Erfahrungen mit verschiedenen Datenbanksystemen, beispielsweise Sybase oder dem Microsoft SQL-Server. Wenn Sie auf mein oben genanntes Datum geachtet haben und sich ein wenig auskennen, 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 DBMSSystemen. Die Werkzeuge sind andere, die Struktur der Datenbank (Schema, Tablespace) ist anders, Abfragen müssen zum Teil anders gestaltet werden. Anders ausgedrü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änden. Ich betrachte eine Datenbank immer als Werkzeug, als Mittel zum Zweck, mehr oder weniger Datensätze irgendwo zu speichern und bei Bedarf auch wiederzufinden. 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 Anwenderprobleme 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 bohren.

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 insgesamt eine tragende Rolle zu, denn es lieferte einige der in diesem Buch aufgearbeiteten Anregungen und Beispiele. Erwähnen möchte ich auch meine beiden Kinder: euch traf es mal wieder am meisten, 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 Beispiele 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 abgesehen 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 schwerpunktmäßig mit diesen Themen beschäftigen (z.B. Oracle 8i und Java, ADDISON-WESLEY, ISBN 3-8273-1485-2). Im ersten Teil des Workshops „Oracle – erste Schritte “ geht es neben einigen allgemeinen 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 Indices 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 kennen. Der nächste bzw. dritte Teil des Buches widmet sich dem komplexen Thema Abfragen. Ausgehend von einfachen Auswahlabfragen geht der Streifzug weiter durch die Welt der Verknüpfungen (Joins) und mündet danach in den Komplex der Änderungsabfragen inklusive dem Erstellen von Cursorn zur Durchführung von Datenbankänderungen. Abgerundet wird der ganze Themenkomplex mit einigen Ausführungen und Tipps zum Thema Abfragetuning und verschiedenen Beispielen zur Anwendung der verfügbaren Data-Dictionary-Views, mit deren Hilfe Sie das Oracle-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 Änderungscursors geht: mit PL/SQL haben Sie eine schier unerschöpflichen Menge von Möglichkeiten. Abgeschlossen wird das Kapitel mit verschiedenen Anwendungsbeispielen, 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 FrontEnd-Anwendungen erstellen können. Als Demonstrationsobjekt finden Sie unter anderem eine Funktion, mit deren Hilfe Sie von Excel aus Abfragen in der OracleDatenbank 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, konstruktive 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 [email protected] 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 verschiedener Konzepte und Grundbegriffe. Sofern Sie schon einmal mit ähnlichen Datenbanksystemen (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 dieser 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 Sammlung 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 Arbeiten mit einer oder mehreren Datenbanken ermöglicht. Strukturierte Datensammlungen gab es eigentlich schon immer. Aber, und das wissen 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 Informationen kümmern. Ein Ergebnis dieser Verfahrensweisen war meistens eine sehr enge Verzahnung von Anwendungsprogramm und Datenbasis. Bei einem DatenbankManagement-System werden solche Detailarbeiten wie das Einfügen, Löschen oder Finden von Daten von ihm selbst erledigt. Hierzu erhält es vom Anwendungsprogramm lediglich bestimmte Kommandos in Form einer speziellen Sprache. Durch das vorhandene Regelwerk dieser Sprache und der Möglichkeit, das viele verschiedene Anwendungsprogramme die zugehörigen Kommandos absetzen können, entsteht die gewünschte Anwendungsunabhängigkeit.

14


1.1.1

Klienten und Diener

Entsprechend der eben erläuterten Definition handelt es sich auch bei dem Produkt 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 entgegenzunehmen, 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 Win NT, 95, 98, 2000 Excel

Server

Access

Access-DBMS Netzwerk

Datenbank

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 abgefragt. 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 Änderungen 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 komplexes Gebilde mit einer Unzahl verschiedenster Funktionalitäten. Es sollte somit plausibel sein, dass seine Arbeitsgeschwindigkeit nicht unwesentlich von

Grundlagen

X

X

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. 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 optimal 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 Arbeitsplatzrechner transportiert werden, damit das DBMS uns anschließend als Ergebnis 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. 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 Rechner 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-Systemen (z.B. auch FoxPro, Paradox, Approach u.a.) funktionieren. In der englischsprachigen Literatur wird ein solches DBMS oftmals auch als File Sharing Database System 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 zugehö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 System entstanden, wie Sie es in der heutigen Praxis oftmals vorfinden. Zum einen haben Sie den Arbeitsplatzrechner, den Client, auf dem die eigentlichen Anwendungen laufen. Diese fordern mit Hilfe von Nachrichten Daten aus der Datenbank ab oder veranlassen dortige Änderungen. Die Nachrichten werden über das Netzwerk an das auf dem Server laufende DBMS übermittelt. Das sorgt für die Bereitstellung 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.

16


Arbeitsplatz

Server

Win NT, 95, 98, 2000 Excel

DBMS

Access Nachrichtendienst

Nachrichtendienst Netzwerk

Datenbank

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 Hauptaufgabe 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 exklusiv nutzt. Die einzelnen Anwendungen verbinden sich lediglich direkt oder über den Listener mit dem DBMS; auch bei tausend Anwendern sind die Datenbankdateien nur einmal geöffnet. Sie haben nun auf ziemlich pragmatische Weise die Struktur eines Client/ServerSystems (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 aktualisiert werden, so müssen alle Datensätze zum Client transportiert werden. Dort werden die Änderungen durchgeführt und anschließend müssen alle Datensätze wieder in die Datenbank auf den Server zurückgeschrieben werden.

Der Client schickt eine entsprechende Aktualisierungsnachricht an das DBMS. Dieses führt anschließend direkt die notwendigen Aktualisierungen in der Datenbank durch.

Grundlagen

17

File Sharing System

Client/Server System

In vielen Anwendungen hängt die Arbeitsgeschwindigkeit direkt von der Geschwindigkeit des DBMS ab. Daher muss jeder Arbeitsplatzrechner entsprechend leistungsfähig sein, damit das auf ihm laufende DBMS über genügend Ressourcen verfügen kann.

Der Server muss entsprechend leistungsfähig ausgelegt werden, damit das dort laufende DBMS die Anforderungen der Clients schnell genug abarbeiten kann. Die auf den Arbeitsstationen verfügbaren Ressourcen spielen (gäbe es nicht Windows) eigentlich keine Rolle mehr.

Wird die konkrete Anwendung zu langsam und liegt dies zum Beispiel an der Größe der Datenbank, so muss das DBMS und damit alle Arbeitsplatzrechner aufgerüstet werden.

In dem Fall muss lediglich der Server entsprechend 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 Client/Server-Technologie von Datenbanksystemen gepachtet ist. Dem ist natürlich nicht so, d.h. ein modernes leistungsfähiges DBMS ist nur ein Vertreter vieler anderer 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 kommunizieren 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öpfchenweise“ ankommen. Bei soviel offenkundiger Werbung für Client/Server möchte ich hier dennoch einmal 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 reibungslosen Betrieb notwendigen Strukturen fehlen. Hiermit meine ich vor allem vorhandenes 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 Erfahrungen damit gemacht, wenn im Rahmen irgendwelcher Softwareprojekte ein DBMS auf C/S-Basis eingeführt bzw. durchgesetzt wurde, dieses aber in der Softwarelandschaft 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.

18


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 normalen 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 Auswahlentscheidung noch immer so häufig aus einer Bierlaune heraus oder auf dem Tennisbzw. 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 Vorschlaghammer 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 Aufgabenstellungen sein.

1.1.2

Aufbau des Oracle-DBMS

Aufgrund des letzten Kapitels wissen Sie nun, dass Oracle zur Klasse der Client/Server-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-Datenbankadministratoren oder Sie schmökern einfach mal ein wenig in den per HTML gelieferten 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-Verzeichnis, 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ültigen 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 laufen haben. Das ist also genau so, als würden Sie Excel mehrfach starten und mit jeder Programmkopie genau eine Tabelle laden, wohingegen die definitionskonforme 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 reserviertem Hauptspeicher, der für alle diese Prozesse erreichbar ist. Dieser Hauptspeicherbereich 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 Hintergrundprozessen

Sofern es Sie interessiert, finden Sie in der folgenden Aufstellung eine grobe Beschreibung, welche Funktionen die einzelnen Systemprozesse erfüllen:

X

X X

DBWR (Database Writer) schreibt in der SGA modifizierte Datenblöcke zurück in die Datenbank. SMON (System Monitor) Überwacht die Wiederherstellung der Datenbank bei einem Neustart. Ferner registriert dieser Prozess freiwerdende Bereiche in der Datenbank und vereinfacht somit deren Wiederbelegung. LGWR (Log Writer) Schreibt die im Rahmen von Transaktionen anfallenden Protokollinformationen in die zugehörigen Plattenbereiche (Redo-Log-Einträge).

20

X X


CKPT (Checkpoint) Generiert die sogenannten Checkpoints, zu denen modifizierte Datenblöcke aus der SGA in die Datenbank zurückgeschrieben werden. 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

X X

Database Buffer Cache In diesem Speicherbereich werden die gerade benötigten Datenblöcke vorgehalten. Da üblicherweise nicht alle Daten gleichzeitig in diesen Puffer passen, findet 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. Redo Log Buffer Die während einer Transaktion anfallenden Protokollinformationen werden in diesem Puffer zwischengespeichert. 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. Ähnlich wie beim Database Buffer Cache wird auch dieser Bereich nach dem LRUAlgorithmus 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 OracleDokumentation 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 vorhanden Betriebssytem, denn beim Anlegen und Verwalten dieser Dateien muss sich natürlich auch das DBMS an die vorgegebenen Spielregeln des Betriebssystems halten. Konkret geht es hierbei beispielsweise um Namenskonventionen (Länge von Pfad- und Dateinamen, Sonderzeichen) oder eventuell vorhandene Größenbeschränkungen von einzelnen Dateien oder des definierten Filesystems (UNIX). Für uns als Anwender bildet die gesamte Datenbank eine logische Einheit. Physikalisch 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 sogenannten 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

Physische Dateien

Datei 1

Tablespace 2

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 Beispiel wird der Tablespace 2 durch zwei Dateien gebildet, die sogar auf unterschiedlichen Platten angelegt wurden. In diesen Tablespaces werden nun die benötigten Tabellen und anderen Datenbankobjekte (z.B. Indices) angelegt, d.h. es besteht beispielsweise 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.

22


Früher wurde viel mit diesen Optionen experimentiert, um das Antwortszeitverhalten 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, sondern ganzen Plattenstapeln (Disk-Arrays) zu tun. Hierdurch geht die direkte Kontrolle 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 physikalische Plattenstruktur durch ein darüber liegendes sogenanntes Filesystem zu verschleiern. Die zum Tablespace gehörenden Dateien werden dann in diesem Filesystem angelegt, also geht auch hierbei die direkte Kontrolle über die Plattenzuordnung verloren. Der dritte und wesentlichste Grund ist aber, dass sich die Aufwände dieser physikalischen 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 Speicherkonzept noch ordentlich laufen dürften. Zum anderen zeigt sich der Engpassfaktor oft gar nicht mehr in der Form der durchgeführten Datenzugriffe, sondern übertrieben 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

X

X

Viele Anwendungen definieren für die benötigten Indexdateien einen separaten 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. Logische Gesichtspunkte können für die Gestaltung der Tablespaces ausschlaggebend sein. Beispielsweise besteht die Anwendung aus mehreren verschiedenen 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 Produkte mal in eine eigene Datenbank umziehen müssen. Verteilen von Tabellen mit unterschiedlichem Wachstumsverhalten. Es kann durchaus sinnvoll sein, stark wachsende Tabellen von mehr oder weniger statischen Tabellen zu trennen. Es liegt irgendwie auf der Hand, dass der Verwal-

Grundlagen

X

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. 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 einbzw. 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 gespeichert. Dabei bildet beispielsweise jede Tabelle oder jeder Index ein eigenes Segment. Die Segmente selbst bestehen aus einem oder mehreren zusammenhängenden Datenblöcken (data block), wobei diese zusammenhängenden Blöcke mit dem Begriff Extend bezeichnet werden. Ein solcher Datenblock ist die kleinste Speichereinheit, 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

2. Extend

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

Tablespace

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

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

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 Anlegen 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 verweisen. Hier finden Sie weiterführende Informationen zum Beispiel im Buch

24


„Oracle8“. Folgen Sie dort dem Querverweis „Server Concepts“. Die Informationen finden Sie im Kapitel „Database Structure and Space Management“. In der 8i-Dokumentation 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 ziemlich am Anfang ein Kapitel über die Installation. Der Grund dafür ist ziemlich einfach: vielleicht haben Sie ja auch als klassischer Anwendungsentwickler oder Berater 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öllig aus, um darauf eine lauffähige Installation durchzuführen. Vielleicht besteht ja im Rahmen des aktuellen Projekts die Möglichkeit, eine Version 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, Einzelunternehmen 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 Konfigurationen 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

1.2.1

25

Der Installationsvorgang

Die primäre Installation der Software ist natürlich stark abhängig vom konkret eingesetzten 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 zwischen der Installation des Oracle-Servers und der benötigten Software für die einzelnen Arbeitsstationen unterscheiden. Manchmal liegen diese beiden Produktpakete 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 erfolgen, 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 CPINotebook 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 ordentlich. 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 veranlagte Platzbedarf. Die aktuelle 8i-Version beansprucht in der Standardinstallation 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 Programm 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 speziellen 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 Programm 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 Installationsprogramm 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 8iVersion im Assistentengewand vor.

26

1.2.2


Installation der Version 8

Nach kurzer Ladezeit des Installationsprogramms erhalten Sie eine kleine Dialogbox, 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önnen (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 einwandfrei, jedoch kann es bei anderen Anwendungen (z.B. PeopleSoft oder ODBC-Datenbankanwendungen) zu seltsamen Anomalien kommen, falls eine andere Sprache gewählt wurde. Dies äußert sich beispielsweise darin, dass Datums- oder Zahlenwerte 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-Homeverzeichnis 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 Installationen zu erstellen. In dem Fall existieren üblicherweise auch entsprechend viele Oracle-Homeverzeichnisse. Werden nun auf dem Server irgendwelche Anwendungen 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 Verzeichnisse) in der Windows-Registrierungsdatenbank gespeichert. Hier kann also jede Anwendung Informationen abrufen, die zur Ausführung von bestimmten Programmen oder zum Laden von DLLs gebraucht werden. Allerdings arbeitet nicht (oder noch nicht ?) jedes Programm auf diese Weise. Es gibt noch viele Anwendungen, die zum Laden solcher Bibliotheken Hilfestellung in Form von voreingestellten 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 Windows-Systemvariable path ein. Beenden Sie den Dialog mit No sofern Sie sicher sind, dass Sie keinen solchen Pfad-Eintrag brauchen bzw. Sie die notwendige Einstellung später selbst vornehmen wollen. Kleine Ursache – große Wirkung. Das gilt unter Umständen auch für diesen PfadEintrag. 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.

28


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 Servers und des Clients. Die nächste Option Oracle8 Client wird benötigt, wenn beispielsweise 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önnen, 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-Server im Übrigen zunächst einmal nicht anders, denn auch auf einem Server kann sich ein Anwender theoretisch anmelden und anschließend gewöhnliche Anwendungsprogramme 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 Datenbank“ 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 Nachhinein 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 erstellen 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 diesen letzten Dialog, wodurch der Oracle-Installer mit der eigentlichen Installationsarbeit beginnt. In unserem Fall werden hierbei nicht nur die benötigten Programme 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 Database 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 Installation quittiert.

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

30


Sollten Sie übrigens bei einer Erst- bzw. Vollinstallation Probleme haben, dann ist neben zu wenig Plattenplatz auch immer ein vorhergehender misslungener Installationsversuch 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 Windows-Registrierung erstellten Einträge. Interessant ist auch der Ausschnitt im mittleren 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, OracleStartORCL 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 entfernen. 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.

32


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 reibungslos, wie die vorhergehende Installation. Manchmal ist ein manueller Clean-Up notwendig; eine Kontrolle ist in jedem Falle empfehlenswert. Im Folgenden finden Sie einen möglichen Putzplan, um Ihre Oracle-Installation wieder zu entfernen:

X X X X X X X

Beenden und Deaktivieren Sie mit Hilfe der Systemsteuerung alle eventuell noch vorhandenen Oraclexxxx-Dienste. Löschen Sie alle installierten Komponenten mit Hilfe des Oracle-Installers. Löschen Sie, sofern noch vorhanden, das Oracle-Verzeichnis (z.B. C:\ORANT). Löschen Sie ggf. die noch vorhandenen Programmgruppen. 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. Auch die Einträge der Dienste müssen aus der Windows-Registrierung verschwunden sein oder ansonsten manuell von Ihnen gelöscht werden. Sie finden diese Einträge im Verzeichnis HKEY_LOCAL_MACHINE\SYSTEM\Services. Löschen Sie hier alle Einträge, die mit „Oracle“ beginnen. Starten Sie Ihren Rechner neu.

Bei Klementine war es nicht nur sauber, sondern immer rein. Bei der Registrierungsdatenbank 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 installierten 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 Abbildung 1.6 und dient im Wesentlichen wieder zur Festlegung des Installationsziels und zur Vorgabe des Standardverzeichnisses, das wieder mit der Umgebungsvariable 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 auszuwählen.

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

Ich wähle hier die erste Kategorie „Oracle8i Enterprise Edition“, um einen Datenbankserver mit allen benötigten Komponenten zu installieren. Danach geht es mit der Weiter-Schaltfläche zum nächsten Schritt, in dem die Installationsmethode ausgewählt werden muss. Dabei haben Sie wieder die Auswahl zwischen einer Standardmethode, einem etwas kleiner geschnürten Paketes und der individuellen Auswahl 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 Standardinstallationsmethode zu verwenden, so dass auch automatisch wieder eine Starterdatenbank angelegt 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 wechsele zum nächsten und letzten Dialog des Installationsassistenten, in dem Ihnen noch einmal das geplante Installationsszenario (vgl. Abb. 1.15) gezeigt wird.

34

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 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. 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

36

X


ihn auch beenden, für die Betriebsbereitschaft der Oracle-Datenbank spielt das keine Rolle. OracleTNSListener80 Wenn Sie das Grundlagen-Kapitel vollständig gelesen haben, dann erinnern Sie sich vielleicht an den schematischen Aufbau eines Client/Server-Systems (Abbildung 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 permanent Ressourcen geklaut werden, obwohl ich gerade gar keine Datenbank brauche, weil ich vielleicht nur einen Brief schreibe. Oder von allen installierten Datenbanken 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. Beachten 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 Windows-Systemsteuerung aktivieren; die Reihenfolge in der Sie die einzelnen Dienste aktivieren ist dabei gleichgültig. Wenn Sie beispielsweise zuerst den Dienst OracleStartORCL starten, dann werden Sie feststellen, dass diese Aktion im Hintergrund auch den Start des Dienstes OracleServiceORCL und damit das Hochfahren der zugehö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 standardmäßig die Möglichkeit, sich einen solchen Diener zu basteln. Mit Hilfe des NETKommandos 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

rem rem net net net

37

Starten des Listeners, Starten der Oracle-Instanz ORCLÖffnen der Datenbank start OracleTNSListener80 start OracleStartORCL 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 net net net

Stoppen des Listeners, Stoppen der Datenbank ORCL stop OracleTNSListener80 stop OracleStartORcL 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 Datenbankdiensten entsprechende Skripte erstellen. Wenn Sie bei deren Ausführung versuchen 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


Die Installation einer Oracle-Datenbank läuft dank der mitgelieferten Installationsprogramme 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 inneren vielleicht den Wunsch, selbständig eine eigene Datenbank zu erstellen. Aufgrund 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 Problemen 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

38


notwendig ist, damit Sie zum einen wissen worum es überhaupt geht und zum anderen 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. Vielmehr 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 physischen Gegebenheiten, über Net8 an. Das Gleiche gilt auch, wenn das Anwendungsprogramm Daten versenden will oder auf den Empfang von Daten vom Server wartet. 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.


39

Für uns Nichtnetzwerker hat Net8 den Nachteil, dass wir selbst bei der Installation einer kleinen Spiel- oder Übungsdatenbank bestimmte Konfigurationseinstellungen 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

X

X

X

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-ProtokollAdapters warten. Weder Ihre Anwendung noch der Oracle-Server selbst müssen in irgendeiner Form angepasst werden. Was bei einfachen Strukturen vielleicht ein wenig kopflastig erscheint, zeigt seine wahren Stärken erst bei komplexeren Netzwerken. Stellen wir uns hierzu zwei Datenbanken, eine auf einem NT- und die andere auf einem NOVELL-Server 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 Netzwerkprotokolle oder einer Server/Server-Verbindung wesentlich vereinfacht. Die genaue Arbeitsweise der Verbindungsschicht zwischen Anwendung und DBMS wird mit Hilfe von Konfigurationsdateien gesteuert. Bei einem Versionswechsel müssen Sie in der Regel daher lediglich die entsprechenden Programme und Bibliotheken austauschen. Die alten Konfigurationsdateien bilden anschließend zusammen mit der neuen SQL*Net-Version wieder genau das gleiche logische Oracle-Netzwerk wie vorher ab. Dieser Vorteil gilt im Übrigen auch, wenn Sie mit verschiedenen SQL*Net bzw. Net8-Versionen parallel arbeiten müssen. Immerhin gibt es noch reichlich klassische (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 nebeneinander, wobei Sie die Net-Konfigurationsdateien für beide Installationen verwenden können. Die Net8-Architektur vereinfacht die Bereitstellung zentraler Hilfsmittel, beispielsweise zur Fehleranalyse oder zur Verschlüsselung der übermittelten Daten. Ein entsprechend benötigter Service wird einfach in der zughörigen Konfigurationsdatei einbzw. ausgeschaltet. Bleiben wir mal bei der Verschlüsselung der übermittelten Daten: Wird eine solche Option gewählt, dann gilt sie automatisch für alle eingesetzten Anwendungsprogramme, ohne das in diesen irgendetwas geändert oder angepasst werden muss.

Bei der Verbindungsanforderung von einem Anwendungsprogramm zum OracleDBMS 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 Listener-Prozess, den Sie bei einer standardmäßigen NT-Installation als Dienst OracleTNSListener80 kennen gelernt haben. Dieser Dienst hört permanent das Netzwerk ab und dient quasi als zentrale Empfangsstation aller eingehenden Verbindungsanfragen.

40


Wie schon gesagt, kann der genaue Name dieses Dienstes variieren, d.h. der standardmäßig vergebene Name hängt von der verwendeten Version und Ihren Installationsvorgaben 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) durcheinander 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 Netzwerke, 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 Net8Konfiguration und Möglichkeiten finden Sie natürlich wieder in der Oracle-Dokumentation, und zwar im Buch „Oracle8 Networking“ bzw. „Oracle8i Server Networking“.

1.4.2

Verbindung zur „ Starterdatenbank““ herstellen

Nun geht es endlich los, wir kümmern uns um die Verbindung zu unserer Starterdatenbank. 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 entsprechenden 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 finden. 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


41

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 beispielsweise 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 LISTENER.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 IPAdresse stehen) die Ports 1521 und 1526 überwacht: LISTENER = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= TCP) (Host= ray_dell) (Port= 1521) ) (ADDRESS= (PROTOCOL= TCP) (Host= ray_dell) (Port= 1526) ) ) 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 eintragen:

42


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 Instanzenaufzählung im Wesentlichen aus der Benennung des Datenbanknamens nebst zugehöriger Instanzbezeichnung (SID). Für die Starterdatenbank war der Datenbankname 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 Verweis auf die Dokumentation) die Protokollfunktion des Listeners einbzw. ausschalten 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 Einstellungen in der Datei LISTENER.ORA finden Sie wie immer in der Oracle-Dokumentation, 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 prinzipiell zu tun ist, wenn Sie einen weiteren Listenerprozess installieren möchten oder wenn aus irgendwelchen Gründen während der Installation kein passender Windows-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 Programm 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.


43

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

Das Programm bietet Ihnen eine ganze Reihe von Möglichkeiten, wobei Sie vorhandene 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 Listener heißt LISTENER.ORA, und dort wurde durch Eintrag LISTENER= der Name des Listeners festgelegt. Bei mehreren Listener existieren in dieser Datei auch entsprechend viele Einträge (z.B. LISTENER01= usw.). Durch die Eingabe des Befehls „start listener“ können Sie also den in der Datei definierten Listener starten. Hierdurch erhalten Sie beispielsweise auch einen verlorengegangenen Windows-Dienst zurück.

stop <listener>

stoppt den angegebenen Listener-Prozess.

status <listener>

zeigt den aktuellen Status des vorgegebenen Listeners am Bildschirm an.

reload <listener>

aktiviert eine geänderte Listenerkonfiguration.

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-

44


tere Net8-Clients (z.B. 16-Bit Windows) installiert wurden, d.h. in den Fällen müssen 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 funktionsfähige Client-Konfiguration vorliegen. Grundeinstellungen via SQLNET.ORA Mit Hilfe der Konfigurationsdatei SQLNET.ORA können Sie ein sogenanntes Profil erstellen, mit dem Sie verschiedene 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 überhaupt keine solcher Voreinstellungen gibt. Meistens werden Sie bei der Begutachtung vorhandener Installationen allerdings ein definiertes Profil in Form der Datei SQLNET.ORA finden.

Im Einzelnen können Sie mit Hilfe des Profils

X X X X

Parameter zur Namensgebung, Verschlüsselungseinstellungen, Sicherheitseinstellungen, Trace- und oder Log-Einstellungen

und viele weitere Parameter festlegen. Für kleine Installation können Sie die während der Installation als Muster kopierte Version ohne Änderungen verwenden und selbst bei riesigen Netzwerken gibt es keinen zwingenden Grund für irgendwelche Eingriffe. Beachten Sie allerdings die fett markierte Einstellung des Parameters 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


45

Alle verfügbaren Parameter finden Sie mit einer ausführlichen Beschreibung wieder im „Net8 Administrator’s Guide“ der Oracle-Dokumentation und dort je nach Version 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 „Understanding 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 Werkzeuge, 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 Datenbank, die auf irgendeinem Rechner verfügbar ist. Auf dem Client wird die Verbindung 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 Datenbankinstanz TT23 mit der Datenbank AUSKUNFT auf einem Rechner mit der IP-Adresse 1.33.133.8 anmelden. Diese Verbindung zwischen den Dienstnamen und irgendwelchen 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

46


In dem Beispiel wird der Dienstname GutenMorgen definiert und mit der DBMSInstanz 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 = (ADDRESS = (PROTOCOL = TCP) (HOST = ray_dell) (PORT = 1521) ) (CONNECT_DATA = (SID = ORCL) ) )

names.default_domain = world

SQLNET.ORA

LISTENER.ORA LISTENER = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= TCP) (Host= ray_dell) (Port= 1521) ) ) 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 Wochentag 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 Konfigurationsdateien. 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 X X

X

X

X X X X

47

Kopieren Sie die drei Dateien in das \NET80\ADMIN- bzw. \NETWORK\ ADMIN-Verzeichnis auf dem Datenbankserver. In der Datei SQLNET.ORA müssen Sie keine Anpassungen vornehmen. Beenden Sie alle laufenden Listenerdienste. 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 ipconfig /all (verwenden Sie ipconfig /all | more, wenn Sie nicht alles lesen können) ein.

–

Notieren bzw. merken Sie sich den Rechnernamen und die IP-Adresse.

Öffnen Sie auf dem Client ein MS-DOS-Fenster und überprüfen Sie die Netzwerkkonfiguration. Geben Sie den Befehl ping gefolgt von dem eben ermittelten Rechnernamen (z.B. ping ray_dell) ein. Erhalten Sie über den Rechnernamen keinen Kontakt zum Server, dann müssen Sie in den folgenden Arbeitsschritten statt des Namens die zugehörige IP-Adresse verwenden. 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-Adresse aus. Starten Sie die Listener, indem Sie den zugehörigen Dienst wieder aktivieren. Editieren Sie die Datei TNSNAMES.ORA. Vorausschauend auf die noch zu erstellende Datenbank finden Sie auch hier schon zwei Diensteinträge (orcl.world und db01.world). Tauschen Sie jetzt den Namen ray_dell wieder gegen Ihren Servernamen bzw. dessen IP-Adresse aus. Kopieren Sie die Dateien SQLNET.ORA und TNSNAMES.ORA auf einen Client in das entsprechende \NExx\ADMIN-Unterverzeichnis. Testen Sie Ihre Konfiguration. Öffnen Sie hierzu auf dem Client ein MS-DOSFenster Starten Sie das Programm TNSPING80 bzw. TNSPING (bei korrekter Installation sollte ein Pfad-Eintrag auf das \BIN-Unterverzeichnis existieren) gefolgt 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 Eingabe des Dienstnamens orcl intern immer zur Verwendung des Dienstes orcl.world.

48


Abbildung 1.21: Erfolgreicher Ping zu unserer ORCL- Instanz

Verläuft der Test nicht erfolgreich, so überprüfen Sie noch einmal alle durchgeführten Arbeitsschritte. Haben Sie die Dateien an die richtigen Stellen kopiert? Überprü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 Fehlermeldungen. Neben den Beschreibungen befinden sich hier größtenteils auch brauchbare Kochrezepte zu deren Behebung. Die TNS-Fehlermeldungen stehen dort konkret im Kapitel 25. Natürlich ist es nicht unbedingt notwendig, die Anpassungen an der Net8-Konfiguration manuell durchzuführen. Aber wie Sie an den letzten Beispielen gesehen haben, ist das bei kleinen TCP/IP-Netzwerken durchaus möglich bzw. nicht schwierig. 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.


49

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 JavaApplikation 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 Datenbankdienst 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 verschiedenen 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-Konfiguration 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önnen. Rechts unten im Bild finden Sie eine Liste aller aktuell definierten Dienstnamen.

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 entfernen. 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).

50


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ürfnissen 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 NextSchaltfläche zu weiteren Dialogen zum Bearbeiten der verschiedenen Diensteinstellungen. Im ersten Seite dieser Dialogfolge müssen Sie das zu verwendende Netzwerkprotokoll 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 Netzwerkprotokolls 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 verwendenden 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 eingeben (vgl. Abb. 1.25). Mit Hilfe der nächsten und letzten Seite können Sie Ihren neuen Diensteintrag testen. 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 Passwort 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.


51

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 entsprechenden Eingabefeldes festlegen müssen.

52


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. Allerdings 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-Protokolls 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 Profileinstellungen 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 bearbeiten, 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 diesen Namen wählen können. Auf der nun folgenden Seite können Sie die gewünschten Netzwerkprotokolle auswählen (vgl. Abb. 1.27) und in den darauffolgenden Seiten müssen Sie je nach ausgewähltem Protokoll weitere Einstellungen, beispielsweise die Port-Nummer bei TCP, vornehmen.


53

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 NTArbeitsplatzrechnern 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 Konfigurationsdateien 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“ markieren. Dieses Programm ist bei den Versionen 8 bzw. 8i im Übrigen nahezu funktionskompatibel 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.

54

Abbildung 1.28: Profilerstellung mit Hilfe des Oracle Net8 Assistant

Abbildung 1.29: Oracle Net8 Assistant in der 8i-Version



55

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 Service- 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&EasyProgramm ist auch, dass Sie mit Hilfe des Oracle Net8 Assistant Konfigurationsdateien in jedem erreichbaren Verzeichnis bearbeiten können. Standardmäßig öffnet das Programm die im Verzeichnis \NETxx\ADMIN gespeicherten Konfigurationen, allerdings können Sie mit Hilfe der File- bzw. Datei-Menüeintrage das aktuelle Verzeichnis wechseln oder geladene Konfigurationen in einem anderen Verzeichnis speichern bzw. von dort laden. Im weiteren Verlauf dieses Kapitels soll nun zum wiederholten Male eine Verbindung zu unserer Starterdatenbank hergestellt werden, wobei diesmal logischerweise 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 einmal 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 oberhalb 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 Filebzw. 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).

56


Abbildung 1.30: Bearbeiten der Dienstnamen mit dem Net8-Assistenten

Abbildung 1.31: Bearbeiten der Dienstnamen mit dem Net8-Assistenten unter 8i


57

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 Konfigurationseinstellungen vorzunehmen. Wählen Sie mit Hilfe des Kombinationsfeldes zunächst den Dialog „Listening Locations“ 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 lauschen lassen. Für diesen zweiten Port müssen Sie ebenfalls ein zweites Registerkärtchen anlegen, indem Sie den zweiten Port 1526 eintragen.

Abbildung 1.33: Abhördienste des neuen Listeners konfigurieren

58


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 Kombinationsfeld 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

59

60


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. DateiMenüs speichern, wodurch die Konfigurationsdateien in dem gewählten Verzeichnis 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 Konfiguration 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 durchgefü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 verbindet, 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 Datenbanknamen 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 Minimalnamensdienst zur Verfügung. Tragen Sie in der Datei die IP-Adresse des Datenbankservers


61

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 mehrere 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 zentraler 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 dynamischen 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

X

Verbindungsbündelung Der Connection Manager ermöglicht die logische Zusammenfassung der Verbindungen 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 Performance gesteigert werden. Zugriffskontrolle Durch die Definition verschiedener Regeln besteht die Möglichkeit zu definieren, unter welchen Bedingungen ein Client auf einen Server bzw. eine Datenbank 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 herzustellen. 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 explizit zugelassene Clients eine Verbindung aufnehmen können.

62

1.5


Erstellen einer Datenbank

In diesem Kapitel möchte ich Ihnen zeigen, wie man in Oracle eigene Datenbanken 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 Vorgehensweise 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 Aufgabenzettel. Konkret gibt es für die Anlage einer DBMS-Instanz und der Erstellung der Datenbank wie immer mehrere verschiedene Verfahrensweisen; die Bandbreite der möglichen Wege reicht je nach verwendetem Betriebssystem von „do it yourself“ bis hin zur völlig automatischen Datenbankgenerierung. Dabei werde ich das vollautomatische 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 Verfahrenspraxis. 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 wiederholbar 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 Assistenten 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 DBMSInstanz und den eigentlichen Datenbankdateien gebildet. Diese Instanz vereint alle für den Betrieb der Datenbank benötigten Prozesse nebst Hauptspeicherbereiche 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


63

dem Namen INITSID.ORA, wobei Sie den Platzhalter SID durch den konkreten System-Identifer des DBMS ersetzen müssen. Wenn Sie die Starterdatenbank (SID=orcl) installiert haben, dann finden Sie in Ihrem \DATABASE-Unterverzeichnis 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 automatisch erzeugt. Zusätzlich benötigt die Datenbank mindestens zwei Protokolldateien. Oftmals werden Sie in dem Zusammenhang die Bezeichnungen „redo log“ oder „redo log Dateien“ finden. Diese Log-Dateien werden benötigt, um die Datenbank beispielsweise nach einem Systemzusammenbruch (Server wird ausgeschaltet) wiederherzustellen. 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 vielleicht 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 Vollsicherung erstellt wurden, dann könnte man sich einen Wiederherstellungsprozess bis zu jedem beliebigen nachfolgenden Zeitpunkt vorstellen, denn wie gesagt, die LogDateien 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 mindestens 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

64


ich Ihnen neben den originalen Handbüchern ein Buch, das sich hauptsächlich mit Themen aus dem Alltag eines Datenbankadministrators beschäftigt. Dort sollten 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 gespeichert. 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 unterschiedlichen Festplatten gespeichert werden sollen. Mehr zum Umgang mit diesen Kontrolldateien finden Sie in der Oracle-Dokumentation, beispielsweise im Buch „Server Administrator’s Guide” im Kapitel „Managing Control Files”.

DBMS SID = DB01

TABLESPACE SYSTEM

Konfguration (INITDB01.ORA)

ROLLBACK SYSTEM

Datei (datafile)

Log-Datei (redo log)

Kontrolldatei (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 Transaktion, dem Recovery beim Öffnen der Datenbank oder auch für die Bereitstellung lesekonsistenter Abfragen benötigt. Oracle zeigt geänderte Daten erst nach dem


65

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-Segment 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 Mehrbenutzerbetrieb viele Transaktionen um die Gunst bzw. den Platz der Rollback-Segmente ringen. Die Segmente selbst ringen ggf. konkurrierend mit anderen Objekten 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 kennen, 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 Schritten:

X

X X X

Erstellen der Konfigurationsdatei INITxxxx.ORA entsprechend dem gewünschten System Identifer. Erstellen der neuen Datenbankinstanz. Anlegen der neuen Datenbank. Abspielen verschiedener Standardskripte, die in der neuen (noch leeren) Datenbank 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 Datenbankdateien, notwendig, was aber genau genommen mit der eigentlichen Datenbankerzeugung gar nichts zu tun hat. Im Folgenden wollen wir die Datenbankinstanz „db01“ und die zugehörige Datenbank „datenb01“ erstellen. Alle hierzu benötigten Dateien und Skripte finden Sie auf der Begleit-CD im \DB01-Unterverzeichnis.

66


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 Konfigurationsdatei der Starterdatenbank als Muster verwenden können. Diese Musterdatei besteht hauptsächlich aus Kommentaren, denn neben den wirklichen Anmerkungen in der Datei sind auch die meisten Parameter mit Hilfe des Gatterzeichens (#) auskommentiert. Trotzdem erhalten Sie hierdurch eine Vorstellung ü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 Beschreibung. Im „Server Administrator’s Guide“ finden Sie im Abschnitt „Chapter 2 Creating 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\DATABASE\db01\ctl2db01.ora) remote_login_passwordfile = shared #rollback_segments = (RB0, RB1) Listing 1.7: Minimum einer Instanz-Konfiguration

X

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 Unterstrich (_). Zwischen Groß- und Kleinschreibung wird nicht unterschieden. Der hier spezifizierte Name muss auch beim späteren Anlegen der Datenbank verwendet werden. db_files Maximale Anzahl der möglichen Datenbankdateien. Sowohl der Standard- als auch der Maximalwert für dieses Parameter ist abhängig vom vorhandenen Betriebssystem. 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

X

X

67

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 Dateinamen hängt natürlich vom jeweiligen Betriebssystem ab. 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 entsprechenden Instanz darstellt. Mehr zum Thema der Identifizierung von Administratoren finden Sie in den Oracle-Unterlagen im Buch „Server Administrator's Guide”, beispielsweise im Kapitel „The Oracle Database Administrator“. rollback_segments Mit dem Parameter legen Sie die zu verwendenden Rollback-Segmente fest. Dies ist wichtig, wenn Sie neben dem SYSTEM-Tablespace weitere Bereiche definieren und verwenden möchten. Da diese Rollback-Segmente beim Anlegen der Datenbank jedoch noch nicht definiert sind, ist es wichtig den Parameter zunächst einmal auszukommentieren. Schalten Sie ihn erst ein, nachdem die gesamte 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 Vergleich 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 Datenbankinstanz verwendet wird, sofern in der Konfigurationsdatei nichts anderes spezifiziert 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äufiger Datenbanken erstellen müssen. Auf der anderen Seite möchte ich hier natürlich 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 zusammen mit allen benötigten Parametern starten:

68


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 ansonsten allerdings völlig identisch verwendet.

X X

X

X

X

SID System Identifer der neuen Instanz. Entsprechend dem hinteren Teil der Konfigurationsdatei müssen Sie in unserem Beispiel „db01“ als SID vorgeben. INTERNAL_PWD Passwort für die Administrator-ID „internal“. Während der Anlage der neuen Datenbankinstanz wird hierfür eine Passwortdatei angelegt. Diese Datei befindet sich im \DATABASE-Unterverzeichnis und hat den Namen PWDSID.ORA, wobei SID wieder durch den konkreten System Identifer ersetzt wird. SRVCNAME Wie Sie schon wissen, besteht unter Windows-NT die Möglichkeit, die Datenbankinstanz 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. AUTO, MANUAL Legt die Startart des neuen Dienstes fest. Auf einem echten Datenbankserver wäre „AUTO“ wahrscheinlich die richtige Wahl. Auf meinem NT-Notebook gefä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. 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 Konfigurationsdatei 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 Passwortdatei an. Eventuelle Fehler oder Erfolgsmeldungen müssen Sie der zugehörigen LogDatei ORADIMxx.LOG entnehmen, die Sie standardmäßig im \RDBMSxx-Unterverzeichnis finden. Sofern beim Programmaufruf und in der Konfigurationsdatei


69

keine Tippfehler vorliegen, dann sollten Sie in der Log-Datei lediglich eine Erfolgsmeldung ü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 Systemsteuerung durchführen, aber da wir gerade im MS-DOS-Fenster sind, erledigen wir es durch einen erneuten Aufruf des Instanzen-Managers mit folgenden Parametern: 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 Parameters starttype legen Sie fest, ob das Programm den Service (srvc), die Datenbankinstanz (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“ nachschlagen. 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 erhalten Sie im Rahmen der Installation verschiedene Werkzeuge, sogenannte SQL-Editoren wie beispielsweise SQL*Plus oder das SQL-Worksheet. Da wir zur Zeit aber lediglich ein Halbfertigprodukt besitzen, benötigen wir einen besonders systemnahen 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-

70


ver gestartet werden muss. Die Vorgabe, mit welcher Datenbankinstanz sich der Server-Manager beim Start verbinden soll, erfolgt mit Hilfe einer Umgebungsvariablen 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 SETKommando 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 Eingabetaste erhalten Sie hier keine zweite Zeile, sondern der Server-Manager beginnt sofort mit der Verarbeitung Ihrer Eingabe. Am besten verwenden Sie am Eingabeprompt des Server-Managers lediglich folgende zwei Befehle:


X X

71

Exit Beendet den Server-Manager, d.h. Sie kehren zum MS-DOS-Eingabefenster zurück. @ 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 jedem beliebigen Texteditor erstellen, so dass Sie die benötigten Befehle wenigstens entsprechend komfortabel erfassen bzw. bearbeiten können. Noch besser ist vielleicht sogar, Sie verwenden den Server-Manager überhaupt 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 verwenden, 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.

72


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 Datenbank 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 Benutzerdaten und weitere Rollback-Segmente (ebenfalls mit eigenem Tablespace) haben. Zumindest für die erste der beiden Aufgaben, dem Anlegen der benötigten Systemobjekte, liefert Oracle zwei Standardskripte, die Sie im \RDBMSxx-Unterverzeichnis finden. Es handelt sich hierbei um die Dateien CATALOG.SQL und CATPROC.SQL. In der ersten Datei werden mit Hilfe entsprechender SQL-Kommandos 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 Programmgruppe „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.


73

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-Systemumgebung aufräumt und beispielsweise die zugehörigen Dienste löscht.

Abbildung 1.39: Der Oracle Database Assistant

Abbildung 1.40: Datenbank-Konfigurationsassistent unter 8i

74


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“ weiter zur zweiten Seite des Assistenten. Dort haben Sie die Wahl zwischen einer Standardgenerierung 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 dritten Seite können Sie die Installation verschiedener Zusatzpakete veranlassen, allerdings wird die Auswahl nur angeboten, wenn Sie die zugehörigen Features im Rahmen 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 unserer Konfigurationsdatei hatten wir hierfür überhaupt keine Parameter explizit vorgegeben, 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.


75

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 Speichern von SQL-Programmen herangezogen. Von hier ab laufen die Bilder des 8erund 8i-Assistenten allerdings zunächst einmal auseinander. Die Auswahl des Zeichensatzes 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 European“ 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 überprü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.

76


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, nachdem 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 anderes ein, um anschließend auf die nächste Seite wechseln zu können.


77

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

78


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 Tablespace 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 weiteres 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 fortfahren. 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önnen Sie verschiedene Einstellungen vornehmen, die zu entsprechenden Parametern 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 Parameter log_archive_start = true vorgeben.


79

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 Konfigurationsdatei und wechseln Sie zur nächsten Seite des Datenbankassistenten.

80


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


81

Mit Hilfe des ersten Feldes („Shared Pool Size“ bzw. „gemeinsamer Pool“) bestimmen 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 Speicher 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 einbzw. 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 Blockes 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 Standardwert 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 zugehö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 Benutzerprozessen 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 festgelegt 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.

82


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 endlich 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) enthä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


83

Das erste Skript enthält den create database-Befehl, den wir ebenfalls schon ausgeführt hatten. Das zweite und die eventuell folgenden Skripte vereinen alle notwendigen Schritte, um die bisherige Rudimentärdatenbank fertigzustellen. Auf Ihrer Begleit-CD finden Sie die vom Assistenten erstellte Konfigurationsdatei im \DB01Unterverzeichnis unter dem Namen INITDB01A.ORA. Sie können die DB01Instanz 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 folgenden 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 DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1 MAXEXTENTS 300 PCTINCREASE 1);

5. REM **************TABLESPACE FOR USER********************* CREATE TABLESPACE USR DATAFILE 'E:\ORANT\database\db01\Usr1db01.ora' SIZE 3M DEFAULT STORAGE ( INITIAL 50K NEXT 50K MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 1); 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*********************

84


CREATE TABLESPACE INDX DATAFILE 'E:\ORANT\database\db01\Indx1db01.ora' SIZE 10M DEFAULT STORAGE ( INITIAL 50K NEXT 50K MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 1); 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 Gegebenheiten 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ührung können Sie die verschiedenen Aktionen am Bildschirm mitverfolgen, zumindest 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 verschiedenen Passagen des SQL-Skripts. Die im Listing abgedruckten Nummern sind in der Originaldatei natürlich nicht enthalten. Außerdem finden Sie weitergehende Informationen zu den einzelnen Befehlen entweder am Ende des Kapitels „5. Datenbankprogrammierung“ 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 eingeschaltet, damit es anschließend beliebig wachsen kann.


85

2. Im SYSTEM-Tablespace wird ein weiteres Rollback-Segment angelegt. Dieses Rollback-Segment ist von der Größe her so dimensioniert, dass alle nachfolgenden Statements ausgeführt werden können. Anschließend wird das RollbackSegment aktiviert und danach werden nacheinander die beiden Skripte CATALOG.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 angepasst. 5. Ähnlich wie im Punkt 3 werden die Tablespaces USR, TEMPORY und INDX mitsamt den Dateien USRLDB01.ORA, TMP1DB01.ORA und INDX1DB01.ORA entsprechend den im Assistenten gemachten Vorgaben angelegt. 6. Es werden zwei neue Rollback-Segmente RB0 und RB1 im RBS-Tablespace angelegt und anschließend aktiviert. Beachten Sie nochmals, dass Sie die Verwendung 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-Tablespace-Zuordnungen geändert. Anschließend wird das am Anfang angelegte Rollback-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 Zusatzoptionen 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 generieren und unter NT vielleicht auch automatisch abzuspielen.

86

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 vorhandene 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 Programms 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 Ergebnis erhalten Sie ein kleines Programmfenster, in dem alle auf dem Rechner vorhandenen 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 folgenden 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 Generierung 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-Schaltflä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 abzuspielen. Dieses Skript wurde während der Generierung erstellt und enthält im Wesentlichen 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


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 üblicherweise 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.

88


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 DB01Datenbankinstanz. Einen Nachteil hat das Ganze natürlich: sobald Sie das MSDOS-Fenster schließen oder dort irgendeine Taste drücken, ist die Datenbankinstanz 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 X X

-startup Der Schalter gibt an, dass ORADIM eine Datenbankinstanz auf Ihrem Rechner (im Hintergrund) starten soll. -sid Verwenden Sie den Schalter zusammen mit dem System Identifer derjenigen Instanz, die Sie auf dem Rechner starten wollen. -starttype srvc Mit Hilfe dieses Schalters müssen Sie festlegen, wie die Datenbankinstanz gestartet werden soll. Wie Sie noch sehen werden, stehen Ihnen hierbei verschiedene Varianten zu Verfügung. Der Wert srvc führt zum Starten der Datenbankinstanz.


89

Nach Eingabe des eben beschriebenen Befehls sollte die Prozess-Liste Ihres Windows 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-Unterverzeichnis Ihrer Oracle-Installation finden. Übrigens eignet sich ORADIM auch zum Beenden einer laufenden Instanz. In dem Fall müssen Sie das Programm folgendermaßen aufrufen: oradim80 -shutdown -sid db01 -shuttype srvc -shutmode N oradim -shutdown -sid db01 -shuttype srvc -shutmode N

X X X X

-shutdown legt fest, dass Sie eine Datenbankinstanz beenden möchten. -sid identifiziert die zu schließende Instanz, d.h. geben Sie hier den zugehörigen System Identifer ein. -shuttype Verwenden Sie srvc, um die Datenbankinstanz zu beenden. -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, weshalb 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 Hochfahren der Datenbank zur Folge hat. Eine vollständige Übersicht aller vorhandenen Parameter und Schalter des Programms 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 Diensteintrag, doch wie funktioniert das Verfahren ohne Dienste bzw. unter anderen Betriebssytemen?

90


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 starten, 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 Datenbank mit Hilfe des startup-Befehls und der Vorgabe der zugehörigen Konfigurationsdatei 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 shutdownBefehls, d.h. Sie können diesen Teil der Anweisung auch weglassen. Falls Sie wissen, 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 beispielsweise 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 Programm 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 Kennwort für den Internal-Benutzer und den Pfad und Namen der Konfigurationsdatei vorzugeben.


91

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 speziellen Befehle (z.B. drop database) notwenig, da die zu löschende Datenbank ja nicht in irgendeiner Systemdatenbank des DBMS eingetragen ist, sondern zusammen 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 folgende Holzhammermethode zum Entfernen einer Oracle-Datenbank denkbar:

X X X

Beenden Sie den zugehörigen ORACLE-Hintergrundprozess, beispielsweise durch ein entsprechendes KILL-Kommando (z.B. UNIX) oder indem Sie das Programm unter Windows mit Hilfe des Task-Managers aus der Prozessliste schmeißen. Entfernen Sie den Aufruf der Datenbank aus allen Startup- bzw. Boot-Skripten. Löschen Sie unter NT in der Registrierung alle eventuell vorhandenen Diensteinträge. Löschen Sie alle zugehörigen Dateien (Daten-, Log-, Kontroll- und Konfigurationsdateien).

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 daneben gegriffen und beispielsweise den falschen Prozess abgewürgt oder in der Registrierung 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 Hilfestellung. Zunächst einmal sollten Sie sich einen Überblick über die vorhandene Dateistruktur der Datenbank machen. Identifizieren Sie zunächst die verwendete Konfigurationsdatei, denn in ihr finden Sie einen Verweis auf die zur Datenbank gehörenden Kontrolldateien: control_files = (E:\ORANT\DATABASE\db01\ctl1db01.ora,E:\ORANT\DATABASE\db01\ctl2db01.ora)

Führen Sie mit Hilfe eines SQL-Editors, beispeilsweise dem Server-Manager, folgende 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

92


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 Kapiteln 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 wieder 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 Programm 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-Segmente 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 automatisch generieren kann, indem nach dem Erstellskript einfach auch alle Änderungsskripts nacheinander eingespielt werden. Wie Sie im letzten Kapitel erfahren haben, ist aber nicht nur die Erstellung der Speicherobjekte via SQL möglich, sondern auch die Abfrage der vorhandenen Objekte mitsamt ihren Eigenschaften ist mit Hilfe spezieller Views möglich. Sofern Sie allerdings 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, funktionieren sehr ähnlich, unterscheiden sich aber durch ein jeweils spezielles Einsatzgebiet. 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 vorhandenen Eigenschaften des markierten Objekts betrachten oder ändern können.

94


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 Trainerqualitä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 eigentlich 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 Protokoll-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örigen 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-Managers 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 stehen. Konkret verbergen sich die Storage-Funktionalitäten unter dem Eintrag „Speicher“ 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 Bedingung 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 Studio in Bezug auf das Speichermanagement alle Funktionen wieder, die Ihnen bisher vom Storage Manager geboten wurden. So richtig neu ist eigentlich nur die Artund 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 Aufzeichnungen 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), oftmals ein Werkzeug, mit dem man SQL-Befehle abschicken und die entsprechenden

96


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-Programmen 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önnen, meine ich hiermit das Programm SQL*Plus, das je nach Betriebssystem und Installation als PLUS80.EXE, PLUS80W.EXE, SQLPLUSW.EXE oder lediglich SQLPLUS 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 beschriebenen 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 Telnet-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 ClientInstallation. 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 sicherlich 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 8iClient 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öglichkeiten“. Das Thema SQL*Plus ist so umfangreich, dass es hierzu in der OracleDokumentation sogar ein eigenes Buch „SQL*Plus User’s Guide and Reference“ gibt. Dort finden Sie in dem Kapitel „Command Reference” eine vollständige Übersicht der vorhandenen Befehle mit vielen Beispielen. Ich möchte im Rahmen dieses 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 Eingaben an die Datenbank geschickt. Um die Eingabe abzuschließen haben Sie verschiedene Möglichkeiten:

98

X X


Sie beenden die Zeile mit einem Semikolon (;) und drücken danach die Eingabetaste. Hierdurch werden die im SQL-Puffer gespeicherten Befehle sofort an die Datenbank gesendet. Sie betätigen die Eingabetaste zweimal hintereinander. SQL*Plus beendet nämlich das Füllen des Puffers, wenn Sie in einer Leerzeile die Eingabetaste verwenden. 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 willkommen 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

fügt den spezifizierten Text am Ende der aktuellen Zeile an, vgl. auch Hinweise zu l .

c //

ändert in der aktuellen Zeile den Text in den Text , z.B. c / fromm/from, um „fromm“ in „from“ zu ändern.

c /

löscht den Text aus der aktuellen Zeile.

cl buff

löscht den SQL-Puffer.

del

löscht die aktuelle Zeile, vgl. zu l .

del

löscht die Zeile aus dem SQL-Puffer.

del *

löscht den Puffer von der Zeile bis zur aktuellen Zeile.

del <m>

löscht die Zeilen bis <m> aus dem Puffer.

edit

ruft den per define_editor definierten Texteditor auf (vgl. nächsten Abschnitt).

exec

startet den im Puffer befindlichen PL/SQL-Block.

i

fügt weitere Zeilen hinter der aktuellen Zeile des SQL-Puffers ein.

i

fügt eine Zeile hinter der aktuellen Zeile eine neue mit dem Inhalt ein.

l

führt zur Anzeige des SQL-Puffers

l

zeigt die Zeile des SQL-Puffers an und macht diese zur aktuellen Zeile.

l *

zeigt den Puffer von der Zeile bis zu aktuellen Zeile.

l <m>

listet die Zeilen 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, zwischenspeichern und zur weiteren Bearbeitung an andere Programme, vor allem Editoren, übergeben kann. Welchen Editor Sie hierbei verwenden möchten, können 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 weiterarbeiten, 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 zwischengespeicherten 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 verwenden: get file_name [lis[t]|nol[ist]]

X X

file_name Geben Sie hier den Pfad und Namen der zu ladenden Datei ein. lis[t]|nol[ist] Mit dieser Zusatzoption können Sie vorgeben, ob die Datei nach dem Laden angezeigt wird (list = Standard) oder nicht (nolist).

sav[e] file_name [rep[lace]|app[end]]

X X

file_name Geben Sie hier den Pfad und Namen der zu speichernden Datei ein. 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.

100

1.8.2


SQL*Plus als Skriptinterpreter

Genau wie beim Server-Manager können Sie auch mit Hilfe von SQL*Plus sogenannte SQL-Skripte ablaufen lassen. In einem solchen Skript werden vielleicht verschiedene 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 regelmäßig Batch-Dateien, um mit deren Hilfe regelmäßige Aufgaben, wie z.B.

X X X X

die Durchführung von Sicherungen, einen Dateiversand via FTP, das automatische Löschen bestimmter Dateien oder Verzeichnisse, 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, ausgefü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. Reorganisationsarbeiten, Füllen von Arbeitstabellen etc.) zu starten. Zum anderen finden Sie diese Methode aber in den Batchabläufen von Produktionsumgebungen. Da werden im Rahmen der Nachtverarbeitung, gesteuert durch UNIX-Shell-Skripte, immer wieder verschiedene Abfragen oder PL/SQL-Programme gestartet. Zwischendurch 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 Programm zusammen mit verschiedenen Kommoandozeilenparametern verwenden. Diese Kommondozeilenparameter dienen vor allem zum Anmelden an die Datenbank 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 ausgegeben werden. Dieser Modus ist damit vor allem geeignet, wenn Sie SQL*Plus aus

SQL*Plus

X

X

X

101

einem anderen Programm heraus starten und alle benötigten Anmeldeinformationen vorhanden sind. Logon Mit diesem Parameter müssen Sie die benötigten Anmeldeinformationen übergeben. 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. system/manager@db01). Dabei besteht auch die Möglichkeit, das Passwort wegzulassen, damit es nach dem Start von SQL*Plus abgefragt wird (z.B. system@db01). Skript Mit diesem Parameter können Sie das zu startende SQL-Skript vorgeben. Beginnen 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). 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 Platzhalter handelt, muss der konkrete Dateiname beim Start des Skripts als Argument übergeben werden. Danach erfolgt mit Hilfe der schon bekannten Abfrage die Ausgabe der Namen der zur Datenbank gehörenden Datenfiles. Zum Schluss wird die Ausgabeumleitung wieder aus- (spool off) und die Ausgabe im SQL*Plus-Fenster wieder eingeschaltet. Danach wird das Plus-Programm mittels Exit-Befehl beendet. Starten Sie nun, beispielsweise mit Hilfe des Ausführen-Eintrags, aus dem WindowsStart-Menü folgenden Befehl (vgl. Abb. 1.42):

102


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. Experimentieren Sie einfach mal mit den verschiedenen Startmöglichkeiten, indem Sie beispielsweise 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 AcceptBefehls vom Benutzer einfordern: acc[ept] variable [num[ber]|char|date] [for[mat] format] [def[ault] default] [prompt text]

X X 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. num[ber]|char|date Legen Sie hier bei Bedarf den Datentyp Ihrer Variablen fest. Wenn Sie nichts vorgeben, dann wird der Typ char angenommen. 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 festzulegen, 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

X X

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). def[ault] default Legen Sie hier einen Standardwert fest, der genommen wird, wenn Sie die Eingabeaufforderung mit Hilfe der Eingabetaste übergehen. prompt text Geben Sie hier den Text ein, der während der Eingabeaufforderung am Bildschirm 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 name from v$datafile; 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 Betriebssystemskripts 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 restlichen Zeilen im SQL-Puffer, bis das gestartete Programm wieder beendet wurde.

104


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 spezielle Arbeitstabelle erstellt haben. Eine weitere Möglichkeit besteht in der Erstellung 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 name from v$datafile; 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 Betriebssystembefehls, also auch den Start einer ganzen Batch- bzw. Shellskripts. In unserem Beispiel wird die Batchdatei NACHLAUF.BAT, der beim Aufruf der Name der Ausgabedatei 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 Ausgabedatei, 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

1.9

105

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 8iVersion wieder in einem neuen Layout vorliegt. Zwar lässt dieser Editor ein komfortableres 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 beschriebenen Fähigkeiten fehlen, als Batchschnittstelle zwischen Datenbank und externen 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 Prinzip zwei Fenster. Bei der 8er-Version dient das untere Eingabefenster als FullscreenEditor zum Eingeben bzw. Bearbeiten der benötigten Befehle und nach deren Ausführung werden die Ergebnisse im oberen Ausgabefenster dargestellt. In der 8i-Version 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.

106


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 fassen. 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 verknü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 Eingabefensters 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 Worksheetbzw. Arbeitsblatt-Menü entsprechende Menüeinträge. Mit Hilfe des Clear All- bzw. Alles löschen-Eintrags aus dem Edit- bzw. BearbeitenMenü 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-Worksheets problemlos zurecht zu kommen. Falls nicht, dann finden Sie in der Dokumentation 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 finden 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 Werkzeug, mit dem Sie alle verfügbaren Datenbankobjekte anlegen bzw. bearbeiten können. 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-Studio (vgl. Abb. 2.2). Nun kann man sich streiten, ob es sinnvoll ist, irgendwelche Datenbankdefinitionen mit Hilfe eines solchen Werkzeugs durchzuführen. Betrachten Sie einmal die Abbildung 2.1, in der das Fenster zum Bearbeiten des Programmcodes einer OracleDatenbankprozedur gezeigt wird. Ich glaube, man braucht nicht viel Phantasie um sich vorstellen zu können, dass der zugehörige Programmeditor in Form des kleinen Textfensters schon bei Programmen mit wenigen Zeilen alles andere als hilfreich ist.

110


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 wiederherstellbarer Einzelschritte durchzuführen. Entweder ist das konkrete Anwendungsprogramm aufgrund dort gespeicherter Definitionen in der Lage, die Datenbank mit Hilfe entsprechender SQL-Befehle oder eines generierten Skripts zu erzeugen oder die zur Erstellung der einzelnen Objekte benötigten Statements werden 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 Datenbank im Bedarfsfall automatisch generiert werden kann, indem beispielsweise einfach alle gesammelten Erstell- bzw. Änderungsskripts nacheinander abgespielt werden. 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 komfortabeler, 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 Schaltflä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 Erstellung 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 Programmbedienung, sondern erklärt die Ausprägungen der verschiedenen Eigenschaften des aktuell geöffneten Objekts. Zur grundsätzlichen Bedienung gibt es eigentlich nicht viel zu sagen, das Programm entspricht im Aussehen und in der Funktionsweise dem schon vorgestellten Storage Manager. Außerdem fühlen wir Windows-Explorer gewöhnten Anwender 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 zugehö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 installiert 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 fahnden, denn sie sind nur dann verfügbar, wenn auf dem Datenbankserver die OracleObjekte installiert wurden, wobei es sich hierbei früher um ein extra zu beziehen-

112


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 „Advanced 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 ObjektOption haben oder nicht, dann können Sie dies mit Hilfe einer Abfrage der View v$option klären: SQLWKS> select * from v$option; PARAMETER ---------------------------------------------------------------Partitioning Objects Parallel Server Advanced replication Bit-mapped indexes Connection multiplexing Connection pooling Database queuing Incremental backup and recovery Instead-of triggers Parallel backup and recovery Parallel execution Parallel load Point-in-time tablespace recovery

VALUE -----TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE 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 anlegen 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 technischen 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ötigten Datenbankobjekte oder wird auch zu deren Wartung bzw. Änderung verwendet. 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 Weiterbildungsprodukts Pisa unter Verwendung des gleichnamigen Benutzers und schließlich auch noch eine SAP-Anwendung, über den User saphr installiert. Jedes dieser Produkte 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 werden soll, d.h. es müssen alle zugehörigen Objekte aus der Datenbank entfernt werden. Nichts einfacher als das, denn Sie müssen in dem Fall lediglich das entsprechende 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


Ich weiß nicht, wie es Ihnen geht, aber ich bin immer froh, wenn ich beim erstmaligen Kontakt mit einer neuen Datenbank eine Übersicht der vorhandenen Möglichkeiten finde, um rasch den Brückenschlag aus der alten in die neue Datenbankwelt 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

114


wenn eine solche Übersicht zunächst immer nur einen oberflächlichen Eindruck hinterlässt, so hilft Sie dennoch, die folgenden ersten Gehversuche zu vereinfachen 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 Managers erstellen können kurz beschreibe und auf die SQL-Befehle, die Sie zum Erstellen bzw. Bearbeiten der Objekte benötigen verweise, bzw. diese in den beschriebenen 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 einzelnen Oracle-Befehlen sehr zurück. Dies wird sich auch hier bzw. im weiteren Verlauf 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 tiefergehende 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-Programmierung“, weitergehende Informationen. Dort finden Sie neben weiteren Beispielen auch eine systematische Einführung in PL/SQL. Die nachfolgenden Beispiele (Listings) finden Sie alle auf der zum Buch gehörenden 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 Tablespacenamen ü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-Erweiterungen 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 Übersetzungen spricht man in dem Zusammenhang meistens von Datenfeldern, und


115

damit wir alle über das gleiche Sprechen, habe ich mal eine Definition des Begriffs Datenfeld ausgegraben: Datenfeld: Ein Satz aufeinanderfolgender, indizierter Elemente, die den gleichen 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 Veranschaulichung 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 mittlerweile alle flexibel sind, reicht hierfür ein einfaches numerisches Feld zum Speichern der Wochenstundenzahl meistens nicht mehr aus. Stattdessen benötigen wir eher sieben numerische Felder, um die festgelegte Arbeitszeit pro Wochentag abzuspeichern (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 individuelle Wochenarbeitszeit abspeichern. Betrachtet man nun die sieben Einzelfelder zum Speichern der Tagesstunden, so ist das gemäß der eben beschriebenen Definition ein erstklassiger Kandidat für ein Datenfeld. Statt Sonntag, Montag, Dienstag

116


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 Verwendung des neuen Datentyps tag anstelle der sieben numerischen Felder. Das hat natürlich Auswirkungen auf die Verwendung der Tabelle beim Einfügen oder Änderung 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)); insert into ma_arbeitszeit values ('4712',tag(0, 0, 9, 7.5, 7.5, 4.5, 2)); insert into ma_arbeitszeit 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.


117

Wollen Sie das Datenfeld jedoch im Rahmen eines SQL-Ausdrucks oder für die Ausgabe innerhalb einer Auswahlabfrage verwenden, dann haben Sie allerdings noch ein kleines Problem, denn hierbei können Datenfelder nicht direkt eingesetzt werden, 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ünschten Elemente aus dem Datenfeld herauskopiert werden (vgl. Listing 2.5). Im Vorgriff auf das übernächste Kapitel soll die Funktion hier schon einmal erstellt werden. 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 Parameter 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 Komfort 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? ------------------------------ -------PERSNR NOT NULL AZ_TAG

Type ---VARCHAR2(11) 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.

118


Schreiten wir also zur Verwendung unsere neuen Funktion und listen alle Mitarbeiter 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 Zeichenfolge entsprechend der vorgegebenen Formatierung in ein Datum umzuwandeln. Dieses Datum erhält die Standardfunktion to_char als Eingabeparameter und wandelt das Datum wieder in eine Zeichenkette um. Aufgrund des diesmal verwen-


119

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 weiteres Kriterium hinzukommt, dass die Tabellen meistens auch zusammen gelesen werden. Letzteres ist der Fall, wenn die Tabellen immer wieder über die gemeinsamen Felder verknüpft werden oder mit Hilfe dieser Felder referentielle Integritätsbedingungen 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 cluster gelöscht. Beim Anlegen der einzelnen Tabellen werden dann für die gemeinsamen 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ültigkeit, Vorgesetzter usw.) gespeichert werden. Weiterhin enthält auch der Mitarbeiterstamm 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 Vorgesetzten zu sortieren. Zusammen mit der Kostenstelle werden die Tabellen Mitarbeiterdaten und Kostenstellen also meistens gemeinsam benötigt. Das Gleiche gilt auch bei den Abrechnungsergebnissen. Spielt hier bei einer Auswertung die Kostenstelle eine Rolle, dann benötigt man aus den eben genannten Gründen meistens auch noch die Kostenstellentabelle. Folglich könnte man in dem Fall einen Cluster für das Feld Kostenstelle anlegen und anschließend die drei Tabellen diesem Cluster zuordnen. Auch wenn man spontan einen anderen Eindruck bekommen könnte: Das Clustern von Tabellen hat keinen Einfluss auf deren sonstige Verwendbarkeit. Sie müssen 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.

120

2.2.3


Datenbank-Link (Database Links)

Wie Sie mittlerweile wissen, stellen verschiedene Oracle-Datenbanken selbst auf einem Rechnerknoten eigenständige und voneinander abgeschottete Datensammlungen 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 Zieldatenbank eine geeignete Benutzer-Id nebst zugehörigem Passwort. Des weiteren muss auf dem Server der primären Datenbank ein Dienstname für die Zieldatenbank 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 anzumelden, 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 universelles 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 universell 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 Konfigurationsdatei TNSNAMES.ORA definierten Dienstnamen „eink“ verwendet. Mehr Dienstnameneinträge hat der Client nicht, d.h. die Vertriebsdatenbank in München ist für ihn direkt nicht erreichbar.


121

connect hugo@eink select * from ver_mitarb@ein2

Client

Netzwerk

München Datenbank: vertrieb

Frankfurt Datenbank: einkauf Link ein2 = ver0

eink

vert

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 transparent 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 database 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 welchem Benutzer sich die Datenbankinstanz an der Zieldatenbank anmeldet. Dieses Verfahren müssen Sie beim Erstellen des Links festlegen. Hierbei können Sie beispielsweise 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.

122


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üpfung erstellen. Erweitern Sie hierzu zunächst auf dem Server die Dienstnamenkonfiguration 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 OrclInstanz 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 „system“ 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


123

Mit Hilfe einer Abfrage der View all_db_links können Sie sich übrigens eine Übersicht 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 üblicherweise spezielle Miniprogramme zur Verfügung, mit deren Hilfe Sie bestimmte Aufgaben 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 wichtige 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 Formatieren von Datumswerten, die Durchführung spezieller Berechnungen oder das Bearbeiten von Zeichenketten erledigen können. Des weiteren werden die benötigten Methoden der noch zu besprechenden Objekte mit Hilfe solcher selbstdefinierten Funktionen realisiert. So weit - so gut, doch eigentlich rede bzw. schreibe ich die ganze Zeit am eigentlichen 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, sondern 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 Datenbanksystemen 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 (droppen). 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 Parameter anders formatiert zurückliefert. Konkret erwartet die Funktionen einen Text und liefert diesen rückwärts gelesen wieder zurück.

124


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 Erstellung des benötigten und noch leeren Funktionsgerüsts. Beim Anlegen oder Bearbeiten von Funktionen müssen Sie hinter der create-Anweisung 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 Standarddatentypen (z.B. date, number oder varchar2) auch alle selbstdefinierten Typen verwenden. Nach dieser Parameterleiste folgt eingeleitet durch das Schlüsselwort return die Definition des von der Funktion zurückgelieferten Datentyps und abschließend leitet 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üsselwort begin und enden mit einer end-Anweisung, wobei ein solcher Block auch immer mit einem Semikolon (;) abgeschlossen wird. Innerhalb eines solchen Blockes 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 berechneten 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 Zeichenfolgen 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 zweiten Schritt entsprechend der einstmals beschriebenen Aufgabenstellung erweitern (vgl. Listing 2.10).


125

create or replace function spiegeln (in_c varchar2) return varchar is out_c varchar2(254); i number; begin for i in reverse 1..length(in_c) loop out_c := out_c || substr(in_c, i, 1); end loop; return out_c; end; / show errors; commit; Listing 2.10: Fertigstellung unserer spiegel-Funktion

Was hat sich nun im Einzelnen im Vergleich zum vorherigen Beispiel geändert? Zunächst einmal benötigen wir für die Aufbereitung des rückwärts gelesenen Parameters eine Hilfsvariable, deren Inhalt wir am Ende der Funktion zurückliefern wollen. In dem Fall müssen Sie diese Variable gleich am Anfang, also noch vor dem ersten Programmblock, definieren. In unserem Beispiel verwenden wir hierzu die Variable out_c vom Typ varchar2 und mit einer maximalen Länge von 254 Zeichen. Diese versteckte Definitionsanweisung wird genau wie jede andere auch mit einem Semikolon abgeschlossen. Innerhalb unsere Funktionsrumpfes definieren (deklarieren) wir zunächst eine weitere (numerische) Hilfsvariabel i. Hinter dieser Deklaration beginnt nun das eigentliche Programm innerhalb des zugehörigen Programmblocks. Wie Sie später bei der PL/SQL-Einführung noch sehen werden, kann jeder Programmblock einen eigenen Deklarationsteil besitzen, der normalerweise durch das Schlüsselwort declare eingeleitet wird. Bei der Anlage von Funktionen oder Prozeduren beginnt der Deklarationsteil direkt hinter dem Funktionskopf, also direkt hinter dem is-Schlüsselwort. Aus diesem Grund muss die declare-Anweisung für den ersten Programmblock weggelassen werden. Damit kennen Sie jetzt die grundsätzliche Struktur einer jeden Funktion, egal, ob sie vor Ausführung des eigentlichen Programms eigene Variablen vorab deklariert oder nicht. Ein bisschen was gibt es allerdings noch zur Parameterleiste der Funktion anzumerken. Zwischen den dort spezifizierten Parameternamen und Datentypen können Sie bei Bedarf noch explizit festlegen, in welche Richtung die aufgezählten Parameter verwendet werden können. Gewöhnlich dienen solche Parameter immer als Eingangstor zu dem in der Funktion gespeicherten Programm, weshalb der Zusatz „in“ dem Standard entspricht und daher weggelassen werden kann. Schematisch hat die Spezifikation eines Parameters folgenden Aufbau, wobei Sie eine Beschreibung der einzelnen Schlüsselwörter in der Tabelle 2.1 finden: <Parameter> in | out | in out

126


Schlüsselwort

Bedeutung

In

Standardwert der festlegt, dass der Parameter innerhalb der Funktion bzw. Prozedur nur gelesen werden kann.

Out

Das aufrufende Programm erwartet mit Hilfe dieses Parameters ein Ergebnis zurück.

in out

Der übergebene Parameter kann innerhalb des Programms gelesen aber auch geändert werden.

Tabelle 2.1: Festlegen der Verwendbarkeit von Parametern

Im eigentlichen Programm wird nun der übergebene Parameter mit Hilfe einer for..loop-Schleife durchlaufen. Diese Schleife zählt wegen des Zusatzwortes reverse rückwärts beginnend von der Länge der übergebenen Zeichenkette bis zur Zahl 1. Innerhalb der Schleife wird bei jedem Durchlauf die Zählvariable i entsprechend gesetzt, so dass wir mit ihrer Hilfe und der Funktion substr das dem Durchlauf entsprechende Zeichen aus dem Eingabeparameter herausschneiden und an die Ausgabevariable out_c anhängen können. SQLWKS> select parameter, spiegeln(parameter) from v$option; PARAMETER SPIEGELN(PARAMETER) ------------------------------------ -----------------------Partitioning gninoititraP Objects stcejbO Parallel Server revreS lellaraP Advanced replication noitacilper decnavdA Bit-mapped indexes sexedni deppam-tiB Connection multiplexing gnixelpitlum noitcennoC Connection pooling gniloop noitcennoC Database queuing gniueuq esabataD Incremental backup and recovery yrevocer dna pukcab latnemercnI Instead-of triggers sreggirt fo-daetsnI Parallel backup and recovery yrevocer dna pukcab lellaraP Parallel execution noitucexe lellaraP Parallel load daol lellaraP Point-in-time tablespace recovery yrevocer ecapselbat emit-ni-tnioP 14 rows selected. Listing 2.11: Verwenden der selbstgeschriebenen spiegeln-Funktion

Natürlich können die in der Praxis verwendeten bzw. erstellten Funktionen wesentlich komplexer ausfallen, zum Beispiel weil die notwendigen Berechnungen umfangreicher als in unserer kleinen Funktion sind oder weil Sie von der Möglichkeit Gebrauch machen, innerhalb des Funktionsrumpfs weitere Datenbankabfragen auszuführen. Auf die zuletzt genannten Möglichkeiten werde ich in den nächsten Kapiteln noch häufiger zurückkommen. Verfolgen Sie einfach den im Anhang befindlichen Index, um diejenigen Seiten zu finden, auf denen die Verwendung der Funktionen weiter vertieft wird, womit wir die fast perfekte Überleitung zur nächsten Kategorie des Schema-Managers gefunden haben.


2.2.5

127

Index (Indexes)

Bei einem Index handelt es sich um ein optionales Element, das zusammen mit Tabellen erstellt bzw. verwendet werden kann. Bei sachgemäßer Verwendung, können Sie die Ausführungsgeschwindigkeit von Abfragen erheblich erhöhen, gleichgültig ob es sich hierbei um Auswahl- oder Änderungsabfragen handelt. Dabei hat das Fehlen bzw. Vorhandensein eines Index keinerlei formale Auswirkungen auf die notwendige Kodierung der Abfrage. Letzteres gilt im Wesentlichen übrigens für nahezu alle marktüblichen relationalen Datenbanksysteme, auch wenn der ein oder andere Vertreter die Möglichkeit bietet, im Rahmen einer Abfrage die Verwendung eines ganz speziellen Index zu erzwingen. Stellen Sie sich vor, Sie hätten die Aufgabe, in diesem Buch jede Seite die den Begriff „Funktion“ enthält herauszusuchen. In dem Fall müssen Sie das gesamte Buch Seite für Seite durchsuchen und dabei jede Seite markieren, in der Sie das gesuchte Wort finden. Das ist eine Aufgabe, für die selbst geübte bzw. schnelle Leser mehre Stunden bis Tage benötigen. Ist für dieses Wörtchen jedoch ein entsprechender Eintrag im Buchindex vorhanden, dann reduziert sich die für diese Aufgabe benötigte Zeit auf wenige Sekunden. Zunächst müssen Sie das Wort im Index finden. Da dieser üblicherweise sortiert ist, werden Sie hierbei sicherlich direkt beim Buchstaben „F“ beginnen und erst danach die einzelnen Wörter so lange der Reihe nach durchgehen, bis Sie beim gesuchten Begriff „Funktion“ angelangt sind. Anschließend können Sie die zugehörigen Seitenzahlen ablesen und hierdurch die gesuchten Buchseiten direkt aufschlagen. Die eben beschriebene Vorgehensweise weist übrigens verblüffende Parallelen zu den von der Datenbank verwendeten Methoden auf. In diesem Workshop werden Sie im Kapitel „Abfragen“ bei der Besprechung des Abfragetunings die Ausführungspläne des Datenbanksystems kennen lernen. Hier finden Sie Begriffe wie „full table scan“ (ganzes Buch durchlesen), „index scan“ (Begriff im Index nachschlagen), „index range scan“ (im Index die Wörter „Funk“ bis „Funktion“ suchen) oder „access per rowid“ (Buchseite direkt aufschlagen). Das Vorhandensein von den (richtigen) Indexeinträgen kann in einer Datenbank ähnlich dramatische Auswirkungen haben. Ich selbst habe Situationen erlebt, wo das Löschen eines Index eine Abfrage bei sonst gleichen Bedingungen von 120 auf unter eine Sekunde beschleunigt hat, wodurch Sie sehen können, dass zu viele oder unsinnige Indices dem System auch schaden können. Ebenso ist es mir passiert, das die Ausführungsdauer einer verschachtelten Änderungsabfrage durch das Anlegen eines Index von über drei Stunden auf etwa zehn Sekunden reduziert werden konnte. Wie Sie sehen, reden wir hier also nicht über Peanuts, sondern drehen in Bezug auf die Ausführungsgeschwindigkeit an einer zentralen Stelle der Datenbank. Wie aber kann ein Index besonders nützlich oder schädlich sein? Diese Frage lässt sich pauschal leider nicht beantworten. Im Laufe der Zeit, d.h. bei entsprechender Erfahrung, werden Sie sicherlich ein gutes Gefühl dafür entwickeln, welcher Index für welche Aufgabenstellungen hilfreich sein könnte. Die letztendliche Sicherheit erhält man immer erst beim Testen der Abfragen zusammen mit entsprechend großen Tabellen und beim Studieren der zugehörigen Ausführungspläne.

128


Dennoch gibt es eine einfache Grundregel: Der Index soll helfen, die zugehörigen Sätze in der Tabelle möglichst einfach zu finden. Das hört sich banal an, ist es in der Praxis aber oft nicht. Um dies zu verdeutlichen, möchte ich noch einmal zu meinem eben beschriebenen Buchbeispiel zurückkehren. Nehmen wir einfach mal an, für das zu durchsuchende Buch existiert ein Index, der neben den eigentlichen Suchbegriffen auch immer noch die beiden vorhergehenden und das nächste folgende Wort enthält: die neue Funktion ist, 1, 8 neben der Funktion wird, 9 zu der Funktion ist, 11

Wenn Sie dieses konstruierte Beispiel betrachten, dann sollte einleuchten, dass dieser Index nicht gerade zum schnellen Suchen und Finden einlädt. In der Datenbankpraxis entsteht ein vergleichbarer Index, wenn bei der Erstellung mehrer Felder verknüpft werden und der eigentliche Suchbegriff irgendwo in der Mitte der Kette der indizierten Felder auftaucht. Außerdem haben Sie die Möglichkeit, für eine Tabelle mehrere verschiedene Indices für unterschiedliche Felder bzw. Feldketten anzulegen und genau jetzt kann das zunächst latente Problem, denn ein schlechter Index ist oft immer noch besser als keiner, eskalieren, wenn aufgrund der Indexauswahl der eigentlich bessere nicht mehr verwendet wird. Neben dem Beschleunigen von Abfragen kann es noch weitere Gründe für die Anlage eines Index geben. Nehmen wir einmal an, Sie möchten in einer Tabelle die Eindeutigkeit eines Feldes oder einer bestimmten Feldkombination erzwingen, ohne dass Sie je vorhaben, direkt nach diesem Feld bzw. der Kombination zu suchen. Trotzdem wäre in dem geschilderten Fall die Anlage eines speziellen Index für dieses Feld bzw. die Felder die Maßnahme der ersten Wahl. Wie Sie gleich noch sehen werden, existieren bei der Anlage eines Index verschiedene Varianten. Eine dieser Varianten ist die Erzwingung eindeutiger Indexeinträge, so dass bei dem Versuch des Einfügens von neuen Sätzen, deren Felder bzw. Feldkombinationen diese Regel verletzen würden, ein Fehler entsteht. Jede größere Tabelle sollte mindestens einen solchen eindeutigen Index besitzen, mit dessen Hilfe jede gespeicherte Reihe eindeutig identifiziert werden kann (Primärschlüssel). Physikalisch wird ein Index unabhängig von der zugehörigen Tabelle gespeichert, wobei die Indices üblicherweise sogar in einem eigenen Tablespace und damit in einem eigenen Datenfile und hierdurch vielleicht sogar auf einer eigenen Festplatte gespeichert werden. In Oracle können Indices explizit oder implizit angelegt werden. Im ersten Fall erfolgt die Anlage durch Eingabe einer entsprechenden create index-Anweisung bzw. die Löschung eines Index erfolgt mit Hilfe des Befehls drop index. Bei der impliziten Indexerstellung erfolgt die Definition zusammen mit der Tabellenbeschreibung, wobei wir uns diese Möglichkeit erst später bei der Beschreibung der Tabellen anschauen werden. Eine abschließende Bemerkung möchte ich noch machen, bevor wir das Ganze nun wieder an einem Beispiel ausprobieren. Wo viel Licht ist, da ist bekanntlich


129

auch ein wenig Schatten. Die hier in den Vordergrund gestellten Vorteile der Indices gibt es in einer Datenbank nicht kostenlos. Zum einen benötigen die Indices Plattenplatz und zum anderen kostet auch deren Verwaltung Rechnerressourcen. Schließlich muss das Datenbanksystem bei jeder Änderung nicht nur die eigentliche Datentabelle, sondern auch alle Indices aktualisieren. Aus diesem Grund ist es verständlich, dass in manchen Architekturen nur diejenigen Indices permanent verfügbar sind, die für die Performance der Dialoganwendung vorteilhaft sind. Andere Indices, die für bestimmte Batchläufe oder Reports vorteilhaft sind, werden erst bei Bedarf erstellt und am Ende des Batch-Programms bzw. des Reports wieder gelöscht. Beispiele Bevor Sie irgendwelche Indices anlegen können, benötigen Sie logischerweise zunächst einmal eine Tabelle, die im Rahmen des folgenden Listings angelegt wird, wobei Sie das Beispiel in der Datei LISITING12A.SQL finden. drop table mitarbeiter; / create table mitarbeiter ( persnr varchar2(11) not null, name varchar2(50), strasse varchar2(30), ort varchar2(30), plz varchar2(5) ) tablespace usr storage (initial 10000 next 10000 maxextents unlimited pctincrease 0) / commit; insert into mitarbeiter values ('4711', 'Raymans, Heinz-Gerd', 'Heinrichstr. 7','Duisburg','47231'); insert into mitarbeiter values ('4712', 'Schmidt, Harald', 'Duissernplatz 2','Düsseldorf','42231'); commit;

Nachdem Sie nun mit der Mitarbeitertabelle ein Demonstrationsobjekt haben, können Sie in einem zweiten Schritt einen Index anlegen (vgl. Listing 2.12). create unique index mitarbeiter_pk on mitarbeiter (persnr) tablespace indx storage (initial 10000 next 10000 maxextents unlimited pctincrease 0); commit; Listing 2.12: Index für die Mitarbeitertabelle anlegen

In dem Beispiel legen Sie für die Tabelle mitarbeiter einen eindeutigen Index für das Feld persnr mit dem Namen mitarbeiter_pk an, der im übrigen für das gewählte Schema eindeutig sein muss. Der Index wird in dem Tablespace indx gespeichert und erhält eine eigene Storage-Klausel. Wenn Sie diese Speicherbelegungsregel

130


weglassen, dann wird stattdessen die bei der Anlage des Tablespaces spezifizierte Klausel verwendet. Versuchen Sie doch einfach mal nach Anlage dieses Indexes die oben abgedruckten Insert-Anweisungen noch einmal auszuführen. Da dies zu einer Verletzung der Indexeindeutigkeit führt, erhalten Sie folgerichtig den entsprechenden Hinweis „unique constraint (SYSTEM.MITARBEITER_PK) violated“, wobei die Datensätze nicht in die Datenbank eingefügt werden. Varianten

X

Index für mehrere Felder Wenn Sie einen Index für mehrer Felder erstellen möchten, dann müssen Sie diese einfach innerhalb der Klammer durch Komma getrennt aufzählen. Solche zusammenhängenden Indices können maximal 32 Felder enthalten und sollten (vgl. Anmerkungen von oben) entweder einen sinnvollen Suchpfad wiedergeben oder in der vorgegebenen Kombination den Primärschlüssel der Tabelle bilden: create unique index mitarbeiter_p1 on mitarbeiter (persnr, plz)

X

Sortierung des Index festlegen Bei der Anlage eines Index können Sie dessen Sortierung festlegen, indem Sie hinter den einzelnen Spalten die Sortierreihenfolge mit Hilfe der Schlüsselwörter asc (aufsteigend, standard) bzw. desc (absteigend) festlegen. Das kann sinnvoll sein, wenn die Daten oft entsprechend sortiert ausgegeben werden müssen. create index mitarbeiter_pl on mitarbeiter (plz desc)

X

Nicht eindeutiger Index Lassen Sie das Schlüsselwort unique weg, wenn Sie keinen eindeutigen Index erstellen möchten: create index mitarbeiter_p2 on mitarbeiter (name)

X

Nicht wiederherstellbar Mit Hilfe der Option unrecoverable verhindern Sie, dass der Index bei der Protokollierung auf den Redo-Log-Dateien berücksichtigt wird. Diese Option ist allerdings ein Auslaufmodell und nur noch aus Kompatibilitätsgründen verfügbar. Verwenden Sie stattdessen das Schlüsselwort nologging, wenn sie die Protokollierung für den Index ausschalten wollen. create unique index mitarbeiter_pk on mitarbeiter (persnr) tablespace indx nologging;

X

Weitere Varianten Die bisher beschriebenen Verfahren und Varianten sind diejenigen, die Ihnen zumindest nach meiner Erfahrung in der Praxis meistens über den Weg laufen.


131

Daneben existieren noch ein paar exotischere Möglichkeiten, beispielsweise diejenige des Bitmap Index. Diese Anlageform, die allerdings nur in der Oracle Enterprise Edition verfügbar (vgl. Listing 2.1) ist, wandelt die spezifizierten Indexspalten in entsprechende Bitmuster um. Dieses Verfahren verspricht Performancevorteile bei Spalten mit geringen Wertebereichen (z.B. Geschlecht). Index verwalten Die explizit über create index angelegten Indices können mit Hilfe der Anweisung drop index wieder aus der Datenbank entfernt werden, indem Sie den Befehl zusammen mit dem vergebenen Indexnamen verwenden. drop index mitarbeiter_pk

Intern werden die Indices mit Hilfe sogenannter B*-Bäume verwaltet. Damit diese Bäume beim Suchen dauerhaft optimal funktionieren schadet es nicht, sie von Zeit zu Zeit zu reorganisieren. Hierzu ist es allerdings nicht notwendig den Index zu löschen und anschließend neu anzulegen, sondern Oracle bietet zusammen mit der Anweisung alter index eine Variante, den spezifizierten Index neu aufzubauen (vgl. Listing 2.13). alter index mitarbeiter_pk rebuild; commit; Listing 2.13: Index reorganisieren

Einen Überblick über die in der Datenbank gespeicherten Indices erhalten Sie mit Hilfe einer Abfrage auf die Views all_indexes oder all_ind_columns. Die erste der beiden Views zeigt die generelle Definition des Index, d.h. hier erhalten Sie beispielsweise Informationen über die Speicherbelegungsregel (storage-Klausel) oder den verwendeten Tablespace. Die zweite View zeigt den Aufbau des Index, d.h. sie liefert die Reihenfolge und Namen der im Index verwendeten Spalten. Vergleichen Sie hierzu die im Listing 2.14 abgedruckte Abfrage, in der diese beiden Views verknüpft werden, um die Indices und deren Zusammensetzung für die Tabelle „mitarbeiter“ zu ermitteln; das Listing 2.15 zeigt Ihnen die zugehörige Ausgabe dieser Abfrage entsprechend den eben behandelten Beispielen. select a.index_name, a.uniqueness, b.column_name from all_indexes a, all_ind_columns b where and and and

a.owner='SYSTEM' a.table_name = 'MITARBEITER' b.index_owner = a.owner b.index_name = a.index_name

order by a.index_name, b.column_position Listing 2.14: Analyse der Indexstruktur mit Hilfe vorhandener Systemviews

132


INDEX_NAME -----------------------------MITARBEITER_P1 MITARBEITER_P1 MITARBEITER_PK 3 rows selected.

UNIQUENES --------UNIQUE UNIQUE UNIQUE

COLUMN_NAME ---------------------PERSNR PLZ PERSNR

Listing 2.15: Abfrage der vorhandenen Indices entsprechend unserem vorhergehenden Beispiel

2.2.6

Objekttyp (Object Types)

Hinter dieser Kategorie verbirgt sich technisch auch wieder der Befehl create type, so dass Sie Ihnen auch diese Funktionalitäten wieder nur zusammen mit der ObjekteOption (vgl. „Array Types“) zur Verfügung steht. Konkret geht es hier entsprechend der Kategorieüberschrift in der Tat um die Definition sogenannter Objekte. Bei einem Objekt handelt es sich um eine Einheit, bestehend aus einer benutzerdefinierten Datenkomposition und einer Sammlung von Funktionen und Prozeduren, um diese Daten zum Bearbeiten oder weitergehenden Funktionalitäten bereitzustellen. Im Zusammenhang mit einem solchen Objekt werden die gespeicherten Daten üblicherweise als Attribute oder Eigenschaften bezeichnet, wohingegen man bei den Funktionen und Prozeduren, die in irgendeiner Weise das Verhalten des Objektes repräsentieren, von Methoden spricht. Natürlich würde eine systematische Einleitung in den Objekt-Themenkomplex den Rahmen dieses Buches bei weitem sprengen. Ich glaube aber trotzdem, dass selbst wenn Sie bisher noch gar keine Erfahrung in objektorientierter Programmierung sammeln konnten, die nachfolgenden Ausführungen und Beispiele für Sie nachvollziehbar sind und Klarheit in den einen oder anderen Aspekt des objektorientierten Ansatzes bringen werden. Ich bin immer wieder belustigt über den manchmal stattfindenden Glaubenskrieg zwischen objektorientierter und klassischer rein prozeduraler Programmierung. Ich denke für beide Ansätze gibt es entsprechende Existenzberechtigungen. Was ich allerdings auch nicht mag ist, wenn in mancher Literatur in Bezug auf Objektorientierung der Eindruck entsteht, hierdurch würde – ich übertreibe mal ein wenig – quasi ein neues Weltbild entstehen und die Einführung erfolgt mit Hilfe von derartigen Beispielen, dass man anschließend glaubt, Objekte sind nur etwas für über den Dingen stehende Freaks. Die Welt ist die gleiche geblieben, es sind lediglich neue Verfahren und Werkzeuge zu deren Beschreibung hinzugekommen. Vor etwa fünfzehn Jahren habe ich mein erstes Cobol-Programm für eine Düsseldorfer Versicherungsgesellschaft geschrieben. Für alles und jedes gab es irgendwelche Strukturen, beispielsweise die Struktur „Versicherungsnehmer“, die aus den Komponenten Name, Straße, Ort, Geburtsdatum und vielen weiteren Felder bestand. Heute formuliert man anders, das Objekt „Versicherungsnehmer“ verfügt über die Eigenschaften Name, Straße, Ort usw., aber es hat sich eigentlich nichts geändert, denn es geht darum zusammengehörende Informationen geeignet zu bündeln.


133

Jeder Versicherungsnehmer verfügt bzw. besitzt beliebig viele Verträge, mit zumindest gleichem Vertragsstamm. Heute beschreibt man das natürlich eleganter und ordnet dem Versicherungsnehmer eine Kollektion des Objekts „Vertragsstamm“ zu. Bei der Arbeit mit diesen Strukturen war mein eigentlich permanent auf der Suche nach schon existierenden Unterprogrammen, beispielsweise einem solchen, das mit Hilfe der übergebenen Struktur die Anschrift oder die Anrede korrekt aufbereitet. Spätestens jetzt treten die Vorteile der Objektorientierung stärker in den Vordergrund, denn hierbei sind Sie in der Lage, auch diese Verfahren an die Struktur bzw. das Objekt zu binden. Neben der Bündelung der Daten erfolgt also auch die Konzentration der benötigten Funktionalitäten unter ein und demselben Begriff, eben diesem Objekt. Bei diesen Funktionalitäten spricht man üblicherweise von Methoden. In meinem Beispiel des Versicherungsnehmers erfolgt der Zugriff auf den Namen beispielsweise durch Kodierung der Anweisung x = versicherungsnehmer.name versicherungsnehmer.name = ’Meier, Huber’

und in Abhängigkeit davon, auf welcher Seite des Ausdrucks das Gleichheitszeichen steht, fragt man den Namen ab oder weist ihn zu. Möchte man die Anschrift formatiert ausdrucken, dann spezifiziert man jetzt vielleicht einfach nur noch folgende Anweisung: print versicherungsnehmer.print_anschrift().

Beispiele Als Beispiel für diesen Themenkomplex möchte ich das Objekt „mensch“ erstellen. Damit das Beispiel übersichtlich bleibt, erhält unser mensch-Objekt natürlich nur wenige Eigenschaften wie Namen, Anschrift und das Geburtsdatum. Entsprechend zurückhaltend gehen wir auch mit der Definition von Methoden um. Zum einen soll eine Methode zur Berechnung und Ausgabe des Alters, und zum anderen die eben beschriebene Funktion zur formatierten Anschriftenausgabe erstellt werden. create or replace type mensch as object ( name varchar2(30), vname varchar2(30), strasse varchar2(30), plz varchar2(5), ort varchar2(30), geschl varchar2(1), gebdat date, member function g_alter return number, pragma restrict_references(g_alter, wnds, wnps), member function g_anschrift return varchar2,

134


pragma restrict_references(g_anschrift, wnds, wnps) ); / commit; Listing 2.16: Erstellung unseres Objekts „mensch“

Zunächst legen wir mit Hilfe des schon bekannten Befehls create type das Objekt „mensch“ an (vgl. Listing 2.16). Das funktioniert auf den ersten Blick ganz ähnlich wie die Anlage einer Tabelle, denn die einzelnen Eigenschaften werden genau wie die Spalten einer Tabelle angelegt. Im zweiten Schritt werden die beiden Methoden g_alter und g_anschrift definiert. Dieser Teil erinnert wiederum sehr stark an die Anlage eines Packages und es macht durchaus Sinn, an dieser Stelle kurz zu unterbrechen und zunächst einmal den zu dem Schema-Objekt zugehörigen Abschnitt mitsamt dem Beispiel durchzuarbeiten. Dort finden Sie auch eine genaue Erklärung zu dem Compilerschalter restrict_references, mit der wir für beide Funktionen festlegen, dass sie keine Datenbankänderungen durchführen und keine globalen Variablen ändern können. Danach legen wir die Tabelle im nächsten Schritt zunächst einmal in der klassischen Form an (vgl. Listing 2.17). drop table menschen; / create table menschen (xmensch mensch ) tablespace usr; commit; Listing 2.17: Anlage der Tabelle „menschen“.

„Klassisch“ heißt hierbei, dass wir die Tabelle spaltenweise anlegen, wobei eine oder mehrere dieser Spalten halt zufällig aus einem selbstdefinierten Datentyp gebildet wird. Wie damals bei den Datenfeldern (varray) erhalten wir hierdurch einen abstrakten, interpretationsbedürftigen Datentyp und damit wieder Probleme oder zumindest Mehraufwand innerhalb von SQL-Ausdrücken. Aber auch beim Einfügen bzw. Ändern von Daten müssen wir den Datentyp konstruieren oder jedes Mal entsprechende selbst zu programmierende Member-Funktionen verwenden. SQLWKS> desc menschen Column Name Null? Type ------------------------------ -------- ---XMENSCH ADT(212)

Wie gesagt, benötigt man selbst beim Anlegen von Sätzen einen entsprechenden Konstruktur. In Oracle kodiert man den durch Nennung des Datentyps, dem in Klammern eine Aufzählung aller einzelnen Elemente folgt:


135

insert into menschen values ( mensch('Raymans', 'Heinz-Gerd', 'Harmoniestr. 2a', '47302', 'Duisburg', 'M', to_date('1964.12.03','YYYY.MM.DD') )); commit;

Um diese dauernden Schwierigkeiten zu umgehen, haben Sie auch die Möglichkeit, die Tabelle grundsätzlich objektorientiert anzulegen (sog. Object Tables). In dem Fall besteht die Tabelle jedoch aus einem bzw. aus lauter Objekten, d.h. die Verwendung einzelner „normaler” Spalten ist hierbei nicht mehr möglich. Der Vorteil dabei ist allerdings, dass Oracle das Objekt anschließend auflöst und Sie die einzelnen Eigenschaften wie gewöhnliche Spalten innerhalb von SQL-Ausdrücken verwenden können (vgl. Listing 2.18). drop table menschen; / create table menschen of mensch tablespace usr; commit; Listing 2.18: Anlegen einer objektorientierten Tabelle

Betrachten Sie die Tabellenbeschreibung wieder mit Hilfe des Befehls desc. Obwohl die Tabelle mit Hilfe eines Objekts definiert wurde, ist sie von einer klassischen Tabelle nicht mehr zu unterscheiden, d.h. alle Objekteigenschaften erscheinen wie ganz gewöhnliche Tabellenspalten. SQLWKS> desc menschen Column Name Null? ------------------------------ -------NAME VNAME STRASSE PLZ ORT GESCHL GEBDAT

Type ---VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) VARCHAR2(5) VARCHAR2(30) VARCHAR2(1) DATE

Damit stellt aber auch das Einfügen von Datensätze keine besondere Herausforderung mehr da, d.h. Sie können hierfür ganz gewöhnliche insert-Anweisungen ohne irgendwelche Konstruktoren verwenden (CD: LISTING218A.SQL). insert into menschen values ('Raymans', 'Heinz-Gerd', 'Harmoniestr. 2a','42110', 'Duisburg','M', to_date('1964.12.03','YYYY.MM.DD')); insert into menschen values ('Raymans','Irina',

136


'Harmoniestr. 2a', '42110', 'Duisburg', 'W', to_date('1965.12.27','YYYY.MM.DD')); insert into menschen values ('Zschoge','Helgo', 'Am kleinen Weg 11','10000','Berlin', 'M', to_date('1962.07.13','YYYY.MM.DD')); insert into menschen values ('Heger','Sascha', 'Hansaring 111a','50000','Köln','M', to_date('1969.05.12','YYYY.MM.DD')); commit;

Ähnlich wie bei den Packages unterteilt sich auch das Objekt in zwei Teile. Den erste Teil, in dem die Eigenschaften und sichtbaren Methoden veröffentlicht wurden, haben Sie bereits fertiggestellt. Was noch fehlt ist die Programmierung der veröffentlichten Methoden. Hierzu existiert bei den Objekten ähnlich wie bei den Paketen der „Type body“, in dem die eigentliche Programmierung erfolgt (vgl. Listing 2.19). create or replace type body mensch as member function g_alter return number is begin return floor(months_between(sysdate, gebdat) / 12) ; end; member function g_anschrift return varchar2 is anschrift varchar2(2000) := ' '; begin if geschl = 'M' then anschrift := 'Herrn' || chr(10) || chr(13); else anschrift := 'Frau' || chr(10) || chr(13); end if; anschrift := anschrift || vname || ' ' || name || chr(10) || chr(13); anschrift := anschrift || strasse || chr(10) || chr(13); anschrift := anschrift || plz || ' ' || ort; return anschrift; end; end; / show errors; commit; Listing 2.19: Programmierung der zum Objekt gehörenden Methoden


137

Die erste Methode liefert das Alter, indem zunächst mit Hilfe der Standardfunktion month_between die Differenz zwischen dem Tages- und Geburtsdatums in Monaten berechnet wird. Diese Differenz teilen wir durch zwölf und schneiden von der Division alle Nachkommastellen mit Hilfe der floor-Funktion ab. Die zweite Member-Funktion sieht komplizierter aus, ist es aber nicht. Mit Hilfe des Operators “||” werden alle zur Anschrift gehörenden Einzelfelder aneinandergehängt (konkateniert), wobei an bestimmten Stellen auch die Steuerzeichen chr(10) und chr(13) eingestreut werden, die bei der späteren Ausgabe den gewünschten Zeilenwechsel veranlassen. Mit Hilfe der nun folgenden Abfrage, können Sie das Ergebnis Ihres Schaffens bewundern: SQLWKS> select b.g_anschrift(), name, gebdat, b.g_alter() 2> from menschen b 3> where b.g_alter() > 18 B.G_ANSCHRIFT() NAME GEBDAT B.G_ALTER( ----------------------------- -------------------- -- ------ --------Herrn Heinz-Gerd Raymans Harmoniestr. 2a 42110 Duisburg Raymans 03-DEC-64 35 Frau Irina Raymans Harmoniestr. 2a 42110 Duisburg Raymans 27-DEC-65 34 Herrn Helgo Zschoge Am kleinen Weg 11 10000 Berlin Zschoge 13-JUL-62 38 Herrn Sascha Heger Hansaring 111a 50000 Köln Heger 12-MAY-69 31 4 rows selected.

2.2.7

Paketrumpf (Package bodies)

Diese Kategorie der Schema-Objekte beschreibt die in einem Package (Paket) enthaltenen Funktionen und Prozeduren. Mehr Informationen zu diesem Thema finden Sie im nächsten Abschnitt, der das Schema-Objekt Packages mitsamt den zugehörigen Package bodies beschreibt. Die Anweisung zum Anlegen eines Package bodies lautet create package body bzw. verwenden Sie create or replace package body, um das Schema-Objekt zu ersetzen. Mit Hilfe der Anweisung drop package body können Sie das zugehörige Objekt aus der Datenbank entfernen. Vergleicht man den Aufbau eines solchen Pakets, dann mit herkömmlichen Programmierkonstrukten, beispielsweise einem C-Programm, dann entspricht dieses Objekt dort am ehesten den üblichen Modulen, in dem die einzelnen Prozeduren oder Funktionen programmiert werden.

138

2.2.8


Paket (Packages)

Nicht nur bei der (gelben) Post gibt es Pakete. In einer Oracle-Datenbank versteht man unter einem Package (Paket) die Zusammenfassung oder Verpackung verschiedener Prozeduren oder Funktionen zu einer Einheit. Genau wie im richtigen Leben besteht ein solches Paket meistens aus zwei Teilen, nämlich aus der Verpackung und (hoffentlich zu Weihnachten) auch aus (reichlich) Inhalt, wobei Letzteres in einer Oracle-Datenbank dem Package body gleichzuordnen ist. Aber manchmal erhält man halt auch nur ein leeres Päckchen, was in unserer Datenbank einem Package ohne vorhandenem Package body entspricht. Zurück zum Ernst der Lage. Das Gesamtpaket besteht also (zumindest meistens) aus zwei Teilen, nämlich zum einen aus dem eigentlichen Package, das die Definition aller aufrufbaren Funktionen oder Prozeduren enthält und damit die Hülle oder Verpackung darstellt und zum anderen aus dem Package body, in dem die einzelnen Funktionalitäten ausprogrammiert werden, d.h. das Package body enthält den Programmkode für die im Package aufgezählten Funktionen. Damit fungiert das Package auch als eine Art Schnittstelle zwischen dem Anwender oder anderen aufrufenden Programmen. Die im Paket enthaltenen Funktionen werden durch das Package sichtbar, wobei der zugehörige Programmcode im Package body verborgen bleibt (vgl. Abb. 2.5).

Anwendung Datenbank -SQL*Plus -PL/SQL-Block -Anderes Package -Sonstige Anwendung

Package

Package Body

Abbildung 2.5: Schematischer Aufbau eines Packages

Wie schon im vorhergehenden Kapitel gesagt, kann man diese Konstruktion eines Packages seinem Package body durchaus mit herkömmlichen Programmiersprachen vergleichen. Dabei entspricht das Package body am ehesten den dort verwendeten Modulen, in den sich das eigentliche Programmcoding der einzelnen Funktionen und Prozeduren befindet. Daneben verwenden Sie in diesem Modulen üblicherweise auch Prozeduren oder Funktionen, die in anderen Modulen realisiert wurden und vielleicht sogar erst zur Laufzeit Ihres Programms zur Verfügung stehen. Damit Sie Ihr Programm aber trotz des Fehlens dieser externen Funktionen umwandeln können, müssen Sie zumindest deren Namen und Parametrierung vorab definieren. Wenn Sie Erfahrungen mit den Programmiersprachen C oder Pascal haben, dann kennen Sie ja das ent-


139

sprechende Verfahren, solche Deklarations- bzw. Headerdateien via include oder uses einzubinden. Diese deklarative Eigenschaft weisen die Packages im Übrigen auch auf, denn sobald Sie das Package erstellt haben, können Sie die dort definierten Prozeduren oder Funktionen in anderen PL/SQL-Programmen ansprechen. Eine weitere Parallele ergibt sich auch im Bezug auf die Abstraktion der eigentlichen Programmierung. Wie Sie im weiteren Verlauf noch sehen werden, ist die eigentliche Programmierung im Package body für andere Anwender nicht unbedingt sichtbar, d.h. eine Übersicht des Inhalts ergibt sich alleine aus den im Package vorliegenden Definitionen. In anderen Programmierumgebungen erhalten Sie bestimmte Module oftmals nur in kompilierter Form, d.h. die eigentliche Kodierung der Funktionen ist auch hier nicht sichtbar. Die Verwendungen von Packages bietet einige Vorteile, vor allem dann, wenn man größere zusammenhängende Anwendungen entwickelt:

X

X X X

Selbst ein kleines Programm kann schnell zehn, zwanzig oder mehr einzelne Prozeduren beinhalten. Benötigt Ihre Anwendung nun auch noch eine Vielzahl solcher Programme, dann geht einem bei der Verwendung einzelner Prozeduren bzw. Funktionen neben der Übersicht auch irgendwann einmal bei der Namensgebung die Phantasie aus. Aber selbst mit viel Phantasie haben Sie immer das Problem, dass die Namen der Prozeduren neu entwickelter Anwendungsteile noch nicht in der Datenbank vorhanden sein dürfen. Durch die Zusammenfassung der einzelnen Prozeduren zu den Packages, treten die auf den ersten Blick in den Hintergrund, was einer besseren Übersicht sehr zuträglich ist. Außerdem müssen die Namen der Prozeduren bzw. Funktionen nur innerhalb eines Paketes eindeutig sein; Ausnahmen bestätigen auch hier mal wieder die Regel, da es die Möglichkeit gibt, Prozeduren mehrfach mit unterschiedlichen Parametern zu überladen. Nicht nur bei verteilten Entwicklungsaufgaben haben Packages den Vorteil, dass die enthaltenen Funktionen schon alleine mit deren Definition für andere Anwendungen, quasi als Dummy, verfügbar sind. Die konkrete Ausprogrammierung im Package body kann erst zu einem späteren Zeitpunkt erfolgen. Wird eine in einem Package definierte Prozedur oder Funktion angesprochen, so wird in dem Fall zunächst das gesamte Paket geladen, wodurch auch alle anderen vorhandenen Funktionalitäten verfügbar werden, was die Performance positiv beeinflussen kann. Werden in einem Package globale Variablen deklariert, dann sind die so lange gültig, bis sich der Benutzer wieder von der Datenbank abmeldet bzw. die aktuelle Sitzung (Session) beendet wird. Aufgrund dieses Verhaltens entsteht die Möglichkeit, quasi sitzungsglobale Variablen zu definieren. Ein Effekt, der in der Praxis durchaus genutzt wird und zu den schon angesprochenen leeren Paketen führen kann, d.h. in dem Fall existiert zwecks Erhaltung globaler Variablen zwar ein Package aber kein zugehöriges Package body.

140

X


Als letzten Aspekt möchte ich wieder etwas aus der Richtung Ordnung und Übersicht anführen, wenn auch aus einer anderen Blickrichtung. Wenn Sie Anwendungen in die Datenbank implementieren und hierzu entsprechende Prozeduren oder Funktionen entwerfen, dann müssen Sie in einem späteren Schritt üblicherweise auch Ausführungsberechtigungen für die Anwendung bzw. der zugehörigen Prozeduren vergeben. Sind die zu der Anwendung gehörigen Prozeduren in einem Paket vereint, dann reicht es aus, lediglich die Ausführung des Pakets zu erlauben.

Ein Paket wird mit Hilfe der Anweisung create or replace package und der Paketinhalt mit der Anweisung create or replace package body erstellt bzw. bearbeitet. Ersetzen Sie jeweils die Wörter create or replace durch das Wörtchen drop, um die Anweisung zum Löschen eines Paktes zu erhalten. Beachten Sie hierbei, dass Sie durch das Löschen eines Packages auch automatisch das zugehörige Package body löschen. Beispiele Es ist immer schwierig ein Beispiel zu finden, dass auf der einen Seite nicht zu lang und schwierig ist, aber auf der anderen Seite jedoch alle oder zumindest viele der möglichen Aspekte und Varianten berücksichtigt. In dem folgenden Beispiel, das zwar sicherlich wieder zur Klasse der EFOS-Funktionen (=Eine Funktion ohne Sinn) gehört, ist das dennoch so wie ich glaube ganz gut gelungen. Konkret möchte ich die an der Erstellung unserer spiegeln-Funktion anknüpfen, d.h. sollten Sie die Funktion zwischenzeitlich wieder gelöscht haben, dann müssen Sie die zunächst einmal wieder anlegen. Anschließend beginnen wir mit der Programmierung unseres Pakets „tollhaus“ (vgl. Listing 2.20). create or replace package tollhaus as call_count number; function spiegeln (in_c varchar2) return varchar2; pragma restrict_references (spiegeln, WNDS); end; / show errors; commit; Listing 2.20: Definition des Packages „tollhaus“

Die Anlage des Pakets unterscheidet sich auf den ersten Blick zunächst einmal kaum von der von den Funktionen her bekannten Vorgehensweise. Lediglich das Wörtchen is habe ich zur Abwechslung einmal durch as ersetzt, was aber nicht unbedingt nötig gewesen wäre. Aber auf den zweiten Blick treten mehr und mehr Unterschiede zum Vorschein. Zum Beispiel hat ein Paket nicht einmal einen einzigen Programmblock, d.h. die zugehörige begin-Anweisung fehlt und trotzdem wird eine Package-Definition mit end abgeschlossen.


141

Innerhalb der Paketdefinition wird als erstes die globale Variable call_count vom Datentyp number (Zahl) und anschließend die Funktion spiegeln mit ihren Ein- und Ausgabeparametern definiert. call_count number; function spiegeln (in_c varchar2) return varchar2;

Jede Variable, die einer create package-Anweisung folgt, ist global und für die Lebensdauer der zugehörigen Session gültig. Jede definierte Funktion oder Prozedur kann vom Anwender oder einem anderen Programm aus gestartet (Zugriffsberechtigung vorausgesetzt) werden und muss im Rahmen der Erstellung des Package bodies angelegt bzw. programmiert werden. Nach der Funktion folgt noch eine weitere Anweisung „pragma restrict_references“, wobei es sich hierbei um eine sogenannte Compiler-Direktive handelt, mit der Sie für die betreffende Funktion verschiedenste Einschränkungen festlegen können. pragma restrict_references (function_name, WNDS [, WNPS] [, RNDS] [, RNPS]);

Verwenden müssen Sie diese Compiler-Direktive zusammen mit dem betreffenden Funktions- oder Prozedurnamen und den gewünschten Einschränkungen „WNDS“, „WNPS“, „RNDS“ oder „RNPS“. Dabei ist nur die Einschränkung „WNDS“ zusammen mit dieser pragma-Anweisung zwingend, die anderen Einschränkungen können wahlfrei verwendet werden. Diese Einschränkungen, deren genaue Beschreibung Sie der Tabelle 2.2 entnehmen können, sind notwendig, wenn Sie die im Paket verfügbare Funktion innerhalb eines SQL-Ausdrucks verwenden möchten. Die Ausführung von Funktionen innerhalb von SQL-Ausdrücken ist an bestimmte Spielregeln gebunden, beispielsweise dürfen innerhalb der Funktion keine Tabellendaten geändert werden. Bei gewöhnlichen Funktionen, dass sind die außerhalb eines Pakets, achtet Oracle beim kompilieren der SQL-Anweisung selbst auf die Einhaltung dieser Regel. Ist die Funktion jedoch Bestandteil eines Paketes, dann ist der Code zunächst versteckt. Aus dem Grund müssen Sie die Funktion für den Gebrauch innerhalb von SQL-Ausdrucken zertifizieren, was mit Hilfe der pragma-Anweisung passiert. In dem Fall achtet Oracle beim Anlegen der Funktion im Rahmen der Erstellung des Package bodies darauf, dass in den markierten Funktionen keine datenbankändernden Befehle verwendet werden. Einschränkung

Beschreibung

WNDS

(writes no database state) Es können in der Datenbank keine Tabellenänderungen durchgeführt werden. Wichtig, damit die Funktion beispielsweise in der select-Klausel verwendet werden kann.

RNDS

(reads no database state) Innerhalb der Datenbank können keine Tabellen gelesen werden.

142


Einschränkung

Beschreibung

WNPS

(writes no package state) Die globalen Paketvariablen können nicht verändert werden. Das erlaubt die Verwendung der Funktion in der whereKlausel einer SQL-Abfrage.

RNPS

(reads no package state) Die globalen Paketvariablen können nicht gelesen werden.

Tabelle 2.2: Optionen der restrict_references-Einstellung

Nachdem Sie nun das Package erstellt haben, müssen Sie im nächsten Schritt dessen Inhalt definieren. Bevor ich das konkrete Beispiel hier vorstelle und erkläre, möchte ich zunächst einmal die grundsätzliche Struktur (vgl. Listing 2.21) des Paketinhalts vorstellen. create or replace package body tollhaus as 1) Deklarieren lokaler Funktionen und Prozeduren function kleingross(in_c varchar2) return varchar2; 2) Programmierung der globalen Funktion function spiegeln (in_c varchar2) return varchar2 is begin end; 3) Programmierung der lokalen Funktion function kleingross(in_c in varchar2) return varchar2 is out_c varchar2(254); begin end; 4) Programmieren des Initialisierungsteils begin -- Initialisieren globaler Variablen -- Spezielle Startroutinen end; Listing 2.21: Schematischer Aufbau eines „Package bodies“

Das im Listing 2.21 gedruckte Schema eignet sich ganz gut, die prinzipielle Struktur eines Package bodies darzustellen und im folgenden Listing 2.22 finden Sie anschließend das vollständige Programm. Klar ist eigentlich, dass Package und Package body den gleichen Namen besitzen müssen. Den Rest finden Sie in der nun folgenden Aufzählung:


143

1. Deklarieren Sie alle lokalen Funktionen. Genau genommen müssen Sie dies nur dann tun, wenn Sie die Funktion schon vor der eigentlichen Programmierung in einem anderen Programmteil aufrufen. In unserem Beispiel wäre das genau dann der Fall, wenn Sie die Funktion kleingross erst an der mit 3. markierten Position erstellen, aber schon in dem spiegeln-programm verwenden müssen. Es schadet aber nicht, wenn Sie sich angewöhnen, zunächst alle lokalen Funktionen und Prozeduren aufzuzählen. 2. Programmieren Sie die globalen Funktionen und Prozeduren, also alle diejenigen, die im Package veröffentlicht wurden. 3. Erstellen Sie die lokalen Funktionen und Prozeduren. Natürlich ist die bisher genannte Reihenfolge wie in den meisten Fällen nicht zwingend einzuhalten. Es doch zu tun, schadet aber in keinem Fall. 4. Programmieren Sie bei Bedarf einen speziellen Initialisierungsabschnitt. Hierzu finden Sie am Ende der create package body-Anweisung einen entsprechenden begin..end Block. Dieser Block wird direkt nach dem Laden des Pakets ausgeführt und kann dazu genutzt werden, die globalen Variablen zu initialisieren oder spezielle Startroutinen aufzurufen. create or replace package body tollhaus as function kleingross(in_c varchar2) return varchar2; function spiegeln (in_c varchar2) return varchar2 is begin call_count := call_count +1; if mod(call_count, 2) = 0 then return system.spiegeln(in_c); else return kleingross(in_c) || '>' || to_char(call_count) || '' || to_char(call_count) || '' || to_char(call_count) || ' select name, gebdat, p.g_alter() as a, 2> p.g_buchzahl() as b, p.g_werte() as w 3> from menschen p 4> NAME GEBDAT -------------------------- ------------------Raymans 03-DEC-64 Raymans 27-DEC-65 Zschoge 13-JUL-62 Heger 12-MAY-69 4 rows selected.

A ----------35 34 38 31

B W -----------0 0 1 20 2 43 3 32.25

182


Varianten Ich möchte noch mal auf das Laden der Buchtabelle zurückkommen. In unserem Beispiel haben wir die Buchliste mit Hilfe individueller Änderungsabfragen erstellt, was in der Praxis natürlich nicht denkbar wäre, es sei denn, die zu ladende Tabelle besitzt wirklich nur eine Handvoll Datensätze. In Wirklichkeit stünden Sie jetzt vor der Herausforderung, eine wahrscheinlich als gewöhnliche Tabelle vorliegende Bücherliste in das Kollektionsobjekt zu übertragen, was mit Hilfe von PL/SQL-Sprachelementen eigentlich auch kein größeres Problem darstellt. Doch bevor wir uns eine Lösungsmöglichkeit für die eben beschriebene Aufgabe anschauen, erstellen wir zuerst einmal die relationale Hilfstabelle mit den gespeicherten Büchern (vgl. Listing 2.36). drop table h_buch; / create table h_buch ( name varchar2(30), vname varchar2(30), lfdnr number, titel varchar2(50), wert number ) tablespace usr; commit; / insert into h_buch values insert into h_buch values insert into h_buch values insert into h_buch values insert into h_buch values insert into h_buch values commit;

('Raymans','Irina', 1, 'Oracle Workshop', 20); ('Zschoge', 'Helgo', 1, 'dBASE für Fortgeschrittene', 20); ('Zschoge', 'Helgo', 2, 'Meine Rezepte', 23); ('Heger', 'Sascha', 1, 'Donald Duck', 5); ('Heger', 'Sascha', 2, 'Herr der Ringe', 9.30); ('Heger', 'Sascha', 3, 'Elementarteilchen', 17.95);

Listing 2.47: Erstellen und Füllen der Hilfstabelle zum automatischen Erzeugen der Buchlisten

Zum Laden dieser Buchliste erstellen wir die Funktion make_buchliste (vgl. Listing 2.48). Diese Funktion erhält zur Identifizierung den Namen und Vornamen des Menschen, für den es die vorhandenen Bücher aus unserer Hilfstabelle auslesen und die Bücherliste erstellen soll. create or replace function make_buchliste(name in varchar2, vname in varchar2) return buchliste is x_buchl buchliste; begin declare cursor sel_buecher(s_name varchar2, s_vname varchar2) is select lfdnr, titel, wert from h_buch


183

where name = s_name and vname = s_vname order by lfdnr; b_lfdnr integer; b_titel varchar2(50); b_wert number; begin x_buchl := buchliste(); open sel_buecher(name, vname); loop fetch sel_buecher into b_lfdnr, b_titel, b_wert; Exit when sel_buecher%notfound; x_buchl.extend; x_buchl(x_buchl.count) := buch(b_lfdnr, b_titel, b_wert); end loop; close sel_buecher; return x_buchl; end; end; / show errors; commit; Listing 2.48: Funktion zum Konstruieren eines Objekts aus einer Tabelle

Die Funktion enthält eine Reihe bisher noch nicht bekannter Befehle, weshalb ich im Folgenden auf einzelne Passagen des Programms näher eingehen möchte. Zunächst einmal finden Sie am Anfang der Funktion verschiedene Deklarationen. Dabei wird neben drei gewöhnlichen Variablen auch ein sogenannter Cursor definiert. cursor sel_buecher(s_name varchar2, s_vname varchar2) is select lfdnr, titel, wert from h_buch where name = s_name and vname = s_vname order by lfdnr;

Mehr Informationen zu einem solchen Cursor und zusätzliche Beispiele zu deren Verwendung finden Sie noch reichlich im weiteren Verlauf dieses Buches. An dieser Stelle sollen folgende Hinweise genügen: Der Cursor ermöglicht uns innerhalb der Funktion die spezifizierte SQL-Abfrage auszuführen. In unserem Fall handelt es sich dabei um eine parametrisierte Abfrage, d.h. zur Laufzeit werden die beiden Parameter s_name und v_name innerhalb der where-Bedingung mit ihren konkreten

184


Werten berücksichtigt. Außerdem erhält jeder Cursor einen Namen, mit dem er im weiteren Verlauf des Programms angesprochen werden kann. Damit die im Cursor definierte Abfrage ausgeführt wird, muss dieser zunächst geöffnet werden. Anschließend haben Sie die Möglichkeit, die abgefragten Daten innerhalb einer Schleife der Reihe nach (sequentiell) abzurufen. Nach dem Lesen des letzten Satzes liefert der Cursor einen entsprechend Status, durch den die Schleife beendet bzw. verlassen werden kann und spätestens am Ende Ihres Programms sollten Sie die geöffneten Cursor wieder schließen. Der nun folgende Auszug des Programms zeigt die hierzu benötigten Befehle. open sel_buecher(name, vname); loop fetch sel_buecher into b_lfdnr, b_titel, b_wert; Exit when sel_buecher%notfound; end loop; close sel_buecher;

Innerhalb der Schleife rufen Sie die vom Cursor gelieferten Datensätze mit Hilfe der fetch-Anweisung ab und speichern die in der zugehörigen Abfrage spezifizierten Spalten in die hierfür angelegten Variablen b_lfdnr, b_titel und b_wert. Was nun folgt, ist die Überführung dieser Werte in ein Buchobjekt, und letztendlich muss dieses Buchobjekt an die aktuelle Bücherliste angehängt werden. x_buchl.extend; x_buchl(x_buchl.count) := buch(b_lfdnr, b_titel, b_wert);

Die Bücherliste wird innerhalb der Funktion über die Variable x_buchl geführt bzw. am Ende der Funktion zurückgegeben. Damit in die aktuelle Liste ein neues Buch passt, wird sie zuerst mit Hilfe der Methode extend erweitert. Ohne spezielle Parameter erweitert diese Methode die Liste um genau ein Element und wie Sie aus dem ersten Teil des Satzes folgerichtig schließen können, bietet die extend-Methode verschiedene Varianten, mehrere Elemente auf einmal anzulegen oder sogar zu kopieren. Die Methode count haben Sie schon kennen gelernt. Sie liefert immer die aktuelle Zahl der in der liste enthaltenen Elemente, d.h. die Verwendung von x_buchl(x_buchl.count)

verschafft Ihnen Zugriff auf das letzte Element der Buchliste. Der rechts vom Gleichheitszeichen stehende Ausdruck konstruiert dabei mit Hilfe der drei gelesenen Variablen ein Buchobjekt, so dass im Ergebnis dem neuen Element der Liste ein Buch zugewiesen wird. Beachten Sie allerdings noch die folgende notwendige Anweisung, damit das hier beschriebene Programm funktioniert. x_buchl := buchliste();


185

Wie Sie schon wissen, liefert der Ausdruck buchliste() eine leere Büchersammlung und ist damit in der Lage entsprechende Variablen zu initialisieren. Ohne diese Initialisierung würden Sie bei der Programmausführung eine Fehlermeldung erhalten, da die impliziten Methoden wie count oder extend nur bei initialisierten Listen funktionieren. Sofern Sie kein großer Fan von geschachtelten Ausdrücken sind, so können Sie die Zuweisung des Buches in die Buchliste auch anders programmieren. Statt der Verwendung des buch-Konstruktors x_buchl(x_buchl.count) := buch(b_lfdnr, b_titel, b_wert);

können Sie über die Bücherliste auch direkt auf ein einzelnes Buchobjekt zugreifen und dessen Eigenschaften damit direkt auslesen bzw. verändern. x_buchl(x_buchl.count).lfdnr := b_lfdnr; x_buchl(x_buchl.count).titel := b_titel x_buchl(x_buchl.count).wert := b_wert

Das war auch schon alles. Was (vom Tag) noch übrig bleibt ist die neue Funktion noch schnell auszuprobieren. Erstellen Sie hierzu noch einmal die Hilfstabelle h_mensch, in die Sie alle vorhandenen Daten kopieren. Löschen Sie danach die Tabelle menschen, so dass die nachfolgende SQL-Anweisung die Tabelle zusammen mit den Bücherlisten auflädt. insert into menschen select name, vname, strasse, plz, ort, geschl, gebdat, make_buchliste(name, vname) from h_mensch; commit Listing 2.49: Aufladen der Tabelle „menschen“ zusammen mit den Bücherlisten

2.2.17 Tabelle (Tables) Jetzt sprechen wir über Tabellen, dem sicherlich zentralsten und wichtigsten Element der Schema-Objekte, denn ohne Tabellen ist die Speicherung irgendwelcher Daten in der Datenbank nicht möglich. Die Anlage neuer Tabelle erfolgt mit Hilfe der Anweisung create table. Daneben existieren die Befehle alter table und drop table, um vorhandene Definitionen zu bearbeiten bzw. zu löschen. Vereinfachend betrachtet, enthält der Befehl create table neben dem Namen der neuen Tabelle im Wesentlichen nur noch die Definition der anzulegenden Spalten, den zu verwendenen Tablespace und bei Bedarf auch eine Regel, wie die zum Speichern notwendigen Ausdehnungen des Segments angelegt werden sollen. create table ( ) <Storage-Klausel>;

186


Dabei können Sie die Storage-Klausel weglassen, wenn die Tabelle die im Tablespace verankerten Standardwerte verwenden soll. Die Vorgabe eines speziellen Tablespace kann ebenfalls entfallen. In dem Fall verwendet Oracle entweder den dem Benutzer zugeordneten Standardwert oder den Tablespace „system“. Speicherbelegung Im Folgenden möchte ich einmal etwas genauer auf die Speicherbelegung des zu einer Tabelle gehörenden Segments eingehen. Wie schon gesagt, können Sie mit Hilfe der Storage-Klausel festlegen, wie und wie viele Segmentbereiche (vgl. Abb. 1.5) zum Speichern der Tabellendaten angelegt werden. Den letzten Teil des vorhergehenden Satzes könnte man auch allgemeiner formulieren, denn er gilt nicht nur für Tabellen, sondern überall da, wo Sie eine storage-Klausel angeben können (z.B. Indices, Snapshots und Rollback-Segmente). Die einzelnen Ausprägungen dieser Klausel werden dabei hinter dem Wörtchen storage in Klammern spezifziert. storage (initial .. next .. minextents .. maxextents .. pctincrease ..)

Hinter den verschiedenen Schlüsselwörtern müssen Sie die jeweils benötigten Werte vorgeben. Ansonsten ist neben der Bedeutung der einzelnen Ausprägungen eigentlich nur noch wichtig, dass Sie deren Reihenfolge zum einen wahlfrei und zum anderen auch einzeln bzw. in beliebiger Kombination verwenden können. Die genaue Bedeutung der einzelnen storage-Parameter können Sie der Tabelle 2.4 entnehmen. Storage-Klausel

Bedeutung

initial

Legen Sie hier bei Bedarf die Größe des ersten Segmentbereichs in Kilo(K) oder Megabyte (M) fest.

next

Mit diesem Parameter können Sie die Größe der weiteren Segmentbereiche (Extents) in Kilo- (K) oder Megabyte (M) festlegen.

minextents

Hier können Sie die Anzahl der Extents festlegen, die beim Anlegen der Tabelle bzw. des Objekts erzeugt werden. Standardmäßig legt Oracle immer ein Extent an, denn ohne einen einzigen Segmentbereich ist das Objekt gar nicht vorhanden.

maxextents

Geben Sie mit diesem Parameter die maximale Anzahl der zusätzlichen Segmentbereiche vor oder verwenden Sie statt einer Zahl das Wörtchen „unlimited“, damit die Tabelle bzw. das Objekt uneingeschränkt wachsen kann.

pctincrease

Die hier vorgegebene Zahl wird als Prozentwert interpretiert, um die jeder neue Extent vergrößert wird. Der Standardwert hierfür beträgt 50%. Sollen die neuen Segmente nicht automatisch vergrößert werden, dann müssen Sie pctincrease zusammen mit dem Wert 0 verwenden.

Tabelle 2.4: Beschreibung der storage-Klausel

Einen guten Überblick über alle möglichen Varianten erhalten Sie im Übrigen auch wieder mit Hilfe des Schema-Managers bzw. DBA Studios, in dem Sie dort beispielsweise verschiedene Optionen bzw. deren Kombination auswählen und anschließend die von dem Programm generierte SQL-Anweisung betrachten (vgl. Abb. 2.14).


187

Abbildung 2.14: Generieren einer storage-Klausel mit Hilfe des Schema-Managers

Zwei weitere Klauseln, die Sie bei der Anlage einer Tabelle oder auch anderer datenspeichernder Objekte verwenden können, heißen pctfree bzw. pctused. Mit pctfree reservieren Sie in jedem Extent des Segments eine Art Platzreserve in Prozent, die dem Wachstum durch Änderungen von bestehenden Datensätzen vorbehalten ist. Standardmäßig verwendet Oracle für diesen Wert 10%, d.h. nach dem vollständigen Auffüllen des Extents sind immer noch 10% des Platzes frei, der anschließend für Änderungen der in dem Segmentbereich gespeicherten Daten verwendet wird. Mit der anderen pctused-Klausel legen Sie eine Art Schwellenwert (in Prozent) fest, der vorgibt, wie weit die Belegung eines einstmals vollen Segmentbereichs wieder sinken muss, bevor wieder neue Datensätze hineingeschrieben werden. Der Standardwert für diesen Parameter liegt bei 40 Prozent. Die pctused-Klausel verhindert somit, dass der Status eines Extents permanent zwischen voll und leer wechselt, denn entsprechend dem Standardwert beginnt Oracle erst wieder damit neue Datensätze in den Extent zu schreiben, wenn seine Belegung unter 40% sinkt. Danach wird er allerdings wieder so lange mit neuen Datensätzen gefüllt, bis der in pctfree festgelegte Wert erneut erreicht wird. Unterlegen wir das Ganze mal mit Hilfe eines kleinen Beispiels. Legen Sie hierzu die Tabelle „lohnarten“ mit Hilfe des folgenden Skripts (vgl. Listing 2.50) an.

188


drop table lohnarten; create table lohnarten (la varchar2(3)) tablespace usr storage (initial 4k next 10k minextents 4 pctincrease 0); commit; Listing 2.50: Anlage der Tabelle „lohnarten“ mit spezieller Speicherbelegungsregel

Mit Hilfe einer Abfrage auf die View dba_segments können Sie die definierte Speicherbelegung einer jeden Tabelle bzw. eines jeden Segments abfragen (vgl. Listing 2.51). Bei einer solchen Abfrage können Sie je nach Bedarf den Namen des Eigentümers, den Tablespace oder den Namen des Segments, das ist beispielsweise der Name der Tabelle oder des Index oder den Segmenttyp (z.B. „TABLE“ oder „INDEX“) als einschränkende Kriterien verwenden. SQLWKS> select bytes, blocks, extents, initial_extent, next_extent, 2> min_extents, max_extents, pct_increase 3> from dba_segments where segment_name = 'LOHNARTEN'; BYTES BLOCKS EXTENTS INITIAL NEXT_ MIN_ MAX__INCREA ----- ------- ------- ----------- ---------- -------- -------- -------34816 17 4 4096 10240 4 121 1 1 row selected. Listing 2.51: Analyse des Segments „lohnarten“ mit Hilfe der View dba_segments

In unserem Beispiel beträgt die Größe des ersten Extents also 4096 Byte (4k). Entsprechend der Konfiguration der Datenbankinstanz (db_block_size = 2048) war die Blockgröße auf 2048 Bytes eingestellt, also entspricht die Größe des ersten Extents genau Blöcken. Sofern Sie die Speicherbelegung einmal nachrechnen möchten, dann sollten Sie Ihre vorgegebenen Werte zunächst immer in Blöcken umrechnen, ggf. aufrunden (es gibt keine halben Blöcke) und die erhaltene Blockzahl danach wieder mit der konfigurierten Blockgröße multiplizieren. Mit der Anlage der Tabelle wurden aufgrund unserer storage-Klausel drei weitere Extents angelegt. Für den Parameter pctincrease hatten wir den Wert 0 vergeben, so dass alle Segmenterweiterungen die gleiche Größe besitzen. Jedes dieser weiteren Extents wird mit einer Größe von jeweils 10k angelegt bzw. je 5 Blöcken angelegt. Somit belegt das ganze Segment bzw. die Tabelle insgesamt 17 Blöcke, was zusammen die Summe von 34816 Byte ergibt. Wie bei den meisten anderen Dingen, so ist auch hierbei die Entscheidung über viel oder wenig letztendlich Ansichtssache. Dennoch, so finde ich, sind 34k für eine leere Tabelle ganz schön viel Platz. Sie können die Erweiterungen (Extents) einer Tabelle auch mit Hilfe einer Abfrage auf die Tabelle dba_extents (vgl. Listing 2.52) untersuchen. Der wesentliche Unterschied zu der vorhin gezeigten Abfrage ist, dass hierbei jeder Bereich des Segments einzeln angezeigt wird.


189

SQLWKS> select extent_id, bytes, blocks 2> from dba_extents 3> where segment_name = 'LOHNARTEN'; EXTENT_ID BYTES BLOCKS ---------- ---------- ---------0 4096 2 1 10240 5 2 10240 5 3 10240 5 4 rows selected. Listing 2.52: Analyse des Segments „lohnarten“ mit Hilfe der View dba_extents

Wie leer eine Tabelle bzw. das zugehörige Segment wirklich ist, können Sie im Nachhinein übrigens mit Hilfe des Pakets dbms_space feststellen, denn dort ist die Prozedur unused_space enthalten, mit der Sie den freien Platz in einem Segment ermitteln können (vgl. Listing 2.53). Diese Paketprozedur erhält als Eingabeparameter im Wesentlichen den Namen des zu untersuchenden Segments und liefert die Belegungsdaten in Form verschiedener Ausgabeparameter zurück. Für uns bedeutet das, dass wir die Prozedur innerhalb eines PL/SQL-Skripts verwenden müssen, in dem wir die Ausgabeparameter als Variable definieren und nach dem Aufruf der Prozedur für deren Anzeige am Bildschirm sorgen. set serveroutput on; declare total_blocks number; total_bytes number; unused_blocks number; unused_bytes number; last_used_fid number; last_used_id number; last_used_block number; begin dbms_space.unused_space('SYSTEM', 'LOHNARTEN','TABLE', total_blocks, total_bytes, unused_blocks, unused_bytes, last_used_fid, last_used_id, last_used_block); dbms_output.put_line('total_blocks to_char(total_blocks)); dbms_output.put_line('total_bytes to_char(total_bytes)); dbms_output.put_line('unused_blocks to_char(unused_blocks)); dbms_output.put_line('unused_bytes to_char(unused_bytes)); dbms_output.put_line('last_used_extend_file_id to_char(last_used_fid));

: ' || : ' || : ' || : ' || : ' ||

190


dbms_output.put_line('last_used_extend_block_id: ' || to_char(last_used_id)); dbms_output.put_line('last_used_block : ' || to_char(last_used_block)); end; Listing 2.53: Verwenden von dbms_space.unused_space in einem Skript

In dem Skript werden verschiedene Variablen für die im Paket dbms_space vorhandene Prozedur unused_space deklariert und anschließend wird die Prozedur aufgerufen. Die Ausgabe der einzelnen Ergebnisse erfolgt danach mit Hilfe der Prozedur put_line aus dem Paket dbms_output. Diese Prozedur wird uns im weiteren Verlauf des Buches noch häufiger begegnen. Mit ihr können Sie innerhalb von PL/SQLProgrammen Meldungen sammeln und am Ende der Prozedur am Bildschirm ausgeben. Oftmals wird sie auch verwendet, um mit ihrer Hilfe in einer Prozedur eine Ablaufverfolgung durchzuführen. dbms_output.put_line('irgendein Text')

Mit Hilfe der Prozedur können Sie eine beliebige Zeichenfolge, die innerhalb der Klammern vorgegeben wird, in einen speziellen Ausgabepuffer kopieren. Dieser Ausgabepuffer wird am Ende der Prozedur oder des Skripts am Bildschirm ausgegeben, wobei Letzteres nur dann passiert, wenn Sie die Serverausgabe eingeschaltet haben. set serveroutput on;

Diese Serverausgabe können Sie mit einem speziellen set-Kommando einschalten, so dass am Ende unseres Skripts folgende Informationen am Bildschirm erscheinen: total_blocks : total_bytes : unused_blocks : unused_bytes : last_used_extend_file_id : last_used_extend_block_id: last_used_block :

17 34816 16 32768 3 12 1

In unserem Beispiel sind in dem Segment „lohnarten“ zur Zeit also über 30k frei. Wenn Sie die wieder freigeben wollen, dann müssen Sie sich in unserem Fall zunächst einmal von der minextents-Klausel trennen, denn die würde aufgrund ihrer aktuellen Einstellung jegliche Freigabeaktivitäten verhindern. alter table lohnarten storage (minextents 1); commit;


191

Die Änderung der Speicherbelegungsregel erfolgt mit Hilfe einer alter-Anweisung und da es sich in unserem Beispiel um eine Tabelle handelt, heißt der vollständige Befehle entsprechend alter table. Anschließend erfolgt die Vorgabe einer neuen storage-Klausel, wobei es hierbei ausreicht, nur die zu ändernden Parameter der Klausel vorzugeben. Beachten Sie hierbei allerdings, dass Sie gerade nur die Regel zur Speicherbelegung verändert haben, d.h. in der Datenbank ist in Bezug auf das Segment sonst noch gar nichts passiert. In der Praxis wird die storage-Klausel für existierende Objekte häufig zusammen mit den Parametern pctincrease und maxextents verwendet, um im laufenden Betrieb die Vergrößerung neuer Erweiterungen (Extents) zu verändern bzw. die zulässige Anzahl dieser Erweiterungen zu vergrößern. Im nächsten Schritt geben wir den nicht mehr benötigten Speicherplatz wieder frei. Hierzu verwenden wir wiederum die Anweisung alter table zusammen mit der Klausel dellocate unused. alter table lohnarten deallocate unused keep 7k; commit;

In unserem Beispiel spezifizieren wir zusätzlich die optionale Erweiterung „keep 7k”, die dazu führt, dass Oracle nicht den gesamten freien Speicher freigibt, sondern mindestens 7k bleiben für das gesamte Segment reserviert. Wenn Sie nach Ausführung dieser Anweisungen das Segment noch einmal mit Hilfe der vorgestellten Methoden analysieren, dann werden Sie feststellen, dass Oracle die Extents mit der Id 2 und 3 gelöscht hat. Die Ausdehnung mit der Id 1 konnte aufgrund unserer keep-Vorgabe nicht gelöscht werden, allerdings wurde es entsprechend gekürzt. Ohne die keep-Klausel wäre auch dieser erste Zusatzextent aus der Datenbank gelöscht worden. SQLWKS> select extent_id, bytes, blocks 2> from dba_extents 3> where segment_name = 'LOHNARTEN'; EXTENT_ID BYTES BLOCKS ---------- ---------- ---------0 4096 2 1 6144 3 2 rows selected. total_blocks : total_bytes : unused_blocks : unused_bytes : last_used_extend_file_id : last_used_extend_block_id: last_used_block :

5 10240 4 8192 3 12 1

192


Anhand des Beispiels der Tabellen bin ich nun einmal etwas ausführlicher auf die Speicherbelegung der Segmente eingegangen. Wie schon mehrfach angedeutet, gilt das hier Gesagte allerdings nicht nur für Tabellen, sondern eben für alle mit Hilfe von Segmenten gespeicherten Daten, d.h. die hier beschriebenen Möglichkeiten sind auch bei den Indices, Rollback-Segmenten oder Snapshots verfügbar. Beispiele Die einfachste Form des Befehls create table besteht also aus einem Tabellennamen, einer oder mehreren Spaltendefinitionen und dem Ort bzw. der Regel zur Speicherbelegung. Hierzu haben Sie im bisherigen Verlauf dieses Workshops schon mehrfach Beispiele gesehen. Als Erstes legen wir noch einmal die Lohnartentabelle (vgl. Listing 2.54) an, und sorgen anschließend auch sofort mit Hilfe einzelner insertAnweisungen für ein paar Daten in dieser Tabelle. drop table lohnarten; create table lohnarten( la varchar2(3), la_text varchar2(50) ) tablespace usr storage(initial 4k minextents 1); insert into insert into insert into insert into insert into commit;

lohnarten lohnarten lohnarten lohnarten lohnarten

values values values values values

('100','Grundgehalt'); ('110','Übertraifliche Zulage'); ('120','Sonstige Zulage'); ('200','Überstunden'); ('300','Urlaubsgeld');

Listing 2.54: Anlegen der Tabelle „lohnarten“

Bei vielen Standardprodukten entspricht die Anlage von Tabellen genau dieser Struktur. Das ist vor allem dann der Fall, wenn die zum Arbeiten benötigten Tabellen mit Hilfe der Standardsoftware angepasst und erzeugt werden können. Der Grund dafür ist auch einleuchtend, denn, wie hier beschrieben, können in nahezu allen relationalen Datenbanken Tabellen angelegt werden, wenn man mal von der Vorgabe des Tablespaces und der storage-Klausel absieht. Oracle bietet allerdings noch eine Reihe weiterer Möglichkeiten, schon mit der Tabellendefinition auch Indices oder bestimmte Regelwerke an- bzw. festzulegen. Wie man explizit Indices anlegen kann, das haben Sie bei der Behandlung des entsprechenden Schema-Objekts schon gesehen. Im nächsten Schritt geht es darum, im Rahmen der Tabellendefinition implizite Indices anzulegen. Bei solchen Optionen, gleichgültig ob Indices, Regeln oder Abhängigkeiten spricht man üblicherweise von sogenannten Constraints (Zwänge). Sie werden entweder im Rahmen der Tabellendefinition oder nachträglich mit Hilfe einer alter tableAnweisung definiert. Die Varianten, Verfügbarkeit und Anwendung der verschiedenen Constraints ist in den unterschiedlichen Datenbanksystemen, im Unterschied zur eigentlichen create table-Anweisung sehr verschieden.


193

Generell folgt hinter den Schlüsselwörtern create table der Name der Tabelle und danach folgt in Klammern eine Aufzählung der benötigten Spalten. Die einzelnen Spaltendefinitionen werden dabei durch Komma getrennt. Jede einzelne Spaltendefinition besteht wiederum aus dem Spaltennamen, dem der benötigte Datentyp folgt. Danach folgen zwei weitere optionale Parameter. Zum einen können Sie festlegen, ob eine Spalte überhaupt mit einem Wert gefüllt werden muss oder ob sie auch leer (null) bleiben darf, wobei Letzteres dem Standardwert von Oracle entspricht. Zum anderen können Sie die Spalte einen Standardwert definieren. Damit ergibt sich insgesamt folgendes Schema zur Definition jeder einzelnen Spalte in einer Tabelle: <Spaltenname> [default <Standardwert>] [null|not null]

Die am meisten verwendeten Datentypen sind sicherlich varchar2 für das Speichern variabel langer Zeichenfolgen, date zum Speichern von Datums- und/oder Zeitwerten und number ggf. mit Vorgabe der möglichen Vor- bzw. Nachkommastellen (number(v,n)). zeichenspalte varchar2(10), nummer number, nummermitlaenge number(7,2), datum date

Als Standardwert dürfen Sie im Rahmen der Spaltendefinition einen beliebigen gültigen Ausdruck verwenden. Der darf allerdings keinen Bezug auf andere Spalten der Tabelle bzw. verschiedene vom System vorgehaltene Systemspalten (z.B. rownum) enthalten und muss in Bezug auf den Datentyp und Länge zur zugehörigen Spalte passen. Meistens werden als Standardwerte irgendwelche Konstanten (z.B. ’100’ oder 43) bzw. die Variable sysdate zum Einmelden des Systemdatums verwendet. Beachten Sie allerdings, dass die Verwendung des Standardwerts beim Einfügen neuer Datensätze nur dann greift, wenn Sie das zugehörige Feld in der insert-Anweisung nicht spezifizieren. zeichenspalte varchar2(10) default 'XXL', nummer number default 5*2-2, nummermitlaenge number(7,2) default (–33.2), datum date default sysdate

Wenn Sie eine Spalte zusammen mit der Regel „not null“ anlegen, dann müssen Sie ihr beim Einfügen eines Datensatzes oder beim Ändern immer einen konkreten Wert zuweisen. Zeichenfolgen müssen in dem Fall beispielsweise mindestens ein Leerzeichen, numerische Felder mindestens die Zahl 0 und Datumsfelder irgendein gültiges Datum enthalten. zeichenspalte varchar2(10) default 'XXL' not null, nummer number default 5*2-2 not null, nummermitlaenge number(7,2) default –33.2 not null, datum date default sysdate not null

194


Manche Datenbanksystem unterscheiden sich in Bezug auf die Vergabe eines Standardwertes zusammen mit der Option „not null“. Bei manchen Systemen schließen sich diese beiden Option sogar gegeneinander aus, da schon die insert-Anweisung eine Verletzung der Klausel „not null“ erkennt und die Vergabe des Standardwertes erst später erfolgt. In Oracle ist das anders, d.h. werden beide Optionen zusammen verwendet, dann greift der Standardwert, wenn Sie die zugehörige Spalte beim insert-Befehl weglassen und auf der anderen Seite haben Sie nicht die Möglichkeit, die Spalte im Rahmen einer update-Anweisung auf „null“ zu setzen. Indices Im folgenden Beispiel legen wir für unsere Tabelle „lohnarten“ im Nachhinein einen Primärschlüssel mit Hilfe einer constraint-Klausel (vgl. Listing 2.55) an. Der Vorteil das mit Hilfe einer solchen Klausel anstelle eines gewöhnlichen eindeutigen Indices zu tun ist, dass Oracle diese Definition bei anderen Aktivitäten berücksichtigen und sein Verhalten dementsprechend optimieren kann. alter table lohnarten drop constraint lohnarten_pk; commit; alter table lohnarten add constraint lohnarten_pk primary key (la) using index tablespace indx storage(initial 2k next 4k) ; commit; Listing 2.55: Löschen und Anlegen eines Primärschlüssels

Mit dem Beispiel schlagen wir gleich zwei Fliegen mit einer Klappe. Das nachträgliche Löschen oder Anlegen von Constraints erfolgt immer mit Hilfe des Befehls alter table zusammen mit der Klausel drop constraint bzw. add constraint, je nachdem, ob Sie eine vorhandene Regel löschen oder eine neue Regel anlegen wollen. Außerdem besitzen die verschiedenen Constraints einen bei der Anlage festgelegten Namen, mit dessen Hilfe sie beispielsweise wieder gelöscht werden können. Die Schlüsselwörter „using index“ sind optional und leiten bei deren Verwendung die Spezifizierung von Speichervorgaben für das zugehörige Indexsegment ein. Hier können Sie also den Tablespace vorgeben oder mit Hilfe der storage-Klausel die Speicherbelegung für den Index vorgeben. In unserem Beispiel (Listing 2.55) löschen wir zunächst das Constraint mit dem Namen „lohnarten_pk“. Anschließend legen wir es erneut an, wobei wir den Typ „primary key“ zur Anlage eines Primärschlüssels verwenden. Hierbei müssen Sie im Anschluss alle zum Primärschlüssel gehörenden Felder in Klammern aufzählen. Das hier durchgeführte Szenario, erst drop dann add, entspricht übrigens der üblichen Vorgehensweise beim Ändern, da es eine Anweisung der Art „change constraint“ nicht gibt.


195

Natürlich hätten wir den Primärschlüssel der Tabelle „lohnarten“ auch gleich bei deren Anlage definieren können, wobei wir die zugehörigen Anweisungen in dem Fall folgendermaßen erweitern müssen: create table lohnarten( la varchar2(3), la_text varchar2(50), constraint lohnarten_pk primary key (la) using index tablespace indx storage(initial 2k next 4k) ); tablespace usr storage(initial 4k minextents 1);

Wie Sie an dem Beispiel sehen, werden Constraints, wenn Sie bei der Anlage von Tabellen spezifiziert werden, quasi wie zusätzliche Extraspalten angelegt. Dabei ist es gleichgültig, ob Sie die Constraints am Anfang, zwischen den einzelnen Spalten oder ganz am Ende, d.h. nach der letzten Spaltendefinition angeben. Ich persönlich finde es übersichtlicher, wenn sie am Ende stehen, aber das ist wie so vieles im Leben sicherlich mal wieder Geschmacksache. Primärschlüssel kann es, genau wie in dem entsprechenden Kinofilm, nur einen geben. Insgesamt können eindeutige Felder oder Feldkombinationen natürlich mehrfach auftreten und anstelle zusätzlicher expliziter eindeutiger Indices können Sie auch beliebige weitere unique-Constraints definieren, was eigentlich fast genauso wie die Anlage des Primärschlüssels funktioniert: constraint unique () using index ...

Überwachung von Spalten Im Rahmen der Spaltendefinition haben Sie mit der „null“ bzw. „not null“ Option schon eine Art Miniüberwachung der Spaltenwerte kennen gelernt. Hier geht es jetzt um die Erstellung sogenannter Check-Constraints, mit deren Hilfe sich komplexere Prüfungen für einzelne oder eine Kombination von Spalten definieren lassen. Als Demonstrationsobjekt soll hierzu eine weitere Tabelle „bezuege“ (vgl. Listing 2.56) erstellt werden, in der später die einzelnen Gehaltsbestandteile jedes Mitarbeiters gespeichert werden können. Bei der Definition der Tabelle werden wir auch gleich einige Regeln zur Überwachung der enthaltenen Spalten anlegen. drop table bezuege; create table bezuege( persnr varchar2(10) la varchar2(3) stunden number(5,2) default tage number(5,2) default lohnsatz number(5,2) default betrag number(9,2) default

0 0 0 0

not not not not not not

null, null, null, null, null, null,

196


constraint bezuege_pk primary key (persnr, la), constraint check_lohnsatz check (lohnsatz >= 0), constraint check_record check (betrag0 and (tage=0 and stunden=0) or betrag=0 and (tage0 or stunden0)) ) tablespace usr; commit; Listing 2.56: Anlage der Tabelle „bezuege“ mit verschiedenen Feldprüfungen

In unserem Beispiel kann ein Gehaltsbestandteil neben einem Lohnsatz immer aus der Vorgabe eines Betrags oder einer Kombination aus Tagen und Stunden bestehen. Der Lohnsatz darf dabei nur positive Werte annehmen, was wir mit Hilfe der Regel check_lohnsatz festlegen. Die andere Regel heißt check_record und überprüft die Felder betrag, tage und stunden, so dass die oben beschriebene Eingaberegel beachtet wird. Die Verarbeitung eines check-Constraints entspricht im Prinzip einer wenn- bzw. ifBedingung, d.h. die zugehörige Regel gilt als erfüllt, wenn der spezifizierte Ausdruck den Wahrheitswert „wahr“ zurückliefert. Das Hinzufügen oder Löschen solcher Prüfungen erfolgt natürlich wieder mit Hilfe der alter table-Anweisung entsprechend der bei den Indexen beschriebenen Verfahrensweise. Integritätsprüfungen Wenn Sie noch unerfahren im Umgang mit relationalen Datenbanksystemen sind, dann stellen Sie sich beim Lesen der Überschrift vielleicht die Frage, was hiermit gemeint sein könnte. Genau genommen geht es bei der Überschrift um das Thema der sogenannten „referenziellen Integrität“. Ich habe mal wieder keine Kosten und Mühen gescheut und bin auf die Suche nach einer einfachen aber dennoch halbwegs zutreffenden Erklärung gegangen. Was ist referenzielle Integrität? Referenzielle Integrität ist ein Regelsystem, mithilfe dessen die Datenbank (Oracle) sicherstellt, dass Beziehungen zwischen Datensätzen in Detailtabellen gültig sind und dass verknüpfte Daten nicht versehentlich gelöscht oder geändert werden. Sofern Ihnen dieser Erklärungsversuch noch zu oberflächlich ist, dann wird das Ganze sicherlich klarer, wenn wir es im Rahmen eines Beispiels betrachten. Betrachten Sie hierzu noch einmal unsere beiden bisher angelegten Tabellen „lohnarten“ und „bezuege“ (vgl. Abb. 2.15).


197

bezuege lohnarten persnr la tage stunden lohnsatz betrag

la la_text

Fremdschlüssel, der auf der „lohnarten“-Tabelle beruht. Abbildung 2.15: Beziehungen verknüpfter Tabellen

In unserem Beispiel werden die einzelnen Bezüge mit Hilfe einer Lohnart gespeichert. Dabei soll sichergestellt werden, dass die verwendete Lohnart überhaupt gültig ist bzw. existiert. Das wäre zwar sicherlich auch im Rahmen einer Prüfung auf konstante Werte möglich, doch hätte ein solches Verfahren den Nachteil, dass Sie mit jeder Lohnartenerweiterung die Tabellendefinition anpassen müssten. Außerdem wäre für den Endanwender nicht transparent, für welche Lohnarten in der Tabelle eine Prüfung stattfindet bzw. welche Lohnarten vielleicht versehentlich vergessen wurden. Komfortabler und auch flexibler wäre da schon ein Verfahren, das diese Prüfung mit Hilfe der Lohnartentabelle vornimmt, d.h. alle in der Lohnartentabelle definierten Schlüssel dürfen auch in der Tabelle „bezuege“ vorkommen. In dem Fall verweist (referenziert) die Tabelle „bezuege“ über das Feld „la“ auf die Lohnartentabelle und leiht sich bei dieser quasi deren Schlüssel aus (Fremdschlüssel), d.h. bei dem Lohnartenfeld („la“) handelt es sich in der Tat um einen fremden Schlüssel aus der Lohnartentabelle. Das Verfahren der referenziellen Integrität verlangt neben dieser noch recht einfachen Werteprüfung mittels Referenztabelle jedoch auch noch eine Rückkopplung aus dieser Tabelle zu den jeweiligen Fremdschlüsseln. Wird beispielsweise eine Lohnart gelöscht, dann darf das nur möglich sein, wenn diese nirgendwo mehr als Fremdschlüssel benötigt wird. Das Gleiche gilt natürlich auch, wenn eine Lohnart in der Referenztabelle geändert wird. Das zur Durchführung einer solchen Prüfung verwendete Constraint heißt sprechenderweise foreign key und wird prinzipiell wie die anderen bisher besprochenen Regeln verwendet (vgl. Listing 2.57). drop table bezuege; create table bezuege( persnr varchar2(10) la varchar2(3)

not null, not null,

198

stunden number(5,2) tage number(5,2) lohnsatz number(5,2) betrag number(9,2)


default default default default

0 0 0 0

not not not not

null, null, null, null,

constraint bezuege_pk primary key (persnr, la), constraint check_lohnsatz check (lohnsatz >= 0), constraint check_record check (betrag0 and (tage=0 and stunden=0) or betrag=0 and (tage0 or stunden0)), constraint check_la foreign key (la) references lohnarten(la) ) tablespace usr; commit; Listing 2.57: Anlegen der Tabelle zusammen mit Integritäts-Constraints

Selbstverständlich können Sie die Regel auch wieder im Nachhinein mit Hilfe einer alter table-Anweisung hinzufügen. In jedem Fall müssen Sie hinter den Schlüsselwörtern foreign key die zu überwachenden Felder in Klammern vorgeben. Mit Hilfe des Schlüsselworts references leiten Sie den Verweis auf die Prüftabelle ein, indem Sie deren Namen dahinter vorgeben. Zum Schluss folgen dann in Klammern die entsprechenden Spaltennamen aus der Prüftabelle. Damit ergibt sich das im Folgenden gezeigte Schema: foreign key (feld1 [, feld2] ...) references (rfeld1 [, rfeld2] ...)

Beachten Sie weiterhin, dass die Referenzierung auf eine solche Prüftabelle nur möglich ist, wenn dort für die einzelnen Spalten ein Primärschlüssel oder zumindest ein eindeutiger Index angelegt ist. Selbst ohne diesen Zwang wäre die Anlage eines solchen Indexes naheliegend, damit der Zugriff auf die Prüftabelle entsprechend schnell durchgeführt werden kann. Genau genommen muss Oracle wegen des Indexes sogar gar keinen Zugriff auf die eigentliche Tabelle machen, denn schon mit der Existenz des Indexeintrags ist die Überwachungsregel erfüllt. Halten wir an dieser Stelle mal kurz inne und probieren das Ganze einfach mal aus, bevor wir unser Konstrukt im Rahmen des weiteren Verlaufes des Kapitels vielleicht wieder zerpflücken. So können Sie die beiden nachfolgenden Datensätze beispielsweise problemlos einfügen, da hierbei alle definierten Regeln erfüllt werden. insert into bezuege values ('4711','100',0,0,0,1000); insert into bezuege values ('4711','300',4,3.5,0,0);

Die drei nun folgenden Datensätze können sie nicht in die Datenbank einfügen, da hierbei immer eine der definierten check-Constraints verletzt wird. insert into bezuege values ('4712','100',3,0,0,1000); insert into bezuege values ('4712','300',0,3.5,0,1); insert into bezuege values ('4712','300',0,0,-100,1);


199

Im ersten Fall werden die Felder Tage und Betrag und im zweiten Fall die Felder Stunden und Betrag gleichzeitig bestückt, was entsprechend der Regel check_record verboten ist. Mit dem letzten Datensatz wird versucht, einen negativen Lohnsatz zu speichern, was durch die Regel check_lohnsatz verhindert wird. Mit Hilfe der nächsten beiden Datensätze versuchen wir nun Datensätze mit einer ungültigen Lohnart einzufügen, was aufgrund der Regel check_la ebenfalls verhindert wird. insert into bezuege values ('4712','101',0,0,0,1000); insert into bezuege values ('4712','301',4,2.5,0,0);

Als letzten Schritt greifen wir unser System nun noch von der Lohnartenseite her an, indem wir versuchen, eine verwendete Lohnart zu löschen bzw. umzuschlüsseln. delete lohnarten where la = '100'; update lohnarten set la = '301' where la = '300';

Beide Änderungen werden aufgrund der Regel check_la verhindert. Die Lohnarten 100 und 300 sind in der Tabelle bezuege vorhanden und können deshalb in der Lohnartentabelle weder gelöscht noch umgeschlüsselt werden. Das Löschen oder Ändern nicht verwendeter Lohnarten funktioniert dahingegen auch weiterhin einwandfrei, wie das nun folgende letzte Beispiel zeigt. delete lohnarten where la = '110'; update lohnarten set la = '121' where la = '120';

Nachträgliches Anlegen von Prüfungen Wie ich schon angedeutet habe, können die soeben beschriebenen Constraints zur Überprüfung der in den Tabellen gespeicherten Daten auch im Nachhinein mit Hilfe einer entsprechenden alter table-Anweisung erstellt werden. Für jede zu löschende Regel müssen Sie dabei eine drop- und für jedes neue Constraint eine entsprechende add-Klausel verwenden (vgl. Listing 2.58). alter table bezuege add constraint bezuege_pk primary key (persnr, la) add constraint check_lohnsatz check (lohnsatz >= 0) add constraint check_record check (betrag0 and (tage=0 and stunden=0) or betrag=0 and (tage0 or stunden0)) add constraint check_la foreign key (la) references lohnarten(la) ; commit; Listing 2.58: Nachträgliches Anlegen von Constraints

Beim nachträglichen Anlegen solcher Prüfregeln führt Oracle diese zunächst auf den gesamten Datenbestand aus und erst nach der erfolgreichen Durchführung aller Prüfungen werden die neuen Constraints in der Tabelle installiert. Falls das stört, dann können Sie die Prüfungen mit einer speziellen Klausel anlegen, so dass nur alle neuen oder geänderten Datensätze geprüft werden.

200


add constraint check_la foreign key (la) references lohnarten(la) enable novalidate

Diese besondere Klausel heißt enable novalidate. Standardmäßig werden neue Constraints mit der Klausel enable validate angelegt, so dass die oben beschriebene Vorabprüfung durchgeführt wird. Neben diesen beiden Varianten existiert auch noch die Klausel disable, die zwar zur Anlage, jedoch nicht zur Aktivierung der Prüfroutine führt. add constraint check_la foreign key (la) references lohnarten(la) disable

Generell können Sie die Constraints im Nachhinein je nach Bedarf ein- oder ausschalten, was wieder mit Hilfe einer entsprechenden alter table-Anweisung möglich ist. alter table bezuege enable validate constraint check_lohnsatz disable constraint check_record; commit;

Hinzufügen, Ändern von Spalten Natürlich können auch vorhandene Tabellen nachträglich in Ihrer Struktur verändert werden, jedoch haben Sie hierbei nur sehr eingeschränkte Möglichkeiten:

X X X X X

Das Ändern des Datentypes (z.b. von varchar2 in date) ist nur möglich, wenn die zugehörige Spalte in allen Datensätzen den Wert „null“ enthält. Das Gleiche gilt auch, wenn Sie die definierte Länge verkürzen wollen. Das Verlängern eines Datenfeldes ist dagegen immer möglich. Ein eventuell für eine Spalte definierte Standardwert kann nachträglich geändert werden. Das hat natürlich keine Auswirkungen auf die schon gespeicherten Datensätze, sondern wirkt sich erst bei anschließend neu eingefügten Sätzen aus. Die Option null bzw. not null kann ebenfalls im Nachhinein verändert werden. Allerdings wird beim Ändern der Option auf die Einstellung not null die gesamte Tabelle entsprechend geprüft, d.h. Sie müssen die zugehörige Spalte vorher gegebenenfalls mit irgendeinem Wert füllen. In allen anderen Fällen erfolgt die Änderung der Tabellenstruktur über den Umweg einer manuell erstellten Sicherungskopie, dem Löschen und Neuanlegen der zu ändernden Spalte und dem manuellen Zurückkopieren der gesicherten Daten, wobei die in der geänderten Spalte gespeicherten Werte entsprechend umformatiert werden können. Weitere Hinweise zu diesem Szenario finden Sie im nächsten Abschnitt, wo es um das Löschen von nicht mehr benötigten Spalten geht.


X

201

Das Ändern einer Spaltendefinition erfolgt mit Hilfe der alter table-Anweisung zusammen mit der modify-Klausel. Dabei müssen Sie hinter dem Schlüsselwort modify die zu ändernde Spalte mit ihren neuen Attributen in Klammern spezifizieren. Dabei müssen Sie nur die Attribute angeben, die wirklich geändert werden sollen. Im Folgenden finden Sie hierfür ein paar Beispiele:

alter table bezuege modify (betrag number(10,2)) modify (la default 'xxx') modify (tage null); commit;

Mit Hilfe dieses Listings werden drei Spalten der Tabelle „bezuege“ verändert. Im ersten Fall wird der Datentyp um eine Vorkommastelle verlängert. Für das Lohnartenfeld wird der Standardwert angepasst und bei den Tagen werden ab sofort keine Eingaben mehr benötigt. Löschen von Spalten Für das Löschen einer Spalte existiert überhaupt kein entsprechender Befehl, d.h. in dem Fall müssen Sie für die Tabelle zunächst eine Sicherungskopie anlegen. Danach wird die zu ändernde Tabelle gelöscht und anschließend mit der neuen Struktur wieder angelegt. Am Ende des gesamten Szenarios werden die noch benötigten Spalten aus der Sicherungskopie in die eigentliche Tabelle zurückkopiert. Beim Anlegen der Sicherungskopie können Sie dabei ein ganz spezielle Form des Befehls create table verwenden, denn mit Hilfe dieser besonderen Variante können Sie eine neue Tabelle durch Kopie bzw. aus einem Extrakt einer anderen Tabelle erstellen (vgl. Listing 2.59). drop table cpy_bezuege; create table cpy_bezuege tablespace usr as select * from bezuege; commit; Listing 2.59: Kopieren einer Tabelle

In anderen Datenbanksystem existiert hierfür manchmal die spezielle Variante einer „select… into“ Auswahlabfrage. Das Praktische an dieser Form des create tableBefehls ist, dass Sie sich hierbei das explizite Anlegen der neuen Tabelle durch Aufzählen der benötigten Spalten mit allen notwendigen Attributen ersparen. Allerdings funktioniert das Ganze nur dann so reibungslos, wenn in der spezifizierten Abfrage nur Spaltennamen aus anderen Tabellen und keine Ausdrücke verwendet werden. Wenn Sie innerhalb der Abfrage Ausdrücke verwenden, dann müssen Sie diesen berechneten Spalten zum einen eine Überschrift zuweisen, die später als Feldnamen verwendet wird, und zum anderen ermittelt Oracle den geeigneten Datentyp automatisch.

202


drop table cpy_bezuege; create table cpy_bezuege tablespace usr as select a.*, 4+5 as wert2, 'haha' as text from bezuege a; commit;

In der hier gezeigten Variante erhält die Sicherungskopie cpy_bezuege zwei zusätzliche Spalten. Die erste heißt „WERT2“ und ist numerisch und die zweite neue Spalte hat den Namen „TEXT“ und wird als vierstellige Zeichenfolge angelegt. Nach dem erfolgreichen Erstellen der Sicherungskopie kann die alte Tabelle gelöscht und mit der neuen Struktur wieder angelegt werden. Danach werden die Daten aus der Sicherungskopie zurückgeladen. Im Rahmen der dabei zu verwendenden insert-Anweisung werden gelöschte Spalten weggelassen und geänderte Spalten müssen entsprechend umformatiert werden. Objektorientiert Bei der Vorstellung der objektorientierten Daten- und Tabellentypen haben Sie auch schon einige Beispiele zur Anlage von objektorientierten Tabellen gesehen. Auch bin ich auf den Unterschied zwischen der Verwendung des Objektes im Rahmen einer gewöhnlichen Spalte und der objektorientierten Verwendung eingegangen. Zur Erinnerung können Sie die alternativen Verfahrensweisen dem folgenden Listing noch einmal entnehmen. create table h_mensch (h_m mensch) create table menschen of mensch

Wenn Sie mit Objekten arbeiten möchten oder müssen, dann würde ich die objektorientierte Verfahrensweise bevorzugen, da der anschließende Umgang mit der Tabelle einfacher ist; möglich sind natürlich beide Verfahren. Die ansonsten hier beschriebenen Möglichkeiten zur Anlage von Constraints, ganz gleich ob zur Anlage von Indexen, Prüfungen oder Integritätsüberwachung, stehen Ihnen natürlich auch bei den Objekten bzw. den objektorientierten Tabellen zur Verfügung. Im folgenden Listing finden Sie hierzu noch einmal zwei kleine Beispiele. alter table h_mensch add constraint check_geschl check (h_m.geschl in ('M', 'W') disable alter table menschen add constraint check_geschl check (geschl in ('M', 'W') disable

Varianten Mit zwei besonderen Variationen möchte ich das Kapitel „Tabellen“ zunächst einmal abschließen. Zum einen geht es um den Parameter cache, den Sie zusammen mit der Anlage einer Tabelle verwenden können, und der dazu führt, dass Oracle versucht die zugehörigen Dabenblöcke möglichst lange im Speicher vorzuhalten.


203

Das ist für kleine und häufig genutzte Tabellen interessant, weil diese damit quasi immer sofort zur Verfügung stehen. Der Standardwert für diese Option ist nocache. Zum anderen geht es um die Klausel nologging, die dazu führt, dass zusammen mit Einfügeoperationen weniger Protokollmaterial im redo log-Bereich anfällt. Gerade im Rahmen von Batchprozessen werden häufiger Arbeitstabellen am Anfang des Programms mit Hilfe eines truncate table-Befehls abgeschnitten, um danach wieder über eine insert-Anweisung gefüllt zu werden. In solchen Fällen oder beim Urladen irgendwelcher Daten kann diese Option interessant sein, um die Performance der Einfügeanweisung zu erhöhen. Beide Klauseln können zusammen mit der Anlage der Tabelle oder im Nachhinein über eine entsprechende alter table-Anweisung verwendet werden. Die nachfolgenden Beispiele zeigen Ihnen die prinzipielle Verwendung dieser Klauseln. alter alter alter alter

table table table table

lohnarten lohnarten lohnarten lohnarten

cache; nocache; logging; nologging;

2.2.18 Trigger (Triggers) Bei den sogenannten Triggern handelt es sich um in der Datenbank gespeicherte PL/SQL-Programme, die durch bestimmte Datenereignisse automatisch aufgerufen (getriggert) werden. Konkret können diese Ereignisse in einer Tabelle durch Verwendung einer Einfüge-, Änderungs- oder Löschanweisung ausgelöst werden (vgl. Abb. 2.16).

Datenbank

Before-Trigger

delete from ...

Löschen durchführen

After-Trigger

Abbildung 2.16: Schema der Verwendung getriggerter Programme

204


Die Abbildung 2.16 zeigt Ihnen stark vereinfacht den internen Ablauf einer Löschanweisung bei vorhandenen Trigger-Programmen. Wird jetzt im Rahmen einer SQL-Anweisung ein delete-Kommando abgesetzt, so startet Oracle zunächst das Programm eines vorhandene „Vorab-Löschtriggers“. Anschließend werden die Daten gelöscht und danach startet die Datenbank automatisch das Programm des vorhandenen „Danach-Löschtriggers“. Dabei haben beide Trigger-Programme Zugriff auf die im Rahmen der Löschtransaktion betroffenen Datensätze und beide Programm könnten durch entsprechende Anweisungen die Transaktion abbrechen. Wie ich schon angedeutet habe, werden Trigger immer zusammen mit einer Tabelle definiert, d.h. bei der Erstellung des Triggerprogramms müssen Sie angeben, für welche Tabelle der Trigger gestartet werden soll. Außerdem müssen Sie festlegen, ob der Trigger vor oder nach Durchführung der Änderungstransaktion und für welche Transaktionen der Trigger ausgeführt werden soll, d.h. Sie haben die Möglichkeit, spezielle Einfüge-, Änderungs- oder Löschtrigger zu erstellen. Des weiteren müssen Sie definieren, wie der Trigger zusammen mit der durch die Änderungstransaktion betroffene Datenmenge aufgerufen werden soll. Hierbei haben Sie zum einen die Möglichkeit, den Trigger zusammen mit allen betroffenen Datensätzen bzw. mit der zugehörigen SQL-Anweisung oder mit jedem Datensatz einzeln starten zu lassen. Nach Kenntnis dieser ganzen Informationen macht es Sinn, dass in Abbildung 2.16 vereinfachte Ausführungsmodell von Triggerprogrammen ein wenig zu präzisieren. Der nun folgenden Aufstellung können Sie entnehmen, wie bzw. in welcher Reihenfolge Trigger gestartet werden und wie diese mit eventuell vorhandenen Constrains zusammenarbeiten: 1. Ausführung aller Vorab-Trigger, die nicht für jeden einzelnen Datensatz gestartet werden sollen. 2. Durchlaufen aller im Rahmen der Transaktion selektierten Datensätze. –

Ausführung aller datensatzbezogenen Vorab-Trigger.

–

Ändern, Löschen, Einfügen des Datensatzes entsprechend des SQL-Befehls. Durchführen alle vorhandenen Constraint-Prüfungen.

–

Ausführung aller datensatzbezogenen Danach-Trigger.

3. Ausführen aller nicht datensatzbezogenen Danach-Trigger. Ein ganz beachtlicher Unterschied zu einigen anderen Datenbanksystemen ist, dass Sie für eine Tabelle mehrere Trigger gleichen Typs, beispielsweise mehrere Vorab-Löschtrigger, definieren können. In dem Fall werden beim Löschen eines oder mehrere Datensätze einfach alle zugehörigen Triggerprogramme nacheinander gestartet. Aber alleine schon die Tatsache, dass Sie in Oracle die Trigger vor oder nach Durchführung der zugehörigen Transaktion starten können, ist ein beachtlicher Unterschied im Vergleich zu anderen Datenbanksystemen. Aus meiner Sicht sind die Trigger eines der interessantesten Features einer relationalen Datenbank. Es gibt unendlich viele Einsatzmöglichkeiten, man könnte auch sagen, die Trigger sind die „Eierlegendewollmilchsau“ in Ihrer Werkzeugkiste. In der folgenden Aufstellung habe ich ein paar Einsatzmöglichkeiten für Trigger auf-


205

gezählt und dabei habe ich in Klammern festgehalten ob es sich bei dem Einsatzgebiet eher um einen Vorab- bzw. Danach-Trigger handelt.

X X X X X

X

X X

X

(Vorab) Überprüfung der Transaktionsberechtigung. Dürfen die Daten beispielweise aufgrund anderer Aktivitäten gerade nicht geändert werden, so können Sie darauf mit Hilfe eines Triggers achten. Beispiel: Während die Gehaltsabrechnung läuft, dürfen bestimmte Stammdaten nicht geändert werden. (Vorab) Verhindern bestimmter Transaktionen, beispielsweise Massenupdates oder Mehrfachlöschungen in Stammdatentabellen. (Danach) Automatische Berechnung verschiedener, meistens redundanter Felder. Ein einfaches Beispiel hierfür wäre das Mitführen einer Arbeitsspalte mit einer besonderen Aufbereitung der Suchbegriffe (vgl. nlssort). (Vorab + Danach) Überwachung komplexer Prüfroutinen, die beispielweise im Rahmen der einfachen check- oder Integritäts-Constraints nicht programmiert werden können, weil die Regeln zu umfangreich oder die Datenstrukturen hierfür ungeeignet sind. (Vorab + Danach) Sicherstellen der referentiellen Integrität. Beispielsweise durch automatisches Löschen oder Umbenennen abhängiger Datensätze. Mit Hilfe eines Danach-Triggers könnte beispielsweise jeder Elternsatz seine Kinder löschen. Wenn Sie dieses Prinzip in Ihrer Datenbank durchhalten, dann können Sie anschließend an jeder Stelle mit einer Löschanweisung ansetzen und es ist sichergestellt, dass abhängige Datensätze ebenfalls automatisch gelöscht werden. (Danach) Erstellen von kontrollierten Datenredundanzen. Aus Performancegründen kann es manchmal sinnvoll sein, bestimmte Informationen mehrfach in der Datenbank vorzuhalten. Allerdings müssen Sie dann darauf achten, dass die zugehörigen Felder und Sätze immer die gleichen Werte enthalten, wozu Sie Trigger-Programme verwenden können. (Danach) Erstellen einer Protokollierung von Änderungen auf Datensatzebene. (Vorab + Danach) Ereignisgesteuerte Administration oder soll ich besser Workflow-Management sagen. Ein Trigger bietet Ihnen das ideale Werkzeug, Datenänderungen zu erkennen und daraufhin die benötigten Aktionen auszulösen, beispielsweise neue Datensätze in sogenannte „todo“-Listen einzutragen. (Vorab) Programmierung komplexer Zugriffsschutzbestimmungen, beispielsweise in der Form von datensatzbezogenen Änderungsrechten.

Das waren nur einige Beispiele für einen möglichen Einsatz von Trigger-Programmen, wobei ich glaube, dass das große Spektrum der Einsatzmöglichkeiten deutlich geworden ist. Wenn Sie innerhalb eines Triggers weitere SQL-Änderungskommandos absetzen, dann führt das unter Umständen zum Auslösen weiterer Triggerprogramme, sofern für die entsprechenden Tabellen und Transaktionen entsprechende Programme angelegt wurden (vgl. Abb. 2.17).

206


update tabelle1 ...

tabelle1 update-trigger... { insert tabelle2 }

tabelle2 insert-trigger... { delete tabelle3 }

Abbildung 2.17: Verschachtelte Ausführung von Triggern

Das ist im Übrigen auch wieder ein wichtiger Aspekt im Vergleich zu anderen Datenbanksystemen, wo es unter Umständen Restriktionen bei der Verwendung geschachtelter Trigger gibt bzw. deren kaskadierende Ausführung überhaupt nicht möglich ist. Ein Trigger wird mit Hilfe der Anweisung create or replace trigger erstellt bzw. geändert. Löschen können Sie ihn mit Hilfe des Befehls drop trigger. In beiden Fällen müssen Sie hinter dem Befehl als Erstes den Namen des Triggers spezifizieren. Weitergehende Informationen zu Triggern finden Sie in der Oracle-Dokumentation vor allem an zwei Stellen. Zum einen enthält das Buch „Oracle8 Concepts“ ein eigenes Kapitel „Database Triggers“ und zum anderen finden Sie auch in der „Oracle8 SQL Reference“ unter dem Stichwort „create trigger“ Informationen und Beispiele zur Anlage und Verwendung dieser speziellen Programme. Beispiel An dieser Stelle möchte ich zunächst nur ein sehr einfaches Beispiel anführen und als Variation lediglich die Anlage unterschiedlicher leerer Triggerrümpfe darstellen. Der Grund dafür ist, dass die Erstellung von Triggern schnell zu umfangreicheren Programmpassagen führt und ich möchte hier und jetzt nicht dem gesamten Kapitel „PL/SQL-Programmierung“, in dem Sie weitere und vor allem komplexere Beispiele finden, schleichend vorgreifen müssen. Als Erstes erstellen wir einen Trigger für die Lohartentabelle, der dafür sorgt, dass jegliche Änderungen für die Tabelle nur noch an bestimmten Wochentagen möglich sind (vgl. Listing 2.60). create or replace trigger lohnarten_upd before update on lohnarten begin if to_char(sysdate,'D') not in ('5','7') then


207

raise_application_error(-20001, 'Die Tabelle kann nur am DO und SA geändert werden.'); end if; end; / show errors; commit; Listing 2.60: Beispiel für die Anlage eines Vorab-Triggers

Wie Sie dem Listing 2.60 entnehmen können, erhält jeder Trigger bei der Anlage einen Namen („lohnarten_upd”). Anschließend folgen verschiedene Anweisungen die festlegen, wann und wofür der Trigger gestartet werden soll, was ich gleich noch ausführlicher erläutern werde. Das eigentliche Trigger-Programm befindet sich dann wieder in einem begin..end-Block. In unserem Beispiel ermitteln wir innerhalb des Programms mit Hilfe der Funktionen to_char und sysdate den Wochentag aus dem aktuellen Tagesdatum. Ist dieser Wert nicht fünf und nicht sieben (Donnerstag bzw. Samstag), dann brechen wir mit Hilfe der Funktion raise_application_error die Transaktion ab und stellen dem aufrufenden Anwendungsprogramm eine entsprechende Fehlermeldung zur Verfügung. Varianten Die Deklaration eines Triggers folgt im Prinzip folgendem Schema: create or replace trigger on

Der vergebene Name des Triggers muss innerhalb des verwendeten Schemas eindeutig sein. Zur Spezifizierung des Zeitpunkts können Sie die Schlüsselwörter before oder after verwenden, um entsprechend einen Vorab- bzw. Danach-Trigger zu erstellen. Die den Trigger aufrufende Transaktion legen Sie mit Hilfe der Schlüsselwörter insert, update oder delete (Einfügen, Ändern und Löschen) fest. Hierbei können Sie die einzelnen Änderungsarten miteinander kombinieren, indem Sie diese mit dem Wörtchen or verbinden. insert or update or delete

In dem Fall können Sie innerhalb des Programms mit Hilfe der Schlüsselwörter inserting, updating bzw. deleting auf die jeweils verantwortliche Änderungsanweisung reagieren; ein Beispiel hierfür finden Sie am Ende des Abschnitts. if inserting then ... if updating then ... if deleting then ...

208


Zusammen mit einer Änderungstransaktion (update) können Sie dabei auch noch einzelne Spalten festlegen, so dass der Trigger bei einer update-Anweisung lediglich dann aufgerufen wird, wenn eine der aufgeführten Spalten dabei geändert wird. insert or update of la, la_text or delete

Nachdem nun die Transaktionsarten für den Trigger festgelegt sind, folgt als Nächstes hinter dem Wörtchen on der Namen der zugehörigen Tabelle. Danach legen Sie fest, ob der Trigger für die gesamte Transaktion oder für jeden einzelnen betroffenen Datensatz gestartet werden soll. Dabei entspricht das einmalige Starten des Triggers für die gesamte Transaktion dem Standardverfahren. Um den Trigger für jeden betroffenen Datensatz aufzurufen, müssen Sie die Klausel for each row spezifizieren. Zusammen mit den datensatzbezogenen (for each row) Triggern können Sie auch noch eine Ausführungsbedingung festlegen, die für den Datensatz erfüllt sein muss, damit das Triggerprogramm gestartet wird. Diese Klausel leiten Sie mit dem Schlüsselwort when ein, dem die konkrete Ausführungsbedingung in Klammern folgt. Hierbei können Sie mit Hilfe der Schlüsselwörter new und old auf die geänderten bzw. ursprünglichen Werte der betroffenen Datensätze zugreifen. Im folgenden Beispiel wird das Triggerprogramm nur dann gestartet, wenn die neue Lohnart den Wert „400” oder die alte Lohnart den Wert „233” enthält. for each row when (new.la = '400' or old.la = '233')

Innerhalb des Programms eines datensatzbezogenen Triggers erfolgt der Zugriff auf die alten bzw. neuen Werte durch Verwendung von :new bzw. :old. If :new.la = '400' or :old.la = '233' then

Das war schon fast alles und bevor ich noch kurz auf eine ganz besondere Triggervariante eingehe, finden Sie im Folgenden noch verschiedene Beispiele und Variationen zur Definition von Triggerprogrammen.

X

Erstellen eines Vorab-Triggers für alle Änderungstransaktionen create or replace trigger mtabelle_t1 befor insert or update or delete on mtabelle

X

Erstellen eines Vorab-Triggers für jeden betroffenen Datensatz, der allerdings nur dann gestartet wird, wenn die neue Lohnart größer „900“ ist. create or replace trigger mtabelle_t2 before insert or update(la) or delete on mtabelle for each row when (new.la > '900')

X

Erstellen eines Danach-Triggers, der nach einer Löschoperation aufgerufen wird. create or replace trigger mtabelle_t3 after delete on mtabelle


X

209

Erstellen eines Danach-Triggers, der nach dem Löschen für jeden betroffenen Datensatz gestartet wird, sofern die Lohnart kleiner dem Wert „788“ ist. create or replace trigger mtabelle_t4 after delete on mtabelle for each row when (old.la < '788')

Instead of-Trigger Mit dieser besonderen Variante können Sie das eigentlich Verbotene möglich machen. Konkret geht es darum, Views, die aufgrund ihrer komplexen bzw. speziellen Definition eigentlich nur gelesen werden können, mit Hilfe des Triggers updatefähig zu machen. Hierbei müssen Sie im Triggerprogramm die benötigten Regeln definieren, unter welchen Bedingungen die jeweils an der View beteiligten Tabellen geändert werden sollen. Bevor Sie jetzt allerdings die Ärmel hochkrempeln, um das gleich folgende Beispiel einzutippen, sollten Sie zunächst einmal wieder die View „v$options“ befragen, ob dieses spezielle Feature überhaupt in Ihrer Datenbank verfügbar ist. Mein Beispiel habe ich in Anlehnung an das in der Oracle-Dokumentation vorgestellte Muster erstellt. Stellen wir uns vor, in unserer Datenbank, die wir zusammen mit einem anderen Anwender gemeinsam nutzen, existieren die beiden Tabellen „meine_freunde“ und „deine_freunde“ mit jeweils folgendem Aufbau. drop table meine_freunde; drop table deine_freunde; / create table meine_freunde ( name varchar(50), telefon varchar(30) ) tablespace usr; / create table deine_freunde ( name varchar(50), telefon varchar(30) ) tablespace usr; commit Listing 2.61: Vorbereiten eines instead of-Triggers

In diesen beiden Tabellen können anschließend unabhängig voneinander entsprechende Datensätze gespeichert werden. Damit die Tabellen im Folgenden nicht ganz so leer sind, werden wir einmal jeweils zwei Datensätze einfügen. insert into insert into insert into insert into commit;

meine_freunde meine_freunde deine_freunde deine_freunde

values values values values

('Hildegard', '983932'); ('Ernst', '587332'); ('Paul', '213984'); ('Sonja', '390928');

210


Mit Hilfe einer View können Sie nun eine Abfrage erstellen und dauerhaft speichern, mit der alle vorhandenen Freunde angezeigt werden. Hierbei soll mit Hilfe einer zusätzlichen Spalte dargestellt werden, aus welchem Töpfchen der jeweilige Freund selektiert wurde. create view alle_freunde as select name, telefon, 'meine' as mein_dein from meine_freunde union all select name, telefon, 'deine' from deine_freunde; commit; Listing 2.62: Mischen zweiter Tabelle mit Hilfe einer union-View

Im Rahmen der in der View gespeicherten Abfrage werden zwei exakt gleich aufgebaute select-Abfragen mit Hilfe der union-Anweisung gemischt. Als Ergebnis erhalten Sie eine logische Tabelle, deren Abfrage (vgl. Listing 2.63) den Eindruck erweckt, als würden die zugehörigen Einzelsätze gemeinsam gespeichert werden. SQLWKS> select * from alle_freunde 2> NAME ----------------------------------Hildegard Ernst Paul Sonja 4 rows selected.

TELEFON -----------------------983932 587332 213984 390928

MEIN_ ----meine meine deine deine

Listing 2.63: Abfrage des gemeinsamen Freundeskreises

Das Bearbeiten der in der logischen Tabelle bzw. der View zusammengefassten Datensätze ist aber von Hause aus nicht möglich. Woher soll die Datenbank bei einer Einfügeanweisung der Art insert into alle_freunde values ('Helgo', '758473', 'meine')

auch wissen, in welchen Topf sie den neuen Datensatz einfügen soll, zumal der als Letztes übergebene Wert nicht einmal einer konkret vorhandenen Spalte entspricht? Mit Hilfe der hier besprochenen instead of-Trigger können Sie dieses Dilemma allerdings auflösen und der Datenbank erklären, was sie mit den einzelnen Änderungen tun soll (vgl. Listing 2.64). create or replace trigger alle_freunde instead of insert on alle_freunde for each row


211

begin if :new.mein_dein = 'meine' then insert into meine_freunde values(:new.name, :new.telefon); else insert into deine_freunde values(:new.name, :new.telefon); end if; end; / show errors; commit; Listing 2.64: Erstellen eines einfachen instead of-Triggers

Erst jetzt können Sie die oben abgebildete Einfügeanweisung ausführen und erhalten als Ergebnis einen neuen Datensatz in der Tabelle „meine_freunde”. Wie Sie dem Beispiel entnehmen können, wird mit Hilfe des übergebenen Wertes für die konstruierte Spalte „meine_deine“ innerhalb des Programms entschieden, in welcher Tabelle die Einfügeoperation durchgeführt werden soll. Natürlich können Sie das Programm auch noch um Methoden für das Ändern oder Löschen von Datensätzen oder sogar eine spezielle Variante zur Behandlung von Datensätzen, die mit dem Zusatz „unsere“ geändert werden, erweitern. Das Letztere überlasse ich Ihnen, für das Ändern und Löschen möchte ich aber noch eine vollständige Programmversion vorstellen. create or replace trigger alle_freunde instead of insert or update or delete on alle_freunde for each row begin if inserting then if :new.mein_dein = 'meine' then insert into meine_freunde values(:new.name, :new.telefon); else insert into deine_freunde values(:new.name, :new.telefon); end if; elsif updating then if :new.mein_dein = 'meine' then update meine_freunde set name = :new.name, telefon = :new.telefon where name = :old.name and telefon = :old.telefon; else update deine_freunde set name = :new.name, telefon = :new.telefon where name = :old.name and telefon = :old.telefon; end if; else if :old.mein_dein = 'meine' then

212


delete meine_freunde where name = :old.name and telefon = :old.telefon; else delete deine_freunde where name = :old.name and telefon = :old.telefon; end if; end if; end; / show errors; commit; Listing 2.65: Triggervariante zur Herstellung der Änderungsfähigkeit einer View

Mit Hilfe einer if-Anweisung reagiert das Programm auf die einzelnen zum Aufruf des Triggers geführten Änderungsabfragen. Dabei wird in allen Fällen mit Hilfe der Spalte mein_dein unterschieden, in welcher Tabelle die Änderung konkret durchgeführt werden soll. Nach Erstellung des Triggers können Sie auch Änderungs- oder Löschabfragen zusammen mit der View alle_freunde verwenden. update alle_freunde set telefon = '1111' where name = 'Hildegard' and mein_dein = 'meine' delete alle_freunde where name = 'Paul' and mein_dein = 'deine' commit

Varianten Jeder Segen kann auch mal zum Fluch werden. Hiermit meine ich die Situation, in dem die automatisch gestarteten Triggerprogramme beispielsweise im Rahmen von Wartungs- oder Korrekturaktionen lästig werden. In dem Fall müssen Sie den Trigger allerdings nicht unbedingt löschen, sondern es besteht auch die Möglichkeit, vorübergehend aus- bzw. einzuschalten. Hierzu finden Sie im SQL-Befehlssatz die Anweisung alter trigger, die zusammen mit den schon bekannten Klauseln disable bzw. enable zum Aus- oder Einschalten eines Triggers verwendet werden kann. alter trigger lohnarten_upd disable; alter trigger lohnarten_upd enable;

2.2.19 Ansicht (Views) Bei einer sogenannten View handelt es sich um in der Datenbank gespeicherte Abfrage, die sich nach außen wie eine logische Tabelle verhält, d.h. die View können Sie in einem gewissen Umfang wie eine gewöhnliche Tabelle verwenden, obwohl sie keine eigenen Daten enthält. Mit Hilfe einer solchen View können Daten aus einer anderen Tabelle bzw. anderen Tabellen abgefragt werden, d.h. bei


213

deren Verwendung innerhalb einer Abfrage werden zusätzlich auch die in der View gespeicherten Anweisungen ausgeführt. Die Anlage einer View erfolgt mit Hilfe des Befehls create or replace view. Gelöscht wird sie mit Hilfe des Befehls drop view. Dabei sieht das Anlegen einer View sieht so ähnlich aus wie das Kopieren einer Tabelle mit dem create table as-Befehl. Allerdings wird hierbei statt des Wörtchens „table“ das Wort „view“ verwendet und im Unterschied zum Kopiervorgang werden bei der Anlage der View keine Daten bewegt, sondern es wird lediglich die SQL-Abfrage gespeichert. create or replace view as select

Innerhalb der in der View verwendeten Abfrageanweisung können Sie eine einzige Tabelle verwenden oder aber auch mehrere Tabellen miteinander verknüpfen. Ebenfalls möglich ist die Verwendung von mischenden (union) oder gruppierenden (group by) Abfragen. Insgesamt ergibt sich für das Einsatzgebiet von Views das folgende Spektrum:

X X

X

Speichern komplexer Abfragen, um zum einen deren Verwendbarkeit zu vereinfachen oder aber auch zum anderen dem Endanwender die Ausführung der Abfrage überhaupt zu ermöglichen. Views können auch ein wichtiger Bestandteil eines Sicherheitskonzepts sein. Wie Sie später in diesem Buch noch erfahren werden, muss der Zugriff auf die einzelnen Schema-Objekte für andere Benutzer explizit freigegeben werden. Hat ein Benutzer Zugriff auf eine View, so kann er die dort definierten Spalten und Sätze abrufen, ohne dass er Zugriffsrechte auf die darunter liegenden Tabellen besitzen muss. Konstruktion einer logischen Schicht zwischen Anwendungen, beispielsweise Reports, und der Datenbank, um diese Anwendungen zumindest in einem gewissen Maße resistent gegen Strukturänderungen zu machen.

Gerade für den ersten der aufgeführten Punkte finden Sie schon alleine im Systembereich von Oracle viele Beispiele. Im Rahmen der Tabellenerstellung haben wir häufiger einfache Abfragen auf die View dba_extents gemacht. select extent_id, bytes, blocks from dba_extents where segment_name = 'LOHNARTEN'

Dass diese Abfrage so einfach war, liegt daran, dass die eigentliche Komplexität in der View versteckt ist, denn die dort gespeicherte Auswahlanweisung ist folgende: select ds.owner, ds.segment_name, ds.partition_name, ds.segment_type, ds.tablespace_name, e.ext#, f.file#, e.block#, e.length * ds.blocksize, e.length, e.file# from sys.uet$ e, sys.sys_dba_segs ds, sys.file$ f where e.segfile# = ds.relative_fno and e.segblock# = ds.header_block and e.ts# = ds.tablespace_id and e.ts# = f.ts# and e.file# = f.relfile#

214


Die in einer View gespeicherte Anweisung können Sie übrigens durch eine Abfrage auf das Objekt all_views ermitteln. Ansonsten passt das Beispiel auf alle drei von mir genannten Kategorien. Die Zusammenfassung dieser doch recht umfangreichen Abfrage zu einem Objekt vereinfacht uns allen deren Verwendung. Zum zweiten benötigen und besitzen wir üblicherweise überhaupt keine Zugriffsrechte auf die in der View verwendeten Objekte (z.B. sys_dba_segs). Und drittens könnte Oracle die konkrete Speicherung von Segment- bzw. Extent-Informationen ändern, ohne dass wir das überhaupt mitbekommen, sofern die View dba_extents nach einer solchen Änderung immer noch die gleichen Daten liefert. In Bezug auf die technische Verwendung bzw. Ausführung eines View-Objekts, unterscheidet sich Oracle von manchen anderen Datenbanksystemen. Primäres Ziel ist es nämlich, nicht die eigentliche View auszuführen und das zugehörige Abfrageergebnis zusammen mit der eigentlichen auslösenden Abfrage zu verknüpfen, sondern die in der View gespeicherte Abfrageanweisung mit dem aufrufenden SQL-Statement zu mischen (vgl. Abb. 2.18).

Abfrage: select * from v_bezuege where la = ‘100‘

View v_bezuege: select persnr, la from bezuege where la < ‘900‘

select a.persnr, a.la from bezuege a where (a.la < ‘900‘) and (a.la = ‘100‘)

Datenbank

Abbildung 2.18: Mischen der View-Auswahlanweisung mit dem rufenden SQL-Statement

Diese Vorgehensweise hat den Vorteil, dass bei der Ausführung der View die in den Tabellen spezifzierten Indices bei der Datenauswahl berücksichtigt werden können, so dass mit der Verwendung von Views meistens keine Geschwindigkeitseinbußen einhergehen. Meistens bedeutet demnach aber, dass es auch Ausnahmen gibt. Das ist beispielsweise dann der Fall, wenn Oracle die in der View gespeicherten Auswahlanweisungen nicht zu der aktuell verwendeten Abfrage hinzumischen kann, was unter anderem immer dann passiert, wenn die View folgende Anweisungen enthält:

X X X X

eine connect by-Klausel. die Verwendung von Mengenoperationen (union, union all, minus usw.). gruppierende Abfragen (group by, sum, max, min usw.). die Pseudospalte rownum.


215

In solchen Fällen wird die View ausgeführt und das Ergebnis wird zunächst einmal in einem temporären Bereich zwischengespeichert. Diese temporäre Tabelle wird anschließend mit den anderen an der Abfrage beteiligten Tabellen verknüpft, was die Performance der Abfrage durchaus negativ beeinflussen kann. Beim Analysieren Ihrer SQL-Abfrage können Sie genau ablesen, ob Ihre View ausgeführt oder zur Abfrage hinzugemischt wird. Genauere Informationen hierzu erhalten Sie in diesem Workshop bei der Behandlung des Abfragetunings. Ein weiterer Aspekt bei den Views ist die Fragestellung, ob diese Objekte auch zusammen mit Änderungsabfragen verwendet werden können. Dabei sind einfache Views, deren Abfrage lediglich eine Tabelle verwendet, meistens änderungsfähig, sofern innerhalb der Views folgende Anweisungen nicht verwendet wurden: –

der distinct-Befehl.

–

Aggregatfunktionen (z.B. avg, count, max, min, sum usw.) bzw. Gruppieroperationen (z.B. group by).

–

Mengenoperationen (union, union all, minus usw.).

–

die Befehle start with oder connect by.

–

die Pseudospalte rownum.

Auch eine View, in der verschiedene Tabellen verknüpft werden, kann in einem gewissen Umfang änderungsfähig sein. Generell gilt allerdings, dass die eingesetzte Änderungsabfrage nur eine der in der View verwendeten Tabellen ändern darf. Welche Spalten einer View im Zweifel geändert werden dürfen, können Sie mit Hilfe einer Abfrage auf die View user_updatable_colums ermitteln. select column_name, updatable from user_updatable_columns where table_name = ''

Wie Sie im vorhergehenden Kapitel jedoch gesehen haben, gibt es mit Hilfe der instead of-Trigger immer eine Möglichkeit, den einzelnen Views die Updatefähigkeit selbst dann beizubringen, wenn sie standardmäßig gar keine Änderungsanweisung zulässt. Beispiel

X

Als Beispiel erstellen wir jetzt eine View (vgl. Listing 2.66), die uns alle vorhandenen Bezüge zusammen mit dem Lohnartentext aus der Lohnartentabelle anzeigt.

create or replace view ma_bezuege as select a.persnr, a.la, b.la_text, a.betrag from bezuege a, lohnarten b where b.la = a.la and a.betrag 0; commit; Listing 2.66: Erstellen einer einfachen View

216


Wie Sie dem Beispiel entnehmen können, wird die View ma_bezuege mit Hilfe der Anweisung create or replace view angelegt. Die Verwendung dieser Form hat als Alternative zu der Kombination einzelner drop view bzw. create view-Anweisungen wieder den Vorteil, dass eventuell zugewiesene Zugriffsrechte hierbei erhalten bleiben. Hinter dem Namen der View folgt das Wörtchen as, dem die eigentliche in der View gespeicherte Abfrage folgt. Die Verwendung unseres neuen Objekts in einer Abfrage führt nun alle betragsmäßig gespeicherten Bezüge zusammen mit der Lohnartenbezeichnung zu Tage. SQLWKS> select * from ma_bezuege 2> PERSNR LA LA_TEXT BETRAG ---------- --- -------------------------------------------- ---------4711 100 Grundgehalt 1000 1 row selected.

Eine weitere Abfrage auf die View user_updatable_columns beschert uns Gewissheit, dass ohne zusätzliche Objekte in Form eines instead of-Triggers unsere View eine reine Leseveranstaltung ist. SQLWKS> select column_name, updatable from user_updatable_columns 2> where table_name = 'ma_bezuege' 3> COLUMN_NAME UPD ------------------------------ --0 rows selected.

2.2.20 Zusammenfassung Am Anfang des Kapitels hatte ich Ihnen einen Überblick über die in Oracle verfügbaren Objekte versprochen. Wie gut, dass das Wörtchen „Überblick“ nicht automatisch den zugehörigen Umfang impliziert, denn bei meinem Streifzug durch die Schema-Objekte der Oracle-Datenbank ist ein beachtliches Häufchen Papier entstanden. Trotzdem gibt es natürlich immer Leser, die gerade die eine spezielle Variante eines Befehls vermissen. Doch irgendwie muss man den Rahmen abstecken; schon alleine für die Befehle create oder alter table könnte man locker ein eigenes Buch mit über 200 Seiten erstellen, wenn man alle Variationsmöglichkeiten dieser beiden Befehle beschreibt. Dabei ist es zum Teil sicher auch ein bisschen willkürlich, dass man die eine Variante noch beschreibt, eine andere Variation aber weglässt. In meiner mittlerweile zehnjährigen Erfahrung mit verschiedenen Datenbanken habe ich von Zeit zu Zeit auch immer neue Systeme kennen gelernt. Dabei wäre ich jedes Mal froh gewesen, wenn ich eine ähnliche Übersicht für den Schnelleinstieg zur Verfügung gehabt hätte. Ich hoffe, das geht Ihnen ebenso, wobei ich für konstruktive Verbesserungsvorschläge natürlich immer offen bin.


217

Vielleicht sind Sie nach dieser Einführung aber auch ein wenig beeindruckt. Wenn Sie schon andere Datenbanksysteme kennen, dann müssen Sie zugeben, dass der Katalog der Möglichkeiten ziemlich umfangreich ist. Sofern Sie mit einer Standardsoftware (z.B. PeopleSoft) arbeiten, dann fragen Sie sich jetzt vielleicht aber auch, warum von diesen Möglichkeiten fast kein Gebrauch gemacht wird. Es ist eigentlich nur selten möglich, mit der Einführung einer neuen Software auch den Einsatz eines ganz bestimmten DBMS zu erzwingen. Dies muss man bei der Konzeption bzw. Entwicklung von Standardsoftware berücksichtigen, wenn man sich nicht von vornherein auf einen bestimmten Markt beschränken will. Vergleicht man nun aber die verschiedenen gängigen DBMS-Systeme (Oracle, Sybase, SQL-Server, Informix, DB/2, Gupta), dann stellt man fest, dass der kleinste gemeinsame Nenner in der Tat ziemlich klein ist. Aus Sicht der Oracle-Datenbank werden bestimmte Funktionalitäten (z.B. selbstdefinierte Funktionen) von den meisten anderen Produktion überhaupt nicht unterstützt. Andere Objekte (z.B. Trigger) gibt es zwar auch, aber sie haben im Vergleich zu Oracle zum Teil einen eingeschränkten Funktionsumfang (z.B. nur ein Trigger pro Tabelle) oder wichtige Details in Bezug auf die Erstellung oder Verwendung unterscheiden sich sehr stark. Konkret bedeutet das für den Entwickler, dass wenn er den universellen Markt bedienen will, nur Tabellen, explizit definierte Indices und Views verwenden darf, wobei er selbst hierbei noch Zurückhaltung in Bezug auf die verwendeten Datentypen und die Gestaltung der benötigten Abfragen Zurückhaltung üben muss. Das ist der Grund, warum die Datenbank einer Standardsoftware oftmals so einfach gestrickt ist; gehen Sie ruhig davon aus, dass die zuständigen Programmierer es besser gekonnt hätten, wenn Sie ein Oracle-Produkt entworfen hätten. Wenn Sie spezifisch auf Oracle-Datenbanken zugeschnittene Entwicklung betreiben, dann muss Sie das alles natürlich nicht kümmern. Selbst wenn Sie im Rahmen eines Einführungsprojekts Erweiterungen durchführen kann es sinnvoll sein im Rahmen der jeweiligen Aufgabenstellung weitergehenden Datenbankfunktionalitäten zu nutzen. Allerdings sollte dabei allen klar sein, dass der Wechsel des Standardprodukts auf ein andere Datenbank immer noch möglich, die Portierung der individuellen Erweiterungen jedoch vielleicht nur mit zusätzlichem Aufwand oder sogar gar nicht möglich ist. Was ich hiermit sagen will und sich vor allem an meine Beraterkollegen richtet ist, dass der tiefe Griff in die Trickkiste ist nicht immer das Maß aller Dinge ist. Es dürfte jeder Fachabteilung schwer verständlich zu machen sein, dass sie auf der einen Seite ein nach Herstellerangaben überall lauffähiges Produkt gekauft hat, das aber auf der anderen Seite wegen der individuell durchgeführten Anpassungen nicht mehr portierbar ist. Wenn natürlich Klarheit über diesen Sachverhalt herrscht und in absehbarer Zeit auch kein Wechsel des DBMS geplant ist, dann spricht aus meiner Sicht allerdings nichts dagegen, im Rahmen von Anpassungen und Erweiterungen weitergehende Datenbankfunktionalitäten einzusetzen.

218


Nach diesem mahnenden Fingerzeit an die Spieler und Fummler noch ein abschließender Hinweis. Grundsätzlich finden Sie in der Oracle-Dokumentation unter dem Link „Oracle8 Concepts“ weiterführende und zusammenhängende Erläuterungen zu den verschiedenen Schema-Objekten. Im Buch „PL/SQL User’s Guide and Reference“ finden Sie weitergehende Informationen zu den mit PL/SQL-Erstellten Schema-Objekten wie zum Beispiel Funktionen oder Prozeduren. Daneben gibt es noch den Link „Oracle8 SQL-Reference“. Hier finden Sie für alle Befehle die vollständige Beschreibung der Syntax aller Befehle sowie eine detaillierte Beschreibung der möglichen Parameter und Varianten. Sollten Sie während der Objekterstellung oder beim Testen derselben mal eine Fehlermeldung erhalten, dann können Sie die genaue Bedeutung des Fehlers nebst Hinweise zu dessen Behebung ebenfalls der Oracle-Dokumentation entnehmen, indem Sie dem Link „Oracle8 Error Messages“ folgen. Dort finden Sie eine nach Kategorie bzw. Produkt und Fehlernummer sortierte Auflistung aller Fehlermeldungen.

2.3

Die Beispieldatenbank anlegen

Im weiteren Verlauf des zweiten Kapitels werden wir nun eine kleine Beispieldatenbank anlegen, genauer gesagt legen wir dabei natürlich nur ein eigenes Schema in unserer vorhandenen Datenbank an. Das besteht natürlich nicht wie im richtigen Leben gleich aus hunderten von Tabellen, aber eine kleine Struktur (vgl. Abb. 2.19) kommt dennoch schon zustande. Nach dem Anlegen der entsprechenden Objekte, die wir vor allem bei den der Behandlung der Abfragen im nächsten und bei der PL/ SQL-Programmierung im übernächsten Kapitel benötigen, werden wir die leeren Tabellen mit Daten füllen. Hierbei werden Sie verschiedene Möglichkeiten kennen lernen. In jedem Fall stammen die Daten aus einer Access-Datenbank, die Sie auf der Begleit-CD im Verzeichnis \DATEN finden. Konkret finden Sie dort die beiden Access-Datenbanken MISCH97.MDB und MISCH2000.MDB entsprechend der jeweiligen Access-Versionen. Ebenfalls dort gespeichert sind auch eine Reihe von Textdateien, die auf verschiedene Verfahrensweisen aus der Access-Datenbank exportiert wurden und die im Anschluss an die Fertigstellung des eigenen Schemas importiert werden sollen. Die beiden Access-Datenbanken benötigen Sie in diesem Kapitel also nicht direkt, es sei denn, Sie wollen den Export der beschriebenen Textdateien ausprobieren. Außerdem besteht die Möglichkeit, sich eine Migrationshilfe für Access-Datenbanken zu installieren und sofern Sie diese einmal ausprobieren möchten, dann finden Sie in diesen beiden Access-Datenbanken entsprechendes Eingabematerial für den Migrations-Assistenten.


219

personalien ( persnr varchar2(11) not null, name varchar2(50) not null, strasse1 varchar2(35), strasse2 varchar2(35), strasse3 varchar2(35), strasse4 varchar2(35), ort varchar2(30), land varchar2(3), bland varchar2(6), plz varchar2(12), telefon varchar2(24), geschlecht varchar2(1) not null, familienstd varchar2(1) not null, familienstd_dt date, gebdatum date not null, gebort varchar2(30), gebland varchar2(3) not null)

blaender ( land varchar2(3) not null, bland varchar2(6) not null, bezeichnung varchar2(30))

austrittsgruende (

bvs (

ausgrd varchar2(3) not null, gab date not null, status varchar2(1) not null, bezeichnung varchar2(30) not null )

persnr varchar2(11) not null, lfdnr smallint not null, eintrt date not null, austrt date, ausgrd varchar(3), unternehmen varchar(3) not null)

gehalt ( persnr varchar2(11) not null, lfdnr smallint not null, gab date not null, kst varchar2(10) not null, gehalt number(9,2) not null, zulage number(9,2) not null )

laender ( land varchar2(3) not null, bland varchar2(1) not null, bezeichnung varchar2(30))

unternehmen ( unternehmen varchar2(3) not null, gab date not null, status varchar2(1) not null, bezeichnung varchar2(30) not null )

kostenstelle ( unternehmen varchar2(3) not null, kst varchar2(10) not null, gab date not null, status varchar2(1) not null, bezeichnung varchar2(30) not null )

Abbildung 2.19: Struktur unseres Beispiel-Schemas

2.3.1

Anlage des Schema-Eigners

Am Anfang des Kapitels haben Sie den Begriff des Schemas kennen gelernt. Bisher haben wir bei allen unseren Beispielen immer mit einem der standardmäßig vorhandenen Administratorenkennungen (z.B. system) gearbeitet, was sich im Folgenden nun ändern soll. Aus diesem Grund legen wir gleich zunächst einmal eine neue Benutzerkennung an. Im Vorgriff auf das übernächste Kapitel „Benutzer und Rollen“ will ich an dieser Stelle allerdings nur soviel dazu sagen: In Oracle existieren für die Zuweisung von Benutzerrechten im Prinzip zwei Möglichkeiten. Zunächst einmal können Sie einem einzelnen Benutzer individuelle Einzelrechte

220


zuweisen oder entziehen. Das würde aber selbst bei kleinen Datenbanken mit vielleicht zehn oder zwandzig Benutzern selbst bei nur geringen Einzelrechten nicht sehr lange Spaß machen, weshalb es in Oracle das Konzept der Rollen gibt. Hierbei werden verschiedene Einzelrechte zu einer sogenannten Rolle zusammengefasst und im Anschluss daran werden den jeweiligen Benutzern die einzelnen Rollen zugewiesen, wodurch der indirekt seine Einzelrechte erhält. Aus dem Grund legen wir zunächst die neue Rolle „rbeispiel“ an und weisen der Rolle eine Reihe von weitreichenden Einzelrechten zu (vgl. Listing 2.67). Was diese einzelnen Rechte bedeuten und welche wirklich gebraucht werden oder vielleicht auch entfallen könnten, das erfahren Sie wie schon gesagt ein „paar“ Seiten weiter im Kapitel „Benutzer und Rollen“. Die in dem Zusammenhang gleich abgebildeten und beschriebenen Listings finden Sie auf der CD in der Datei \DATEN\SCHEMA.SQL. drop role rbeispiel; create role rbeispiel; commit; / grant alter session, alter tablespace, alter user, analyze any, become user, create cluster, create database link, create procedure, create public database link, create public synonym, create rollback segment, create sequence, create session, create snapshot, create synonym, create table, create tablespace, create trigger, create user, create view, drop public database link, drop public synonym, drop rollback segment, drop tablespace, drop user, grant any role, manage tablespace, resource, exp_full_database, imp_full_database


221

to rbeispiel with admin option; commit; Listing 2.67: Anlegen unserer Musterrolle „rbeispiel“

Zugegebenerweise züchten wir uns einen kleinen Administrator heran, aber bei der Anlage eines Schemas, zum Beispiel während der Installation einer Anwendung sind solche Rechte gar nicht schlecht. Nach einer Installation können die Befugnisse des Schema-Eigners im Bedarfsfall ja wieder reduziert werden. Die Befehle zum Löschen bzw. Anlegen einer Rolle heißen drop role bzw. create role, wobei in beiden Fällen der Name der jeweiligen Rolle folgt. Anschließend weisen wir der Rolle mit Hilfe entsprechender grant-Kommandos die gewünschten Einzelrechte zu. Im nächsten Schritt legen wir den Schema-Eigner an, den wir mit „ubeispiel“ benennen wollen, wobei Sie das Skript in der Datei \DATEN\USER.SQL finden. drop user ubeispiel cascade; commit; / create user ubeispiel identified by manager default tablespace usr temporary tablespace temporary profile default account unlock quota unlimited on usr quota unlimited on indx quota unlimited on temporary; commit; Listing 2.68: Anlegen des Schema-Eigners „ubeispiel“

Der erste Teil des Skripts löscht den Benutzer „ubeispiel“. Hierbei sorgt die Klausel cascade dafür, dass dies auch dann passiert, wenn der Benutzer Eigentümer irgendwelcher Objekte ist, wobei seine Besitztümer in dem Fall natürlich auch gelöscht werden. Im zweiten Teil des Skripts wird der Benutzer wieder angelegt. Während der Anlage erhält er das Passwort „manager“, bekommt als Tablespace-Standard „usr“ zugewiesen und erhält durch die quota-Klauseln ein uneingeschränktes Platzangebot für die Tablespaces „usr“, „indx“ und „temporary“. Im nächsten Schritt müssen Sie dem neuen Benutzer noch die Rolle „rbeispiel“ zuweisen, was wiederum mit Hilfe einer grant-Anweisung passiert. grant rbeispiel to ubeispiel;

222

2.3.2


Verwalten der Tablespaces

Beim Anlegen eines umfangreichen Schemas bzw. vor allem beim Laden der zugehörigen Daten kann es schon einmal passieren, dass ein Tablespace voll wird, was dann zum Abbruch aller gerade aktiven und auf den ihn zugreifenden Transaktionen führt. In dem Fall müssen Sie den Tablespace vergrößern, wobei Sie hierfür verschiedene Variationsmöglichkeiten haben. Vergrößern des zugrundeliegenden Datenfiles Das ist sicherlich die einfachste aller möglichen Varianten. Sie setzt allerdings voraus, dass auf dem Datenträger noch ausreichend Platz zur Verfügung steht. In dem Fall können Sie versuchen die zum Tablespace gehörende Datei zu vergrößern oder den automatischen Extent-Modus für die Datei einzuschalten bzw. zu erweitern. alter database datafile 'E:\ORANT\DATABASE\DB01\USR1DB01.ORA' resize 9606K; alter database datafile 'E:\ORANT\DATABASE\DB01\USR1DB01.ORA' autoextend on next 3K maxsize unlimited; Listing 2.69: Vergrößern der zum Tablespace gehörenden Datei

Beides passiert mit Hilfe des Befehls alter database datafile, dem die betriebssystemspezifische Vorgabe des zum Tablespace zugehörigen Dateinamens folgt. Mit Hilfe der Klausel resize können Sie die Datei vergrößern, indem Sie hinter der Klausel die neue Größe in Kilo- (K) oder Megabyte (M) vorgeben. Durch die Klausel autoextend on wird die automatische Vergrößerung der Datei eingeschaltet. Hierbei gibt die Klausel next an, in welcher Schrittgröße das passieren soll und die Klausel maxsize legt die maximale Größe der Datei fest, wobei die durch Verwendung von „unlimited“ anschließend uneingeschränkt wachsen kann. Hinzufügen einer weiteren Datei Ist beispielsweise auf dem aktuellen Datenträger kein Platz mehr, dann können Sie den Tablespace auch dadurch vergrößern, dass Sie ihm eine weitere Datei auf einem anderen Datenträger zuweisen. alter tablespace usr add datafile 'E:\ORANT\DATABASE\DB01\USR2DB01.ORA' size 50K autoextend on next 3K maxsize 200K; Listing 2.70: Vergrößern des Tablespace durch Hinzufügen einer neuen Datei

Dies passiert im Unterschied zu vorhin mit einer alter tablespace-Anweisung. Im Rahmen des Befehls können Sie zusammen mit der Klausel add dem Tablespace eine zusätzliche Datei zuweisen, wobei Sie mit Hilfe der schon bekannten Parametern die Anfangsgröße, sowie bei automatischem Wachstum auch die Schritt- und Maximalgröße der Datei vorgeben müssen.


223

Umzug der Datendateien Wird es insgesamt eng, dann kann vielleicht ein Umzug der einen oder anderen Datei helfen. Das geht allerdings nicht mit einem einzigen Befehl, sondern hierzu benötigen Sie mal wieder einen kleineren Ablauf, bei dem auch Betriebssystemaktivitäten notwendig werden. Die prinzipielle Vorgehensweise zum Umzug der zu einem Tablespace gehörenden Dateien ist folgender: 1. Inaktivieren Sie den betreffenden Tablespace. Verwenden Sie hierzu den Zusatz „normal“, damit alle noch laufenden Transaktionen ordentlich abgeschlossen werden. alter tablespace usr offline normal;

2. Kopieren bzw. verschieben Sie die betreffenden Dateien an die gewünschten neuen Stellen. Bei Bedarf können Sie die Dateien dabei auch umbenennen. In meinem Fall habe ich die Dateien einfach nur umbenannt, da ich eigentlich keinen Anlass für einen Umzug hatte. 3. Ändern Sie die Dateizuordnung in der Tablespacedefinition. Hierzu gibt es eine spezielle Variante des alter tablespace-Befehls. alter tablespace usr rename datafile 'E:\ORANT\DATABASE\DB01\USR1DB01.ORA', 'E:\ORANT\DATABASE\DB01\USR2DB01.ORA' to 'E:\ORANT\DATABASE\DB01\USR1DB01a.ORA', 'E:\ORANT\DATABASE\DB01\USR2DB01a.ORA';

Mit Hilfe dieser Variante wird die Liste der hinter den Schlüsselwörtern rename datafile spezifizierten Dateien gegen die hinter dem Wörtchen to aufgezählten Dateinamen ausgetauscht. 4. Machen Sie den Tablespace wieder verfügbar, indem Sie ihn in Analogie zum Schritt Nr. 2 wieder einschalten. alter tablespace usr online;

5. Denken Sie immer daran: Wer sichert, ist feige :-). Der letzte Punkt war natürlich nicht so ernst gemeint. Denken Sie bei solchen Aktionen immer daran, dass Sie quasi am offenen Herzen operieren. Ich würde mich ohne Netz und doppelten Boden an kein Trapez hängen, Sie etwa? Von daher würde ich die betroffenen Dateien immer kopieren (statt verschieben) und auch erst dann Löschen, wenn der Tablespace wieder online ist und funktioniert. Noch sicherer ist natürlich das vorherige Herunterfahren der gesamten Datenbank und das anschließend Backup aller Daten- und Kontrolldateien.

2.3.3

Anlegen des Schemas

Jetzt ist es endlich soweit und wir beginnen damit, die in Abbildung 2.19 dargestellte Struktur unserer kleinen Personaldatenbank anzulegen. Alle gleich folgen-

224


den kleinen Skripte finden Sie auf der Begleit-CD in dem \DATEN-Verzeichnis. Dabei entsprechen die Dateinamen den Namen der angelegten Tabellen zuzüglich der Endung .SQL (z.B. PERSONALIEN.SQL). Personalien In der Tabelle speichern wir später unsere Personalstammdaten. Wie Sie der Abbildung 2.19 entnehmen können, enthält sie eine Reihe von Fremdschlüsseln, deren Überwachung wir allerdings erst zu einem späteren Zeitpunkt mit Hilfe verschiedener Constraints implementieren werden. Die Tabelle erhält einen Primärschlüssel und einen expliziten Index für das Feld „name“. drop table personalien; / create table personalien ( persnr varchar2(11) not null, name varchar2(50) not null, strasse1 varchar2(35), strasse2 varchar2(35), strasse3 varchar2(35), strasse4 varchar2(35), ort varchar2(30), land varchar2(3), bland varchar2(6), plz varchar2(12), telefon varchar2(24), geschlecht varchar2(1) not null, familienstd varchar2(1) not null, familienstd_dt date, gebdatum date not null, gebort varchar2(30), gebland varchar2(3) not null, constraint persnr_pk primary key (persnr) using index tablespace indx storage (initial 100K next 100K) ) tablespace usr storage (initial 100K next 100K ); / create index personalien1 on personalien (name) tablespace indx storage (initial 100K next 100K) / commit; Listing 2.71: Anlage der Tabelle „personalien“


225

Länder Mit Hilfe der Ländertabelle werden die in den Personalien erfassten Länderschlüssel vertextet. Der Schalter im Feld bland gibt vor, ob es für das Land in der Tabelle blaender eine weitere Unterteilung (z.B. Bundesländer) gibt oder nicht. Für das Feld „bland“ sind nur die Werte „Y“ bzw. „N“ gültig, was mit Hilfe eines entsprechenden check-Constraints geprüft wird. Außerdem erhält die Tabelle wieder einen Primärschlüssel. drop table laender; / create table laender ( land varchar2(3) not null, bland varchar2(1) default 'N' not null , bezeichnung varchar2(30), constraint laender_pk primary key (land) using index tablespace indx storage (initial 10K next 10K), constraint bland_check check (bland in ('Y','N')) ) tablespace usr storage (initial 20K next 20K ); / commit; Listing 2.72: Anlage der Ländertabelle „laender“

Bundesländer Mit Hilfe der jetzt folgenden Tabelle kann eine weitergehende Unterteilung der Länder in Bundesländer oder Provinzen durchgeführt werden. Die Tabelle besitzt als ersten Schlüssel das Feld „land“, der wiederum ein geliehener Schlüssel aus der Ländertabelle ist. Der zweite Schlüssel kodiert das jeweilige Bundesland und wird in den Personalstammdaten erfasst. Dabei regelt der in der Ländertabelle vorhandene Schalter „bland“, ob Bundesländer verfügbar sind bzw. erfasst werden müssen. drop table blaender; / create table blaender ( land varchar2(3) not null, bland varchar2(6) not null, bezeichnung varchar2(30), constraint blaender_pk primary key (land, bland) using index tablespace indx storage (initial 10K

226


next 10K) ) tablespace usr storage (initial 20K next 20K ); / commit; Listing 2.73: Anlegen der Bundesländer in der Tabelle „blaender“

Beschäftigungsverhältnisse In unserer Personaldatenbank kann ein Mitarbeiter mehr als ein Beschäftigungsverhältnis haben. Solche unterschiedlichen BV’s können beispielsweise dadurch entstehen, dass ein Mitarbeiter im Laufe seines Lebens mehrfach in einem Unternehmen einbzw. austritt. Aber auch die Versetzung in ein anderes Konzernunternehmen führt zu einem neuen Beschäftigungsverhältnis. Diese BV’s hängen direkt an den Personalien und werden mit Hilfe einer laufenden Nummer fortlaufend durchnummeriert. Ansonsten erhält die Tabelle zunächst einmal zwei Constraints, mit denen der Primärschlüssel und eine Werteprüfung für das Feld „lfdnr“ erstellt wird. Beachten Sie auch noch einmal die vorhandenen Verknüpfungen zu den Tabellen „unternehmen“ und „austrittsgruende“ über die entsprechenden Datenfelder. Die Realisierung der hier notwendigen Maßnahmen zur Überwachung der referentiellen Integrität wird uns aufgrund der Historisierung der Referenztabellen im weiteren Verlauf des Buches noch Freude machen. drop table bvs; / create table bvs ( persnr varchar2(11) not null, lfdnr smallint not null, eintrt date not null, austrt date, ausgrd varchar(3), unternehmen varchar(3) not null, constraint lfdnr_check check (lfdnr >= 0), constraint bvs_pk primary key (persnr, lfdnr) using index tablespace indx storage (initial 10K next 10K) ) tablespace usr storage (initial 20K next 20K ); / commit; Listing 2.74: Anlage der Beschäftigungsverhältnisse


227

Unternehmen Mit Hilfe der folgenden Tabelle speichern und vertexten wir die verfügbaren Unternehmen. Dabei ist die Tabelle historisch aufgebaut, d.h. pro Unternehmen kann es mehrere Datensätze mit unterschiedlichen gültig-ab-Daten („gab“) geben. In dem Zusammenhang ist des Feld „status“ besonders beachtenswert. Selbst ohne echte Historien können Sie ein Unternehmen ab einem bestimmten Termin inaktivieren, indem Sie einen neuen Datensatz einfügen und anschließend im Statusfeld den Wert „I“ (=inaktiv) speichern. Der Wertebereich für das Statusfeld und der Primärschlüssel der Tabelle werden mit Hilfe entsprechender Constraints angelegt. drop table unternehmen; / create table unternehmen ( unternehmen varchar2(3) not null, gab date not null, status varchar2(1) default 'A' not null, bezeichnung varchar2(30) not null, constraint status_chk check (status in ('A','I')), constraint unternehmen_pk primary key (unternehmen, gab) using index tablespace indx storage (initial 10K next 10K ) ) tablespace usr storage (initial 20K next 20K ); / commit; Listing 2.75: Erstellen der Unternehmenstabelle

Kostenstellen Mit Hilfe der Kostenstellentabelle werden die Kostenstellen definiert, die selbst wiederum unternehmensbezogen sind, d.h. in unserem Datenmodell besitzt jedes Unternehmen seine eigenen Kostenstellen. Genau wie die Unternehmen, besitzen auch die Kostenstellen ein Historiendatum („gab“) und ein Statusfeld, mit dem die Verwendung einer nicht mehr gültigen Kostenstelle ausgeschlossen werden soll. Die Wertebereichsprüfung für den Status und der Primärschlüssel der Tabelle werden auch hier wieder mit Hilfe entsprechender Constraints realisiert. drop table kostenstelle; / create table kostenstelle ( unternehmen varchar2(3) not null, kst varchar2(10) not null, gab date not null,

228


status varchar2(1) default 'A' not null, bezeichnung varchar2(30) not null, constraint kst_status_chk check (status in ('A','I')), constraint kostenstelle_pk primary key (unternehmen, kst, gab) using index tablespace indx storage (initial 10K next 10K) ) tablespace usr storage (initial 20K next 20K); / commit; Listing 2.76: Anlage einer Tabelle zum Speichern der Kostenstellen

Gehälter Von Steuern und Sozialversicherungsabgaben wollen wir nichts wissen, aber wenigstens Gehalt sollen unsere fiktiven Mitarbeiter bekommen. Aus diesem Grund existiert in unserem Schema ein kleiner Gehaltsdatensatz, mit dessen Hilfe wir das Gehalt und die Kostenstelle des Mitarbeiters speichern können. Wie im richtigen Leben, so hoffen auch unsere virtuellen Mitarbeiter natürlich auf häufige und entsprechend üppige Gehaltsveränderungen, weshalb die Gehaltstabelle wieder historisch aufgebaut ist. Außerdem hängt sie natürlich nicht direkt an den Personalien, denn das Vorhandensein eines Beschäftigungsverhältnisses ist eine Voraussetzung für jegliche Gehaltszahlung. Ansonsten wird hier nur die Kostenstelle als Fremdschlüssel aus der Kostenstellentabelle entliehen. Neben der Erstellung des Primärschlüssels finden Sie hier zur Zeit nur zwei weitere Constraints, mit denen die Beträge der beiden Gehaltsfelder überprüft werden. drop table gehalt; / create table gehalt ( persnr varchar2(11) not null, lfdnr smallint not null, gab date not null, kst varchar2(10) not null, gehalt number(9,2) not null, zulage number(9,2) not null, constraint gehalt_ck check (gehalt >= 0), constraint zulage_ck check (zulage >= 0), constraint gehalt_pk primary key (persnr, lfdnr, gab) using index tablespace indx storage (initial 10K next 10K) ) tablespace usr


storage

229

(initial 30K next 30K );

/ commit; Listing 2.77: Erstellen der Gehaltstabelle

Austrittsgründe Damit kommen wir zunächst einmal zur letzten unserer Stammdatentabellen. Wie Sie wieder der Abbildung 2.19 entnehmen können, werden die Austrittsgründe aus den Beschäftigungsverhältnissen heraus referenziert. Die Historisierung der Tabelle wird auch diesmal wieder primär aus der Notwendigkeit getrieben, einen vorhandenen Schlüssel ab einem bestimmten Datum zu inaktivieren. Aus dem Grund finden Sie also auch hier wieder die beiden Felder „gab“ und „status“. Durch die vorhandenen Constraints wird zunächst wieder der Primärschlüssel gebildet und es erfolgt die Überwachung der im Statusfeld verwendeten Werte. drop table austrittsgruende; / create table austrittsgruende ( ausgrd varchar2(3) not null, gab date not null, status varchar2(1) default 'A' not null, bezeichnung varchar2(30) not null, constraint aus_status_chk check (status in ('A','I')), constraint austrittsgruende_pk primary key (ausgrd, gab) using index tablespace indx storage (initial 10K next 10K) ) tablespace usr storage (initial 10K next 10K); / commit; Listing 2.78: Anlegen einer Tabelle zum Speichern der Austrittsgründe

Nach Anlage dieser letzten Tabelle ist unser Schema zunächst einmal fertiggestellt. Zu einem späteren Zeitpunkt werden wir uns um die Einrichtung der referentiellen Integritätsüberwachung kümmern, d.h. am Ende des Kapitels zur PL/SQL-Programmierung finden Sie mögliche Verfahrensweisen hierzu.

230

2.4


Datenmigration

Wenn Sie schon einmal an einem größeren Umstellungsprojekt mitgearbeitet haben, dann wissen Sie, dass irgendwann der Zeitpunkt kommt, an dem man die grüne Entwicklungswiese verlassen muss und wo es darum geht, die Daten aus den Altanwendungen in das neue System zu übertragen. Da es dabei in der Praxis meistens schon um mehr als eine Handvoll von Datensätzen geht, ist es schon ein interessanter Aspekt, sich einmal anzuschauen, welche Hilfsmittel und Möglichkeiten Oracle hierbei bietet. Normalerweise werden die alten Daten nicht deckungsgleich in die neue Struktur passen, d.h. Sie haben es im Wesentlichen mit den drei folgenden Problemen zu tun:

X

X

X

Die Daten sind im neuen System anders strukturiert. Dabei gibt es nicht nur neue und andere Schlüsselbegriffe, sondern auch die Stammdaten werden im neuen System vielleicht anders gruppiert, bestimmte Informationen (z.B. Historien) werden anders dargestellt. Die benötigten Daten müssen üblicherweise zunächst aus den Altsystemen bereitgestellt bzw. exportiert werden, wobei wir einfach mal davon ausgehen, dass es sich hierbei nicht um eine Oracle-Datenbank handelt. Manchmal müssen alle benötigten Informationen sogar aus verschiedenen Quellen eingesammelt werden. Letztendlich existiert dann auch noch ein Importproblem, denn die aus den Altsystemen erhaltenen Daten kommen schließlich nicht von alleine in die neue Datenbank.

Gerade der zuerst genannte Punkt würzt das insgesamt vorhandene Problem ganz pikant, denn wir haben es hier nicht nur mit einer rein technischen Aufgabenstellung zu tun, sondern benötigen während der Migration eine Menge von Ablauflogik, um die gelesenen Daten umzuformatieren, zu mischen oder entsprechend der neuen Struktur zu speichern. Welche Möglichkeiten Sie in Bezug auf den Export der Daten haben, das hängt natürlich wesentlich von dem konkret vorliegenden Altsystem ab. In unserem Beispiel geht es auch weniger darum, wie die Daten aus dem Altsystem kommen, sondern es interessiert vornehmlich die Frage, wie diese Daten aussehen sollten, damit sie besonders einfach in eine Oracle-Datenbank importiert werden können. Insgesamt denke ich, erhalten Sie im weiteren Verlauf dieses Kapitels viele Informationen und Anregungen, auf welche Art und Weise Sie eine solche Migrationsaufgabe anpacken können.

2.4.1

Variationsmöglichkeiten

Es gibt bekanntlich viele Wege nach Rom. Alle diese Wege unterscheiden sich, allerdings nicht immer unbedingt in gut oder schlecht bzw. lang oder kurz. So gibt es auch hier mal wieder kein Patentrezept, kein schwarz oder weiß in Bezug auf den optimalen Lösungsweg Ihre Oracle-Datenbank mit Altdaten zu versorgen. Nach

Datenmigration

231

meiner Erfahrung, und die ist was Migrationsaufgaben angeht schon ganz beachtlich, schadet es nicht, wenn Sie in Ihrem Konzept über die nachfolgende Aspekte zumindest einmal nachdenken.

X

X

X

X

X

X

Artenreichtum lässt das Herz eines jeden Botanikers höher schlagen. Bei Migrationsaufgaben sollte man die Anzahl der Varianten eher gering halten. Wenn Sie hunderte von Tabellen migrieren und dabei für jede zweite Tabelle ein neues Verfahren erfinden, dann ist die Aufgabenstellung irgendwann nur noch von Ihnen selbst durchführbar und mich würde es nicht wundern, wenn in Folge der Hektik des Tages „x“ selbst Ihnen Fehler unterlaufen. Vermeiden Sie Mischformen. Wie schon angedeutet, benötigt man im Rahmen des Datentransports häufig eine gewisse Ablauflogik. Nach meiner Erfahrung hat es sich bewährt, wenn man sich dabei entscheidet, diese Logik entweder im Ziel oder in der Quelle zu realisieren und diese selbstauferlegte Restriktion auch weitestgehend einzuhalten. Als Konsequenz dieses Handelns ist eine der beiden beteiligten Schnittstellen dann meistens sehr einfach aufgebaut. Liegen die Daten beispielsweise aufgrund komplexer Exportprogramme genau in der benötigten Form vor, dann können Sie diese mit Hilfe von Standardtools in die Datenbank einspielen. Umgekehrt können Sie die Daten vielleicht mit Hilfe von vorhandenen Utilities exportieren, wenn Sie die benötigten Importfunktionalitäten im neuen System geplant haben (vgl. Abb. 2.20). Migration ist kein Einmalgeschäft. Sicherlich spielen die durchgeführten Importaktivitäten nach dem Projektende keine große Rolle mehr und trotzdem sollten Sie sich vom dem Gedanken des einmaligen Verwendungszwecks nicht zu allzu abenteuerlichen Verfahrensweisen, womöglich mit vielen manuellen Eingriffen, verleiten lassen. Meistens stellt sich während des Projekts nämlich heraus, dass die Migrationsaktiviäten zumindest bis zum Projektende aufgrund verschiedener Testdatenbanken, eventueller Vorabpilotierung bestimmter Anwendungsteile doch regelmäßiger als zunächst geplant eingesetzt werden. Berücksichtigen Sie von vornherein das zu erwartende Mengengerüst. Mit zehn Datensätzen klappt jedes denkbare Verfahren. Bei mehren Millionen Datensätzen sieht das ganz anders aus. Selbst bei ein paar tausend Datensätzen würde ich nach meiner Erfahrung davon abraten ein Verfahren zu konstruieren, das stark von der Existenz einer vorhandenen Netzwerkverbindung abhängt. Verlagern Sie das gesamte Migrationsgeschäft möglichst direkt auf die Server, d.h. verwenden oder schreiben Sie nur Programme, die direkt auf den Datenbankservern lauffähig sind. Ebenso sollten Sie von vornherein Mechanismen vorsehen, die es Ihnen ermöglichen, abgebrochene Migrationsjobs wieder aufzusetzen und das gesamte Übernahmeverfahren sollte möglichst modular aufgebaut werden, damit im Fehlerfall nicht immer nur alle sondern auch einzelne Tabellen neu aufgebaut werden können. Überlegen Sie sich, ob Sie den Datenimport mit oder ohne aktivierte Prüfroutinen, egal ob in der Form spezieller Constraints oder über Triggerprogramme, durchführen wollen. Ohne diese Prüfroutinen geht das Laden der Daten sicherlich schneller, allerdings sollten Sie in dem Fall auch schon gewissen Konsis-

232


tenzprüfungen in den Importprogrammen vorsehen. Manchmal hat man aber auch gar keine Wahl für die eine oder andere Variante, beispielsweise dann, wenn aufgrund komplexer Abhängigkeiten quasi alle Daten in einem logischen Schritt geladen werden müssten.

Quelle

Exportprogramm(e)

Exportdateien

Export-Utilitie

Import

Import-Utilitie Abfragen, SQL-Programme

Ziel

Abbildung 2.20: Gegenüberstellung zweier gängiger Migrationsvarianten

Die Abbildung 2.20 verdeutlicht den beschriebenen Zusammenhang der Mischformen noch einmal. Entsprechend der links dargestellten Verfahrensweise wurden die benötigten Daten mit Hilfe komplexer Exportprogramme gemäß der neuen Datenbankstruktur aufbereitet. Aus diesem Grund können die Exportdateien mit Hilfe eines Oracle-Ladetools direkt in die neuen Zieltabellen importiert werden, d.h. im Ziel findet keine Aufbereitungslogik der Daten mehr statt. Im Gegensatz dazu werden die Daten im rechten Teil der Abbildung 2.20 mit Hilfe eines Exporttools oder zumindest sehr einfacher Programme aus dem Quellsystem ausgegeben. Anschließend werden die Daten wieder mit Hilfe eines Oracle-Werkzeugs in entsprechende Arbeitstabellen geladen, von wo aus sie mit Hilfe entsprechender Abfragen oder PL/SQL-Programme in die jeweiligen Zieltabellen verteilt werden. Alternativ hierzu wären auch noch spezielle Importprogramme denkbar, die die einzelnen Importdateien verarbeiten und dabei die neuen Zieltabellen direkt beschreiben. Allerdings sollte man in dem Fall darauf achten, dass hierbei nur Programme eingesetzt werden, die direkt auf dem Datenbankserver lauffähig sind.

Datenmigration

233

Ich persönlich würde meistens den im rechten Teil der Abbildung skizzierten Weg bevorzugen. Das liegt zum einen schon an der von mir geforderten Einschränkung an Varianten, denn in der Praxis existiert in größeren Projekten mehr als eine Datenquelle mit einer Bandbreite von der Mainframe-IMS-Datenbank bis hin zum manuell erstelltem Excel-Spreadsheet. In dem Fall haben Sie eigentlich gar keine Chance, die Daten mit Hilfe der Exportprogramme fertig aufzubereiten. Zum anderen liegt es sicherlich auch an den Quellen selbst, die oft nur mit Hilfe schwerfälliger Programme oder anfälligen Makros abgefragt werden können. Sind die Daten aber erst einmal in der Oracle-Datenbank angekommen, dann steht Ihnen mit SQL bzw. PL/ SQL ein nahezu unerschöpfliches Repertoire an Möglichkeiten zur Verfügung.

2.4.2

Laden unserer Beispiel-DB

Nach diesen allgemeinen Vorbemerkungen wollen wir uns nun wieder unserer kleinen Personaldatenbank widmen und damit beginnen, sie mit Daten zu füllen. Dabei entspricht die von uns verwendete Methode dem linken Teil der Abbildung 2.20, d.h. die zu importierenden Daten liegen in einer dem Ziel entsprechenden Form vor, und obwohl ich vorhin gesagt habe, dass es so etwas im richtigen Leben eigentlich gar nicht gibt, so ist es für uns dennoch interessant, weil es uns hier vornehmlich darauf ankommt, zu schauen, wie die Daten mit Hilfe von Oracle-Tools oder anderen Methoden geladen werden können. Austrittsgründe Für kleine Tabellen kann es sinnvolle Variante sein, den Importvorgang mit Hilfe eines SQL-Skripts durchzuführen. In dem Fall müssen Sie die zu importierenden Daten in entsprechende insert-Anweisungen verpacken. Die Daten der Austrittsgründe finden Sie auf der Begleit-CD in der Datei \DATEN\AUSTRITTSGRUENDE.TXT und das Importskript heißt IMP_AUSTRITTSGRUENDE.SQL. Ursprünglich stammen Sie aus der vorhandenen Access-Datenbank und wurden mit Hilfe der dort vorhandenen Abfrage „export austrittsgruende“ als Datei mit fester Satzlänge exportiert. insert into austrittsgruende (ausgrd, gab, status, bezeichnung) to_date('01.01.1990','DD.MM.YYYY'),'A','Kündigung AN'); insert into austrittsgruende (ausgrd, gab, status, bezeichnung) to_date('01.01.1990','DD.MM.YYYY'),'A','Kündigung AG'); insert into austrittsgruende (ausgrd, gab, status, bezeichnung) to_date('01.01.1990','DD.MM.YYYY'),'A','Versetzung'); insert into austrittsgruende (ausgrd, gab, status, bezeichnung)

values ('55', values ('56', values ('60', values

Wir betten diese Textdatei in folgende Anweisungsfolge ein, mit der zum einen die Tabelle vorab gelöscht und am Ende die ganze Transaktion mit einem commitBefehl abgeschlossen wird. truncate table austrittsgruende; @c:\temp\austrittsgruende.txt; commit; Listing 2.79: Einspielen der Austrittsgründe (IMP_AUSTRITTSGRUENDE.SQL)

234


Wenn Sie sich nun fragen, warum ich das so kompliziert mache, und die truncatebzw. commit-Befehle nicht einfach mit in die Textdatei schreibe, dann kann ich darauf nur entgegnen, dass ich mich ja wenigstens in diesem Buch an meine eigenen Regeln halten will, denn durch diese Trennung wird der gesamte Prozess ohne manuelle Eingriffe wiederholbar. Einfach die Austrittsgründe neu exportieren und danach das Importskript erneut starten. Länder Die Ländertabelle importieren wir genau wie die Austrittsgründe. Die zugehörigen Daten finden Sie wieder in Form von insert-Anweisungen in der Datei \DATEN\LAENDER.TXT; das Importskript befindet sich in der Datei IMP_LAENDER.SQL. Die Datendatei wurde aus der Access-Datenbank mit Hilfe der Abfrage „export laender“ erstellt. insert insert insert insert insert insert

into into into into into into

laender laender laender laender laender laender

(land, (land, (land, (land, (land, (land,

bland, bland, bland, bland, bland, bland,

bezeichnung) bezeichnung) bezeichnung) bezeichnung) bezeichnung) bezeichnung)

values values values values values values

('DEU','Y','Deutschland'); ('AUT','Y','Österreich'); ('BEL','N','Belgien'); ('GBR','N','Grossbritannien'); ('FIN','N','Finnland'); ('FRA','N','Frankreich');

Die Datei können Sie folgendermaßen einspielen: truncate table laender; @c:\temp\laender.txt; commit; Listing 2.80: Einspielen der Ländertabelle (IMP_LAENDER.SQL)

Bundesländer Genau wie bisher gehen wir auch bei den Bundesländern vor. Die zum Importieren benötigten insert-Anweisungen und das Importskript finden Sie in den Dateien BLAENDER.TXT bzw. IMP_BLAENDER.SQL. Die Datendatei wurde aus der AccessDatenbank mit Hilfe der Abfrage „export blaender“ erstellt. insert len'); insert insert insert

into blaender (land, bland, bezeichnung) values ('DEU','NW','Nordrhein-Wesfahinto blaender (land, bland, bezeichnung) values ('DEU','BY','Bayern'); into blaender (land, bland, bezeichnung) values ('DEU','BE','Berlin'); into blaender (land, bland, bezeichnung) values ('DEU','HH','Hamburg');

Die Datei spielen Sie wieder mit Hilfe folgender Anweisungen in die Datenbank ein: truncate table blaender; @c:\temp\blaender.txt; commit; Listing 2.81: Importieren der Bundesländer (IMP_BLAENDER.SQL)

Datenmigration

235

Unternehmen Die nächste kleine Referenztabelle enthält die Unternehmen unserer Datenbank und wird mit Hilfe der Dateien UNTERNEHMEN.TXT bzw. IMP_UNTERNEHMEN.SQL importiert. Die Daten stammen ebenfalls aus der Access-Datenbank und wurden mit Hilfe der dortigen Abfrage „export unternehmen“ erstellt. insert into unternehmen (unternehmen, gab, status, bezeichnung) values to_date('01.01.1990','DD.MM.YYYY'),'A','Raymans EDV Beratung'); insert into unternehmen (unternehmen, gab, status, bezeichnung) values to_date('01.01.1998','DD.MM.YYYY'),'A','Raymans Medienberatung'); insert into unternehmen (unternehmen, gab, status, bezeichnung) values to_date('01.11.2001','DD.MM.YYYY'),'I','Raymans Medienberatung'); insert into unternehmen (unternehmen, gab, status, bezeichnung) values to_date('01.01.1992','DD.MM.YYYY'),'A','Raymans Consulting GmbH');

('001', ('002', ('002', ('001',

Das Einspielen der Unternehmensdaten erfolgt in der mittlerweile gewohnten Weise: truncate table unternehmen; @c:\temp\unternehmen.txt; commit; Listing 2.82: Einspielen der Unternehmen (IMP_UNTERNEHMEN.SQL)

Kostenstellen Die letzte unserer Referenztabellen enthält die Kostenstellen und da das ganze Verfahren mittlerweile langweilig wurde, habe ich hier einmal das Hinzufügen manuell erfasster Kostenstellen simuliert. Zum einen finden Sie daher die Datei KOSTENSTELLEN.TXT, deren Inhalt mit Hilfe der Abfrage „export kostenstellen“ aus der Access-Datenbank exportiert wurde. Zum anderen enthält Ihre CD aber noch eine zweite Datei mit dem treffenden Namen MANUELLE_KST.TXT, die eine selbsterfasste Kostenstelle enthält. Das zum Import verwendete Skript finden Sie in der Datei IMP_KOSTENSTELLEN.SQL. insert into kostenstelle (unternehmen, kst, gab, status, bezeichnung) values ('001','PSOFT', to_date('01.01.1992','DD.MM.YYYY'),'A','PeopleSoft-Beratung'); insert into kostenstelle (unternehmen, kst, gab, status, bezeichnung) values ('001','PERS', to_date('01.01.1990','DD.MM.YYYY'),'A','Personalabteilung'); insert into kostenstelle (unternehmen, kst, gab, status, bezeichnung) values ('002','MARK', to_date('01.01.1998','DD.MM.YYYY'),'A','Marketing');

Das folgende Skript zum Einspielen der Kostenstellen bindet ausnahmsweise einmal zwei Datendateien ein. truncate table kostenstellen; @c:\temp\kostenstellen.txt; @c:\temp\manuelle_kst.txt; commit; Listing 2.83: Einspielen der exportierten und manuell erfassten Kostenstellen

236

2.4.3


Der Data Manager

Eigentlich alle aktuellen Datenbanksystem liefern ein Werkzeug, um sequentielle Dateien (sogenannte „Flatfiles“) zu importieren. Der Vorteil dieser Programme besteht dabei im Unterschied zu allen anderen denkbaren Alternativen eigentlich immer in der rasanten Arbeitsgeschwindigkeit, mit der die importierten Daten in die Zieltabellen geschrieben werden. Bei Oracle ist so ein Werkzeug natürlich auch vorhanden. Es handelt sich hierbei um den sogenannten Data Manager, mit dem allerdings nicht nur die hier benötigten Importaufgaben erledigt werden können. Bei dem Data Manager handelt es sich um ein Programm, mit dem Sie zum einen einzelne Tabellen bis hin zu ganzen Datenbanken exportieren und auch wieder einspielen können. Damit eignet sich dieses Werkzeug beispielsweise zum Sichern einzelner Tabellen oder ermöglicht auch den Umzug einer ganzen Datenbank beispielsweise in eine neue Rechnerumgebung. Zum anderen können Sie das Programm auch zum Importieren von gewöhnlichen Textdateien verwenden. Ähnlich wie bei SQL*Plus besitzen auch die zum Data Manger gehörenden Programme die Eigenschaft, dass sie sowohl auf allen denkbaren Plattformen zu Hause sind, als auch, dass sie überall gleich bedient werden. Für den NT-Client bietet Oracle allerdings mal wieder eine Luxusversion an, und hat den drei genannten Funktionen (Export, Import, Laden) eine übliche Windows-Oberfläche übergestülpt. Bei der 8er-Version finden Sie das Programm-Icon für diese Oberfläche normalerweise in der Programmgruppe „Oracle Enterprise Manager“; ansonsten können Sie auch das zugehörige Programm VAD.EXE direkt aufrufen. Bei der 8i-Version erhalten Sie den Zugang zu dem Programm mit Hilfe des Werkzeuge-Menüs. Folgen Sie dort dem Eintrag „Datenverwaltung“ und anschließend dem Menü „Laden“, um zu den entsprechenden Ladeassistenten zu gelangen. Die wesentlichen Bestandteile des Programms finden Sie im Data-Menü. Dort verzweigen Sie mit Hilfe der Einträge Export, Import und Load in jeweils unterschiedliche Assistenten (vgl. Abb. 2.22), die alle notwendigen Eingaben und Parameter abfragen, um anschließend das eigentliche Programm zu starten oder einen entsprechenden Job innerhalb der Datenbank zu triggern. Letzteres funktioniert natürlich nur dann, wenn das zugehörige System zur Jobsteuerung auf Ihrem Datenbankserver aktiviert wurde. Wie schon gesagt, benötigen wir in unserem Fall zum Laden der übrigen Tabellen unserer Personaldatenbank die Ladefunktion (SQL*Loader) des Data Managers. Konkret verbirgt sich dahinter unter NT das Programm SQLLDR80.EXE bzw. SQLLDR.EXE bei der 8i-Version (bzw. einfach nur SQLLDR, z.B. unter AIX). In jedem Fall sollten Sie darauf achten, dass Sie das Programm auf dem Datenbankserver starten, damit seine rasante Arbeitsgeschwindigkeit voll zur Geltung kommt und nicht durch ein eventuelle lahmes Netzwerk ausgebremst wird.

Datenmigration

Abbildung 2.21: NT-Oberfläche des Data Managers in der 8er-Version

Abbildung 2.22: Assistent zum Abfragen der benötigten Ladeparameter

237

238


Starten des SQL*Loaders Das Programm erwartet beim Aufruf eine Reihe von Kommandozeilenparametern, die zum Teil allerdings auch in einer sogenannten Kontroll- bzw. Steuerungsdatei, die ebenfalls Teil der Kommandozeilenparameter ist, verwendet werden können. Bei dem Verwenden von Parametern müssen Sie entweder eine strikte Reihenfolge beachten, oder die einzelnen Parameterwerte mit Hilfe eines Schlüsselworts in der Form <Schlüssel>=<Wert> übergeben. Da ich es praktischer finde, die Steuerung des Ladeprogramms mit Hilfe einer Parameterdatei durchzuführen, finden Sie die Erläuterung der aus meiner Sicht wichtigsten drei Parameter in der folgenden Tabelle 2.5.

Parameter

Beschreibung

USERID

Übergeben Sie mit Hilfe dieses Schlüssels eine gültige Verbindungszeichenfolge in der üblichen Form /<Passwort>@<Servicename> (z.B.„system/ manager@db01“). Den Servicenamen müssen Sie natürlich weglassen, wenn Sie beim Laden die direkte Methode verwenden.

CONTROL

Verwenden Sie den Parameter, um mit ihm den Namen und Pfad der Steuerdatei zu spezifizieren. Auf den Aufbau dieser Steuerdatei werde ich später noch zurückkommen; kurz zusammengefasst enthält die Steuerdatei den Namen und den Aufbau der Importdatei.

DIRECT

Diesen Parameter müssen Sie nur zusammen mit dem Wert „TRUE“ verwenden, d.h. ansonsten können Sie ihn weglassen, so dass das Ladeprogramm von „FALSE“ ausgeht. Was beim direkten Laden genau passiert, das können Sie ein paar Zeilen weiter erfahren.

Tabelle 2.5: Tabelle 2.5: Wichtige Parameter für den Aufruf des SQL*Loaders

Direktes Laden Bezüglich der Option des direkten Ladens (DIRECT=TRUE) findet man in manchen Handbüchern schon manchmal mystisch anmutende Erklärungen. Ich will einmal versuchen das was eigentlich dahinter steckt, mit einfachen Worten auf den Punkt zu bringen. Bei dieser Methode umgeht Oracle im Prinzip seine internen Strukturen und schreibt die Daten quasi direkt in die zugehörige Tabelle der Datenbank. Eigentlich logisch, dass dies in einer unglaublichen Arbeitsgeschwindigkeit mündet. Aber auch das gibt es mal wieder nicht umsonst, sondern schlägt sich in folgenden Restriktionen nieder.

X

X

Keine Ausführung von in der Datenbank verankerter Logik. Konkret heißt das, dass konsitenzüberwachende Regelwerke, beispielsweise in der Form von definierten Constraints oder Triggern nicht beachtet bzw. ausgeführt werden. Die zu ladenden Daten müssen also in jeglicher Hinsicht in Ordnung sein oder die notwendigen Prüfungen müssen später in einem zweiten, separaten Schritt erfolgen. Die Methode funktioniert nur dann, wenn Sie bei der Ausführung des SQL*Loaders das NET8-Protokoll umgehen können. Letzteres ist in der Regel nur möglich, wenn das Programm direkt auf dem Datenbankserver ausgeführt wird.

Das direkte Laden eignet sich damit vor allem zum Laden von Arbeitstabellen zum Beispiel im Rahmen einer Schnittstelle oder beim erstmaligen Aufbau der Daten-

Datenmigration

239

bank. Weitere Informationen zum Gebrauch dieses Werkzeugs finden Sie im nächsten Kapitel, in dem wir mit dem Aufladen unserer Beispieldatenbank fortfahren und hierzu den SQL*Loader einsetzen. Ansonsten hält auch die Oracle-Dokumentation eine umfangreiche Beschreibung des Werkzeugs bereit. Folgen Sie einfach dem Link „Oracle8 Utilities“, um zur zugehörigen Dokumentation zu finden.

2.4.4

Laden der Stammdaten per SQL*Loader

Im letzten Abschnitt des zweiten Kapitels wollen wir nun das Aufladen unserer Personaldatenbank fortsetzen, indem wir die Stammdaten mit Hilfe des gerade vorgestellten Ladetools von Oracle importieren. Hierbei werden Sie verschiedene Verfahrensweisen kennen lernen, um auf einen eventuell unterschiedlichen Aufbau der Importdateien reagieren zu können. Feste Satzlänge Ein oftmals verwendetes Format bei der Bereitstellung von Exportdateien ist die Verwendung fester Satz- und Feldlängen. Gerade im Großrechnerbereich ist dieses Format häufig anzutreffen, da es in den dort üblichen Programmen so leicht zu verwenden ist. Für unsere kleine Datenbank wollen wir die Personalstammdaten mit Hilfe einer Datei mit fester Satzlänge importieren. Hierzu finden Sie auf der CD die Datei \DATEN\PERSONALIEN.TXT, die per Export aus der in der Access-Datenbank vorliegenden Tabelle gewonnen wurde.

Abbildung 2.23: Öffnen der Personalstamm-Textdatei mit Hilfe eines Editors

240


Wie Sie der Abbildung 2.23 entnehmen können, habe ich der exportierten Textdatei anschließend vier Zeilen vorangestellt, um mir das Zählen der Stellen zu vereinfachen. In den ersten drei Zeilen habe ich eine Art Lineal eingefügt und mit Hilfe der vierten Zeile haben ich die einzelnen Felder mit ihrer maximalen Länge angezeichnet. Diese vier Zeilen dürfen natürlich nicht importiert werden, was Sie im Rahmen der Steuerdatei für den Loader entsprechend einstellen können. Bei dieser Steuerdatei handelt es sich ebenfalls um eine gewöhnliche Textdatei, die Sie mit jedem beliebigen Editor erstellen können. Im Listing 2.84 finden Sie einen Abdruck der zum Laden der Personalien benötigten Steuerdatei, die Sie auf der CD ebenfalls im \DATEN-Verzeichnis unter dem Namen PERSONALIEN.CTL finden. -- Laden der Personalien options ( skip=4 ) load infile badfile discardfile discardmax truncate into table

'c:\temp\personalien.txt' 'c:\temp\personalien.bad' 'c:\temp\personalien.dsc' 999 ubeispiel.personalien

( persnr name strasse1 strasse2 strasse3 strasse4 ort land bland plz telefon geschlecht familienstd familienstd_dt gebdatum gebort gebland

position(01:11) position(12:61) position(62:96) position(97:131) position(132:166) position(167:201) position(202:231) position(232:234) position(235:240) position(241:252) position(253:276) position(277:277) position(278:278) position(279:288)

char, char, char, char, char, char, char, char, char, char, char, char, char, date "DD.MM.YYYY" nullif familienstd_dt=blanks, position(298:307) date "DD.MM.YYYY", position(317:346) char, position(347:349) char

) Listing 2.84: Steuerdatei zum Importieren der Personalien

Datenmigration

241

Wie Sie dem Listing 2.84 entnehmen können, erfolgt die Erfassung der für den Ladevorgang benötigten Steuerdatei in freier Form. In unserem konkreten Beispiel erstellen wir hierbei die beiden Abschnitte options und load. Mit Hilfe des ersten Abschnittes (options) können Sie verschiedene Parameter festlegen, die im Bedarfsfalle auch per Kommandozeilenparameter festgelegt werden können. Entnehmen Sie der Tabelle 2.6 die Bedeutung der wichtigsten Optionen. Option

Standardwert

Beschreibung

skip

0

Anzahl der Zeilen, die vom Loader aus der Datendatei überlesen werden.

load

Alle

Anzahl der zu importierenden Datensätze.

errors

50

Maximal erlaubte Fehler, bevor das Programm abbricht.

direct

FALSE

Schaltet bei Bedarf den direkten Ladevorgang ein.

Tabelle 2.6: Wichtige Optionen innerhalb der Steuerdatei des SQL*Loaders

Die einzelnen Optionen werden hinter dem Schlüsselwort options in Klammern einfach untereinander aufgezählt und für jede verwendete Option schreiben Sie den benötigten Wert mit Hilfe eines Gleichheitszeichens direkt hinter den jeweiligen Optionsschlüssel. Die Verwendung irgendwelcher Optionen in der Steuerdatei verhindert im Übrigen nicht deren Überschreibung mit Hilfe eines entsprechenden Kommandozeilenparameters. In unserem Beispiel würde also der folgende Programmaufruf sqlldr80 userid=ubeispiel ... skip = 20 sqlldr userid=ubeispiel ... skip = 20

zum Überlesen von 20 anstatt der standardmäßig eingestellten vier Datensätze führen. Der zweite und wichtigere Abschnitt load enthält alle benötigten Dateinamen und auch den Aufbau der Importdatei. Dabei folgen zunächst eine Reihe von Anweisungen, mit denen beispielsweise der Name und Pfad der Importdatei, die zu verwendende Datenbanktabelle und weitere gleich näher beschriebene Optionen festgelegt werden können. Anschließend folgt in Klammern der Aufbau der Importdatei, in dem bei einer festen Satzlänge alle Tabellenfelder den entsprechenden Satzpositionen zugeordnet werden. Parameter

Beschreibung

infile

Pfad und Name der Importdatei. Befinden sich die zu importierenden Daten ebenfalls in der Kontrolldatei, dann müssen Sie für den Parameter infile den Wert „*“ verwenden, wobei die zu importierenden Daten dem Schlüsselwort begindata folgen müssen.

badfile

Hier können Sie eine Datei spezifizieren, in die das Programm alle fehlerhaften Datensätze (z.B. Formatfehler) kopiert.

discardfile

Mit Hilfe dieses Parameters können Sie eine Datei vorgeben, in die das Programm alle Datensätze kopiert, deren Einfügeoperation beispielsweise wegen einer Regelverletzung abgewiesen wurde.

242


Parameter

Beschreibung

discardmax

Anzahl der zulässigen Abweisungen. Die Überschreitung führt zu einem Programmabbruch.

truncate

Verwenden Sie dieses Schlüsselwort, wenn die Tabelle vor dem Importieren gelöscht werden soll. Ohne diesen Parameter werden die importierten Daten an die Tabelle angefügt.

into table

Geben Sie hier den Namen der aufnehmenden Tabelle an.

Tabelle 2.7: Wichtige Ladeparameter

Nach Vorgabe aller benötigten Ladeparameter erfolgt die Definition der zu importierenden Daten. Bei einer festen Satzlänge müssen Sie hierbei jedem Tabellenfeld die entsprechende Satzposition zuweisen, was mit Hilfe des Schlüsselworts position passiert, hinter dem die Anfangs- und Endeposition im Datensatz in Klammern eingetragen wird. Danach folgt die Festlegung des Datentyps, wobei Sie vor allem bei Datumsfeldern das im Datensatz verwendete Format festlegen müssen. Beachten Sie hierbei auch die Klausel nullif familienstd_dt=blanks

die Ihnen ermöglicht, bei leeren Feldern in der Datenbank den Wert „null“ zu speichern. Damit hätten wir alle notwendigen Definitionen durchgeführt und es bleibt nur noch übrig, das Ladeprogramm zu starten und damit die Personalstammdaten zu importieren. Öffnen Sie hierzu ein MS-DOS-Fenster und stellen Sie die Umgebungsvariable oracle_sid auf die zu verwendende Datenbankinstanz ein. Anschließend können Sie den SQL*Loader starten, wobei Sie als Kommandozeilen wenigstens die Anmeldeinformationen und die zu verwendende Steuerdatei übergeben müssen. set oracle_sid=db01 sqlldr80 userid=ubeispiel/manager control=c:\temp\personalien.ctl direct=true log=c:\temp\personalien.log Listing 2.85: Starten des SQL*Loaders zum Importieren der Personalstammdaten

In dem Beispiel finden Sie als letzten Parameter einen Wert, der mit Hilfe des Schlüssels log übergeben wird, und mit dem Sie den Namen und das Ziel des erstellten Ladeprotokolls festlegen können. Als Alternative zur Vorgabe so vieler einzelner Kommandozeilenparameter können Sie diese auch in einer sogenannten Parameterdatei zusammenfassen und anschließend nur die Parameterdatei als Kommandozeilenparameter verwenden. set oracle_sid=db01 sqlldr80 parfile=personalien.par

Innerhalb dieser Parameterdatei können Sie anschließend alle benötigten Kommandozeilenparameter spezifizieren, was vor allem dann Sinn macht, wenn der Ladevorgang mehrfach oder sogar regelmäßig wiederholt wird.

Datenmigration

243

userid=ubeispiel/manger control= c:\temp\personalien.ctl direct=true log=c:\temp\personalien.log

Variable Satzlänge Dieses Format geht sparsamer mit dem für die Exportdatei benötigten Plattenplatz um, in dem für jedes Feld nur der benötigte Platz im Datensatz verwendet wird. Damit ein solcher Datensatz im Nachhinein wieder in die einzelnen Felder zerlegt werden kann, werden diese im Satz mit Hilfe eines speziellen Trennzeichens verbunden. Außerdem ist es üblich, Zeichenketten zusätzlich in Anführungszeichen zu setzen, da ja zumindest theoretisch die Möglichkeit besteht, dass das Trennzeichen selbst auch in der Zeichenkette auftaucht. "mit mir nicht; na ja"; 333; 23.11.1998

Datensätze mit variabler Satzlänge können heutzutage eigentlich mit jeder gängigen Standardsoftware erstellt und direkt mit Hilfe des SQL*Loaders geladen werden. In unserem Beispiel liegen die Gehaltsdaten (Datei: GEHALT.TXT) in diesem Format vor. Die Daten wurden aus der Access-Datenbank mit Hilfe der Exportspezifikation „Gehalt“ erstellt und haben folgenden Aufbau: "PERSNR";"LFDNR";"GAB";"KST";"GEHALT";"ZULAGE" "7000001";0;01.01.1990 00:00:00;"PERS";4500.00;500.00 "7000002";0;01.04.1998 00:00:00;"PERS";4750.00;300.00 "7000002";0;01.04.1999 00:00:00;"PERS";4980.00;290.00 "7000003";0;01.08.1999 00:00:00;"EDV";6500.00;0.00

Diesmal wurde die erste Datenzeile mit den Feldnamen beim Export automatisch hinzugefügt. Bei vielen Programmen können Sie beim Export explizit vorgeben, ob die erste Datenzeile die Feldnamen enthalten soll oder nicht. Genau wie beim Laden der Personalstammdaten benötigen wir natürlich wieder eine Steuerdatei, die für den SQL*Loader den Satzaufbau beschreibt. -- Laden der Gehälter options ( skip=1 ) load infile 'c:\temp\gehalt.txt' badfile 'c:\temp\gehalt.bad' discardfile 'c:\temp\gehalt.dsc' discardmax 999 truncate into table ubeispiel.gehalt fields terminated by ';' optionally enclosed by '"' (

244

persnr lfdnr gab kst gehalt zulage


position(*) position(*) position(*) position(*) position(*) position(*)

char, integer external, date "DD.MM.YYYY HH24:MI:SS", char, decimal external, decimal external

) Listing 2.86: Steuerdatei zum Importieren der variabel langen Gehaltsdatensätze

Die Steuerdatei finden Sie auf Ihrem Datenträger unter dem Namen GEHALT.CTL. Eigentlich hat sich im Unterschied zu vorhin gar nicht soviel geändert. Zunächst einmal überlesen wir mit Hilfe der skip-Klausel nur noch den ersten Datensatz, der die Feldnamen enthält. Des weiteren sind im load-Abschnitt zwei weitere Optionen hinzugekommen, mit denen wir über die Anweisungen fields terminated by das Feldtrennzeichen und optionally enclosed by das die Textfelder umschließende Sonderzeichen festlegen. Die Definition des Datensatzes erfolgt für die einzelnen Felder jetzt natürlich ohne eine feste Positionsangabe. Der als Platzhalter verwendete Stern führt innerhalb des Programms immer zur Verwendung des nächsten Feldes. Gestartet wird das Programm natürlich genau wie bei der festen Satzlänge, d.h. es wird lediglich eine andere Steuerdatei als Kommandozeilenparameter übergeben. set oracle_sid=db01 sqlldr80 userid=ubeispiel/manager control=c:\temp\gehalt.ctl direct=true log=c:\temp\gehalt.log Listing 2.87: Starten des Imports der Gehaltsdatensätze

Logische Datensätze Mit Hilfe der beiden vorhergehenden Abschnitte haben Sie sicherlich die wichtigsten Verwendungsformen des SQL*Loaders kennen gelernt. Allerdings fehlt uns noch eine Datei zur Vervollständigung unserer Personaldatenstruktur, und so habe ich mir für die noch fehlenden Beschäftigungsverhältnisse ein ganz besonders Format ausgedacht, das aber trotzdem direkt per SQL*Loader in die Datenbank importiert werden kann. 1:PERSNR LFDNR EINTRT 2:UNTERNEHMEN 3:AUSGRD AUSTRT 1:[23456] [23456789] 2:[0] 3:[][23456789] 1:7000002001.04.1998 00:00:00 2:001 3: 15.07.1990 00:00:00 1:7000003001.08.1999 00:00:00 2:001

Datenmigration

245

In dem abgedruckten Muster dienen die ersten sechs Zeilen wieder zur Dokumentation bzw. zum Anzeichnen der in den Sätzen enthaltenen Felder. Die eigentlichen Daten beginnen mit der Zeile sieben. Wie Sie dem Muster entnehmen können, bilden immer zwei bis drei Datensätze zusammen einen logischen Datensatz. Dabei werden die einzelnen Datensätze in der Datei mit Hilfe einer Satzart, die Sie auf den ersten beiden Stellen finden, unterschieden. Außerdem besteht die Möglichkeit, dass der letzte Datensatz einer Gruppe fehlt, weil die dort enthaltenden Daten (Austrittsgrund und Austrittsdatum) nicht vorhanden sind. Innerhalb der einzelnen Datensätze gilt wieder das Format der festen Feld bzw. Satzlänge, d.h. die Satzsätze vom Typ „1:“ sind beispielsweise alle gleich formatiert. Auch diese Datei finden Sie wieder auf der Begleit-CD zum Buch unter dem Namen \DATEN\BVS.TXT. Ebenfalls dort finden Sie auch die für den SQL*Loader benötigte Steuerdatei BVS.CTL. -- Laden der BV's options ( skip = 2 ) load infile 'c:\temp\bvs.txt' badfile 'c:\temp\bvs.bad' discardfile 'c:\temp\bvs.dsc' discardmax 999 truncate continueif next (1:2) '1:' into table ubeispiel.bvs ( persnr lfdnr eintrt unternehmen ausgrd austrt

position(1:7) position(8:8) position(9:27) position(28:30) position(31:32) position(33:51)

char, integer external, date "DD.MM.YYYY HH24:MI:SS", char, char, date "DD.MM.YYYY HH24:MI:SS"

) Listing 2.88: Steuerdatei zum Einspielen der Beschäftigungsverhältnisse

Betrachten Sie zunächst einmal den Parameter für den Wert skip und werfen Sie dabei auch noch mal ein Auge auf den Musterausdruck der Datendatei. An dem Beispiel erkennen Sie, dass die bisherige Erläuterung dieses Parameters nicht ganz richtig ist. Entweder Sie merken sich, dass mit Hilfe des skip-Parameters logische Datensätze überlesen werden oder sie interpretieren den Wert einfach als eine Anzahl von Schreibaussetzern, bevor das Programm mit dem Einfügen der neuen Datensätze beginnt.

246


Wirklich neu in unserer Steuerdatei ist die Anweisung continueif, mit deren Hilfe wir das Ladeprogramm anweisen, solange Sätze aus der Datei einzulesen und aneinanderzuhängen, bis an den ersten beiden Stellen die Satzart „1:“ auftaucht. continueif next (1:2) '1:'

Entsprechend sind auch die Positionierungen auf den gedachten, logischen Datensatz ausgerichtet. Dabei müssen Sie allerdings beachten, dass die Satzarten, also in unserem Beispiel jeweils die ersten beiden Stellen, nicht in dem logischen Datensatz enthalten sind. Das nachfolgende Beispiel verdeutlicht dieses Zusammenhang noch einmal, indem dort die ersten drei Sätze aus der Datei und der hieraus gewonnenen logischen Datensatz gezeigt werden. 1:7000002001.04.1998 00:00:00 2:001 3: 15.07.1990 00:00:00 1 2 3 4 5 6 123456789012345678901234567890123456789012345678901234567890 7000002001.04.1998 00:00:00001 15.07.1990 00:00:00

Auf die eigentliche Verwendung des Programms hat das Ganze natürlich keinen Einfluss, d.h. wir starten wieder das Programm SQLLDR80.EXE unter Verwendung der neuen Steuerdatei. set oracle_sid=db01 sqlldr80 userid=ubeispiel/manager control=c:\temp\bvs.ctl direct=true log=c:\temp\bvs.log

Varianten Neben den hier beschriebenen Möglichkeiten, bietet Ihnen der SQL*Loader noch eine Reihe von Varianten, deren konkrete Verwendung Sie bei Bedarf bzw. Interesse in der Oracle-Dokumentation nachlesen können. Von daher ist die jetzt folgende Aufzählung eher als Ideenfindung zu verstehen, eine Art Brainstorming also.

X

Anstatt nur einer Importdatei (infile) können Sie in der Steuerdatei auch mehrere zu importierende Dateien vorgeben, indem Sie einfach mehrere infile-Parameter verwenden. In dem Fall können Sie ebenfalls mehrer badfile- oder discardfile-Einstellungen vornehmen, um für die einzelnen Importdateien jeweils eigene Fehlerdateien zu erstellen. infile 'datei01' infile 'datei02'

X

badfile 'bad01' badfile 'bad02'

discardfile 'discf01' discardfile 'discf02'

Das Programm SQL*Loader ist in der Lage, eine eventuell notwendige Zeichenkonvertierung durchzuführen, beispielsweise weil Sie Daten importieren, die auf anderen Zeichensatztabellen basieren.

Datenmigration

X

X X

247

Anstelle der truncate-Anweisung, die vor dem Import zum Löschen aller eventuell vorhanden Daten führt, können Sie auch die Anweisungen insert oder append verwenden. Dabei setzt insert voraus, dass die Tabelle leer ist, d.h. das Ladeprogramm wird abgebrochen, falls dem nicht so ist. Dagegen führt die append-Anweisung immer zum Anfügen der neuen Sätze an die in der Tabelle vorhandenen Daten. Abgebrochene Ladevorgänge können wiederaufgesetzt werden. Hierzu existiert das spezielle Kommando continue_load, dass Sie in dem Fall anstatt des infile-Befehls verwenden müssen. Außerdem können Sie in dem Fall hinter dem insert into-Befehl den Aufsetzpunkt mit Hilfe eines skip-Kommandos festlegen. Ebenfalls besteht die Möglichkeit, mit einer Importdatei mehrere verschiedene Tabellen zu bedienen. In dem Fall müssen Sie zum einen mehrere into table-Befehle vorgeben und dabei mit Hilfe einer when-Klausel eine Bedingung spezifizieren, welche Datensätze in welche Tabelle zu importieren sind.

2.4.5

Wie geht es weiter?

Unsere kleine Personaldatenbank ist zumindest von seiner Struktur her weitestgehend fertiggestellt und die für die verschiedenen Tabellen vorhandenen Beispieldaten haben wir ebenfalls aufgeladen. Damit haben wir eine gute Ausgangsbasis geschaffen, um uns mit Hilfe des nächsten Kapitels verschiedene Abfragemöglichkeiten anzuschauen. Die endgültige Fertigstellung unserer Beispieldatenbank erfolgt, allerdings nur in Ansätzen, erst am Ende des Kapitels „PL/SQL-Programmierungen“. Dort finden Sie zunächst eine systematische Einführung in PL/SQL und im weiteren Verlauf des Kapitels werden wir die noch fehlenden Prüfungen anhand eines exemplarischen Beispiels erstellen bzw. programmieren. Abrechnungsergebnisse Im nächsten Schritt werden wir unsere Datenbank allerdings noch um eine Tabelle mit speziellen Ergebnisdaten erweitern. Diese Tabelle enthält monatliche Abrechnungsergebnisse, die mitarbeiterbezogen mit Hilfe einer Lohnart gespeichert werden. Dabei verzichten wir in unserem Beispiel auf eine zur Lohnart passenden Referenztabelle. Die Tabelle können Sie in Ihrer Datenbank mit Hilfe des folgenden Skripts anlegen, das Sie in der Datei \DATEN\LOHNART.SQL finden. drop table lohnarten; create table lohnarten ( persnr varchar2(11) not null, lfdnr smallint not null, gab date not null, la varchar2(3) not null, satzart varchar(2) default 'DM' not null, betr01 number(9,2) not null, betr02 number(9,2) not null,

248

betr03 betr04 betr05 betr06 betr07 betr08 betr09 betr10 betr11 betr12


number(9,2) number(9,2) number(9,2) number(9,2) number(9,2) number(9,2) number(9,2) number(9,2) number(9,2) number(9,2)

not not not not not not not not not not

null, null, null, null, null, null, null, null, null, null,

constraint satzart_check check (satzart in ('DM','TA','ST','LB')), constraint lohnarten_pk primary key (persnr, lfdnr, gab, la, satzart) ); commit; Listing 2.89: Speichern der Abrechnungsergebnisse

Eine besondere Aufmerksamkeit sollten Sie einmal dem Datenfeld „satzart“, das ebenfalls Teil des Primärschlüssels ist, schenken. Mit Hilfe dieser Satzart wird gesteuert, was in den einzelnen zur Lohnart gehörenden Betragsfeldern genau gespeichert ist. Standardmäßig in der Access-Datenbank sind die zugehörigen Daten in der Tabelle „ORCLADMIN_LOHNARTN“ gespeichert. Ich habe sie ähnlich wie die Gehaltsdaten als variabel lange Datensätze mit Verwendung eines Feldtrennzeichens exportiert, wobei Sie das Ergebnis auf Ihrer CD in der Datei \DATEN\LOHNARTEN.TXT finden. Zum Import verwenden wir wieder das Programm SQL*Loader. Eine für den Import geeignete Steuerdatei finden Sie im gleichen Verzeichnis unter dem Namen LOHNARTEN.CTL, so dass Sie die Tabelle nach dem Anlegen mit Daten füllen können.

3

Abfragen

In diesem Kapitel werden wir uns mit den verschiedenen Möglichkeiten beschäftigen, Abfragen an unsere Datenbank zu senden, d.h. wir beschäftigen uns zum ersten Mal etwas systematischer mit SQL (= Structured Query Language). Dabei werden wir uns im ersten Teil mit Auswahlabfragen beschäftigen. Im Anschluss daran lernen Sie die verschiedenen Änderungsabfragen kennen, was in der Erstellung von selbstprogrammierten Cursors zur Durchführung von Datenänderungen mündet. Das Ganze finden dann seinen Abschluss in einigen Ausführungen und Hinweisen zum Tuning bzw. der Ablaufkontrolle von Abfragen. Im letzten Teil dieses dritten Kapitels werden wir einen Abstecher ins Data Dictionary von Oracle unternehmen und uns dabei anschauen, welche Informationen die verschiednen Systemtabellen und Sichten für uns bereithalten. Dabei geht die von mir praktizierte Vorgehensweise auch in diesem Kapitel wieder davon aus, dass Sie zum einen schon gewisse Grundkenntnisse und Erfahrungen aus anderen Datenbanksystemen haben und zum anderen sich nicht scheuen, bestimmte weitergehende Informationen in der Oracle-Dokumentation nachzuschlagen. Diese finden Sie, indem Sie die hier beschriebenen Befehle in der „Oracle8 SQL-Referenz“ nachschlagen. Daneben befindet sich auch in dem Buch „Oracle8 Concepts“ ein Kapitel „SQL and PL/SQL“ mit einer zusammenhängenden Beschreibung des gesamten Themenkomplexes. Die in diesem Kapitel gezeigten kleineren Abfragebeispiele habe ich Ihnen auf Ihrer Begleit-CD in dem Verzeichnis \ABFRAGEN zusammengestellt. Für jedes größere Kapitel finden Sie hier eine eigene Datei (z.B. ABFRAGE31.SQL), in der ich die ganzen Beispiele aneinandergehängt habe.

3.1

Einfache Auswahlabfragen

Genau wie in allen anderen relationalen Datenbanksystemen erfolgt die Abfrage oder Änderung der gespeicherten Daten mit Hilfe von SQL. Damit sollte die Verwendung dieser Abfragesprache in allen relationalen Datenbanksystemen eigentlich gleich funktionieren, gäbe es da nicht die produktspezifischen Spracherweiterungen bzw. Verfahrensvarianten. Mit anderen Worten: ohne Transact-SQL, PL/SQL oder Jet-SQL wäre die Welt mal wieder übersichtlicher, aber sicherlich nicht einfacher, denn die einzelnen Spracherweiterungen wurden wohl kaum aus einer Bierlaune heraus entworfen, sondern sie entstanden im Laufe der Zeit, um Ihnen das Spektrum der Möglichkeiten zu vergrößern bzw. die Arbeit zu erleichtern; die Alternative, dass alle Hersteller das gleiche Süppchen kochen, dürfte wohl auch hier auf ewig eine Traumvorstellung bleiben.

250

Abfragen

In diesem Abschnitt möchte ich bei der Behandlung der Auswahlabfragen mit einem einfachen Beispiel beginnen und damit die grundsätzliche Struktur einer solchen Abfrage erläutern. Einfach heißt in diesem Fall, dass im Rahmen dieser Abfrage lediglich eine Tabelle gelesen wird. Schwierig, sofern man davon überhaupt reden kann, wird es nämlich frühestens dann, wenn mehrere Tabellen ins Spiel kommen, die dann im Rahmen der Abfrage sinnvoll miteinander verknüpft werden müssen, damit das gewünschte Ergebnis zustande kommt.

3.1.1

Struktur einer Auswahlabfrage

Im Prinzip besitzt eine Auswahlabfrage eine sehr einfache Struktur und besteht in ihrer Grundform aus gerade mal zwei bis vier Abschnitten. select from [where ] [order by <Sortierbedingungen>]

Der erste Abschnitt ist zwingend und wird mit Hilfe des Schlüsselwortes select eingeleitet. Diesem Schlüsselwort folgt eine Liste der gewünschten Datenfelder und Ausdrücke, d.h. im Rahmen einer solchen Auswahlabfrage können nicht nur Tabellenspalten, sondern auch komplexe Berechnungen durchgeführt werden. SQLWKS> select persnr, 2> substr(name,1,20) || ' sysdate;

410

PL/SQL-Programmierung

Hierdurch schleicht sich allerdings eine or-Verknüpfung in unsere Auswahlabfrage ein, was bei umfangreicheren Selektionskriterien entsprechend zu berücksichtigen ist. Die Verwendung der nvl-Funktion bietet einen eleganteren Lösungsansatz und führt zu folgender where-Klausel: where nvl(austrt, sysdate+1) > sysdate

In dem Fall werden nicht gefüllte Austritte einfach durch einen Wert ersetzt, der bei der anschließenden Selektion in der gewünschten Weise berücksichtigt wird.

5.1.5

Ausgabe von Meldungen

Mit Hilfe spezieller Funktionen sind Sie in der Lage, während der Ausführung Ihres PL/SQL-Programms spezielle Meldungen auszugeben, um beispielsweise auf besondere Situationen oder Fehler hinzuweisen. Dabei gibt es zur Ausgabe von Fehlernachrichten spezielle Kommandos, die neben der Meldung auch automatisch dafür sorgen, dass das aktuell laufende Programm abgebrochen wird, wohingegen die ausgegebenen Hinweise gesammelt und erst nach Beendigung des Programms bereitgestellt werden. Oft werden die Hinweismeldungen auch dazu benutzt, um eine gewisse Ablaufverfolgung des Programms durchzuführen. Zwar existieren hierzu auch spezielle Tools, die eventuell im Zusammenspiel mit der Client-Engine mehr Möglichkeiten bieten, jedoch sind solche Tools zum einen nicht immer verfügbar und zum anderen kennt man sich mit deren Umgang vielleicht auch nicht gut genug aus. Hinweise ausgeben Zur Aufbereitung und Ausgabe von Hinweisen bietet Oracle verschiedene Funktionen an, die Ihnen durch das Paket dbms_output bereitgestellt werden. Mit Hilfe dieses Pakets wird ein interner Puffer verwaltet, der am Ende Ihres Programms oder Skripts am Bildschirm ausgegeben werden kann. Das passiert allerdings nur, wenn Sie den Parameter serveroutput auf on gestellt haben, was Sie mit Hilfe der folgenden set-Anweisung durchführen können: set serveroutput on;

Diese Einstellung gilt für die aktive Datenbanksitzung oder solange, bis Sie diese Einstellung wieder auf den Ausgangswert off setzen. Die für die Erstellung von Meldungen wesentlichste Prozedur im dbms_output-Paket heißt put_line und kopiert die als Parameter übergebene Zeichenkette in diesen eben beschriebenen internen Puffer. begin dbms_output.put_line('Hallo, hier bin ich'); end;

Dabei fügt diese Prozedur genauer gesagt eine komplette Zeile in diesen Puffer, d.h. man kann sich diesen internen Puffer wie ein mehrzeiliges Textfeld vorstellen, das mit Hilfe der put_line-Funktion vollgeschrieben wird und wobei jede dieser Zeile

Einführung in PL/SQL

411

maximal 255 Zeichen lang ist. Dieses Textfeld bzw. der gesamte Puffer ist im Übrigen standardmäßig 2000 Byte groß und kann bei Bedarf mit Hilfe der Paket-Prozedur dbms_output.enable vergrößert werden. begin dbms_output.enable(20000); end;

Außerdem wird die Pufferung der erzeugten Hinweise hierdurch erneut eingeschaltet, sofern Sie dieses Verfahren zuvor durch Anwenden der dbms_output.disable-Prozedur abgeschaltet haben. Ein solches Abschalten hat allerdings auch zur Konsequenz, dass die bisher gepufferten Daten dabei verloren gehen, da der interne Puffer hierbei gelöscht wird. Soll keine ganze Zeile, sondern nur ein einzelner Text bzw. ein einzelnes Feld in den Ausgabepuffer kopiert werden, dann können Sie hierzu die put-Prozedur des Pakets verwenden und einen Zeilenwechsel vielleicht irgendwann durch das Aufrufen der new_line-Prozedur veranlassen. Das folgende Beispiel entspricht also der soeben durchgeführten Textausgabe, wobei die Ausgabe diesmal in zwei Schritten erfolgt und durch einen manuellen Zeilenwechsel abgeschlossen wird. Begin dbms_output.put('Hallo, '); dbms_output.put('hier bin ich'); dbms_output.new_line; end;

Das ist auch schon fast alles, was in dem dbms_output-Paket enthalten ist. Der Vollständigkeit halber möchte ich noch erwähnen, dass Sie in dem Paket neben den eben beschriebenen Prozeduren noch die beiden Objekte get_line und get_lines finden, mit denen Sie die in den Puffer geschriebenen Daten wieder auslesen können. Die Verwendung dieser beiden Prozeduren ist übrigens im Kopf des Pakets beschrieben, d.h. sofern Sie die beiden wirklich einmal verwenden müssen, dann finden Sie dort weiterhelfende Informationen. Ansonsten finden Sie eine Beschreibung des gesamten Pakets auch im Kapitel 12 des Buchs „Oracle8 Application Developer's Guide“ bzw. schlagen Sie im dortigen Index einfach „dbms_output“ nach, um die entsprechenden Textstellen zu finden. Meistens wird das dbms_output-Paket dazu verwendet, den Ablauf eines PL/SQLProgramms zu kontrollieren oder während der Ausführung den Wert bestimmter Variablen zu protokollieren. Dabei kann das Paket in allen PL/SQL-Objekten, also auch in Triggern, angewendet werden. Wenn Sie hierbei anschließend eine Transaktion auf die Tabelle ausführen, für die ein Trigger mit Hinweismeldungen angelegt wurde, dann erhalten Sie die erstellten Hinweise nach der Durchführung der Transaktion auf dem Bildschirm. Fehlermeldungen generieren Wenn Sie während der Programmausführung eine Fehlermeldung und einen damit verbundenen Programmabbruch erzeugen möchten, dann können Sie dies mit

412


Hilfe der Prozedur raise_application_error erreichen. Diese Prozedur ist übrigens Bestandteil des Pakets dbms_standard, weshalb sie ohne Nennung des Paketnamens verwendet werden kann. Die Prozedur erhält üblicherweise zwei bis drei Parameter. Mit Hilfe des ersten Parameters müssen Sie eine Fehlernummer vorgeben, wobei hierfür der Nummernkreis von –20000 bis –20999 für anwendungsspezifische Fehler reserviert wurde. Der zweite Parameter enthält die bis zu 2048 Zeichen lange Fehlermeldung. Der dritte Parameter wird standardmäßig mit dem Wert false (falsch) vorbelegt und führt dazu, dass nur die von Ihnen ausgegebene Fehlernachricht ausgegeben wird. Verwenden Sie stattdessen den Wert true (wahr), dann werden auch eventuell vorhergehende Fehler angezeigt, was bei der Programmierung einer Fehlerbehandlungsroutine interessant sein kann. In diesem Workshop finden Sie bei der Beschreibung solcher Fehlerbehandlungsroutinen auch noch weitergehende Informationen zu raise_application_error. Das nun folgende kleine Beispiel (vgl. Listing 5.8) zeigt Ihnen die Anwendung der raise_application_error-Routine mitsamt den Ausgaben, die hierbei am Bildschirm des SQL-Editors erscheinen. Mit Hilfe des dbms_out-Pakets dokumentieren wir dabei, dass unser Programm nach Ausgabe der Meldung wirklich abbricht, denn die kurz vor Programmende erzeugte Hinweismeldung wird nicht ausgegeben. Begin dbms_output.put_line('Anfang'); raise_application_error(-20000,'Keine Lust zum Arbeiten'); dbms_output.put_line('Ende'); end; ORA-20000: Keine Lust zum Arbeiten ORA-06512: at line 3 Anfang Listing 5.8: Verwenden von raise_application_error

5.1.6

Konditionalbedingungen

Nur selten läuft ein Programm geradlinig von oben nach unten bzw. von seinem Anfang bis zu seinem Ende durch. In der Regel sind bestimmte Programmbefehle an besondere Bedingungen gebunden, so dass zur Laufzeit entschieden wird, ob spezielle Befehle oder vielleicht sogar Unterprogramme aufgerufen werden oder nicht. Die Programmierung solcher Bedingungen erfolgt in PL/SQL genau wie in den meisten anderen Programmiersprachen mit Hilfe der if-Anweisung, dabei entspricht die einfache Form dieser Anweisung dem folgenden Schema: if then [else ] end if;


413

Ist die hinter dem if-Befehl spezifizierte Bedingung erfüllt, so werden die hinter dem Schlüsselwort then kodierten Anweisungen ausgeführt und anschließend wird die Programmausführung mit den Anweisungen fortgesetzt, die der end if-Anweisung folgen. Ist die Bedingung nicht erfüllt, dann verzweigt das Programm zu den Anweisungen, die der else-Klausel folgen, sofern solche Anweisungen überhaupt vorhanden sind, denn die Kodierung eines else-Zweigs ist optional. Wie Sie dem Schema allerdings richtig entnehmen können, ist die Vorgabe der then-Anweisungen im Unterschied zu einigen anderen Programmiersprachen allerdings nicht wahlfrei. Das erkennt man im Übrigen schon daran, dass hinter dem then genau wie hinter dem else kein Semikolon steht, d.h. sowohl if als auch else alleine bilden keine vollständige Anweisung, denn diese werden ja bekanntlich mit einem Semikolon beendet. Ansonsten gibt es allerdings kaum besondere Restriktionen. Die if-Anweisungen können im Programm beispielsweise beliebig geschachtelt werden. Das geht prinzipiell so lange, bis Sie die Übersicht verlieren, d.h. hier bilden wir und nicht das System die Grenzen des Möglichen. Formal müssen Sie dabei nur beachten, dass jedem if irgendwann einmal das zugehörige end if folgen muss. Was die mit der if-Anweisung verbundene Ausführungsbedingung angeht, so gilt hier im Prinzip das Gleiche, was Sie schon bei den Abfragen bei der Beschreibung der where-Klausel gelesen haben bzw. dort nachlesen können. So eine Bedingung besteht also wieder aus einem oder mehreren Ausdrücken, die jeweils mit Hilfe der verfügbaren Vergleichsoperatoren (vgl. Kapitel 3.1.2) verglichen und wo mehrere solcher Vergleichsbedingungen mit Hilfe der vorhandenen Verknüpfungsoperatoren (vgl. Tabelle 3.1) verbunden werden. if a > b then; dbms_output.put_line('then-Zweig'); else dbms_output.put_line('else-Zweig'); if b > c then dbms_output.put_line('then-2-Zweig'); end if; end if;

Oft hat man beim Programmdesign das Problem, dass der else-Teil einer if-Bedingung nicht unbedingt immer ausgeführt werden soll, sondern selbst wiederum von einer weiteren, also geschachtelten Unterbedingung abhängig ist. Für solche Fälle hat sich in den letzten Jahren in vielen Programmiersprachen eine besondere Unterform der if-Abfrage entwickelt, die dem folgenden Schema entspricht: if then elsif then elsif then [else

414


] end if;

Ist die erste if-Bedingung nicht erfüllt, dann wird die nächstfolgende elsif-Bedingung untersucht, der ggf. die dritte und vierte usw. Bedingung folgt. Wenn keine der vorhandenen Bedingungen erfülltl ist und damit zur Ausführung der zugehörigen Anweisungen führt, dann kommen die im else-Zweig kodierten Programmschritte zur ausführen, was natürlich nur geht, wenn eine solcher Zweig überhaupt vorhanden ist. Sprungmarken Zusammen mit den if-Anweisungen kommen zumindest mir immer noch sofort die Sprungmarken in den Sinn, was nicht daran liegt, dass ich sie so oft verwende, sondern früher, so vor ungefähr 60 Jahren, da bildeten if-Befehl und Sprungbefehl irgendwie eine Einheit, was heutzutage wegen der vielen anderen und mächtigen Konstruktionsmöglichkeiten sicherlich nicht mehr gilt. Dennoch gibt es den Befehl immer noch in nahezu allen Programmiersprachen und diejenigen Sprachen, die von sich behaupten, dass sie frei von Sprüngen wären, haben das nur dadurch erreicht, indem sie spezielle Sprungbefehle einfach verschleiern, denn ein exit ist im Prinzip auch nichts anderes als der Sprung zu einer vordefinierten Marke hinter der zugehörigen Schleife. Doch lassen wir diesen Glaubenskrieg links liegen und wenden uns wieder dem eigentlichen Thema zu. In Ihren PL/SQL-Programmen haben Sie die Möglichkeit, Sprungmarken zu setzen. Eine solche Sprungmarke besteht im Prinzip aus einem beliebigen Wort, einer Art Überschrift, mit der die zugehörige Programmstelle gekennzeichnet wird. Eine solche Sprungmarke wird in PL/SQL von doppelten Kleiner- und Größerzeichen eingeschlossen und besteht ansonsten im Regelfall nur aus Buchstaben und Ziffern. >

Wenn Sie außerdem noch andere besondere Zeichen (Minus, Leerzeichen usw.) innerhalb einer Sprungmarke verwenden wollen, dann müssen Sie diese insgesamt mit doppelten Anführungszeichen einschließen.

Eine solche Sprungmarke können Sie in Ihrem Programm mit Hilfe der goto-Anweisung ansteuern, indem Sie den Befehl zusammen mit der gewünschten Sprungmarke verwenden. Hierbei müssen Sie allerdings folgende Einschränkungen beachten: 1. Sie dürfen nicht in eine if-then-else-Anweisung hineinspringen, was im Übrigen auch für Sprünge zwischen den einzelnen Zweigen gilt, denn die sind ebenfalls verboten. 2. Sie dürfen nicht in tieferliegende Programmblöcke springen. 3. Sie dürfen eine Prozedur oder Funktion nicht per goto-Anweisung verlassen. 4. Sie dürfen aus einer Fehlerbehandlungsroutine nicht in den zugehörigen Block zurückspringen.


415

Ich weiß nicht, wie es Ihnen geht, aber ich empfinde keine der vier genannten Einschränkungen in irgendeiner Weise restriktiv. Wie schon gesagt, benötigt man den Befehl in der heutigen Zeit aufgrund der vielen anderen Möglichkeiten sowieso nur noch sehr sehr selten. Trotzdem habe ich Ihnen im Beispiel 5.9 eines meiner Lieblingsbeispiele serviert, indem Sie die „sinnvolle“ Anwendung des gotoBefehls demonstriert bekommen. begin goto anfang; dbms_output.put_line('Schritt-4'); goto ende; dbms_output.put_line('Schritt-3'); goto "schritt-4"; dbms_output.put_line('Schritt-2'); goto "schritt-3"; dbms_output.put_line('Anfang'); goto "schritt-2"; > dbms_output.put_line('Ende'); end; Statement processed. Anfang Schritt-2 Schritt-3 Schritt-4 Ende Listing 5.9: Anwendung des goto-Befehls

5.1.7

Schleifen

Wie schon bei der Einleitung zu den Konditionalbedingungen gesagt, läuft ein Programm nur selten sequentiell vom Start zum Programmende, sondern manche Programmteile werden nur unter bestimmten Bedingungen ausgeführt, wohingegen andere Teile häufiger wiederholt werden müssen. Solche Wiederholungen bzw. Schleifen können auch in PL/SQL mit Hilfe entsprechender Anweisungen programmiert werden.

416


Je nach verwendeter Programmiersprache gibt es immer verschiedene Varianten, um diese Schleifen zu programmieren. Unter PL/SQL stehen Ihnen die im Folgenden beschriebenen Schleifen-Konstruktionen zur Verfügung, wobei Sie ein kleines Anwendungsbeispiel ganz am Ende des Kapitels im Listing 5.10 finden:

X

while loop-Schleife Bei der while loop-Schleife werden die in der Schleife programmierten Anweisung so lange ausgeführt, wie die hinter der while-Anweisung kodierte Bedingung erfüllt ist. Ist diese Bedingung schon beim Erreichen der Schleife nicht mehr erfüllt, dann wird die Schleife folglich gar nicht durchlaufen. Die Programmierung einer while loop-Schleife entspricht dem folgenden Schema: while loop end loop;

X

loop-Schleife Bei der loop-Schleife handelt es sich um eine Sonderform der soeben beschriebenen while loop-Schleife. Wie Sie schon an der Begriffsführung erkennen können, fehlt hierbei die while-Klausel und damit die Abbruchbedingung der Schleife, d.h. loop-Schleifen laufen zunächst einmal endlos lange. Damit das in der Praxis dann doch nicht passiert, denn Endlosschleifen gelten nach neusten wissenschaftlichen Erkenntnissen als Fehler, gibt es die exit-Anweisung, mit der Sie die Schleife verlassen können, so dass die Verwendung der loop-Schleife nach etwa folgendem Schema erfolgt: loop if then exit; end if; end loop;

X

for loop-Schleife Bei der for loop-Schleife, die manchmal auch einfach Zählschleife genannt wird, legen Sie von vornherein explizit fest, wie oft die Schleife durchlaufen wird, indem eine Laufvariable entsprechend eines vorgegebenen Intervalls variiert wird, bis die hintere Intervallgrenze erreicht wird. Die Verwendung einer for loopSchleife sieht in etwa folgendermaßen aus: for in [reverse] loop end loop;

Normalerweise wird das vorgegebene Intervall in aufsteigender Reihenfolge durchlaufen, d.h. die Laufvariable nimmt mit jedem Schleifendurchlauf den nächsten Wert des Intervalls an.


417

exit-Anweisung Zum vorzeitigen Verlassen einer Schleife existiert in PL/SQL die exit-Anweisung. Es dürfte nur wenig Anforderungen geben die dazu führen, dass der exit-Befehl direkt verwendet wird, d.h. in aller Regel wird er innerhalb einer if-Anweisung verwendet, mit der die besondere Ausstiegsbedingung für die Schleife festgelegt wird. Aus diesem Grund gibt es für die exit-Anweisung auch eine weitere Variante, in der Sie die Abbruchbedingung mit Hilfe des Schlüsselwortes when direkt zusammen mit dem exit-Befehl Programmieren können. exit when

Schleifen benennen In bestimmten Ausnahmesituationen kann es sinnvoll sein, den einzelnen Schleifen eine Markierung in Form einer gewöhnlichen Sprungmarke zu geben, die direkt vor dem Anfang der Schleife gesetzt werden muss. Optional können Sie den verwendeten Sprungnamen auch noch einmal an das Ende der Schleife direkt hinter der end loop-Anweisung stellen: > loop ... end loop Schleife1;

Aus meiner Sicht sind solche Benennungen nur in bestimmten Ausnahmesituationen sinnvoll, denn hierdurch haben Sie bei geschachtelten Schleifen die Möglichkeit, mit Hilfe einer weiteren exit-Variante gezielt aus mehreren Schleifen herauszuspringen. Das folgende Beispiel demonstriert diese Möglichkeit, indem mit Hilfe der exit-Anweisung als allen Schleifen herausgesprungen wird: > loop loop exit schleife1 when … end loop; end loop;

Anwendungsbeispiel declare i integer := 0; j integer := 0; k integer := 0; begin dbms_output.enable(50000); loop i:=i+1;

418


j:= 1; while j < 10 loop for k in reverse 1..10 loop dbms_output.put('Schleife=> '); dbms_output.put(to_char(i, '99.')); dbms_output.put(to_char(j, '99.')); dbms_output.put(to_char(k, '99')); dbms_output.new_line; end loop; j:=j+1; end loop; exit when i=10; end loop; end; Listing 5.10: Anwendungsbeispiel zur Schleifenverwendung

5.1.8

Datenbankabfragen

Innerhalb eines PL/SQL-Programms können Sie zu jedem beliebigen Zeitpunkt irgendwelche Datenbankaktionen ausführen. Dabei können Sie beispielsweise innerhalb der where-Bedingung auf alle verfügbaren Variablen Bezug nehmen, so dass auf diese Weise dynamische SQL-Kommandos entstehen: update personalien set name = xname where persnr = xpnr;

In diesem Beispiel wird der Name für einen speziellen Mitarbeiter geändert, wobei der neue Name bzw. die zu ändernde Personalnummer erst zur Laufzeit durch die Werte in den Variablen xname bzw. xpnr feststehen. Wesentlich interessanter als die Beschreibung solcher parametrisierten Änderungsabfragen ist jedoch die Fragestellung, wie innerhalb eines PL/SQL-Programms irgendwelche Tabellen der Datenbank gelesen werden können. Die einfachste Variante, bestimmte Felder aus der Datenbank in einem PL/SQL-Programm zu lesen besteht darin, eine gewöhnliche Auswahlabfrage zu kodieren, und die selektierten Felder mit Hilfe der into-Klausel in entsprechende Variablen oder eine geeignete Struktur zu kopieren. declare xpersnr personalien.persnr%type; xname personalien.name%type; begin select persnr, name into xpersnr, xname


419

from personalien where persnr = '7000188'; dbms_output.put_line(xname); end;

Allerdings führt diese Abfragetechnik zu einem Laufzeitfehler, wenn die eingesetzte Abfrage nicht genau einen Datensatz zurückliefert. Positiv ausgedrückt gibt es also Probleme, wenn Ihre Abfrage keinen oder mehrere Datensätze liefert. Für dieses Problem gibt es genau genommen drei verschiedene Lösungsansätze: 1. Sie verwenden anstelle einer solchen Abfrage einen Cursor. Das ist natürlich wesentlich aufwändiger, denn wie Sie schon gesehen haben bzw. gleich noch einmal sehen werden, müssen Sie den Cursor nicht nur definieren, sondern auch mit Hilfe spezieller Befehle verarbeiten. Dafür ist die ganze Anwendung dann allerdings fehlertolerant, denn sofern der Cursor keinen Datensatz liefert erkennen Sie das mit Hilfe der entsprechenden Statusanzeige %notfound und ansonsten wird der Cursor nach dem Lesen des ersten Satzes wieder geschlossen, so dass auch die Anlieferung mehrerer Datensätze kein Problem mehr darstellt. 2. Die zweite Möglichkeit besteht darin, die Abfrage in einem speziellen Block zu kapseln und den Block mit einer geeigneten Fehlerbehandlungsroutine auszustatten. Natürlich führt auch das zu einem gewissen Mehraufwand in Form entsprechender Programmlogik, so dass auch diese Lösung eigentlich nicht so recht überzeugen kann. 3. Die einfachste Variante zur Lösung des Problems besteht in der Anwendung eines kleinen Tricks. Wie Sie sich vielleicht erinnern, hatte die Verwendung von Aggregatfunktionen in einer Abfrage die Nebenwirkung, dass die Abfrage hierdurch immer Ergebnisse zurückliefert. Wenn wir die benötigten Spalten also mit Hilfe der max-Funktion abfragen, dann ist sichergestellt, dass wir immer genau einen Wert erhalten und wenn die Abfrage gar keinen Datensatz selektiert, dann erhalten wir aufgrund der max-Funktion immerhin noch den Wert null. Die dritte Variante, scheint auf den ersten Blick die einfachste Lösung zu bieten, was sich bestätigt, wenn man sich das geänderte Programm einmal anschaut: declare xpersnr personalien.persnr%type; xname personalien.name%type; begin select max(persnr), max(name) into xpersnr, xname from personalien where persnr = '7000188'; dbms_output.put_line(xname); end;

420


Verwenden von Cursorn Sofern Sie in Ihrem Programm nicht nur einen einzelnen Datensatz benötigen, sondern die aus einer Abfrage resultierenden Datenmenge verarbeiten müssen, dann ist es notwendig hierfür einen entsprechenden Cursor zu definieren. In diesem Workshop (vgl. Kapitel 3.3.5) haben Sie schon den Cursor als Instrument zum Durcharbeiten einer Datenmenge kennen gelernt. Im Prinzip handelt es sich bei einem solchen Cursor um ein Objekt, das es Ihnen ermöglicht in einem Programm eine spezielle Abfrage auszuführen und die zugehörigen Datensatz im Rahmen einer Schleife einzeln zu empfangen bzw. zu verarbeiten. Hierzu müssen Sie den Cursor im Deklarationsteil des Programms bzw. des zugehörigen Blocks zunächst einmal definieren. Hierbei wird neben dem Namen des Cursors auch die damit verbundene Abfrage festgelegt. Das folgende Beispiel erzeugt den Cursor read_pers, mit dem zwei Felder der Tabelle personalien gelesen werden. declare cursor read_pers is select persnr, name from personalien order by name;

Innerhalb des Programms können Sie den Cursor bei Bedarf öffnen, so dass die damit verbundene Abfrage ausgeführt wird. Anschließend haben Sie die Möglichkeit, die einzelnen Datensätze der Reihe nach abzufordern. Wird der Cursor nicht mehr benötigt, bzw. wurden alle Datensätze gelesen, dann sollte er innerhalb des Programms wieder geschlossen werden, was auch zu einer Freigabe der an den Cursor gebundenen Ressourcen führt. Dabei erfolgt das Öffnen eines Cursors erfolgt mit Hilfe der open-Anweisung. Für das Abrufen der einzelnen Datensätze existiert die Anweisung fetch und geschlossen wird der Cursor mit Hilfe eines close-Befehls. In dem folgenden Beispiel 5.11 finden Sie ein kleines Beispiel für die Verwendung eines Cursors, indem die Personalien der Reihe nach gelesen und die jeweiligen Namen ausgegeben werden. declare cursor read_pers is select persnr, name from personalien; xpersnr personalien.persnr%type; xname personalien.name%type not null := ' '; begin open read_pers; loop fetch read_pers into xpersnr, xname; exit when read_pers%notfound; dbms_output.put_line(xname); end loop; end; Listing 5.11: Datensätze mit Hilfe eines Cursors verarbeiten


421

Wie Sie an dem Beispiel 5.11 sehen können, erfolgt die Verarbeitung der selektierten Datensätze mit Hilfe einer loop-Schleife. Damit diese Endlosschleife nicht bis zum jüngsten Tag läuft, programmieren wir mit Hilfe der exit-Anweisung eine geeignete Abbruchbedingung, indem wir die Statusvariable notfound des Cursors abfragen. Diese enthält nämlich genau dann den Wert true, wenn der vorherige fetch-Befehl wegen des erreichten Cursorendes keinen Datensatz mehr geliefert hat. Insgesamt stehen Ihnen bei einem Cursor die in der Tabelle 5.11 gezeigten Statusvariablen zur Verfügung. Statusvariable

Beschreibung

%found

ist true, wenn der vorherige fetch einen Datensatz geliefert hat.

%isopen

enthält den Wert true, wenn der Cursor geöffnet wurde.

%notfound

entspricht „not %found“ und ist damit nur dann wahr, wenn der vorherige fetch-Versuch nicht erfolgreich war.

%rowcount

zählt alle gelesenen Datensätze, d.h. der Wert dieser Statusvariablen erhöht sich mit jedem fetch-Befehl.

Tabelle 5.11: Beschreibung der Statusvariablen eines Cursors

for-Schleifen für Cursor Zum Abarbeiten der vom Cursor gelieferten Datensätze existiert im PL/SQL-Sprachumfang eine spezielle Variante der for-Schleife, mit der Sie die gelieferten Datensatz vollständig durchlaufen können. Dabei führt diese spezielle Schleife auch implizit die open- und close-Befehle für den Cursor aus, so dass sich unser letzten Beispiel noch einmal deutlich verkürzen lässt (vgl. Listing 5.12). declare cursor read_pers is select persnr, name from personalien; begin for xrec in read_pers loop dbms_output.put_line(xrec.name); end loop; end; Listing 5.12: Anwenden eines Cursors zusammen mit der speziellen for-Schleife

Wenn Sie dieses Beispiel mit der vorhergehenden Definition der for loop-Schleife vergleichen, dann werden Sie vor allem folgende Unterschiede erkennen:

X

X

Anstelle des vorgegebenen Schleifenintervalls tritt jetzt einfach der Name des Cursors, d.h. das Intervall heißt ganz einfach vom ersten bis zum letzten Datensatz. Die Laufvariable der Schleife, die ich in unserem Beispiel xrec genannt habe, wird vom Programm automatisch angelegt. Hierbei handelt es sich um eine Struktur, die Sie auch manuell folgendermaßen definieren könnten:

422


xrec read_pers%rowtype;

Um das noch einmal deutlich zu sagen: Die for-Schleife verwendet beim Cursor immer eine Laufvariable, die einer Struktur entspricht und die bei Bedarf automatisch angelegt wird. Letzteres können Sie aber auch durch eine eigene Deklaration vorwegnehmen. Ansonsten müssen Sie bei dieser Art der Verarbeitung eigentlich nur noch beachten, dass der Cursor beim Einstieg in die Schleife nicht geöffnet sein darf, da das ansonsten zu einem Laufzeitfehler führt. Parameter in Cursorn verwenden Die bisher in unserem Cursor verwendete Abfrage war stets statisch und besaß keine laufzeitabhängige Komponente. Eine solche können Sie natürlich ähnlich wie bei der zuvor gezeigten einfachen Abfrage erzeugen, indem Sie innerhalb der Abfrage einfach andere Variablen verwenden. declare xpersnr personalien.persnr%type; cursor read_pers is select name from personalien where persnr = xpersnr;

Wird dieser Cursor während der Programmausführung geöffnet, dann richtet sich das Abfrageergebnis nach dem aktuellen Wert der Variablen xpersnr. So weit so gut, und trotzdem hat das soeben beschriebene Verfahren entscheidende Nachteile. Zum einen müssen die beim Cursor verwendeten Variablen alle vorab definiert werden, d.h. schon im Deklarationsteil Ihres Programms entstehen nicht immer angenehme Abhängigkeiten. Zum anderen verdient dieses Verfahren auch nicht gerade einen Übersichtspreis. Wird der Cursor beispielsweise einige hundert Zeilen später verwendet, dann ist nirgendwo ersichtlich, ob und mit welchen Parametern die zugehörige Abfrage ausgeführt wird. Besser wäre es, die benötigten Variablen beim Starten des Cursors als sichtbare Parameter zu übergeben, wozu es in PL/SQL ein entsprechendes Verfahren (vgl. Listing 5.13) gibt. declare cursor read_pers(xpersnr varchar2) is select name from personalien where persnr = xpersnr; begin for xrec in read_pers('7000188') loop dbms_output.put_line(xrec.name); end loop; end; Listing 5.13: Parameterübergabe an einen Cursor


423

Ich finde, dass der ganze Aufbau jetzt stark an eine Funktion erinnert. Bei der Definition des Cursors werden alle benötigten Variablen zusammen mit ihrem Datentyp hinter dem Cursornamen in Klammern aufgelistet und beim Starten bzw. Öffnen des Cursors werden dann alle konkreten Werte wie bei einem Funktionsaufruf in der entsprechenden Reihenfolge übergeben. Dynamisches SQL Die zuletzt verwendeten Abfragen waren zum Schluss zwar alle in einem gewissen Umfang variabel, doch verdient keine der bisherigen Beispiele die Bezeichnung „dynamisches SQL“. Hierunter versteht man im Allgemeinen etwas ganz anderes, nämlich die Möglichkeit die gesamte SQL-Abfrage erst zur Laufzeit zusammenzubauen und anschließend auszuführen. Nehmen wir als Aufgabenstellung einmal an, wir möchten von Zeit zu Zeit alle Indices unseres Schemas reorganisieren. Grundsätzlich ist so eine Indexreorganisation mit Hilfe einer Anweisung gemäß dem folgenden Schema möglich: alter index rebuild;

Außerdem erhalten Sie alle im Schema enthaltenen Indices durch eine Abfrage der View user_indexes, doch wie kann man diese Informationen zusammen mit der jeweils entsprechenden alter index-Anweisung dynamisch kombinieren. Wenn man es nicht besser weiß, dann kann man sich natürlich mit Hilfe einer entsprechenden Anweisung die zur Reorganisation benötigten Statements erzeugen und das hierdurch ausgegebene Skript in einem zweiten Schritt ausführen. select 'alter index ' || index_name || ' rebuild;' from user_indexes

Da PL/SQL Ihnen aber die Möglichkeit bietet, zur Laufzeit generierte SQL-Kommandos auszuführen, können wir diese beiden Schritte auch in einem verschmelzen und uns hierfür ein entsprechendes Skript basteln. Die Basis für die Verwendung dynamischer SQL-Abfragen finden Sie im Paket dbms_sql, das in der Oracle-Dokumentation wieder im Buch „Oracle8 Application Developer's Guide“ beschrieben ist. Wenn wir zunächst einmal von Auswahlabfragen absehen, dann folgt die Verwendung dynamischer SQL-Statements dem folgenden Schema:

X X X X

Öffnen eines Ausführungskanals mit Hilfe der Funktion open_cursor. Prüfen des auszuführenden Statements mit Hilfe der Prozedur parse. Beachten Sie, dass DDL-Statements hierbei auch sofort ausgeführt werden. Auf der anderen Seite schadet es aber auch nicht, wenn Sie jedes Mal eine execute-Funktion verwenden, da das geparste DDL-Statement nicht noch einmal ausgeführt wird. Ausführen der Abfrage durch einen Aufruf der execute-Funktion. Schließen des Ausführungskanals durch einen Aufruf der Prozedur close_cursor.

424


Die vollständige Lösung der oben beschriebenen Aufgabe finden Sie im Listing 5.14. Zunächst einmal definieren wir in diesem Programm den Cursor meine_indexe entsprechend der eben dargestellten Abfrage auf die View user_indexes. Des weiteren benötigen wir im Programm noch zwei weitere Integervariablen sql_id und ret. Zentralstelle des Programms ist die for loop-Schleife, in der alle vom Cursor gelieferten Indexnamen der Reihe nach geliefert und mit Hilfe der Variablen mi_rec. index_name zur Verfügung gestellt werden. declare cursor meine_indexe is select index_name from user_indexes; sql_id integer; ret integer; begin sql_id := dbms_sql.open_cursor; for mi_rec in meine_indexe loop dbms_sql.parse(sql_id, 'alter index ' || mi_rec.index_name || ' rebuild', dbms_sql.native); -- wegen des DDL-Befehls ist ein execute -- nicht unbedingt notwendig -- ret := dbms_sql.execute(sql_id); end loop; dbms_sql.close_cursor(sql_id); end; Listing 5.14: Reorganisation aller Indices mit Hilfe dynamischer SQL-Anweisungen

Vor dem Einstieg in die Schleife eröffnen wir einen dynamischen SQL-Cursor, indem wir die Funktion open_cursor aufrufen. sql_id := dbms_sql.open_cursor;

Den von dieser Funktion zurückgegebenen Wert speichern wir in einer Variablen, da er für alle weiteren dynamischen Aktivitäten benötigt wird. Innerhalb der Schleife wird das auszuführende Statement zunächst geprüft, indem es der parseProzedur übergeben wird, was prinzipiell nach folgendem Schema geschieht: dbms_sql.parse(, <Statement>, <Spracheinstellung>)

Wie Sie sehen, benötigt diese Prozedur insgesamt drei Parameter. Der erste dieser drei Parameter spezifiziert dabei den zuvor geöffneten Cursor, d.h. hier müssen Sie den von der open_cursor-Funktion gelieferten Wert übergeben. Der zweite Parame-


425

ter enthält die auszuführende Abfrage und mit dem letzten Parameter legen Sie die bei der Prüfung zu verwendende PL/SQL-Sprachversion fest. Hierzu existieren im dbms_sql-Paket drei vordefinierte Werte, die Sie der Tabelle 5.12 entnehmen können. Konstante

Wert

Bedeutung

V6

0

Interpretation des Statements entsprechend der Version 6.

V7

2

Verwenden der Version 7.

Native

1

Aktuelle Version zur Statementanalyse benutzen.

Tabelle 5.12: Sprachoptionen der dbms_sql.parse

Nach der erfolgreichen Analyse des auszuführenden Statements kann dieses mit Hilfe der execute-Funktion ausgeführt werden, die hierzu lediglich die Kennung des zugehörigen Cursors benötigt. Der von dieser Funktion zurückgegebene Wert enthält bei Änderungsabfragen die Anzahl der von der Abfrage betroffenen Datensätze und bei Auswahlabfragen ist dieser Wert ohne Bedeutung. ret := dbms_sql.execute(sql_id);

Zum Schluss müssen Sie den Cursor wieder schließen, was diesmal mit Hilfe der close_cursor-Prozedur passiert, der Sie zu diesem Zwecke wieder die entsprechende Cursorkennung übergeben müssen. dbms_sql.close_cursor(sql_id);

Wie Sie an dem letzten Beispiel gesehen haben, war es gar nicht so schwer, mit Hilfe des dbms_sql-Pakets ein intelligentes Skript zu erstellen, das bestimmte Wartungsarbeiten durchführt. Solche und ähnliche Arbeiten lassen sich in der Praxis wirklich prima mit Hilfe dynamischer SQL-Statements erledigen, weshalb Routinen in der eben beschriebenen Form häufig anzutreffen sind. Allerdings ist der Leistungsumfang des dbms_sql-Pakets noch wesentlich größer, denn neben dem Ausführen von DDL- oder DML-Anweisungen lassen sich auch Auswahlabfragen dynamisch erzeugen und ausführen. Dynamische Auswahlabfragen erstellen Wie Sie gleich sehen werden, ist die Erstellung dynamischer Auswahlabfragen ein ganz schönes Stück Tipparbeit. Mit Hilfe einer dynamischen Auswahlabfrage wollen wir verschiedene Felder aus den Personalien und den zugehörigen Gehältern aus der Datenbank lesen und diese am Bildschirm ausgeben. Die dabei verwendete Abfrage beinhaltet also eine Verknüpfung zwischen den Tabellen personalien und gehalt, wobei die Gehaltsdaten zusätzlich auf den aktuellsten Datensatz eingeschränkt werden sollen. Wir haben es in unserem Beispiel konkret also mit folgender Abfrage zu tun: select a.persnr, a.name, a.gebdatum, b.gehalt from personalien a, gehalt b where b.persnr = a.persnr and b.gab = (select max(gab)

426


from gehalt b1 where b1.persnr = b.persnr ) order by a.name

Das komplette Programm finden Sie im Listing 5.15, das wir im Anschluss mal wieder Stück für Stück auseinandernehmen werden und selbst wenn Sie dynamische Auswahlabfragen in der Regel nur sehr selten benötigen, so ist das Beispiel doch wenigstens dazu geeignet aufzuzeigen, wie einfach doch die Verwendung eines deklarierten Cursors ist. declare dyn_sql integer; sql_st varchar2(500); rc integer; xpersnr xname xgeburt xgehalt

varchar2(10); varchar2(30); date; number;

begin dbms_output.enable(50000); dyn_sql := dbms_sql.open_cursor; sql_st := 'select a.persnr, a.name, a.gebdatum, b.gehalt from personalien a, gehalt b where b.persnr = a.persnr and b.gab = (select max(gab) from gehalt b1 where b1.persnr = b.persnr ) order by a.name'; dbms_sql.parse(dyn_sql, sql_st, dbms_sql.native); dbms_sql.define_column(dyn_sql, dbms_sql.define_column(dyn_sql, dbms_sql.define_column(dyn_sql, dbms_sql.define_column(dyn_sql,

1, 2, 3, 4,

xpersnr, 10); xname, 30); xgeburt); xgehalt);

rc := dbms_sql.execute_and_fetch(dyn_sql); while rc > 0 loop dbms_sql.column_value(dyn_sql, 1, xpersnr); dbms_sql.column_value(dyn_sql, 2, xname); dbms_sql.column_value(dyn_sql, 3, xgeburt); dbms_sql.column_value(dyn_sql, 4, xgehalt);


427

dbms_output.put(rpad(xpersnr,10,' ') || ' '); dbms_output.put(rpad(xname,30,' ') || ' '); dbms_output.put(to_char(xgeburt, 'DD.MM.YYYY') || ' '); dbms_output.put(to_char(xgehalt,'999990.00' )); dbms_output.new_line; rc := dbms_sql.fetch_rows(dyn_sql); end loop; dbms_output.put_line('Anzahl Sätze: ' || to_char(dbms_sql.last_row_count,'9999')); dbms_sql.close_cursor(dyn_sql); end; Listing 5.15: Beispiel einer dynamischen Auswahlabfrage

Eigentlich beginnt alles genau wie bei den dynamischen Änderungsabfragen, d.h. zunächst erzeugen wir uns wieder einen dynamischen Cursor, dessen Kennung wir in der Variablen dyn_sql speichern. Die auszuführende Abfrage konstruieren wir in der Variablen sql_st und übergeben sie anschließend der Prozedur parse zur Überprüfung und Würdigung. Erst was danach kommt ist im Vergleich zum vorhergehenden Beispiel wirklich neu. dbms_sql.define_column(dyn_sql, 1, xpersnr, 10); dbms_sql.define_column(dyn_sql, 3, xgeburt);

Mit Hilfe der define_column-Prozedur müssen Sie diejenigen Spalten der Abfrage definieren, die Sie nach dem Lesen der einzelnen Datensätze in entsprechende Variablen übernehmen wollen. Dank der Überlagerungstechnik können dabei nahezu alle Datentypen mit Hilfe der gleichen Prozedur definiert werden, die dafür drei bis vier Parameter erwartet. Durch den ersten Parameter wird der Bezug zum definierten Cursor hergestellt, indem die zugehörige Kennung übergeben wird. Der zweite Parameter bezieht sich auf die in der select-Anweisung aufgezählten Spalten und Ausdrücke und beschreibt die entsprechende Position in dieser Liste. Mit Hilfe des dritten Parameters legen Sie die Variable fest, in der die selektierten Werte später bereitgestellt werden sollen. Bei numerischen Werten oder Datumsfeldern sind Sie damit auch schon fertig und nur bei Textfeldern müssen Sie mit Hilfe des vierten Parameters die gewünschte Länge des Textpuffers vorgeben. Die define_column-Prozedur ist also das Bindeglied zwischen der Abfrage auf der einen und den entsprechenden Programmvariablen auf der anderen Seite. Nachdem Sie nun die Verbindung zwischen dem Abfrageobjekt und Ihren Programmvariablen hergestellt haben, könnten Sie die in dem Cursor gespeicherte Abfrage ausführen, was wiederum mit Hilfe der execute-Funktion möglich wäre. Der nächste Schritt bestünde dann darin, denn ersten Datensatz aus der selektierten Datenmenge anzufordern.

428


Da diese beiden Schritte in Auswahlabfragen eigentlich immer zusammengehören, gibt es dafür im dbms_sql-Paket sogar eine eigene Funktion, die wir in unserem Beispiel auch verwendet haben. rc := dbms_sql.execute_and_fetch(dyn_sql);

Mit der Funktion execute_and_fetch wird also die Abfrage ausgeführt und der erste Datensatz, sofern vorhanden, wird zur Abholung bereitgestellt. Hierzu benötigt die Funktion wiederum die Kennung des geöffneten Cursors und liefert als Ergebnis die Zahl der gelesenen Datensätze zurück, d.h. sofern Ihre Abfrage gar keine Sätze ermitteln konnte, erhalten Sie hier als Wert die Zahl 0. Alle weiteren Datensätze werden mit Hilfe der fetch_rows-Funktion angefordert, die wiederum die Zahl der gelesenen Sätze zurückliefert und die Cursorkennung als Parameter übergeben bekommt. rc := dbms_sql.fetch_rows(dyn_sql);

Aufgrund der Verhaltensweise dieser beiden Funktionen können Sie das Abarbeiten der selektierten Datenmenge ganz gut mit einer while loop-Schleife programmieren, die insgesamt so lange durchlaufen wird, wie der von der fetch_rows-Funktion zurückgegebene Wert größer 0 ist. rc := dbms_sql.execute_and_fetch(dyn_sql); while rc > 0 loop ... rc := dbms_sql.fetch_rows(dyn_sql); end loop;

Innerhalb der Schleife müssen wir nun bei jedem Durchlauf und damit für jeden selektierten Datensatz die einzelnen gewünschten Spalten anfordern, was mit Hilfe der column_value-Prozedur passiert, die hierzu neben der Cursorkennung wieder die Position der Select-Liste und die zugehörige Programmvariable benötigt. dbms_sql.column_value(dyn_sql, 1, xpersnr);

Die restlichen Befehle innerhalb der Schleife dienen zur Aufbereitung bzw. Formatierung der gelesenen Werte, beispielweise werden die Textfelder mit Hilfe der rpadFunktion auf eine einheitliche Länge ausgerichtet, so dass Endergebnis der normalen Ausgabe im SQL-Editor in fast nichts nachsteht. Am Ende der ausgegebenen Datensätze drucken wir sogar noch die Zahl der gelesenen Datensätze aus, die wir mit Hilfe der last_row_count-Funktion ermitteln können. Diese Funktion entspricht praktisch der rowcount-Statusvariablen, die Sie bei den statischen Cursorn kennen gelernt haben, d.h. der von der Funktion last_row_count gelieferte Wert erhöht sich wieder mit jedem erfolgreichen Aufruf von fetch_rows. 7000006 7000018 7000021 ...

Beckmann,Yonne Bruckner,Yonne Bätzing,Bärbel

04.01.1957 13.03.1968 17.01.1963

5899.00 5300.00 624.00


7000012 Sistermann,Willy 7000016 Voltair,Samuel 7000008 Voltair,Samuel 7000009 Zola,Wolf Anzahl Sätze: 23

429

16.08.1975 23.01.1959 19.11.1965 23.07.1966

5122.00 6300.00 5200.00 6200.00

Listing 5.16: Ausführung der dynamsichen Auswahlabfrage aus Beispiel 5.15

Dynamische Abfragen parametrieren In diesem nun folgenden letzten Abschnitt zum Thema der Abfrageverwendung in einem PL/SQL-Programm werden wir die bisherigen Verfahrensweisen krönen und unsere dynamischen Abfragen parametrieren. Wenn Sie sich nun fragen, warum bzw. aus welchem Grund wir irgendwelche Mühen unternehmen, die dynamischen Abfragen in einem nun folgenden Schritt noch flexibler zu gestalten, dann gibt es hierfür eine ganz einfache Antwort, nämlich Zeit. Wird innerhalb eines Programms eine dynamische Abfrage zum Beispiel innerhalb einer Schleife mehrfach mit lediglich anderen Parametern ausgeführt, so können Sie sich den mehrfachen Aufruf der parse-Prozedur und die damit verbundenen Prüfungen und Übersetzungsaktivitäten sparen, indem Sie die Abfrage parametergesteuert erstellen. Dabei müssen Sie für jeden benötigten Parameter in der dynamischen SQL-Anweisung einen entsprechenden Platzhalter definieren. dbms_sql.parse(sql_id, 'delete lohnarten where persnr = :X', dbms_sql.native);

Für diese Platzhalter können Sie ähnliche wie bei den Variablen einem beliebigen Namen verwenden, wobei die Kennzeichnung des Platzhalters durch einen vorangestellten Doppelpunkt erfolgt. Vor dem Ausführen der Abfrage, d.h. vor dem Ausführen der execute- bzw. execute_and_fetch-Funktion müssen Sie den Platzhalter natürlich durch einen konkreten Wert ersetzen, wofür die bind_variable-Prozedur im dbms_sql-Paket existiert. dbms_sql.bind_variable(sql_id, ':X', xpersnr);

Mit Hilfe dieser Prozedur wird der in der Abfrage vorhandene Platzhalter „:X“, dessen Name als zweiter Parameter spezifiziert werden muss durch den als dritten Parameter übergebenen Wert ersetzt. In meinem Beispiel würde also der in der Variablen xpersnr gespeicherte Wert in die Löschabfrage eingesetzt, so dass das anschließende Ausführen der execute-Funktion zur Löschung der entsprechenden Mitarbeiterdaten führt.

5.1.9

Fehlerbehandlung

Tritt während der Ausführung eines PL/SQL-Programms ein Fehler auf, so wird das Programm mitsamt der aktuellen Transaktion abgebrochen. Dabei ist es relativ gleichgültig, wie es zu der Fehlersituation kam bzw. was den Laufzeitfehler ausge-

430


löst hat. Im Folgenden finden Sie eine bei weitem nicht vollständige Liste von möglichen Ursachen solcher Laufzeitfehler:

X X

X

X

Es liegt eine technische Störung vor. Beispielsweise ist eine an der Abfrage beteiligte Datenbank nicht verfügbar, das verwendete Rollback-Segment ist zu klein, oder Tablespace oder die zugehörige Festplatte ist voll. Manchmal liegen die Ursachen eines Laufzeitfehlers auch im Betriebsablauf, beispielweise weil bestimmte Datenbankobjekte aufgrund von Zugriffskonflikten nicht gesperrt werden konnten oder weil ein Administrator die zum Programm gehörende Session wegen anlaufender Wartungsarbeiten aus dem System geworfen hat. Ein anderer Pulk von Quellen für Laufzeitfehler ist eher im zugehörigen Programm zu suchen. Hierzu zählen beispielsweise Situationen, in denen nicht definierte (z.B. Division durch 0) oder verbotene Anweisungen (Zuweisung von null in eine not null-Variable) ausgeführt werden. Ebenfalls in diese Kategorie gehören Probleme, die beim Einsatz dynamischer SQL-Anweisungen entstehen, weil die zur Laufzeit konstruierten SQL-Abfragen syntaktisch fehlerhaft sind. Die letzte und wesentlichste Gruppe von Fehlerursachen ist allerdings in dem ganz gewöhnlichen Betrieb einer relationalen Datenbank und der damit verbundenen Methoden und Konzepte zu suchen. Was kann der arme Programmierer dafür, wenn seine eigentlich korrekte SQL-Anweisung von irgendeinem Constraint oder Trigger zurückgerollt wird oder wenn ein Datensatz aufgrund der Mehrbenutzerumgebung auf einmal schon da ist und wegen des vorhandenen Primärschlüssel ein Laufzeitfehler des Typs „doppelter Wert bei einem eindeutigen Index“ entsteht?

Die Frage, die Sie sich bei jedem Programm oder Skript nun stellen müssen ist, welcher dieser eben genannten Laufzeitfehler wollen Sie in Ihrem Programm explizit abfangen und bei welchen Fehler lassen Sie es einfach drauf ankommen und nehmen somit im Falle eines Falles eben den Programmabsturz in Kauf. Nach meiner Ansicht kann man die aus den beiden ersten Gruppen resultierenden Laufzeitfehler oftmals durchaus unbeachtet lassen, d.h. beim Eintreten einer solchen Situation erfolgt ein entsprechender Programmabsturz. Eigentlich ist es ja egal, ob die Meldung eines technischen Problems durch eine Systemmeldung oder mit Hilfe einer im Programm generierten Meldung erfolgt. Außerdem gibt es gerade im technischen Umfeld Fehlersituationen, die keine Fehlerbehandlungsroutine dieser Welt erfolgreich behandeln kann, beispielsweise wenn der Datenbankserver einfach ausgeschaltet wurde. Für die in der dritten Gruppe beschriebenen Fehlerquellen finde ich auch nicht unbedingt, dass sie in einer speziellen Fehlerbehandlungsroutine gut aufgehoben sind, denn die meisten solcher Probleme können schon im Vorfeld durch entsprechende Programmpassagen abgefangen bzw. ausgeschlossen werden. Besteht beispielsweise die Möglichkeit, dass ein Divisor den Wert 0 annehmen kann, dann sollte das im Vorfeld der Division durch entsprechende Programmlogik abgefangen werden. Besteht diese Möglichkeit aufgrund der vorhandenen Rahmenbedingungen eigentlich nicht, so kann man in vielen Fällen auch ohne Prüfung und speziel-


431

ler Fehlerbehandlungsroutine in die Divisionsaufgabe einsteigen. Steht dann doch einmal eine 0 unter dem Bruchstrich, so führt das halt zum vorzeitigen Ableben Ihres Programms und der Erkenntnis, dass ein Fehler im Gesamtkonzept vorliegt bzw. die „nicht 0 Garantie“ nicht viel Wert war. Die in der letzten Gruppe beschriebenen Fehlerursachen sollten im Regelfall sicherlich nicht zum Absturz eines Programms, sondern höchstens zum Abbruch der aktuellen Transaktion und zur Ausgabe entsprechender Meldungen führen, wobei es natürlich auch hier Situationen gibt, wo das Versagen einer Operationen den geordneten Rückzug des gesamten Programms nahe legt. Behandlung im Programm Wie ich schon ganz am Anfang des Kapitels angedeutet habe, besteht innerhalb von PL/SQL die Möglichkeit, innerhalb eines Programmblocks eine spezielle Routine zur Behandlung von Laufzeitfehlern zu programmieren. Eine solche Fehlerbehandlungsroutine beginnt mit dem Schlüsselwort exception und bildet meistens den Abschluss eines solchen Programmblocks, so dass sich für die Blockstruktur unserer Programme das folgende neue Schema ergibt: begin ... Anweisungen des Blocks A begin ... Anweisungen des Blocks B exception ... Fehlerbehandlung für Block B end; exception ... Fehlerbehandlung für Block A end;

Diesem Schema können Sie auch entnehmen, dass durch die geeignete Konstruktion von Programmblöcken die Möglichkeit besteht, für spezielle Anweisungen entsprechende Fehlerbehandlungsroutinen zu programmieren. Das ist gerade bei der Erstellung von Schleifen besonders interessant, wenn bei einem Fehler innerhalb der Schleife zwar der aktuelle Datensatz nicht weiter bearbeitet werden soll, die noch fehlenden Durchläufe bzw. die restlichen Datensätze jedoch verarbeitet werden können. Wie gesagt, beginnt die Programmierung einer solchen Ausnahmeroutine mit der exception-Anweisung, der mit Hilfe des Schlüsselwortes when eine Aufzählung der zu berücksichtigenden Ausnahmezustände folgt, so dass sich folgendes Programmschema ergibt: exception when Laufzeitfehler-A then ... Problembehandlung für A

432


when Laufzeitfehler-B then ... Problembehandlung für B ... when others then

Die zu verwendenden Codes sind im Paket dbms_standard vordefiniert, so dass Sie in Ihrem Programm die dort definierten Konstanten und damit sprechende Namen verwenden können. Eine vollständige Aufstellung der verfügbaren Konstanten müssen Sie jetzt allerdings nicht dem dbms_standard-Paket entlocken, sondern Sie finden diese in der Oracle-Dokumentation im Buch „PL/SQL User's Guide and Reference“ im Kapitel „Error Handling“ und dort im Abschnitt „Predefined Exceptions“. Ist der aufgetretene Fehler in Ihrer selbstgeschriebenen Fehlerbehandlungsroutine nicht enthalten, dann tritt wieder das dafür im System standardmäßig verfügbare Verfahren in Kraft, d.h. es erfolgt die Ausgabe der zugehörigen Hinweis- bzw. Fehlermeldungen und anschließend kommt es zum erzwungenen Programmabbruch. Betrachten Sie nun das zunächst einmal sehr einfache Beispiel 5.17, mit dem ich die grundsätzliche Funktionsweise einmal am Beispiel der Division durch 0 zeigen möchte. declare i integer not null:=0; j integer; begin i:=10/i; --i:= j; exception when zero_divide then raise_application_error(-20000, 'Fehlerhafte Division', false); when others then raise_application_error(-20000,'Unbekannter Fehler',true); end; Listing 5.17: Programmierung einer exception-Routine für Laufzeitfehler

Wie Sie dem Beispiel 5.17 entnehmen können, heißt die Konstante für den bei der Division durch 0 entstehenden Fehler zero_divide. Beim Eintreten dieses Fehlers geben wir mit Hilfe von raise_application_error eine entsprechende Meldung aus und leiten den Programmabbruch ein. ORA-20000: Fehlerhafte Division ORA-06512: at line 9


433

Als dritten Parameter für diese Prozedur habe ich dieses Mal explizit den Wert false übergeben, so dass vorhergehende Fehlermeldungen nicht mit ausgegeben werden. Im Unterschied hierzu verwende ich bei der Behandlung der sonstigen Fehler als dritten Parameter den Wert true, um bei der Verarbeitung des eigentlich unbekannten Problems wenigstens die zugehörige Fehlermeldung zu erhalten. Sie können diese unterschiedliche Verhaltensweise leicht ausprobieren, indem Sie die fehlerauslösende Programmstelle ändern bzw. die Kommentierung im Programm austauschen: -- i:=10/i; i:= j;

Anschließend entsteht bei der Programmausführung wegen der verbotenen Zuweisung von null der Laufzeitfehler value_error, den wir aber nicht explizit abgefangen haben, sondern im Rahmen der sonstigen Fehler bearbeiten und aufgrund des anderen Parameterwertes von raise_application_error sieht das Ganze jetzt folgendermaßen aus: ORA-20000: Unbekannter Fehler ORA-06512: at line 11 ORA-06502: PL/SQL: numeric or value error

Selbst Laufzeitfehler auslösen Weiter oben in diesem Workshop hatte ich gesagt, dass Sie mit Hilfe des raise_application_errors-Befehls die Ausgabe des beim Aufruf verwendeten Hinweises und das Beenden des Programms bewirken. Betrachtet man alleine Aktion und Wirkung dieses Befehls, dann sieht das auch durchaus so aus, wobei die genaue Verfahrensweise eine andere ist, denn mit Hilfe dieser Prozedur lösen Sie in Ihrem Programm einen Laufzeitfehler aus, wobei Sie die im ersten Parameter verwendete Nummer zur Unterscheidung der jeweiligen Fehler verwendet werden können. Und wenn für diesen ausgelösten Fehler keine spezielle Fehlerbehandlungsroutine verfügbar ist, dann führt das eben zu dem beschriebenen Programmabbruch. begin raise_application_error(-20980,'Bitte abbrechen...'); exception when zero_divide then raise_application_error(-20000, 'Fehlerhafte Division', false); when others then raise_application_error(-20000,'Unbekannter Fehler',true); end; ORA-20000: Unbekannter Fehler ORA-06512: at line 9 ORA-20980: Bitte abbrechen... Listing 5.18: Erzeugen eines Laufzeitfehlers mit raise_application_error

434


Das Beispiel 5.18 demonstriert diesen Zusammenhang noch einmal. Gleich zu Beginn wird mit Hilfe der Prozedur raise_application_error der Laufzeitfehler 20980 ausgelöst, der natürlich zur Abarbeitung der in unserem Block programmierten Fehlerbehandlungsroutine führt. Da der generierte Fehler natürlich nicht in der exception-Liste aufgeführt ist wird der when others-Zweig ausgeführt, was zu den im Listing gezeigten Meldungen und zum Programmende führt. Sofern Sie in Ihrem Programm auf solche selbstausgelösten Laufzeitfehler in besonderer Art und Weise reagieren möchten, dann besteht eine Möglichkeit darin, innerhalb des when others-Zweigs die Statusvariablen sqlcode oder sqlerrm abzufragen und entsprechend der dort gespeicherten Werte zu reagieren. Wie sich anhand der Bezeichnungen der beiden Variablen sicher schon denken können, enthält sqlcode den zum Laufzeitfehler zugehörigen Fehlerocde und sqlerrm die zugehörige Fehlermeldung. Eine andere Möglichkeit besteht darin, für die selbstdefinierten Fehlernummern, die im Übrigen im Wertebereich von –20000 bis –20999 liegen müssen, benannte Laufzeitfehler zu katalogisieren. Hierzu müssen Sie zunächst im Deklarationsteil des Blocks den gewünschten Laufzeitfehlernamen deklarieren und diesen Namen anschließend in einem zweiten Schritt mit der zugehörigen Fehlernummer verknüpfen: declare sonstiges exception; pragma exception_init(sonstiges, -20980);

Mit diesem Beispiel definieren wir den Laufzeitfehler sonstiges und verknüpfen ihn anschließend mit der Anweisung pragma exception_init mit der gewünschten Fehlernummer. Anschließend können Sie diesen Laufzeitfehler in Ihrer Fehlerbehandlungsroutine mit Hilfe eines eigenen when-Zweigs abfangen, was mit Hilfe des nächsten Beispiels 5.19 demonstriert wird. declare sonstiges exception; pragma exception_init(sonstiges, -20980); begin raise_application_error(-20980,'Bitte abbrechen...'); exception when zero_divide then raise_application_error(-20000, 'Fehlerhafte Division', false); when sonstiges then raise_application_error(-20000,'Sonstiger Fehler',true); when others then raise_application_error(-20000,'Unbekannter Fehler',true); end;


435

ORA-20000: Sonstiger Fehler ORA-06512: at line 14 ORA-20980: Bitte abbrechen... Listing 5.19: Abfangen selbsterstellter Laufzeitfehler

Die raise-Anweisung Wenn Sie in Ihrem Programm selbst einen Laufzeitfehler auslösen, für den eine geeignete Fehlerbehandlungsroutine vorhanden ist, dann wirkt die im Beispiel 5.19 gezeigte Verfahrensweise wegen der zweimaligen Verwendung der raise_application_error-Prozedur irgendwie ein wenig umständlich, und in der Tat existiert noch eine weitere Variante, einen Laufzeitfehler auszulösen. Diese zweite Variante hört auf den Namen raise und kann zum Auslösen eines für den Block definierten Laufzeitfehlers verwendet werden, wobei Sie die genaue Verwendung dem folgenden Schema entnehmen können: declare exception; begin ... raise ; exception ... when then end;

Ich möchte auch den raise-Befehl mit Hilfe eines kurzen Beispiels demonstrieren und dabei vor allem auch einmal zeigen, dass Fehlerbehandlungsroutinen natürlich nicht nur zum Programmieren eines schöneren Programmabbruchs gedacht sind, denn wenn Sie innerhalb der exception-Programmierung keinen weiteren unbehandelten Fehler generieren, was aber oftmals und auch in allen unseren bisherigen Beispielen passierte, dann wird das Programm eben nicht abgebrochen, sondern kann hinter der exception-Routine fortgesetzt werden. In solchen Fällen ist es allerdings oftmals zweckmäßig, auf die Verwendung separater Programmblöcke zurückzugreifen. In unserem nächsten Beispiel sollen alle Datensätze der Tabelle personalien verarbeitet werden. Zu Demonstrationszwecken denken wir uns dabei, dass bei allen männlichen Mitarbeitern im Programm der Ausnahmezustand eintritt, was zu einem Laufzeitfehler führt, den wir im Programm natürlich mit Hilfe der raise-Anweisung selbst auslösen. declare cursor xpers is select persnr, name, geschlecht from personalien; falsches_geschlecht exception;

436


begin for xpers_rec in xpers loop begin if xpers_rec.geschlecht in ('M','2') then -- Simulation eines Fehlers raise falsches_geschlecht; end if; dbms_output.put_line(xpers_rec.persnr || ' ok!'); exception when falsches_geschlecht then dbms_output.put_line(xpers_rec.persnr || ' falsch!'); end; end loop; end; Listing 5.20: Behandeln eines Laufzeitfehlers in einer Schleife

Wie Sie dem Beispiel 5.20 entnehmen können, deklarieren wir in unserem Programm neben dem Cursor xpers auch noch den Laufzeitfehler falsches_geschlecht. Die einzelnen Datensätze des Cursors verarbeiten wir wieder mit Hilfe einer for loop-Schleife, wobei die eigentliche Verarbeitung der Personalien mit Hilfe eines separaten Blocks erfolgt. begin if xpers_rec.geschlecht in ('M','2') then -- Simulation eines Fehlers raise falsches_geschlecht; end if; dbms_output.put_line(xpers_rec.persnr || ' ok!'); exception when falsches_geschlecht then dbms_output.put_line(xpers_rec.persnr || ' falsch!'); end;

In diesem Block lösen wir bei den männlichen Kollegen aus unserer Testdatenbank den zuvor deklarierten Fehler falsches_geschlecht aus, der aber aufgrund der im Block enthaltenen exception-Routine abgefangen wird, und das Einzige, was wir in unserer Fehlerroutine diesmal tun besteht in der Ausgabe einer Meldung in dem von dbms_output verwalteten Protokollpuffers. Der entstandene Laufzeitfehler wurde also abgefangen und es erfolgt demzufolge kein Programmabbruch. Stattdessen fährt unser Programm mit der Verarbeitung des nächsten Datensatzes fort.


7000002 7000003 7000004 7000006 7000009 7000011 7000012 7000014 7000016 7000018

437

falsch! ok! falsch! ok! falsch! falsch! falsch! falsch! falsch! ok!

Listing 5.21: Auszug aus dem zum Beispiel 5.20 zugehörigen Protokoll

Protokollieren von Laufzeitfehlern Das zuletzt gezeigte Beispiel funktioniert zwar ganz prima, ist insofern aber etwas praxisfremd, da die vom Programm mit Hilfe des dbms_output-Pakets erzeugten Meldungen nur angezeigt werden, wenn man das Skript oder Programm mit Hilfe eines SQL-Editors startet. Ist das Skript aber beispielsweise in einem gewöhnlichen Programm eingebettet oder das PL/SQL-Programm wird mit irgendwelchen Mechanismen automatisch gestartet, dann ist die Verwendung des dbms_ouput-Pakets zur Dokumentation von Laufzeitfehlern nicht sonderlich gut geeignet. In der Praxis verwendet man zur Protokollierung solcher Meldung oftmals gewöhnliche Datenbanktabellen, die anschließend nach jedem Programmlauf ausgewertet werden können. Mit Hilfe des nächsten Beispiels (vgl. Listing 5.22) erzeugen wir zunächst einmal eine solche Protokolltabelle, in der wir gleich die personenbezogenen Fehlermeldungen speichern wollen. drop table meldungen; / create table meldungen (persnr varchar2(11), meldung varchar2(255)); Listing 5.22: Anlage einer einfachen Protokolltabelle

Unser nächstes Beispiel verwendet als Ausgangsbasis wieder das im Listing 5.20 gezeigte Programm. Allerdings wollen wir im Rahmen der Verarbeitung diesmal eine Spalte ändern, bzw. diese Änderung beim Auftreten eines Laufzeitfehlers rückgängig machen und stattdessen einen Hinweis in unserer Protokolltabelle einstellen. declare cursor xpers is select persnr, name, geschlecht from personalien; falsches_geschlecht exception; begin delete meldungen;

438


update personalien set strasse1 = null; commit; for xpers_rec in xpers loop begin update personalien set strasse1 = strasse4 where persnr = xpers_rec.persnr; if xpers_rec.geschlecht in ('M','2') then -- Simulation eines Fehlers raise falsches_geschlecht; end if; commit; exception when falsches_geschlecht then rollback; insert into meldungen values (xpers_rec.persnr, 'Irgend ein fehler '); commit; end; end loop; end; Listing 5.23: Verwenden einer Datenbanktabelle zum Speichern von Laufzeitfehlern

Die ersten Anweisungen in unserer neuen Programmvariante dienen eigentlich nur dazu, das Programm mehrfach wiederholen zu können, indem zum einen die Protokolltabelle gelöscht wird und zum anderen die durchgeführten Änderungen rückgängig gemacht werden. delete meldungen; update personalien set strasse1 = null; commit;

Innerhalb der Programmschleife soll für jeden Mitarbeiter das Feld strasse4 in das Feld strasse1 kopiert werden, was mit Hilfe der folgenden update-Anweisung passiert: update personalien set strasse1 = strasse4 where persnr = xpers_rec.persnr;

Die für gespeicherten männlichen Mitarbeiter generieren wir nach der Durchführung der Änderung nun wieder mit Hilfe des raise-Kommandos den simulierten Laufzeitfehler und gelangen somit in die zugehörige Fehlerbehandlungsroutine.


439

Dort fügen wir mit Hilfe einer einfachen insert-Anweisung einen Datensatz in die soeben angelegte Protokolltabelle ein. insert into meldungen values (xpers_rec.persnr, 'Irgend ein fehler ');

Das eigentliche Problem bei der ganzen Angelegenheit besteht nun darin, dass im Fehlerfall die schon durchgeführten Änderungen für diesen Satz zurückgerollt werden müssen und auf der anderen Seite darauf geachtet werden muss, dass ins Protokoll eingefügte Meldungen in jedem Fall erhalten bleiben. Genau genommen ist das aber gar nicht schwierig und die Lösung besteht einzig und alleine in dem Einfügen geeigneter commit- bzw. rollback-Anweisungen. Wie Sie dem Listing 5.23 entnehmen können, habe ich mich dafür entschieden, die innerhalb der Schleife durchgeführten Transaktionen für jeden Datensatz sofort zu beenden, was durch die vor der Fehlerbehandlungsroutine platzierte commit-Anweisung passiert. Entsteht nun innerhalb des Blocks ein Fehler, dann rollen wir diese aktuelle Transaktion zunächst zurück und fügen anschließend, d.h. in einer neuen Transaktion, die Protokolldatensatz in die entsprechende Tabelle ein, wobei wir auch diese Transaktion sofort durch eine commit-Anweisung abschließen. Wenn Sie dieses Programm laufen lassen, dann erhalten Sie für alle männlichen Mitarbeiter einen Hinweis in der Protokolltabelle und für alle weiblichen Mitarbeiter wird die Straße ins Datenfeld strasse1 kopiert. SQLWKS> select persnr, strasse1 from personalien 2> PERSNR STRASSE1 ----------- ----------------------------------7000002 7000003 Im Schlosspark 3 7000004 7000006 Franz-Haniel-Gasse 3 7000009 ... 26 rows selected. SQLWKS> select * from meldungen 2> PERSNR MELDUNG ----------- -----------------------7000002 Irgend ein fehler 7000004 Irgend ein fehler 7000009 Irgend ein fehler 7000011 Irgend ein fehler ... 12 rows selected. Listing 5.24: Ergebnis der Änderungsabfrage aus dem Beispiel 5.23

440


Obwohl das Programm einwandfrei funktioniert, habe ich dennoch schon wieder etwas zu meckern, denn Sie sollten sich zumindest darüber im Klaren sein, dass Sie in dem Fall einen undefinierten Zustand bekommen, wenn das zuletzt gezeigte Programm während der Verarbeitung doch noch unkontrolliert abstürzt. Da wir jede Transaktion sofort abschließen bleibt die Datenbank in einem halbfertigen Zustand, wenn das Programm nicht bis zum Ende läuft. Das wäre in unserem und in ähnlich gelagerten Beispielen, wo die Programme jederzeit wiederholt werden können, zwar kein Problem, doch es gibt in der Praxis anders gelagerte Fälle, wo es besser ist, wenn das Programm entweder ganz oder gar nicht läuft. Verwenden von Sicherungspunkten In solchen Fällen hilft der Einsatz von Sicherungspunkten. Im Rahmen der Transaktionsbeschreibung hatten Sie die zugehörige savepoint-Anweisung zwar schon kennen gelernt, jedoch wurde Ihnen ein vernünftiges und einleuchtendes Anwendungsbeispiel bislang vorenthalten. Das möchte ich mit der nächsten und letzten Variante des vorhergehenden Beispiels jetzt nachholen. Um es noch einmal zusammenzufassen: Wir haben es jetzt mit den zwei konkurrierenden Problemen zu tun. Zum einen müssen wir das Wechselspiel zwischen dem Zurückrollen einzelner Datensatzänderungen und dem Einfügen der Protokolldatensätze realisieren und zum anderen soll keine der gesamten Änderungen sichtbar werden, wenn das Programm nicht normal beendet wird. declare cursor xpers is select persnr, name, geschlecht from personalien; falsches_geschlecht exception; begin delete meldungen; update personalien set strasse1 = null; commit; for xpers_rec in xpers loop begin savepoint sicher; update personalien set strasse1 = strasse4 where persnr = xpers_rec.persnr; if xpers_rec.geschlecht in ('M','2') then -- Simulation eines Fehlers raise falsches_geschlecht; end if;


441

exception when falsches_geschlecht then rollback to savepoint sicher; insert into meldungen values (xpers_rec.persnr, 'Irgend ein fehler '); end; end loop; commit; end; Listing 5.25: Verwenden von Sicherungspunkten

Im Unterschied zur letzten Varianten definieren wir diesmal am Anfang des Schleifenblocks den Sicherungspunkt sicher, d.h. wir gehen davon aus, dass am Anfang unserer Schleife die Welt noch bzw. wieder in Ordnung ist. Anschließend führen wir wieder unsere Datenänderung durch, dem die Generierung des Laufzeitfehlers folgt. Bei der Behandlung des Laufzeitfehlers müssen wir als Erstes wieder die zuletzt durchgeführten Änderungen rückgängig machen, was diesmal allerdings mit Hilfe einer speziellen rollback-Anweisung passiert, mit der wir alle Änderungen bis zum letzten Sicherungspunkt zurückrollen. Anschließend fügen wir unsere Meldung in die Protokolltabelle ein. Da wir diesen Sicherungspunkt jedes Mal erneut am Anfang eines Schleifendurchlaufs setzen, führt die Anweisung rollback to savepoint sicher zur Rückgängigmachung aller im aktuellen Durchlauf durchgeführten Änderungen, wohingegen die Einfügeoperation, die hinter dem rollback-Kommando bzw. vor dem Sicherungspunkt ausgeführt wird, dabei erhalten bleibt. Ebenfalls unterschiedlich zur vorhergehenden Programmvariante ist, dass wir diesmal erst ganz am Ende des Programms, d.h. nach dem Verarbeitung aller Datensätze, eine commit-Anweisung absetzen und damit alle durchgeführten Änderungen endgültig bestätigen. Kommt es zwischendurch also doch noch zu einem Programmabbruch, so finden Sie in der Datenbank überhaupt keine Änderungen und Protokolldatensätze. Wenn Sie diesen Effekt einmal ausprobieren wollen, dann können Sie den commitBefehl beispielsweise durch eine rollback- oder raise_application_error-Anweisung ersetzen.

5.1.10 Dateiverarbeitung Zwar dient eine SQL-Datenbank mitsamt der darin enthaltenen Werkzeuge in erster Linie der Verarbeitung der in der Datenbank gespeicherten Tabellen und dennoch bietet Ihnen PL/SQL auch eine Möglichkeit, gewöhnliche Dateien in Ihren Programmablauf mit einzubinden. Auf diese Weise sind Sie in der Lage, beispiels-

442


weise Schnittstellendateien direkt innerhalb eines PL/SQL-Programms zu verarbeiten, d.h. Sie benötigen nicht unbedingt zusätzliche Arbeitsschritte um solche Dateien in einem vor- bzw. nachgelagerten Schritt zu importieren bzw. zu exportieren. Konkret werden Ihnen diese Möglichkeiten durch das Paket utl_file beschert, d.h. mit Hilfe der dort vorhandenen Funktionen und Prozeduren können Sie gewöhnliche Textdateien erstellen oder verarbeiten. Wie an vielen anderen Stellen auch, so erhalten Sie in diesem Abschnitt natürlich mal wieder nur einen ersten Eindruck von den insgesamt zur Verfügung stehenden Möglichkeiten. Mehr Informationen bzw. die vollständige Beschreibung des utl_file-Pakets finden Sie wieder in der Oracle-Dokumentation im Buch „Oracle8 Application Developer's Guide“ und dort im Kapitel „PL/SQL Input/Output“. Die Verarbeitung bzw. Erstellung von Textdateien erfolgt mittlerweile in fast jeder Programmiersprache mit ähnlichen Befehlen bzw. die generelle Vorgehensweise folgt immer dem gleichen Schema. Zunächst müssen Sie die zu verarbeitende Datei mit Hilfe einer speziellen Anweisung öffnen, wobei Sie üblicherweise eine Kennbzw. Kanalnummer erhalten, die anschließend bei allen anderen Dateioperationen verwendet wird. Mit Hilfe spezieller Befehle können Sie die geöffnete Datei lesen oder beschreiben und nach erledigter Arbeit wird die Datei mit Hilfe einer speziellen Anweisung wieder geschlossen. Verzeichnisse freigeben Gewöhnlich haben die Instanzen der Datenbank uneingeschränkten Zugriff auf die Ressourcen des eingesetzten Servers. Werden nun im Rahmen von Serverprogrammen Dateien erstellt oder geändert und können diese Programme von beliebigen Datenbankbenutzern gestartet werden, dann haben diese dadurch vielleicht auch indirekt Zugriff auf Dateien und Verzeichnisse, für die Sie normalerweise keine Berechtigungen besitzen. Aus diesem Grund ist die Verwendung des utl_file-Pakets an besondere Einstellungen gebunden, d.h. standardmäßig ist das Paket zwar vorhanden, aber es können mit ihm keinerlei Dateien verarbeitet werden. Damit die im Paket enthaltenen Funktionen benutzt werden können, müssen Sie innerhalb der Instanzkonfiguration (INITxxxx.ORA) diejenigen Verzeichnisse explizit freigeben, in denen das Paket Dateien verarbeiten darf. Hierzu müssen Sie in der Konfigurationsdatei der Instanz den Parameter utl_file_dir mit dem freizugebenden Verzeichnis verwenden, wobei Sie für jedes Verzeichnis einen eigenen Parametereintrag spezifizieren müssen. utl_file_dir = c:\temp utl_file_dir = c:\output\data utl_file_dir = c:\daten

Dabei müssen Sie natürlich die vom Betriebssystem des Servers abhängige Schreibweise für Verzeichnisse beachten. Bei dem von mir gezeigten Beispiel handelt es sich offensichtlich um eine Einstellung für NT-Server. Auf einem Unix-Server kippt dann der die Unterverzeichnisse trennende Strich in die andere Richtung. Außer-


443

dem fehlen üblicherweise die Laufwerksbuchstaben und Sie müssen die exakte Schreibweise (Groß-/Kleinschreibweise) beachten: utl_file_dir = /PSI/applications

Wenn Sie einen unbeschränkten Zugriff ermöglichen wollen, dann müssen Sie allerdings nicht jedes vorhandenes Verzeichnis vorgeben, sondern können sich die Sache deutlich vereinfachen, indem Sie folgende Kurzform verwenden. utl_file_dir = *

Datei öffnen In PL/SQL erfolgt das Öffnen einer Datei mit der Funktion utl_file.fopen, die hierzu insgesamt drei Parameter erhält und für die geöffnete Datei eine Kennung vom Typ utl_file.file_type zurückliefert. := utl_file.fopen(, , <Modus>)

Mit Hilfe der ersten beiden Parameter müssen Sie der Funktion das Verzeichnis und den Dateinamen der zu öffnenden Datei vorgeben. Der dritte Parameter legt fest, in welchem Modus die Datei geöffnet wird und bestimmt damit, welche Operationen anschließend mit der geöffneten Datei möglich sind. Modus

Beschreibung

r

öffnet die Datei zum Lesen und ermöglicht damit anschließend die Verwendung der Funktion get_line.

w

Verwenden Sie diesen Parameter, um die Datei im Schreibmodus zu öffnen, wobei eine schon vorhandene Datei hierbei überschrieben wird.

a

Dieser Modus dient zum Fortschreiben der Datei, d.h. eine bereits vorhandene Datei wird hierdurch nicht überschrieben, sondern verlängert. Ist die Datei noch gar nicht vorhanden, dann öffnet die Funktion die Datei automatisch im Modus „w“.

Tabelle 5.13: Verschiedene Modi zum Öffnen einer Datei

Wenn in Ihrem Programm Verzeichnis- oder Dateinamen variabel vorgegeben werden können, dann sollten Sie wenigstens den Laufzeitfehler utl_file.invalid_operation und utl_file.invalid_path abfangen, die bei Verwendung eines fehlerhaften Datei- bzw. Verzeichnisnamens ausgelöst werden. Datei schließen Eine im Programm geöffnete Datei sollten Sie ordentlich schließen, wenn Sie diese nicht mehr benötigen. Ordentlich bedeutet hierbei, dass Sie die geöffnete Datei mit Hilfe der Prozedur utl_file.fclose schließen, der Sie dafür die zugehörige Kennung übergeben müssen. utl_file.fclose()

444


Auch diese Prozedur kann verschiedene Laufzeitfehler auslösen. Beispielsweise erhalten Sie den Fehler utl_file.invalid_filehandle, wenn Sie die Prozedur mit einer ungültigen Kennung aufrufen. Als Alternative zum Schließen der einzelnen Dateien können Sie am Ende des Programms beispielsweise auch die Prozedur utl_file.fclose_all verwenden, die automatisch alle geöffneten Dateien schließt. Datensätze lesen Gelesen werden die in der Textdatei vorhandenen Datensätze mit Hilfe der Prozedur utl_file.get_line, der Sie hierzu neben der Kennung vor allem einen Puffer zur Aufnahme der gelesenen Datenzeile übergeben müssen. utl_file.get_line(, )

Bei der Verwendung dieser Prozedur sollten Sie vor allem dem Laufzeitfehler not_data_found ein wenig Beachtung schenken, denn dieser Fehler wird ausgelöst, wenn Sie versuchen, über das Ende der Datei hinauszulesen, d.h. mit Hilfe dieses Fehlers können Sie das Dateiende erkennen. Damit sind wir in der Lage, das Ganze anhand eines einfachen Beispiels zu demonstrieren. Hierzu erstellen wir ein Programm (vgl. Listing 5.26), mit dem wir eine beliebige Textdatei wie zum Beispiel die Konfigurationsdatei der Datenbankinstanz lesen und die einzelnen Datensätze am Bildschirm ausgeben. declare f utl_file.file_type; p varchar2(255); begin f := utl_file.fopen('e:\orant\database\db01','initdb01.ora','r'); loop begin utl_file.get_line(f, p); dbms_output.put_line(p); exception when no_data_found then exit; end; end loop; utl_file.fclose(f); end; Listing 5.26: Lesen und Verarbeiten einer Textdatei

Wie Sie dem Beispiel entnehmen können, startet unser Programm mit dem Öffnen der Textdatei und schließt diese mit Hilfe der letzten Programmanweisung wieder. Im Inneren des Programms programmieren wir eine loop-Schleife, mit deren Hilfe


445

die vorhandenen Datensätze der Datei gelesen und ausgegeben werden sollen. Innerhalb der Schleife verwenden wir einen eigenen Programmblock in dem wir eine Fehlerbehandlungsroutine programmieren, in der wir das erreichte Dateiende abfangen und anschließend die loop-Schleife verlassen. begin utl_file.get_line(f, p); dbms_output.put_line(p); exception when no_data_found then exit; end;

Datensätze schreiben Das Erstellen von Textdateien ist unter anderem mit Hilfe der Prozeduren utl_file.put und utl_file.new_line möglich. Dabei wird die erste der beiden genannten Prozeduren dazu benutzt, den Inhalt einer Puffervariablen an die aktuelle Dateiposition zu schreiben. Mit Hilfe der zweiten Prozedur erzeugen Sie in der Ausgabedatei einen Zeilenwechsel, d.h. ein nachfolgender Ausgabebefehl beginnt wieder mit einem neuen Datensatz. Wenn Sie eine Textdatei satzweise wegschreiben, dann müssen Sie die beiden Prozeduren also jedes Mal im Wechsel einsetzen, weshalb es im Paket auch eine Kombination der beiden Prozeduren gibt, die unter dem Namen utl_file.put_line angelegt ist und das Wegschreiben des Datensatzes mit dem anschließenden Zeilenwechsel in einem Rutsch erledigt. utl_file.put(, ); utl_file.new_line(); utl_file.put_line(, );

Zur Demonstration der Dateiausgabe werden wir gleich eine kleine Routine schreiben, mit der Sie den Inhalt einer Tabelle in eine Textdatei exportieren können. Als Tabelle wählen wir die Personalien aus und damit das ganze Beispiel (vgl. Listing 5.27) klein und übersichtlich bleibt, begnügen wir uns damit, anstelle der gesamten Tabelle nur drei verschiedene Datenfelder zu exportieren. Zum Lesen der Tabelle personalien definieren wir in unserem Skript den Cursor xpers, der innerhalb des Programmblocks mit Hilfe einer for loop-Schleife durchgelesen wird. Zuvor öffnen wir mit Hilfe der Prozedur utl_file.fopen die Ausgabedatei C:\TEMP\EXPORT.TXT im Ausgabemodus. declare cursor xpers is select * from personalien; f utl_file.file_type; begin

446


f := utl_file.fopen('c:\temp','export.txt','w'); for xpers_rec in xpers loop utl_file.put(f, xpers_rec.persnr); utl_file.put(f, chr(9)); utl_file.put(f, xpers_rec.name); utl_file.put(f, chr(9)); utl_file.put(f, to_char(xpers_rec.gebdatum,'YYYY.MM.DD')); utl_file.new_line(f); end loop; utl_file.fclose(f); end; Listing 5.27: Erstellen eines Beispiels für den Export einer Tabelle in eine Textdatei

Zur Ausgabe der einzelnen Datenfelder verwenden wir die Prozedur utl_file.put. Da diese Prozedur wie gesagt die geöffnete Datei mit Hilfe des übergebenen Puffer an der aktuellen Position fortschreibt, können wir jedes benötigte Datenfeld mit Hilfe eines eigenen Prozeduraufrufs ausgeben und nach Ausgabe des letzten Datenfeldes verwenden wir die Prozedur utl_file.new_line, damit die nächste Ausgabeoperation mit einem neuen Datensatz beginnt. Als Alternative hierzu hätten wir den gesamten Ausgabesatz auch zunächst mit Hilfe einer entsprechenden Puffervariablen aufbereiten können und hätten diese Puffervariable anschließend mit Hilfe der Prozedur utl_file.put_line als ganzen Datensatz in die Datei kopiert. Zwischen den einzelnen Datenfelder erzeugen wir die Ausgabe eines speziellen Trennzeichens, wobei wir durch die Ausgabe des Ausdrucks chr(9) einen Tabulator als Trennzeichen in die Textdatei einfügen.

5.1.11 Pipes So langsam stoßen wir mehr und mehr in ganz spezielle Randgebiete der PL/SQLProgrammierung vor, weshalb die Ausführlichkeit der hier gezeigten Beispiele mitsamt der zugehörigen Erläuterungen entsprechend abnimmt. Konkret geht es in diesem Kapitel um die sogenannten Datenbank-Pipes, die Ihnen aufgrund der Funktionalitäten des Pakets dbms_pipe zur Verfügung stehen. Sollten die im Folgenden kredenzten Häppchen Ihren Appetit wecken, dann sollten Sie sich die entsprechenden Seiten in der Oracle-Dokumentation gönnen. Sie finden dort eine ausführliche Beschreibung des dbms_pipe-Pakets im Buch „Oracle8 Application Developer's Guide“ und dort konkret wieder im Kapitel „PL/SQL Input/Output“. Sie erinnern sich sicherlich an die Pakete, mit denen Sie in der Lage waren sitzungsglobale Variablen zu definieren. Oftmals werden solche globalen Variablen auch dazu benutzt, um die Kommunikation zwischen in sich abgeschlossenen aber der aktuellen Sitzung zugeordneten Prozeduren oder Prozessen zu steuern. Ein konkretes Anwendungsbeispiel hierfür liegt in der Weiterleitung von Informationen von einem Vorab-Trigger an einen Danach-Trigger.


447

Bei den hier beschriebenen Pipes handelt es sich so ähnlich wie bei den Variablen im Prinzip auch um globale Bereiche, die allerdings datenbankglobal zur Verfügung stehen, d.h. auf die in der Pipe gespeicherten Informationen kann theoretisch jede beliebige Datenbanksitzung zugreifen. Zur Verwendung solcher Pipes gibt es auch aus meiner Sicht die folgenden beiden Einsatzgebiete:

X X

Sitzungsübergreifende Bereitstellung bestimmter Informationen, beispielsweise um spezielle Zwischenergebnisse oder den Stand der Verarbeitung ohne spezielle Arbeitstabellen zu dokumentieren. Steuerung und Kommunikation zwischen verschiedenen Prozessen, ggf. sogar zwischen PL/SQL-Programmen und sonstigen Serveranwendungen. Mit Hilfe solcher Pipes könnten Sie beispielsweise verschiedene Jobs synchronisieren, indem Sie die zugehörigen Programme so erstellen, dass Sie erst nach dem Empfang spezieller Nachrichten mit der eigentlichen Arbeit beginnen.

Die maximale Lebensdauer einer solchen Pipe entspricht der einer Datenbankinstanz, d.h. mit dem Runterfahren der Datenbank gehen die in der Pipe gepufferten Informationen verloren und werden beim Wiederhochfahren der Instanz nicht automatisch restauriert. Konkret hängt die Lebensdauer einer Pipe davon ab, ob sie implizit oder explizit erstellt wurde. Implizite Pipes werden vom System automatisch erstellt und auch wieder gelöscht, wenn in Ihr keine Informationen mehr vorhanden sind. Im Gegensatz dazu werden die expliziten Pipes mit Hilfe spezieller Befehle erstellt und gelöscht und bleiben daher auch dann erhalten, wenn in dem zugehörigen Bereich aktuell keine Daten gespeichert werden. Übrigens werden die impliziten Pipes häufig auch als öffentliche und die expliziten Varianten als private Pipes bezeichnet. Einstellen von Daten in die Pipe Wie eben gesagt, werden implizite Pipes automatisch vom DBMS angelegt. Das passiert genau dann, wenn eine entsprechende Routine versucht, Informationen in diese Pipe einzustellen. Das nachfolgende Beispiel zeigt dies an einem sehr einfachen Beispiel, indem eine einfache Zeichenfolge in die Pipe mit dem Namen „Hallo“ eingeleitet wird. declare i integer; begin dbms_pipe.pack_message('Ich bin da'); i:=dbms_pipe.send_message('Hallo'); end; Listing 5.28: Erzeugen einer impliziten Pipe

Wie Sie dem Beispiel 5.28 entnehmen können, benötigt man zum Einstellen von Information in die Pipe genau zwei verschiedene Anweisungen. Mit Hilfe der ersten Prozedur dbms_pipe.pack_message wird die zu übermittelnde Information in einen lokalen Pufferbereich übertragen. Anschließend wird dieser Bereich mit Hilfe der Funktion dbms_pipe.send_message in die benannte Pipe eingestellt, wobei der zu

448


verwendende Name als Parameter übergeben werden muss. In unserem Beispiel stellen wir durch den verwendeten Aufruf also einen kleinen Text in die Pipe mit dem Namen „Hallo“, die, sofern sie noch nicht vorhanden ist, dabei automatisch angelegt wird. Die Prozedur pack_message verträgt aufgrund der mehrfach überlagernden Deklaration im Paket nahezu jeden gängigen Datentyp. Lediglich für die Datentypen raw und rowid gibt es im Paket entsprechende Prozedurvarianten (z.B. pack_message_ rowid). Die send_message-Funktion kann mit ein bis drei Parametern aufgerufen werden: := dbms_pipe.send_message(, <Timeout>, <Max.Länge>);

Wie Sie schon wissen, beschreibt der erste Parameter den Namen der zu verwendenden bzw. erstellenden Pipe. Der zweite Parameter legt fest, wie die Funktion auf den erfolgreichen Einstellvorgang wartet, bevor der Einstellversuch abgebrochen wird. Ohne Vorgabe dieses Parameters wartet send_message der in der Konstanten maxwait festgelegten Anzahl von Sekunden was zur Zeit etwa 1000 Tage entspricht. Mit Hilfe des dritten Parameters können Sie die maximale Größe der Pipe festlegen, wobei die Pipe ohne diesen Parameter maxpipesize Byte groß ist, wobei der aktuelle Wert der maxpipesize-Konstante 8192 Byte ist. Der Rückgabewert der send_message-Funktion ist vom Datentyp Integer und entspricht der Zahl 0, wenn der Einstellvorgang erfolgreich verlief. Im Falle eines Timeouts erhalten Sie den Wert 1 und die Beschreibung weiterer möglicher Rückgabewerte können Sie der Oracle-Beschreibung entnehmen. Auslesen der Pipe Die Entnahme von Informationen aus einer solchen Pipeline ist genauso einfach wie deren Einfüllung und entspricht im Wesentlichen dem umgekehrten Einstellvorgang. Zum Ausprobieren des nun folgenden Beispiels 5.29 sollten Sie mal wieder ein zweite Sitzung Ihres SQL-Editors starten und das im Listing 5.28 gezeigte Einstellbeispiel mit der einen und das nun folgende Lesebeispiel mit der anderen Sitzung ausführen. declare i integer; b varchar2(255); begin i:=dbms_pipe.receive_message('Hallo'); dbms_pipe.unpack_message(b); dbms_output.put_line(b); end; Listing 5.29: Auslesen von Informationen aus einer Pipe

Die Entnahme von Informationen erfolgt mit Hilfe der Funktion dbms_pipe. receive_message und führt zum Kopieren der in der Pipe befindlichen Daten in einen lokalen Zwischenpuffer. Von dort aus können Sie die gepufferten Daten mit


449

Hilfe der Prozedur dbms_pipe.unpack_message in entsprechende Variablen übertragen. Ähnlich wie beim Einstellen von Informationen in die Pipe, kann auch die receive_message-Funktion mit mehr als einem Parameter verwendet werden. := dbms_pipe.receive_message(, <Timeout>);

Der erste Parameter beschreibt wieder den Namen der zu verwendenden Pipe, wobei der zweite Parameter festlegt, wie lange die Funktion auf das Eintreffen von Nachrichten warten soll. Standardmäßig entspricht das wieder der maxwait-Konstante, d.h. ohne konkrete Vorgabe der maximalen Wartezeit warten wir bis zu 1000 Tage, bevor die Funktion erfolglos abbricht. Ebenfalls ähnlich wie beim Senden können Sie auch beim Empfang mit Hilfe des zurückgelieferten integerwertes Feststellen, ob der Vorgang erfolgreich war oder nicht. Die Zahl 0 steht auch hier wieder für den Erfolg und alle anderen Ergebnisse spezifizieren einen aufgetretenen Fehler, wobei der wichtigste wieder die Zeitüberschreitung mit dem Wert 1 ist. Die Kopie der Pipe-Information in eine lokale Arbeitsvariable erfolgt wie schon gesagt mit Hilfe der unpack_message-Prozedur. Genau wie beim Packen der Information liegt auch diese Prozedur im Paket wieder in mehrfacher Deklaration vor, so dass Sie sie mit allen gängigen Datentypen verwenden können. Dennoch müssen Sie natürlich wissen, welche Variable Sie beim Prozeduraufruf verwenden müssen, wenn als Information Texte, Zahlen oder Datumswerte möglich sind. Aus diesem Grund enthält das dbms_pipe-Paket die Funktion next_item_type, mit deren Hilfe Sie den Datentyp der empfangenen Information ermitteln können, wobei Sie die Bedeutung der von dieser Funktion zurückgelieferten Ergebnisse der Tabelle 5.14 entnehmen können: := dbms_pipe.next_item_type; next_item_type

Beschreibung

0

Keine Informationen vorhanden, Pipe ist leer.

6

Ergebnis ist vom Datentyp number.

9

Ergebnis ist vom Datentyp varchar2.

12

Ergebnis ist vom Datentyp date.

Tabelle 5.14: Bedeutung der von nest_item_type gelieferten Ergebnisse

Arbeitsweise der öffentlichen Pipes Wenn Sie nun mit der Arbeitsweise der Pipes ein wenig experimentieren möchten und die beiden Beispiele 5.28 und 5.29 in der vorliegenden Weise verwenden wollen, dann sollten Sie zunächst einmal das Skript 5.28 mit Hilfe einer entsprechenden Sitzung (einmal) ausführen. Anschließend müssen Sie das Skript 5.29 mit Hilfe einer anderen Sitzung ausführen und erhalten die entsprechende Bildschirmausgabe:

450


Statement processed. Ich bin da

Wenn Sie das Skript 5.29 nun noch einmal ausführen, dann hängt Ihr SQL-Editor anschließend scheinbar, wobei das daran liegt, dass Ihr Skript die nächsten 1000 Tage auf Nachrichten in der Pipe „Hallo“ wartet. Also lassen Sie es nicht so lange warten, und starten das Skript 5.28 noch einmal, wodurch auch das in der anderen Sitzung laufende Programm sofort beendet wird. Neben der Erkenntnis, dass also auch ein wartender Prozess die für die Kommunikation verwendete Pipe eröffnen kann, bestätigt dieses Beispiel die grundsätzliche Arbeitsweise einer Pipe. Man kann sich das Ganze also wirklich als eine Art Pipeline vorstellen, in der auf der einen Seite jemand etwas einfüllt, was auf der anderen Seite entnommen wird, denn mit dem Abrufen von Informationen aus der Pipe werden diese dort gelöscht. Sie können dies noch einmal überprüfen, indem Sie das Beispiel 5.28 mehrmals hintereinander starten. Anschließend können Sie auch das Skript 5.29 entsprechend häufig aufrufen und erst nach einem nochmaligen Aufruf hängt die zugehörige Sitzung wieder, weil das Programm auf Nachrichten wartet. Verwenden privater Pipes Die Verwendung der privaten bzw. expliziten Pipes unterscheidet sich im eigentlichen Gebrauch nicht von der eben beschriebenen öffentlichen Varianten. Der wesentliche Unterschied besteht eigentlich darin, dass Sie die Pipe mit Hilfe einer speziellen Funktion anlegen müssen: := dbms_pipe.create_pipe( [, Größe]);

Der hierbei verwendete Name muss in der Datenbankinstanz eindeutig sein, d.h. der Anlageversuch schlägt fehl, wenn der Name schon für eine andere private oder öffentliche Pipe verwendet wird. Optional können Sie bei der Anlage auch wieder die maximale Größe des Meldungspools festlegen, wobei das Paket standardmäßig die in der Konstante maxpipesize gespeicherte Anzahl von Bytes (z.Zt. 8192) verwendet. Sofern die Anlage der neuen Pipe erfolgreich funktioniert entspricht der zurückgelieferte Wert der Zahl 0. Alle anderen Ergebnisse stehen für einen entsprechenden Fehler. Was für die Anlage gilt, ist entsprechend auf für die Löschung der Pipe anzuwenden, d.h. auch hier müssen Sie die Pipe wieder manuell aus dem System entfernen: := dbms_pipe.remove_pipe();

Hierzu übergeben Sie der remove_pipe-Funktion den Namen der zu löschenden Pipe und erhalten als Ergebnis die Zahl 0, wenn der Löschvorgang erfolgreich ausgeführt werden konnte. Verwalten der Pipes Zur Verwaltung der Pipes gibt es zwei interessante Funktionen im dbms_pipe-Paket. Die erste dieser beiden Funktionen heißt purge und führt zum Löschen aller in der


451

Pipe enthaltenen Nachrichten. Hierzu benötigt die Prozedur als Parameter den Namen der Pipe und, sofern es sich bei dieser um eine öffentliche Pipe handelt, wird sie nach dem Löschen aller Inhalte in einem zweiten Schritt ebenfalls automatisch vom System gelöscht. dbms_pipe.purge();

Die zweite Prozedur dient zum Löschen des lokalen Zwischenpuffers und heißt reset_buffer. dbms_pipe.reset_buffer;

Das Problem ist nämlich, dass wenn Sie den Puffer einmal mit Hilfe der Prozedur dbms_pipe.pack_message bestücken, dann können Sie dies nicht so ohne weiteres rückgängig machen, denn das nochmalige Ausführen der Prozedur packt eine weitere Nachricht in Puffer und führt nicht zum Überschreiben der dort bereits gespeicherten Informationen.

5.1.12 Verwenden von PL/SQL Zum Abschluss dieser PL/SQL-Einführung möchte ich noch einmal zusammenfassen, an welchen Stellen bzw. in welchen Objekten üblicherweise PL/SQL-Elemente verwendet werden und wie diese Objekte erstellt werden. Skripte Eine einfache Möglichkeit zur Verwendung von PL/SQL-Befehlen besteht in der Erstellung eines Skripts, das in der einfachsten Form aus genau einem Programmblock besteht, wobei auch die meisten der in diesem Buch gezeigten Beispiele auf einem solchen Skript basierten. In der Praxis können solche Skripte natürlich mit Hilfe einer der vorhandenen SQL-Editoren abgespielt werden. Aber auch in allen anderen Anwendungen, mit denen Sie gewöhnliche SQL-Abfragen an die Datenbank schicken können, besteht meistens die Möglichkeit ein Skript in Form eines PL/SQL-Blocks zu verwenden, wobei Sie in dem folgenden Listing 5.30 noch einmal dessen grundsätzliche Struktur finden. declare begin end; Listing 5.30: Struktur eines einfachen PL/SQL-Skripts

Funktionen Die selbsterstellten Funktionen enthalten üblicherweise PL/SQL-Sprachelemente, mit denen innerhalb der Funktion komplexe Berechnungen oder, in Abhängigkeit verschiedener Bedingungen, unterschiedliche Datenbankabfragen durchgeführt werden. Das in einer Funktion gekapselte Miniprogramm kann anschließend bei

452


entsprechenden Zugriffsrechten innerhalb gewöhnlicher SQL-Abfragen oder bei der Erstellung andere PL/SQL-Programme verwendet werden. In diesem Workshop finden Sie im Kapitel 2.2.4 eine ausführliche Einführung in die Erstellung und Verwendung von selbsterstellten Funktionen. Daher ist das Listing 5.31 auch nur als Gedächtnisstütze zu verstehen, wie eine derartige Funktion für die meisten Aufgabenstellungen realisiert werden kann. create or replace function (<Parameterliste>) return is ; begin end; Listing 5.31: Grundsätzlicher Aufbau einer selbsterstellten Funktion

Prozeduren Wenn das erstellte Miniprogramm keinen speziellen Rückgabewert zurückliefern soll, dann wird aus der Funktion eine Prozedur. Damit beschränkt sich die Verwendbarkeit des Prozedurprogramms auf die direkte Ausführung oder die Verwendung in anderen PL/SQL-Programmen. In diesem Workshop finden Sie eine ausführlich Beschreibung zur Erstellung oder Verwendung von Prozeduren im Kapitel 2.2.9; hier soll mit Hilfe des Beispiels 5.32 nur noch einmal das grundsätzliche Schema der Prozedurerstellung gezeigt werden. create or replace procedure (<Parameterliste>) is

; begin end; Listing 5.32: Schema der Prozedurerstellung

Packages Bei den sogenannten Packages handelt es sich genau genommen schon um kleinere in der Datenbank gespeicherte Anwendungen. Ein Package entsteht durch die


453

Verschmelzung von Funktionen und Prozeduren zu einer Einheit, was aus folgenden Gründen sinnvoll sein kann:

X X

Im Falle einer gesamten Anwendung, die intern aus vielen einzelnen Funktionen und Prozeduren besteht, soll nur die Startfunktion nach außen sichtbar sein, d.h. alle anderen Routinen sollen nicht außerhalb des Pakets aufgerufen werden. Zusammenfassung von Funktionen und Prozeduren zu einer logischen Einheit, wie zum Beispiel dem Paket dbms_sql, in dem alle Funktionen und Prozeduren zur Erstellung dynamischer SQL-Anweisungen zusammengefasst sind. Das fördert in der Datenbank nicht nur die Übersicht über die insgesamt vorhandenen Programmobjekte, sondern vereinfacht auch die Erstellung wiederverwendbarer Programmteile, und auch deren Verteilung in andere Datenbanken.

Ein Package besteht aus einer Art Schnittstelle, in dem alle nach außen sichtbaren Funktionen und Prozeduren deklariert werden und dem eigentlichen Programmteil, der sich in einem zweiten Objekt, dem Package body befindet, d.h. hier findet die eigentliche Programmierung der im Package deklarierten Objekte statt. Werden im Package body zusätzliche Funktionen oder Prozeduren erstellt, so sind die nach außen unsichtbar, können also nur innerhalb des Pakets aufgerufen werden. In diesem Workshop haben wir die Pakete im Kapitel 2.2.8 behandelt und dabei auch entsprechende Beispiele erstellt. Das nun folgende Beispiel 5.33 soll noch einmal an das Schema erinnern, wie solche Packages grundsätzlich angelegt werden. create or replace package <Paketname> as -- Deklaration aller sichtbaren Funktionen, -- Prozeduren und globalen Variablen function (<Parameterliste>) return ; procedure (<Parameterliste>); end; / create or replace package body <Paketname> as -- Deklarieren lokaler Funktionen und Prozeduren function (<Parameterliste>) return ); procedure (<Parameterliste>); -- Erstellen der öffentlichen Objekte function (<Parameterliste>) return ) is ... übliches Schema zum erstellen einer Funktion end; procedure (<Parameterliste>) is ... übliches Schema zum erstellen einer Prozedur end; -Programmieren der lokalen Funktionen und Prozeduren

454


begin -- Programmieren eines Initialisierungsteils, der beim -- Laden des Pakets ausgeführt wird. end; Listing 5.33: Schema zum Programmieren eines Packages

Trigger Bei den Triggern handelt es sich um die letzte Kategorie von Datenbankobjekten, bei denen üblicherweise PL/SQL-Sprachelemente zum Einsatz kommen. Bei den Triggern handelt es sich um Programme, die beim Ausführen bestimmter Transaktionen automatisch gestartet werden. Hierzu wird ein solches Programm einer Datenbanktabelle und einer oder mehreren Änderungstransaktionen zugeordnet. Auf diese Weise können Sie für eine bestimmte Tabelle beispielsweise ein Programm erstellen, dass immer dann ausgeführt wird, wenn in dieser Tabelle eine neuer Datensatz eingefügt wird. In unserem Workshop werden die Trigger und ihre Funktionsweise im Kapitel 2.2.18 ausführlich behandelt, so dass hier (vgl. Listing 5.34) nur noch einmal an das Schema zu ihrer Erstellung erinnert werden soll. create or replace trigger before|after on begin end; Listing 5.34: Schema zur Erstellung von Datenbanktriggern

5.2

Anwendungsbeispiele

Nach dieser Einführung in die PL/SQL-Programmierung möchte ich dieses Thema noch mit Hilfe einiger Anwendungsbeispiele abrunden. Die dabei gezeigten Beispiele sind natürlich lauffähig, müssen in Produktivbedingungen jedoch sicherlich erweitert bzw. angepasst werden, d.h. es handelt sich hierbei nicht um fertige wiederverwendbare Tools, sondern um Anregungen für Ihre eigene Entwicklungsarbeit.

5.2.1

Benutzerverwaltung

Im Rahmen des vierten Kapitels haben Sie gesehen, wie Sie neue Datenbankbenutzer anlegen und deren Zugriffsrechte verwalten können. Zwar können diese Arbeiten mit Hilfe der vorhandenen Werkzeuge vollständig erledigt werden, jedoch ist

Anwendungsbeispiele

455

das gigantische Arbeit, sofern die Datenbank über entsprechend viele Tabellen besitzt und die Fachabteilung viele Benutzerkennungen mit vor allem unterschiedlichen Zugriffsprofilen fordert. Dabei kann man die Benutzer und die zugehörige Rechteverwaltung oftmals schon mit einfachen Maßnahmen dramatisch unterstützen, was im Rahmen dieses Beispiels gezeigt werden soll. Konkret geht es hier um die Verwaltung von Zugriffsrechten, die mit Hilfe einer entsprechenden Tabelle definiert und anschließend durch den Aufruf einer Prozedur erstellt bzw. aktualisiert werden können. Diese Tabelle nennen wir in unserem Beispiel benutzer_rechte und kann mit Hilfe des Listings 5.35 erzeugt werden; die Bedeutung der einzelnen Spalten können Sie der Tabelle 5.15 entnehmen und das Listing 5.36 dient zum Einfügen eines Zugriffsprofils für den Benutzer „ubeipsiel1“. drop table benutzer_rechte; / create table benutzer_rechte ( benutzer varchar2(30) not null, record varchar2(30) not null, typ char(1) default 'E' not null, aendern char(1) default 'N' not null, constraint b_r_typ check (typ in ('E','G')), constraint b_r_aendern check (aendern in ('N','Y')), constraint benutzer_rechte_pk primary key (benutzer, record) using index tablespace indx storage (initial 10K next 10K) ) tablespace usr storage (initial 10K next 10K); / commit; Listing 5.35: Tabelle zum Speichern der gewünschten Zugriffsrechte

Spalte

Bedeutung

benutzer

Benutzer oder Gruppe, für die der jeweilige Zugriff eingestellt werden soll.

record

Datensatz oder Datensatzgruppen (z.B. „pers%“), für die Zugriffsrechte erteilt werden sollen.

typ

legt fest, ob es sich um einen einzelnen Datensatz „E“ oder eine Satzgruppe „G“ handelt.

aendern

bestimmt, ob die jeweiligen Datensätze auch geändert „Y“ werden dürfen.

Tabelle 5.15: Aufbau der Tabelle benutzer_rechte

456


insert into benutzer_rechte values ('UBEISPIEL1', 'PERSONALIEN', 'E', 'Y'); insert into benutzer_rechte values ('UBEISPIEL1','L%','G','N'); insert into benutzer_rechte values('UBEISPIEL1','B%','G','N'); commit; Listing 5.36: Einfügen des Zugriffsprofils für den Benutzer „ubeispiel1“

Das Programm Die Programmierung der benötigten Funktionen erfolgt mit Hilfe eines Packages, das Sie mit Hilfe des Listings 5.37 anlegen können und das insgesamt zwei sichtbare Prozeduren enthält. Die erste Prozedur heißt create_user und dient zur Anlage bzw. Aktualisierung einer einzelnen Benutzerkennung, wohingegen die zweite Prozedur zur Aktualisierung aller Benutzer dient, was beispielsweise nach umfangreichen Datenbankwartungen hilfreich ist. Die Ausprogrammierung der einzelnen Prozeduren können Sie dem Listing 5.38 entnehmen. create or replace package benutzer as procedure create_user(userid in varchar2); procedure create_all_user; end; Listing 5.37: Definition des Pakets zur Benutzerverwaltung

create or replace package body benutzer as /* -----------------------------------------------------------------Löschen vorhandener Zugriffsberechtigungen -------------------------------------------------------------------*/ procedure revoke_objects(userid in varchar2) as -- 'gedachtes' declare cursor revoke_objects is select distinct table_name from all_tab_privs where grantee = userid; cid integer; rc integer; begin cid := dbms_sql.open_cursor; for revoke_objects_rec in revoke_objects loop dbms_sql.parse(cid, 'revoke all on ' || revoke_objects_rec.table_name || ' from ' || userid, dbms_sql.native);

Anwendungsbeispiele

rc := dbms_sql.execute(cid); end loop; dbms_sql.close_cursor(cid); end revoke_objects; /* -----------------------------------------------------------------Ausführen eines grant-SQL-Befehls -------------------------------------------------------------------*/ procedure grant_sql(sql_txt in varchar2) as -- 'gedachtes' declare cid integer; rc integer; begin cid := dbms_sql.open_cursor; dbms_sql.parse(cid, sql_txt, dbms_sql.native); rc := dbms_sql.execute(cid); dbms_sql.close_cursor(cid); dbms_output.put_line(sql_txt || ' -> ok'); exception when others then dbms_output.put_line('Fehler bei ' || sql_txt); dbms_output.put_line(sqlerrm); end grant_sql; /* -----------------------------------------------------------------Anlage bzw. Aktualisieren eines einzelnen Benutzers oder einer einzelnen Gruppe. -------------------------------------------------------------------*/ procedure create_user(userid in varchar2) as -- 'gedachtes' declare cursor aktuelle_rechte is select * from benutzer_rechte where benutzer = userid order by typ desc; cursor records (in_record varchar2) is select table_name from all_tables where table_name like in_record union

457

458


select view_name from all_views where view_name like in_record; grant_txt varchar2(255):=' '; begin -- Löschen aller vorhandenen Zugriffsrechte revoke_objects(userid); -- Alle Datensätze des Profils bearbeiten for aktuelle_rechte_rec in aktuelle_rechte loop if aktuelle_rechte_rec.aendern = 'Y' then grant_txt := 'grant all on '; else grant_txt := 'grant select on '; end if; if aktuelle_rechte_rec.typ = 'E' then grant_sql(grant_txt || aktuelle_rechte_rec.record || ' to ' || userid); else for records_rec in records(aktuelle_rechte_rec.record) loop grant_sql(grant_txt || records_rec.table_name || ' to ' || userid); end loop; end if; end loop; commit; end create_user; /* -----------------------------------------------------------------Aktualisieren aller Benutzer und Rollen -------------------------------------------------------------------*/ procedure create_all_user as -- 'gedachtes' declare cursor alle_benutzer is select distinct benutzer from benutzer_rechte; begin for alle_benutzer_rec in alle_benutzer loop create_user(alle_benutzer_rec.benutzer); end loop;

Anwendungsbeispiele

459

end create_all_user; /* -----------------------------------------------------------------Initialisierungsteil -------------------------------------------------------------------*/ begin dbms_output.enable(50000); end benutzer; Listing 5.38: Programm zur automatischen Generierung von Benutzerrechten

Je nachdem, ob Sie die Rechte für einen einzelnen Benutzer oder ob Sie alle gespeicherten Benutzerrechte aktualisieren möchten, müssen Sie die Prozedur create_user oder create_all_users starten, was durch folgende execute-Anweisung möglich ist: execute benutzer.create_user('UBEISPIEL1'); execute benutzer.create_all_users;

Programmbeschreibung Beginnen wir bei der Beschreibung mit der Prozedur create_all_users. Diese Prozedur verwendet den Cursor alle_benutzer, mit dem die Namen aller in der Tabelle benutzer_rechte gespeicherten Benutzer- bzw. Rollennamen selektiert werden. Innerhalb der Prozedur wird dieser Cursor mit Hilfe einer for loop-Schleife durchlaufen und für jeden gefundenen Namen wird die Prozedur create_user aufgerufen. Die Prozedur create_user erhält beim Aufruf die Kennung des zu aktualisierenden Benutzers, egal ob sie direkt oder aus der create_all_users-Prozedur heraus aufgerufen wird. Innerhalb dieser Prozedur rufen wir im ersten Schritt die Prozedur revoke_objects auf, mit der dem übergebenen Benutzer zunächst einmal alle eventuell zugeteilten Zugriffsrechte entzogen werden. Anschließend durchläuft die Prozedur mit Hilfe einer Schleife den Cursor aktuelle_rechte, der für den aktuellen Benutzer eine Selektion der für ihn in der Tabelle benutzer_rechte gespeicherten Datensätze liefert. Innerhalb dieser Schleife wird zunächst in Abhängigkeit des Feldes benutzer_rechte. aendern der Anfang einer typischen grant-Anweisung generiert und in der Variablen grant_txt gespeichert. Sofern es sich bei dem aktuellen Datensatz um eine Zugriffssteuerung vom Typ „E“ handelt, dann rufen wir die Prozedur grant_sql auf, innerhalb derer der entsprechende grant-Befehl ausgeführt wird. Hierzu geben wir der grant_sql-Funktion als Argument die vollständige Anweisung mit, die beim Aufruf entsprechend zusammengestellt wird. Handelt es sich bei dem aktuellen Datensatz um eine Gruppe, dann starten wir den anderen Cursor records, der die Namen aller dem Suchmuster entsprechenden Tabellen oder Views liefert. Dabei führt auch hier jeder gefundenen Datensatz zu einem Aufruf der grant_sql-Prozedur, um die entsprechende grant-Anweisung abzusetzen.

460


Innerhalb der grant_sql-Prozedur wird der übergebene grant-Befehl mit Hilfe einer dynamsichen SQL-Anweisung ausgeführt. Tritt dabei ein Fehler auf, beispielsweise weil der eingetragene Benutzer nicht angelegt ist, die aufgeführte Tabelle nicht existiert oder der ausführende Benutzer selbst nicht das Recht hat, die Zugriffsrechte zu erteilen, dann führt das aufgrund der programmierten exception-Routine zur Ausgabe einer entsprechenden Fehlermeldung. Mit Hilfe der Prozedur revoke_objects werden dem aktuellen Benutzer zunächst alle früher erteilten Zugriffsrechte entzogen, wobei diese mit Hilfe einer Abfrage auf die View all_tab_privs ermittelt werden. Diese Abfrage wird in der Prozedur mit Hilfe des Cursors revoke_objects ausgeführt, der innerhalb einer for loop-Schleife abgearbeitet wird, wobei für jeden gefundenen Datensatz eine entsprechende revokeAnweisung generiert und abgesetzt wird.

5.2.2

Änderungsprotokollierung

Manchmal ist es notwendig, alle in der Datenbank durchgeführten Änderungen festzuhalten, wobei neben dem zugehörigen Verursacher (Benutzerkennung, Datum und Zeit) auch der alte Zustand des Datensatzes festgehalten werden soll. Zu diesem Zwecke benötigen wir natürlich eine spezielle Protokolltabelle, in der die geänderten Datensätze festgehalten werden. Solche Protokolldateien können aus Gründen der Nachvollziehbarkeit oder auch für andere Prozesse (z.B. Schnittstellen) angelegt werden. Da mit Hilfe des Protokolls quasi ein Abbild der Zustände vor bzw. nach der Änderung entsteht, besteht die Möglichkeit, die reinen Änderungen herauszufiltern und entsprechend zu reagieren. Wir werden die Protokollierung am Beispiel der Gehaltstabelle durchführen, d.h. wir benötigen eine Tabelle, die dem Aufbau der Tabelle gehalt entspricht und zusätzlich noch verschiedene Statusfelder enthält. Statusfeld

Beschreibung

audit_userid

enthält die Benutzerkennung, die für die Datenänderung verantwortlich ist.

audit_zeit

Zeitstempel, an der die Änderung durchgeführt wurde.

audit_typ

beschreibt die durchgeführte Änderungstransaktion. A: Es wurde ein neuer Datensatz angelegt, wobei der im Protokoll befindliche Datensatz diesem neuen Satz entspricht. L: Ein Datensatz wurde gelöscht. Dabei wird der gelöschte Satz ins Protokoll gestellt. U: Ein vorhandener Satz wurde geändert, das Protokoll beinhaltet jetzt den Datensatz vor der Änderung. K: Es wurde eine Schlüsseländerung durchgeführt. Eine Schlüsseländerung wird wie eine Löschung und Neuanlage protokolliert, wobei der K-Satz den gelöschten Datensatz enthält. N: Das ist bei einer Schlüsseländerung der zweite Eintrag im Protokoll, wobei diesmal der neue bzw. geänderte Datensatz festgehalten wird.

Tabelle 5.16: Bedeutung der einzelnen Statusfelder in unserer Protokolltabelle

Anwendungsbeispiele

461

Die Protokolltabelle selbst legen wir, wie Sie im Listing 5.39 sehen, mit Hilfe eines kleinen Tricks an, indem wir die Struktur der Gehaltstabelle durch eine Abfrage und die benötigten Statusfelder mit Hilfe geeigneter Ausdrücke erzeugen. Die Abfrage gestalten wir dabei so, dass keine Datensätze selektiert werden, so dass nur die Struktur der Tabelle kopiert wird. drop table audit_gehalt; / create table audit_gehalt tablespace usr storage (initial 10K next 10K) as select user as audit_userid, sysdate as audit_zeit, 'E' as audit_typ, a.* from gehalt a where persnr = 'xx'; / alter table audit_gehalt modify ( audit_userid not null, audit_zeit not null, audit_typ not null); / commit; Listing 5.39: Anlage der Protokolltabelle

Das Programm Die Programmierung dieser Aufgabenstellung erfolgt mit Hilfe eines Triggers. Dieser Trigger soll nach Durchführung der Änderung für jeden Datensatz gestartet werden, so dass wir mit Hilfe recht einfacher SQL-Anweisungen die benötigten Protokollsätze erzeugen können. Das Muster für einen solchen Trigger finden Sie in dem nachfolgenden Beispiel 5.40. create or replace trigger audit_gehalt after update or insert or delete on gehalt for each row declare i_flag char(1); d_flag char(1); begin if updating('PERSNR') or updating('LFDNR') or updating('GAB') then i_flag := 'N'; d_flag := 'K'; else

462


i_flag := 'A'; if deleting then d_flag := 'L'; else d_flag := 'U'; end if; end if; -- Einfügetransaktion oder Ändern des Primärschlüssels if inserting or i_flag = 'N' then insert into audit_gehalt values (user, sysdate, i_flag, :new.persnr, :new.lfdnr, :new.gab, :new.kst, :new.gehalt, :new.zulage); end if; -- Bei allen Änderungen werden die alten (:old) Werte protokolliert if deleting or updating then insert into audit_gehalt values (user, sysdate, d_flag, :old.persnr, :old.lfdnr, :old.gab, :old.kst, :old.gehalt, :old.zulage); end if; end; Listing 5.40: Verwenden eines Triggers zur Änderungsprotokollierung

Programmbeschreibung Bei einer solchen Aufgabenstellung handelt es sich um ein Paradebeispiel für einen Trigger, der nach Durchführung der Datenänderungen ausgeführt werden soll. Kommt es vor oder während der Änderungen, beispielsweise wegen eines VorabTriggers oder einer Constraint-Verletzung zum Abbruch der Transaktion, so wird dieser Trigger erst gar nicht mehr gestartet, d.h. es kommt auch nicht zum Erzeugen der Protokollsätze. Der Trigger, der mit dem Namen audit_gehalt für die Tabelle gehalt erstellt wird, wird aufgrund der verwendeten Klauseln after update or insert or delete on gehalt for each row

von der Datenbank automatisch nach jeder Änderungstransaktion für jeden betroffenen Datensatz gestartet. Da wir nichts anderes vorgeben stehen uns somit die alten und neuen Werte des geänderten Datensatzes mit Hilfe der Bindungsvariablen :old und :new zur Verfügung. Normalerweise führt jede Datensatzänderung zu einem entsprechendem Eintrag in der Protokolltabelle. Dabei wird mit Ausnahme der neu eingefügten Datensätze immer der Wert vor der Änderung im Protokoll gespeichert. Ebenfalls eine Ausnahme stellt die Durchführung einer Schlüsseländerung dar, da in dem Fall zwei Datensätze in das Protokoll geschrieben werden.

Anwendungsbeispiele

463

Das ist der einzige Grund, warum wir innerhalb des Triggerprogramms überhaupt Programmlogik benötigen und die vom Trigger bereitgestellten Änderungsdaten nicht einfach an die Protokolltabelle weiterleiten können. Konkret überprüfen wir als Erstes, ob eines der drei Primärschlüsselfelder geändert wurde und setzen in dem Fall die beiden Protokollcodes „N“ und „K“ in die entsprechenden Variablen i_flag bzw. d_flag. if updating('PERSNR') or updating('LFDNR') or updating('GAB') then i_flag := 'N'; d_flag := 'K'; else i_flag := 'A'; if deleting then d_flag := 'L'; else d_flag := 'U'; end if; end if;

In den anderen Fällen speichern wir je nachdem ob Datensätze angelegt, gelöscht oder geändert wurden die Codes „A“, „L“ oder „U“ in den Variablen. Im nächsten Schritt erfolgt das Anlegen der Protokollsätze. Dabei müssen die neuen Daten der Gehaltstabelle ins Protokoll kopiert werden, wenn entweder neue Datensätze eingefügt wurden oder eine Primärschlüsseländerung vorliegt, was man jetzt mit Hilfe der Variablen i_flag erkennen kann. -- Einfügetransaktion oder Ändern des Primärschlüssels if inserting or i_flag = 'N' then

In allen anderen Fällen müssen die :old-Werte in das Protokoll übertragen werden, wobei aufgrund der Programmstruktur bei einer Schlüsseländerung beide if-Zweige durchlaufen werden. -- Bei allen Änderungen werden die alten (:old) Werte protokolliert if deleting or updating then

In allen Fällen erfolgt die Bestückung der zusätzlichen Protokollspalten audit_userid und audit_zeit mit Hilfe der Systemfunktionen user und sysdate. Wenn Sie nun einmal nacheinander die im Listing 5.41 gezeigten Änderungstransaktionen ausführen, dann können Sie anschließend die Funktionsweise des Triggers mit Hilfe der Protokolleinträge kontrollieren. update gehalt set gehalt = 7455 where persnr = '7000188'; insert into gehalt values ('7000188', 0, to_date('01.01.2001','DD.MM.YYYY'), 'MARK', 6400, 300);

464


update gehalt set gab = to_date('01.04.2001','DD.MM.YYYY') where persnr = '7000188' and gab < to_date('01.01.2002','DD.MM.YYYY'); delete gehalt where persnr = '7000188' and gab < to_date('01.01.2002','DD.MM.YYYY'); Listing 5.41: Ausführen verschiedener Änderungstransaktionen

Wie Sie nun der Protokolltabelle bzw. dem Listing 5.42 entnehmen können, werden ab jetzt alle Änderungen der Gehaltstabelle einwandfrei aufgezeichnet. SQLWKS> 2> 3> 4> 5> 6>

select audit_userid, to_char(audit_zeit,'DD.MM.YYYY HH24:MI:SS'), audit_typ, persnr, lfdnr, gab, kst, gehalt, zulage from audit_gehalt where persnr = '7000188' order by 2

AUDIT_USERID TO_CHAR(AUDIT_ZEIT, A PERSNR LFDNR GAB KST GEHALT ZULAGE ------------------- ------------------- ----------- ---------- ---------------- ---------- ---------- --------UBEISPIEL 04.10.2000 18:46:41 U 7000188 0 01-JAN-07 MARK 6240 250 UBEISPIEL 7000188

04.10.2000 19:18:04 A 0 01-JAN-01 MARK

6400

300

UBEISPIEL 7000188

04.10.2000 19:18:04 N 0 01-APR-01 MARK

6400

300

UBEISPIEL 7000188

04.10.2000 19:18:04 K 0 01-JAN-01 MARK

6400

300

UBEISPIEL 7000188 5 rows selected.

04.10.2000 19:18:04 L 0 01-APR-01 MARK

6400

300

Listing 5.42: Auswertung des Änderungsprotokolls

Wie Sie dem Protokoll entnehmen können, wurde zunächst um 18:46 eine Datensatzänderung durchgeführt, wobei das Protokoll die alten Tabellenwerte anzeigt. Anschließend wurde um 19:18 ein neuer Datensatz zum 01.01.2001 angelegt, der anschließend auf den 01.04.2001 verschoben und danach gelöscht wurde. Dabei kann man die letzten Transaktion natürlich nicht mehr anhand des Zeitstempels unterscheiden, wenn sie, so wie bei mir, innerhalb einer Abfrage ausgeführt werden. Sofern das bei der konkreten Aufgabenstellung ein Problem darstellt, dann müssen Sie die Protokolltabelle noch um ein weiteres Feld erweitern, in dem Sie

Anwendungsbeispiele

465

beispielsweise eine laufende Nummer mit Hilfe einer Sequence (vgl. Kapitel 2.2.12) speichern. Werden solche Protokolltrigger im größeren Umfang, d.h. für viele Tabellen, gebraucht, dann würde ich mir wiederum eine Prozedur oder ein Paket erstellen, dass die Trigger oder zumindest den benötigten Triggercode automatisch generiert. Hierzu könnte man sich wieder eine Arbeitstabelle anlegen, in der man die Tabellen nebst zugehöriger Protokolltabelle speichert. Wie Sie gesehen haben, sind die meisten Anweisungen im Triggerprogramm konstant, d.h. die einzelnen Trigger unterscheiden sich eigentlich nur durch die abgeprüften Primärschlüsselfelder und durch die konkret verwendete insert-Anweisung zum Erstellen des Änderungsprotokolls. Im Kapitel 3.5.1 dieses Workshops haben Sie ein Muster gesehen (vgl. Listing 3.44), wie Sie mit Hilfe einer speziellen Abfrage die Struktur einer Tabelle und damit den String für die values-Liste erzeugen könnten. Im Beispiel 3.47 (gleiches Kapitel) finden Sie ein Muster dafür, wie Sie die im Primärschlüssel vorhandenen Felder ermitteln können, so dass Sie ebenfalls in der Lage sind, die benötigten updating-Prüfungen zu generieren.

5.2.3

Komplexe Integritätsbedingungen

Wie Sie schon wissen, können Integritätsbedingungen manchmal mit Hilfe der sogenannten Constraints in der Datenbank angelegt werden. Das gilt auch dann, wenn die Entscheidung über die Ordnungsmäßigkeit eines Datensatzes von der Existenz eines Satzes aus einer anderen Tabelle (vgl. Abb. 2.13) abhängt. Auch solche referentiellen Integritätsbedingungen können im Rahmen der Tabellendefinition mit Hilfe der foreign key-Klausel angelegt werden, weshalb man in dem Zusammenhang auf von der deklarativen referentiellen Integrität spricht. Manchmal sind die Datenstrukturen allerdings ungeeignet oder die Prüfroutinen so komplex, dass die zugehörigen Regeln nicht mit Hilfe gewöhnlicher Constraints abgebildet werden können. In solchen und anderen Fällen können Ihnen Trigger weiterhelfen, da Sie hierbei als Prüfroutine komplexe PL/SQL-Programme erstellen können. Damit sind nicht mehr die enge formale Struktur einer Constraint-Klausel, sondern nur noch die Komplexität und eventuell die Laufzeit der erstellten Prüfregel Ihre Gegner. Automatisches Löschen Als erstes Beispiel zu diesem unerschöpflichen Themenkomplex wollen wir uns mit dem kaskadierenden Löschen voneinander abhängiger Datensätze beschäftigen. Betrachen Sie hierzu zunächst einmal die Abbildung 5.2, in der Sie noch einmal einen Ausschnitt unserer Datenbankstruktur finden.

466


personalien (persnr)

bvs (persnr, lfdnr)

lohnarten

gehalt

(persnr, lfdnr, gab)

(persnr, lfdnr, gab)

Abbildung 5.2: Auszug der Musterdatenbank mit der Struktur der Stammdatentabellen

Die nun folgende erste Aufgabe besteht also darin, beim Löschen eines Datensatzes auch die jeweils abhängigen Sätze automatisch mit Hilfe geeigneter Trigger zu löschen. Als Erstes programmieren wir nun den benötigten Löschtrigger für die Tabelle personalien (vgl. Beispiel 5.43), in dem wir nichts weiter zu tun brauchen, als für die gelöschte Personalnummer eine Löschanweisung auf die bvs-Tabelle abzusetzen. create or replace trigger personalien_delete after delete on personalien for each row begin delete bvs where persnr = :old.persnr; end; Listing 5.43: Löschweitergabe an abhängige Personalstamm-Tabellen

Das zweite Beispiel 5.44 ist natürlich genauso einfach, denn beim Löschen eines Datensatzes der bvs-Tabelle geben wir den Löschbefehl an die Tabellen lohnarten und gehalt weiter. create or replace trigger bvs_delete after delete on bvs for each row begin delete lohnarten where persnr = :old.persnr and lfdnr = :old.lfdnr; delete gehalt where persnr = :old.persnr and lfdnr = :old.lfdnr; end; Listing 5.44: Löschweitergabe an bvs-abhängige Tabellen

Anwendungsbeispiele

467

Prüfbedingungen Nachdem wir nun die Löschabhängigkeiten mit Hilfe eines Triggers realisiert haben, geht es im zweiten Schritt darum, mit Hilfe dieses Features eine Prüfbedingung zu erstellen. Konkret möchte ich das am Beispiel der Kostenstellen- und Gehaltstabelle demonstrieren, die durch das gemeinsame Feld kst miteinander verbunden sind. Bei solchen Prüfbedingungen tut man nach meiner Erfahrung gut daran, die gewünschten Regelwerke nach den Kategorien falsch und unerwünscht zu unterscheiden, wobei die folgenden Bedingungen sicherlich zur ersten Kategorie gehören:

X

X X

Verwenden einer Kostenstelle zu einem Gültigkeitstermin, an dem diese noch gar nicht definiert ist, d.h. es gilt gehalt.gab < min(kostenstelle.gab). Dieser Effekt muss auch verhindert werden, wenn das Gültigkeitsdatum der Kostenstelle im Nachhinein verändert wird. Löschen einer Kostenstelle, wenn diese noch in irgendeinem Gehaltsdatensatz verwendet wird. Dahingegen ist es lediglich unerwünscht, inaktive (status = „I“) Kostenstellen in aktuellen Gehaltsdatensätzen zu verwenden. Dies unterstreicht man in einer konkreten Anwendung sicherlich dadurch, dass der Dialog in Abhängigkeit der Gültigkeit des Gehaltsdatensatzes nur aktive Kostenstellen anzeigt oder beim Speichern einer Gehaltsänderung eine Hinweismeldung generiert, dass die aktuelle Kostenstelle zur Zeit eigentlich inaktiv ist.

Werden solche Regeln, die im Normalfall zwar beachtet und im Ausnahmefall aber genauso gut umgangen werden dürfen, entsprechend restriktiv in der Datenbank abgelegt, dann erhält man schnell Systeme, die eigentlich nur noch dann funktionieren, wenn niemand mehr Änderungen eingibt. Würde man in unserem Beispiel versuchen, die Benutzung inaktiver Kostenstellen restriktiv zu verhindern, dann müssten Sie sich mit folgenden Herausforderungen beschäftigen:

X

X

Unsere bisherigen Abfragen, in denen wir abhängige Datensätze mit Hilfe von max-Unterabfragen selektiert haben, spiegeln genau genommen immer nur eine Zeitpunktsbetrachtung wieder. Die Prüfung solcher Bedingungen muss aber immer über ganze Zeiträume erfolgen, denn obwohl die Kostenstelle zum aktuellen Gehaltstermin noch gültig ist, kann sie ja schon ab morgen auf inaktiv gesetzt sein. Prüfungen müssten also immer vom Gültigkeitstermin des geänderten Datensatzes bis zum implizit vorgegebenen Gültig-bis-Datum, das sich durch eine eventuell folgende Historie ergibt, durchgeführt werden. Soll die Verwendung inaktiver Sätze also wirklich restriktiv verhindert werden, so muss dies schon beim Design des Datenmodells berücksichtigt werden, wobei unser Datenmodell hierfür eigentlich nicht geeignet ist. Alternativ kann natürlich auch die Möglichkeit zur Durchführung von Datenänderungen mit Hilfe von Änderungsabfragen verzichtet werden und stattdessen werden alle Änderungen mit Hilfe von Prozeduren durchgeführt, die alle neuen Werte als Parameter erhalten. Mit Hilfe solcher Prozeduren wäre es auch in unserem Datenmodell möglich, die Verwendung inaktiver Sätze zu verhindern.

468

X


Scheinbare Verstöße gegen die Verwendung inaktiver Kostenstellen sind bei genauerer Betrachtung manchmal gar keine. Betrachtet man nur die Gehaltsdaten, so wird dort wegen einer fehlenden Historie noch eine inaktive Kostenstelle verwendet. Da der Mitarbeiter aber vielleicht schon seit langem ausgetreten ist, bedeutet dies, dass auch die Gehaltshistorie eigentlich inaktiv ist, was aber erst durch Hinzuziehung weiterer Datensätze (z.B. bvs-Tabelle) festgestellt werden kann. Somit müssten auf einmal auch die Beschäftigungsdaten die Kostenstellenintegrität überwachen, obwohl diese Tabelle eigentlich gar nichts mit den Kostenstellen zu tun hat. In der Praxis sind solche Abhängigkeiten häufig unvorstellbar komplex. Man hat es praktisch mit einer Art Spinnennetz zu tun, wobei die Regel in der Mitte sitzt und von allen Seiten am Netz gezogen und gerüttelt wird.

Aus den soeben geschilderten Gründen sollen die hier vorgestellten Trigger natürlich nur dazu dienen, echte Fehler zu verhindern. Dabei beginnen wir im Beispiel 5.45 mit der Gehaltstabelle und erstellen einen Trigger, der die Verwendung ungültiger Kostenstellen verhindert. create or replace trigger gehalt_kst after insert or update of gab on gehalt for each row declare ct integer; begin select count(*) into ct from bvs b, kostenstelle a where b.persnr = :new.persnr and b.lfdnr = :new.lfdnr and a.unternehmen = b.unternehmen and a.kst = :new.kst and gab = (select max(gab) from kostenstelle a1 where a1.unternehmen = a.unternehmen and a1.kst = a.kst and a1.gab k1, g2 -> k1, g3 -> k2 usw.). Würde nun die erste Kostenstellenhistorie gelöscht oder das Gültigkeitsdatum so geändert, dass es hinter dem Datum g1 liegt, dann entstünde hierdurch eine inkonsistente Situation, denn anschließend fände der erste Gehaltsdatensatz keine Kostenstelle mehr. create or replace trigger kostenstelle_kst before delete or update of unternehmen, kst, gab on kostenstelle for each row declare ct integer; begin select count(*) into ct from gehalt a, bvs b where b.persnr = a.persnr and b.lfdnr = a.lfdnr and b.unternehmen = :old.unternehmen and a.kst = :old.kst and not exists(select 1 from kostenstelle c where c.unternehmen = :old.unternehmen

470


and c.kst = :old.kst and c.gab 0 then raise_application_error(-20000,'Kostenstellenänderungen wegen vorhandener Verknüpfungen nicht möglich.'); end if; end; Listing 5.46: Überwachung der Konsistenz beim Löschen einer Kostenstelle

Im Rahmen des Triggerprogramms analysieren wir einfach den Datenbestand dahingehend, ob es Gehaltsdatensätze gibt, für die es keine passende Kostenstelle gibt, was wir mit Hilfe einer entsprechenden not exists-Unterabfrage ermitteln. Was beim Test des Programms allerdings dabei herauskommt, dass können Sie dem Listing 5.47 entnehmen. delete kostenstelle where kst = 'PSOFT'; ORA-04091: table SYSTEM.KOSTENSTELLE is mutating, trigger/function may not see it Listing 5.47: Das mutating-Syndrom

Das Problem besteht nämlich darin, dass Sie innerhalb eines satzweise arbeitenden Triggers die zugrundeliegende Tabelle selbst nicht lesen dürfen. Falls Sie es bei der Programmierung doch einmal tun, dann erhalten Sie bei der Ausführung des Triggers die eben gezeigte Fehlermeldung, wobei dabei das weitere Dilemma darin besteht, dass Sie nur mit erheblichen Programmieraufwand aus dieser Zwickmühle herauskommen. Bevor ich nun zu einem konkreten Lösungsvorschlag komme, möchte ich noch einmal auf das Ausführungsschema der verschiedenen Triggertypen zurückkommen. Wie Sie wissen, unterscheiden sich die einzelnen Trigger zum einen durch den Zeitpunkt ihrer Ausführung und zum anderen dadurch, ob Sie für die zugehörige Transaktion oder für jeden betroffenen Datensatz ausgeführt werden, was insgesamt zu folgendem Ausführungsschema führt: 1. Ausführung aller Vorab-Trigger, die nicht für jeden einzelnen Datensatz gestartet werden sollen. 2. Durchlaufen aller im Rahmen der Transaktion selektierten Datensätze. –

Ausführung aller datensatzbezogenen Vorab-Trigger.

–

Ändern, Löschen, Einfügen des Datensatzes entsprechend des SQL-Befehls. Durchführen alle vorhandenen Constraint-Prüfungen.

–

Ausführung aller datensatzbezogenen Danach-Trigger.

3. Ausführen aller nicht datensatzbezogenen Danach-Trigger.

Anwendungsbeispiele

471

Dieses Schema und den Umstand, das wir mit Hilfe eines Packages sitzungsglobale Variablen speichern können, werden wir uns bei der Lösung des Kostenstellenproblems zu Nutze machen, indem wir diese Variablen in einem Transaktions-VorabTrigger initialisieren, uns in einem satzweise arbeitenden Danach-Trigger die geänderten Kostenstellen merken und diese im Transaktions-Danach-Trigger überprüfen. Betrachten Sie nun noch einmal die Abbildung 5.3. Augrund unseres Datenmodells besitzten die historischen Daten zwar einen echten Anfang, der vom Gültigkeitsdatum der ersten Historie bestimmt wird, gelten aus technischer Sicht anschließend aber für immer. Zwar kann eine Kostenstelle als inaktiv markiert werden, aber in dem Fall ist sie trotzdem noch vorhanden. Aus diesen Gründen müssen wir bei Kostenstellenänderungen eigentlich nur in folgenden Fällen Prüfungen durchführen:

X X

Der erste Datensatz mit dem Beginndatum „k1“ (vgl. Abb. 5.3) wird gelöscht. Das Beginndatum des ersten Datensatzes wird so verändert, dass das neue Beginndatum hinter dem alten liegt, d.h. die Kostenstelle wird insgesamt erst zu einem späteren Zeitpunkt gültig.

create or replace package kostenstelle_paket is type kst_aend is record (unternehmen kostenstelle.unternehmen%type, kst kostenstelle.kst%type, gab date ); type t_kst_aend is table of kst_aend; v_kst_aend t_kst_aend; end; Listing 5.48: Erstellen des für die Kostenstellenprüfung benötigten Pakets

Das Listing 5.48 zeigt Ihnen die Anlage des benötigten Packages. Hier definieren wir zunächst die Struktur kst_aend, die alle Primärschlüsselfelder der Kostenstellentabelle enthält. Im nächsten Schritt definieren wir für diese Struktur die dynamische Tabelle t_kst_aend, und damit wir diese neuen Typen auch benutzen können, benötigen wir zusätzlich die Variable v_kst_aend, mit deren Hilfe wir diese Tabelle in den folgenden Programmen ansprechen können. create or replace trigger kostenstelle_kst1 before delete or update of unternehmen, kst, gab on kostenstelle begin kostenstelle_paket.v_kst_aend := kostenstelle_paket.t_kst_aend(); end; Listing 5.49: Initialisieren des Packages beim Starten der Änderungstransaktion

472


Mit Hilfe des im Listing 5.49 gezeigten Vorab-Triggers wird unsere Arbeitstabelle v_kst_aend beim Start einer entsprechenden Änderungstransaktion gelöscht, indem wir der Variablen mit Hilfe des Typenkonstruktors eine leere Tabelle zuweisen. Im nächsten Schritt folgt der satzweise arbeitende Trigger, in dem wir die Schlüssel aller geänderten Datensätze speichern. create or replace trigger kostenstelle_kst2 after delete or update of unternehmen, kst, gab on kostenstelle for each row declare i integer; begin if deleting or :old.gab < :new.gab or updating('UNTERNEHMEN') or updating('KST') then kostenstelle_paket.v_kst_aend.extend(1); i:=kostenstelle_paket.v_kst_aend.count; kostenstelle_paket.v_kst_aend(i).unternehmen := :old.unternehmen; kostenstelle_paket.v_kst_aend(i).kst := :old.kst; kostenstelle_paket.v_kst_aend(i).gab := :old.gab; end if; end; Listing 5.50: Speichern der geänderten Datensätze in einem dynamischen Datenfeld

Mit Hilfe des satzweise arbeitenden Triggers speichern wir alle relevanten Datensätze in dem globalen Datenfeld. Entsprechend der gemachten Vorbemerkungen muss das beim Ändern eines Historiendatums grundsätzlich nur dann passieren, wenn das neue Datum hinter dem alten liegt. Für jeden Datensatz wird das Datenfeld v_kst_aend mit Hilfe der extend-Methode um ein Element erweitert. Den aktuellen Index können Sie jeweils mit Hilfe der count-Methode ermitteln, wobei die Verwendung der Hilfsvariablen i nur aus Gründen der besseren Lesbarkeit erfolgt. create or replace trigger kostenstelle_kst3 after delete or update of unternehmen, kst, gab on kostenstelle declare i integer; ct integer; pgab date; begin for i in 1..kostenstelle_paket.v_kst_aend.count loop dbms_output.put(kostenstelle_paket.v_kst_aend(i).unternehmen); dbms_output.put(kostenstelle_paket.v_kst_aend(i).kst); dbms_output.put(','); dbms_output.put(kostenstelle_paket.v_kst_aend(i).gab); -- Prüfen, ob die Kostenstelle geprüft werden muss

Anwendungsbeispiele

select count(*) into ct from kostenstelle where unternehmen = kostenstelle_paket.v_kst_aend(i).unternehmen and kst = kostenstelle_paket.v_kst_aend(i).kst and gab < kostenstelle_paket.v_kst_aend(i).gab; if ct > 0 then dbms_output.put(' => keine Prüfung erforderlich!'); else -------------------------------------------------------------- Die 1. Historie wurde gelöscht oder verändert. -- Das Feld gab der neuen ersten Historie ermitteln ------------------------------------------------------------select min(gab) into pgab from kostenstelle where unternehmen = kostenstelle_paket.v_kst_aend(i).unternehmen and kst = kostenstelle_paket.v_kst_aend(i).kst and gab > kostenstelle_paket.v_kst_aend(i).gab; ct := 0; if pgab is null then ---------------------------------------------------------- Die Kostenstelle wurde vollständig gelöscht. -- Prüfen, ob die Kostenstelle noch irgendwo verwendet -- wird --------------------------------------------------------dbms_output.put(' => Kostenstelle gelöscht'); select count(*) into ct from gehalt a, bvs b where b.persnr = a.persnr and b.lfdnr = a.lfdnr and b.unternehmen = kostenstelle_paket.v_kst_aend(i).unternehmen and a.kst = kostenstelle_paket.v_kst_aend(i).kst and rownum = 1; else ---------------------------------------------------------- Die erste Kostenstellenhistorie wurde gelöscht bzw. -- deren Beginndatum wurde verküzt. Das neue Beginndatum -- der ersten Historiesteht jetzt im Feld pgab. Prüfen ob -- es Gehaltsdatensätze gibt, -- die die geänderte Kostenstelle verwenden und vor pgab -- gültig sind. --------------------------------------------------------dbms_output.put(' => Neue Gültigkeit ab ' || pgab);

473

474


select count(*) into ct from gehalt a, bvs b where b.persnr = a.persnr and b.lfdnr = a.lfdnr and b.unternehmen = kostenstelle_paket.v_kst_aend(i).unternehmen and a.kst = kostenstelle_paket.v_kst_aend(i).kst and a.gab < pgab and rownum = 1; end if; if ct > 0 then dbms_output.put(' (Fehler)'); dbms_output.new_line; raise_application_error(-20000, 'Inkonsistente Kostenstelle: ' || kostenstelle_paket.v_kst_aend(i).unternehmen || kostenstelle_paket.v_kst_aend(i).kst || ', ' || kostenstelle_paket.v_kst_aend(i).gab); else dbms_output.put(' (OK)'); dbms_output.new_line; end if; end if; end loop; end; Listing 5.51: Prüfung der im Datenfeld gespeicherten Kostenstellen

Zunächst einmal werden die im Datenfeld gesammelten Kostenstellen mit Hilfe einer for loop-Schleife verarbeitet. Hierbei wird im Inneren der Schleife für jedes Element als Erstes ermittelt, ob zu der geänderten Kostenstelle noch eine Vorgängerhistorie existiert. Falls ja, dann gibt es aufgrund unserer Vereinbarungen keinen Grund mehr, in den Gehaltsdaten nach Inkonsistenzen zu suchen. Ansonsten gibt es prinzipiell zwei Möglichkeiten: Entweder die Kostenstelle wurde vollständig gelöscht oder die erste Historie wurde geändert, d.h. die Historische Linie der Kostenstelle beginnt jetzt mit einem anderen Datum. Im ersten Fall schauen wir mit Hilfe einer geeigneten Abfrage in der Datenbank nach, ob die Kostenstelle noch von irgendeinem Gehaltsdatensatz verwendet wird. Im zweiten Fall wird geprüft, ob es Gehaltsdatensätze mit der geänderten Kostenstelle gibt, die vor deren Historienbeginn liegen. In beiden Fällen wird die Transaktion mit Hilfe eines Aufrufs von raise_application_error abgebrochen, wenn entsprechende Datensätze in der Datenbank gefunden werden.

Anwendungsbeispiele

475

Wie Sie dem Listing 5.51 entnehmen können, habe ich an verschiedenen Stellen die Ausgabe von Hinweismeldungen (dbms_output) eingebaut. Diese Meldungen können Ihnen beim Test oder beim Spielen mit diesem Trigger helfen. Hierzu ist es vielleicht auch sinnvoll, wenn Sie die Abbruchbedingung im letzten Trigger zunächst einmal auskommentieren und Ihre Transaktionen selbständig durch ein rollback-Kommando zurückrollen. delete kostenstelle where kst = 'PSOFT'; rollback 001PSOFT,01-JAN-92 => Kostenstelle gelöscht (Fehler)

Zusammenfassung Ich glaube, durch das letzte Beispiel bekommt man schon ein Gefühl dafür, dass irgendwie eigentlich alles möglich ist. In Analogie zum letzten Beispiel könnten Sie zum einen auch die Prüfung der Gehaltsdatensätze noch effizienter gestalten und zum anderen wäre ebenfalls eine Überwachung des Inaktiv-Status denkbar, was in unserem Beispiel wegen der getroffenen Vereinbarung nicht notwendig war, zum anderen aber wegen der wesentlich umfangreicheren Programmierung den Rahmen aber auch bei weitem gesprengt hätte. Schließlich will ich Ihnen mit diesem Workshop keine fertigen Lösungen verkaufen, sondern Ideen generieren, wie Sie Ihre konkreten Aufgabenstellungen vielleicht lösen bzw. angehen könnten. In diesem Sinne ist auch das letzte Anwendungsbeispiel zu verstehen, das sicherlich schon ganz gut funktioniert, dem für einen echten Produktiveinsatz aber noch das eine oder andere Feature fehlt.

5.2.4

Exporthilfe

Als letztes Anwendungsbeispiel soll ein Programm erstellt werden, mit in Analogie zum Kapitel 5.1.10 eine Tabelle exportieren können. Allerdings soll das Programm so flexibel sein, dass Sie mit seiner Hilfe zum einen jede beliebige Tabelle exportieren und dabei auch das Ausgabeformat in einem gewissen Umfang beeinflussen können. Das Programm Die Programmierung erfolgt wieder mit Hilfe eines Packages, da neben der eigentlichen Startprozedur weitere private Prozeduren benötigt werden. Die Anlage des Pakets können Sie dem Beispiel 5.52 entnehmen und das zugehörige Programm finden Sie im Listing 5.53. create or replace package export as procedure export_table(owner in varchar2, table_name in varchar2, path in varchar2, file in varchar2, dtformat in varchar2, ft in varchar2, st in varchar2, kopf boolean); end; Listing 5.52: Anlage des Exportpakets

476


create or replace package body export as sql_buff varchar2(5000); sql_head varchar2(1000); /*-------------------------------------------------------------------Ermitteln der Struktur für die Exporttabelle. Das Ergebnis wird in den Variablen sql_buff und sql_head zwischengespeichert --------------------------------------------------------------------*/ procedure get_sql(iowner in varchar2, itable_name in varchar2, dtformat in varchar2, ft in varchar2, st in varchar2) is -- Abfrage der Tabellenstruktur cursor sel_cols is select column_name, data_type from all_tab_columns where owner = iowner and table_name = itable_name order by column_id; lbuff feldt satzt first

varchar2(50); varchar2(5); varchar2(15); boolean := true;

begin sql_buff := 'select '; -- Aufbereiten der Textbegrenzung if ft > ' ' then feldt := '''' || ft || ''''; else feldt := ''; end if; -- Aufbereiten des Feldtrennzeichens satzt := ' || ' || '''' || st || '''' || ' || '; -- Abarbeiten aller Feldnamen der gewählten Tabelle for sel_cols_rec in sel_cols loop -- Sonderbehandlung für das erste Datenfeld if first then first := false; lbuff := ''; sql_head := ''; else lbuff := satzt; sql_head := sql_head || st; end if;

Anwendungsbeispiele

-- Konstruktion eines select-Strings -- für Textfelder if sel_cols_rec.data_type in ('VARCHAR2','VARCHAR','CHAR') then lbuff := lbuff || feldt || ' || ' || sel_cols_rec.column_name || ' || ' || feldt; sql_buff := sql_buff || lbuff; sql_head := sql_head || sel_cols_rec.column_name; -- für Datumsfelder elsif sel_cols_rec.data_type = 'DATE' then lbuff := lbuff || 'nvl(to_char(' || sel_cols_rec.column_name || ',' || '''' || dtformat || '''' || '),' || '''' || '''' ||')'; sql_buff := sql_buff || lbuff; sql_head := sql_head || sel_cols_rec.column_name; -- für numerische Felder elsif sel_cols_rec.data_type = 'NUMBER' then lbuff := lbuff || 'nvl(to_char(' || sel_cols_rec.column_name || '),' || '''' || '''' ||')'; sql_buff := sql_buff || lbuff; sql_head := sql_head || sel_cols_rec.column_name; end if; end loop; end; /*--------------------------------------------------------------------Ausführen des dynamischen SQL-Buffers und Ausgabe der erhaltenen Daten --------------------------------------------------------------------*/ procedure export_records(path in varchar2, file in varchar2, kopf boolean) is ct rc textbuff rec_ct

integer; integer; varchar2(1500); integer:=0;

f utl_file.file_type; begin -- Öffnen und Parsen des dynamsichen Cursors ct := dbms_sql.open_cursor; dbms_sql.parse(ct, sql_buff, dbms_sql.native); dbms_sql.define_column(ct, 1, textbuff, 1500); -- Öffnen der Exportdatei f := utl_file.fopen(path, file, 'w');

477

478


-- Ausgabe der Feldüberschriften, falls gewünscht if kopf then utl_file.put_line(f, sql_head); end if; -- Ausführen des Cursors und holen des ersten Satzes rc := dbms_sql.execute_and_fetch(ct); while rc > 0 loop dbms_sql.column_value(ct, 1, textbuff); -- Satz wegschreiben utl_file.put_line(f, textbuff); -- Nächsten Record holen rc := dbms_sql.fetch_rows(ct); rec_ct := rec_ct + 1; end loop; -- Cursor und Datei schließen dbms_sql.close_cursor(ct); utl_file.fclose(f); dbms_output.put_line('Datensätze ' || to_char(rec_ct,'9999999')); end; /*-------------------------------------------------------------------Hauptprogramm --------------------------------------------------------------------*/ procedure export_table(owner in varchar2, table_name in varchar2, path in varchar2, file in varchar2, dtformat in varchar2, ft in varchar2, st in varchar2, kopf boolean) is begin -- SQL-String konstruieren get_sql(owner, table_name, dtformat, ft, st); -- from-Klausel ergänzen sql_buff := sql_buff || ' from ' || owner || '.' || table_name; dbms_output.put('Export von '); dbms_output.put(owner || '.' || table_name); dbms_output.put(' in '); dbms_output.put(path || ' -> ' || file); dbms_output.new_line; -- Export starten export_records(path, file, kopf); end; end; Listing 5.53: Programm für den universellen Dateiexport

Anwendungsbeispiele

479

Programmbeschreibung Das Exportprogramm wird mit Hilfe der Prozedur export_table gestartet, der neben dem Namen der Tabelle vor allem auch der Name und das Verzeichnis der Exportdatei übergeben werden müssen. Mit Hilfe der nächsten drei Parameter wird das bei Datumsfeldern zu verwendende Format, das zu verwendende Textbegrenzungszeichen und das Feldtrennzeichen vorgegeben und mit Hilfe des letzten Parameters können Sie festlegen, ob in der Datei die Feldnamen als erste Zeile ausgegeben werden sollen. execute export.export_table('UBEISPIEL','GEHALT', 'c:\temp','gehalt.txt', 'DD.MM.YYYY','"',';',true); Statement processed. Export von UBEISPIEL.GEHALT in c:\temp -> gehalt.txt Datensätze 49

Bei diesem Aufruf exportieren wir also die Tabelle gehalt aus dem Schema ubeispiel in die Datei C:\TEMP\GEHALT.TXT. Dabei werden Datumswerte im Format DD.MM.YYYY ausgegeben, Textfelder werden in Anführungszeichen gesetzt und alle Datenfelder werden durch ein Semikolon getrennt, wobei die Feldnamen als erste Zeile ausgegeben werden. PERSNR;LFDNR;GAB;KST;GEHALT;ZULAGE "7000001";0;01.01.1990;"PERS";4500;500 "7000002";0;01.04.1998;"PERS";4750;300 "7000002";0;01.04.1999;"PERS";4980;290 "7000003";0;01.08.1999;"EDV";6500;0 "7000004";0;01.04.1998;"EDV";7250;455 "7000004";0;01.07.1998;"PSOFT";7250;455 "7000004";0;01.04.1999;"PSOFT";7850;512 "7000005";0;01.04.1998;"PSOFT";6200;120 .... Listing 5.54: Auszug aus der Exportdatei

Innerhalb der Hauptprozedur export_table des Programms wird zunächst die Prozedur get_sql gestartet, mit der die Struktur der zu exportierenden Tabelle ausgelesen werden soll. Das passiert dort mit Hilfe des Cursors sel_cols, der mit Hilfe einer Abfrage auf die View all_tab_columns alle in der übergebenen Tabelle vorhandenen Spalten und die zugehörigen Datentypen selektiert. Das Ziel dieser Prozedur ist es, für jede vorhandene Datenspalte die in der Variabel sql_buff gespeicherte SQL-Abfrage zu erweitern. Diese Abfrage wird so konstruiert, dass alle in der Tabelle vorhandenen Felder aneinandergehängt werden, d.h. die später für den Export abgesetzte Abfrage selektiert genau eine Spalte. Für unsere Gehaltsdaten hat diese select-Anweisung beispielsweise folgenden Aufbau:

480


select '"' || PERSNR || '"' || ';' || nvl(to_char(LFDNR),'') || ';' || nvl(to_char(GAB,'DD.MM.YYYY'),'') || ';' || '"' || KST || '"' || ';' || nvl(to_char(GEHALT),'') || ';' || nvl(to_char(ZULAGE),'')

Die benötigten Exportsätze werden also schon durch Abfrage vollständig aufbereitet, d.h. unser select-Ausdruck enthält ebenfalls alle benötigten Trenn- und Begrenzungszeichen. Aus diesem Grund wird zunächst einmal das Textbegrenzungszeichen in der Variablen feldt durch folgende Anweisungen aufbereitet: if ft > ' ' then feldt := '''' || ft || ''''; else feldt := ''; end if;

Aufgrund der Anweisung im if-Zweig enthält die Variable feldt das beim Prozeduraufruf übergebene Textbegrenzungszeichen, das von je einem Anführungszeichen eingeschlossen ist. In unserem Fall enthält die Variable also folgenden Wert '“' . Das zu verwendende Feldtrennzeichen enthält ebenfalls wird ebenfalls aufbereitet und in der Variablen satzt gespeichert. Dabei enthält diese Variable neben diesem Trennzeichen auch den speziellen Konkatinierungsoperator, der bei der späteren Abfrage für das Aneinanderhängen der einzelnen Spalten sorgt. Im nächsten Schritt wird der Cursor mit Hilfe einer for loop-Schleife abgearbeitet. Dabei müssen alle exportfähigen Datentypen mit Hilfe spezieller Anweisungen in den SQL-Puffer eingearbeitet werden, weshalb Sie in dem Beispiel für die einzelnen Datentypen unterschiedliche if-Zweige finden. Sofern Sie das Programm in der Praxis verwenden wollen, dann müssen Sie den inneren Teil der Schleife eventuell erweitern oder anpassen, wenn Sie die weitere Datentypen ausgeben oder die vorhandenen Möglichkeiten ausbauen wollen. Neben dem Fortschreiben des SQL-Puffers in der Variablen sql_buff wird innerhalb der Schleife auch die Variable sql_head gefüllt, in der die Feldüberschriften aufbereitet werden. Nach dem Durchlaufen der Prozedur get_sql befindet sich in der Variablen sql_buff, also ein abfragefähiger Ausdruck und in der Variablen sql_head stehen alle zugehörigen Feldnamen. Was dem SQL-Statement allerdings noch fehlt ist eine geeignete from-Klausel, die der sql_buff-Variablen im Anschluss an die Prozedur angefügt wird. sql_buff := sql_buff || ' from ' || owner || '.' || table_name;

Danach verzweigt das Programm in die Prozedur export_records, in der die eigentliche Tabellenausgabe stattfindet. Eigentlich handelt es sich hierbei um die Kombination von zwei schon gezeigten Beispielen, denn zum einen wird mit Hilfe des Pakets dbms_sql eine Auswahlabfrage ausgeführt, wobei konkret das in der Variablen sql_buff gespeicherte Statement verwendet wird und zum anderen werden die selektierten Datensätze mit Hilfe des Paketes utl_file in eine Textdatei geschrieben.

6

Anwendungsentwicklung

Mit diesem Kapitel nähern wir uns dem Ende des Workshops, wobei ich das Buch mit einigen Hinweisen zur Anwendungsentwicklung bzw. der Einbeziehung der Oracle-Datenbank bei der Erstellung von Front-Ends abschließen möchte. Immer wenn Sie ein konkretes Anwendungsprogramm, beispielsweise eine WindowsAnwendung, entwickeln, in der Sie auf Daten aus einer Oracle-Datenbank zugreifen wollen, dann besteht das erste zu überwindende Problem darin, aus Ihrem Anwendungsprogramm eine Verbindung zur Datenbank herzustellen.

6.1

Grundlagen

Genau genommen müssen Sie dabei eine Verbindung zum Net8-Protokoll aufnehmen, denn hierüber können Sie sich anschließend an eine Oracle-Instanz anmelden und danach SQL-Befehle absenden und Ergebnisse oder Fehlermeldungen empfangen. Für die Kommunikation eines Clients mit einer Datenbankinstanz über das Net8-Protokoll existiert ein standardisiertes Verfahren, das oftmals mit dem Kürzel „OCI“ beschrieben wird. Diese Abkürzung steht für „Oracle Call Interface“ und beschreibt eine Funktionsbibliothek die alle Routinen bereitstellt, die für die Kommunikation mit einer Oracle-Instanz benötigt werden. Hierbei handelt es sich beispielsweise um Funktionen, um

X X X

eine Verbindung mit einer Datenbankinstanz aufzubauen bzw. zu beenden. eine SQL-Abfrage oder einen PL/SQL-Block an den Server zu schicken. Abfrageergebnisse oder Fehlermeldungen zu empfangen.

Ein solches OCI steht für alle Betriebssysteme zur Verfügung, für die ein Oracle-Client existiert. Allerdings besitzt diese Funktionsbibliothek ein Format, das in der ursprünglichen Form eigentlich nur C/C++ Programmierer anspricht, dabei auch gewisse Anforderungen an diesen stellt und in anderen Programmiersprachen eigentlich nicht direkt verwendet werden kann. Wenn Sie beispielsweise ein Windows-Programm entwickeln und hierbei nicht C bzw. C++ als Programmiersprache verwenden, dann besteht eine Möglichkeit zur direkten Verwendung der OCIBibliothek darin, zunächst eine DLL (also doch wieder C) zu entwerfen, in der Sie die benötigten OCI-Funktionen einbetten. Bei den einzelnen DLL-Funktionen müssen Sie dann darauf achten, dass diese innerhalb der konkret eingesetzten Umgebung verwendbar sind, was in der Regel bedeutet, dass Sie bei der Parametergestaltung möglichst einfache Datentypen verwenden sollten. Hinweise zur Verwendung der OCI-Bibliothek finden Sie in der Oracle-Dokumentation im Buch „Application Development“. Dort finden Sie verschiedene Verweise auf detaillierte Beschreibungen des Oracle Call Interfaces.

482


Auf der anderen Seite wäre es aber unverständlich, wenn nicht sogar unsinnig, die Arbeit, die andere schon vor uns erledigt haben und die uns des weiteren sogar zur Verfügung steht selbst noch einmal zu wiederholen, d.h. es gibt auch andere Möglichkeiten ohne den Umweg über den C-Compiler Programme mit Oracle-Datenbankzugriffen zu erstellen. Teilweise sind die benötigten Funktionalitäten sogar schon in den Anwendungen oder Programmiersprachen integriert. Wenn Sie beispielsweise Front-Ends mit Hilfe von Oracle-Forms entwerfen, dann brauchen Sie sich über die Verbindung zur Datenbankinstanz eigentlich kein Kopfzerbrechen zu machen. Gleiches gilt im Übrigen auch, wenn Sie Anwendungen mit SQR entwickeln und selbst den CobolProgrammierern steht aufgrund verfügbarer Zusatzoptionen ein problemloser Datenbankzugang zur Verfügung. Neben solchen produktspezifischen Lösungen existieren aber auch noch weitere allgemeinverwendbare Hilfen, um mit einer Oracle-Instanz in Kontakt zu treten. Unter Windows handelt es sich dabei im Prinzip um besondere DLLs oder OCXSteuerelemente, die eine einfacherer Verwendung der OCI-Funktionen ermöglichen, wobei diese meistens sogar mit weiteren Zusatzfunktionen ausgestattet wurden, indem Sie den Empfang einer Datenmenge beispielsweise nicht mit Hilfe unzähliger systemnaher Funktionen programmieren müssen, sondern hierfür geschaffene Objekte mit komfortablen und leistungsfähigen Methoden finden. Im weiteren Verlauf möchte ich Ihnen zwei Vertreter dieser verfügbaren Helferlein kurz vorstellen und deren Verwendung ebenfalls anhand eines Beispiels demonstrieren, wobei ich mir als Vertreter eine ODBC-Verbingung und die Anwendung der Oracle-Objekte ausgesucht habe.

6.1.1

ODBC-Verbindung

Wie schon gesagt, besteht eine Variante zum Einbinden einer Oracle-Datenbank in die eigene Programmierung oder in verschiedene Anwendungsprogramme darin, die Verwendung mit Hilfe eines ODBC-Treibers (ODBC = Open Database Connectivity) herzustellen. Um über ODBC mit einer Oracle-Datenbank arbeiten zu können, müssen insgesamt zwei Voraussetzungen erfüllt sein:

X

X

Der zur Oracle- Datenbank passende ODBC-Treiber muss installiert sein, was im Rahmen einer standardmäßigen Client-Installation auf Windows-Arbeitsplätzen automatisch erfolgt. Bei manueller Auswahl der zu installierenden Komponenten müssen Sie gegebenenfalls darauf achten, dass auch das Produkt „Oracle8 ODBC Driver“ mit zur Installation ausgewählt wird. Der ODBC-Treiber muss für die Arbeit mit der gewünschten Datenbank eingerichtet werden, was Sie mit Hilfe eines speziellen ODBC-Managers durchführen können, den Sie üblicherweise in der Systemsteuerung Ihres Windows-Systems finden.

Grundlagen

483

Aufbau einer ODBC-Verbindung Nach dem Start des ODBC-Managers, der sich heutzutage in seinem Programmfenster ODBC-Datenquellen-Administrator nennt, erhalten Sie ein kleines Arbeitsfenster mit verschiedenen Registerkärtchen. Mit Hilfe des Registerkärtchens „Treiber“ (vgl. Abb. 6.1). erhalten Sie eine Liste der bereites installierten ODBC-Treiber. Wie Sie der Abbildung auch entnehmen können, gibt es für einige Datenbanksysteme durchaus passende ODBC-Treiber von verschiedenen Herstellern.

Abbildung 6.1: ODBC-Datenquellen-Administrator mit einer Liste der installierten Treiber

Nach meinen Erfahrungen funktioniert sowohl der von Microsoft als auch der von Oracle gelieferte Treiber sehr gut. Dennoch gibt es aus meiner Sicht kein wirkliches Entscheidungsproblem, denn ich habe in der Vergangenheit immer den vom Datenbankhersteller gelieferten Treiber verwendet, sofern er verfügbar war und funktionierte. Um den ODBC-Treiber zusammen mit einer Datenbank verwenden zu können, müssen Sie ihn für die gewünschte Datenquelle einrichten. Dies hängt damit zusammen, dass gemäß dem eigentlichen Konzept von ODBC eine Unabhängigkeit zwischen Anwendung und verwendeter Datenbank entstehen soll. Aus dem Grund verbinden sich die einzelnen Anwendungen nicht direkt mit einer Datenbank, sondern zunächst mit einer abstrakten Datenquelle (vgl. Abb. 6.2). Was sich konkret hinter dieser Datenquelle verbirgt, das wird im Rahmen der ODBC-Datenquellenkonfiguration festgelegt.

484


Anwendungsprogramm

ODBC-Datenquelle

Treiber und Datenbank

(MeineDaten)

(Oracle-Treiber, db01)

Net8

Datenbank

Abbildung 6.2: Schematische Struktur einer ODBC-Datenquelle

Wie Sie der Abbildung 6.2 entnehmen können, verbindet sich eine ODBC-Anwendung mit Hilfe eines logischen Namens an eine Datenbank bzw. genauer gesagt an eine Datenquelle. Welche Datenbank (Name und Hersteller) sich konkret dahinter verbirgt wurde im Rahmen der Konfiguration dieser Datenquelle festgelegt, d.h. auf diese Weise können zumindest theoretisch datenbankunabhängige Anwendungen erstellt werden. Echte Datenbankunabhängigkeit erreicht man natürlich nicht nur dadurch, dass man Verbindungsinformationen flexibel bzw. abstrakt verwaltet. Ich habe im Rahmen dieses Workshops ja schon mehrfach angedeutet, dass die verschiedenen verfügbaren Datenbanksysteme ein durchaus unterschiedliches Funktionsspektrum besitzen, wobei sich selbst die Formulierung bestimmter Abfragen unterschiedlich gestaltet. Setzt man in seiner Anwendung also irgendwelche speziellen Funktionalitäten ein, dann ist es mit dieser Unabhängigkeit sowieso vorbei. Damit dieses Konzept aber wenigstens im Rahmen gewöhnlicher Auswahl- bzw. Änderungsabfragen funktioniert, bietet ODBC neben der Verschlüsselung von Datenquellen natürlich noch weitere Funktionalitäten (vgl. Abb. 6.3). Ich habe in der Abbildung 6.3 einmal den Aufbau eines ODBC-Treibers stark vereinfacht dargestellt. Im Prinzip besteht so ein ODBC-Treiber aus drei Schichten. Mit Hilfe der ersten Schicht erfolgt die Kontaktaufnahme und Kommunikation zum Treiber, d.h. diese Schicht fungiert quasi als Schnittstelle zum Anwendungsprogramm. In der mittleren Schicht werden die an den Treiber übermittelten Abfragen für die konkret eingesetzte Datenbank übersetzt. Die hierdurch entstehenden Abfragen werden mit Hilfe der ebenfalls datenbankspezifischen Verbindungsschicht an die Datenbank weitergeleitet. Zurück geht der Weg genau umgekehrt, d.h. die in der Verbindungsschicht empfangenen Daten werden durch den Treiber dem Anwendungsprogramm über die Schnittstellenschicht zur Verfügung gestellt.

Grundlagen

485

Anwendungsprogramm

Interface PassThrough

Universalübersetzer

Datenbankverbindung

Datenbank

Abbildung 6.3: Verwenden eines ODBC-Treibers

Technisch betrachtet, besteht ein solcher ODBC-Treiber aus einem Geflecht verschiedenster DLLs, die jeweils spezifische Einzelaufgaben in diesem komplexen Funktionsnetzwerk übernehmen. Dabei liegt auf der Hand, dass der Gebrauch der in Abbildung 6.3 skizzierten „Universalübersetzers“ einen gewissen Overhead mit sich bringt. Allerdings können Sie der Abbildung auch entnehmen, dass es eine Möglichkeit gibt, diesen Übersetzer zu umgehen, indem Sie sogenannte Passthrough-Abfragen erstellen. Bei diesem Abfragetyp kommunizieren der ODBC-Einund Ausgang quasi direkt miteinander, was zwei Vorteile mit sich bringt. Zum einen steht Ihnen jetzt wieder der nahezu vollständige Funktionsumfang Ihrer Datenbank zu Verfügung und zum anderen entstehen Ihnen hierbei keine nennenswerten Geschwindigkeitseinbußen mehr. Die Verwendung von ODBC zusammen mit der Option PathThrough stellt also durchaus eine Alternative zur direkten Verwendung des Oracle Call Interfaces dar. Aus meiner Erfahrung gibt es zumindest nichts was dagegen spricht, denn es funktioniert stabil, ist schnell genug, relativ einfach zu programmieren und eröffnet einem den direkten Zugang zu allen wichtigen Datenbankfunktionalitäten. Datenquelle einrichten Bevor wir uns mal an einem Beispiel anschauen, wie Sie mit Hilfe von ODBC Daten aus Ihrer Datenbank empfangen können, müssen wir zunächst eine Datenquelle für unsere Datenbankinstanz „db01“ einrichten. Öffnen Sie hierzu das Fenster Ihrer Windows-Systemsteuerung und starten Sie dort den ODBC-Manager bzw. Datenquellen-Administrator. Wählen Sie anschließend innerhalb des Registrierkärtchens „Benutzer-DSN“ die Schaltfläche „Hinzufügen“, um die Anlage einer

486


neuen Datenquelle einzuleiten. Hierdurch erhalten Sie einen Dialog (vgl. Abb. 6.4), der Ihnen eine Liste aller installierten ODBC-Treiber anzeigt.

Abbildung 6.4: Auswahl des Treibers für die neue Datenquelle

Aus dieser Liste (vgl. Abb. 6.4) wählen Sie den ODBC-Treiber von Oracle aus. Anschließend können Sie mit der Schaltfläche „Fertig stellen“ mit der Verarbeitung fortfahren, wodurch Sie einen Dialog zur Konfiguration der neuen Datenquelle erhalten.

Abbildung 6.5: Neue Datenquelle konfigurieren

Mit Hilfe des zur Einrichtung der neuen Datenquelle angezeigten Setup-Dialogs (vgl. Abb. 6.5) müssen Sie der zunächst einmal einen Namen geben, unter dem die Datenquelle in den späteren ODBC-Programmen angesprochen wird. Zusätzlich können Sie in dem nächsten Feld eine optionale Beschreibung für diese Datenquelle erfassen.

Grundlagen

487

Das nächste Datenfeld ist wieder wichtig, denn hier legen Sie fest, mit welcher Datenbank die Verbindungsschicht Kontakt aufnehmen soll. Da dieser Kontakt über das Net8-Netzwerk hergestellt wird, müssen Sie hier einen gültigen Servicenamen verwenden. Im darauffolgenden Feld haben Sie die Möglichkeit, die BenutzerId, mit der die Anmeldung erfolgen soll, als eine Art Standardwert vorzugeben, wobei Sie innerhalb Ihrer Anwendung die Benutzer-Id zusammen mit dem zugehörigen Passwort beim Starten der ODBC-Verbindung vorgeben können. Speichern Sie Ihre neue Datenquellendefinition mit Hilfe der OK-Schaltfläche. Anschließend können Sie den ODBC-Administrator beenden, d.h. das war schon alles, um eine neue ODBC-Datenquelle einzurichten. Ein Anwendungsbeispiel Nach der Installation bzw. der Konfiguration einer ODBC-Datenquelle steht Ihnen die Oracle-Datenbank in vielen Anwendungen quasi auf Knopfdruck zur Verfügung. Beispielsweise können Sie von Excel aus mit Hilfe von Microsoft Query direkt Abfragen in der Oracle-Datenbank ausführen und die Ergebnisse in Ihr Excel-Arbeitsblatt importieren. Das Gleiche gilt im Übrigen auch für Winword, denn auch hier existiert zumindest in den aktuelleren Versionen eine Datenschnittstelle, mit der Sie beispielsweise Serienbriefe durch direktes Anzapfen bzw. Verwenden einer Datenbankabfrage mischen können. Ein weiteres Beispiel ergibt sich in der Verwendung von Oracle-Tabellen innerhalb einer Access-Datenbank. Wählen Sie hierzu im Datei-Menü den Eintrag „Externe Daten“ und dort „Tabelle Verknüpfen“. Anschließend erscheint ein Dialog, mit dessen Hilfe Sie die Datenquelle, in der die zu verknüpfende Tabelle liegt auswählen können. Wählen Sie in diesem Fenster in dem Dialogfeld „Dateityp“ den Eintrag „ODBC-Datenquelle“ aus, wodurch Sie automatisch ein neues Dialogfenster (vgl. Abb. 6.6) erhalten, in dem Sie das Registerkärtchen „Computerdatenquelle“ finden.

Abbildung 6.6: Verknüpfung zu einer Oracle-Tabelle herstellen

488


Wählen Sie in der angezeigten Liste der verfügbaren Datenquellen den soeben angelegten Eintrag zur Verbindung mit der db01-Instanz aus und beenden Sie den Dialog danach mit Hilfe der OK-Schaltfläche. Anschließend werden Sie zur Eingabe einer Benutzerkennung nebst zugehörigem Passwort aufgefordert und wenn Sie auch diese letzte „Hürde“ überwunden haben, dann stehen Ihnen die in der Oracle-Datenbank vorhandenen Tabellen zur Auswahl.

Abbildung 6.7: Verknüpfung zur Tabelle ubeispiel.personalien herstellen

Wählen Sie in der gezeigten Liste (vgl. Abb. 6.7) der vorhandenen Tabellen diejenigen oder alle aus, für die Sie in Ihrer Access-Datenbank eine Verknüpfung wünschen, die nach Beendigung dieses Dialogs mit OK hergestellt werden. Innerhalb der Access-Anwendung können Sie diese eingebundenen Tabellen anschließend genaue wie gewöhnliche Access-Objekte benutzen, d.h. Sie können darauf basierende Abfragen, Formulare oder Reports erstellen. Verwenden von Visual oder Access Basic Genauso gut wie die eben beschriebene Verfahrensweise funktioniert auch die Verwendung einer ODBC-Datenquelle in einem Programm, beispielsweise unter Verwendung von Visual Basis oder Access Basic. Beachten Sie bei den folgenden Beispielen, dass Sie unter Verwendung von DAO 3.6 erstellt wurden, d.h. Sie müssen die entsprechende Library zur Verwendung in Ihrem Projekt freischalten. Hierzu finden Sie üblicherweise den Menüeintrag „Verweise“ unter dem Extrasoder Projektmenü. Die beiden gezeigten Beispiele finden Sie auf Ihrer CD übrigens im Verzeichnis \ANWENDUNG. Das erste Beispiel 6.1 könnte beispielsweise in einem Access-Modul verwendet werden, wobei Sie die erstellte Funktion start beispielsweise mit Hilfe eines Makros starten können. Function start() Dim db As Database Dim qu As QueryDef

Set db = CurrentDb()

Grundlagen

489

On Error Resume Next db.QueryDefs.Delete "Read" On Error GoTo 0 Set qu = db.CreateQueryDef("Read") qu.Connect = "ODBC;DSN=MeineDB01;UID=UBEISPIEL;PWD=MANAGER;DATABASE=DB01" qu.ReturnsRecords = False qu.SQL = "delete from ubeispiel.personalien where persnr = '4711'" qu.Execute MsgBox "Gelöscht " & Format$(qu.RecordsAffected) qu.Close db.Close End Function Listing 6.1: Verwenden von ODBC innerhalb einer Access-Funktion

Im Beispiel 6.1 erstellen wir innerhalb der aktuellen Access-Datenbank zunächst eine neues Abfrageobjekt mit dem Namen „Read“. Damit das in jedem Falle funktioniert, wird das Objekt vorab mit Hilfe der delete-Methode aus der aktuellen QueryDefs-Liste gelöscht. Nachdem wir nun das neue bzw. alte Abfrageobjekt wieder neu erstellt haben, beginnen wir in der Funktion die einzelnen Eigenschaften zu besetzen. Im Rahmen der ODBC-Programmierung ist vor allem die connect-Eigenschaft besonders wichtig, da mit ihr die Verbindung zur der zu verwendenden Datenquelle hergestellt wird. ODBC;DSN=MeineDB01;UID=UBEISPIEL;PWD=MANAGER;DATABASE=DB01

Eine solche Verbindungszeichenfolge beginnt in unserem Fall immer mit der Konstanten „ODBC“, denen weitere, zum Teil treiberspezifische Einträge folgen, die alle durch ein Semikolon getrennt werden. In unserem Beispiel müssen Sie mit Hilfe der Einträge UID, PWD und DATABASE die Benutzerkennung, das zugehörige Passwort und den Servicenamen für das Net8-Protokoll vorgeben. In den folgenden Programmzeilen belegen wir weitere Eigenschaften des Abfrageobjekts mit den gewünschten Eigenschaften und führen die im Objekt gespeicherte Löschabfrage anschließend mit Hilfe der execute-Methode aus. Als Variante können Sie auch ein Abfrageobjekt erstellen, indem Sie eine beliebige Datenbankabfrage auf die Oracle-Datenbank speichern, das Sie anschließend innerhalb von Access für die Berichtserstellung oder beliebige andere Aktivitäten verwenden können. Set qu = db.CreateQueryDef("Read") qu.Connect = "ODBC;DSN=MeineDB01;UID=UBEISPIEL;PWD=MANAGER;DATABASE=DB01" qu.ReturnsRecords = True qu.SQL = "select * from ubeispiel.personalien" qu.Close

490


Das nächste und letzte Beispiel (vgl. Listing 6.2) zeigt, wie Sie beispielsweise innerhalb eines Visual Basic-Programms die Verbindung zu einer Oracle-Datenbank aufnehmen, anschließend eine Abfrage auf die Personalstammdaten ausführen und die Ergebnisse mit Hilfe einer Schleife verarbeiten, wobei das Programm die Namen mit Hilfe einer einfachen Meldungsbox anzeigt. Dim ws As Workspace Dim cn As Connection Dim rs As Recordset Set ws = DBEngine.CreateWorkspace("Test", "", "", dbUseODBC) Set cn = ws.OpenConnection("Test", dbDriverNoPrompt, False, "ODBC;DSN=MeineDB01;UID=UBEISPIEL;PWD=MANAGER;DATABASE=DB01") Set rs = cn.OpenRecordset("select * from ubeispiel.personalien")

Do While Not rs.EOF MsgBox rs.Fields("name") rs.MoveNext Loop rs.Close cn.Close ws.Close Listing 6.2: Erstellen einer direkten ODBC-Abfrage in Visual Basic

Der wesentliche Unterschied zum zuerst gezeigten Beispiel 6.1 ist zunächst einmal, dass Sie diesmal überhaupt keine Access-Datenbank benötigen. Sie können das Programmbeispiel in den click-Code einer Befehlsschaltfläche auf einem sonst leeren Formular ausprobieren. Das Einzige, was Sie in Ihrem VB-Projekt brauchen, ist ein Verweis auf die DAO-Library von Microsoft (Version 3.6). Nicht nur ODBC ist bei genauerer Betrachtung ein Sandwich mit viel Belag, sondern auch die darauf aufsetzenden DAO-Objekte machen aus dem Hamburger einen Big Mäc. Das untenliegende Brötchen entspricht dabei dem sogenannten Arbeitsbereich (Workspace), den wir mit Hilfe der createworkspace-Funktion erzeugen. Ein wichtiger Parameter dabei ist die vordefinierte Konstante dbUseODBC, die es uns ermöglicht, in diesem Arbeitsbereich die schon beschriebenen PassthroughAbfragen auszuführen. Im nächsten Schritt kümmern wir uns um eine Verbindung zur Oracle-Datenbank, d.h. wir legen auf dem Brötchen die erste Käsescheibe in Form eines sogenannten Connection-Objekts. Genau wie im letzten Beispiel verwenden wir hierbei wieder die schon beschriebene Verbindungszeichenfolge, damit der Treiber sich an der vorgegebenen Datenquelle anmelden kann. Auf unserem Connection-Objekt baut wiederum das im nächsten Schritt erstellte Recordset-Objekt auf, mit dem wir die durch die spezifizierte SQL-Abfrage gelieferten Datensätze verarbeiten können.

Grundlagen

6.1.2

491

Verwenden der Oracle-Objekte

Eine andere Möglichkeit schnell, einfach und komfortabel Oracle-Anwendungen zu entwickeln, besteht darin, bei der Entwicklung auf die Oracle Objects zurückzugreifen. Ähnlich wie bei ODBC, stehen Ihnen bei diesen Objekten allerdings nicht nur Hilfsmittel zur einfacheren Verbindung mit einer Oracle Instanz zur Verfügung, sondern Sie erhalten ebenfalls eine Menge Möglichkeiten Abfragen auf besonders einfache Weise auszuführen oder die empfangenen Daten mit Hilfe spezieller Steuerelemente darzustellen. Der wesentliche Unterschied zu ODBC ist allerdings, dass die Oracle Objects direkt auf Net8 aufsetzen, d.h. Sie benötigen für eine Datenbankanmeldung lediglich den üblichen Servicenamen, weitergehende Einstellungen oder Definitionen werden nicht gebraucht. Hierzu zählt beispielsweise das Oracle Data Control, das Sie beispielsweise innerhalb eines Visual Basic-Projekts verwenden können und mit dem Sie ähnlich wie bei dem Data Control von Microsoft Datenbankanwendungen zusammenklicken können, ohne hierfür eine Zeile Code programmieren zu müssen, indem das Data Control mit Hilfe der vorhandenen Eigenschaften an die Datenbank und die einzelnen Anzeigeelemente mit Hilfe ihrer Eigenschaften an das Data Control gebunden werden.

Abbildung 6.8: Beispiel einer einfachen VB-Anwendung

Sie finden das in Abbildung 6.8 gezeigte Beispiel übrigens ebenfalls im Verzeichnis \ANWENDUNG. Das Visual Basic-Projekt hat den Namen ORCLDEMO.VDP und das Formular heißt entsprechend ORCLDEMO.FRM (bzw. FRX). Der Tabelle 6.1 können Sie die wesentlichen Eigenschaften der verwendeten Steuerelemente entnehmen. Natürlich besteht auch die Möglichkeit, die Objekte innerhalb von Programmen zu benutzen und dabei ähnliche Konstruktionen wie bei den beiden ODBC-Beispielen zu bauen. Ich habe mich diesmal für eine Beispiel zusammen mit Microsoft Excel entschieden, d.h. wir werden dort im Folgenden eine kleine VBA-Funktion bauen, mit denen Sie direkt aus Ihren Excel-Arbeitsblättern auf die Datenbank zugreifen können.

492


Steuerelement/Eigenschaft

Belegung

Oracle Data Control Connect

Vorgabe von Benutzerkennung und Passwort, z.B. ubeispiel/manager.

Databasename

Servicename, z.B. DB01.

Recordsource

Auszuführende Abfrage, z.B. „select * from personalien“.

Textfelder Datafield

Anzuzeigendes Datenfeld, z.B. „persnr“.

Datasource

Datenquelle, in dem Fall der Name des eingesetzten Data Controls, z.B. ORADC1.

Tabelle 6.1: Wichtige Einstellung in dem Musterprojekt

Verwenden der Oracle-Objekte in Excel Bei erfolgreicher Installation der Oracle Objects, werden diese automatisch in Ihrer Windows-Umgebung registriert, so dass damit auch schon alle Voraussetzungen zu deren Verwendung erfüllt sind. Gleich wollen wir anhand eines kleinen Beispiels eine Funktion bauen, mit der Sie direkt aus Ihrem Arbeitsblatt heraus auf die Datenbank zugreifen können. Diese Funktion soll dabei genau wie eine Excel-Standardfunktion verwendbar sein, d.h. Sie können sie wie die Standardfunktion summe in allen denkbaren Varianten einsetzen. Das fertige Beispiel finden Sie im Listing 6.3 und auf der CD in der Datei \ANWENDUNG\LISTING63.TXT. Function fetch_field(service As String, connect As String, sqlbuff As String) As Variant Dim OraSession As Object Dim OraDatabase As Object Dim OraDynaset As Object On Error GoTo xxerr: 'Erstellen einer OLE-Verbindung zu den Objekten Set OraSession = CreateObject("OracleInProcServer.XOraSession") 'Connecten zur Datenbank Set OraDatabase = OraSession.OpenDatabase(service, connect, 0&) 'Abfrage ausführen Set OraDynaset = OraDatabase.CreateDynaset(sqlbuff, 0&) 'Erstes Feld im ersten Datensatz lesen, der Rest wird weggeworfen fetch_field = OraDynaset.fields(0).Value 'Cursor und Sitzung schließen OraDynaset.Close

Grundlagen

493

OraDatabase.Close Exit Function xxerr: fetch_field = Error End Function Listing 6.3: Kleine Funktion zur Datenbankabfrage in Excel

Ich finde, dieses Programmbeispiel hat durchaus Ähnlichkeiten zu den beiden letzten Beispielen 6.1 und 6.2. Zunächst müssen Sie mit Hilfe der Funktion CreateObject ein Sitzungsobjekt erstellen, dass Sie anschließend mit Hilfe der Methode OpenDatabase mit der Datenbank verbinden, wodurch Sie eine konkrete Datenbankverbindung erhalten, die Sie wiederum als Basis zur Ausführung von Abfragen verwenden können. Für alle diese Aufgaben benötigt unsere Funktion insgesamt drei Parameter. Der erste legt die zu verwendende Datenbankinstanz fest, indem dort der zugehörige Servicename für das Net8-Protokoll übergeben wird. Der zweite Parameter enthält die benötigten Anmeldeinformationen, also Benutzerkennung und das zugehörige Passwort und mit Hilfe des letzten Parameters wird die auszuführende Abfrage spezifiziert. fetch_field("db01", "ubeispiel/manager", "select ... ")

Installation der Funktion Gehen Sie folgendermaßen vor, um die hier beschriebene Funktion in einem ExcelArbeitsblatt verfügbar zu machen: 1. Starten Sie Excel mit einem neuen, leeren Arbeitsblatt. 2. Wählen Sie im Extras-Menü die Einträge „Makros“ und anschließend „Visual Basic Editor“. Anschließend wird der VBA-Editor mit seinen verschiedenen Arbeitsfenstern gestartet. 3. Sie können die Funktion ein einem vorhandenen oder separaten Modul speichern. Öffnen Sie das gewünschte Modul oder erstellen Sie ein neues, indem Sie im Einfügen-Menü des VBA-Editors den Eintrag „Modul“ auswählen. 4. Kopieren Sie das im Beispiel 6.3 gezeigte Listing vollständig in das ausgewählte Modul und speichern Sie die Änderungen anschließend. Anwenden der Funktion Zur Anwendung der Funktion habe ich eine kleine Personalstatistik erstellt, die Sie ebenfalls im Verzeichnis \ANWENDUNG in der Datei DEMO.XLS finden. Das Schöne an diesem Beispiel ist, dass abgesehen von den reinen Berechnungen wie die Summenfelder, alle anderen Spalten direkt aus der Datenbank gelesen werden und somit jederzeit per F9-Funktionstaste (manuelles Neuberechnen) aktualisiert werden können. Noch besser ist allerdings, dass wir die Parameter der Funktion im zweiten Arbeitsblatt speichern können, d.h. die Parameter der einzelnen Funktionsaufrufe bestehen selbst wiederum aus lauter Zellverweisen.

494


Abbildung 6.9: Verwenden unserer neuen Funktion in einer Personalstatistik

=fetch_field(Tabelle2!$A$1;Tabelle2!$A$2;Tabelle2!B7)

In dem zweiten Arbeitsblatt „Tabelle2“ stehen also die konkreten Anweisungen für unsere kleine Statistik (vlg. Abb. 6.10). In den Zellen A1 und A2 wurden der Servicename und die Anmeldeinformationen abgelegt, wobei man die Abfrage dieser Daten sicherlich auch noch parametergesteuert realisieren könnte. In den Zellen B7 bis C9 sind die auszuführenden SQL-Abfragen abgelegt, die zu den in Abbildung 6.9 gezeigten Ergebnissen führen.

Abbildung 6.10: Definition der Personalstatistik

Stichwortverzeichnis XSymbole != 256 (+) 279 >= 255 || 124

XA

Abfrage Auswahlabfragen 250 Abfragen 249 Ablaufkontrolle 249 Aliasnamen 251 Änderungsabfragen 249, 298 aufteilen 296 Auswahlabfragen 249–250 connect by-Klausel 294 Cursor verwenden 249, 309 distinct-Klausel 253–254 Einfügeabfragen 303 Existenzprüfung 271 for update-Klausel 306 from-Klausel 250–251, 269–270 group by-Klausel 261, 264 Gruppierungen 261 having-Klausel 261, 263–264 hierarchisch 287 insert into-Anweisung 303, 305 Joins 266 Löschabfragen 301 Mengenoperationen 281 order by-Klausel 250, 260, 282 Outer-Joins 278 returning-Klausel 317 select-Klausel 250 sortieren 259 Tabelle löschen 302 Transaktion 319 Tuning 249, 324 Unterabfragen 271, 273 update-Anweisung 298 where-Klausel 250, 254, 269 Abfragen ausführen siehe SQL*Plus Abfrageoptimierung siehe Tuning von Abfragen Abgleichengruppe 156 abs 398 accept 102 add constraint 194, 199 add_months 404 Aggregatfunktionen 262–263, 275 Aliasnamen 251, 270

all_clusters 119 all_db_links 123 all_ind_columns 131 all_indexes 131 all_tab_columns 479 all_tab_privs 456, 460 all_tables 457 all_views 214 alter cluster 119 alter database datafile 222 alter index 423 alter profile 365 alter sequence 156, 158 alter session 397 alter system kill session 353 alter table 185, 192 alter tablespace 222 alter trigger 212 alter type 179 analyze table 326 and 258 Änderungsabfragen 298 Änderungsprotokoll 170 Äquivalenz 258 Archiver 63 Array Types 114–116 ascending 260 ascii 401 Aufbau einer View ermitteln 350 Ausdruck 392 Ausführungsplan 329 Planungstabelle erstellen 329 Ausführungsplan lesen 331 Auswahlabfragen dynamsich erzeugen 425 avg 262

XB

Bedingungen siehe if-Anweisung begin 124, 384 Benutzer 357 cascade-Klausel 362 create user 361 drop user 361 Passwortregeln 364 Rechte vergeben 366 Rollen zuweisen 369 Systemrechte vergeben 369 Zugriff auf Funktionen oder Prozeduren 368 Zugriff auf Tabellen und Views 366

496

between 257 binary_integer 387 bind_variable 429 Blockstruktur 384 boolean 387

XC

cascade 362, 364 ceil 399 char 387 chartorowid 315, 406 chr 400, 446 CKPT 20 close 312, 420 close_cursor 423 Cluster 119 Cobol 382 Collections 172 column_value 428 commit 306, 316–317, 320 concat 400 connect 71, 90 connect by 290, 292, 294, 332 Constraint 465 Constraints 192 check 195 default 193 disable 200 enable novalidate 200 foreign key 197 null / not null 193 primary key 194 references 198 control_files 67 count 180, 262, 391, 472 create cluster 119 create database 72 create database link 121 create function 123 create index 128, 131, 224 create or replace function 117, 124–125, 365 create or replace package 456, 471, 475 create or replace package body 137, 143, 456, 476

create or replace procedure 149 create or replace trigger 206, 210, 461, 468, 472

create or replace type 133, 174–175 create or replace type body 136, 178, 180 create or replace view 213, 216, 295 create package 141 create package body 137 create procedure 149 create profile 363 create public synonym 172 create role 220–221, 363

Stichwortverzeichnis

create sequence 156 create snapshot 164 create snapshot log 160, 166 create synonym 171 create table 115–116, 135, 185, 192, 224, 296 create table as select 461 create type 132, 134, 173–174 create user 221, 362 create view 216 create_pipe siehe dbms_pipe current of 316 currval 158 Cursor 309, 313, 420 Datensätze abrufen 420 for-Schleife 421 öffnen 420 Parameter verwenden 422 schließen 420 Statusvariablen 421 cursor 310

XD

Data Definition Language siehe DDL Data Dictionary siehe Systemviews Data Manager 236 Database Buffer Cache 20 Database Link 120 date 387 Datei öffnen siehe utl_file Datei schließen siehe utl_file Dateiverarbeitung 441 Datenbank 13–14 anlegen 69, 72 erstellen 62 Instanz 62 Instanz erstellen 67 Kontrolldatei 64 löschen 91 öffnen und schließen 89 Parameterdatei 62 Protokolldateien 63 redo log 63 Rollback-Segment 64 Rollback-Segmente 67 Struktur 62 Tablespace 63 Datenbank-Management-System 14–15, 18 arbeitsplatzorientiert 14 Client/Server-Struktur 15 File Sharing Database System 15 Instanz 19 System-Identifer 19 Datenbankname ermitteln 352 Datenbankobjekte 109 Datenbankparameter abfragen 353 Datenbank-Pipes siehe dbms_pipe


Datenbankverknüpfung 120 Datenblock 23 DB_BLOCK_SIZE 23 Datenfeld 387–390 Datenfelder 114 Datenimport 230 Datensätze sperren 306 Datentypen 193 binary_integer 387 boolean 387 char 387 date 387 number 387 raw 117 Übersicht 386 varchar2 388 varray 116 Datentypkonvertierung 396 Datum konvertieren 405 Datumsfunktionen 403 DB_BLOCK_SIZE 23 db_files 66 db_name 66 DBA Studio 94, 360 dba_col_privs 378 dba_extents 188 dba_profiles 376 dba_role_privs 376 dba_roles 376 dba_segments 188 dba_sys_privs 376–377 dba_tab_privs 377–378 dba_users 376 DBA-Studio 109 DBMS siehe Datenbank-Management-System dbms_output 190, 318, 410, 457, 475 disable 411 enable 411 new_line 411 put 411 put_line 410 dbms_pipe 446 create_pipe 450 next_item_type 449 pack_message 447 Pipe auslesen 448 Pipe erstellen 447 purge 450 receive_message 448 reset_buffer 451 send_message 447 unpack_message 449 dbms_pipe siehe remove_pipe dbms_refresh 156, 167

497

dbms_snapshot 165 dbms_space 189–190 dbms_sql 423, 456, 480 bind_variable 429 close_cursor 423 column_value 428 define_column 427 execute 423, 427 execute_and_fetch 428 fetch_rows 428 last_row_count 428 open_cursor 423 parse 423 dbms_standard 432 raise_application_error 412 dbms_utility 327 DBWR 19 DDL-Abfragen dynamsich erzeugen 423 DDL-Anweisungen 321 declare 125, 150, 310, 385, 388 decode 265, 409 default 193, 394 define_column 427 define_editor 99 Deklarationsteil 125, 385 delete 301 deleting 463, 472 descending 260 Dienst 36–37 Dienste Batchdatei zum Starten 36 disable 200 disable siehe dbms_output distinct 253 DML-Abfragen dynamsich erzeugen 423 drop cluster 119 drop constraint 194 drop database link 121 drop function 123 drop index 128, 131 drop package body 137 drop procedure 149 drop profile 363 drop public synonym 172 drop role 220–221, 363 drop sequence 156 drop snapshot 164 drop snapshot log 160, 166 drop synonym 171 drop table 115, 135, 185, 296 drop trigger 206 drop user 221, 362 drop view 213, 216

498

dual 255 Dynamisches SQL 423

XE

edit 99 Einfügeabfragen 303 enable novalidate 200 enable siehe dbms_output end 124, 384 Erstellen eines Ausführungsplans 330 exception 431, 457, 460 exec 98 execute 150, 423, 427, 459, 479 execute_and_fetch 428 Existenzprüfung 271 exists 272, 300, 302 exit 416–417 exit when 312, 417 explain plan 330 Export von Daten 475 Extend 23 extend 183, 392, 472 Extents 186, 188

XF

fclose siehe utl_file Fehlerbehandlung siehe Laufzeitfehler Fehlerbehandlungsroutine 384 Fehlermeldung ausgeben siehe raise_application_error fetch 312, 420–421 fetch_rows 428 File Sharing Database System siehe Datenbank-Management-System floor 180, 399 fopen siehe utl_file for each row 208, 211 for loop 416 for update 306 for update nowait 307 for..loop-Schleife 126 foreign key 198, 465 Formatierung von Long-Feldern 350 Formel 392 from 250–251, 269 Funktion zur Passwortkontrolle 365 Funktionen 123, 125, 149, 398, 451 Aggregatfunktionen 262 Datenkonvertierung 405 Datum 403 numerische 398 sonstige 409 Übersicht 398 Zeichenfolgen 399 Funktionen analysieren 351


XG

Ganzzahldivision 144, 399 get 99 get_line siehe dbms_output Globale Variablen 141 goto 414 grant 220 greatest 409 group by 261, 263–264 Gruppierungen 261

XH

having 261, 264 Hints 327, 342–343 Hinweismeldungen 410 Histogramme 326 host 103

XI

identified by 362 if-Anweisung 412 Implikation 258 Import von Daten 230 in 256, 273 Index 127–129, 194 index by 389 Indexaufbau ermitteln 349 Indexe ermitteln 349 initcap 400 insersect 285 insert into 116, 135, 303, 305 inserting 211, 463 Installation 25 8er-Version 26 entfernen 32 Oracle-Homeverzeichnis 26, 32 Version 8i 32 Windows-Dienste 35 Installers 25 Instanz 19–20, 35, 62 Datenbank öffnen und schließen 89 erstellen 67 INITxxxx.ORA 66 konfigurieren 66 ORADIM.EXE 88 Servicename 45 starten und stoppen 88 verwalten 87 Instanzparameter 66 control_files 67 db_files 66 db_name 66 remote_login_passwordfile 67 rollback_segments 67 instead of 210


499

Instead of Trigger 209 instr 401 integer 385, 387 intersect 281 into 418 is not null 256 is null 256

lock table 308 Logische Verknüpfungsoperatoren 257 loop 416 lower 143, 145, 400 lpad 400 LRU-Algorithmus 20 ltrim 400

XJ

XM

Joins 266, 268 connect by-Klausel 290 Existenzprüfung 271 Inner-Joins 268 Nichtexistenz prüfen 273 Outer-Joins 278 Unterabfragen 273, 276

XK

Kollektionen 172, 390 Kommentare 386 Konfigurationsdatei 66 Konfigurationsparameter siehe Instanzparameter Konstruktor 177, 391–392 Kontrolldatei 64 Konvertierfunktionen siehe Funktionen

XL

last_day 404 last_row_count 428 Laufzeitfehler Austellung der Fehler 432 Behandlung im Programm 431 exception 431 pragma exception_init 434 protokollieren 437 raise 435 raise_application_errors 433 selbst auslösen 433 Sicherungspunkte 440 sqlcode 434 sqlerrm 434 Ursachen 429 when 431 least 409 length 401 Lesekonsistenz 322 Lesetransaktion 322 level 292 LGWR 19 like 256 Listener 16, 36, 39–41, 55 Konfigurationsdatei 41 Konsole 42 Protokolldatei 42 Verwaltung 42

max 262, 275, 419 member function 178 Mengenoperationen 281 Methoden count 391–392 delete 392 exists 392 extend 392 first 392 last 392 limit 392 next 392 prior 392 trim 392 min 262, 275 minus 281, 286 mod 143–144, 399 modify 201 months_between 180, 404 mutating 470

XN

nested table 176 Net8 38–40, 69, 120 Client konfigurieren 43 Configuration Assistant 48 Configuration Assistant für 8i 52 Connection Manager 61 Grundeinstellungen 44 Host-Naming 60 Konfigurationsdateien 40 Listener konfigurieren 41 LISTENER.ORA 41 Oracle Names 61 Oracle Net8 Assistant 53 Registrierungsdatenbank 40 Servicename 45 SQLNET.ORA 43–44 TNSNAMES.ORA 43, 45 Werkzeuge zur Anpassung 48 Net8-Protokoll 481 new_line siehe dbms_output next_day 404 next_item_type siehe dbms_pipe nextval 158 Nichtexistenz prüfen 273 nls_date_format 397

500

nlssort 401 not 258 not exists 273, 285, 300, 470 not in 256 not like 256 notfound siehe Cursor nowait 307 null-Werte 256 number 387 nvl 257, 409

XO

Object Types 132–133 Objektbezogene Rechte 358 ODBC 482 Datenquelle einrichten 485 Passthrough-Abfragen 485 Verbindungszeichenfolge 489 Online-Dokumentation 18 open 312, 420 Open Database Connectivity 482 open_cursor 423 Operatoren 251, 392–393 || 124 Logische Verknüpfungsoperatoren 257 Mengenoperatoren 281 Outer-Join 279 Vergleichsoperatoren 254 Optimierer 325 optimizer_mode 327 or 258 Oracle Call Interface 481 Oracle Data Control 491 Oracle Objects 491 Oracle Schema Manager 109 ORACLE_SID 70 Oracle-Homeverzeichnis 26 Oracle-Installer 25 Oracle-Protokoll-Adapter 38 Oracle-Protokoll-Adapters 39 ORADIM.EXE 68 order by 250, 260, 283 Outer-Joins 278

XP

pack_message siehe dbms_pipe Package 138, 142, 475 Package bodies 137 Package body 138–139, 142, 453 Packages 138–139, 452, 471 Pakete dbms_output 190, 318, 410 dbms_refresh 156, 167 dbms_snapshot 165 dbms_space 189


dbms_sql 423, 480 dbms_standard 412, 432 dbms_utility 327 utl_file 442, 480 Pakte dbms_pipe 446 Parameter überladen 146 Parameterleiste 125 parse 423 password_verify_function 365 Passwortregeln 364 pause 104 Pipe auslesen 448 erstellen 447 Pipe siehe dbms_pipe PL/SQL 381 PL/SQL-Engine 382 PMON 20 Potenzierung 399 power 399 pragma exception_init 434 pragma restrict_references 133, 141 prior 292 Profile 358, 363 cascade-Klausel 364 create profile 363 drop profile 363 Passwortregeln 364 Programmblock 124 Programmblöcke 384 Protokolldateien 63 Prozeduren 149, 452 Prozeduren analysieren 351 Prozeduren ausführen 150 Prozedurparameter 154 namensbezogene Übergabe 154 positionsbezogene Übergabe 154 Pseudospalten level 292 rowid 314 rownum 270 purge siehe dbms_pipe put siehe dbms_output put_line siehe dbms_output put_line siehe utl_file

XQ

Quadratwurzel 399 Queue Tables 151 quota unlimited 221

XR

raise 435 raise_application_error 207, 365, 412, 474 raise_application_errors 433


raw 117 rebuild 423 receive_message siehe dbms_pipe Rechte objektbezogen 358 Profil 358 Systemrechte 358 Rechtevergabe mit SQL 366 grant 366 revoke 366 record 387, 389 Redo Log Buffer 20 redo log Dateien 63 references 198 refresh 165 Refresh group 156 remote_login_passwordfile 67 remove_pipe siehe dbms_pipe Reorganisation eines Index siehe Index Reorganisieren eines Index 131 replace 400 Replikation 160 reset_buffer siehe dbms_pipe resize 222 restrict_references 134 returning 318–319 reverse 126 role_role_privs 377 rollback 306, 321, 475 rollback_segments 67 Rollback-Segment 64, 321 Rollback-Segmente 67 Rollen 357, 363 create role 363 drop role 363 round 399 rowid 314, 316, 387, 406 rowidtochar 315, 406 rownum 270 rowtype 396 rpad 400, 428 rtrim 400 run 98 Runden 399

XS

save 99 savepoint 323, 440 Schema 112 Benutzer-Id 113 löschen 113 Schema-Objekt Sequences 156 Snapshot logs 160 Schema-Objekte Abgleichengruppe 156

501

Ansicht 212 Array Types 114, 116 Cluster 119 Datenbank-Link 120 Funktionen 123, 125 Index 127–129 Object Types 132–133 Package 138 Package bodies 137 Prozeduren 149 Queue Tables 151 Refresh group 156 Snapshot Logs 166 Snapshots 160 Synonyms 170 Tabellen 185 Tabellentyp 172 Table Types 172 Tables 185 Trigger 203 Views 212 Warteschlangentabelle 151 Schleifen 415 Cursor-for-Schleife 421 exit 416–417 for loop 416 loop 416 Namen geben 417 while loop 416 Security Manager 359 Segment 23 Extend 23 Segmente 23, 186 Segmenttyp 188 select 250–251, 269 select..into 418 send_message siehe dbms_pipe Sequence 465 Sequences 156 Server Manager 69 Server-Manager 70, 72 @ 71 exit 70 Skript starten 71 serveroutput 410 Session beenden 353 Sessionaktivität ermitteln 355 Sessions ermitteln 353 set 410 set longwidth 1000 350 set serveroutput on 190, 317 set termout off 101 set transaction read only Lesetransaktion 322 set transaction use rollback 321

502

SGA siehe System Global Area Shared Pool 20 show errors 117, 124 shutdown 90 Sicherungspunkte 323, 440 SID siehe System-Identifer sign 399 Skripte 451 smallint 387 SMON 19 Snapshot aktualisieren 165–166 Snapshot Logs 166, 170 Snapshot logs 160 Snapshots 156, 160, 163–164, 168, 170 Sortieren 259 lexikalisch 401 Spaltenbezogene Rechte anaylsieren 378 Speicherbelegung 186 Sperrungen 306, 308 Sperrungen ermitteln 354 spool 101 Sprungmarken 414 SQL 249 SQL*Loader 236 feste Satzlänge 239 logische Datensätze 244 Steuerdatei 241 variable Satzlänge 243 SQL*Loaders 238 SQL*Net 38–39 SQL*Plus 96–97, 100, 103 Abfragen ausführen 97 accept 102 AIX 96 Ausgaben umleiten 101 Benutzereingaben 102 Betriebssystembefehle 103 define_editor 99 edit 99 Eingabepuffer 98 exec 98 get 99 host 103 Kommandozeilenparameter 100 Laden und Speichern von Dateien 99 MS-DOS 97 pause 104 run 98 save 99 Skript starten 100 spool 101 Texteditor 99 Windows 97 sqlcode 434 SQL-Editor 96


sqlerrm 434 SQL-Worksheet 105–106 SQR 382 sqrt 399 Standardwert festlegen 193 start with 291 startup 71, 90 stddev 262 Stichtagsbestände 170 Storage-Klausel 186 storage-Klausel 188 Storage-Manager für Oracle8 93 für Oracle8i 94 Protokollierung 94 Systembefehle analysieren 94 Structured Query Language siehe SQL substr 400 Suchen und Ersetzen 400 sum 262 SVRMGR30.EXE 69 SVRMGRL.EXE 69 Synonyms 170 sysdate 404, 463 System Global Area 19 System-Identifer 19 Systemrechte 358 Systemrechte einer Rolle ermitteln 377 Systemrechte ermitteln 376 Systemrechte vergeben 369 Systemview Aufbau einer View ermitteln 350 user_views 350 Systemviews 346, 375 all_clusters 119 all_db_links 123 all_ind_columns 131 all_indexes 131 all_views 214 Benutzer und Rollen analysieren 376 Datenbankname ermitteln 352 Datenbankparameter abfragen 353 dba_col_privs 378 dba_extents 188 dba_profiles 376 dba_role_privs 376 dba_roles 376 dba_segments 188 dba_sys_privs 376 dba_tab_privs 377 dba_users 376 Funktionen oder Prozeduren analysieren 351 Indexaufbau ermitteln 349 Indexe ermitteln 349


role_role_privs 377 Rollen ermitteln 376 Sessionaktivität ermitteln 355 Sessions ermitteln 353 Spaltenbezogene Rechte 378 Sperrungen ermitteln 354 Systemrechte einer Rolle ermitteln 377 Systemrechte ermitteln 376 Tabellen analysieren 347 Tabellenstruktur analysieren 347 Trigger analysieren 351 Übergabeparameter ermitteln 352 user_arguments 352 user_indexes 349 user_source 351 user_tab_columns 347, 349 user_tables 347 user_triggers 351 user_updatable_colums 215 v$database 352 v$lock 354 v$locked_object 354 v$parameter 353 v$sessions 353 v$sql 355 Zugriffsrechte analysieren 355

XT

Tabelle ändern 201 Tabelle kopieren 201 Tabelle löschen 302 Tabellen 185 Tabellen analysieren 347 Tabellen sperren 308 Tabellenstruktur analysieren 347 Tabellentyp 172 table 388 table is mutating 470 table of 390 Table Types 172 Tables 185 Tablespace 21–22, 63, 186, 188, 222 Datei hinzufügen 222 Dateien umziehen 223 vergrößern 222 Textfeld formatieren 350 TNS siehe Transparent Network Substrate TNS_ADMIN 40 to_char 206, 406 to_date 406 to_number 406 Transaktion 319 commit 320 in DDL-Anweisung 321 Lesekonsistenz 322

503

Lesetransaktion 322 rollback 321 Rollback-Segment zuweisen 321 savepoint 323 set transaction 321 Sicherungspunkte 323 translate 401 Transparent Network Substrate 38 Trigger 203, 206–207, 454, 461–462, 465 Ausführungsschema 470 deleting 463 inserting 463 mutating table 470 updating 463 Trigger analysieren 351 Trigger einund ausschalten 212 trunc 399, 404 truncate table 302 Tuning von Abfragen 324 analyze table 326 Ausführungsplan 329 Ausführungsplan erstellen 330 Ausführungsplan lesen 331 datenbankübergreifend 340 dbms_utility 327 explain plan 330 Grundregeln 336 Gruppierungen 341 Hints 327, 341 Histogramme 326 Joins und Mengenoperationen 337 kostenbasierte Optimierung 325 Operationen 334 Optimierer 325 optimizer_mode 327 regelbasierte Optimierung 325 Struktur und Aufbau 339 Unterabfragen 338 Views 340 type 389, 396, 471

XU

Übergabeparameter ermitteln 352 Überladen von Parametern 146 uid 409 union 281, 283 union all 281, 285 unpack_message siehe dbms_pipe Unterabfragen 271, 273, 276, 299, 301 Unterabfragen mit connect by 294 update 116, 298 updating 211, 463, 472 upper 143, 145, 401 user 409, 463 user_arguments 352 user_indexes 349

504

user_source 351 user_tab_columns 347, 349 user_tables 347 user_triggers 351 user_updatable_colums 215 user_views 350 userenv 409 utl_file 442, 480 Datei öffnen 443 Datei schließen 443 Datensätze lesen 444 Datensätze schreiben 445 fclose 443 fclose_all 444 fopen 443 get_line 444 new_line 445 put 445 put_line 445 Verzeichnisse freigeben 442 utl_file.fclose 443 utl_file.get_line 444 utl_file.put_line 445

XV

v$database 352 v$lock 354 v$locked_object 354 v$parameter 353 v$sessions 353 v$sql 355 varance 262


varchar2 388 Variablen anlegen 385 implizite Konvertierung 396 Initialisierung 394 null-Werte 395 Sichtbarkeit 385 Typableitung 395 Wertzuweisung 385 varray 116–117, 134, 388 Varrays 390 Vergleichsoperatoren 254 View Aufbau ermitteln 350 Views 212 Visual Basic 382 Vorzeichenfunktion 399

XW

Warteschlangentabellen 151 when 431 where 250, 254, 269 while loop 416 Windows-Dienste 35

XZ

Zahl konvertieren 405 Zahlengenerator 156 Zugewiesene Rollen ermitteln 376 Zugriffsrechte analysieren 355 Zugriffsrechte mit SQL vergeben 366

Oracle-Programmierung. Datenbankprogrammierung und -administration GERMAN

ADO 2.5 - VB-Datenbankprogrammierung für Profis GERMAN

Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN

Räuchern und Pökeln GERMAN

Ajax und Java German

Erlebnis und Bildung German

Arbeits- und Organisationspsychologie GERMAN

Bilanzanalyse und Kennzahlen German

Wissensproduktion und Wissenstransfer German

Internet Information Server 5.0 . Administration und Praxisbeispiele

Mambo: Installation, Administration, Anwendung und Entwicklung

Internet Information Server 5.0 . Administration und Praxisbeispiele

Eis, Sorbet und Co. GERMAN

Brotaufstriche. Pikant und süß GERMAN

Dionysos und das Dionysische German

Mind Mapping und Gedächtnistraining GERMAN

Permakultur kurz und bündig GERMAN

COBIT kompakt und verständlich GERMAN

Graphen- und Netzwerkoptimierung (German Edition)

Festigkeitslehre: Aufgaben und Losungen GERMAN

Tantra. Einführung und Grundlagen GERMAN

Algorithmen und Datenstrukturen (German Edition)

Rentierhorn und Erlenholz GERMAN RUSSIAN

Wavelets. Theorie und Anwendungen. GERMAN

Lüftung und Sanitär (Baukonstruktionen) GERMAN

Darwin und die Evolution GERMAN

PHP und MySQL Easy GERMAN

Aufgabensammlung Werkstoffkunde und Werkstoffprufung German

Sprache, Kultur und Zielgruppen German

Konzentrative und analytische Meditation GERMAN

Zwischen Enthüllen und Verstecken German

Oracle-Programmierung. Datenbankprogrammierung und -administration GERMAN

ADO 2.5 - VB-Datenbankprogrammierung für Profis GERMAN

Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN

Räuchern und Pökeln GERMAN

Ajax und Java German

Erlebnis und Bildung German

Arbeits- und Organisationspsychologie GERMAN

Bilanzanalyse und Kennzahlen German

Wissensproduktion und Wissenstransfer German

Internet Information Server 5.0 . Administration und Praxisbeispiele

Mambo: Installation, Administration, Anwendung und Entwicklung

Internet Information Server 5.0 . Administration und Praxisbeispiele

Eis, Sorbet und Co. GERMAN

Brotaufstriche. Pikant und süß GERMAN

Dionysos und das Dionysische German

Mind Mapping und Gedächtnistraining GERMAN

Permakultur kurz und bündig GERMAN

COBIT kompakt und verständlich GERMAN

Graphen- und Netzwerkoptimierung (German Edition)

Festigkeitslehre: Aufgaben und Losungen GERMAN

Tantra. Einführung und Grundlagen GERMAN

Algorithmen und Datenstrukturen (German Edition)

Rentierhorn und Erlenholz GERMAN RUSSIAN

Wavelets. Theorie und Anwendungen. GERMAN

Lüftung und Sanitär (Baukonstruktionen) GERMAN

Darwin und die Evolution GERMAN

PHP und MySQL Easy GERMAN

Aufgabensammlung Werkstoffkunde und Werkstoffprufung German

Sprache, Kultur und Zielgruppen German

Konzentrative und analytische Meditation GERMAN

Zwischen Enthüllen und Verstecken German

Recommend Documents