# Einleitung

Grundlagen von SQL sollten vorhanden sein. Dieses Buch versteht sich mehr als Nachschlagewerk und Einführung auf einem sehr einfachen Level. Es ist auch ideal für Umsteiger anderer Programmiersprachen weil hier versucht wird, auf einfachste Art und Weise, das Datenbanksystem der Firma Oracle etwas näher zu bringen.

# SQL*PLUS
## Aufruf-Möglichkeiten
### iSQL

iSQL ist eine Möglichkeit, mit dem Datenbankserver Kontakt aufzunehmen alleine über einen beliebigen Web-Browser. Es muss keine Software auf dem Client installiert werden. Diese Möglichkeit gibt es jedoch nur bei der Version 10g. Schon bei der Version 11g gibt es diese Möglichkeit nicht mehr.
Aufruf bei Oracle 10g über die URL: http://<host>:5560/isqlplus Dabei muss anstelle von <host> der Computername angegeben werden. Den Computernamen eines Servers, an dem man gerade angemeldet ist, kann man bei Windows herausfinden durch:
Start / Einstellungen / Systemsteuerung / System
In Reiter Netzwerkidentifikation findet man den Computernamen angegeben.
Über den Web-Browser kann man dadurch auf alle Datenbank-Server zugreifen, deren Servername man kennt und bei denen eine Anmeldung über iSQL und den Port 5560 nicht explizit deaktiviert ist.
Natürlich ist eine Identifikation an diesem Server mit einer Oracle-User-ID und Passwort auch noch erforderlich, aber viele Datenbanken haben ja den User SCOTT mit dem Passwort TIGER...
Über diesen Aufruf kann man sich nicht als SYSDBA oder SYSOPER anmelden.

### iSQL/dba

Um administrative Arbeiten auszuführen, die eine Anmeldung AS SYSDBA oder AS SYSOPER erfordern, kann die folgende URL benutzt werden: http://<host>:5560/isqlplus/dba
Nach einem erfoglreichen Connect mit einem User in der SYSDBA-Rolle kann die Datenbank z.B. heruntergefahren werden oder neu gestartet werden.

### SQL*Plus als Windows-Tool

Das SQL*Plus-Worksheet war lange Zeit die im Oracle-Lieferumfang gehörende Standard-Client-Software, um SQL-Befehle ausführen zu lassen. Seit der Version 11g gibt es diese Möglichkeit nicht mehr. An die Stelle dessen tritt nun der Oracle SQL Developer.
Aufrufmöglichkeiten:
* Als Befehl in einem CMD-Fenster: SQLPLUSW
* Start / Ausführen / SQLPLUSW
* Start / Programme / Oracle / Anwendungsentwicklung / SQL Plus
* Oder C:\oraclexe\app\oracle\product\11.2.0\server\bin\sqlplus.exe

### SQL*Plus als Command-Line-Tool

Als Befehl in einem CMD-Fenster: SQLPLUS. Dadurch wird die Verwendung von SQL*Plus per Shell-/Batchskript ermöglicht. Diese Variante gab es schon immer und sie ist auch in der aktuellen Version (11g) noch vorhanden.
Als Befehlsparameter kann man einen Connect-String angeben. Angenommen, man möchte eine Anmeldung als User SCOTT (mit dem Passwort TIGER) an einer lokalen Datenbank vornehmen, dann sind folgende Aufrufe möglich:
Wenn man das Passwort nicht direkt angibt, wird man anschließend aufgefordert, das Passwort einzugeben. Der Vorteil dabei ist, dass das eingegebene Passwort nicht auf dem Bildschirm sichtbar ist. Da wir in diesem Beispiel den Datenbank-Namen nicht angegeben haben, verwendet SQL*Plus den in der Registry angegebenen Datenbank-Namen.
Aufbau zu einer entfernten Datenbank d.h. zu einem Datenbank-Server, der über das Netzwerk zu erreichen ist und der in der lokal gespeicherten Datei TNSNAMES.ORA eingetragen ist. Der Name der Datenbank ist z.B. ORCL. Folgende Aufrufe sind möglich:
Man kann auch SQL*Plus starten ohne ein Login auszuführen:
Danach ist SQL*Plus gestartet, aber es besteht noch keine Verbindung zu einer Datenbank. In diesem Zustand kann man lediglich die SQL*Plus-Umgebungsvariablen abfragen oder ändern und eben einen Connect-Befehl anweisen z.B.:
Das gibt einem die Möglichkeit, mehrere SQL-Befehle in einer Datei als Skript zu speichern und den Connect-Befehl ebenfalls im Skript anzugeben. Wenn das Skript dann noch mit dem Befehl disconnect endet, dann ist es eine in sich abgeschlossene Einheit, die eine Verbindung zu einer Datenbank aufbaut, eine Verarbeitung ausführt und die Verbindung wieder beendet. Wenn man beim Aufruf von SQL*Plus gleich schon das Passwort mitangibt, dann hat das den Nachteil, dass bei MS-Windows das Passwort im Window-Header sichtbar ist.

### SQL*Plus-Session beenden

Alle SQL*Plus-Varianten können mit dem Befehl EXIT oder QUIT wieder beendet werden.
Sowohl das Beenden über EXIT oder QUIT, als auch das sofortige schliessen (in Windows) über Fenster schliessen / x-Button führt implizit ein commit auf dem Datenbank-Server aus.

## Interaktives Arbeiten
### Allgemeine Formatierung ändern

Nach dem Aufruf einer SQL*Plus-Session ist es in vielen Fällen erforderlich, die Formatierung der Server-Ausgaben zu ändern.
Die Formatierung wird im SQL*Plus in Systemvariablen (auf dem Client-Computer) gespeichert.
Die Systemvariable LINESIZE gibt an, wie viele Zeichen in einer Zeile maximal ausgegeben werden sollen. Wenn die Ausgabezeile länger ist, dann wird der Rest in der nächsten Zeile ausgegeben. Der Default-Wert dieser Systemvariablen ist 80.
Die Systemvariable PAGESIZE gibt an, nach wievielen Ausgabezeilen die Überschrift erneut ausgegeben werden soll. Der Default-Wert dieser Systemvariablen ist 14.
Die Inhalte der SQL*Plus-Systemvariablen kann man mit dem Befehl SHOW ausgeben lassen:
Wenn viele Tabellenspalten ausgegeben werden sollen, dann können die vielen Zeilenumbrüche störend sein. Auch die wiederholte Ausgabe der Spaltenüberschriften kann störend wirken.
Die SQL*Plus-Systemvariablen kann man mit dem SET-Befehl ändern. Die Änderung ist jedoch nur für die aktuelle Session aktiv:
Es gibt noch wesentlich mehr Systemvariablen, mit denen man die Formatierung beeinflussen kann. Eine vollständige Beschreibung findet man im SQL*Plus-Manual. (Siehe Literatur-Liste)

### Formatierung bestimmter Spalten ändern

Wenn Daten durch den SELECT-Befehl ausgegeben werden, dann wird für jede Spalte so viel Platz gelassen, dass auch ein Wert mit maximaler Länge ausgegeben werden kann.
Beispiel:
Wenn man die Formatierung ändern will, dann kann man mit dem Befehl COLUMN FORMAT das Ausgabeformat ändern. Die Befehle können auch abgekürzt werden als COL FOR.
Beispiel: Die Spalte ENAME soll in maximal 6 Zeichen ausgegeben werden und die Spalte SAL soll mit Tausenderpunkten und zwei Nachkommastellen ausgegeben werden:
Wenn man der Wert einer Spalte in dem vorgegebenen Format nicht ausgegeben werden kann (wenn der Platz nicht ausreicht), dann wird automatisch ein Zeilenumbruch ausgeführt.
Beispiel:
und bei numerischen Werten wird bei Platzmangel der vorhandene Platz mit dem Hash-Zeichen aufgefüllt.
Eine Formatierung kann wieder aufgehoben werden mit dem Schlüsselwort CLEAR.

### Login-Skript erstellen

Um die Änderungen an den Systemvariablen des SQL*Plus-Client nicht bei jedem Start einer Session erneut setzen zu müssen, können die Änderungen in einem Login-Skript eingetragen werden, das bei jedem Aufbau einer neuen Session automatisch ausgeführt wird. Bei einer Standard-Installation der Oracle-Version 10g unter Windows befindet sich das Login-Skript in dem folgenden Verzeichnis:
Bei der Version 11g liegt es hier:
Sollte kein schreibender Zugriff auf die oben angegebene Datei möglich sein, kann man in dem aktuellen Verzeichnis oder in dem per Umgebungsvariable gesetzten Verzeichnis $ORACLE_PATH eine Datei namens login.sql erstellen, die durch SQL*Plus beim Start nach der glogin.sql eingelesen wird. Eventuell doppelte Angaben überschreiben demnach die Werte, die beim Einlesen der glogin.sql gesetzt worden sind.

### Editor

Im SQLPLUS und im SQLPLUSW kann ein Editor aufgerufen werden, um den letzten SQL-Befehl bzw. den letzten PL/SQL-Block zu verändern.
Der Aufruf erfolgt mit dem Befehl EDIT (Abkürzung: ED). Nach dem Editieren des Befehls muss die Seite gespeichert werden und der Editor beendet werden. Dann kann der veränderte Befehl mit / oder mit RUN (Abkürzung: R) ausgeführt werden.
In der Systemvariablen _EDITOR ist der Name des Editors eingetragen, der bei EDIT aufgerufen wird.
Man kann auch einen anderen Editor angeben, z.B. den VI-Editor:

### Readline Funktionalität

Will man dieselbe Funktionalität wie in einer Shell haben (alle vorhergehenden Befehle, durchsuchen der Befehle etc.) hilft das Programm rlwrap (readline wrapper). Das Programm liegt den meisten Distributionen als Paket bei, unter Ubuntu installiert man es mit apt-get install rlwrap. Der Aufruf von SQLPLUS erfolgt dann so:

### Befehl / Skript ausführen

Ein SQL-Statement wird mit einem Semikolon oder einer Leerzeile abgeschlossen. Bei einem Abschluss durch ein Semikolon wird der SQL-Befehl auch gleich ausgeführt.
Ein PL/SQL-Block kann aus mehreren SQL-Statements bestehen. Er wird erst ausgeführt, wenn der Block abgeschlossen wurde. Das geschieht durch eine Zeile, in der nur ein einzelner Punkt oder ein Slash eingetragen ist. Bei einem Slash wird der PL/SQL-Block auch gleich ausgeführt.
Mit dem Befehl RUN (Abkürzung: R) oder einem Slash (eine Eingabezeile, in der nur ein Slash eingegeben wird) wird der letzte SQL-Befehl bzw. der letzte PL/SQL-Block erneut ausgeführt. Der Unterschied ist nur, dass bei RUN der SQL-Befehl bzw. der PL/SQL-Block, der ausgeführt werden soll, noch einmal ausgegeben wird, während bei dem Slash nur ausgeführt wird.
Mit dem Befehl LIST (Abkürzung: L) kann man den letzten SQL-Befehl bzw. den letzten PL/SQL-Block ausgeben ohne ihn auszuführen.
Mit dem Befehl SAVE <Dateiname> (Abkürzung: SAV <Dateiname>) kann man den letzten SQL-Befehl bzw. den letzten PL/SQL-Block in die Datei <Dateiname> ausgeben. Wenn man dabei keine Extension angibt, dann wird automatisch .sql ergänzt.
Mit dem Befehl GET <Dateiname> kann man SQL-Statements aus einer Datei in den Buffer laden. Die gelesenen Statements werden dabei nicht ausgeführt.
Wenn man SQL-Statements aus einer Datei lesen und gleichzeitig ausführen will, dann kann man GET und danach RUN verwenden oder START <Dateiname> (Abkürzung: @<Dateiname>) angeben. Der Unterschied ist nur, dass GET und RUN nur ein einziges SQL-Statement oder einen einzigen PL/SQL-Block in den Buffer übertragen können, während mit START auch beliebig viele SQL-Statements und PL/SQL-Blöcke aus der Datei ausgeführt werden können.
In der Datei, die mit START oder @ ausgeführt wird, können weitere Skripte eingebunden werden, indem diese ebenfalls mit START oder @ benannt werden. Die weiteren Skripte werden bei einem Aufruf mit @ <Dateiname> in dem Verzeichnis gesucht, aus dem SQLPLUS gestartet wurde. Man kann ein weiteres Sktipt auch mit @@ <Dateiname> aufrufen. Der Unterschied besteht darin, dass <Dateiname> in dem Verzeichnis gesucht wird, in dem das aufrufende Skript liegt.

### Tabellenstruktur ausgeben

Mit dem DESCRIBE-Befehl (Abkürzung: DESC) kann die Struktur einer Tabelle, Prozedur oder Funktion ausgegeben werden.
Beispiel:
Sollten nach den Spaltennamen zuviele Leerstellen kommen, ist die Variable LINESIZE zu hoch eingestellt, dann mit set linesize 80 diese kleiner setzen, und den describe Befehl wiederholen.
Die selben Informationen erhält man auch mit einem Zugriff auf die Katalog-Tabelle USER_TAB_COLUMNS (ohne störende 1000 Leerzeichen dazwischen). Wie bei allen Zugriffen auf Katalog-Tabellen muss man darauf achten, dass der Tabellenname in Grossbuchstaben angegeben wird:

### SQL*Plus-Austausch-Variablen - erstes Beispiel

Wenn man eine Austausch-Variable das erste Mal mit & verwendet, dann wird bei jeder Skriptausführung eine Eingabeaufforderung ausgeführt.
Wenn das Skript ein zweites Mal ausgeführt wird, dann muss erneut ein Wert für die Austauschvariable eingegeben werden, allerdings kann dann ein anderer Wert eingegeben werden.

### Unterschied zwischen & und &&

Wenn die Austausch-Variable das erste Mal mit && verwendet wurde, dann wird nur bei diesem ersten Auftreten eine Eingabe verlangt. Wenn man die Ausführung mit / wiederholt, dann erfolgt keine Eingabeaufforderung mehr.

### Eingabeaufforderung mit PROMPT und ACCEPT

Die Eingabe einer Austausch-Variablen kann explizit durch den Befehl ACCEPT (Abkürzung: ACC) angewiesen werden, ohne dass auf dem Datenbank-Server ein SQL-Befehl ausgeführt werden muss.
Mit ACCEPT PROMPT kann noch ein Kommentar zu der Eingabeaufforderung definiert werden.
PROMPT und ACCEPT eignen sich vor allem für die Ausführung von SQL-Skripten, die in einer Datei abgelegt sind.
Beispiel: In der Datei s.sql stehen das folgende Skript:
Das Skript wird ausgeführt:

