[Arbeitsgruppe Datenbanken][Dipl.-Inform. Christian Goldberg]
Bei der Installation können vor allem bei den älteren Versionen der OracleDB unter Linux Probleme auftreten. Generell gilt bzgl. der Kompatibilität:
| DB-Version | kompatiblel mit | Hardwarevoraussetzungen |
| 8i | Windows 95/NT | CPU: ab Pentium RAM: mind. 32MB HDD: 100-200 MB |
| 9i | Windows NT ab SP5 Windows 2000 ab SP1 Windows XP Professional SuSE Linux Enterprise Server 7/8 (SuSE Linux Prof. 7/8 mit Einschränkungen) |
CPU: ab Pentium 266 MHz RAM (Client/Server): mind. 128MB/256MB (WIN), mind. 256MB/512MB (Linux) SWAP: 400 MB (WIN), 1GB (Linux) HDD: 3-5 GB |
| 10g | Windows 2000 ab SP1 Windows XP Professional Windows Server 2003 SuSE Linux Enterprise Server 9 (SuSE Linux Prof. 9 mit Einschränkungen) Red Hat Enterprise Linux 3.0 ab Update 3 Red Hat Enterprise Linux 4.0 |
CPU: ab 1GHz RAM (Client/Server): mind. 512MB/1GB SWAP: 1,5x RAM HDD: 3-7 GB |
Die Versionen 9i und 10g laufen nicht unter Windows XP Home! Die DB wird hier als eine Reihe von Diensten eingerichtet, die nach der Installation bei jedem Start von Windows gestartet werden. Sollte dies nicht erwünscht sein (z.B. da man die DB nicht ständig benötigt), wird empfohlen, die Dienste auf manuelles Starten zu stellen, da der Startvorgang recht lange braucht.
Novell hat für SuSE Linux Enterprise Server 9 (SLES9) ein RPM-Packet namens orarun erstellt, welches einen Oracle-Nutzer sowie die nötigen Start- und Stop-Skripte vorkonfiguriert. Es müssen dann nur noch das Passwort für den Oracle-Nutzer sowie Pfade und zu startende Datenbanken geändert werden. Das RPM-Packet kann mit kleinen Einschränkungen auch für SuSE Linux Prof. 9 (SLPro9) verwendet werden. Es ist auf den SLES9-CDs enthalten oder kann per FTP bezogen werden (näheres siehe Installationsanleitungen unten).
Weitere Informationen zur Installation:
Folgende Umgebungsvariablen werden von z.B. SQL*Plus verwendet, um auf eine lokale Datenbank zuzugreifen:
ORACLE_HOME ORACLE_BASE ORACLE_SID
Sie bezeichnen den Pfad zum Oracle-Verzeichnis sowie den Namen der Datenbank, die verwendet werden soll. Sofern eine lokale Oracle-DB existiert, die von allen genutzt wird, sollte man diese Variablen möglichst in die globalen Konfigurationsdateien eintragen, also z.B. unter Linux in die Datei /etc/profile.local und unter Windows in die Liste der Umgebungsvariablen unter "Eigenschaften von Arbeitsplatz" -> "Erweitert" -> "Umgebungsvariablen". Zusätzlich kann man noch den Pfad um das Oracleverzeichnis $ORACLE_HOME/bin erweitern.
Die Umgebungsvariablen können natürlich jederzeit vom Nutzer für seinen Account überschrieben werden, falls dieser z.B. eine andere lokale Datenbank nutzen möchte.
Auf dem Linux-Server bach (141.48.14.51) sind die Umgebungsvariablen in der Datei /etc/profile.local z.B. folgendermaßen gesetzt:
export ORACLE_HOME=/dbs/oracle/OraHome1/ export ORACLE_BASE=/dbs/oracle/OraHome1/ export ORACLE_SID=lxdb1
Für die Nutzung von entfernten Datenbanken, kann sich jeder Nutzer mit Hilfe des "Netzwerk-Konfigurations-Assistenten" ($ORACLE_HOME/bin/netca) eine Datei tnsnames.ora in seinem Home-Verzeichnis erstellen, in der die Verbindungsdaten stehen. Unter SQL*Plus und anderen Datenbank-Tools kann man dann den dort definierten Datenbanknamen verwenden.
Siehe hierzu auch: Datenbankverbindung zu bach von außen tunneln.
Einige Windows-Applikationen von Oracle haben die Eigenart, beim Anmelden nur 3 Eingabefelder (Benutzerkonto, Kennwort, Hostzeichenfolge) anzubieten. Eine erweiterte Anmeldeoption "AS SYSDBA" oder "AS SYSOPER" kann man hier - im Gegensatz z.B. zur OEM-Console - nicht auswählen. Der Versuch, diese Optionen wie beim Kommandozeilen-SQL*Plus direkt hinter den Nutzernamen zu hängen, schlägt hier allerdings fehl.
Um sich dennoch als SYSDBA oder SYSOPER anzumelden muß man hier den entsprechenden String (z.B. "AS SYSDBA") hinter die Host-Zeichenfolge anhängen! Eine Anmeldung von SYS im SYSDBA-Modus mit dem Kennwort XXX auf der Datenbank ORACLE würde also folgende Eingaben unter Windows benötigen:
Benutzername : SYS Kennwort : XXX Hostzeichenfolge: ORACLE AS SYSDBA
Die Standard-Passwörter werden von Oracle verwendet, bis sie z.B. während der Konfiguration mit Hilfe des Datenbank-Konfigurations-Assistenten (dbca) erstmalig festgelegt/geändert werden. Sollte der Assistent sich vorzeitig beenden, z.B. wegen eines Absturzes oder einer Fehlermeldung, kann es passieren, daß die Nutzer schon mit diesen Passwörtern angelegt wurden:
SYSTEM/MANAGER SYS/CHANGE_ON_INSTALL DBSNMP/DBSNMP SCOTT/TIGER
Der Nutzer SCOTT ist ein Beispielnutzer, der während der Konfiguration mit Hilfe von Templates angelegt wird. Weitere Beispielnutzer, die im Nachhinein durch Skripte (z.B. utlsampl.sql) angelegt werden können sind:
ADAMS/WOOD JONES/STEEL CLARK/CLOTH BLAKE/PAPER
Da diese Accounts allgemein bekannt sind, sollte man sie nach der Installation schnellstmöglich ändern bzw. deaktivieren!
Die vollständige EMP-DEPT-Datenbank aus dem Praktikum "Praktische Datenbankprogrammierung" kann über des Skript $ORACLE_HOME/demo/empdept/empdept.sql auf linpc26 bzw. $ORACLE_HOME/demo/empdept.sql auf bach (141.48.14.51) installiert werden.
Alle Datenbanken, die mithilfe von Templates des Datenbank-Konfigurations-Assistenten erstellt wurden, enthalten bereits mehrere, schon installierte Beispiel-Schemas inklusive der zugehörigen Benutzer:
| Datenbank/Schema | Besitzer | PL/SQL-Skript | Tablespace | Weitere Nutzer |
| Human Resources | HR | human_resources/hr_main.sql | EXAMPLE | |
| Order Entry | OE | order_entry/oe_main.sql | EXAMPLE | |
| Product Media | PM | products_media/pm_main.sql | EXAMPLE | |
| Shipping | QS | shipping/qs_main.sql | EXAMPLE | QS_ADM, QS_CB, QS_CBADM, QS_CS, QS_ES, QS_OS, QS_WS |
| Sales History | SH | sales_history/sh_main.sql | EXAMPLE | |
| Emp-Dept | SCOTT | - | SYSTEM |
Die Pfad-Angaben beziehen sich auf Unterverzeichnisse von $ORACLE_HOME/demo/schema/. Die angegebenen Skripte installieren bei Ausführung durch den DBA (SYS) die jeweilige Datenbank inklusive der zugehörigen Nutzer. Dabei wird man jeweils interaktiv nach den betreffenden Passwörtern für die neuen Nutzer gefragt.
Mit den Scripten $ORACLE_HOME/demo/schema/mksample.sql und /$ORACLE_HOME/demo/schema/mk_dir.sql können sämtliche Schemas (außer Emp-Dept) auf einmal installiert werden. Siehe dazu auch die README.txt im selben Verzeichnis.
Die Emp-Dept-Datenbank des Nutzers SCOTT ist eine abgespeckte Variante, der oben angegebenen vollständigen Datenbank. Sie besteht nur aus den Tabellen EMP, DEPT, SALGRADE und BONUS. Für diese abgespeckte Variante gibt es kein Installationsskript.
Vorsicht! Sollte die zu erstellende Datenbank bereits bestehen, wird diese bestehende DB automatisch gelöscht! Damit gehen dann auch alle evtl. schon vorgenommenen Änderungen verloren.
Die Oracle-Datenbank bietet die Möglichkeit, sich die Ausführung eines SQL-Statements sowie eine zugehörige Statistik ausgeben zu lassen. Damit kann man z.B. die Ausführungsgeschwindigkeit bzw. Komplexität und Kosten von SQL-Anfragen vergleichen oder überprüfen, ob bei bestimmten Anfragen die eingerichteten Indizes von Oracle benutzt werden. Die Statistik sagt außerdem noch etwas über die Anfragegröße und die Menge der übertragenen Daten aus.
Der zugehörige Befehl unter Oracle sieht dabei folgendermaßen aus:
EXPLAIN PLAN FOR <SQL-Statement>
Dieser veranlaßt Oracle, so zu tun, als ob das SQL-Statement ausgeführt würde (was aber nicht getan wird) und speichert den zugehörigen Ausführungsplan in die Tabelle PLAN_TABLE. Mit Hilfe eines speziellen SQL-Statements kann man nun die gewünschten Informationen aus der Tabelle extrahieren. Allerdings exisitert diese Tabelle unter Oracle 9i nicht von Anfang an, sondern jeder Nutzer muß diese für sich selbst erstellen. Um dies zu erleichtern (die Tabelle hat 29 Attribute), gibt es unter $ORACLE_HOME/rdbms/admin ein Skript namens utlxplan.sql, welches die Tabelle erstellt. Bei Oracle 10g wird die Tabelle automatisch erstellt.
Da das komplette SQL-Statement zur Ausgabe der Informationen aus PLAN_TABLE sehr kompliziert ist (eine vereinfachte Variante gibt es hier), empfiehlt es sich, die autotrace-Funktion von SQL*Plus zu nutzen, um an die gewünschten Informationen aus der Tabelle zu kommen. Der Befehl dafür lautet:
set autotrace on
und sorgt dafür, das an jede Ausgabe eine Tabelle mit dem Ausführungsplan und eine mit den zugehörigen Statistiken angehängt wird. Abschalten kann man dieses Verhalten wieder mit:
set autotrace off
Um diese Funktion nutzen zu können, muß man allerdings vom Administrator die Rechte der Rolle PLUSTRACE zugeordnet bekommen haben. Die Rolle kann vom DBA mit Hilfe des Skriptes $ORACLE_HOME/sqlplus/admin/plustrce.sql erstellt und dann den Nutzern oder natürlich auch anderen Rollen zugewiesen werden.
Nach einem Patch der Datenbank (von 9.2.0.1) oder des DB-Clients kann es trotz zugewiesener PLUSTRACE-Rolle und erstellter PLAN_TABLE (siehe 1.5.) passieren, daß das Setzen der Autotrace-Funktion mit einer Fehlermeldung abgewiesen wird:
SP2-0618: Cannot find the Session Identifier. Check PLUSTRACE role is enabled SP2-0611: Error enabling STATISTICS report
Wobei es passieren kann, daß das oben beschriebene Verhalten nicht bei Windows-Clients, sondern nur bei Unix/Linux-Clients auftritt oder auch umgekehrt!
Dies kann an einer veränderten SessionID-Abfrage für die Statistiken liegen, die auch etwas andere Zugriffsrechte verlangt. In der alten Version (9.2.0.1) geschieht dies über den View V_$SESSION, bei der neuen Version (Patchset 9.2.0.3 bzw. 9.2.0.4) allerdings über den View V_$MYSTAT für den dann entsprechend SELECT-Rechte benötigt werden.
Auf der sicheren Seite ist man, wenn beide Rechte gleichzeitig eingetragen werden. Hier die Liste der benötigten Rechte für die Rolle PLUSTRACE (SQL-Syntax nach Einloggen als sys):
grant select on v_$sesstat to plustrace; grant select on v_$statname to plustrace; grant select on v_$session to plustrace; grant select on v_$mystat to plustrace;
Entsprechend sollte man das Script $ORACLE_HOME/sqlplus/admin/plustrce.sql abändern, damit der Fehler bei der späteren Nutzung dieses Scriptes nicht wieder auftritt.
Ein Repository kann man sich wie eine Art Daten-Container vorstellen, der Meta-Daten über Projekte enthält. Es wird nicht benötigt, um schnell eine kleine Datenbank zu erstellen (z.B. EMP-DEPT), sondern für größere oder eine Vielzahl von kleinen Projekten.
Mit Hilfe des Repository können auf einfache und komfortable Weise alle Projekte (inkl. z.B. Informationen über das Datenmodell, das Prozessmodell und viele andere Design-Aspekte einer Anwendung) und zugehörige Daten wie Nutzer und deren Zugriffsrechte bzgl. der Projekte verwaltet werden.
Möchte man zum Erstellen einer Datenbank den Oracle Designer verwenden, so ist es ebenfalls notwenig, ein Repository zu erstellen, da der Designer von Oracle auf diesem Mechanismus basiert. Für Anwender, die eine einfache Möglichkeit suchen, um rechnergestützt ein ER-Diagramm zu erstellen und dieses automatisch in ein relationales DB-Schema überführen zu lassen, ist diese Methode eher ungeeignet. Für solche Zwecke gibt es extra Anwendungen (wie z.B. den Power Designer der Firma CA), die wesentlich effizienter arbeiten und nicht vorher tausende von Tabellen, Trigger, Packages usw. im Bereich von über 100 MB in die Datenbank speichern müssen.
Wer aber dennoch ein Repository erstellen will oder muß, sollte vor dem Erstellen einige Punkte beachten:
Der Besitzer (Owner) des Repository ist ein Benutzer mit Sonderrechten! Man sollte hier nicht irgendeinen beliebigen Account nehmen und darunter das Repository installieren, sondern sich genau überlegen, wer das Repository administrieren darf und wer es nur benutzen soll. Am vernünftigsten ist wohl die Variante, für den Repository-Administrator einen ganz neuen Benutzer zu erstellen. Dieser kann dann schon existierenden Benutzern Rechte zur Nutzung des Repository erteilen.
Der Repository-Besitzer wird nicht automatisch angelegt, sondern muß VOR dem Erstellen existieren, da man sich am Repository Administration Utility (RAU) als selbiger vorher anmelden muß.
Der Benutzer, unter dessen Account das Repository erstellt werden soll, benötigt folgende Rechte:
ALTER SESSION CREATE DATABASE LINK CREATE PROCEDURE CREATE PUBLIC SYNONYM # Nicht unbedingt notwendig, aber empfohlen CREATE ROLE CREATE SESSION CREATE TRIGGER CREATE TYPE CREATE VIEW DROP PUBLIC SYNONYM # Nicht unbedingt notwendig, aber empfohlen SELECT ANY SEQUENCE SELECT ON sys.dba_rollback_segs # View des Benutzers SYS (10g) SELECT ON sys.dba_segments # View des Benutzers SYS (10g) SELECT ON sys.v_$nls_parameters # View des Benutzers SYS (10g) SELECT ON sys.v_$parameter # View des Benutzers SYS EXECUTE ON sys.dbms_lock # Package von SYS EXECUTE ON sys.dbms_pipe # Package von SYS EXECUTE ON sys.dbms_rls # Package von SYS (10g) CREATE ANY SYNONYM DROP ANY SYNONYM
wobei der untere Block der Rechte NICHT in Form einer Rolle erteilt werden darf! Diese Rechte müssen dem Repository-Besitzer direkt zugewiesen werden. Eine Begründung für dieses Verhalten habe allerdings ich bisher noch nicht gefunden. Der obere Block darf ohne weiteres in Form einer oder mehrerer Rollen zugewiesen werden (je nach Organisation und Hierarchie der vorhandenen Rechte und Rollen in der Datenbank). Rechte, die mit (10g) gekennzeichnet sind, sind bei der Version 10g (ab 9.0.4.5) des Designers hinzugekommen und waren bei mir bei der Version 9i nicht notwendig.
Sind diese obigen Rechte nicht gesetzt, so wird die Installation des Repositories früher oder (meist) später mit einer Fehlermeldung stoppen. An dieser Stelle ist es allerdings noch möglich, die nötigen Rechte zu setzen (z.B. mit dem OEM oder mit SQL*Plus: GRANT ... TO ...) und den aktuellen Vorgang nochmal zu wiederholen (durch Klicken auf den "Pfeil nach links" = rewind).
Ob die notwendigen Rechte für den Repository-Besitzer wirklich zufriedenstellend gesetzt wurden, sollte man vor der Installation nochmals mit Hilfe des Repository Administration Utility -> Check Requirements überprüfen.
Nach dem Klick auf "Install" wird man unter anderem gefragt, ob man "public synonyms" verwenden möchte. Wenn Sie mehr als 10 Nutzer für den Zugriff auf das Repository planen, sollten Sie hier auf jeden Fall (wie empfohlen) "JA" wählen, da sonst für jeden neu freigeschalteten Nutzer erst Synonyme erstellt werden müssen, was bei vielen Nutzern sehr lange dauert und nervt, da es nicht zusammen für alle, sondern für jeden Nutzer extra geschieht!
Damit man die Option verwenden kann, sind die obigen Rechte CREATE/DROP PUBLIC SYNONYM für den Repository-Besitzer obligatorisch.
Beim Erstellen des Repository wird man u.a. gefragt, welche Teile in welchem Tablespace gespeichert werden sollen. Hier ist unbedingt darauf zu achten, daß der ausgewählte Tablespace 1. genügend Platz zur Verfügung stellt (Maximalgröße) und 2. die Quota-Einstellungen des Repository-Besitzers für den gewünschten Tablespace ausreichend gesetzt sind (200-300 MB sollten es bei der "SMALL"-Variante schon sein!). Am besten man erstellt für das Repository (je nach Größe und vorhandenem Plattenplatz) einen oder mehrere Tablespaces extra, und noch besser: aus Performancegründen auf unterschiedlichen Platten. Der Repository-Besitzer benötigt dann entsprechende Quotas auf allen zu verwendenden Tablespaces, sonst tauchen diese gar nicht in der Auswahl auf!
Auch dies kann notfalls während des Erstellens noch geändert werden.
Nach dem Erstellen kann der Besitzer (nur) den schon in der DB vorhandenen Benutzern mit dem RAU das Recht zuweisen, das Repository zu benutzen. Mit Hilfe des Repository Object Navigators (RON) können unterhalb des Repositories außerdem weitere Container angelegt und Benutzern zugeordnet werden.
Beim Designer (Design Editor, RON, ...) kann sich danach jeder Benutzer, der das Recht der Nutzung zugewiesen bekommen hat, unter seinem normalen Account anmelden!
Um auf ein bereits installiertes Oracle Designer Repository zuzugreifen, müssen die Versionen des installierten Repository und des Oracle Designers, mit dem darauf zugegriffen wird, übereinstimmen. Bei nicht übereinstimmenden Versionen bringt der Oracle Designer eine entsprechende Fehlermeldung. Hier gibt es nur 2 Lösungsmöglichkeiten:
Um auf das Repository der DB studdb im Institut zuzugreifen, muß die Version des zu verwendenden Designers mit der dort installierten Version (10.1.2.0.2) übereinstimmen. (Die alte Version funktioniert seit dem Sommersemester 2007 nicht mehr!) Diese neue Version ist direkt als Paket von Oracle erhältlich. Um diese Version zu installieren, gehen Sie folgendermaßen vor:
Downloads und Links zu diesem Thema:
Stand dieser Informationen: 26.04.2007.
| CG, Halle (Saale), 26.04.2007; 16:08:01 |
|