Home 
ORDIX News 4/2005
ORDIX News 4/2005
ORDIX News 4/2005
der Version 10.2 verschaffen wollen.
| SGA System Global Area. SGA ist der von Oracle allokierte Hauptspeicher auf dem Datenbank Server. |
| ASM Automatic Storage Management. Oracle Volume Manager, der das Striping, Mirroring und Loadbalancing übernimmt. |
Oracle 10gR2 ist seit Anfang August 2005 für Linux verfügbar. Zum Redaktionsschluss steht das Release für folgende Plattformen zur Verfügung:
Die Neuheiten lassen sich thematisch in folgende Blöcke unterteilen:
Wir starten mit den Neuheiten zum Thema Administration.
Womit beginnen wir, wenn wir Auto fahren? Wir starten den Motor. So ähnlich ist es bei Oracle auch: Wir starten im ersten Schritt die Instanz. Diese besteht aus der SGA und den Hintergrundprozessen.
Bei sehr großen SGAs kann das Initialisieren des Hauptspeichers manchmal etwas länger dauern. Um diese Wartezeit zu verkürzen, werden mit 10gR2 zunächst nur 10 Prozent des Datenbank Puffers allokiert. Der große Rest wird im laufenden Betrieb initialisiert.
Bis einschließlich 10gR1 muss zum Ändern von Parametern wie maxlog.les, maxlogmembers usw. per create controlfile Skript eine neue Control Datei erstellt werden. So etwas ist mit einem Wartungsfenster verbunden.
Mit Oracle 10gR2 können wir solche Dinge online erledigen. Das bedeutet weniger Wartungsfenster und somit höhere Verfügbarkeit.
In Test- und Qualitätssicherungsumgebungen kommt es häufig vor, dass die vorzuhaltenden Datenmengen stark schwanken. Als Datenbankadministrator (DBA) machen wir dann beispielsweise Folgendes:
Den Tablespaces werden Dateien mit einer Größe x Gbytes hinzugefügt. Nach der Testphase liegen dort viele große Dateien ohne Inhalt. Jetzt gibt es zwei Möglichkeiten:
Beide Varianten sind nicht besonders befriedigend. Mit 10gR2 gibt es nun die Möglichkeit, einzelne Datenbankdateien zu löschen.
Das Package dbms_redefinition ist bereits mit 10gR1 erweitert worden. Mit 10gR2 ist es jetzt auch möglich, einzelne Partitionen einer Tabelle auf andere Tablespaces zu verschieben.
Mit 10gR1 haben wir den Oracle Scheduler bekommen. Mit 10gR2 ist der Scheduler um die Funktionen erweitert worden, auf das sicherlich viele DBAs gewartet haben. Das Stichwort heißt hier "Ereignissteuerung".
Der Parameter DB_FILE_MULTIBLOCK_READ_COUNT steuert die Anzahl der Blöcke, die beim Lesen in einer Art vorauseilendem Gehorsam bei Scan-Vorgängen in den Datenbank-Cache gelesen werden. Beispiele hierfür sind Full Table Scans oder Index Fast Full Scans. Der Wert dieses Parameters hat einen nicht zu unterschätzenden Einfluss auf die Gesamt-Performance der Datenbank.
Mit dem neuen Feature wird die Datenbank in die Lage versetzt, selbstständig einen optimalen Wert für diesen Parameter zu finden. Dabei werden die Größe des Datenbank-Caches und die optimale I/O-Größe des Betriebssystems berücksichtigt.
Mit dem Feature "Automatic Undo Retention" wird die Undo Retention immer auf dem maximal möglichen Wert für die feste Größe des UNDO Tablespaces gehalten. Das bedeutet, dass der Parameter UNDO_RETENTION letztlich überflüssig wird.
Ein gerne vergessener Punkt beim Recovery von Datenbanken ist das manuelle Hinzufügen von Dateien für den Temporary Tablespace. Es fällt ja auch zunächst nicht auf. Das Recovery ist beendet, die Datenbank ist offen und alle sind froh, dass die Anwender und Kunden wieder arbeiten können. Bei der nächsten größeren Sortieroperation hat diese Freude aber ein jähes Ende. Der typische Anruf, den der DBA bekommt, lautet: "Da geht was nicht." Nun gibt es zwei Möglichkeiten:
Damit das in Zukunft nicht mehr vorkommt, hat Oracle Erbarmen mit uns und gestattet es dem Recovery Manager, Tempfiles nach vollbrachtem Recovery selbstständig anzulegen.
Mit 10gR1 wurde Flashback Database eingeführt. Flashback Database gibt uns die Möglichkeit, ein Point in Time Recovery durchzuführen, ohne ein Backup einspielen zu müssen. Bei einem Point in Time Recovery, egal ob mit einem Backup oder mittels Flashback Database, wird die Datenbank am Ende des Vorgangs immer mit der Option resetlogs geöffnet: alter Database open resetlogs;
Wenn wir das einmal gemacht haben, können wir mit 10gR1 nicht mehr per Flashback Database hinter den open resetlogs-Punkt zurückfahren.
Wir gehen davon aus, dass der DBA mit Bedacht zu Werke ging und die Datenbank vor dem open resetlogs mit der read only Option geöffnet hat, um sich zu vergewissern, dass alles in Ordnung ist. Dennoch kann es sein, und es ist sicherlich auch schon vorgekommen, dass kurz nach dem Öffnen der Datenbank die Anwender feststellen, dass ein nochmaliges Zurücksetzen erforderlich ist. Mit 10gR2 ist genau das ohne Einspielen eines Backups möglich.
flashback Database to before resetlogs;
Erinnern wir uns an Savepoints. Das sind die Zwischenstationen bei einer längeren Transaktion, die sich per Rollback anfahren lassen. So etwas Ähnliches gibt es jetzt auch für Flashback Database. Damit ist folgendes Szenario vorstellbar:
Bei einem Fehler durch die Prozedur ließe sich somit ein bereits vorher klar definierter Wiederaufsatzpunkt anfahren.
Wir wissen, dass Data Guard eine tolle Sache ist. Mit den Releases ab 9.0 hat es jedes Mal neue, wichtige Features gegeben. Einige wollen wir uns in Erinnerung rufen:
Was unsere Kunden und uns aber immer gestört hat, war die Tatsache, dass wir uns selbst um das Löschen der angewandten Logfiles kümmern mussten. Sicherlich lässt sich so etwas schedulen, aber Oracle kann es jetzt auch - für die logische Standby-Datenbank.
Sobald die archivierten Redo Log Dateien vom SQL Apply abgearbeitet wurden, werden sie gelöscht.
Bei einem Fehler oder dem Ausfall der Produktionsdatenbank oder des Netzwerks kann Data Guard jetzt automatisch einen Failover zu einer vorher definierten Standby-Datenbank durchführen. Dies geschieht ohne manuelle Eingriffe.
Die Idee dahinter ist verlockend: 7x24 h, ohne Zutun eines Administrators. Aber das ist eine Funktionalität, die wir sehr genau untersuchen werden, damit wir Sie hier richtig beraten können.
In der ORDIX News 1/2005 berichteten wir über das geänderte Verhalten des Statements drop table <tabellenname>.
Mit 10gR1 führt dieses Kommando dazu, dass die Tabelle nicht wirklich gelöscht wird, sondern nur umbenannt wird. Bei 10gR2 lässt sich das Verhalten von drop table mit einem init.ora Parameter steuern.
RECYCLEBIN = [ON | OFF]
Steht der Parameter auf OFF, so verhält sich drop table wie von den Releases bis einschließlich 9.2 bekannt. Der Standardwert ist leider ON, der Recyclebin ist also eingeschaltet.
Insgesamt bringt 10gR2 nicht so viel fundamental Neues wie 10gR1. Das hat sicherlich auch niemand ernsthaft erwartet. Aber die neuen Features machen Oracle in Summe wieder ein Stückchen "runder".
Die hier vorgestellten neuen Funktionen stellen die aus unserer Sicht wichtigsten Highlights dar, die Oracle mit dem zweiten Release von 10g hinzugefügt hat. Es gibt jedoch noch eine Fülle weiterer Kleinigkeiten für die bereits oben genannten Themenblöcke: Administration, Verfügbarkeit, Performance, Backup und Recovery sowie SQL und PL/SQL.
In den folgenden Ausgaben gehen wir auf die einzelnen Features detaillierter ein.
Andreas Kother (info@ordix.de).