### Deklaration mit DEFINE

Austausch-Variable können auch mit DEFINE (Abkürzung: DEF) bekannt gemacht werden. Wenn sie danach verwendet werden, dann keine Eingabeaufforderung mehr ausgeführt.
Selbst wenn man den SQL-Befehl erneut ausführt, wird keine Eingabeaufforderung mehr ausgeführt. Der einmal definierte Wert wird wieder verwendet.

### Eingabeaufforderung für einen String-Wert

Wenn man mit Austausch-Variablen String-Werte verarbeiten will, dann muss man sich grundsätzlich entscheiden, ob in der Variablen der String mit oder ohne Anführungszeichen gespeichert werden soll. Im ersten Fall muss auch der Anwender bei der Eingabeaufforderung den String mit - und um zweiten Fall ohne - Anführungszeichen eingeben.
Beispiel für die Speicherung mit Anführungszeichen:
Beispiel für die Speicherung ohne Anführungszeichen:

### Gibt es ein Escape-Zeichen?

Wie kann man denn in einem SQL*Plus-Skript nach einem String suchen, der mit & beginnt ohne dass die nachfolgenden Buchstaben als Austauschvariable interpretiert werden?
Mit set define kann das & Zeichen geändert werden:
Mit set define off kann die Suche nach Austauschvariablen ausgeschaltet werden. Dann werden alle Zeichen so belassen, wie sie angegeben sind. Das kann dann sinnvoll sein, wenn man in einem Skript Strings mit allen möglichen Sonderzeichen verwenden möchte, ohne dass eines davon als Austauschvariable interpretiert werden soll.

### Punkt als Trennzeichen

Wenn man eine Variable ohne Leerzeichen an ein anderes Literal anschließen möchte, dann muss man den Punkt als Trennzeichen verwenden.
Beispiel für numerische Werte
Beispiel für Zeichenketten

## Nutzung von SQL*Plus in Skripten
### einfaches Beispiel

Man kann in einer Datei SQL-Befehle und PL/SQL-Blöcke speichern, die häufig ausgeführt werden müssen.
Beispiel: In der Datei ana.sql stehen die folgenden Befehle:
Diese Datei kann ausgeführt werden in einer SQL*Plus-Session:
Wenn das Skript sehr umfangreich ist und man nicht möchte, dass die Meldungen 'Tabelle wurde analysiert.' auf dem Bildschirm ausgegeben werden, dann kann man die Systemvariable FEEDBACK auf OFF setzen. Das Skript ana.sql wird dann wie folgt erweitert:

### Kommentare

Es gibt drei Möglichkeiten, in einem Skript Kommentare zu verfassen:

### Bind-Variablen

Das kann man in einem SQL*Plus-Fenster ausführen. (Mit dem Programm TOAD geht das leider nicht)

### Whenever-Befehl

Wenn bei der Ausführung der Befehle eines Skripts Fehler auftreten, dann wird normalerweise der fehlerhafte Befehl übersprungen und mit den nachfolgenden Befehlen fortgesetzt. Wenn man jedoch bei einem Fehler die weitere Verarbeitung abbrechen will, dann kann man an den Anfang des Skripts eine WHENEVER-Anweisung setzen:
Oserror betrifft Fehler aus dem umgebenden Betriebssystem. Sqlerror betrifft Fehler bei der Ausführung der SQL-Statements vom Oracle-Server.
Wenn bei einem Fehler die Verarbeitung fortgesetzt werden soll, dann kann man das auch explizit anweisen:
Die Whenever-Anweisungen beziehen sich immer auf alle nachfolgenden SQL-Befehle.

### Return-Code abfragen

SQL*Plus kann beim EXIT Returncodes übergeben.
ein SUCCESS liefert als RC 0, FAILURE als RC 1 und WARNING als RC 2. Des Weiteren kann ein numerischer Wert (0..255) übergeben werden, der dann im RC steht:

### Cursor definieren

Mit SQL*Plus können Cursor-Variablen definiert werden, die in einem PL/SQL-Block verwendet werden. In dem nachfolgenden Beispiel wird eine Cursor-Variable mit dem Namen C deklariert, geöffnet und - nach Beendigung des PL/SQL-Blocks - ausgegeben. Die Ausgabe wird durch die Autoprint-Option aktiviert.
Cursor-Variablen kann man auch dafür verwenden, um Prozeduren oder Funktionen aufzurufen, die einen Cursor als Parameter erwarten.

## Tipps und Tricks
### Skript generieren

Ein Administrator muss oft verschiedene Wartungs-Arbeiten für alle Tabellen ausführen, die bestimmte Kriterien erfüllen. So zum Beispiel das Aktualisieren von Statistikdaten.
Dabei kann es sein, dass diese SQL-Befehle für hunderte oder gar tausende Tabellen ausgeführt werden müssen. Natürlich wird ein Administrator solche Befehle nicht für jede Tabelle von Hand eintippen, sondern er könnte sich ein Skript dafür generieren.
Beispiel: Mit dem folgenden Befehl werden Analyze-Befehle für alle Tabellen des Users SCOTT generiert.
Nun kann man den Output entweder mit der Maus kopieren und erneut ausführen lassen, oder man läßt den Output gleich in eine Datei mitschreiben. Das kann man mit dem SPOOL-Befehl machen. Das hat den Vorteil, dass man das Skript noch in einem Editor nachbearbeiten kann, bevor man es ausführt. Nach der Ausführung steht das Skript immer noch zur Verfügung und man kann zu einem späteren Zeitpunkt noch einmal nachschauen, welche Befehle ausgeführt wurde.
Wenn man den Output in eine Datei protokolliert, dann wäre es nützlich, die Spaltenüberschriften und die Ergebnis-Meldung zu deaktivieren. Die Befehle dafür sehen dann so aus:
In der Datei x.sql wurde das Skript generiert. Hier muss man evtl. noch die Protokollierung des SPOOL OFF entfernen, danach kann man es ausführen:

### Serveroutput vergrößern

Um die Ausgaben von ausgeführten Packages/Prozeduren auch zu sehen, muss diese Ausgabe auch eingeschaltet werden, und gross genug sein:
So wird eine Prozedur zwar ausgeführt, es wird aber nichts ausgegeben. Um die Ausgabe zu erhalten, muss der Serveroutput eingeschaltet werden:
Oracle schreibt diese Ausgaben erst mal in einen Buffer, und gibt diesen Buffer erst am Ende aus. Dabei kann es passieren, dass der Fehler ORA-20000: ORU-10027: buffer overflow, limit of 2000 bytes auftritt, der besagt, dass dieser Buffer übergelaufen ist. Diesen kann man bis zu einer Grösse von 1000000 vergrössern:

### Datenbankserver starten und stoppen

Der Vorteil von SQL*Plus ist, dass man damit auch auf einen Datenbank-Server zugreifen kann, bei dem die Datenbank-Instanz noch nicht gestartet ist. Das liegt daran, dass das sqlplus Programm auf einem Client-Computer ausgeführt wird. Sqlplus nimmt zunächst Kontakt mit dem Listener auf dem Datenbank-Server auf. Der Listener ist ein Prozess, der in der Regel aktiv bleibt, auch wenn die Datenbank heruntergefahren ist. Der Listener hat die Möglichkeit, ein Hochfahren der Datenbank-Instanz zu bewirken.
Der User SCOTT hat nicht das SYSDBA-Privileg, daher kann er sich an einer inaktiven Instanz nicht anmelden:
Jedoch der User SYS hat das SYSDBA-Privileg, daher kann er sich anmelden und die Instanz hochfahren:
Das Stoppen und Herunterfahren einer Datenbank-Instanz kann genauso durch SQL*Plus ausgeführt werden - vorausgesetzt, der User hat die SYSDBA-Berechtigung:
Das Starten und Stoppen einer Datenbank wird ausführlicher beschrieben im Kapitel Oracle: Datenbank starten.

## Literatur

* download.oracle.com SQL*Plus User's Guide and Reference der Oracle Version 11.1
* download.oracle.com SQL*Plus Quick Reference der Oracle Version 11.1
* www.orafaq.com/wiki/SQL*Plus_FAQ

# SQL Developer

Der SQL Developer von Oracle (zuvor Projekt Raptor) ist ein grafisches Entwicklerwerkzeug (IDE) für alle Operationen, welche an einer Oracle Datenbank vorgenommen werden können:
* Anlegen und Bearbeiten von Tabellen und Indices
* Entwickeln und debuggen von PL/SQL Code
* etc.
Er ist komplett in Java geschrieben und verwendet den JDBC Thin-Driver (d. h. er benötigt keinen extra installierten Treiber - lediglich ein lauffähiges JDK). Da er kostenlos verwendet werden kann, ist er besonders bei kleineren Firmen sehr beliebt.
Der SQL Developer ersetzt das SQL*Plus-Worksheet, das seit der Version 11g nicht mehr dabei ist.
Beim ersten Start von SQL Developer muss der Pfad für die Java-Version angegeben werden. Bei der Oracle-Version 11g ist immer eine Java-Version mit dabei. Man findet sie im Verzeichnis:

# Toad
## Allgemeines

TOAD (Tool for Oracle Application Developer) ist ein Werkzeug zur Entwicklung und Administration von Oracle-Datenbanken und -Anwendungen aus dem Haus Quest Software. Er zeichnet sich hauptsächlich durch seine Vielfältigkeit und umfangreichen Funktionen aus und ist dabei übersichtlich gestaltet und leicht zu bedienen. Toad enthält folgende Bereiche: SQL Editor, Schema Browser, Procedure Editor, SQL Modeler. Daneben bietet es Funktionen für Datenbankadministratoren.

## SQL Editor

Editor mit Syntaxhervorhebung, in dem SQL- und PL/SQL-Skripte formuliert, gespeichert und ausgeführt werden können.

## Schema Browser

Der Schema Browser erlaubt die Pflege und Verwaltung aller Oracle-Objekte (Tabelle, Index, View, Sequence, Package, Trigger etc.). Zur Tabellenpflege gehört auch die editierbare, tabellarische Darstellung von Tabelleninhalten/Daten.

## Procedure Editor

Der Procedure Editor dient der Entwicklung und dem Debugging von PL/SQL-Prozeduren, -Funktionen und -Packages. Seit der Version 9 von Toad sind SQL Editor und Procedure Editor zu einem Editor zusammengefasst.

## ER Diagram

ER Diagram erstellt eine grafische Darstellung des Tabellenschemas mit Fremdschlüsselbeziehungen und liefert damit weniger ein ER-Diagramm sondern eher ein Servermodell-Diagramm vergleichbar mit dem Oracle Designer.

# Aqua Data Studio

Aqua Data Studio
Aqua Data Studio ist ein Datenbank Abfrage und Administration Programm für Sql-Datenbanken wie zum Beispiel Oracle, welches auch ohne SQL*PLUS funktioniert. Es basiert auf JDBC und hat dadurch den Vorteil, dass man nicht erst alles bei Oracle lange zusammen suchen muss, sondern relativ einfach und schnell „loslegen“ kann.
Aqua Data Studio ist für Schulungszwecke, also für nicht kommerzielle Zwecke kostenlos. Selbst die kommerziellen Lizenzen sind wesentlich günstiger als eine Lizenz von Quests Toad.

# Table
## Tabellendefinition

Es gibt drei Arten von Tabellen:
* Relationale Tabellen
* Objekttabellen
* XML Tabellen
Die relationale Tabelle ist die Grundstruktur, um Daten zu halten. Sie ist in der Form von Spalten (Columns) und Zeilen (Rows) aufgebaut.

### Beispielscript

RELTABLE
Objekttabellen erweitern relationale Tabellen um die Möglichkeit der Nutzung von Objekttypen. Mindestens eine Spalte der Tabelle beinhaltet die Definition eines Objekttyps.
OBJTABLE
OBJTYPE

## Check-Constraints

Bereits bei der Definition einer Tabelle, kann man festlegen, welche Werte oder Wertebereiche für einen Spaltenwert erlaubt oder verboten sind. Dadurch wird die Integrität der Datenbank erhöht, da nur Werte in die Datenbank eingepflegt werden können, die diesen Regeln entsprechen. Beispiel:
| NOT NULL | Bestimmt, dass der Spalte im Datensatz ein Wert zugeordnet werden muss. |
| DEFAULT | Setzt einen Vorgabewert. |
| CHECK | Ist eine Boolesche Regel, die wahr sein muss, damit der Datensatz akzeptiert wird. |

## Einfügereihenfolge ermitteln

Wenn viele Tabellen existieren, die mit Fremdschlüsseln miteinander verknüpft sind, dann kann man sich die Einfüge-Reihenfolge der Tabellen aus den Informationen im Datenbank-Distionary generieren lassen.
Beispiel für Oracle:
Diese Query verwendet Informationen aus der Dictionary-View USER_CONSTRAINTS. Durch mehrere inline-Views und einem rekursivem SQL-Statement werden die gesuchten Informationen ermittelt. Die Formulierung 'CONNECT BY PRIOR' ist in Oracle eine Möglichkeit, rekursiv vorzugehen. Es werden durch 'START WITH parent IN' zuerst alle Tabellen gesucht, die keine eigenen Fremdschlüssel haben, die aber Detail-Tabellen haben (das ist die Ebene 1). Dann werden alle Tabellen gesucht, die Fremdschlüssel zu den bereits gefundenen Tabellen haben (das ist die Ebene 2). Dann werden alle neu gefundenen Tabellen untersucht, ob sie wiederum Detail-Tabellen haben. Genau das ist die Rekursion. Sie wird so lange weiter fortgesetzt, bis alle Detail-Tabellen gefunden wurden. (Ebenen 3, 4, 5, u.s.w) Die Pseudo-Spalte LEVEL gibt in Oracle bei rekursiven SQL-Statements an, wie viele Rekursions-Schritte bereits ausgeführt wurden.
Bei der oben beschriebenen Query werden Tabellen ohne Fremdschlüssel nicht ausgegeben. Falls es Ring-Verkettungen gibt, dann werden die daran beteiligten Tabellen auch nicht ausgegeben, da sie bei der 'START WITH' Klausel nicht gefunden werden. Wenn Ring-Verkettungen vorhanden sind, dann kann man diese mit der folgenden Query ausgeben. Sie verwendet auch wieder die Inline-Views REL und EBENEN und sucht schließlich nach Tabellen in USER_TABLES, die zwar in REL enthalten sind (die also Fremdschlüssel haben), die aber nicht in der View EBENEN enthalten sind. Falls eine Ring-Verkettung nur eine einzige Tabelle betrifft, also die Tabelle einen Fremdschlüssel hat, der auf die eigene Tabelle verweist, dann ist dafür noch ein weiterer Schritt erforderlich. Solche Tabellen werden gefunden mit dem Zugriff auf REL mit der Bedingung 'WHERE parent = child'.
Die REL-View kann man auch dazu verwenden, um die dritte Gruppe von Tabellen zu finden, nämlich diejenigen, die mit Fremdschlüsseln nichts zu tun haben. Diese Tabellen haben keine eigenen Fremdschlüssel und werden auch von keiner anderen Tabelle als als Master-Tabelle referenziert. Dafür sucht man nach allen Tabellen in USER_TABLES, die weder als Parent, noch als Child in der REL-View vorkommen.

