Freitag Jul 08, 2016

Data Guard und Automatic Standby File Management

Standby Systeme sind für jede Datenbank unverzichtbar, die Wert auf Verfügbarkeit legt. Standby Datenbanken erlauben bei ungeplanten Ausfällen schnell wieder online zu sein und sollten deshalb auch in keiner Desaster Recovery Strategie fehlen. Oracle hat die Funktionalitäten rund um Standby Datenbanken kontinuierlich erweitert und so stehen mit Oracle Data Guard jeder Enterprise Edition der Datenbank viele erweiterte Standby Funktionalitäten zur Verfügung. Damit ist man gegen fast jedes Ausfall-Szenario abgesichert - nicht umsonst ist deshalb Data Guard auch ein fester Bestandteil der Maximum Availability Architektur von Oracle.

Eine Erweiterung von Data Guard war schon zu Oracle 9i Zeiten, die Einführung vom automatischen Standby File Management. Hier werden die Informationen im Redo der Datenbank erweitert, so dass auch das Anlegen von Datendateien und neuen Tablespaces automatisch auf die Standby Seite propagiert werden.

Damit dies auch dann reibungslos funktioniert, wenn sich die Dateistrukturen auf der Standby Seite vom Primärsystem unterscheiden, gibt es Convert Parameter, die entsprechende Pfade der Primärseite auf der Standby Seite durch die richtige Verzeichnisstruktur ersetzen. Diese Parameter finden aber nicht nur rein bei Data Guard Verwendung, sondern auch beim Duplizieren von Datenbanken mit dem Recovery Manager.

Leider gibt es bei den Convert Parametern immer wieder Verwirrung, wenn diese nicht greifen. Warum dies so ist erklärt der Community Tipp zu Data Guard und Automatic Standby File Management.

Freitag Apr 29, 2016

Data Guard und Multitenant

Oracle Multitenant hat den Charme mehrere einzelne Pluggable Datenbanken mit einem einzigen Data Guard abzusichern, da Data Guard auf Container Datenbank Ebene funktioniert. Das erspart viel Verwaltungsaufwand und es muss nicht mehr wie früher für mehrere Datenbanken verschiedene Data Guard Umgebungen aufgebaut, überwacht und administriert werden. Weitere Vorteile und Grundlagen von Multitenant finden Sie auch in unserem Dojo #7: Oracle 12c Multitenant.

Dieser Vorteil, nur einige, wenige Data Guard Umgebungen pflegen zu müssen, birgt aber auch einige administrative Stolpersteine, derer man sich bewusst sein sollte. So sind mit der Version 12.1 noch einige Einschränkungen vorhanden: Das Flashback, gerne im Zusammenhang mit Data Guard Umgebungen gesehen, ist nicht für einzelnen Pluggable Datenbank möglich, ebenso wenig das Umschalten einer einzelnen Pluggable Datenbank auf die Standby Seite. Auch dies funktioniert technisch, wie Data Guard selber, nur auf Container Datenbank Ebene.

Ein weiterer Knackpunkt ist das Verhalten beim Anlegen, Einstecken oder Duplizieren von PDBs. Was genau es zu Berücksichtigen gibt, wenn in eine Multitenant Umgebung mit Data Guard abgesichert wird, erfahren Sie im aktuellen Community Tipp.

Freitag Jan 08, 2016

Hochverfügbarkeit für APEX

Je mehr APEX für unternehmenskritische Anwendungen eingesetzt wird, desto wichtiger wird die Verfügbarkeit der APEX-Installation. Da APEX in der Oracle-Datenbank läuft, können alle Hochverfügbarkeitstechnologien derselben genutzt werden. So lässt sich APEX fast ohne Veränderung in einer RAC-Datenbank betreiben (Real Application Clusters). Auch die Verwendung einer Standby-Datenbank mit Oracle Data Guard für ein APEX-System ist völlig unproblematisch.

Wie einfach dies geht zeigt unser erster Community Tipp in diesem Jahr zusammen mit der APEX Community.

Freitag Feb 07, 2014

Block Korruption: Erkennen, Vorbeugen und (automatisch) Reparieren

Eine Datenbank hat eigentlich nur eine wichtige Aufgabe: Die ihr anvertrauten Daten zu speichern und bei Bedarf auch richtig wiederzugeben. Dabei ist es egal, ob es sich nur um eine kleine Datenbank auf Platte handelt, oder auf Technologien beruht diese Daten InMemory zur Verfügung zu stellen. Leider gibt es aber - egal welche Speichertechnologie verwendet wird - immer wieder Ereignisse, die Daten bei der Speicherung korrumpieren. Daher ist es eine zentrale Anforderung diese sogenannte Block Korruption zu erkennen, zu vermeiden und ggf. sogar direkt automatisch zu beheben. Oft zeigen sich die Probleme allerdings erst dann, wenn man versucht wieder auf die Daten zuzugreifen. Dann kann es häufig schon zu spät sein, insbesondere, wenn die fehlerhaften Blöcke auch im Backup enthalten sind.

Genau hier zeichnet sich die Oracle Datenbank mit Ihren Technologien aus, die nicht nur gleich beim Backup mit RMAN eine Überprüfung der Blöcke vornehmen, sondern auch erweiterte Funktionen zur Prävention bieten. Hierzu gehört auch eine Active Standby Umgebung mit der es sogar möglich diese Fehler direkt und automatisch zu korrigieren.

Ein weiterer wichtiger Punkt ist das Verhalten der Datenbank, wenn eine Block Korruption erkannt wurde, insbesondere in Zeiten von Konsolidierung und Multitenant.

Mehr dazu im aktuellen Tipp.

About

Hier finden Sie aktuelle Tipps rund um die Core und Cloud Themen der Oracle Datenbank.

Die Community-Einträge repräsentieren die Meinung der Autoren und entsprechen nicht zwingend der Meinung der Oracle Deutschland B.V. & Co KG.

Viel Spaß beim Lesen wünschen
Ulrike Schwinn, Ralf Durben,
Manuel Hoßfeld und Sebastian Solbach

Search

Categories
Archives
« Juli 2016
MoDiMiDoFrSaSo
    
1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
18
19
20
21
23
24
25
26
27
28
29
30
31
       
Heute