Tipps & Tricks rund um die Oracle Datenbank. de http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/images/11g.jpg http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/index.html http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/rdbmsadmin/index.html Die mitgelieferten Skripte im Verzeichnis $ORACLE_HOME/rdbms/admin bieten schon seit jeher DBAs und Entwickler eine zusätzliche Unterstützung bei ihrer Arbeit. Sie stehen automatisch nach jeder Installation im Verzeichnis rdbms/admin zur weiteren Verwendung zur Verfügung. Nur wie findet man genau das Skript, das einem die richtige Unterstützung bietet?

Eine Dokumentation aller Skripte existiert nicht. Man kann sich an den Namen der Skripte orientieren, da sie mit sprechenden Namen aufgelistet sind und kann die Kurzeinleitung im Skript nachlesen. Das ist mühselig und kostet Zeit. Daher bietet dieser Tipp einen Überblick über wichtige Skripte einschließlich einer Kurzbeschreibung. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/flashback_database/index.html Flashback Database bezeichnet die Funktionalität der Oracle Datenbank, die Datenbank zeitlich auf einen bestimmten Punkt, respektive eine bestimmte System Change Number (SCN) zurücksetzen zu können - vergleichbar mit einem Rückspulknopf eines Kassettenrekorders oder der Rücksetztaste eines CD-Players.

Mag dieses Vorgehen bei Produktivsystemen eher selten Einsatz finden, da beim Rücksetzten alle Daten nach dem zurückgesetzten Zeitpunkt verloren wären (es sei denn man würde dieser vorher exportieren), gibt es gerade für Test- oder Standby Systeme viele Einsatzmöglichkeiten. Einige bestehende Datenbank Funktionalitäten verwenden Flashback Database implizit.

Obwohl diese Funktionalität gerade für Standby Systeme und Testsysteme bestens geeignet ist, gibt es eine gewisse Zurückhaltung Flashback Database einzusetzen. Eine Ursache ist oft die Angst vor zusätzlicher Last, die das Schreiben der Flashback Logs erzeugt, sowie der zusätzlich benötigte Plattenplatz. Dabei ist die Last im Normalfall relativ gering (ca. 5%) und auch der zusätzlich benötigte Platz für die Flashback Logs lässt sich relativ genau bestimmen. Ebenfalls wird häufig nicht beachtet, dass es auch ohne das explizite Einschalten der Flashback Logs möglich ist, einen garantieren Rücksetzpunkt (Guaranteed Restore Point kurz GRP) festzulegen, und die Datenbank dann auf diesen Restore Point zurückzusetzen. Das Setzen eines garantierten Rücksetzpunktes funktioniert in 11gR2 im laufenden Betrieb.

Wie dies genau funktioniert, welche Unterschiede es zum generellen Einschalten von Flashback Logs gibt, wie man Flashback Database monitoren kann und was es sonst noch zu berücksichtigen gibt, damit beschäftigt sich der heutige Tipp. https://blogs.oracle.com/dbacommunity_deutsch/ Oracle Enterprise Manager Cloud Control 12c verwaltet Systeme unterschiedlicher Art wie zum Beispiel Datenbanken, Application Server, Applikationen oder ganze Exadata Maschinen. Die Benutzer von Cloud Control haben also unterschiedliche Interessen. Dieses betrifft sowohl die Einstiegsseite eines Benutzers in Cloud Control, als auch einzelne Target-Homepages.

Ein Datenbankadministrator möchte als Einstiegsseite zum Beispiel automatisch die Liste der Datenbanken angezeigt bekommen, für die er auch zuständig ist. Ein Middleware Administrator wünscht sich sicherlich eine andere Einstiegsseite. Aus diesem Grund kann die Einstiegsseite personalisiert werden. Lesen Sie unter "Personalisierung der Einstiegsseite", wie das funktioniert.

Auch einzelne Target-Homepages können individuell angepasst werden, wie der Tipp "Persönliche Gestaltung einzelner Seiten" zeigt. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/help/index.html Es gibt eine ganze Reihe an Oracle Tools für die Oracle Datenbank, die per Command Line Interfaces bedient werden können: Von RMAN über ADRCI, vom SQL*Loader über Export/Import, von SRVCTL über SQL*Plus. Und wie es sich für ordentliche Werkzeug gehört, besitzt auch (fast) jedes einzelne von ihnen eine eigene Hilfestellung. Wobei die Betonung eindeutig auf "eigene" liegt.

Auch der ungeübte Benutzer wird sehr schnell merken, dass Oracle sich hier wohl nie so wirklich Gedanken darüber gemacht hat, die Hilfefunktionen zu vereinheitlichen - außer dass die Hilfe mehr oder weniger hilfreich ist. Die wohl interessanteste Ausprägung dieser Hilfefunktion ist hier sicherlich der RMAN, dessen umfangreiche Syntaxhilfe nur schwer zu erhalten ist - es sei denn man vertippt sich absichtlich. Solange man alles richtig macht (oder eben falsch, aber leider mit der richtigen Syntax) ist RMAN kein Hinweis über seine umfangreichen Syntaxchecker zu "entlocken".