## Partitionierung

Partitionierung nennt man den Vorgang, eine große Tabelle zwecks Performanzoptimierung in kleinere Teiltabellen zu zerlegen.
Es gibt verschiedene Arten der Partitionierung:
* Range-Partitionierung
* Hash-Partitionierung
* List-Partitionierung
* Interval-Partitionierung
Ferner kann man Partitionen noch weiter in Sub-Partitionen unterteilen.

### Range-Partitionierung

Beispiel
Eine Partition mit MAXVALUE muss nicht angegeben werden. Dann allerdings können keine Werte größer oder gleich 11 für die Spalte t2 eingefügt werden.
Die Partitionierung kann auch von mehreren Spalten abhängig gemacht werden:
In einer Query kann man sich auf die einzelnen Partitionen beziehen, indem man entweder den Namen der Partition angibt, oder die Werte, die die Partitionierung beeinflussen. Beispiel:

### Hash-Partitionierung

Beispiel

### List-Partitionierung

Beispiel
Wenn keine Default-Partition angelegt wird, dann können für die Spalte ort nur die angegebenen Werte eingetragen werden.

### Interval-Partitionierung

Intervall-Partitionierung ist eine besondere Form der Range-Partitionierung, wobei die Spalte, von der die Partitionierung abhängt, den Datentyp DATE haben muss.
Beispiel
Bei dieser Tabelle werden initial die drei angegebenen Partitionen angelegt. Sobald in die Tabelle Sätze eingefügt werden, bei denen der Wert für buchungs_datum nicht in die bestehenden Partitionen passt, werden automatisch weitere Partitionen erzeugt. Dabei wird pro Monat eine neue Partition erzeugt.
Man kann die Bildung neuer Intervalle jederzeit ändern. Die Änderung beeinflusst nicht die bereits existierenden Partitionen. Nur wenn neue Partitionen nach der letzten existierenden Partition gebraucht werden, kommt die Intervall-Angabe zur Anwendung.
Beispiel zur Definition, dass neue Partitionen nur im Rhythmus von jeweils 2 Jahren angelegt werden sollen:
Beispiel zur Definition, dass neue Partitionen nur im Rhythmus von jeweils 5 Tagen angelegt werden sollen:

## Datadictionary-Views für Tabellen

In Oracle gibt es fast alle Dictionary-Views in dreifacher Ausführung:
* Views mit dem Präfix USER_ zeigen die eigenen Objekte an, also die Objekte, die im eigenen Schema erstellt sind.
* Views mit dem Präfix ALL_ zeigen alle Objekte an, für die man eine Zugriffsberechtigung hat. Das sind die Objekte im eigenen Schema und auch Objekte in anderen Schemata, für die man durch den GRANT-Befehl eine Zugriffsberechtigung erhalten hat.
* Auf Views mit dem Präfix DBA_ kann man nur zugreifen, wenn man das Administrations-Recht hat. In dieser View werden alle Objekte der gesamten Datenbank angezeigt, also auch die, auf die man keine Zugriffsrechte besitzt.
Alle Oracle Dictionary-Views sind in dem Manual Reference (nicht: SQL-Reference) beschrieben.
Einige Beispiele
Alle eigenen Tabellen einer Datenbank anzeigen:
Alle Tabellen anzeigen, auf die man zugriffsberechtigt ist:
Alle Tabellen, die es in der gesamten Datenbank gibt, anzeigen:
Alle Spaltennamen anzeigen mit den dazugehörigen Datentypen einer Tabelle:
Seit der Version 11 gibt es zusätzlich die View ALL_TAB_COLS. Der Unterschied zu ALL_TAB_COLUMNS besteht darin, dass versteckte Spalten in dieser View nicht ausgefiltert werden:
Alle Fremdschlüssel-Beziehungen und anderen Constraints anzeigen. Fremdschlüssel-Beziehungen haben den Typ 'R'. Bei DELETE_RULE = 'CASCADE' handelt es sich um eine Beziehung mit Löschweitergabe und bei 'NO ACTION' um eine Beziehung mit Lösch-Restriktion.
Tabellen-Kommentare werden in einer eigenen View bereitgestellt:
Ab der Version 11g gibt es eine eigene View zur Ausgabe von Statistik-Daten:
Zusätzliche Informationen über partitionierte Tabellen. Jede partitionierte Tabelle hat hier einen Eintrag:
Informationen über Partitionen und Sub-Partitionen. Jede Partition bzw. Sub-Partition hat hier eine eigene Zeile:

## Tabellen verkleinern

Wenn man Sätze aus einer Tabelle löscht, dann wird der Speicherplatz im Tablespace trotzdem nicht freigegeben. Alle Datenblöcke, die einmal für die Speicherung von Daten für eine bestimmte Tabelle verwendet wurden, bleiben dieser Tabelle zugeordnet und können nicht zur Speicherung von Daten in anderen Tabellen benutzt werden. Wenn man eine Tabelle nur vorübergehend mit einem großen Datenvolumen gefüllt wurde und der Speicherplatz danach für andere Tabellen zur Verfügung gestellt werden soll, dann gibt es verschiedene Möglichkeiten:
* ALTER TABLE MOVE TABLESPACE
* EXPORT / drop Table / create Table / IMPORT
* ALTER TABLE SHRINK SPACE
Die Varianten 1 und 2 haben den Nachteil, dass es eine Ausfallzeit gibt, in der andere Programme, die auf diese Tabelle zugreifen wollen, eine Fehlermeldung bekommen.
Die Variante 3 gibt es seit der Version 10g. Sie hat den Vorteil, dass die Tabelle nur durch einen Lock gesperrt wird. Andere Programme müssen so lange warten, bis die Verkleinerung fertig ist, sie bekommen aber keine Fehlermeldung.
Der Befehl ALTER TABLE SHRINK SPACE ist an bestimmte Bedingungen geknüpft:
Verkleinern kann man damit
* Tabellen
* Indizes
* indexorganisierte Tabellen
* Partitionen
* Subpartitionen
* LOB Segmente (ab Version 10.2)
* Materialized Views
Voraussetzungen
* Oracle RDBMS ab Version 10g.
* Der Tablespace muss mit der Option SEGMENT MANAGEMENT AUTO angelegt sein.
* Bei der Tabelle, die verkleinert werden soll, muss ROW MOVEMENT aktiviert sein.
Einschränkungen
* Die Tabelle darf nicht komprimiert sein.
* Die Tabelle darf keine FUNCTION BASED Indizes besitzen.
* Die Mastertabelle einer ON COMMIT MATERIALIZED VIEW kann nicht verkleinert werden.
* ROWID MATERIALIZED VIEWS müssen nach dem Verkleinern neu aufgebaut werden.
* Tabelle darf keine LOB oder LONG Spalten besitzen (nur in Version 10.1).
* Der Befehl SHRINK SPACE ist eine Art der Reorganisation. Dadurch ändern sich die ROWIDs.

# View
### Permanent definierte Views

Views sind virtuelle Tabellen. Das heißt sie werden aus Tabellen zur Laufzeit gebildet. Views lösen viele praktische Probleme, da sie zum einen SELECT-Abfragen überflüssig machen können, oder den Zugriff auf eine Tabelle einschränken können, um Spalten für Anwender zu verbergen. Eine View speichert selber jedoch keine Daten, sondern wendet nur das SQL-Statement an, das bei der View-Definition hinterlegt wurde.
Beispiel:
Wenn eine View ein komplexeres SQL-Statement verwendet (Join, Group-by, Funktionen) dann kann diese View nicht mehr für Schreib-Befehle (INSERT, UPDATE, DELETE) verwendet werden. Abhilfe können hier INSTEAD-OF-TRIGGER leisten.
Wenn die Tabelle, auf die sich die View bezieht, geändert wird, dann ist die View ungültig. Sie kann dann mit dem folgenden Befehl wieder validiert werden:

### Inline-Views

Seit der Version 10g ist es möglich, eine View nur für die Ausführung eines einzelnen SQL-Statements zu definieren und dann in diesem zu verwenden. Solche Views werden nicht im Dictionary eingetragen.
Beispiel:

## Datadictionary-Views für Views

In der Spalte VIEW_TEXT ist das SQL-Statement angegeben, dass zum Erstellen der View verwendet wurde.

# Materialized View
## Materialized Views

Im Gegensatz zu normalen Views, sind Materialized Views physikalisch gespeichert um so die Zugriffe zu beschleunigen. Dies ist vor allem bei großen Datenmengen und komplexen Abfragen von Vorteil.

## CREATE

Mit täglich REFRESH:
Eigentlich, select SYSDATE from DUAL gibt das Datum.

## SELECT MATERIALIZED VIEW
# Index

Ein Index ist ein Datenbanksegment, dass über ein oder mehrere Spalten einer Tabelle erstellt wird. Der Datenzugriff einer Tabelle wird somit schneller. Auf eine bestimmte Spaltenfolge kann nur ein Index erstellt werden.
Es gibt verschiedene Arten von Indizes:
* B-tree Index
* funktionsbasierter B-tree Index
* B-tree Cluster Index
* Hash Cluster Index
* Reverse Key Index
* Bitmap Index
* Bitmap Join Index
Eine spezielle Möglichkeit sind Index-Organized Tables. Hier gibt es nur die Index-Struktur und die sonst zugrundeliegende Tabelle entfällt.
Wenn die Tabelle, auf die sich ein Index bezieht, partitioniert ist, dann kann der Index in der selben Weise partitioniert werden (lokale Partitionierung). Er kann auch ohne Partitionierung als eine einzige Struktur erstellt werden oder er kann eine ganz eigene Partitionierung haben (globale Partitionierung).

## Datadictionary-Views für Indizes

Alle Indizes anzeigen.
In der Spalte UNIQUENESS ist angegeben, ob es sich um einen eindeutigen Index handelt (UNIQUE) oder die Indexwerte in der Tabelle mehrmals vorkommen dürfen (NONUNIQUE)
Indexpartitionen anzeigen:

# Tablespace

Ein Tablespace ist eine logische Einheit zum Speichern von Datenobjekten (z. B. Tabellen). Ein Tablespace muss aus mindestens einem und kann aus mehreren Datafiles bestehen. Ein Tablespace kann vergrößert werden, indem ein Datafile angehängt oder vergrößert wird. Ein einmal zugeordnetes Datafile kann nicht mehr entfernt werden. Es gibt nur die Möglichkeit, alle Tabellen und sonstigen Objekte aus diesem Tablespace zu entfernen, den Tablespace als Ganzes zu löschen (DROP) und neu zu erstellen.
Es gibt Standard Tablespaces mit besonderer Funktion:
* SYSTEM = für Systemobjekte
* SYSAUX = ab 10g für bestimmte Systemobjekte (z. B. Statspack, Advisor, Scheduler)
* TEMP = temporär verwendeter Bereich für Sortierungen
* UNDO = ab 9i, Name kann abweichen, dient der Speicherung von Rollback-Informationen
* USERS = für die Benutzer
Zusätzlich können individuelle Tablespaces für Benutzerdaten angelegt werden. Für verschiedene Aufgabenbereiche können spezifische Tablespaces erstellt werden, um die Datenbank zu strukturieren.
Jeder Benutzer bekommt einen Tablespace zugewiesen, in dem er seine Objekte ablegen darf. Benutzerdaten sollten nicht im SYSTEM-Tablespace sondern in einem Benutzer-Tablespace abgelegt werden.
Tablespaces können auf Read-Only gesetzt werden, um Datenänderungen zu verhindern. Dies kann z. B. für historische Daten sinnvoll sein. Ein Read-Only-Tablespace kann auch wieder in den Schreibmodus versetzt werden.
Die Verfügbarkeit von Tablespaces kann Online (Standard) und Offline sein. Ein Tablespace kann z. B. offline gesetzt werden, um ein Backup durchzuführen oder bestimmte Daten nicht zugreifbar zu machen.

## Dictionary-Views zu Tablespaces

Zuordnung der Datafiles zu TS
Datafiles vom Temp-Tablespace

# Prozeduren
## Einstieg

Möglichkeiten, eine Prozedur zu erstellen:
* Eine Prozedur kann erstellt werden, indem ein compiliertes Programm als Aktion definiert wird.
* Eine Procedur kann auch eine PL/SQL-Script als Verarbeitungsteil erhalten.
Prozeduren sind nützlich, um regelmäßig wiederkehrende Arbeitsabläufe zu automatisieren z.B. um Installationsarbeiten durchzuführen.
Beispiel:
Die Procedur wird im SQLPLUS aufgerufen mit dem Befehl:
Innerhalb eines PL/SQL-Scripts wird die Procedur nur durch Angabe ihres Namens aufgefufen.

## Parameterübergabe

Wenn man der Prozedur Parameter übergeben will, dann wird unterschieden in:
* IN: Die aufrufende Umgebung übergibt einen Wert an die Prozedur. Dieser Parameter kann innerhalb der Verarbeitung nicht verändert werden. IN ist der default Parameter-Modus
* OUT: Die aufrufende Umgebung übergibt eine Variable an die Prozedur, die innerhalb der Prozedur als nicht initialisiert betrachtet wird. Wenn innerhalb der Verarbeitung diesem Parameter ein Wert zugewiesen wird, dann wird dieser an die aufrufende Umgebung zurückgegeben.
* IN OUT: Die Aufrufende Umgebung übergibt eine Variable an die Prozedur. Diese kann innerhalb der Prozedur verwendet werden und auch geändert werden. Der geänderte Wert wird der aufrufenden Umgebung mitgeteilt.
Einfache Prozedur, die einen Parameter übergeben bekommt:
Es ist auch möglich, Werte von Prozeduren verändern zu lassen:
Wird dieses zweite Beispiel verwendet, liefert der entsprechende Test:
wie zu erwarten die Werte 13 und 55.
Für die Übergabe der Daten per Referenz gibt es die NOCOPY Option bei den Parametern.

