Die aktuell eingetroffene Version von Dbvisit Standby nehme ich mal zum Anlass die „Smart Alternative“ näher vorzustellen. Diese bringt auch wieder neue Features mit. So kann man jetzt nicht nur mit ein paar Klicks eine Standby Datenbank aufbauen. Hinzu kommt die Möglichkeit, dass wir den Zeitpunkt genau festlegen können, den unsere Standby Datenbank widerspiegeln soll. Damit erhält der DBA eine einfache Möglichkeit Reporting- oder Testdatenbanken aufzubauen, die Reporting-Daten bis zu einem bestimmten Zeitpunkt enthalten soll. In den nächsten Zeilen gebe ich einen Einblick wie sie innerhalb von 10 Minuten eine neue Datenbank aus Ihren vorhandenen Daten erstellen, der Rest hängt natürlich einzig von der Menge Ihrer Daten ab.
Natürlich muss etwas Vorarbeit in Form von Installation und Konfiguration geleistet werden. Hat man den Dreh aber einmal raus, erleichtert es die Administration erheblich. Jetzt gibt es natürlich einige Spezialisten die sagen, das geht doch auch alles mit Oracle-eigenen Mitteln vor allem RMAN ist hier zu nennen, das kann ich alles selber. Und tatsächlich, Dbvisit macht sich das, was Oracle mitbringt und in die Datenbank eingebaut hat zunutze. Hier liegt aber nicht der Fokus, man kann sich sicher sein, dass Oracle selbst am besten die Innereien seiner Datenbank kennt. Was Dbvisit macht ist, dem DBA die Arbeit zu erleichtern und das tut es. Als weiterer Punkt kommt hinzu, dass Dbvisit natürlich eine Alternative zu Oracle Data Guard darstellt, und das nicht nur unter Kostengesichtspunkten. Nicht jeder DBA ist mit einer Enterprise Edition mit Data Guard Option gesegnet, aber jeder muss für eine Absicherung seiner Datenbank sorgen. So bietet Dbvisit seine Standby Lösung auch für die Standard Editionen an.
Die Installation von Dbvisit Standby 7.0 selbst ist denkbar einfach und kann ich damit getrost abhaken. Ich stelle hier die Windows Variante mit einer 11gR2 Datenbank vor, aber die Linux-Version unterscheidet sich nur unwesentlich und Abweichungen beziehen sich eben auch auf Linux- bzw. Unix-Eigenheiten. Wichtig ist nur, dass alles was Sie auf dem Quell-Server auch möglichst 1:1 auf dem Ziel-Server tun. Damit beziehe ich mich zum einen auf die Installation des Oracle-RDBMS, die gemounteten Laufwerke, die Verfügbarkeit der einzelnen Oracle-Destinations und bei der Dbvisit-Installation vor allem auf die Installationsverzeichnisse. Gegenüber den Vorgängerversionen hat man hier ordentlich Hand angelegt und die Installation deutlich verbessert. Jetzt bringt Dbvisit seinen eigenen Netzwerk Service mit und räumt damit Konfigurationsprobleme mit WinSSHD, dessen man sich unter Windows gewiss sein konnte mit einem Wisch aus dem Weg. WinSSHD hat sich erledigt, verschwenden Sie also keinen Gedanken mehr daran.
Neben der eigentlichen Standby Programmatik bringt Dbvisit noch einen eigenen Webserver mit. Damit wird die Verwaltung über eine Weboberfläche realisiert, diese ist von überall aus dem Netzwerk erreichbar und bringt alles an Funktionalität klickfreundlich an den Mann. Ich empfehle für die effektive Nutzung den Mozilla Firefox. Ich habe andere getestet und der Firefox hat sich in Punkto Schnelligkeit und Darstellung durchgesetzt. Die Weboberfläche erreichen Sie nach der Installation standardmäßig über http://hostname:8081. Wer eine Abneigung gegen Klicki-Bunti hat kann natürlich auf die Dbvisit-eigene Konsole setzen. Vorteil ist natürlich, dass es zu keinen Unterbrechungen in der Verbindung kommen kann. Wirkliche Argumente, die unbedingt für die Konsole sprechen kenne ich aber nicht. Jedem das seine also.
Sie haben die Wahl.
Soweit so gut. Wenn alles installiert ist geht es an die Konfiguration, vorausgesetzt, wir haben auf der Quellseite eine Oracle Datenbank im Archive-Log-Modus und auf der Zielseite ein entsprechendes Oracle RDBMS, dass unsere Standby aufnehmen könnte. Bevor es so richtig losgehen kann, verlangt Dbvisit von uns eine Konfiguration zu erstellen, diese wird in einer Konfigurationsdatei gespeichert und DDC File genannt. Wenn man will, kann man diese Datei später auch direkt bearbeiten und sich den Weg über die jeweilige Oberfläche sparen. Für das erste Mal empfehle ich aber den einfachsten Weg über die Weboberfläche mit Setup > New Dbvisit Setup. Alles Weitere wird wirklich verständlich über alle notwendigen Eingaben abverlangt und Erläuterungen werden direkt bereitgehalten. Was uns geboten wird ist auf jeden Fall umfangreich. Wir können fast alle Details festlegen, zudem wird RAC unterstützt. Wir können Mail Settings für die Alarmierung festlegen und das Archive-Log-Management auf beiden Seiten bis ins kleinste anpassen. Mit dem notwendigen Datenbank Know-how und Englischkenntnissen bleiben wirklich selten Fragen offen, die sich nur durch testen beantworten ließen. Im Zweifel hält Dbvisit einen frei zugänglichen und umfangreichen „Administrations Guide“ online bereit oder Sie Fragen mich, ich beantworte Ihre Fragen gerne.
Wenn die sieben Schritte der Konfiguration durchlaufen sind, und das DDC File erfolgreich erzeugt ist, kann es dann auch direkt mit der Erstellung der Standby Datenbank weiter gehen. Das ist schneller erledigt als die Konfiguration, die Sie für eine Quell-Datenbank auch nur einmal anlegen müssen und im Zweifel anpassen. Auch die Standby Erstellung können Sie bequem über die Web-GUI vornehmen über Setup > Create Standby Database. Dbvisit übernimmt die Arbeit im Hintergrund. Hier haben Sie nun die Möglichkeit Ihre Daten für den Transfer komprimieren zu lassen, oder Sie können diese auch erst auf ein externes Medium laden und separat einspielen, wenn Sie Ihr Netzwerk nicht belasten wollen. Abschließend können Sie noch das Parameterfile feingranular nach Ihren Bedürfnissen anpassen und beispielsweise File-Destinations umsetzen, NLS Parameter ändern, oder, oder, oder. Den Rest übernimmt Dbvisit und stellt Ihnen bis zum Mount eine Standby Datenbank bereit.
Was jetzt noch bleibt ist Festzulegen wie häufig die Standby Datenbank mit der Produktion abgeglichen werden soll. Dazu sollten Sie wissen wie Dbvisit an dieser Stelle arbeitet. Zunächst erstellt Dbvisit aus den vorhandenen (archivierten) Redo-Log Informationen (daher die Notwendigkeit des Archive-Log-Modus) eigene, komprimierte Archive-Logs, diese werden dann ganz einfach über das Netzwerk zum Ziel-Server verschoben. Auf dem Ziel-Server werden diese Redo-Logs dann dekomprimiert, eingespielt bzw. appliziert (Englisch: applied). Daraus ergibt sich ein TRANSFER Prozess auf der Quell-Seite und ein APPLY Prozess auf der Ziel-Seite. Je nachdem wie oft man nun eines der beiden oder beides macht, belastet man nun auch das Netzwerk und die Datenbank mehr oder weniger stark. Die häufigste Empfehlung von der man im Umfeld von Oracle Standby Datenbanken liest, das betrifft nicht nur Dbvisit, liegt im Übrigen bei 15 Minuten. Somit hat man also im Desaster-Fall 15 Minuten Datenverlust. Dafür sollte man aber in der ganzen Restlichen Zeit in der mal kein Desaster ansteht die Produktion performant weiter laufen können. Wenn das nicht reicht muss man natürlich auf seine Umgebung 10 oder gar 5 Minuten testen oder eben eine andere Lösung zur Hochverfügbarkeit suchen. Die Konfiguration dazu finden Sie unter Run > Set Schedules.
So das war’s dann oder? Natürlich haben wir noch einen entscheidenden Punkt vergessen. Den Graceful Switchover oder im schlimmsten Fall den Failover. Auch hier arbeitet Dbvisit zuverlässig. Vorausgesetzt man hat akkurat bei der Einrichtung gearbeitet und seine Standby als 1:1 Kopie (nicht nur für den Ernstfall) bereitgestellt. So kann man mit einem Graceful Switchover die Produktion während Wartungsarbeiten am Server oder generell im primären Rechenzentrum aufrecht erhalten. Der Switchover kann ebenfalls bequem über die Weboberfläche vorgenommen werden. Gesichert mit der Eingabe eines Unique-Keys auf Quell- und Ziel-Seite eingeleitet übernimmt den Rest Dbvisit. Nach ein paar Minuten kann die Produktion auf der ehemals Standby-Seite frei gegeben werden. Was hin geht muss auch wieder zurück gehen, und das tut es natürlich. Trotzdem empfehle ich das ganze Prozedere vorher zu testen und sich mit der Materie vertraut zu machen. Für den Ernstfall, also Ihre Produktions-Seite gibt es aus welchen Gründen auch immer nicht mehr, können Sie Ihre PHYSICAL STANDBY natürlich auch in eine PRIMARY verwandeln, per Web-GUI. The Show must go on.
Schließlich bietet uns Dbvisit auch noch sehr schön visualisierte Reportings über unsere Standby Konfiguration, sowie Transfer- und Sync-Status.
Einsichtnahme in die Log-Files wird uns per Web-GUI auch gewährt.