Wie man bei den vielen unterschiedlichen Oracle Tools die hilfreichen Informationen bekommt, damit beschäftigt sich unser Tipp. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/net/index.html Der Zugriff auf Datenbanken über das Netzwerk stellt aus Security Sicht einen ausgesprochen kritischen Vorgang dar, der unbedingt vor Missbrauch geschützt werden muss. Deshalb ist es auch nicht weiter verwunderlich, dass im Security Ecosystem etliche Produkte angeboten werden, die diesen Zugriff sichern helfen: Das beginnt bei Firewalls mit SQL Net Proxy, geht über Produkte wie die Oracle Database Firewall, die einen Schutz vor SQL Injection Angriffen über das Netzwerk leisten, und endet etwa bei den Angeboten zur Netzwerkverschlüsselung, wie sie im Oracle Datenbankumfeld vor allem die Advanced Security Option anbietet.
Aber vor jedem Einsatz schwieriger oder kostspieliger Mittel zur Steigerung der Sicherheit einer Datenbank steht der Einsatz solcher Mittel, die ohne zusätzliche Kosten oder relativ einfach zu implementieren sind. Dazu gehören das bereits in einem Community Artikel andiskutierte Härten der Datenbank oder das in einem weiteren Artikel angesprochene Umsetzen des Prinzips des least privilege. Im vorliegenden Artikel soll darauf eingegangen werden, wie die Verbindungsaufnahme zur Datenbank über einen Listener Prozess sowie die Netzwerkverbindung zwischen Client und Datenbank über SQL Net eigene Mittel so konfiguriert werden können, dass dies die Sicherheit einer Datenbank ohne Zusatzkosten erhöht. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/adrci/index.html Mit der Oracle Datenbank 11g wurde das Logverhalten der Oracle Datenbank umgestellt und die Trace, Log und Alert Informationen im Automatic Diagnostic Repository abgespeichert. Der primäre Grund, die Protokollierung der Datenbank von der alten Struktur unter $ORACLE_BASE/admin in die neue Struktur unter $ORACLE_BASE/diag/rdbms zu überführen, lag sicherlich auch an der Formatänderung in das XML Format, welches die gespeicherten Daten nun maschinell einfacher lesbar macht.
Damit einher gingen aber auch viele andere nützliche Funktionalitäten, wie das automatische Rollieren der Logfiles, das automatische Löschen derselben und die Möglichkeit der Erzeugung von sogenannten Incident Paketen, die alle notwendigen Informationen zu einem spezifischen Problem enthalten, um diese Informationen gesammelt an Oracle Support weiterzuleiten zu können.
Aber nicht nur die Oracle Datenbank protokolliert in die Struktur des Automatic Diagnostic Repositories. Immer mehr Oracle Tools nutzen diese Struktur zu Protokollierung. So findet man die Logfiles des Listeners und des Oracle Clients in dieser Struktur wieder - auch wenn dies, wie beim Client, nicht unter $ORACLE_BASE, sondern in dem Verzeichnis geschieht, aus dem zum Beispiel SQLPlus aufgerufen wurde. Selbst der neueste Enterprise Manager 12c Agent verwendet das ADR schon, es ist also nur noch eine Frage der Zeit, bis auch die Grid Infrastruktur ihre Logfiles dort ablegen wird.
Umso wichtiger ist es, sich das Command Line Interface zu diesem Automatic Diagnostic Repository im folgenden Tipp mal genauer anzuschauen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/compadv1/index.html Seit 11g Release 2 steht standardmässig ein Compression Advisor in der Datenbank zur Verfügung. Ohne zusätzliche Installation ist dieser Advisor über das Package DBMS_COMPRESSION in jeder Edition sofort einsetzbar. Im Gegensatz zum alten "Compression Advisor", der für Versionen vor 11g Release 2 von OTN geladen werden kann, ist diese Technologie auch für partitionierte Tabellen und für alle vorhandenen Komprimierungsalgorithmen (auch EHCC) einsetzbar.Nun stellt sich die Frage, ob man den Compression Advisor auch dazu verwenden kann, eine Rückrechnung durchzuführen? Das heisst, man gibt ein komprimiertes Segment vor und möchte berechnen, wie groß das unkomprimierte Segment war. Auch dies kann mit der Prozedur GET_COMPRESSION_RATIO bewerkstelligt werden. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/flash/index.html Zurückgehen in der Zeit ist schon lange ein Feature, das die Oracle Datenbank unterstützt. Flashback in Oracle bedeutet Daten eines früheren Zeitpunkts zur Verfügung zu stellen. Schon in Oracle 9i wurde begonnen diese Anforderung durch das Flashback Query Konzept in der Datenbank zu implementieren. Folgender Tipp gibt einen Gesamtüberblick über den aktuellen Stand der Flashback Technologien. Dabei wird die Nutzung und das notwendige Setup der einzelnen Technologien an einem durchgängigen Beispiel illustriert. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/av/index.html Oracle Audit Vault, das Datawarehouse für Datenbank Audit Daten, ist inzwischen seit fast 5 Jahren verfügbar. Es handelt sich dabei nicht um ein Stück Basistechnologie wie eine Datenbank oder ein Betriebssystem, sondern um eine fertige Lösung für den Bereich Security & Compliance. Oracle Audit Vault ermöglicht es Unternehmen, Audit Daten aus Oracle, Microsoft SQL Server, Sybase ASE und IBM DB2 (LUW) Datenbanken zentral und geschützt vor Manipulationen zu speichern und datenbankübergreifend auszuwerten. Im Dezember 2011 wurde das neuste Release von Oracle Audit Vault mit der Versionsnummer 10.3 freigegeben. Das neue Release bietet den Anlass für eine Anleitung zur einfachsten Installation und funktionalen Teststellung von Oracle Audit Vault. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/SPM_2/index.html Beim manuellen Tuning von SQL Statements stellt sich häufig die Frage, wie man die Ausführung von Statements beeinflussen kann. Indirekt ist dies möglich durch Änderung an Optimizereinstellungen in der Umgebung, Änderungen von Statistiken, Änderungen an den Zugriffsstrukturen oder natürlich auch direkt mit Hints. Möchte oder kann man keine Hints in den Applikationen programmieren und trotzdem den Optimizer auf direkte Art und Weise beeinflussen, kann man den Einsatz von SQL Plan Management in Erwägung ziehen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_upgrade1/index.html Ein Upgrade von Grid Control nach Cloud Control ist verschiedenartig möglich. In diesem Tipp werden diese Methoden kurz beschrieben und die 1-System Methode ausführlich dargestellt. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_selfupdate/index.html Lesen Sie, wie Sie Ihre Cloud Control Umgebung jederzeit aktuell halten können. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_agentdeploy/index.html Lesen Sie, wie Sie für Ihre Cloud Control Umgebung neue Agenten auf den Zielsystemen installieren. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_promotetarget/index.html Lesen Sie, wie Sie in Ihrer Cloud Control Umgebung neue Targets hinzufügen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_namedcred/index.html Erhöhen Sie die Sicherheit in Ihrer Cloud Control Umgebung durch die Verwendung der neuartigen Named Credentials. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_anmeldeprivs/index.html Erhöhen Sie die Sicherheit in Ihrer Cloud Control Umgebung durch die Ausnutzung der neuen, feiner granulierten Privilegien. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_adm/index.html Oracle Enterprise Manager Cloud Control 12c besteht aus vielen neuen Funktionen, die in den unterschiedlichsten Bereichen - wie auch im Testumfeld - zu finden sind. Dabei handelt es sich beispielsweise um die Möglichkeit, eine Testumgebungen mit einer Teilmenge der Daten (auch Data Subsetting) zu erzeugen oder um die Möglichkeit sensitive Spalten zu definieren und diese beim Masking zu nutzen. Voraussetzung für diese Technologien ist das Vorhandensein von Application Data Models (kurz ADM). Die generelle Funktionsweise ist schnell erläutert: Beim sogenannten "Discovery" werden Schemas der Applikationen geprüft um referentielle Beziehungen zwischen Tabellen und Spalten zu beschreiben. Dabei werden Datenbeziehungen und Charakteristiken für die sensitiven Spalten und das Data Subsetting erschlossen. Das ADM wird zur weiteren Verwendung im zentralen Repository gespeichert. Zudem existiert eine spezielle Unterstützung für Fusion Applications und E-Business Suite. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_sensitive/index.html Oracle Enterprise Manager Cloud Control 12c besteht aus vielen neuen Funktionen, die in den unterschiedlichsten Bereichen - wie auch im Testumfeld - zu finden sind. Dabei handelt es sich beispielsweise um die Möglichkeit, eine Testumgebung mit einer Teilmenge der Daten (auch Data Subsetting) zu erzeugen oder um die Möglichkeit sensitive Spalten zu definieren und diese bei der Daten Maskierung zu nutzen. In diesem Tipp wollen wir die Definition und die Nutzung von sensiblen Spalten (sensitive columns) demonstrieren. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_packmgmt/index.html In Oracle Enterprise Manager Cloud Control 12c wurde der Bereich Kontrolle über die Nutzung von Management Packs gegenüber Oracle Enterprise Manager Grid Control 11g stark modifiziert und mit mehreren Verbesserungen versehen. Dieser Tipp beschreibt, wie Sie in Cloud Control sicherstellen können, nur die Management Packs zu nutzen, die auch wirklich lizenziert sind. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/resumable/index.html Operationen, die unvorhergesehen abbrechen, da sie nicht mehr über ausreichenden Speicherplatz im TEMP, UNDO oder DATA Tablespace verfügen, führen zu erhöhtem Arbeitsaufwand. Sie müssen neu angestartet werden und beanspruchen damit insgesamt mehr Zeit als vielleicht eingeplant war. Besonders lästig ist dies beispielsweise bei langlaufenden Ladevorgängen oder bei langwierigen INDEX CREATE Operationen. Das Feature RESUMABLE SPACE ALLOCATION, das seit jeher in der Datenbank ohne zusätzliche Installation zur Verfügung steht, schafft Abhilfe. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/dbappliance_faq/index.html Die Technologie hochverfügbare Datenbanken einfach zu installieren und managen, scheint bei unseren Kunden auf großes Interesse zu stoßen. Sicher gibt es schon viele Informationen auf OTN zu finden und sogar ein deutsches DataSheet. Dennoch scheint es immer noch viele Fragen rund um die Oracle Database Appliance zu geben. Diese habe wir diesmal in folgendem Tipp zusammengefasst. Sollte ein wichtiger Punkt fehlen, nehmen wir diesen gerne mit auf. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/auditmngmt/index.html Das Package DBMS_AUDIT_MGMT stellt Routinen bereit, Audit Daten, egal wo sie gespeichert sind, zu verschieben und zu löschen. Allerdings wurde das Package zunächst nur im Zusammenhang mit dem Einsatz von Audit Vault für Datenbanken ab Version 10.2 unterstützt. Zum Teil war dazu die Installation zusätzlicher Patches nötig. Ab Version 11.2 der Datenbank ist das Package dann aber ohne zusätzliche Patches und für den allgemeinen Einsatz freigegeben worden. Mehr dazu in unserem Tipp. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/opatch/index.html Fast jeder, der schon einmal einen Datenbank Patch installiert hat, kennt eigentlich das Oracle Patch Utility - kurz OPatch. Da alleine schon der Vorgang einen Patch zu installieren, nicht zu den angenehmsten Erfahrungen gehört, verbinden viele mit OPatch nicht unbedingt Positives. Dass vor jedem Patch immer erst die aktuelle Version des OPAtch Utilities geladen werden muss, trägt auch nicht gerade zu einer verbesserten Beziehung zu OPatch bei. Eigentlich zu Unrecht, denn neben den Vorteilen einer Tool gestützten Patch Installation hat OPatch auch noch einige andere nette Funktionalitäten, über die nur selten gesprochen wird... Mehr zu Patching und anderes in unserem Tipp. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/cc12_overview/index.html Seit 3. Oktober steht die Software für Enterprise Manager 12.1 für die Plattformen Linux x86 (32-bit) und Linux x86-64 (64-bit) zum Download zur Verfügung. Die neue Version 12c von Enterprise Manager ist eine umfassende Weiterentwicklung von Grid Control 11g. Die zentrale Verwaltungskonsole trägt jetzt den Namen Cloud Control 12c und die graphische Oberfläche wurde komplett überarbeitet. Aber auch funktional gibt es viele Neuerungen. Um einen Vorgeschmack auf einige der neuen Features zu geben, haben wir im aktuellen Tipp eine Auswahl von 12 interessanten Neuerungen zusammengestellt. Mehr dazu in unserem Tipp ... http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/sqldeveloper/index.html Oracle SQL Developer ist ein Java basierendes Entwickler-Werkzeug, das seit März 2006 zum Download von OTN zur Verfügung steht. Jede neue Datenbanksoftware enthält automatisch eine Version von SQL Developer. Mittlerweile - speziell auch mit dem neuesten Release 3 - sind einige Features eingeführt worden, die die Nutzung auch für DBAs interessant machen können. Mehr dazu in unserem Tipp ... http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/ovm30/index.html Was lange währt wird endlich gut: Auf dieses Sprichwort hat sich wohl auch die neue Version 3.0. von Oracle Virtual Machine (OracleVM oder OVM) gestützt und ist nach einigen Release Verschiebungen nun zum Download verfügbar. Aber ganz nach dem Sprichwort sind durch die längere Entwicklungszeit auch viele Verbesserungen im neuen Release verfügbar. Mehr dazu in unserem Tipp ... http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/indexcompress/index.html Welche Indizes mit welchen Eigenschaften stehen den Applikationen in der Datenbank zur Verfügung? Sind die Indizes für den Optimizer überhaupt nutzbar? Wieviel Speicherplatz wird von den Indizes alloziert? Werden die Indizes überhaupt verwendet? Müssen Indizes reorganisiert werden? Diese und weitere Fragen stellen sich automatisch, falls man sich mit dem Tuning von Datenbankapplikationen oder der Speicherplatzoptimierung befasst. Der folgende Tipp soll dabei helfen, diese Fragen zu beantworten. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/mav_introduction/index.html Die Steigerung der Abfrageperformance einzelner SQL Statements ist für den DBA eine täglich zu meisternde Herausforderung. Verschiedene Funktionen innerhalb der Oracle Datenbank können den DBA beim Tuning der Abfrageperformance unterstützen. Materialized Views (MAV), die bereits seit der Version Oracle 8i zur Verfügung stehen, sind ein gern genutztes Tuningmittel in Datawarehouse-Umgebungen. In Materialized Views werden nahezu beliebig komplexe Aggregate auf großen Tabellen vorausberechnet und materialisert abgelegt. Ein Zugriff auf diese materialisierte View ist erheblich schneller als ein Zugriff auf die Basistabellen durch die Verwendung einer herkömmlichen View. Die Performancesteigerung rührt daher, dass für die Ermittlung der vorausberechneten Aggregate der Materialized View wesentlich weniger I/O Operationen notwendig sind. Dieser Artikel stellt die Grundlagen des Arbeitens mit Materialized Views dar und gibt anhand von Beispielen Hinweise zu deren Erstellung und zum Feature Query Rewrite. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/DB_filecopy/index.html Seit Oracle Database 10g Release 1 gibt es das sehr hilfreiche PL/SQL-Package DBMS_FILE_TRANSFER. Mit diesem Package kann die Datenbank Dateien innerhalb des Datenbankservers oder auch von Datenbankserver zu Datenbankserver kopieren. Damit können Sie als Datenbankbenutzer, ohne sich auf Betriebssystem-Ebene anzumelden, physikalische Kopien von Dateien erstellen. Das funktioniert sowohl für Dateisysteme als auch für ASM und kann sehr sinnvoll sein, zum Beispiel im Rahmen von automatisierten Batch-Vorgängen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/dm/index.html International agierende Unternehmen arbeiten sehr oft mit Multibyte Zeichensätzen (Unicode), um unterschiedlichste Zeichensymbole in der Datenbank abbilden zu können. Mit Data Masking bietet Oracle die Möglichkeit sensible Daten z.B. für Test- und Entwicklungsumgebungen zu anonymisieren. Die Konfiguration von Data Masking geschieht über die graphische Oberfläche von Enterprise Manager Grid Control. Um eine Maskierung oder Anonymisierung von Daten in Multibyte Zeichensätzen erfolgreich und korrekt durchzuführen muss auch die Umgebung von Grid Control entsprechend aufgesetzt sein. Im Folgenden wird an Hand eines Beispiels beschrieben, wie die Grid Control sowie die Agent-Umgebungen für die Maskierung von Daten mit Data Masking konfiguriert werden müssen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/ovm_pcipassthrough/index.html Ziel von Virtualisierungslösungen ist es, möglichst viele Systeme in die virtuelle Welt zu überführen. Dies bringt neben der Kosteneinsparung durch die Hardwarekonsolidierung auch mehr Flexibilität und vereinfacht die Sicherung ganzer Systeme. Allerdings gibt es unter den laufenden Systemen bei Kunden oft einige "Ausreißer", bei denen die herkömmlichen Virtualisierungsmöglichkeiten, wie zum Beispiel für Netzwerk, Storage, Memory und CPU nicht ausreichen. Hierzu könnte zum Beispiel ein System gehören, welches die Funktion eines FAX Servers übernimmt oder ein System, welches exklusiven Zugriff auf eine Netzwerkkarte, ein Bandlaufwerk, einen USB Port oder eine andere im Rechner installierte Hardware benötigt. Die Möglichkeit des exklusiven Zugriffs, bzw. des Zugriffs auf Ressourcen, für die im Hypervisor keine Virtualisierungslösung vorgesehen ist, nennt sich bei XEN (der Basis von Oracle VM) PCI Passthrough: Das Gast System bekommt direkten Zugriff auf die Hardware Ressource und "greift" direkt auf die Physik durch. Wie man dies unter Oracle VM konfigurieren kann, zeigt dieser Tipp. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/AWR_transport/index.html Das Automatic Workload Repository (AWR) wurde in Oracle Datenbank 10g eingeführt. Dabei sammelt die Datenbank permanent Performancedaten mittels äußerst schnellen und effizienten Zugriffen auf Hauptspeicherinhalte, die dann in Datenbanktabellen im Tablespace SYSAUX gespeichert werden. Die Analyse dieser Performance Daten findet dann je nach Bedarf mit normalen Datenbankzugriffen auf diese Tabellen des AWR statt. Die Speicherdauer der Daten im AWR ist standardmäßig auf 8 Tage gesetzt und kann selbstverständlich vergrößert werden. Eine langfristige dezentrale Speicherung für spätere umfassende Analysen ist jedoch manchmal nicht möglich. So ergibt sich der Wunsch, die AWR-Daten in ein zentrales für eine langfristige Speicherung zu übertragen. Dazu stellt die Oracle Datenbank entsprechende Skripte zur Verfügung. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/emcli_4_kein_remote/index.html "EMCLI soll nicht mehr remote arbeiten dürfen, wie kann man das einstellen?" Diese Frage wurde mir kürzlich von einem Kunden gestellt und aus diesem aktuellen Anlass gibt es heute einen zweiten Tipp. Aus Sicherheitsgründen möchte dieser Kunde, dass die Utility EMCLI (Enterprise Manager Command Line Interface) nur auf dem OMS Server selbst funktioniert, jedoch nicht von weiteren Clients. Durch eine einfache Konfiguration können Sie dieses in Grid Control 11g einstellen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/testcase/index.html Der Erfolg beim Tunen von SQL Statements oder gar die Behebung von aufgetretenen Fehlern bei der SQL-Ausführung ist häufig davon abhängig, einen reproduzierbaren Testfall zur Verfügung zu stellen. Dies kann eine sehr umständliche und zeitaufwändige Aufgabe. Der sogenannte Test Case Builder bietet eine Möglichkeit, diesen Vorgang stark zu vereinfachen. Implementiert ist der Test Case Builder über das Package DBMS_SQLDIAG. Teilfunktionen sind auch graphisch über die Support Workbench des Enterprise Managers zu nutzen. Die Verwendung von DBMS_SQLDIAG wird in diesem Tipp detailliert anhand eines Beispiels beschrieben. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/orion/index.html Die Performance von Datenbanksystemen wird in der Praxis häufig durch die Fähigkeiten des verwendeten Storage Systems bestimmt. Um die Charakteristika des Storage Systems vermessen und beurteilen zu können, gibt es verschiedene geeignete Ansätze. Der Community-Tipp I/O-Durchsatzmessung mittels calibration unter Oracle 11g beschreibt die I/O Kalibrierung mit der API des PL/SQL Package dbms_resource_manager, für die eine installierte Oracle Datenbank erforderlich ist. Das ebenfalls schon länger bekannte Utility ORION (ORacle IO Numbers), auf dem auch das PL/SQL Package dbms_resource_manager beruht, war bislang nur als Betaversion verfügbar und als solche nicht ohne Einschränkungen unterstützt. Dieses hat sich mit dem Patchset 11.2.0.2, das seit September 2010 zur Verfügung steht, geändert. Das Utility ORION wird nun offiziell unterstützt und automatisch mit der Oracle Datenbank Software im Binary-Verzeichnis installiert. Die Verwendung von ORION wird in diesem Tipp detailliert anhand eines Beispiels beschrieben. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/grid_startup/index.html Die Dokumentation zur Grid Infrastruktur beschreibt zwar generell die involvierten Prozesse, bleibt aber einige interessante Informationen schuldig. So wird nirgends auf die genaue Start-Reihenfolge eingegangen. Genauso wenig wie eine Antwort auf die Frage gegeben wird, wie Oracle das "Henne - Ei" Problem gelöst hat: Ohne ASM keinen Zugriff auf OCR und Voting Disks und ohne OCR und Voting Disks keine Möglichkeit, ASM zu starten. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/proxy/index.html Nachvollziehbarkeit ist eines der Hauptthemen im Bereich der Datenbanksicherheit. Deshalb steht der DBA bei Anwendungen, die über einen Application Server auf die Datenbank zugreifen, immer wieder vor der Herausforderung, wie man die Benutzer der zugehörigen Anwendung eindeutig identifiziert. Diese Herausforderung wird durch die Verwendung des Connection Pooling noch größer. Der Community Beitrag Anwendungsbenutzer eindeutig identifizieren hat sich bereits einmal mit dem Thema beschäftigt und sich dabei auf das Arbeiten mit dem CLIENT_IDENTIFIER konzentriert. Die beschriebene Vorgehensweise birgt allerdings die Gefahr, dass durch Umgehen der Anwendung die darin implementierten Berechtigungskonzepte unterlaufen werden. Das läßt sich nur verhindern, wenn die Rechte der Anwendungsbenutzer durch die Datenbank selbst verwaltet werden. Damit stellt sich selbstverständlich die umgekehrte Frage, wie unterschiedliche Berechtigungen der Endbenutzer wirksam umgesetzt werden können, wenn alle mit der gleichen Anwendung arbeiten. Der aktuelle Beitrag zeigt, wie man diese Frage durch die Verwendung sogenannter Proxy Benutzer recht einfach beantworten kann. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/apex/index.html Die Leser unter Ihnen, die Application Express (kurz APEX) kennen, werden vielleicht fragen, was APEX mit der Tätigkeit als DBA zu tun hat. APEX ist doch ein Werkzeug für Entwickler! Dieser Einwand ist natürlich gerechtfertigt, allerdings sollen in diesem Tipp keine Entwicklerfeatures dargestellt werden. Hierfür steht schon seit geraumer Zeit die APEX Community zur Verfügung. Dieser Tipp soll APEX aus der Sicht der DBAs beschreiben, damit DBAs, die APEX-Umgebungen zur Verfügung stellen wollen, einen Einblick in die Technologie von APEX erhalten und von der einfachen Handhabbarket überzeugt werden. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/snapshot_standby/index.html Standby Datenbanken werden normalerweise im Zusammenhang mit Hochverfügbarkeit und Disaster Recovery gesehen: Im Falle eines gravierenden Fehlers auf der Seite der Produktionsdatenbank soll die Standby-Datenbank die Arbeit möglichst schnell übernehmen. Das Konzept von Standby-Datenbanken kann aber viel mehr und Oracle hat sich mit diesem Thema in zwei ausgesprochen interessanten Funktionsbereichen beschäftigt. In diesem Tipp wird einer dieser Funktionsbereiche beleuchtet: Die Snapshot Standby-Datenbank. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/odd-das-beste-aus-11g/index.html Im Februar 2011 erfuhren 300 Teilnehmer der Veranstaltungsreihe Oracle's Eleven - das Beste aus der 11g-Datenbank mehr über die Möglichkeiten der Oracle-Datenbank. Im Fokus stand dabei die in Standard- und Enterprise Edition bereits eingebaute Funktionalität. Für die Mitglieder der deutschsprachigen Communities stellen wir diese Informationen exklusiv nochmals zusammen. Wenn Sie nicht die Gelegenheit zur Teilnahme hatten, finden Sie hier einen groben Überblick über die behandelten Themen und weiterführende Links. Während dieser Artikel vorrangig die DBA-Themen der Veranstaltungsreihe behandelt, finden Sie Inhalte, die sich an Entwickler richten, in unserer deutschen APEX-Community. Die Folien zur Veranstaltungsreihe stehen unter http://apex.oracle.com/folien zur Verfügung - geben Sie Editionen als Schlüsselwort ein. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/privs/index.html Früher besaßen Server nur eine Netzwerkkarte und waren somit nur über ein Subnetz erreichbar. Mit steigenden Anforderungen stieg die Anzahl der Netzwerkkarten und somit auch die Subnetze, über welche die Datenbanken erreichbar sind. Mittlerweile gehört die Erreichbarkeit von Datenbankservern über mehrere unterschiedliche Netze zur Standardausstattung in vielen Rechenzentren. Zusätzlich versucht man hierüber auch den Zugriff auf die Datenbank zu steuern, indem man z.B. Netze für das Intranet und das Extranet bereitstellt oder bestimmte Ladeoperationen, die Data Guard Kommunikation oder ähnliches über eigene Netze abwickelt. Ein Beispiel aus der Praxis ware z.B. der Zugriff auf ein Exadata System, bei dem bestimmte Server über Infiniband auf die Datenbankknoten zugreifen, anstatt über das Standard "Ethernet" Public Netz. Ist dies bei Single Instanz Datenbanken recht einfach zu bewerkstelligen, indem pro Subnetz ein eigener Listener definiert wird, der die Clients vom jeweils entsprechenden Netz entgegennimmt, so gibt es im RAC bzw. Grid Infrastruktur Umfeld doch noch einiges mehr zu beachten. Der folgender Tipp gibt eine Anleitung wie solche zusätzlichen Netzwerke in der 11gR2 Grid Infrastruktur konfiguriert werden. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/dbms_xplan/index.html Ändern sich Applikationen oder die Umgebung durch Einspielen von Patches, Änderungen an Initialisierungsparametern, Änderungen an den Storageparametern oder Zugriffsstrukturen besteht häufig die Notwendigkeit, Ausführungspläne zu generieren und zu analysieren. Die Oracle Datenbank liefert schon seit langer Zeit unterschiedliche Methoden und Instrumente, um die Ausführungen von SQL Statements zu monitoren und die zugehörigen Ausführungspläne zu generieren. Möchte man ausführliche Informationen über die Ausführungspläne erhalten, obwohl das Tuning Pack (noch) nicht im Einsatz ist, oder möchte man unabhängig von graphischen Implementierungen der Oracle Werkzeuge sein, sollte man das Package DBMS_XPLAN verwenden. Der Tipp zeigt häufig verwendete Funktionen von DBMS_XPLAN und darüberhinaus Funktionalitäten, die weniger bekannt aber sehr hilfreich sein können. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/gc11_1_multi_oms_install/index.html Der Betrieb einer hochverfügbaren Grid Control Umgebung wird immer wichtiger. Aus diesem Grund zeigt dieser Tipp, wie eine solches hochverfügbares Grid Control aufgebaut wird. Eine theoretische Betrachtung findet sich in der Dokumentation "Oracle Enterprise Manager Administration 11g Release 1 (11.1.0.1)" im Part III "Enterprise Manager High Availability". Dort werden verschiedene Varianten diskutiert. Dieser Tipp zeigt, wie eine Grid Control Umgebung mit mehreren aktiven OMS aufgebaut wird. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/segments_on_demand/index.html Mit dem Anlegen von Tabellen wurden bis zur Version Oracle 11g abhängig vom Objektattribut MINEXTENTS automatisch ein oder mehrere initiale Extents erzeugt. Durch die Installation von Anwendungssystemen wie zum Beispiel Standardsoftware (SAP, Oracle EBS, ...) werden sehr viele Objekte in der Datenbank angelegt. Für diese Objekte wird allein durch das Anlegen schon sehr viel Plattenplatz verbraucht, ohne dass bereits Daten im Schema geladen sind. Kunden, deren Systeme bei einem Dienstleister betrieben werden, sind von diesem Umstand in besonderer Weise betroffen. IT Dienstleister messen ihren Aufwand nämlich auch in der Menge des verbrauchten Plattenspeichers und stellen diesen dem Kunden in Rechnung. Aus diesem Grunde ist das Erzeugen vieler leerer Segmente für diese Kunden ein ärgerliches und vor allem teures Unterfangen! Mit der Datenbankversion Oracle 11gR2 wurde die Funktionalität der deferred segment creation eingeführt. Das bedeutet, dass Tabellen bei ihrer Erzeugung zwar im Data Dictionary registriert werden, Segmente aber erst dann angelegt werden, wenn die Tabelle mit Daten gefüllt wird. Leider war diese Funktionalität noch sehr restriktiv implementiert, so konnten zum Beispiel partitionierte Objekte noch nicht von der deferred segment creation profitieren. Mit dem aktuellen Patchset, der Version 11.2.0.2, wurden einige Verbesserungen implementiert, die in diesem Tipp anhand von Praxisbeispielen vorgestellt werden. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/11gr22/index.html Seit Mitte September steht das neue Patchset 11.2.0.2 zum Download für die Plattformen Linux x86 und Solaris zur Verfügung. Über die normale Funktionalität eines Patchsets hinaus werden dieses Mal neue Features mitgeliefert zum Beispiel im Installer, im Testing-Bereich, in der Segment Verwaltung und im Bereich der Quality of Service Verwaltung. Um einen Vorgeschmack auf einige der neuen Features zu geben, haben wir eine Auswahl von 11 interessanten Neuerungen zusammengestellt. Bei den Beschreibungen handelt es sich um eine kurze Zusammenfassung der einzelnen Neuerungen, die nicht nach Prioritäten geordnet ist. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/rollen/index.html Rollen steigern die Produktivität des DBAs und können gleichzeitig die Sicherheit von Datenbanksystemen erhöhen. Die Produktivitätssteigerung wird dadurch erreicht, dass nach der Zuweisung von Privilegien oder Rollen an eine Rolle zukünftig nur noch diese Rolle vergeben werden muß, wenn ein neuer Benutzer mit identischen Berechtigungen einzurichten ist. Man könnte zwar argumentieren, dass ein einfaches Skript mit einer Reihe von GRANT Befehlen ähnlich produktiv ist. Allerdings wird bei Änderungen im Berechtigungskonzept unmittelbar deutlich, dass es viel aufwändiger ist, zunächst alle Benutzer eindeutig auszumachen, deren Berechtigungen betroffen sind, und diese Benutzer dann zu modifizieren. Arbeitet man dagegen mit Rollen sind die Berechtigungen nur noch an einer Stelle zu pflegen - nämlich im Rahmen der Rollen. Die Sicherheit wird erhöht, weil über Rollen das Prinzip des least privilege leichter umzusetzen ist: Es werden nur die Berechtigungen an eine Rolle vergeben, die die Benutzer der Rolle unbedingt benötigen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/grid_dbconsole/index.html Eine Real Application Cluster Datenbank mit der Oracle eigenen Clusterware aufzubauen, ist nur ein kleiner, wenn auch sehr bedeutender Bestandteil der 11gR2 Grid Infrastruktur. Da es sich aber bei der in der Grid Infrastruktur enthaltenen Clusterware um eine vollwertige Clusterware handelt, können auch andere Applikationen und Prozesse damit überwacht werden. Leider bietet Oracle im Gegensatz zu seiner Solaris Clusterware nur wenig vorgefertigte Agenten und Skripte hierzu an, da die Clusterware vornehmlich für den RAC zur Verfügung steht. Die bestehenden Agenten und Whitepaper finden sich auf der Oracle Clusterware Seite. Hierzu gehört SAP, RAC One Node, Golden Gate, Oracle VM Manager und bei älteren Clusterware Releases auch ein Whitepaper zum Cold Failover einer Oracle Datenbank. Mit 11gR2 Clusterware wurden aber eben diese Funktionalität erheblich erweitert: So gibt es nicht nur die graphische Verwaltung im Database Control und im Enterprise Manager Grid Control der Clusterware Ressourcen (Applikation und Prozesse, die überwacht werden), sondern auch verbesserte Skripte und mehr Möglichkeiten Abhängigkeiten zwischen den einzelnen Ressourcen zu definieren. Wie die Einsatzbeispiele hierzu aussehen können, ist in diesem Tipp anhand der Einbindung des Database Controls bzw. des Oracle Enterprise Management Agents in die Überwachung der Oracle Clusterware beschrieben. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/parallel_dml/index.html Effizientes und schnelles Einfügen oder Verändern von Daten ist mittlerweile eine unverzichtbares Ziel von Datenbankanwendungen. Die entsprechende Performance kann beispielsweise durch zusätzliche Parallelisierung, Reduzierung von Table Scans oder durch Umgehung des Buffer Caches mit Direct Writes gewonnen werden. Im folgenden Beitrag werden einige interessante Aspekte zum Thema DML-Operationen erläutert, neue Features in 11g Release 2 aufgezeigt und speziell das Thema Umgang mit Parallel DML erläutert. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/advanced_partitioning/index.html In großen Datenbanken wird Partitionierung eingesetzt, um die Datenmengen, die eine einzelne Abfrage bewegen muss, zu reduzieren. Die aktuelle Datenbankversion Oracle 11g bietet umfangreiche Erweiterungen, die dem DBA die Arbeit mit partitionierten Objekten stark vereinfacht. Einige grundlegende Funktionen wurden bereits in dem Community-Artikel Partitionspflege mit Oracle 11g leicht gemacht vorgestellt. Um die Beschreibung der Möglichkeiten abzurunden, die durch den Einsatz von Partitionierung gegeben sind, soll dieser Artikel die in der DBA Community bislang nicht näher erläuterten Partitionierungsmethoden der Zusammengesetzten Partitionierung und System Partitionierung beschreiben. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/GC11_1_wartung/index.html Oracle Enterprise Manager Grid Control ist die zentrale Verwaltungslösung für alle Oracle Produkte. Ein solches System bedarf aber auch seinerseits ein wenig Wartung und Pflege. Dieser Tipp zeigt, wie Sie Grid Control verwalten und pflegen können. Die neue Version 11g von Enterprise Manager basiert auf dem Weblogic Server als Applikationsserver und damit hat sich auch einiges im Vergleich zu der Version 10g von Grid Control geändert. Im Bereich Starten und Stoppen von Grid Control gibt es dabei Vereinfachungen, und auch die Pflege von Log- und Tracedateien sieht anders aus. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/pump/index.html Mehr als 20 Jahre lang wurden die client-basierten Werkzeuge exp und imp zum Exportieren und Importieren von Daten eingesetzt. Seit Oracle Database 10g wird neue Funkionalität, wie zum Beispiel das Exportieren und Importieren von Daten, die mit dem Feature Transparent Data Encryption verschlüsselt sind, in diese Werkzeuge nicht mehr integriert. exp soll sogar über kurz oder lang völlig aus dem Lieferumfang der Datenbanksoftware fallen. imp wird es dagegen noch länger geben, denn Daten, die aus älteren Datenbankversionen mit exp exportiert wurden, sollen auch in neuere Versionen der Oracle Datenbank geladen werden können. Ausschlaggebend für die Entscheidung, exp / imp nicht mehr weiterzuentwickeln, waren Performanceprobleme. Die Werkzeuge waren in einer Zeit entwickelt worden, in der eine Datenbank von einigen 100 MB als 'groß' angesehen wurde. Sie konnten allmählich mit den ständig wachsenden Datenmengen nicht mehr angemessen umgehen: Die Zeitfenster, die ein Export oder Import benötigte, wurden zunehmend unvereinbar mit den ständig schrumpfenden Wartungsfenstern einer Datenbankwelt, die sich in Richtung 24x7 Verfügbarkeit bewegte. Der Nachfolger von exp / imp ist Oracle Data Pump. Durch verschiedene Verfahren - z.B Kopieren von Datendateien beim Transportieren von Tablespaces, Direct Path Exports und Imports, Verwendung von Externen Tabellen in einem Data Pump spezifischen Format und der möglichen Parallelisierung aller Vorgänge - erreicht Data Pump eine Steigerung der Performance um ein Vielfaches gegenüber exp / imp: Läufe, die mit exp / imp Stunden beanspruchen, können so in Minuten abgeschlossen werden. Allerdings sei auch erwähnt, dass die Performancevorteile erst ab einer bestimmten Datenmenge zum Tragen kommen. Bei geringen Datenmengen erhöht der zusätzliche administrative Aufwand, den Data Pump für die ins Auge gefassten großen Datenmengen betreibt, unter Umständen den Zeitbedarf für einen Export oder Import sogar geringfügig. Dieser Beitrag skizziert die Architektur von Data Pump und gibt eine Einführung in das Arbeiten mit dem 'neuen' Werkzeug. Selbstverständlich sollte jeder, der regelmäßig Daten mit Data Pump exportiert oder importiert und das Werkzeug optimal ausnutzen will, sich bei Gelegenheit mit den Kapiteln aus dem Utility Guide vertraut machen, die Oracle Data Pump ausführlich beschreiben. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/asm_dg_change/index.html Das Oracle Automatic Storage Management (ASM) ist seit Oracle 10g der bevorzugte Storage Manager für Oracle Datenbanken, da er das Management des Storage für Datenbank Files erheblich vereinfacht. Aber seit Oracle 11g Release 2 ist ASM nicht nur für Datenbanken zu verwenden: Im neuen Release ist ASM ein vollwertiger clusterfähiger Volume Manager. Damit kommen nun alle Files in den Genuss der ASM Vorteile: Hierzu gehören neben dem automatische Striping der Daten über alle verwendeten Platten auch Spiegelungstechnologien zur Datensicherheit. Allerdings müssen einige Parameter, wie die Spiegelung, beim initialen Einrichten der Diskgruppen festgelegt werden. Dies ist insbesondere ärgerlich, da bei der Installation der 11g Release 2 Grid Infrastruktur nur wenige Vorgaben für die Default Diskgruppe gemacht werden können. Und dies ist nachträglich auch nicht mehr leicht zu ändern: Denn dann liegen bereits die Konfigurationsfiles der Clusterware in ASM. Dieser Tipp beschreibt das Verschieben von OCR, Voting Disk und dem ASM SPFile in eine neue Diskgruppe. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/realmonitor/index.html Die Datenbank selbst stellt ein eigenes Framework zur Verfügung, um ohne Verwendung von externen Werkzeugen und ohne zusätzliche Installation ein genaues Monitoring zu erlauben. Das Framework umfasst seit jeher spezielle Data Dictionary Views, V$-Tabellen, PL/SQL-Packages für verschiedene Advisory-Aufgaben und ein spezielles Workload Repository. In jedem neuen Datenbankrelease wächst der Funktionsumfang dieses Frameworks - so auch in Oracle Database 11g mit Real-time Monitoring (auch SQL Monitoring ) und den Active Reports. Der Tipp zeigt wie Sie diese Werkzeuge einfach anwenden können. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/emcli_3/index.html Oracle Enterprise Grid Control bietet neben der grafischen Oberfläche auch ein Command Line Interface (emcli) an. In zwei früheren Tipps dieser kleinen Reihe wurden die allgemeine Benutzung (Aufruf und Anmeldung) sowie verschiedene Anwendungen beschrieben. Der heutige Tipp zeigt Ihnen, wie sie das Auditing von Grid Control einschalten und das Data Masking Pack mittels emcli nutzen können. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/part_advisor/index.html Für die Steigerung der Performance von Abfragen ist es von entscheidender Bedeutung, die Menge der Daten, die in einer Abfrage bewegt werden müssen, zu reduzieren. Ein sehr gut geeignetes Mittel hierzu ist der Einsatz von Partitionierung. Mit dieser Funktionalität, die bereits seit Oracle 8i zur Verfügung steht und kontinuierlich erweitert wurde, ist es möglich, große Datenmengen aufzuteilen. Dadurch können Abfragen, die nur eine Teilmenge der Gesamtdatenmenge auswerten, performant ausgeführt werden. Die in Oracle 11g erweiterten Partitionierungsmethoden wurden bereits in einem Community-Artikel vorgestellt. Anwender, die noch nie mit der Technik der Partitionierung in Berührung gekommen sind, tun sich erfahrungsgemäß schwer, geeignete Partitionierungsstrategien festzulegen. In der aktuellen Datenbankversion Oracle 11g wurde der Partition Advisor als Zusatzfunktion des SQL Access Advisors eingeführt. Der SQL Access Advisor gibt dem Datenbankadministrator hilfreiche Empfehlungen, mit deren Hilfe ein bestehendes Datenmodell auf Partitionierung umgestellt werden kann. Dieser Artikel stellt diese spezielle Funktion des SQL Access Advisors an einem kleinen Beispiel vor. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/vpd/index.html Die existierenden Objektprivilegien, die Anwendern das Lesen, Einfügen, Ändern und Löschen von Daten erlauben, zielen immer auf alle Zeilen einer Tabelle. Soll der Zugriff auf Zeilenebene gesteuert werden, weicht man entweder auf die Steuerung des Zugriffs über Anwendungen aus oder verwendet Views. Beides ist uneffektiv: Die Steuerung über Anwendungen, weil sie in jeder Anwendung separat programmiert werden muss und Änderungen in jeder Anwendung nachgezogen werden müssen. Die Steuerung über Views, weil bei großen Benutzergruppen oder vielen Views das ganze Berechtigungssystem schnell unüberschaubar wird. Oracle bietet schon seit der Version Oracle8i eine Lösung für dieses Problem: Die Lösung ist unter den Namen Fine Grained Access Control (FGAC) oder auch Virtual Private Database (VPD) bekannt. Es handelt sich dabei um ein Feature der Enterprise Edition, dessen Nutzung in der Regel eine enge Zusammenarbeit von Datenbankadministratoren und Anwendungsentwicklern voraussetzt. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/gridinfrastruktur_sod/index.html Die 11gR2 Grid Infrastruktur ermöglicht eine saubere Trennung von Aufgaben des System- bzw. Storage-Administrators auf der einen Seite und der Datenbank Administratoren auf der anderen Seite. Dazu gehört im ersten Schritt das Anlegen unterschiedlicher Benutzer und Benutzergruppen, da dies die Grundlage jeder Funktionstrennung bei der Systemadministration ist. Zwar gibt das Installationshandbuch genügend Informationen, wie solch eine Trennung in einer 11gR2 Umgebung vorzunehmen ist und wie dazu die Benutzer und Gruppen angelegt werden sollten. Allerdings fiel mir in Gesprächen mit Kunden auf, dass es gerade in Bezug auf diese Funktionstrennung immer wieder zu Missverständnissen kommt. Zusätzlich ergibt sich mit der 11gR2 Grid Infrastruktur noch eine andere Problematik, wenn auch auch ältere Datenbanken Versionen betrieben und deren Prozesse von der 11gR2 Grid Infrastruktur überwacht werden sollen: Die vorhergehenden Releases kannten die saubere Trennung der Verantwortlichkeiten, wie sie 11gR2 einführt noch nicht. Diese Unklarheiten und die Integration älterer Datenbank Releases möchte ich mit dem folgenden Tipp beseitigen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/meta/index.html Wie kann man festellen, mit welchen Eigenschaften d.h. mit welchem DDL-Kommando, eine Tabelle erzeugt worden ist? Welche Indizes, Trigger usw. gehören zu einer gewissen Tabelle? Skripte, die Abfragen auf die entsprechenden Data Dictionary Views wie USER_TABLES, USER_INDEXES usw. ausführen, könnten eine mögliche Lösung darstellen. Diese Skripte sind unter Umständen sehr aufwändig und komplex und müssen gegebenenfalls pro Datenbankrelease angepasst werden. Schon seit Oracle Version 9i ist es möglich, diese Aufgabe durch einfache Aufrufe des PL/SQL Package DBMS_METADATA zu generieren. Das Package ist ohne zusätzliche Installation in jeder Datenbank-Edition vorhanden und nutzbar. Intern wird die Technologie zum Beispiel bei der Nutzung von Oracle Data Pump oder im Oracle SQL Developer verwendet. Das Package ist sehr mächtig und kann entweder in einfachen SQL Abfragen oder auch in Applikationen genutzt werden. Der Tipp zeigt einige Beispiele zu Verwendung und gibt darüberhinaus auch einen Einblick in das DBMS_METADATA_DIFF Package. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/gc11_1_install/index.html Die neue Version 11g von Enterprise Manager steht für die Plattformen Linux und Solaris (SPARC) zur Verfügung. Funktional beinhaltet diese neue Version neben vielen Details drei wesentliche Bereiche:

• Vollständige Unterstützung der aktuellen Datenbankversion (11g Release 2)
• Vollständige Unterstützung der aktuellen Applikation-Server-Version Weblogic Server 10.3.2
• Integration von My Oracle Support, sodass die Interaktion mit Oracle Support komplett in Grid Control durchgeführt werden kann

Es gibt aber auch eine generelle Neuerung: Die von Grid Control genutzte Middleware wurde ausgetauscht. Bislang lief der Oracle Management Server in einer OC4J Instanz in einem Oracle Application Server. Mit der neuen Version 11g wird dazu der Weblogic Server 10.3.2 verwendet. Auch die Installation von Grid Control hat sich geändert: In der Version 10g wurde mit dem Installer der Grid Control Software sowohl Grid Control selbst als auch die dazu verwendete Middleware und bei Bedarf sogar die Datenbank für das Repository installiert. In diesem Tipp bekommen Sie eine einfache Anleitung zur Installation und Migration von Oracle Enterprise Manager 11g. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/parallel_query/index.html Datenbanken enthalten heutzutage eine riesige Menge an Daten, unabhängig davon, ob es sich um OLTP Systeme, Datawarehouses oder Operational Data Stores handelt. Die performante Ausführung von SQL-Abfragen kann daher durchaus eine Herausforderung darstellen, denn die Antwortzeit hängt in einem solchen Fall wesentlich von der Menge der abgefragten Daten ab. Ein gutes Mittel, Abfragen auf großen Datenmengen performant abzuarbeiten, ist die Nutzung von Parallel Query, die es bereits seit der Oracle Version 7.3 in der Enterprise Edition gibt. Die Grundidee von Parallel Query ist es, mehrere Unterprozesse zu starten, die jeder für sich eine Teilmenge der Daten bearbeiten und das Zwischenresultat dann zur Ermittlung des Endergebnisses an den zentralen Benutzerprozess zurückmelden. Durch dieses Prinzip werden die zur Verfügung stehenden Rechnerressourcen besser ausgenutzt und eine zum Teil erhebliche Verbesserung der SQL Antwortzeiten bei Abfragen großer Tabellen erreicht. Das Beispiel wird dies belegen. Die parallele Ausführung von Abfragen war lange Zeit sehr restriktiv implementiert, so konnte parallel Query zuerst nur mit partitionierten Tabellen verwendet werden, wobei der Parallelitätsgrad (DoP = Degree of Parallelism) mit der Anzahl der Partitionen und den zur Verfügung stehenden Prozessoren korrespondieren musste. Diese Einschränkungen haben glücklicherweise für die aktuell im Einsatz befindlichen Releases keine Relevanz mehr, eine parallele Ausführung ist auch bei nicht partitionierten Objekten völlig unproblematisch. Bis zur Version Oracle 11g musste der DBA allerdings noch für alle in einer Abfrage verwendeten Tabellen und die dazugehörenden Indizes den DoP manuell ermitteln, einstellen und pflegen. Nur auf diese Weise war es überhaupt möglich, gleichbleibend gute Antwortzeiten zu erzielen. Man kann sich leicht vorstellen, dass es nicht immer ganz einfach war, den Parallelitätsgrad zu ermitteln, der für die bestmögliche Antwortzeit sorgte. Der optimale DoP hängt nämlich von vielen Faktoren ab, neben der reinen Datenmenge sind unter anderem auch die zur Verfügung stehenden CPU-Ressourcen (Prozessoren oder Kerne) oder die Art der Benutzerlast entscheidend. In der aktuellen Datenbankversion Oracle 11g hat es rund um das Thema Parallel Query Verbesserungen gegeben, die den DBA mit sehr mächtigen Automatismen unterstützen. Dieser Artikel führt kurz in das Thema Parallel Query ein, zeigt die Möglichkeiten in Oracle 11g Release 2 und gibt Hinweise darauf, wie die parallele Ausführung überwacht und gesteuert werden kann. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/eps/index.html Client-Server-Anwendungen und Batch Jobs, aber auch privilegierte Benutzer wie DBAs, die Werkzeuge wie z.B. SQL*Plus nutzen, loggen sich unter Angabe von Benutzername und Passwort auf Datenbanken ein. Die Steuerdateien der Batch Jobs bergen ein gewisses Sicherheitsrisiko, denn sie enthalten häufig die benötigten Benutzernamen und Passwörter. Und auf UNIX-Systemen kann außerdem jeder, der Zugriff auf das System hat, die im Skript enthaltenen bzw. eingegebenen Passwörter in der Prozessliste im Klartext sehen. Der folgende Beitrag zeigt, wie sowohl Batch Jobs als auch Benutzer sich durch das Verwenden sogenannter external password files sicher und ohne Eingabe von Benutzername und Passwort bei der Datenbank anmelden. External password files sind ein Feature der Enterprise Edition der Datenbank, sie sind also im normalen Lieferumfang der Enterprise Edition enthalten. Implementiert wird das Feature über Einträge in den Dateien sqlnet.ora und tnsnames.ora sowie über ein Wallet. Dieses Wallet ist das eigentliche external password file - eine kleine, nur wenige KB große Datei, die mit dem 3DES-Algorithmus verschlüsselt und durch ein Passwort gesichert ist. External password files funktionieren sowohl für Client-Server-Anwendungen als auch direkt auf dem Server. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/RMAN_II_Restore/index.html Nachdem im letzten Recovery Manager Tipp das Thema Backup ausführlich behandelt wurde, geht es in diesem Tipp darum, wie Sie mit Hilfe dieser Backups ein Recovery durchführen. Zwar sollte mit Oracle 11g der Recovery Advisor verwendet werden, um die optimale Wiederherstellungsstrategie zu finden, aber es gibt ein paar nützliche Funktionalitäten, wenn das Restore manuell durchgeführt wird. Hierzu gehört unter anderem das Restore an einen anderen Speicherort bzw. auf eine andere Diskgruppe in ASM. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/tts/index.html Transportable Tablespaces, ein Feature der Enterprise Edition, ist schon seit Oracle8i ein sehr gutes Mittel, um Daten schnell und effizient zwischen Datenbanken zu transportieren. Die Idee dabei ist, "nur" die Metadaten eines Tablespaces zu exportieren und eine Kopie der Datendateien zur Verfügung zu stellen. Nachdem die Datendateien auf dem Zielsystem zur Verfügung stehen, erfolgt als abschliessende Operation nur noch ein Import der zugehörigen Metadaten. Aus diesem Grund kann diese Technik wesentlich schneller Daten bewegen als ein traditioneller Datenbank-Export bzw.Import. Unterschiedliche Blockgrößen bzw. unterschiedliche Plattformen der Datenbanken (z.B. von Windows nach Solaris) stellen seit Oracle 9i bzw. 10g kein Hindernis mehr dar. Ausgehend von einem älteren Datenbankrelease (ab Oracle 8i) ist der Transport auch in ein neueres Release - beispielsweise in Oracle 9i, 10g oder 11g möglich. Der Einsatz ist vielfältig und wird von Kunden erfolgreich genutzt. Auch im Migrationsumfeld hat sich der Einsatz von Transportable Tablespaces bewährt. Liegt ein grosses Datenvolumen vor und ist die Transportzeit begrenzt, sind die Vorteile, die die Transportable Tablespace Technologie bietet, im Vergleich zu anderen Techniken nicht zu übertreffen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/virtual_columns/index.html Die Verwendung von Ausdrücken wird durch die Oracle Datenbank schon seit langem unterstützt. Ein Beispiel hierfür ist die Verwendung von Ausdrücken in Views oder function-based Indices. Üblicherweise werden Views dafür genutzt, Berechnungen transparent für den Anwender abzubilden. Das geschieht, indem das Ergebnis einer Berechnung aus Spalten der zugrundeliegenden Tabelle als neue Spalte in einer View bereitgestellt wird. Seit Oracle 8i besteht die Möglichkeit, Ausdrücke zu indizieren, welches über die Verwendung von function-based Indices geschieht. In Oracle 11g können nun Ausdrücke als virtuelle Spalten direkt in den Basistabellen gespeichert werden. Dieser Artikel zeigt auf, wie flexibel der Einsatz von virtuellen Spalten im Vergleich zu den geschilderten Alternativen ist. Hierbei geht es um die Grundlagen der Verwendung von virtuellen Spalten und die verschiedenen Aspekte, die beim Umgang mit virtuellen Spalten zu beachten sind. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/dv/index.html Privilegierte Benutzer, z.B. Datenbankadministratoren (DBAs), haben seit jeher lesenden und schreibenden Zugriff auf den gesamten Datenbestand der Datenbank. Sie können auch die Strukturen der Datenbank und der darin abgelegten Objekte nahezu nach Belieben manipulieren. Inzwischen gewinnen allerdings Datenschutz und Datensicherheit immer mehr an Bedeutung, und unterschiedlichste Gesetze und Verordnungen verpflichten Unternehmen dazu, die 'Machtfülle' privilegierter Benutzer einzuschränken. Der Einsatz von Oracle Database Vault (DV), einer kostenpflichtigen Option der Enterprise Edition der Datenbank, kann dabei eine große Hilfe sein: Zum einen unterstützt DV Funktionstrennung und Aufgabenverteilung (separation of duties) - eine zentrale Komponente jeder Sicherheitsarchitektur. So können z.B das Verwalten von Benutzern, das Einrichten und Ändern von Datenbankstrukturen usw. mit den Mitteln von DV auf unterschiedliche Personen verteilt werden. Zum andern kann DV genauso wirksam das Prinzip des least privilege durchsetzen. Privilegien können mittels DV so verteilt und eingeschränkt werden, dass DBAs ausschließlich über die Privilegien verfügen, die sie für die Erfüllung der ihnen speziell zugewiesenen Aufgaben benötigen. Diese DBAs erhalten aber nicht mehr automatisch weitere oder gar alle Systemprivilegien. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/rman_i_backup/index.html Seit Oracle den Recovery Manager (RMAN) mit der Datenbank ausliefert, ist das Online Backup und Recovery einer Oracle Datenbank kein Hexenwerk mehr. Es ist eigentlich so einfach, dass man fragen möchte, warum immer noch Datenbanken nur "offline" gesichert werden oder gar ganz ohne ein Backup betrieben werden. Einer der Gründe mag vielleicht sein, dass RMAN über ein anderes Interface und eine andere Syntax verfügt, als man dies von SQL*Plus her gewöhnt ist. So trifft man hier und da immer noch auf einigen Widerstand gegen den RMAN. Gerade aber mit 10g wurden viele Kleinigkeiten in der Bedienung des RMAN verbessert, die es erlauben ein Backup in kürzester Zeit zu bewerkstelligen. Aber nicht nur das, auch Housekeeping Operationen der Backups und archivierten Redologs sind fest mit dem RMAN verknüpft und erleichtern so die Aufgaben eines DBAs. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/compadv/index.html Speicherplatzeinsparungen und Performanceverbesserungen sind zwei wichtige Argumente für den Einsatz von Komprimierung in der Datenbank. Mit Oracle Database 11g sind zusätzlich neue Algorithmen und Funktionen hinzugefügt worden, die die Komprimierung für die Praxis noch interessanter machen können. Je nach Algorithmus kann dabei ein grosser Anteil des urspünglichen Platzes eingespart werden. Bevor die Performanceverbesserung beispielsweise mit dem Real Application Testing Werkzeug getestet wird, wird daher in der Regel im ersten Schritt die Einsparung an Speicherplatz überprüft. Wie kann man den Grad der Speicherplatzeinsparung feststellen? Naheliegend ist, neue Segmente mithilfe der neuen Speichereinstellung zu erstellen und dann den Quotient aus nicht komprimierten und komprimierten Objekten - die sogenannte Compression Ratio - zu berechnen. Eine Alternative ist die Nutzung des neuen Compression Advisors in 11g Release 2, der ohne zusätzliche Installation mit dem Package DBMS_COMPRESSION zur Verfügung steht. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/drcp/index.html Webbasierende Applikationen haben häufig die Eigenschaft Datenbankverbindungen und somit Connection-Ressourcen der Datenbank zu benötigen. Beim Öffnen einer Website beispielsweise wird eine Datenbankverbindung eingerichtet, nach dem Laden der Website ist die Verbindung zur Datenbank wieder getrennt. Bei wiederholten weiteren Zugriffen auf diese Website werden dann erneut Datenbankverbindungen benötigt. Unter Umständen werden auf diese Art und Weise eine grosse Anzahl von simultanen Verbindungen (auch Connections) für Webapplikationen in der Datenbank zur Verfügung gestellt. Was hat dies nun mit Ihrer Arbeit als Datenbankadministrator zu tun? Database Resident Connection Pooling (kurz DRCP), ein neues Feature in Oracle Database 11g, das standardmässig zur Verfügung steht, addressiert genau diese Problematik auf sehr einfache Art und Weise. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/segment_112/index.html Ressourcen effizient einsetzen durch optimale Ausnutzung des Speicherplatzes und Optimierung von Ausführungsplänen ist ein wichtiges Thema in 11g Release 2. Keine unnötigen Informationen sollen den Platz in der Datenbank verschwenden. Falls beispielsweise grosse Installationen viele Tabellen benötigen, die niemals befüllt werden, wäre es sinnvoll, keinen Speicherplatz zu allokieren. Ein anderes Thema ist Verwendung und Speicherung von UNUSABLE Indizes. Auch sie verwenden in jedem Fall Platz, was bei grossen nicht mehr genutzten Indexpartitionen eine unnötige Speicherplatzverschwendung bedeutet. Dabei kann es zusätzlich unter gewissen Umständen zu nicht optimalen Ausführungsplänen kommen. In 11g Release 2 ändert sich dieses Verhalten und folgende neue Features addressieren diese Anliegen:

• Speicherplatz bei Bedarf - auch bekannt unter deferred segment creation
• Segmentlose UNUSABLE Indizes - auch bekannt unter zero size unusable index

Was bedeutet dies nun für den Umstieg auf 11g Release 2? http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/client_identifier/index.html Die Architektur moderner Anwendungen sieht häufig sehr ähnlich aus: Ein Benutzer identifiziert sich auf der Middletier gegenüber der Anwendung. Die Anwendung selbst arbeitet dann entweder über einen Connection Pool mit der Datenbank oder es gibt, wie bei Oracle Application Express (Apex) oder den grossen Anwendungspaketen von Oracle (Siebel, Oracle E-Business Suite, Peoplesoft...) und SAP, auf der Datenbankseite nur einen einzigen Anwender. Dieser führt alle Abfragen oder Datenmanipulationen für den Endanwender aus. In beiden Fällen - Connection Pool oder einzelner Anwendungsbenutzer - ist auf der Datenbank nicht mehr ohne Weiteres festzustellen, welcher Endanwender tatsächlich für eine Abfrage oder Manipulation verantwortlich ist. Immer häufiger wird aber aus Gründen der Sicherheit und Nachvollziehbarkeit verlangt, dass nicht nur anwendungsseitig, sondern z.B. auch im Rahmen des Datenbankauditing nachweisbar sein muss, wer genau welche Daten abfragt oder ändert. Deshalb stellt sich die Frage, wie eine Anwendung mit den oben beschriebenen Eigenschaften Informationen über konkrete Benutzer an die Datenbank übergeben kann. Die Oracle Datenbank bietet für diese Anforderung eine sehr einfache Möglichkeit. Sie setzt lediglich voraus, dass die auf der Middletier laufende Anwendung eine Umgebungsvariable manipuliert, den CLIENT_IDENTIFIER. Wie der CLIENT_IDENTIFIER in den eigenen Anwendungen zu verwenden ist, wird in diesem Tipp dargestellt. Übrigens verwendet Peoplesoft Tools in der Version 8.50 den CLIENT_IDENTIFIER bereits, und auch in der Oracle E-Business Suite soll er schon bald standardmässig verfügbar sein. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/sql_on_olap_cubes_2/index.html In der letzten Ausgabe wurden Abfragen mit Standard SQL auf einen OLAP Cube ausführlich beschrieben. Die dort vorgestellte Abfragetechnik verwendet nur die relationalen Cube Views, die im Zuge der Generierung des OLAP Cubes im Analytic Workspace Manager (AWM) automatisch erzeugt werden. Die direkte Abfrage der relationalen Cube Views hat hierbei unmittelbar Auswirkungen auf die Formulierung des SQL-Statements. Es dürfen in dieser Art von Abfrage nämlich keine Aggregat- oder Gruppierungsfunktionen mehr verwendet werden. Das Ergebnis der Aggregationen ist direkt im Cube - oder besser der Cube View - als Spalte enthalten. Eine Abfragetechnik unter Verwendung der Cube Views würde sich also demnach für ein eigenes Reporting von Endbenutzern anbieten, da die zu erstellenden Statements wenig Komplexität besitzen und sehr einfach formuliert werden können. Besondere SQL Kenntnisse sind an dieser Stelle nicht notwendig. Die in diesem zweiten Teil vorgestellte Abfragetechnik verwendet sogenannte Cube-organized Materialized Views, auf die mit komplexen SQL-Statements und mit Verwendung von Query Rewrite zugegriffen wird. Diese Art von Statements enthalten Aggregat- sowie auch Gruppierungsfunktionen und werden häufig durch BI Abfragetools erzeugt. Ein Berichtsgenerator wird ebenfalls eher mit Aggregat- und Gruppierungsfunktionen auf die Tabellen des zugrundeliegenden STAR Schemas zugreifen und auf diese Weise die Vorteile des Query Rewrites nutzen. Die Erstellung der in Oracle 11g eingeführten Cube-organized Materialized Views im Analytic Workspace Manager (AWM), deren Konfigurationsmöglichkeiten und schließlich die Erstellung von Abfragen wird in diesem Tipp anhand von Beispielen demonstriert. Wie bereits der letzte Tipp ist auch dieser wieder so gestaltet, dass Sie die einzelnen Schritte selbst nachvollziehen sollten, um das komplexe Thema besser nachvollziehen zu können. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/sql_on_olap_cubes/index.html Die Erstellung von OLAP Cubes mit dem Analytic Workspace Manager (AWM) ist in einem früheren Tipp ausführlich behandelt worden. Wie dort ausgeführt, enthalten die Zellen eines OLAP Cubes nahezu beliebig komplexe geschäftliche Kennzahlen, die nach unterschiedlichen Kriterien (Hierarchien) verdichtet vorliegen. Mit den unterschiedlichsten Methoden und Werzeugen von MS Excel bis hin zu Oracle BI Enterprise Edition können die Inhalte von OLAP Cubes ausgewertet und visualisiert werden. Die Abfragesprache, mit der auf den OLAP Cube zugegriffen wird, ist hierbei SQL. Das SQL wird jedoch innerhalb der verwendeten Software generiert und bleibt daher dem Benutzer meistens verborgen. Durch die Verwendung der seit Oracle 11g bekannten Cube-organized Materialized Views können eine Vielzahl von relationalen Materialized Views ersetzt werden, die Abfragen im Datawarehouse mittels Query Rewrite beschleunigen. Cube-organized Materialized Views werden hierbei über den OLAP Cube gelegt, ohne ein neues Objekt mit redundanten Daten zu erzeugen. Dieses Verhalten ist bereits aus der relationalen Welt mit der Verwendung der Materialized Views on prebuilt table bekannt. Dieser Tipp, sowie der in 14 Tagen erscheinende 2. Teil, vervollständigen das Thema OLAP in der Datenbank. Beide sind erneut ausdrücklich zum Mitmachen gedacht. Es wird gezeigt, wie das Abfragen von OLAP Cubes über den Zugiff auf die zum OLAP Cube gehörenden relationalen Views mit Hilfe von einfachem SQL erfolgt. Darüberhinaus wird die Steigerung der Abfrage Performance durch Query Rewrite auf eine Cube-organized Materialized View dargestellt. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/external_tables/index.html External Tables sind seit Oracle 9i das geeignete Mittel, Datenmengen, die in Flat Files ausserhalb der Datenbank gespeichert sind, im READ-ONLY Zugriff zu haben. In die Datenbank selbst werden keine Daten geladen, sondern nur die Metadaten der External Tables gespeichert. Voraussetzung ist dabei die Beschreibbarkeit der Flat Datei im "Oracle Access" Treiber-Format wie SQL*Loader und Datapump. So können grosse Datenmengen aus Flat Dateien über External Tables einfach selektiert, über einen Join ausgewertet oder sortiert werden wie mit normalen Tabellen. CREATE VIEW oder CREATE SYNONYM-Operationen sind ebenso möglich. Zu beachten ist allerdings, dass keine DML-Operationen oder Indizierung erlaubt sind. Darüberhinaus ist es seit Oracle 10g möglich, das Resultat eines beliebigen SELECT-Statements mit der External Tables Technik zu entladen. Seit 11g Release 2 können die Flat Dateien für die External Tables Nutzung vorab mit anderen Programmen aufbereitet werden (pre-processing). So können auch Daten, die nicht im Oracle Treiber Format vorliegen, als Eingabe verwendet werden. Die Nutzung von External Tables bietet somit die Möglichkeit, Daten performant zu laden und zu entladen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/11gr2/index.html 11g Release 2 steht zum Download auf OTN für die Plattform Linux zur Verfügung. Um einen Vorgeschmack auf einige der neuen Features zu geben, haben wir im Folgenden eine Auswahl von 11 interessanten Neuerungen zusammengestellt. Bei den Beschreibungen handelt es sich um eine kurze Zusammenfassung der einzelnen Neuerungen, die nicht nach Prioritäten geordnet ist. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/sts_update/index.html In einem frühen Tipp zu SQL Tuning Sets im Einsatz wurde gezeigt, wie Sie SQL Tuning Sets verwenden können. Es wurde dabei beschrieben, wie SQL Tuning Sets von einer Datenbank zu einer anderen Datenbank transferiert werden können. Auch wird dort gezeigt, wie einfach man die laufende Last (SQL-Statements) in inkrementellen Schritten oder die SQL-Statements, die noch im Cursor-Cache gespeichert sind, in ein SQL Tuning Set übernehmen kann. Leider ist dieses in der Praxis oft nicht verwendbar. In diesem Update zeige ich daher weitere Möglichkeiten zum Laden von SQL-Statements und des Transfers.