## Übersicht über Proceduren, die bei der Installation mitgeliefert werden
# Funktionen

Neben den vielen Funktionen, die die SQL-Sprache schon bietet, kann man eigene Funktionen definieren. Funktionen haben immer einen oder mehrere Input-Parameter und genau einen Ergebniswert.
Hier ein ganz einfaches Beispiel einer Funktion, die einen String als Input erwartet und einen String als Ergebnis liefert. Die Verarbeitung der Funktion besteht darin, den Input-Parameter um ein 'x' zu erweitern.
Diese Funktion kann man nun genauso verwenden wie die anderen bereits vordefinierten Funktionen. Man muss nur darauf achten, dass man die richtige Anzahl an Parametern angibt und die passenden Datentypen wählt. Beispielaufruf:
Ergebnis:
Im Anweisungsteil der Funktion können beliebig komplexe PL/SQL-Anweisungen angegeben werden. Ein Beispiel für eine etwas komplexere Funktion:
Funktionen kann man gut testen, indem man sie in einem SELECT einsetzt, der aus der Tabelle dual liest. Diese Tabelle enthält genau einen Satz mit einer Spalte. Eigentlich ist man aber an diesem Satz gar nicht interessiert, sondern man will durch diesen SELECT nur bewirken, dass die Funktion genau einmal aufgerufen wird. Aufrufbeispiel:
Ergebnis:
Hinweise:
* Die 1. Funktion ist deterministisch, d.h. wenn man die Funktion zweimal mit demselben Eingabe-Parameter aufruft, dann liefert sie immer denselben Output.
* Die 2. Funktion ist nicht-deterministisch, d.h. ihr Ergebnis ist auch von anderen Informationen abhängig als nur den übergebenen Parametern. Wenn jemand die Sätze in der Tabelle ben01.templ ändert, dann kann die Funktion anzma bei gleichem Eingabe-Parameter ein anderes Ergebnis liefern.

# Package
## Syntax

Ein Package ist eine Zusammenfassung auf verschiedenen Typen, Prozeduren und Funktionen. Die Definition eines Package geschieht in zwei Schritten. Erst wird die Package Specification erstellt. Das ist die Schnittstelle, die von außen "sichtbar" ist. In einem zweiten Schritt kann danach der Package Body erstellt werden, der die Verarbeitung beschreibt.
Ausführung:
Syntax zum Erstellen eines Package Bodys:
Globale Variablen und Typen in einem Package definieren ...
Überlagern von Prozeduren und Funktionen ...

# Trigger
## Was ist und macht ein Trigger

Trigger sind eventgesteuerte Prozeduren, die automatisch bei bestimmten Ereignissen durchgeführt werden.
Es gibt 3 Auslöser
* INSERT
* UPDATE
* DELETE
Zusätzlich kann noch der Ausführungszeitpunkt bestimmt werden
* BEFORE - vor der Änderung
* AFTER - nach der Änderung
* INSTEAD OF - anstelle der Änderung
Seit Oracle 9i können Trigger für folgende weitere Ereignisse definiert werden:
* DDL-Statements: CREATE, ALTER, DROP
* An- und Abmeldungen: LOGON, LOGOFF
* Start/Stop der Datenbank: STARTUP, SHUTDOWN
* Bei Systemfehler: SERVERERROR
Ein weiteres Kriterium ist, wie oft der Trigger gestartet werden soll
* ROW-Trigger: for each row
    werden pro geänderter Zeile ausgeführt
    Haben dadurch Zugriff auf die Attribute des Tupels vor und nach Ausführung des Triggers
    Anwendungsbeispiel: Protokollierung, Überprüfung von Aktionen, ...
* Statement-Trigger: for each statement
    werden pro ausgeführtem Statement einmalig ausgeführt, egal wieviele Zeilen betroffen sind
    Inhalt der Tupel ist nicht bekannt
    Anwendungsbeispiel: Zugriffsschutz, ...

## Syntax eines Triggers

Nur in ROW-Triggern werden die Alten (old) und Neuen (new) Werte der Tabelle zur Verfügung gestellt
Syntax bei Bedingungen: new.spaltenname, old.spaltenname
Syntax bei Aktionen: :new.spaltenname, :old.spaltenname
Bei BEFORE-Triggern besteht die Möglichkeit die NEW-Werte zu ändern
Weitere Infos: http://www.psoug.org/reference/instead_of_trigger.html

## Sequenzen und Timestamps in den Triggern (Vorlage)
# Sequenzen

Sequenzen sind Generatoren für numerische Werte, die automatisch hochgezählt werden und üblicherweise für Primärschlüsselwerte verwendet werden. Sinn einer Sequenz ist die Vermeidung des beliebten Anfängerfehlers "select max(id)+1 from xyz" zur Erzeugung des nächsten Primärschlüsselwertes.

## Verwenden von Sequenzen

liefert den nächsten Wert der Sequenz
liefert den aktuellen Wert der Sequenz, das heißt, genau den Wert, der beim letzten Aufruf von SEQUENCE_NAME.nextval zurückgeliefert wurde. SEQUENCE_NAME.currval kann erst aufgerufen werden, wenn vorher mindestens einmal SEQUENCE_NAME.nextval aufgerufen worden ist. Mit Currval kann man jedoch nur Werte abfragen, die in der eigenen Session erzeugt wurden. Selbst wenn in anderen parallel laufenden Sessions von der selben Sequence bereits weitere Werte generiert wurden, dann liefert Currval immer noch den zuletzt für die eigene Session generierten Wert. Wenn man in einer Session noch nicht mit Nextval einen Wert generiert hat, dann kann man auch nicht mit Currval den zuletzt generierten Wert abfragen.
Anwendungsbeispiel
Oft steht man vor dem Problem, dass man den Wert, der soeben in die Datenbank geschrieben wurde weiterverwenden will, z.B. um einen Detaildatensatz in einer Untergeordneten Tabelle anzulegen, der über den Fremdschlüssel num verbunden ist. Hierzu gibt es 2 Möglichkeiten:
* Referenzieren über SEQUENCE_NAME.currval. Nachteil hierbei ist, dass insbesondere bei längeren Programmen oftmals nicht sichergestellt werden kann, dass der Wert der Sequenz unverändert ist.
* Innerhalb eines PL/SQL-Programms kann man den Wert über die RETURNING-Klausel direkt in eine Variable speichern:
Alternativ Speicherung in einer PL/SQL-Variablen:
Beim Verwenden einer Sequenz kann nicht sichergestellt werden, dass die eingetragenen Werte lückenlos aufeinanderfolgen. Das liegt schon daran, dass immer mehrere Werte im Voraus generiert werden und in einem Cache gespeichert werden. Wenn die Datenbank heruntergefahren wird, dann gehen die im Cache gespeicherten Werte verloren.

## Trigger (Vorlage) für eine Sequenz

====(ersetze Platzhalter <% %>. ====
==== Zusätzlich (& nützlich): Timestamp's im Trigger. Siehe z.B.: --SELECT SYSDATE INTO :NEW.CHG_DATE FROM DUAL; // ggf. entfernen.====

# sonstige Objekte
## Synonym

Ein Synonym (anderer Name) für Datenbankobjekte wie Tabellen, Stored Procedures oder andere Synonyms.

## Database Link

Ein Database Link ist eine gespeicherte Verbindung zu einer anderen Datenbank mit einem definierten Benutzer. Es werden die Berechtigungen dieses Benutzers in der Remote-Datenbank verwendet. Die Auflösung der Remote-Datenbank erfolgt über die tnsnames.ora.
Alle DB-Links können über folgende Abfrage ermittelt werden: select * from dba_db_links;
Die Abfrage der Remote-Datenbank erfolgt über das Anhängen von @<DB_LINK> an eine normale Abfrage. Zum Beispiel:
oder
wenn abakus der Name einer Tabelle, einer View oder eines Synonyms auf der Remote-Datenbank ist und db3 der Name eines Database Link.
Ein Beispiel für das Anlegen eines Database Link (Fixed User Database Link):
* db3 ist hier der Name des Database Link, der angelegt werden soll
* user51 der vorgegebene User auf der Remote-Datenbank
* tz4ut das Passwort dieses Users user51
* tomate ist der Servicename der Remote-Datenbank entsprechend dem Eintrag in der lokalen tnsnames.ora

# DB-Architektur
## Übersicht Datenbankinstanz

In Oracle besitzt jede Datenbank eine eigene Instanz der DBMS-Software. Das ist unterschiedlich zu einigen anderen DBMS-Systemen, wo eine Instanz mehrere Datenbanken unterstützt.
SID System-Identifer der Oracle-Datenbankinstanz

## Hintergrundprozesse

* 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).
* 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.
Jede Oracle-Instanz besitzt einen eigenen Speicherbereich. Diese sogenannte SGA (System Global Area) ist wiederum in mehrere Bereiche aufgeteilt.
Diese Speicherbereiche werden während der Initialisierung der Instanz angelegt und können in der Größe zur Laufzeit nicht geändert werden.
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 LRU-Algorithmus verwaltet, d.h., häufig benutzte Abfragen oder Prozeduren stehen direkt zur Ausführung zur Verfügung.

## Dictionary-Views über den Zustand der Datenbank

Neben den Dictionary-Tabellen USER_*, ALL_* und DBA_* gibt es noch eine weitere Gruppe von Dictionary-Views. Diese geben über den Zustand der Datenbank Auskunft. Diese Views haben den Präfix V$. Sie sind hauptsächlich für die Administration wichtig.
Anzeigen aller Sessions, die gerade aktiv sind oder zuletzt aktiv waren:
Anzeigen von Informationen über die aktuelle Datenbank-Instanz.
Anzeige der Versionen der Komponenten:
Es gibt noch einige weitere Dictionary-Views, die zu keiner der oben genannten Gruppen passen:
Wenn man die exakte Version einer Oracle-Installation ermitteln will, dann läßt man sich am besten die Database-Properties anzeigen.

# Anmeldung
## Local Naming

Beim Local Naming werden die Descriptoren verwendet, die in der Datei tnsnames.ora eingetragen sind. Diese Datei steht in $ORACLE_HOME/network/admin.
Wenn man sich als User "scott" (mit dem Passwort "tiger") an der Datenbank "testdb" anmelden möchte, dann muss man den folgenden Connect-String in einem Client-Tool eingeben:
Wenn der Datenbankname bei der Installation in der Windows-Registry hinterlegt wurde, dann kann man diesen auch weglassen:
Wenn man das Kennwort nicht in lesbarer Form eingeben will, dann kann man es (z.B. bei SQLPLUS) auch in dem Connect-String weglassen. Es erscheint dann eine Eingabeaufforderung, über die man das Passwort ohne Darstellung auf dem Bildschirm erfassen kann:
Wenn der User das sysdba-Recht hat, dann kann er sich auch als Administrator anmelden. Nur wenn man als Administrator angemeldet ist, kann man bestimmte administrative Veränderungen an der Datenbank vornehmen z.B. eine Datenbank löschen.
Der Befehl "connect" darf auch abgekürzt werden als "conn"
Anmelden im SQLPLUS aus einem DOS-Fenster:

## Andere Möglichkeiten der Namensauflösung

* local Naming wurde oben beschrieben.
* Directory Naming verwendet eine Namensauflösung durch einen zentralen LDAP-Server.
* Easy Connect Naming verwendet einen Connect-String in der Form: CONNECT username/Passwort@host:port/service-name. Die Parameter port und service-name sind optional. Bei dieser Methode wird die Datei tnsnames.ora nicht verwendet.
* External Naming Es gibt noch weitere Möglichkeiten der Namensauflösung durch Oracle-fremde Tools.
Local Naming ist die default-Einstellung nach der Installation.

# Dateien
## Arten von Datenbank-Dateien

Die physikalische Datenbank besteht aus vier Typen von Dateien:
* Parameter-Dateien: Dateien, in denen Parameter das Hochfahren der Datenbank-Instanz und der Client-Verbindung abgelegt sind.
* Control-Dateien: Steuer-Dateien, in denen abgelegt wird, welche Datenbank-Dateien zur physischen Datenbank gehören.
* Tablespace-Dateien: Dateien, in denen die Daten des System-Katalogs und der Benutzer-Tabellen gespeichert sind.
* Redolog-Dateien: Informationen über Datenänderungen. Diese werden benötigt für Backup und Recover.
Die Tablespace-, Redolog- und Control-Dateien sind nach der Standard-Installation unter Windows in einem einzigen Verzeichnis angelegt: C:\Oracle\oradata\<SID>

### Datenspiegelung

Aus Sicherheitsgründen sollten die Dateien der Oracle-Datenbank auf mehrere Festplatten gespiegelt gespeichert werden. Das ist einerseits möglich durch den Einsatz von RAID-Platten, die hardwaremäßig die Spiegelung vornehmen. Die Datenbank-Dateien kann man auch von der Oracle-Datenbank auf mehreren Platten spiegeln lassen. Man sollte aber darauf achten, dass die Verbindung vom Server zu diesen Platten schnell genug ist (möglichst über den Datenbus und nicht über eine langsame Netzwerkverbindung).
Offline-Sicherung
Zusätzlich sollten diese Dateien regelmäßig gesichert werden. Am einfachsten ist eine Sicherung der Dateien, wenn gerade keine Instanz mit dieser Datenbank verbunden ist. Eine solche Sicherung kann man jederzeit wieder zurückspielen, man muss nur darauf achten, dass die Dateien vollständig sind und von derselben Version stammen. Danach kann man die Instanz wieder starten und mit der zurückgesicherten Version weiterarbeiten.
Online-Sicherung
Oft müssen Datenbanken 7 Tage zu je 24 Stunden verfügbar sein. Alle Datenbank-Dateien kann man auch während des laufenden Betriebes sichern. Dafür werden spezielle Tools eingesetzt (BACKUP, RECOVER, ARCH-Prozess).

## Parameter-Dateien

Die Parameter-Dateien liegen jeweils unter dem Pfad, in dem die Datenbank installiert wurde. Dies kann ein beliebiger Pfad sein und ist z. B. bei einer Unix-/Linux-Installation in der Umgebungsvariablen ORACLE_HOME abgelegt. Zur Veranschaulichung dieses "Home"-Verzeichnisses und dessen Variabilität wird diese Variable im Folgenden den Pfaden in der Windows-Notierung vorangestellt.

