Oracle Database 12c bringt eine Reihe hilfreicher Features mit sich. Wie alle anderen Releases muss sie allerdings auch verwaltet werden. Dazu steht neben den bekannten Tools jetzt mit EM Database Express auch ein neues Mitglied aus der Familie "Enterprise Manager" (EM) zur Verfügung. DOAG Online nimmt die Administrationswerkzeuge in Augenschein.
Das zentrale Puzzlestück für die Verwaltung von Oracle Produkten ist Cloud Control 12c. Neben der Verwaltungskonsole existiert eine ganze Reihe von Tools. Alle Produkte dieser Familie hören auf den Nachnamen "Enterprise Manager". Ihr modularer Aufbau sorgt bei neuen Produkten oder Produktversionen für eine rasche Verwaltungsunterstützung.
Das Modul, das die Verwaltung der Oracle-Datenbank übernimmt, unterstützt seit Februar 2013 – und somit schon vor Erscheinen des Releases – 12c-Features wie Oracle Multitenant, Data Redaction, neues Auditing, neue "Resource Manager"-Pläne und vieles mehr. Als Oracle Database 12c das Tageslicht erblickte, war eine Verwaltung dieser Features in Cloud Control 12c also bereits gegeben. Die vollständige Unterstützung aller neuen Features wird mit den folgenden neuen Versionen des Datenbank-Moduls in Cloud Control zeitnah realisiert.
Abbildung 1: Umgang mit Pluggable Databases in Cloud Control
Wie für die Oracle-Datenbank 10g beziehungsweise 11g gibt es auch in 12c eine Einzel-Datenbank-Verwaltungslösung, die als Webanwendung genutzt wird. Bis 11g hieß diese "EM Database Control". In 12c wird sie von einem neuen Tool abgelöst: EM Database Express.
EM Database Express
Im Gegensatz zum alten EM Database Control benötigen DBAs bei der Implementierung von EM Database Express keinen "OC4J Container". Denn die Implementierung erfolgt nun über einen Zugriff auf die in der Datenbank beinhaltete XDB (XML-Datenbank).
Dies verschlankt nicht nur die Installation der Datenbank, sondern macht auch die Webanwendung effizienter und schneller. EM Database Express wird mit jeder Oracle-Datenbank 12c installiert und bei Verwendung des "Database Configuration Assistant" auch konfiguriert. Sollte EM Database Express für eine Datenbank mal nicht funktionieren, so muss nur ein Port für die XDB geöffnet werden.
Mit EM Database Express können Sie sich schnell einen guten Überblick über die Datenbank verschaffen und Basis-Verwaltungsaufgaben durchführen. Das Tool ist in folgende fünf Sektionen unterteilt:
- Überblick
- Configuration
- Storage
- Security
- Performance
Mit einem Klick auf den Namen der Instanz oben links landen Sie in der Sektion Überblick. Dort können Sie den Status der Datenbank, einige Angaben zu Performance, Incidents (nur CDB), laufende Jobs und laufende SQL-Kommandos sehen.
Im Bereich "Configuration" können Sie je nach Art der Datenbank verschiedene Konfigurationen vornehmen: Instanzparameter einstellen, die SGA konfigurieren (nicht bei PDB), und die in der Datenbank genutzten Features einsehen.
Unter Storage können Sie das Undo-Management betreiben, "Redo Log"-Einstellungen vornehmen, sowie Archivelogs, Kontrolldateien und Datendateien verwalten (letztere nicht bei CDBs).
In der Sektion Security können Datenbankbenutzer, -Rollen und -Profile (letztere nicht bei CDBs) eingestellt werden.
Der Performance-Bereich ist nur in Zusammenhang mit bestehender Lizenz für Diagnostics- bzw. "Tuning Pack" nutzbar. Er gibt Ihnen einen wertvollen Performance-Überblick über Ihre Datenbank. Darüber hinaus können Sie den "Tuning Advisor" nutzen.
Abbildung 2: Performance Hub in EM Database Express
Aktivierung des EM Database Express
Die Aktivierung von EM Database Express ist sehr einfach. Mit der Listener Control Utility können Sie ermitteln, welche Ports auf Ihrem Server schon geöffnet sind:
lsnrctl status |
Sie sehen damit aber nicht, welcher Port für welche Datenbank verwendet wird. Dazu fragen Sie in der jeweiligen Datenbank ab:
| class="courier">SQL> select DBMS_XDB_CONFIG.GETHTTPPORT, DBMS_XDB_CONFIG.GETHTTPSPORT from dual; GETHTTPPORT GETHTTPSPORT ----------- ------------ 5500 5501 |
Sollten die Ergebnisse 0 oder NULL sein, so sind die jeweiligen Ports nicht geöffnet. Im obigen Fall gibt es sowohl einen SSL als auch einen Nicht-SSL Port. Wenn es einen Port gibt, ist EM Database Express aktiviert und kann, wie im obigen Fall, so aufgerufen werden:
| http://hostname:5500/em |
bzw.
| https://hostname:5501/em |
Sie öffnen einen Port (zum Beispiel Port 5506) für den Betrieb mit SSL einfach mit
| SQL> exec DBMS_XDB_CONFIG.SETHTTPSPORT(5506); |
Zum Deaktivieren von EM Database Express setzen Sie einfach den Port auf NULL.
Weitere Utilities
Neben Oracle Enterprise Manager gibt es aber auch bei den altbekannten Utilities Data Pump und SQL*Loader neue Features zu vermelden.
Data Pump
So können Sie jetzt für verschlüsselte Export-Dateien, die mit einem Passwort geschützt werden sollen, dieses Passwort auch interaktiv angeben und nicht wie zuvor nur als Parameter in der Kommandozeile (bzw. als Parameter in einer Datei).
| expdp hr/hr@ORCL1 dumpfile=hr.dmp directory=WDGDIR schemas=hr encryption=all encryption_mode=password encryption_pwd_prompt=y |
Des Weiteren können Sie Views als Tabellen exportieren. Dabei wird nicht wie früher nur die Viewdefinition exportiert. Vielmehr wird die Definition der View als SELECT-Abfrage für einen Datenexport herangezogen. Es wird also eine Export-Datei erzeugt, die dann bei einem Import die entsprechenden Daten als Tabelle importiert.
| expdp hr/hr@ORCL1 dumpfile=hr.dmp directory=WDGDIR views_as_tables<=[schema].tabelle,... |
Mit dem TRANSFORM-Parameter können Sie jetzt auch beim Import eine Komprimierungsmethode wählen.
| imdp hr/hr@ORCL1 dumpfile=hr.dmp directory=WDGDIR transform=table_compression_clause:COMPRESS_FOR_OLTP |
Gerade bei initialien Imports ist es oft nicht sinnvoll, die dadurch normalerweise anfallenden "Redo Log"-Daten generieren zu lassen. Das gilt vor allem, wenn erst im Nachhinein eine Backup-Strategie aufgesetzt und die Datenbank produktiv wird. Aus diesem Grund können Sie jetzt den auch von anderen Kommandos bekannten NOLOGGING-Modus für den Import verwenden. Diese kann auf Tabellen oder Indizes eingeschränkt werden.
| imdp hr/hr@ORCL1 dumpfile=hr.dmp directory=WDGDIR transform=disable_archive_logging:Y|N[:TABLE|INDEX] |
Schon seit langer Zeit gibt es die Möglichkeit, eine Datenbank per Export/Import zu transportieren. Dabei werden per "Full Database Export" alle Nicht-System-Daten in eine Exportdatei ausgelesen. Bei großen Datenbanken wird diese Export-Datei entsprechend groß und der Vorgang dürfte auch seine Zeit benötigen.
Dann wird diese große Export-Datei, die auch in kleine Stücke aufgesplittet werden kann, von Server zu Server kopiert. Beim "Full Database Import" wird zunächst eine leere Datenbank mit allen System-Daten erstellt, und dann werden die in der Export-Datei gespeicherten Nicht-System-Daten importiert, zumeist auch ein zeitraubender Vorgang.
Mit der Oracle Datenbank 12c gibt es nun einen neuen Weg für diese Aufgabe: "Full Transportable Export/Import". Dabei werden beim Export keine Daten aus der Quelldatenbank ausgelesen, sondern nur Metadaten – also die Beschreibung, welche Datendateien zur Datenbank gehören. Denn die Idee dabei ist, dass nicht eine Export-Datei mit den Benutzerdaten von Server zu Server kopiert wird, sondern die Datendateien selbst. Dieses Prinzip ist seit geraumer Zeit als "Transportable Tablespace" bekannt, was jetzt auf die ganze Datenbank ausgeweitet wird.
Beim Import wird wieder eine leere Datenbank erzeugt und die kopierten Datendateien werden dieser neuen Datenbank hinzugefügt. Damit entfällt das zeitraubende Auslesen und Einlesen der Benutzerdaten. Voraussetzung für dieses Verfahren ist, dass alle Tablespaces der Quelldatenbank READ ONLY gesetzt werden.
SQL*Loader
Auch beim SQL*Loader bringt 12c neue Features mit sich: Für einfache Ladevorgänge mit CSV-Dateien (CSV – Comma Seperated Values) brauchen Sie jetzt keine Steuerungsdatei mehr. Der SQL*Loader ist in der Lage, die CSV-Datei automatisch zu analysieren und zu laden. Voraussetzung ist die Verwendung von Kommata als Trennzeichen in der CSV-Datei, sowie die Verwendung skalarer Datentypen (Character – CHAR/VARCHAR, Number, Date), die den Datentypen in der Tabelle entsprechen müssen, also keine Konvertierung erfordern). Ein kleines Beispiel macht dieses neue Feature deutlich:
Tabellendefinition:
| SQL> create table wdg1 (nu number,text varchar2(100),datum date); |
Datendatei wdg1.txt:
1,Hans,01-jan-13 |
Ladekommando:
| sqlldr hr/hr@ORCL1 table=wdg1 data=wdg1.txt |
Neue Management-Features in der Datenbank
Nutzung von temporären Tablespaces
Auch ganz ohne Tools geht es mit und in Oracle Database 12c besser: So können jetzt die Undo-Daten für temporäre Tabellen in eigenen Undo-Segmenten gespeichert werden. Diese liegen im temporären Tablespace – und nicht wie sonst im Undo-Tablespace.
Der große Vorteil: Der Umgang mit großen temporären Tabellen bläht nicht mehr unnötigerweise die normalen Undo-Segmente auf. Diese waren dann im weiteren Verlauf größer als eigentlich notwendig. Das hat sich mit 12c erübrigt.
Auch können auf diese Weise temporäre Tabellen in einer "Active Data Guard"-Datenbank schreibend verwendet werden. Denn sowohl die temporäre Tabelle als auch deren Undo-Daten liegen ja im temporären Tablespace. Im Gegensatz zu den anderen Tablespaces ist der temporäre Tablespace auch in einer sonst "READ ONLY"-geöffneten "Active Data Guard"-Datenbank beschreibbar.
Der Administrationsaufwand für dieses Feature ist denkbar gering: Sie stellen es einfach mit dem Instanzparameter „temp_undo_enabled“ ein. Das Anlegen erfolgt dann automatisch. Mit dem Löschen einer temporären Tabelle wird auch deren Undo-Segment automatisch gelöscht.
| SQL> alter system|session set temp_undo_enabled=true|false; |
Die Verwendung dieser Undo-Segemente kann in v$tempundostat eingesehen werden.
Neuer Instantparameter PGA_AGGREGATE_LIMIT
Auch in Sachen Steuerung der SGA gibt 12c Neues zum Vorschein: In früheren Versionen wurde der Parameter PGA_AGGREGATE_TARGET eingeführt. Dieser gibt eine Zielgröße für die Summe aller PGA-Inhalte an. Benötigt allerdings die Nutzungsart der Datenbank mehr PGA als angegeben, so kann die Zielgröße nicht eingehalten werden.
Bevor eine Datenbanksitzung einen Fehler aufgrund mangelnder PGA-Memory bekommt, überschreitet die Datenbank das per Instanzparameter vorgegebene Ziel.
Mit dem neuen Instanzparameter PGA_AGGREGATE_LIMIT können Sie dies verhindern und so eine stärkere Kontrolle bezüglich des genutzten Hauptspeichers ausüben – im Ernstfall natürlich zulasten von Datenbanksitzungen, die dann Memory-Fehler bekommen.
Blick in das "Oracle Inventory" mit PL/SQL-Package DBMS_QOPATCH
Von vielen DBAs wurde schon lange eine Möglichkeit gewünscht, aus SQL beziehungsweise PL/SQL heraus einen Blick in das "Oracle Inventory" einer Oracle-Installation zu werfen. Aber auch aus Anwendungssicht ist es sicherlich interessant, Prüfungen hinsichtlich vorhandener Patches vorzunehmen und im Ernstfall Anwendungsmodule zu blockieren.
Dieser Zugriff war auch früher schon möglich, wenn auch recht aufwändig. Mit dem neuen PL/SQL-Package DBMS_QOPATCH können Sie jetzt zum Beispiel sehr einfach sehen, welche Patches installiert sind mit
REM Welche Patches sind installiert? |
oder auch gezielt suchen mit
REM Ist ein spezieller Patch installiert? |
Spot ADDM
Wer das "Diagnostics Pack" lizenziert hat, kann sich auf eine neue Variante des "Automatischen Datenbank Diagnostic Monitors" (ADDM) freuen, die den Namen “Spot ADDM” trägt. Dabei wird bei speziellen Ereignissen – wie zum Beispiel Deadlocks, Hochlast, CPU-Bound, etc. – automatisch ein Diagnostiklauf gestartet, der später jederzeit eingesehen werden kann. Damit ist gewährleistet, dass performancekritische Situationen später genauestens analysiert werden können.