• Füllen eines SQL Tuning Sets mit Daten aus AWR Snapshots
• Füllen eines SQL Tuning Sets mit Daten aus AWR Baselines
• Füllen eines SQL Tuning Sets mit Daten aus Top Activity
• Transfer von SQL Tuning Sets

http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/olap_cubes_mit_awm/index.html Die Technologie des Online Analytical Processing (OLAP) wird im Datawarehouseumfeld dazu verwendet, das in Standardberichten vorliegende Zahlenmaterial einer tiefergehenden Analyse zu unterziehen. Während Standardberichte häufig durch den Einsatz einzelner, spezialisierter Materialized Views optimiert worden sind, ist dieses bei einer ad-hoc durchgeführten drill-down-Analyse nicht möglich, da die zugrundeliegenden Abfragen und Berechnungen nicht im Vorfeld klar sind. Aus diesem Grunde lässt die Antwortzeit für ad-hoc Abfragen leider meistens zu wünschen übrig. Um die Antwortzeiten für ad-hoc Abfragen zu reduzieren, werden daher OLAP-Cubes eingesetzt, die die Daten logisch in Form eines mehrdimensionalen Würfels darstellen. Die Dimensionen des OLAP-Cubes beschreiben die Daten und erlauben auf einfache Weise den Zugriff. Dabei können Daten über eine oder mehrere Achsen des Würfels ausgewählt werden. Bereits seit der Datenbankversion 9i ist die Oracle Datenbank in der Lage, multidimensionale Objekte abzubilden. Im Laufe der Zeit sind die Möglichkeiten dieser Technologie immer mehr erweitert worden. Der vorerst letzte Evolutionsschritt ist in der aktuellen Version Oracle 11g erfolgt. In dieser Version sind cube-organized Materialized Views eingeführt worden, die durch den mehrdimensionalen Aufbau eine Vielzahl relationaler Materialized Views ersetzen können und auf diese Weise die Abfrageperformance in Datawarehouses verbessern helfen. Die Wartung bzw. die Aktualisierung dieser Daten ist durch ein inkrementelles Refresh schnell und leicht durchführbar. Für den Datenbankadministrator, der bisher vorwiegend mit relational organisierten Daten gearbeitet hat, stellt die multidimensionale OLAP-Welt leider noch häufig ein "Buch mit sieben Siegeln" dar, das aus diesem Grunde oftmals verschlossen bleibt. Dieser Tipp soll dazu dienen, durch das Aufzeigen von Parallelen zur relationalen Datenbank-Welt die fremd anmutende OLAP-Welt zu erklären und dem DBA näherzubringen. Gleichzeitig wird mit dem Analytic Workspace Manager 11g ein Werkzeug vorgestellt, das die Erzeugung multidimensionaler Datenbankobjekte signifikant erleichtert. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/tde/index.html Es gibt eine einfache Möglichkeit, mit verschlüsselten Daten zu arbeiten, wenn man sich entschließen kann, die Advanced Security Option (ASO) einzusetzen. Damit fallen zwar zusätzliche Lizenzgebühren an, aber der Erwerb einer Lizenz für ASO erlaubt im Rahmen des Feature Transparent Data Encryption (TDE) neben der Verschlüsselung von Benutzerdaten die Verschlüsselung von Backups mit RMAN, Exports mit Data Pump und des kompletten Datenverkehrs von und zur Datenbank. Ausserdem erlaubt erst der Einsatz der ASO, LDAP-Verzeichnisse zur Benutzerverwaltung der Datenbankbenutzer einzubinden und Mechanismen zur starken Authentisierung der Benutzer einzusetzen - z.B. in Form von Smartcards. In diesem Beitrag wird beschrieben, wie man TDE einsetzt, um Benutzerdaten zu verschlüsseln. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/scheduler/index.html Datenbank-Jobs in der Datenbank zu verwalten, ist schon seit jeher mit dem Package DBMS_JOB in der Datenbank möglich. Mit Oracle Database 10g ist nun das Package DBMS_SCHEDULER als Ersatz für DBMS_JOB eingeführt worden. Wie DBMS_JOB steht DBMS_SCHEDULER ohne zusätzliche Installation in allen Editionen der Datenbank zur Verfügung. DBMS_SCHEDULER Package bietet allerdings mehr Funktionalität und wird im Gegensatz zum Package DBMS_JOB in jedem Release weiterentwickelt. Genau diese Anleitung zu Oracle VM möchte ich hier veröffentlichen, einen RAC auf nur einem! Laptop (mit nur einer Netzwerkkarte) zu installieren. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/ovmrac/index.html Viele DBAs und Entwickler möchten gerne Erfahrungen mit dem Real Application Cluster von Oracle sammeln. Leider hat man aber selten die Hardware zur Verfügung um sich schnell einen Test-Cluster aufzubauen. Eine Lösung dafür heißt Virtualisierung. Was liegt also näher als sich eine RAC Umgebung mit Oracle Virtual Machine (OVM) aufzubauen? Allerdings stellen sich dabei folgende Probleme: Erstens ist OVM ein Serverprodukt und keine Lösung wie VMware Server oder Workstation, welches einfach auf einem Windows/Linux Rechner läuft, zweitens sollte man für die Administration besser einen zweiten Server haben (für den VM Manager) und drittens findet man im Netz kaum Step-by-Step Anleitungen. Genau diese Anleitung zu Oracle VM möchte ich hier veröffentlichen, einen RAC auf nur einem! Laptop (mit nur einer Netzwerkkarte) zu installieren. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/securefile/index.html Die Speicherung von Daten im LOB-Datentyp (wie z.B. BLOB, CLOB) ist eine wichtige Grundlage, um unstrukturierte Daten wie Dokumente und Bilder in der Datenbank abzuspeichern. Mit Oracle Database 11g steht ein neuer Datentyp für die Speicherung von Large Objects in allen Editionen der Datenbank zur Verfügung, die sogenannten SECUREFILEs. Im Gegensatz zu der "alten" LOB-Technologie, die ab 11g mit dem neuen Schlüsselwort BASICFILE angesprochen werden kann, bieten SECUREFILEs verbesserte Performance, vereinfachtes Management und unter Nutzung von zusätzlichen Datenbank-Optionen wie Advanced Compression oder Advanced Security zusätzliche Eigenschaften wie Verschlüsselung und Komprimierung bzw. "Deduplizierung" an. Verwendet man SECUREFILEs, so ändern sich die Programmierschnittstellen Java, .NET, PHP nicht - alle API-Aufrufe bleiben gleich. Natürlich bleiben auch Datenbank Abfragen, die Oracle Text, XML-Path oder das Paket DBMS_LOB nutzen, gleich und müssen nicht angepasst werden. Im Tipp wird die Verwendung und das Monitoring von SECUREFILEs an Beispielen demonstriert. Das Erzeugen von SECUREFILEs, die Migration, eine Anwendung von zusätzlichen Eigenschaften wie Komprimierung und der Vergleich von "alter" und neuer Technologie sind ebenfalls Thema des Tipps. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/auditing/index.html Im Datenbankumfeld versteht man unter Auditieren das Aufzeichnen von Benutzeraktivitäten. Die Oracle-Datenbank kann das seit etwa 20 Jahren. Seit Oracle Version 6 konnte protokolliert werden, wer mit welchen Befehlen auf welche Objekte zugreift oder wer welche Systemprivilegien nutzt. Diese Möglichkeiten haben aber viele Jahre lang eher ein Schattendasein unter den Datenbankfeatures geführt. Das ist z.B. daran erkennbar, dass das Auditing standardmäßig immer ausgeschaltet war und erst nach der änderung des (statischen) Konfigurationsparameters audit_trail und dem Neustart der Datenbank genutzt werden konnte. Inzwischen wird dem Auditing aber immer stärkere Aufmerksamkeit entgegengebracht - kein Wunder, denn Sicherheitsaspekte und Compliance-Anforderungen erzwingen ein immer umfangreicheres Monitoring der Benutzeraktivitäten. Sichtbar wird diese veränderte Einstellung dem Auditing gegenüber übrigens auch in der veränderten Standardeinstellung der neusten Datenbankversion, Oracle Database 11g: Hier ist das Auditing standardmäßig für alle Befehle aktiviert, die aus der Oracle-Perspektive sicherheitsrelevant sein könnten - z.B. für den Befehl CREATE USER. Obwohl man also schon lange die unterschiedlichsten Aktivitäten auditieren konnte, mangelte es lange an Differenzierungsmöglichkeiten. Betrachtet man beispielsweise den Zugriff auf Tabellendaten, konnte man nur feststellen, wer und wann lesend oder ändernd auf eine Tabelle zugegriffen hat. Auch ob die Aktion erfolgreich war oder nicht, wurde notiert. Die genauen Statements konnte man jedoch mit Datenbankmitteln nicht reproduzieren. Genauso wenig konnte das Auditieren an bestimmte Bedingungen geknüpft werden. Beides ist inzwischen möglich. Im folgenden Tipp erhalten Sie Hinweise dazu, wie man ein differenziertes und aussagefähiges Auditing implementiert. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/io_calibration/index.html Die Implementierung eines I/O Subsystems mit einem hohen Durchsatz ist ein integraler Bestandteil der Infrastruktur für eine zeitgemäße Applikation, sowohl im Datawarehouse- als auch im OLTP-Umfeld. Defizite im Design des Gesamtsystems wie zum Beispiel eine zu geringe Anzahl eingesetzter Festplatten oder eine nicht ausreichende Netzwerk-Bandbreite machen sich dann im laufenden Betrieb in Form schlechter Antwortzeiten unangenehm bemerkbar. Um den Kunden zur Vermeidung von Performanceengpässen eine Hilfe zu geben, hat Oracle vor einiger Zeit die Oracle Optimized Warehouse Initiative gestartet, die eine auf allen Ebenen der Systemlandschaft ausgewogene Architektur beschreibt. Diese Initiative hat im September letzten Jahres ihren bisherigen Höhepunkt in der Vorstellung der HP Oracle Database Machine gefunden, die auf den Prinzipien der well-balanced Architektur beruht. Diesen Idealzustand findet der DBA jedoch in historisch gewachsenen Umgebungen häufig nicht vor - vielmehr hat er für Anwenderklagen über mangelhafte Antwortzeiten Ursachen und Lösungen zu finden. Der Prozeß der Problemlösung beginnt üblicherweise mit der Waitevent-Analyse eines AWR-Reports. Hierbei deutet sich durch erhöhte Werte für I/O-bezogene Wait-Events (Wait Class "User I/O" oder "System I/O") ein Engpass im I/O-Durchsatz an. Um diesen Ansatz weiterzuverfolgen, ist es notwendig, die maximale Rate der I/O Operationen der Datenbank zu messen, die diese zuverlässig bereitstellen kann. Diesen Vorgang nennt man calibration. Das Ziel einer calibration hängt natürlich auch von dem Lastprofil ab, mit der die Datenbank betrieben wird:

• OLTP-Last: Fokus auf IOPS und Latenz
• DWH-Last: Fokus auf I/O-Durchsatz

Dieser Community-Tipp zeigt die Möglichkeiten der calibration in der aktuellen Version von Oracle 11g auf. Damit können I/O-Engpässe in bestehenden Umgebungen aufgezeigt oder auch die I/O Spezifikation einer neuen Systemlandschaft verifiziert werden. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/resource_manager/index.html Ressourcen in der Datenbank mit dem Database Resource Manager zu verwalten, ist schon seit der Version 8i mit der Enterprise Edition der Datenbank möglich. Mit der Oracle Database Version 10g und der Verfügbarkeit über die graphische Oberfläche des Enterprise Managers und die Erweiterung der Nutzung über Services, Module, Programme usw. erhöhen sich die Anwendungsmöglichkeiten des Database Resource Managers. Unabhängig von der Datenbanklast werden gewissen Sessions oder Applikationen ein Minimum an Ressourcen garantiert. So können zum Beispiel CPU-Ressourcen für verschiedene Applikationen priorisiert werden, langlaufende Operationen unterbunden oder die Anzahl der Sessions begrenzt werden, um nur einige Beispiele zu nennen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/haerten/index.html Jede Komponente der IT Infrastruktur muß optimal gegen Mißbrauch gesichert werden, damit ein akzeptabler Sicherheitsgrad des Gesamtsystems erreicht wird. Datenbanken kommt dabei jedoch eine herausragende Bedeutung zu, denn in ihnen ist das wichtigste Gut eines Unternehmens in konzentrierter Form abgelegt: Informationen. Dieser Tipp beschreibt die ersten Schritte auf dem Weg zu einer Grundsicherung der Datenbank. Diese Grundsicherung wird auch als Härten bezeichnet. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/aufbau_standby/index.html Mit Oracle 11g und den neuen Funktionalitäten im RMAN und Data Guard ist der Aufbau einer Standby Datenbank fast eine Sache von wenigen Minuten. Zumindest was die eigentliche Arbeit am Rechner anbelangt - die Zeit zum Kopieren der Daten ist hierbei natürlich nicht eingerechnet. Dieser Tipp beschreibt in Kürze die einfachen Schritte zum Klonen des Oracle Homes, der Erstellung einer 11g Standby Datenbank inkl. Konfiguration des Data Guard Brokers - das alles ohne Einsatz von Oracle Enterprise Manager Grid Control. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/advanced_compression/index.html Untersuchungen haben gezeigt, dass eine der größten Herausforderungen im Betrieb von Datawarehouses der Umgang mit stark wachsenden Datenmengen ist. Das Speichern großer Datenmengen hat dabei nicht nur einen Kosten-, sondern auch einen Performanceaspekt. Daher ist es bereits seit der Oracle Datenbankversion 9.2 in der Enterprise Edition möglich, das Datenvolumen durch den Einsatz von Komprimierung zu reduzieren. Da der Komprimierungsalgorithmus nur einen geringen Overhead erzeugt, war es bereits mit dieser Version grundsätzlich leicht umsetzbar, Plattenspeicher einzusparen und gleichzeitig bei I/O-intensiven Abfragen durch die Minimierung der Anzahl zu lesender Blöcke die Auswerteperformance zu steigern. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/inv_index/index.html Initialisierungsparameter können statisch oder dynamisch sein. Dynamische Parameter lassen sich mit dem ALTER SESSION-Kommando einstellen und gelten für die Dauer der Session. Dadurch wird es möglich, viele Funktionen in der Session zu nutzen ohne das gesamte System zu beeinflussen. Besonders im aktuellen Datenbank Release 11g sind einige wichtige Funktionen und Features eingeführt worden, die sich meist auch über dynamische Initialisierungsparameter einstellen lassen. Ein Beispiel dafür ist das Feature Invisible Index. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/acl/index.html UTL_SMTP, UTL_TCP, DBMS_LDAP und andere Packages, die auch schon länger im Lieferumfang der Datenbank enthalten sind, erlauben den einfachen Zugriff auf andere Server direkt aus der Datenbank. Die Packages sind überwiegend für den Benutzer PUBLIC zur Ausführung freigegeben. Natürlich ist das bei Bedarf ausgesprochen hilfreich, aber andererseits stellt sowohl die allgemeine als auch die uneingeschränkte Verfügbarkeit ein erhebliches Sicherheitsrisiko dar. Um dieses Sicherheitsrisiko zu eliminieren, ist die Funktionalität der betroffenen Packages in Oracle11g so modifiziert worden, dass der Zugriff auf andere Server erst nach einer ausdrücklichen Freigabe erfolgen kann. Die Freigabe erfolgt über sogenannte Access Control Lists (ACLs), die über den Aufruf von Packages erstellt und bearbeitet werden. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/statistics/index.html Optimizer-Statistiken liefern seit der Einführung des Cost Based Optimizers eine der wichtigsten Grundlagen zur Ermittlung eines guten Ausführungsplans durch den Optimizer. Um das Statistikmanagement zu erleichtern, gibt es seit Oracle Version 10g einen vordefinierten Datenbank-Scheduler Job, der das Sammeln von Statistiken automatisiert. Die manuelle Nutzung des Package DBMS_STATS ist dadurch allerdings nicht überflüssig geworden, da DBMS_STATS über den vordefinierten Scheduler-Job hinaus eine Vielzahl von zusätzlichen Möglichkeiten bietet, die zudem in 11g erweitert worden sind. Abgesehen vom manuellen Sammeln von Statistiken kann die Nutzung des Package DBMS_STATS weitere interessante Aufgaben erfüllen http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/einfache_verwaltung_mit_11g_partitioning/index.html Die Technik der Partitionierung ist eigentlich nicht neu, sondern bereits mit der Oracle Datenbankversion 8 als RANGE-Partitionierung eingeführt worden. Schrittweise um HASH-, LIST-Partitioning sowie zusammengesetzte Partitionierungsmöglichkeiten und verschiedene Maintenance-Operationen ergänzt, bietet die Partitioning Option schon in Oracle 10g reichhaltige Möglichkeiten, große Datenmengen in Datawarehouses zu strukturieren und zu verwalten. In der neuen Datenbankversion Oracle 11g sind die zur Verfügung stehenden Techniken erneut umfangreich erweitert worden. Eine besonders hilfreiche Erweiterung der Partitioning Option in 11g stellen