### Init.ora bzw. Init<SID>.ora

Datei: %ORACLE_HOME%\database\init<SID>.ora
In früheren Versionen waren hier die Initialisierungs-Parameter eingetragen. Seit der Version 8 steht hier nur noch ein Verweis auf eine Datei mit den Parametern drin, und zwar auf:
%ORACLE_HOME%\..\admin\<SID>\pfile\init.ora
Inhalt: Parameter der Datenbank und der Datenbank-Instanz.

### tnsnames.ora

Datei: %ORACLE_HOME%\network\ADMIN\tnsnames.ora
Inhalt: Verbindungsdaten für den Client. Hier müssen alle Server eingetragen sein, auf die der Client zugreifen kann.

### listener.ora

Datei: %ORACLE_HOME%\network\ADMIN\listener.ora
Inhalt: Parameter für den Listener-Prozess auf dem Server, der die Verbindung zu den Clients bedient.

### sqlnet.ora

Datei: %ORACLE_HOME%\network\ADMIN\sqlnet.ora
Inhalt: Parameter der Netzwerkverbindung
Es gibt noch eine Vielzahl weiterer Parameter-Dateien, die man anlegen kann, doch diese drei sind die wichtigsten.

### Weitere Parameter-Dateien

* %ORACLE_HOME%\sqlplus\ADMIN\init.sql SQL*PLUS-Parameter

## Tablespace-Dateien

Eine Tablespace-Datei ist ein Bereich auf der Festplatte, der vom Betriebssystem für die ORACLE-Datenbank zur Verfügung gestellt wird. Die Oracle-Datenbank verwendet eine oder mehrere Tablespace-Dateien zur Speicherung der Daten in dem Tablespace.
Die Datei wird in Extents aufgeteilt. Die Größe eines Extents beträgt ein ganzzahliges Vielfaches eines Betriebssystem-Blocks. Jeder Extent beinhaltet mehrere Datenblöcke. Die Größe eines Datenblocks ist in der init.ora - Datei eingetragen (Parameter db_block_size) und beträgt normalerweise 8 KB. Dieser Parameter wird beim Anlegen einer Database einmal festgelegt und kann danach nicht mehr verändert werden.
Bei Lese- und Schreib-Zugriffen wird immer ein ganzer Block gelesen oder geschrieben. Es wird nie auf einzelne Bytes der Speicherplatte zugegriffen. Bei Schreib-Zugriffen wird ein Block in die SGA gelesen. Dort werden einzelne Werte oder Sätze aus dem Block verändert. Der DBWR-Prozess hat die Aufgabe, in regelmäßigen Abständen, alle geänderten Blöcke wieder auf die Speicherplatte zu schreiben.

### Aufbau eines Datenblocks

Der Parameter PCTFREE gibt an, wieviel Prozent des Datenbereichs frei bleiben muss für Datenänderungen (UPDATEs). Dieser Bereich wird nicht für INSERTs verwendet. Wenn der Block durch INSERTs mit Daten bis zur PCTFREE-Grenze gefüllt wurde, dann wird er als "voll" markiert. Wenn dann durch UPDATE oder DELETE-Anweisungen wieder freier Platz entsteht, dann wird dieser Block aber nicht gleich wieder als "Frei" markiert. Erst wenn der Füllgrad unter die PCTUSED-Marke kommt, erst dann wird dieser Block wieder als "Frei" markiert und kann beim nächsten INSERT wieder neue Datensätze aufnehmen. Die Adressen von allen "freien" Blöcken werden in der Freispeicherliste notiert. PCTUSED sorgt dafür, dass ein Block nicht zu häufig in die Freispeicherliste eingetragen wird und wieder von dort entfernt werden muss.
Die Parameter PCTFREE und PCTUSED werden beim Erstellen eines Tablespace einmal für alle Datenblöcke festgelegt. Sie können auch nachträglich geändert werden. Wenn die Daten selten geändert werden, dann kann man PCTFREE / PCTUSED auf z. B. 5/80 festlegen (gute Speicherplatzausnutzung). Wenn die Daten sehr oft geändert werden, dann sollte man PCTFREE / PCTUSED auf z. B. 20/40 festlegen (Es wird viel freier Platz gelassen, um die Performance der Schreib-Zugriffe zu verbessern.).

### Row-Fragmentierung

Die Parameter PCTFREE und PCTUSED haben die Aufgabe, Row-Migration so weit wie möglich zu vermeiden.
ROW Migration entsteht, wenn ein Datensatz durch ein UPDATE so groß wird, dass er nicht mehr in den Datenbereich des Blocks passt. Dann wird ein Verweis auf einen neuen Block an die Stelle eingetragen. Beim Lesen muss dann der Original-Block gelesen werden und der neue Block. Row-Chaining ist erforderlich, wenn die Record-Länge eines Satzes größer ist, als der Datenbereich eines Blocks. Dann muss dieser Datensatz auf einen zweiten Block fortgeschrieben werden. Wenn der zweite Block auch nicht ausreicht, dann wird ein dritter, vierter ... Block dafür verwendet. So entsteht eine Kette von Blöcken, die zur Speicherung eines einzelnen Datensatzes benutzt werden. Row-Chaining kann man nur dadurch verhindern, wenn man beim Anlegen der Database die db_block_size entsprechend größer festlegt.
Über die Data-Dictionary-View v$datafile kann man die Größe der einzelnen Tablespace-Dateien anzeigen lassen.
Weitere Data-Dictionary-Views zur Speicherplatzverwaltung:

## Rollback-Segmente

Rollback-Segmente sind spezielle Segmente in einem Tablespace, die Datenänderungen protokollieren.
Wenn eine Transaktion eine Änderung an den Daten vornimmt, dann wird die Änderung zunächst an dem Datensegment vorgenommen, aber die alte Version des Satzes wird in dem Rollback-Segment vermerkt. Solange die ändernde Transaktion ihre Änderung noch nicht durch COMMIT freigegeben hat, bekommen alle anderen lesenden Transaktionen die alte Version des Datensatzes zu lesen. Diese Informationen werden dann aus den Rollback-Segmenten gelesen. Wenn die ändernde Transaktion ihre Änderung durch COMMIT freigibt, bekommen andere lesende Transaktionen die neue Version des Satzes zu lesen. Nur solche Transaktionen, die ihren Lesezugriff noch vor dem COMMIT-Zeitpunkt begonnen haben, bekommen immer noch die alte Version des Satzes zu lesen, denn alle Lesezugriffe werden als Snapshot ermittelt d.h. als Sicht auf die Datenbank zu einem bestimmten Zeitpunkt. Wenn die Informationen in den Rollback-Segmenten nicht mehr gebraucht werden, können sie wieder überschrieben werden. Durch den System-Parameter UNDO-RETENTION wird festgelegt, wie lange die Informationen in den Rollback-Segmenten nach ihre Freigabe noch erhalten bleiben sollen für Lesezugriffe, die vor der Commit-Schreibung mit ihrem Zugriff begonnen haben.

### Snapshot too old

Falls ein Programm z.B. mit einem Select alle vorhandenen Sätze aus einer Tabelle auslesen muss und für jeden Satz eine zeitaufwändige Verarbeitung ausführen muss, dann kann es vorkommen, dass für dieses Programm auf Informationen aus den Rollback-Segmenten zugegriffen will, die aber bereits überschrieben wurden, weil die UNDO-RETENTION-Zeit schon vorbei ist. Dann bricht diesen Programm ab mit der Fehlermeldung „ORA-01555: Snapshot too old“. In diesem Fall kann man die UNDO-RETENTION-Zeit hochsetzen. Wenn das Programm drei Stunden braucht, dann muss die UNDO-RETENTION-Zeit auf 3 * 60 * 60 = 10800 gesetzt werden, d.h. alle Informationen in den Rollback-Segmenten bleiben nach ihrer Freigabe noch drei Stunden erhalten. Erst dann dürfen sie überschrieben werden.
Bei einer so hohen UNDO-RETENTION-Zeit wird viel Platz für die Rollback-Informationen gebraucht.
Nach einer Standard-Installation der Oracle-Datenbank gibt es nur den SYSTEM-Tablespace, in dem sowohl die User-Daten, als auch die Rollback-Daten abgelegt werden. Um die Dictionary-Tabellen nicht unnötig zu belasten und um das Recovery zu erleichtern, sollte man die User-Tabellen in eigenen Tablespaces ablegen. Ebenso ist es empfehlenswert, mindestens einen eigenen Tablespace anzulegen, in denen ausschließlich Rollback-Segmente gespeichert werden. Oracle empfielt, die Tablespace für die Rollback-Segmente auf einer anderen Platte zu plazieren, als die Tablespace in denen die Daten-Segmente gespeichert werden. Das fördert Parallelzugriffe auf Daten- und Rollback-Informationen.
Ab Version 10 spricht man von UNDO-Segmenten und UNDO-Tablespaces.

### Neue Rollback-Segmente anlegen

Um neue Rollbacksegmente anzulegen, müssen diese einem bestimmten Tablespace zugewiesen werden. Danach müssen die Rollback-Segmente ONLINE gesetzt werden.
Falls eigene Rollback-Segmente angelegt werden, dann müssen diese in der Parameter-Datei init.ora bekanntgegeben werden z.B.

## Redolog-Dateien

Redolog-Dateien speichern Informationen über alle Datenänderungen in den Tablespace-Dateien. Sie können im Falle eines Speichermediums-Fehlers zur Rekonstruktion der Daten herangezogen werden. Es müssen mindestens zwei Redolog-Dateien (mindestens zwei Gruppen mit jeweils mindestens einer Datei) für jede Database definiert sein. Jede Redolog-Datei sollte zusätzlich auf mehrere Platten gespiegelt werden.
Die Änderungen an den TS-Dateien werden immer in eine Redolog-Datei ausgegeben, bis diese voll ist. Dann führt das System einen Logswitch durch, d.h. es wird eine neue Redolog-Datei begonnen. Da aber nur eine begrenzte Anzahl von Redolog-Dateien vorhanden ist, wird nach dem Beschreiben der letzten Datei, wieder mit der ersten fortgesetzt. Die bisherigen Einträge der Datei, werden dabei überschrieben. Damit die Redolog-Informationen durch das Überschreiben nicht verloren gehen, hat der ARCH-Prozess die Aufgabe, nach einem Logswitch die gerade fertig geschriebene Redolog-Datei zu archivieren.
Nach der Installation ist der ARCH-Prozess nicht aktiv, d.h. die Datenbank befindet sich im NOARCHIVELOG-Modus. In diesem Zustand kann nur manuelles Offline-Backup und Recovery ausgeführt werden. (s. Seite 3) Um die Datenbank-Funktionen BACKUP und RECOVER ausführen zu können, muss die Datenbank in den ARCHIVELOG-Modus versetzt werden. Dann nimmt der ARCH-Prozess seine Arbeit auf.

### Redolog-Gruppen

Da die Redolog-Dateien elementare Voraussetzung für ein Recover nach einem Plattencrash sind, ist es dringend empfohlen, die Redolog-Dateien von der Datenbank gespiegelt zu beschreiben.
Anzeigen der aktuell vorhandenen Redolog-Dateien:

### Redolog-Gruppen verändern

Man kann nur Loggruppen ändern, die gerade nicht aktiv sind. Einen Wechsel zur nächsten Loggruppe kann man erzwingen durch den Befehl:
Einrichten einer zusätzlichen Redolog-Gruppe:
Redolog-Gruppe erweitern um eine zusätzliche Datei auf der E-Platte:
Redolog-Gruppe löschen:
Eine einzelne Datei aus einer Redolog-Gruppe löschen:
Eine einzelne Datei umbenennen:
Die Datenbank entfernt die Dateien nur aus ihrem Verzeichnis. Das Entfernen der physischen Datei auf der Betriebssystem-Ebene muss man selber machen.
Ebenso muss beim Umbenennen die Datei auf Betriebssystem-Ebene bereits unter dem neuen Namen existieren.

### Empfehlungen für die Handhabung von Redolog-Dateien

* Redolog-Dateien sollten auf einer anderen Platte gespeichert werden, als die Tablespace-Dateien
* Jede Redolog-Gruppe sollte aus mindestens 2 Dateien bestehen
* Um Zugriffskollisionen zwischen dem LGWR und dem ARCH-Prozessen zu vermeiden, sollte sich das Verzeichnis, in den die Redolog-Dateien archiviert werden, auf einer anderen Platte befinden, als die Redolog-Dateien geschrieben werden.
* Wenn viele Datenänderungen ausgeführt werden, dann sollten die Redolog-Dateien entsprechend größer dimensioniert werden. Fall eine Redolog-Gruppe voll ist und der ARCH-Prozess die nächste Redolog-Gruppe noch nicht fertig archiviert hat, dann muss das System so lange warten, bis die Archivierung abgeschlossen ist.
* Bis Version 9 ist maximal eine fünffache Spiegelung der Redolog-Dateien möglich.
* Größe von Redolog-Dateien:

## Control-Dateien

Die Control-Dateien enthalten die Informationen über alle physikalischen Datanbankdateien
Sie beinhalten die Verwaltungs- und Strukturinformationen
* Datenbankname
* Namen der Tablespace-Dateien
* Namen der Redolog-Dateien
* die aktuelle LOG-Sequenznummer
* weitere Informationen, die für ein Recover erforderlich sind.
Die Control-Dateien sollten ebenfalls auf unterschiedlichen Platten abgelegt werden.
Die aktuell vorhandenen Control-Dateien kann man sich ausgeben lassen mit:

### Control-Dateien wiederherstellen

Falls die Controldateien zerstört wurden (und alle anderen Dateien noch ok sind), dann kann man die Control-Dateien neu erstellen lassen mit folgender Befehlsfolge:
Dadurch wird in dem Trace-Verzeichnis ein Script erstellt, mit dem man die Control-Dateien sichern kann. Die Trace-Datei findet man in dem Verzeichnis:
Datei mit dem letzten Datum suchen. In der Datei muss man die Header-Zeilen und die Kommentar-Zeilen entfernen. Dann kann man die Datei z.B. speichern unter c:\con_neu.sql und ausführen:
Nun sind die Controldateien neu angelegt worden.

# Datenbank starten
## Verwalten der Datenbank-Instanz

Eine Oracle-Datenbank besteht aus den Dateien und einem Programm, das im Arbeitsspeicher aktiv ist. Das aktive Programm bezeichnet man auch als Oracle-Instanz.
Die Instanz kann gestartet werden
* mit dem Enterprise Manager
* dem SQL*Plus-Befehl STARTUP
* bei Windows durch Starten der Dienste
Beim Starten der Instanz werden verschiedene Zustände durchlaufen:
* SHUTDOWN
* NOMOUNT
* MOUNT
* OPEN
Diese Zustände können alle nacheinander durchlaufen werden bis zum Status OPEN, in dem die Instanz die normale Arbeit ausführen kann. Man kann die Status auch einzeln durchlaufen, um bestimmte administrative Arbeiten ausführen zu können.
Der aktuelle Status der Datenbank kann ermittelt werden mit dem Befehl:

## DB-Status SHUTDOWN

Sowohl die physische Datenbank, als auch die Instanz ist heruntergefahren.
In diesem Zustand kann sich nur ein User als SYSDBA anmelden. Die Anmeldung wird bestätigt mit der Meldung:
Bei einer nicht hochgefahrenen Instanz angemeldet.
Zum Hochfahren der Datenbank müssen noch drei weitere Phasen durchlaufen werden:
Zustand NOMOUNT
Zustand MOUNT
Zustand OPEN
Eine gestoppte Datenbank kann komplett hochgefahren werden (und alle Phasen des Start-Prozesses durchlaufen) mit dem Befehl:
startup
oder
startup normal

## DB-Status NOMOUNT

Eine Database kann vom Administrator in verschiedene Status versetzt werden:
Der erste Schritt zum Starten einer Datenbank ist das Starten der Instanz im Zustand NOMOUNT.
In diesem Zustand ist die Instanz hochgefahren, hat aber noch keine Verbindung zur physischen Database aufgenommen.
Nur in diesem Zustand kann eine neue Datenbank erstellt werden.
In diesem Zustand sind nur Befehle zulässig, die auf keine Datenbank-Dateien zugreifen:
Folgende Dictionary-Views sind selektierbar:

## DB-Status MOUNT

Um die physische Datenbank zu öffnen, wird sie in den Status MOUNT versetzt.
Wenn die Database im Zustand SHUTDOWN ist, dann kann sie in den Status MOUNT gebracht werden durch den Befehl:
Wenn die Database im Zustand NOMOUNT ist, dann kann sie in den Status MOUNT gebracht werden durch den Befehl:
Um die Datenbank in den Zustand MOUNT zu versetzen, müssen die Controldateien gelesen werden, um zu ermitteln, welche Dateien zur physischen Datenbank gehören.
Falls die Control-Dateien nicht gefunden werden oder inkonsistent sind, dann kann die Datenbank nicht in den MOUNT-Zustand versetzt werden.
In diesem Zustand sind weitere Dictionary-Views selektierbar:
Zugriffe auf die Benutzer- oder Dictionary-Tabellen ist in diesem Zustand noch nicht möglich

## DB-Status OPEN

Um das reguläre Arbeiten mit der Datenbank zu ermöglichen, muss die Datenbank noch geöffnet werden.
Wenn die Database im Zustand SHUTDOWN ist, dann kann sie in den Status OPEN gebracht werden durch den Befehl:
Wenn die Datenbank im Zustand NOMOUNT oder MOUNT ist, dann kann sie in den Status OPEN gebracht werden durch den Befehl:
Erst jetzt sind die Benutzer- und Dictionary-Tabellen zugreifbar. Nur in diesem Zustand können sich User ohne SYSDBA-Privileg an der Datenbank anmelden.
Ist eine Datenbank aus einem Onlinebackup zurückgespielt worden, werden die ArchivedRedoLogs mit
in die Datenbank eingepflegt. Sind alle ArchivedRedoLogs eingepflegt, muss die Datenbank noch mit
geöffnet werden. Da die OnlineRedoLogs nicht mehr aktuell sind, müssen sie neu initialisiert werden.

## Weitere Startmöglichkeiten

Entspricht einem SHUTDOWN ABORT und anschließendem STARTUP NORMAL
Öffnen der Datenbank nach vorherigem Recover
Öffnen der Datenbank nur für Lese-Operationen.

## DB-Status RESTRICT

Um Wartungsarbeiten an der Datenbank auszuführen, kann die Datenbank im Zustand RESTRICT geöffnet werden. Dieser Zustand ist derselbe, wie der OPEN-Zustand, aber es dürfen sich nur User mit dem Systemprivileg "restricted Session" anmelden.
Voraussetzung: Die Datenbank muss im Zustand SHUTDOWN sein. Sie wird nun hochgefahren in den OPEN Zustand. Der Administrator kann jetzt auf alle Tabellen zugreifen, aber ein Anmelden anderer Benutzer ist ausgeschlossen. Genauer ausgedrückt: Nur Benutzer mit dem Systemprivileg "restricted session" können sich jetzt anmelden.
"Normale" Benutzer, die sich in diesem Zustand anmelden wollen, erhalten die Fehlermeldung:
Falls die Datenbank aus dem laufenden Betrieb in den RESTRICT-Zustand versetzt werden soll, dann kann das mit dem folgenden Befehl geschehen:
Achtung: Falls jedoch noch andere Benutzer noch mit der Datenbank verbunden sind, dann werden diese Verbindungen nicht getrennt. Nur Neuanmeldungen von "normalen" Benutzern sind ausgeschlossen. Falls die anderen Benutzer zwangsweise abgemeldet werden sollen, dann ist ein Shutdown erforderlich.
Die Datenbank kann für den normalen Betrieb wieder freigegeben werden durch den Befehl:

## SHUTDOWN-Befehl

Beim Herunterfahren der Datenbank muss angegeben werden, wie mit anderen noch mit der Datenbank arbeitenden Benutzern und den noch aktiven Transaktionen umgegangen werden soll:
oder
wartet solange, bis alle aktiven Benutzer mit "EXIT" ihre Arbeiten beendet haben. Ein erneuter LOGON ist nicht möglich.
Alle Transaktionen dürfen ihre Arbeiten bis zum nächsten Commit-Punkt fortsetzen, die geänderten Daten werden gespeichert und dann wird der Benutzer von der Datenbank getrennt. Falls eine Transaktion "klemmt", weil sie z.B. auf eine andere Transaktion wartet z.B. in einem Deadlock, dann kann die Datenbank nicht herunterfahren. Wenn die datenbank durch einen SHUTDOWN TRANSACTIONAL heruntergefahren werden konnte, dann sind die Daten in jedem Fall konsistent.
Nun wird nicht mehr bis zum nächsten Commit gewartet, sondern alle Aktivitäten der noch aktiven Benutzer werden sofort gestoppt. Alle Datenänderungen werden mit Rollback zurückgerollt. Auf diese Weise können auch Deadlock-Situationen aufgelöst werden. Alle Daten sind durch den Rollback in einem konsistenten Zustand.
Bei diesem Befehl wird sofort der Kontakt der Instanz zur physischen Datenbank unterbrochen. Falls andere Transaktionen noch aktiv waren, dann sind die Daten inkonsistent. Beim nächsten Hochfahren muss erst mal ein Recover ausgeführt werden. SHUTDOWN ABORT hat dieselbe Wirkung wie eine Unterbrechung der Stromversorgung.
Bei Ausführung des Shutdown-Befehls wird folgende Meldung ausgegeben:
Dadurch wird exakt protokolliert, wie die Datenbank die einzelnen Phasen des Startup-Befehle in genau der umgekehrten Reihenfolge durchläuft. Wenn als Letztes die Instanz heruntergefahren ist, dann befindet sich die Datenbank im SHUTDOWN-Zustand.
Sollte beim Herunterfahren der Datenbank ein Problem auftreten, dann besteht die Möglichkeit für den Administrator, sich in einer weiteren Session anzumelden und mit dem Befehl
oder
das Herunterfahren zu beschleunigen.
In der folgenden Tabelle sind die relevanten Aktionen dargestellt.
| Modus für das Herunterfahren | A | I | T | N |
| Lässt neue Anmeldungen zu | Nein | Nein | Nein | Nein |
| Wartet, bis aktuelle Sessions beendet sind | Nein | Nein | Nein | Ja |
| Wartet, bis aktuelle Transaktionen beendet sind | Nein | Nein | Ja | Ja |
| Erzwingt Checkpoint und schließt Dateien | Nein | Ja | Ja | Ja |
A = ABORT, I = IMMEDIATE, T = TRANSACTIONAL, N = NORMAL,

# Benutzerverwaltung
## Durch Installation angelegte Benutzer

Wenn eine Oracle-Datenbank installiert wird, dann werden die folgenden Benutzer eingerichtet:
Der User SYS hat die DBA-Rolle und das SYSDBA-Recht. Er kann sich an der Datenbank-Instanz anmelden, wenn diese noch nicht hochgefahren ist. SYS darf den STARTUP-Befehl ausführen. SYS kann nicht nur die Datenbank administrieren, sondern darf auch alle Tabelleninhalte der anderen Benutzer anzeigen lassen. Der User SYS kann selber Tabellen erstellen. Diese Möglichkeit sollte nur dafür genutzt werden, um Tabellen zu erstellen, die vom System oder für die Systemverwaltung genutzt werden. Benutzer, die dieses Privileg erlangen wollen, müssen in der Betriebssystemgruppe dba sein und müssen sich mit dem Kommandozeilenzusatz as sysdba anmelden. Aus Sicherheitsgründen sollte dieses Konto geLOCKED sein, damit keine Loginmöglichkeit mehr über den Listener, trotz bekanntem Passwort, besteht. Ein lokaler Login ist weiterhin möglich.
Der User SYSTEM hat ebenfalls die DBA-Rolle und das SYSDBA-Recht. Er kann jedoch - im Vergleich zum SYS - nicht die Tabellen der anderen Benutzer anzeigen. Auch das SYSTEM Konto sollte aus Sicherheitsgründen geLOCKED sein, damit keine Loginmöglichkeit mehr über den Listener, trotz bekanntem Passwort, besteht. Ein lokaler Login ist weiterhin möglich.
Die oben angegebenen Passwörter werden bei einer Installation bis zur Version 9 automatisch vergeben. Ab der Version 10g muss man die Initial-Passwörter während der Installation selber bestimmen.
Weitere User-IDs, die bei der Installation zusätzlicher Komponenten erstellt werden:

## Einen neuen Benutzer anlegen

Um einen Benutzer anzulegen, sind nur wenige Angaben erforderlich:
Die User-ID des neuen Benutzers lautet jm und es wurde das Passwort "geheim" festgelegt. Diesem Benutzer wird der default Tablespace (meistens der Tablespace USERS) und der default TEMP Tablespace (meistens der Tablespace TEMP) und das Profil mit dem Namen DEFAULT zugewiesen.
Oft soll der neue Benutzer einen eigenen Tablespace erhalten. Dann muss dieser erst angelegt werden:
Dann kann man den neuen Benutzer anlegen und diesen Tablespace als seinen default Tablespace angeben:
Einige Berechtigungen für den User jm vergeben:
Anmeldung als der neu erstellte User jm:
Bei der externen Autorisierung übernimmt das Betriebssystem die Passwortprüfung für die Authentifizierung. In diesem Fall wird innerhalb der Oracle-Datenbank kein Passwort für einen Benutzer gespeichert bzw. überprüft. Der Benutzer muss lediglich der Oracle-Datenbank bekannt gemacht werden.
Passwort ändern:
Das Passwort des eigenen Users kann man immer ändern. Das Passwort eines anderen Users kann nur der Administrator ändern.

## Einen bestehenden Benutzer löschen

Sollten für den Benutzer bereits abhängige Daten existieren, muss die 'cascade' Option angegeben werden, um alle Abhängigkeiten mitzulöschen.

## Systemprivilegien

Systemprivilegien sind Rechte zur Administration der Datenbank. Sie sind unabhängig von bestimmten Objekten (z.B. Tabellen, Spalten, Indices)
Welche Systemprivilegien hat ein User erhalten?

## Objektprivilegien

Objektprivilegien sind Berechtigungen zur Administration bestimmter Datenbank-Objekte. Bei der Vergabe dieser Berechtigungen muss immer das betreffende Objekt genannt werden, auf das sich das Recht bezieht.
Welche Objektprivilegien hat ein User erhalten?
Durch die Quota wird festgelegt, wie viel Platz ein Benutzer in Anspruch nehmen darf für die Tabellen, die er erstellt und mit Daten füllt. Die Quota kann ein Administrator ändern:
Welche Quotas wurden vergeben:
Welche Spaltenprivilegien wurden vergeben?
Welche Objektprivilegien hat er weitergegeben?
Welche Objektprivilegien hat er von anderen Usern erhalten?
Welche Spaltenprivilegien hat er erhalten?
Welche Spaltenprivilegien hat er weitergegeben?

## Profil

Jeder User hat ein Profil, in dem verschiedene Ressource- und Passwort-Parameter festgelegt sind. Über die Ressource-Parameter kann ein Benutzer eingeschränkt werden in der Benutzung der Systemressourcen (z.B. maximal zulässige Anzahl Sessions, CPU-Nutzung). Die Passwort-Parameter legen z.B. fest, wie lange ein Passwort verwendet werden darf und die zulässige Anzahl der Fehleingaben. Welches Profil ein User hat, ist in DBA_USERS eingetragen.
Welche Profile gibt es und welche Einstellungen sind z.B. in dem Profil 'DEFAULT' festgelegt?
Der Systemadministrator kann auch weitere Profile anlegen. Beispiel:

## Rolle

Meistens gibt es in einem Unternehmen verschiedene Gruppen von Mitarbeitern, die bestimmte Berechtigungen haben. Beispiel: Softwareentwickler, Administratoren, Anwender. Jeder Oracle-User braucht eine Vielzahl von Berechtigungen, die davon abhängig ist, in welcher Gruppe er tätig ist. Damit nun diese vielen Einzel-Berechtigungen nicht bei jeder personellen Veränderung einzeln zugewiesen oder entzogen werden müssen, gibt es in Oracle das Rollen-Konzept.
Eine Rolle wird eingerichtet und die dafür vorgesehenen Berechtigungen werden dieser Rolle gegeben.
Dann wird diese Rolle an die einzelnen User vergeben.
Jedem User kann eine Default-Rolle zugewiesen werden. Beispiel:
Wenn ein User mehrere Rollen erhalten hat, dann kann er diese aktivieren und deaktivieren durch den Befehl SET:
Welche Rollen sind in der aktuellen Session gerade aktiv?
Welche Rollen gibt es?
Welche System- und Objektprivilegien wurden einer Rolle gegeben? Wurden einer Rolle noch weitere Rollen zugewiesen?
Welche Rollen hat der User JM erhalten?