• INTERVALL-Partitionierung
• REFERENZ-Partitionierung

dar. Die Verwaltung eines Objektes, das nach einer zeitlichen Dimension (z. B. Verkäufe nach Tag/Woche/Monat) partitioniert ist, nimmt insbesondere beim Periodenwechsel sehr viel Zeit in Anspruch. Wenn der DBA nicht durch rechtzeitige Anlage einer neuen bzw. durch das Vorhandensein einer Default-Partition dafür Sorge getragen hat, dass die ins DWH fließenden Daten abgelegt werden können, kommt es sogar zu Fehlern im ETL-Prozess. ähnlich aufwändig gestaltet sich die Erweiterung von partitionierten Tabellen, die über referentielle Integritäten (z. B. Bestellungen und Bestellpositionen) verbunden sind. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/Grid_Control_Management_Pack_Verwaltung/index.html Oracle Enterprise Manager Grid Control besteht aus einer Basis von Funktionalitäten und erweiternde Management Packs. Die Basisfunktionalität umfasst unter Anderem die Standardadministration einer Datenbank wie Schemamanagement, Speichermanagement, usw. aber auch Backup und Recovery. Diese Basisfunktionalität ist Bestandteil der Datenbanklizenz (sowohl Enterprise Edition als auch Standard Edition). Die Management Packs, wie zum Beispiel Datenbank Diagnostics Pack oder Datenbank Configuration Pack sind separat zu lizenzieren. Eine solche Zusatzlizenz kann auch nur für die Nutzung des Packs für Enterprise Edition Datenbanken erworben werden. Damit sich die Verwendung von Grid Control so einfach wie möglich gestaltet sind alle Management Packs standardmäßig eingeschaltet. Eine Zusatzinstallation oder Aktivierung ist also nicht erforderlich. Wenn man aber verschiedene Management Packs nicht lizenziert hat, möchte man sicherlich entweder diese abschalten oder zumindest kenntlich machen. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/SPM/index.html Jede Umgebung unterliegt Veränderungen. Upgrades, Einführung zusätzlicher Zugriffsstrukturen, Einführung oder änderungen von Datenbankparametern stellen nur einige Beispiele dar. Dies kann auch bei optimal getunten Applikationen zu änderungen des Ausführungsplans (SQL Plans) und somit zu veränderter Performance und im schlechtesten Fall zu längeren Ausführungszeiten führen. Wünschenswert wäre den "Status Quo" zu erhalten und die "alten" Ausführungspläne beibehalten zu können. Der Einsatz von Statement Hints oder die Nutzung von Stored Outlines sind mögliche Lösungsansätze. Nachteil dieser Methoden ist allerdings die fehlende Flexibilität und Weiterentwicklung der Pläne: neue Ausführungspläne, die zu einer Verbesserung führen könnten, werden nicht mehr in Betracht kommen. Diese Problematik wird flexibel durch das sogenannte SQL Plan Management (auch SQL Plan Control oder kurz SPM) gelöst. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/fbda/index.html Daten werden gespeichert und zum Teil lange aufbewahrt. Mitunter werden die Daten nach ihrer ersten Speicherung geändert, vielleicht sogar mehrfach. Je nach gesetzlicher oder betrieblicher Vorgabe müssen die Veränderungen nachverfolgbar sein. Damit sind zugleich Mechanismen gefordert, die sicherstellen, dass die Folge der Versionen lückenlos ist. Und implizit bedeutet das zusätzlich, dass die Versionen auch vor Löschen und Verändern geschützt sein müssen. Häufig erfolgt das Versionieren über die Anwendung, mit der die Daten auch erfasst werden, und ist damit durch Umgehen der Anwendung zu unterlaufen. Die Versionierung kann auch durch Trigger erfolgen, was eventuell auf Kosten der Performance geht, weil die Transaktionslast des Systems durch das Abarbeiten der Trigger steigt. Oder die Versionierung erfolgt durch besondere Werkzeuge und ist deshalb mit höheren Kosten und / oder höherer Komplexität verbunden. Neben den genannten Schwächen der jeweiligen Lösung, bleibt bei allen drei Lösungsansätzen zusätzlich die Frage nach dem Schutz vor unerlaubtem Löschen oder ändern versionierter Daten offen. Flashback Data Archives lösen diese Frage, denn sie bieten nicht nur einen wirksamen Mechanismus zum Versionieren von Datensätzen, sondern sie schützen diese Versionen auch vor Veränderung und löschen sie schließlich sogar automatisch nach Ablauf ihrer Aufbewahrungsfrist. Dieser letzte Punkt mag auf den ersten Blick weniger wichtig erscheinen, aber Gesetze und Vorschriften beinhalten in der Regel nicht nur strenge Fristen zur Aufbewahrung von Daten, sondern ebenso strenge Fristen zu ihrer Löschung. In der Oracle-Preisliste finden Sie die Archives als neue Option zur Enterprise Edition der Oracle Database 11g unter dem Namen Total Recall - was übersetzt so viel heißt wie 'das perfekte Gedächtnis'. http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/ssl_einstellungen_fuer_management_agent/index.html Oracle Enterprise Manager Grid Control arbeitet mit Agenten auf den verschiedenen Zielplattformen. Diese Agenten (Oracle Management Agent) kommunizieren mit dem zentralen OMS (oder mehrereren zentralen OMS in einer HA Umgebung). Dabei werden unter anderem ständig Monitoringdaten vom Agenten zum OMS geschickt. Damit diese Kommunikation nicht von Außenstehenden abgehört werden kann, sollte sie mittels SSL-Verschlüsselung gesichert werden.