## Was machen die einzelnen User gerade?

In der Katalog-View v$session sind alle gerade aktiven Sessions verzeichnet. In der View v$sql sind die zuletzt ausgeführten SQL-Statements eingetragen. Bei einer Verknüpfung dieser beiden Views kann man sich ausgeben lassen, welche SQL-Statements die einzelnen Benutzer ausgeführt haben und wie oft diese Statements ausgeführt wurden.

## Zugriff auf Dictionary-Tabellen

Der Initilisierungsparameter O7_DICTIONARY_ACCESSABILITY sollte auf dem Default FALSE stehen. Dadurch wird verhindert, dass Benutzer mit dem Privileg SELECT ANY TABLE Tabellen des Data Dictionary lesen können. Der Wert TRUE stellt den Zustand her, der in Version 7 der Datenbank Default war: Das SELECT ANY TABLE Privileg galt auch für die Tabellen des Data Dictionary.
Drei Rollen erlauben eine differenzierte Steuerung des Zugriffs auf Objekte des Data Dictionary:
* SELECT_CATALOG_ROLE erlaubt den Zugriff auf Data Dictionary Views
* DELETE_CATALOG_ROLE ermöglicht das Löschen in den Tabellen des Audit Trails und
* EXECUTE_CATALOG_ROLE eröffnet den Zugriff auf Prozeduren und Packages des Data Dictionary.
Das Privileg SELECT ANY DICTIONARY erlaubt nicht nur den Zugriff auf Views des Data Dictionary, sondern den Zugriff auf ALLE Objekte des Benutzers SYS.

# Tablespace verwalten
## Konfiguration von Tablespaces

Nach der Installation von Oracle gibt es nur den SYSTEM-Tablespace (bei Oracle Version < 10g), ab Oracle Version 10g gibt es mind. den SYSTEM und den SYSAUX Tablespace.
Es ist empfehlenswert, die System-Daten und die Anwendungsdaten in getrennten Tablespaces zu speichern.
Für die Systemdaten kann man eigene Tablespaces einrichten für
* Datadictionary (existiert schon)
* Tools
* Rollback-Segmente
* Sort-Bereich (temporärer Tablespace)
Für die Anwendungsdaten kann man Tablespaces einrichten für
* die einzelnen Fachgebiete
* Indices

## Neuen Tablespace erstellen

Der Tablespace wird mit einer festen Größe von 10MB angelegt.
Die Extent-Verwaltung erfolgt bei diesem Tablespace lokal im Tablespace durch ein BITMAP und nicht über das Datadictionary. Alle Extents haben dieselbe Größe.
Dieser Tablespace wird zunächst mit 10MB angelegt. Er kann sich bei Bedarf in Schritten von 200 KB bis zu einer Maximalgröße von 200MB selbst erweitern.

## Tablespace erweitern

Die beiden Tablespaces werden erweitert, indem eine weitere Datei hinzugefügt wird. Im ersten Fall ist es eine Datei mit fester Größe, im zweiten Fall ist es eine Datei, die sich bei Bedarf selbst erweitern kann.
Wenn der TEMP Tablespace erweitert werden soll, dann wird TEMPFILE anstelle von DATAFILE angegeben:
Die AUTOEXTEND-Einstellung kann man nachträglich mit Hilfe des ALTER-DATABASE-Befehls verändern.
Die Tablespace-Datei wird wieder verkleinert auf 10 MB. Dieser Befehl kann nur dann ausgeführt werden, wenn das bestehende Datenvolumen nicht den abzutrennenden Speicherbereich verwendet.
Die einzelnen hintereinanderliegenden freien Extents in den Tablespace-Dateien werden zu ganzen Blöcken zusammengefasst. Dadurch können neue größere Extents in dem freien Platz angelegt werden.

## Tablespace administrieren

Für bestimmte administrative Tätigkeiten müssen Tablespaces offline gesetzt werden.
In einer NOARCHIVELOG-Umgebung (d.h. es ist kein ARCH-Prozess aktiv, dementsprechend werden die Redolog-Dateien nicht archiviert):
In einer ARCHIVELOG-Umgebung (die Redolog-Dateien werden vom ARCH-Prozess archiviert):
Schlüsselwort NORMAL: die Anweisung wird nur dann ausgeführt, wenn sich der Tablespace in einer Fehlersituation befindet.
Schlüsselwort IMMEDIATE: der Tablespace wird sofort in den OFFLINE-Modus gesetzt, auch wenn eine Transaktion diesen gerade benutzt. Beim ONLINE-Setzen muss ein Recover stattfinden.
Schlüsselwort TEMPORARY: die Dateien, die sich nicht in einer Fehlersituation befinden, werden durch einen Checkpoint gesichert. Beim ONLINE-Setzen muss ein Recover nur für die fehlerhaften Dateien stattfinden.
Man kann auch einzelne Datenbankdateien online / offline setzen. In einer NOARCHIVELOG-Umgebung muss der Parameter DROP angegeben werden. Dies kann es ggf. erforderlich machen ein recover auf die Datenbankdatei auszuführen, bevor sie wieder online gesetzt werden kann.

## Datenbankdatei umbenennen

1. Schritt: Tablespace OFFLINE setzen
2. Schritt: Datei auf Betriebssystemebene kopieren (Oracle schaut in beiden Dateien nach)
3. Schritt: Neuen Namen im Oracle bekannt geben:
oder:
4. Schritt: Tablespace ONLINE setzen
5. Kontrollieren:
6. Wenn die neue Datenbankdatei Online ist, kann die alte Datenbankdatei auf Betriebssystemebene gelöscht werden
Falls mehrere Datenbankdateien oder Dateien aus dem SYSTEM-Tablespace umbenannt werden sollen, können folgende Schritte ausgeführt werden:
1. Schritt: Datenbank in den MOUNT-Status versetzen
2. Schritt: Datei mit Betriebsystemmitteln umbenennen
3. Schritt: Neuen Namen im Oracle bekannt geben:
oder:
4. Schritt: Datenbank in den OPEN-Status versetzen

## Tablespace löschen

Falls der Tablespace leer ist (keine Tabellen, Indexe, Rollback-Segmente vorhanden):
Falls sich noch Objekte im Tablespace befinden:
Ab Version 9 können auch die Datendateien auf Betriebssystemebene mit gelöscht werden:
Falls sich noch Objekte im Tablespace befinden und von anderen Objekten Referenzen auf die Objekte im zu löschenden Tablespace existieren:
Ohne die Angabe "AND DATAFILES" müssen die Dateien noch manuell mit Betriebssystemmitteln gelöscht werden.

## Temporary Tablespace

Wenn bei der Ausführung von SQL-Statements Sortierungen gefordert werden, und diese Daten für die SGA zu umfangreich sind, dann werden sie in einem Tablespace auf der Platte zwischengespeichert und sortiert. Dabei können kurzfristig viele Extents angefordert werden, die danach wieder freigegeben werden. Um die Speicherplatzverwaltung im SYSTEM-Tablespace und in den Daten-Tablespaces nicht unnötig zu belasten, sollten temporäre Tablespaces zur Aufnahme dieser Daten bereitgestellt werden.
Temporary Tablespace anlegen
Ein temporärer Tablespace hat ein TEMPFILE und KEIN DATAFILE.
Man kann auch einen "normalen" Tablespace in einen temporären Tablespace umwandeln:
Und man kann einen temporären Tablespace in einen "normalen" Tablespace umwandeln:

## Datadictionary-Views für Tablespaces

Anzeige aller Tablespaces:
Anzeige der Datendateien:
Anzeige der Temp-Dateien:
Freiplatzverwaltung:
Tablespaces mit AUTOEXTEND ON:
Anzeige der Objekte in den Tablespaces:
Wie groß ist der Redolog-Bereich? Redologs werden nicht in einem Tablespace gespeichert, sondern als "Archive-Log-Dateien" in einem dafür vorgesehenen Verzeichnis ausgegeben.

# Backup und Recover
## Backup-Strategie

Offline-Backup
Die Datenbank-Dateien werden gesichert, während die Datenbank nicht geöffnet ist.
Vorteile:
* einfache Handhabung
* das Backup kann mit Betriebsystem-Mitteln durchgeführt werden
Nachteile:
* die Datenbank muss heruntergefahren werden
* falls ein Recover erforderlich ist, dann kann nur die Sicherung wiederhergestellt werden. Alle danach erfolgten Änderungen können nicht automatisch nachgezogen werden.
* Die Datenbank kann nur als Ganzes wiederhergestellt werden.
Online-Backup
Während der Benutzung der Datenbank von Anwendern kann auch eine Datensicherung hergestellt werden. Diese Sicherung enthält aber keinen Snapshot, sondern die Änderungen, die während der Erstellung der Sicherung ausgeführt wurden, sind teilweise in der Sicherung enthalten.
Online-Sicherungen sind nur möglich, wenn auch die Redolog-Dateien durch den ARCH-Prozess gesichert werden.
Vorteile:
* Kein SHUTDOWN erforderlich zur Erstellung der Sicherung
* beim Recover kann eine Sicherung eingespielt werden und dann die Änderungen automatisch nachvollzogen werden bis zu einem bestimmten Punkt z.B. bis vor den Start eines bestimmten Programms
* Einzelne Tablespaces können gesichert werden
Nachteile:
* Das Erstellen einer online-Sicherung belastet die anderen Aktivitäten der Instanz
* ein Recover auf die Datensicherung alleine ist nicht möglich, da die Sicherung keine konsistenten Daten eines Snapshots enthält.

## Offline-Backup

Beispiel-Script für die Durchführung eines offline-Backup (unter Windows)
Aufruf des Scripts:
Zur Durchführung eines Recover müssen alle Dateien wieder an ihren Ursprungsort kopiert werden. Falls die Datenbank-Dateien auf unterschiedlichen Platten gespeichert waren, dann muss darauf geachtet werden, dass alle Dateien wieder an ihren richtigen Ort kopiert werden. Es darf keine einzige Datei ausgelassen werden. Am besten hebt man sich die generierte Backup-Datei auf oder man erstellt sich gleich eine geeignete Recover-Datei, mit der ein Recover automatisch abläuft.

## Online-Backup

Ein Online-Backup ist nur zu gebrauchen, wenn die Redolog-Dateien über den ARCH-Prozess gesichert werden. Denn die einzelnen Dateien werden parallel zu den Änderungen der Datenbank erstellt. Bestimmte Änderungen sind in den Dateien bereits enthalten, andere noch nicht.
Wenn man später eine Online-Sicherung für das Recover verwenden will, dann müssen nach dem Einspielen der Sicherung die archivierten Redolog-Dateien ausgewertet werden, um alle Datenänderungen bis zu einem bestimmten Timestamp nachzuvollziehen. Erst dann ist ein bestimmter, konsistenter Zustand der Datenbank wieder hergestellt.
Ein Online-Backup kann durch folgende Befehlsfolge ausgeführt werden:
1. Beginn der Online-Sicherung dem System mitteilen
2. Mit Betriebssystem-Mitteln wird die Datei in das Backup-Verzeichnis kopiert
3. Das Ende der Online-Sicherung dem System mitteilen
Für die Durchführung von Online-Backups kann man sich auch Skripte generieren, die dann automatisiert ablaufen. Dabei muss man darauf achten, dass immer nur ein Tablespaces im Backup-Status ist. Für jeden Tablespace, der gesichert werden soll, müssen die oben genannten drei Schritte durchlaufen werden.

## Control-Dateien wiederherstellen

Falls die Controldateien zerstört wurden (und alle anderen Dateien noch ok sind), dann kann man die Control-Dateien neu erstellen lassen mit folgender Befehlsfolge:
oder
Dadurch wird in dem Trace-Verzeichnis ein Script erstellt, mit dem man die Control-Dateien sichern kann. Die Trace-Datei findet man in dem Verzeichnis:
Datei mit dem letzten Datum suchen.
In der Datei muss man die Header-Zeilen und die Kommentar-Zeilen entfernen. Dann kann man die Datei z.B. speichern unter c:\con_neu.sql und ausführen:
Nun sind die Controldateien neu angelegt worden.

## ARCH-Prozess

Der ARCH-Prozess hat die Aufgabe, die voll geschriebenen LOG-Dateien zu sichern. Der LGWR (Log-Writer-Prozess) überschreibt und hat nur eine bestimmte Anzahl von Log-Dateien zur Verfügung. Wenn die eine Datei voll ist, dann schreibt er die Log-Informationen in die nächste Datei weiter. Dabei wird der alte Inhalt der Log-Datei überschrieben. Der ARCH-Prozess sorgt dafür, dass die Log-Dateien nach ihrem Beschreiben gesichert werden.
Der ARCH-Prozess wird aktiviert durch:
Einträge in der Datei init.ora: (Beispiel)
Dann muss der ARCH-Prozess noch aktiviert werden. Das geht nur, wenn die Datenbank in der MOUNT-Phase ist, (nicht in der OPEN-Phase)
Nun kann man die Arbeit des ARCH-Prozesses beobachten.
Die Data-Dictionary-Views geben über seine Aktivitäten Auskunft:
Man kann einen Logswitch erzwingen, auch wenn die aktuelle Logdatei noch nicht voll ist mit dem Befehl

## Recover
### Recover allgemeine Bemerkungen

Vor dem Starten eines Recover sollte immer eine genaue Fehleranalyse stehen. Dabei können grundsätzlich zwei Fehlerarten unterschieden werden:
logische Fehler
* Datenfehler durch fehlerhafte Programme
* Ein Programm oder Skript ist in seiner Verarbeitung abgebrochen und hinterläßt die Daten in einem inkonsistenten Zustand.
* Operator-Fehler z.B. ein Programm zur Erhöhung der Gehälter wurde aus Versehen zwei mal gestartet
* Anwender oder Administratoren haben aus Versehen wichtige Tabellen oder Datensätze gelöscht
* es stehen keine ausreichenden Systemressourcen zur Verfügung (Systemüberlastung, Tablespace-Dateien sind voll, Rollbacksegmente sind zu klein, Deadlocks)
technische Fehler
* Stromausfall
* Hardwarefehler z.B. bei den Speicherplatten
* Die Ausführung von Tools ist fehlgeschlagen, so dass sich die Daten in einem inkonsistenten Zustand befinden

### Recover planen

Wenn ein Datenfehler festgestellt wurde, dann sollten die einzelnen Schritte für das Recover genau geplant werden.
Erst wenn
* die Fehlerursache genau eingegrenzt ist und
* der Umfang der erforderlichen Recover-Massnahme genau ermittelt ist
ist es sinnvoll, mit dem Recover zu beginnen.

### Recover ausführen mit einer offline-Sicherung

Offline-Sicherungen können nur als Ganzes verwendet werden. Einzelne Teile oder einzelne Dateien können nicht wiederhergestellt werden. Es müssen alle beteiligten Dateien einschließlich dem System-Tablespace, den Control-Dateien und den Redolog-Dateien aus der Sicherung übernommen werden. Alle Datenänderungen, die seit dem Zeitpunkt der Erstellung der offline-Sicherung ausgeführt wurden, müssen wiederholt werden.

### Recover ausführen mit einer online-Sicherung

Einzelne Dateien können wiederhergestellt werden. Eine viel granularere Steuerung ist möglich. Die Änderungen an den Daten, die seit dem Herstellen der Sicherung ausgeführt wurden sind, können durch Auslesen der Log-Dateien nachvollzogen werden, ohne dass die Anwendungsprogramme neu ablaufen müssen. Für das Recover mit online-Sicherungen gibt es eine große Vielzahl von Möglichkeiten, auf die in diesem Seminar nicht eingegangen werden kann. Beispielhaft soll das recovern einer einzelnen Tablespace-Datei dienen, das auf der nächsten Seite erläutert ist.

### Recover Beispiel 1

Es wurde eine Datei, gelöscht, in der die Daten eines Tablespace mit Anwendungstabellen gespeichert waren. Es handelt sich um einen Tablespace, dessen Anlegen noch in den zur Verfügung stehenden LOG-Dateien verzeichnet ist.
1. Beim Hochfahren der Datenbank wird ausgegeben, dass eine Datei fehlt.
Ausgabe:
Die Datenbank konnte nicht geöffnet werden. Sie befindet sich im Status MOUNT
Nun ist die Datenbank geöffnet. Man kann auf alle Objekte zugreifen, ausser auf die Daten in dem defekten Tablespace.
Nun wird der Name des Tablespace ermittelt, der den Datafile 3 verwendet:
Es handelt sich um den Tablespace "USERS"
Die Datenbank kann selbständig auf die Daten der Sicherung zugreifen und die fehlende Datei wieder herstellen. Nun ist der Tablespace wieder in Ordnung.
Anmerkung: Falls der Tablespace vor einem Jahr angelegt worden ist und die Log-Dateien nicht mehr vorhanden sind für den gesamten Zeitraum dazwischen, dann ist der oben skizzierte Ablauf nicht möglich. Es muss mindestend die Log-Datei vorhanden sein, die das Anlegen des Tablespace protokolliert und alle zeitlich nachfolgenden Log-Dateien.

### Recover Beispiel 2

Es wurde eine Datei, gelöscht, in der die Daten eines Tablespace mit Anwendungstabellen gespeichert waren. Es steht eine Offline-Sicherung zur Verfügung und alle Log-Dateien seit der letzten Offline-Sicherung stehen auch zur Verfügung.
Dann kann man die betroffene Daten-Datei von der Offline-Sicherung kopieren und anschließend die Datenbank wieder hochfahren. Die Meldungen des STARTUP Befehls und des anschließenden Recover sind in dem nachfolgenden Script wiedergegeben:

# NLS
## NLS

Oracle bietet verschiedene Möglichkeiten, eine Client-Session zu parametrisieren, um auf länderspezifische Besonderheiten Rücksicht zu nehmen. Beim nächsten Connect müssen Änderungen an den Session-Parametern erneut ausgeführt werden.
Dieser Parameter bestimmt die Sprache, in der Server-Meldungen ausgegeben werden.
Durch diesen Parameter werden verschiedene andere Parameter verändert. So wird z.B. das Format der Datums- und Uhrzeit-Ausgabe, sowie die Zeitzone festgelegt. Diese Einzelparameter kann man anschließend trotzdem noch individuell verändern.
Das erste Zeichen der NLS_NUMERIC_CHARACTERS legt fest, ob ein Dezimalpunkt oder ein Komma ausgegeben werden soll. Das zweite Zeichen legt fest, mit welchen Zeichen die Abtrennung der Tausender-Stellen vorgenommen wird.
Beispiel:
Anführungszeichen ausgeben

# Import Export

Es gibt das Kommandozeilenwerkzeug exp zum Exportieren einer Oracle Datenbank.
Dieser Export kann dann mit dem Kommandozeilenwerkzeug imp wieder eingespielt werden.
Ab der Version 10 kann Alternativ dazu auch der Enterprisemanager verwendet werden (Export und Import mit Hilfe des Webbrowsers, mir persönlich zu umständlich und unübersichtlich).
Bitte beachten sie, dass bei Oracle 8 und 9 die Datenbank (hinter dem @) angegeben werden muss. Bei der Version 10 ist das nicht erforderlich, hierbei muss allerdings der Datenbankname als Umgebungsvariable zur Verfügung stehen. z.B. unter Linux/Unix export ORACLE_SID=$dbname
Des Weiteren besteht die Möglichkeit bei vielen Parametern y oder yes zu verwenden.
Grundsätzlich gibt es vier verschiedene Modi:
* full - vollständiger Export bzw. Import, meistens durch den User system durchgeführt.
* user - nur die Datenbankobjekte exportieren bzw. importieren, die diesem User gehören
* table - einzelne Tabellen exportieren bzw. importieren
* tablespace - einzelne Tablespaces exportieren bzw. importieren

## exp

Syntax:
Hilfe:
$expModes:
$expOpts:
Beispiele:
Einen kompletten Export einer Oracle Datenbank kann beispielsweise hiermit erstellt werden:
Einen userspezifischen Export kann beispielsweise hiermit erstellt werden:
Falls der Export mit dem Benutzer system durchgeführt wird kann der User mit dem Parameter "owner" angegeben werden.
Ein Export von einer oder mehreren Tabellen kann beispielsweise folgendermaßen aus sehen:
Ein Export von Tablespace(s) kann beispielsweise folgendermaßen aus sehen:

## imp

Der Import funktioniert korrespondierend zum Export, d.h. es gibt auch wieder die vier Modi und etliche Optionen. Hinzu kommt, dass auch "in" einen anderen Benutzer importieren kann.
Syntax:
Hilfe:
$impModes:
$impOpts:
Beispiele: Einen kompletten Import einer Oracle Datenbank kann beispielsweise hiermit erstellt werden.

# Datenbank Tuning

Es gibt viele Bereiche für das Tuning einer Oracle-Datenbank.

## Lock-Erkennung und -Behebung
### Locks auf der Datenbank ermitteln

Ausgeben aller Sessions, die gerade von anderen Sessions blockiert werden.
Locks auf allen Objekten in der Datenbank anzeigen
Locks nur für die Objekte des aktuellen Benutzers in der Datenbank anzeigen
SQL-Statement-Cache der aktuellen Sessions anzeigen

### Skript catblock.sql zur Anzeigen von Sperrungen

In $ORACLE_HOME\RDBMS\ADMIN\catblock.sql befindet sich ein Script zum Erstellen einiger System-Views, mit denen Locks angezeigt werden können. Folgende Views werden erstellt:
* DBA_KGLLOCK
* DBA_LOCKS
* DBA_LOCK
* DBA_LOCK_INTERNAL
* DBA_DML_LOCKS
* DBA_DDL_LOCKS
* DBA_WAITERS
* DBA_BLOCKERS
Blockiert jemand eine andere Transaktion?
Wer wird blockiert?
Wie lange wartet die Session 13 schon?
Welche User arbeitet als Session 13 bzw. 19?

### Skript utllockt.sql zur Anzeige von wartenden Transaktionen

In $ORACLE_HOME\RDBMS\ADMIN\utllockt.sql findet man ein Script zur Anzeige von wartenden Transaktionen.
In diesem Script wird
* eine Tabelle erstellt,
* mit Daten gefüllt,
* angezeigt
* und dann wird die Tabelle wieder entfernt.
Beispiel für eine Anzeige von Sperren:
* Die Session 9 wartet auf die Session 8.
* Session 7 wartet auf Session 9
* Session 10 wartet ebenfalls auf Session 9

### Kill Session

Die Session 19 blockiert die Session 13 schon seit 34 Minuten. Sie soll beendet werden. Bei kill session muss man immer die Session-Id und die Serial-Nummer in Anführungszeichen angeben.
Die Session 19 erhält zunächst keine Fehlermeldung. Erst wenn der nächste Befehl eingegeben wird, stellt SQL-PLUS fest, dass die Verbindung zur Server-Session nicht mehr existiert:

# CharacterSet ändern

In diesem Kapitel wird beschrieben, wie man den Zeichensatz in einer Datenbank ändern kann. Der Zeichensatz der Datenbank legt fest, mit welcher Codierung die Text-Informationen auf der Festplatte gespeichert werden. Wenn z. B. ein w:ASCII-Zeichensatz mit deutschen Umlauten festgelegt ist, dann können in den Tabellen dieser Datenbank zwar alle deutschen Schriftzeichen gespeichert werden (inkl. ä, ö, ü und ß), jedoch nicht die Umlaute aller anderen europäischen Länder. Erst recht können keine Schriftzeichen gespeichert werden, die nicht auf dem w:lateinischen Alphabet basieren. Wenn man für die Datenbank einen w:Unicode-Zeichensatz festlegt, dann können fast alle Schriftzeichen dieser Welt gespeichert werden, allerdings wird für alle seltener vorkommenden Schriftzeichen (also auch für die deutschen Umlaute) jeweils mehr als ein Byte Speicherplatz verbraucht.
Eine (Rückwärts-) Konvertierung von UTF8 nach WE8MSWIN1252 ist nur mit Verlusten möglich, da WE8MSWIN1252 eine echte Untermenge von UTF8 ist. Beispielsweise sind die griechischen oder kyrillischen Buchstaben in UTF8 vorhanden, aber nicht in WE8MSWIN1252.
Unabhängig vom Zeichensatz der Datenbank ist der Zeichensatz eines Oracle-Clients. Wenn die Zeichensätze sich unterscheiden, dann werden die Daten konvertiert, soweit das möglich ist.
Vor der Umstellung sollte auf jeden Fall ein FullBackup der Datenbank erstellt werden, damit man diesen wieder zurückladen kann, wenn irgend etwas schief geht. Außerdem sei erwähnt, dass "alter database character set ..." seit Oracle 10gR1 nicht mehr unterstützt wird. Nachfolgende Anleitung ist deshalb nur mit größter Vorsicht zu verwenden, laut Oracle Dokumenation können die Daten in CLOB Spalten korrupt werden. Wenn man sicher gehen will, sollte man sich besser an die entsprechende Dokumentation von Oracle halten: Character Set Migration
Als sys mit sysdba-Berechtigung via sqlplus an der Oracle Instanz anmelden.
CharacterSet der Datenbank überprüfen
bzw. um sämtliche Einstellungen zu sehen
Die Datenbank anhalten
Die Datenbank einhängen aber noch nicht öffnen
Bei manchen Versionen gab es an dieser Stelle einen Bug, bei dem ein Fehler nach "startup mount;" ausgegeben wurde. Falls dieser noch nicht behoben ist, kann folgender Befehl eventuell helfen "connect / as sysdba".
Session für Operation vorbereiten
Datenbank öffnen
CharacterSet ändern
hiermit geht es dann
Datenbank wieder schließen und herunterfahren
Datenbank wieder normal hochfahren
Nochmal
ausführen und die Einstellungen überprüfen.
Getestet auf Oracle 8.1.7.3 unter Windows 2000 Server.
Getestet auf Oracle 10.1.0.2.0 unter Linux; erfolgreich.
Getestet auf Oracle 10.2.0.4 unter Windows 2003 Server; erfolgreich (obwohl dies lt. Oracle SQL Reference 10g nicht mehr möglich sein sollte).
Getestet auf Oracle 11.1.0.7 unter AIX5L Server; erfolgreich.
Getestet auf Oracle 11.2.0.1.0 unter Windows 2008 Enterprise Server; erfolgreich.
Getestet auf Oracle 11.2.0.1.0 unter Oracle Enterprise Linux 6.4; erfolgreich.

# Links

Verwandte Themen in Wikibooks
http://de.wikibooks.org/wiki/SQL
http://de.wikibooks.org/wiki/PL/SQL
http://de.wikibooks.org/wiki/Relationenalgebra_und_SQL
Verwandte Themen in Wikipedia
http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem)
http://de.wikipedia.org/wiki/PL/SQL
http://de.wikipedia.org/wiki/Oracle_Real_Application_Cluster
Links zum sonstigen WWW
http://www.oracle.com
http://www.sysdba.de
http://www.aquafold.com
http://www.quest.com
http://web.dadanini.com:7980/books/Sql_in_21Tagen/
http://www.orafaq.com/wiki/Main_Page
* Druckversion des Buches Name des Buches
* Dieses Buch umfasst derzeit etwa ? DIN-A4-Seiten einschließlich Bilder.
* Wenn Sie dieses Buch drucken oder die Druckvorschau Ihres Browsers verwenden, ist diese Notiz nicht sichtbar.
* Zum Drucken klicken Sie in der linken Menüleiste im Abschnitt „Drucken/exportieren“ auf Als PDF herunterladen.
* Mehr Informationen über Druckversionen siehe Hilfe:Fertigstellen/ PDF-Versionen.
* Hinweise:
* Für einen reinen Text-Ausdruck kann man die Bilder-Darstellung im Browser deaktivieren:
* Internet-Explorer: Extras > Internetoptionen > Erweitert > Bilder anzeigen (Häkchen entfernen und mit OK bestätigen)
* Mozilla Firefox: Extras > Einstellungen > Inhalt > Grafiken laden (Häkchen entfernen und mit OK bestätigen)
* Opera: Ansicht > Bilder > Keine Bilder
* Texte, die in Klappboxen stehen, werden nicht immer ausgedruckt (abhängig von der Definition). Auf jeden Fall müssen sie ausgeklappt sein, wenn sie gedruckt werden sollen.
* Die Funktion „Als PDF herunterladen“ kann zu Darstellungsfehlern führen.
* ↑ https://docs.oracle.com/cd/B12037_01/server.101/b10759/statements_1004.htm#sthref2671