Pressemeldung DBSentinel v2

Pressemeldung: DBSentinel – Die Standby-Datenbank-Lösung für alle Oracle Editions

Veröffentlicht auf: www.wallstreet-online.de , www.finanzen100.de , www.computerwelt.at

 

DBSentinel – Die Standby-Datenbank-Lösung für alle Oracle Editions
Einfache Lösung zum unschlagbaren Preis-Leistungs-Verhältnis

Wien (pts) – Mit den steigenden Anforderungen an die moderne IT-Infrastruktur können Ausfälle von Produktionssystemen sehr schnell zu kritischen Situationen führen, die für Unternehmen oft mit hohen Kosten verbunden sind. Zum Beispiel ein Wasserrohrbruch, aber auch “leichte Fälle” wie Leitungsbrüche oder Stromausfälle zeigen die Grenzen einer einzigen Server-Location auf. Je nach Schwere des Ausfalls kann die Wiederherstellung einer Datenbanksicherung tagelang dauern und für Unternehmen bedrohliche Auswirkungen haben. Doch oft scheuen – speziell kleinere – Unternehmen eine “out-of-the-box”-Lösung, wegen vermeintlicher hoher Kosten oder fürchten einen hohen Aufwand.

DBSentinel: Made in Austria – Bestes Preis/Leistungsverhältnis

Das IT-Unternehmen DBConcepts – http://www.dbconcepts.at – aus Wien, einer der führenden Oracle Experten in Österreich, wartete nun mit einer besonders attraktiven Lösung auf: DBSentinel ( http://www.dbsentinel.at ), die Oracle Hot-Standby Datenbank für alle Oracle Editionen. “Sie ist eine effektive und einfach zu administrierende Software-Lösung und weist vor allem wohl das derzeit beste Preis/Leistung Verhältnis am Markt auf”, hebt Peter Macek, Geschäftsführer von DBConcepts, hervor. DBConcepts gilt als anerkannter Spezialist auf dem gesamten Gebiet der Oracle-Infrastruktur.

Die preiswerte Hot-Standby-Lösung um einmalige €3.323,50 Euro exkl. MwSt.

Der DBSentinel ist die Hot-Standby-Lösung für Oracle XE, SEOne und SE Datenbanken. Pro Primary Servere (Quellserver) wird nur eine DBSentinel-Lizenz benötigt, ungeachtet der Anzahl von Instanzen, CPU´s und Standby Server. Bis zu zehn Standby-Datenbanken pro Primary Server sind dabei möglich. Der Support erfolgt in deutscher Sprache. Die einmalige unbefristete Lizenz ermöglicht hohe Einsparungen gegenüber herkömmlichen Lösungen. Peter Macek ist überzeugt: “Mit einem Lizenzpreis von €3.323,50 Euro exkl. MwSt. ist DBSentinel die Lösung mit dem derzeit besten Preis-Leistungs-Verhältnis am Markt.”

DBSentinel wurde mit dem Know How und unter dem Lead von DBConcepts in Kooperation entwickelt. “Die kostenlose, brandneue Trial Version von DBSentinel 2.0 ist ab sofort als Download erhältlich”, schließt Peter Macek.

Statische Listener-Registrierung

Um einen Switchover durchführen zu können, ist es (neben den ASM-Aliases für Redo-Logs) notwendig, die beteiligten Datenbanken statisch am Listener zu registrieren.

Bei der normalerweise üblichen dynamischen Listener-Registrierung meldet sich die Datenbank am Listener an, sobald sie gestartet worden ist; erst dann weiss der Listener über die Datenbank Bescheid und kann Remote-Zugriffe weiter reichen.

Damit ein Remote-Zugriff auch dann funktioniert, wenn die Datenbank nicht läuft (z.B. um die Datenbank aus der Ferne zu starten – was beim Switchover passiert), muss sie explizit dem Listener bekannt gemacht werden.

Eine dynamisch registrierte Datenbank mit dem Namen SENTEST sieht im Output von “lsnrctl status” folgendermassen aus:

[...]
Service "SENTEST" has 1 instance(s).
  Instance "SENTEST", status READY, has 1 handler(s) for this service...
[...]

Um diese Datenbank statisch am Listener zu registrieren, ist ein Eintrag im File $ORACLE_HOME/network/admin/listener.ora nötig:

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (ORACLE_HOME=/opt/oracle/app/product/11.2.0/db_1)
      (SID_NAME=SENTEST))
  )

Passen Sie dabei den Pfad für das ORACLE_HOME Ihrem Setup entsprechend an.

Falls Sie mehr als eine Datenbank statisch registrieren möchten, erweitern Sie die Liste einfach:

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (ORACLE_HOME=/opt/oracle/app/product/11.2.0/db_1)
      (SID_NAME=SENTEST))
    (SID_DESC=
      (ORACLE_HOME=/opt/oracle/app/product/11.2.0/db_1)
      (SID_NAME=SENPROD))
  )

Nach einem Neu-Einlesen des Config-Files mittels “lsnrctl reload” zeigt “lsnrctl status” nun die statisch registrierte Datenbank (zusätzlich) an:

Service "SENTEST" has 2 instance(s).
  Instance "SENTEST", status UNKNOWN, has 1 handler(s) for this service...
  Instance "SENTEST", status READY, has 1 handler(s) for this service...

Die Instanz mit Status “READY” ist die aktuell laufende, die sich dynamisch am Listener registriert hat; die statisch registrierte wird immer als “UNKNOWN” angeführt.

Falls Sie einen RAC einsetzen, müssen Sie beachten, dass der Listener hier üblicherweise im Grid Environment läuft; das zu bearbeitende Config-File liegt also in $GRID_HOME/network/admin, und auch lsnrctl muss aus dem Grid Environment gestartet werden.

ASM-Aliases für Redo-Logs

Falls Sie ein DBSentinel-Setup mit zwei Oracle-Datenbanken auf ASM betreiben und vorhaben, einen Switchover zwischen Primary- und Standby-Datenbank durchzuführen (“Rollentausch”), ist es zwingend erforderlich, dass die Redo-Logs der Primary-Datenbank mit ASM-Alias-Dateinamen angesprochen werden.

Da üblicherweise bei einer Standard-Datenbankinstallation für die Redo-Logs “system generated filenames” vergeben werden, müssen Sie Ihre Redo-Logs umbenennen und dabei explizit ASM-Alias-Dateinamen verwenden. Am einfachsten geht das, indem Sie neue Redo-Logs bzw. Redo-Log-Gruppen anlegen und die alten Redo-Logs droppen.

Finden Sie zunächst heraus, wieviele Redo-Log-Gruppen in Ihrer Datenbank vorhanden sind, wieviele Logfiles es pro Gruppe gibt und wie groß diese sind:

SQL> select group#, thread#, members, bytes from v$log;

    GROUP#    THREAD#    MEMBERS      BYTES
---------- ---------- ---------- ----------
         1          1          2   52428800
         2          1          2   52428800
         3          2          2   52428800
         4          2          2   52428800

Legen Sie nun für jede vorhandene Gruppe eine neue Gruppe an – passen Sie dabei die ASM-Alias-Namen an Ihre Diskgroups an (inkl. Verteilung der Logs einer Gruppe auf mehrere Diskgroups), verwenden Sie freie Gruppennummern und achten Sie auf die Thread-Zuweisung und die Größe:

SQL> alter database add logfile thread 1 group 5 ('+DG_REDO1/redo1_1_1.log', '+DG_REDO2/redo1_1_2.log') size 52428800;

SQL> alter database add logfile thread 1 group 6 ('+DG_REDO1/redo1_2_1.log', '+DG_REDO2/redo1_2_2.log') size 52428800;

SQL> alter database add logfile thread 2 group 7 ('+DG_REDO1/redo2_1_1.log', '+DG_REDO2/redo2_1_2.log') size 52428800;

SQL> alter database add logfile thread 2 group 8 ('+DG_REDO1/redo2_2_1.log', '+DG_REDO2/redo2_2_2.log') size 52428800;

Erzwingen Sie einige Logswitches, indem Sie die folgende Anweisung mehrere Male durchführen, um die neuen Redo-Logs in Verwendung zu nehmen:

SQL> alter system archive log current;

Überprüfen Sie den Status der Redo-Log-Gruppen:

SQL> select group#, thread#, archived, status from v$log;

    GROUP#    THREAD# ARC STATUS
---------- ---------- --- ----------------
         1          1 YES ACTIVE
         2          1 YES ACTIVE
         3          2 YES ACTIVE
         4          2 YES ACTIVE
         5          1 NO  CURRENT
         6          1 YES INACTIVE
         7          2 YES INACTIVE
         8          2 NO  CURRENT

Erzwingen Sie weitere Logswitches bzw. warten Sie, bis die alten Log-Gruppen als “INACTIVE” angezeigt werden, und droppen Sie diese dann:

SQL> alter database drop logfile group 1;
SQL> alter database drop logfile group 2;
SQL> alter database drop logfile group 3;
SQL> alter database drop logfile group 4;

Falls die Datenbank die Logfiles noch nicht droppen kann (weil sie noch in Verwendung sind), liefert sie einen ORA-01623 bzw. ORA-01624 Fehler, und Sie müssen noch warten oder weitere Logswitches durchführen, bis die Datenbank die Logfiles freigibt.

Am Ende sollten Sie wieder die gleiche Anzahl an Redo-Log-Gruppen haben wie am Beginn des Umbaus.

Mit folgender Abfrage können Sie noch prüfen, ob die neuen Logfiles tatsächlich die richtigen Alias-Namen haben:

SQL> select member from v$logfile;

MEMBER
--------------------------------
+DG_REDO1/redo1_1_1.log
+DG_REDO2/redo1_1_2.log
+DG_REDO1/redo1_2_1.log
+DG_REDO2/redo1_2_2.log
+DG_REDO1/redo2_1_1.log
+DG_REDO2/redo2_1_2.log
+DG_REDO1/redo2_2_1.log
+DG_REDO2/redo2_2_2.log

DBSentinel Präsentation am Speed & Uptime Business Breakfast

Save the Date

Gemeinsam mit Oracle Österreich lädt DBConcepts Sie herzlich zum kostenlosen Speed & Uptime Business Breakfast ein.

Lernen Sie bei einem ausgedehnten Frühstück in entspannter Atmosphäre die brandneue Oracle Database Appliance (ODA) sowie die neue Version 2.0 des DBSentinel kennen.
Das “Speed und Uptime” Business Breakfast findet an folgenden Terminen bzw Locations statt:

20. März 2012, Dornbirn, Four Points Panoramahaus Dornbirn
21. März 2012, Innsbruck, Hotel Ramada Innsbruck Tivoli
23. März 2012, Graz, Hotel Süd
29. März 2012, Wien, Business Base CITYPORT11
17. April 2012, Linz, Hotel Harry´s Home

Alle weiteren Details und die Anmeldung finden Sie auf der Webseite von DBConcepts.

Bitte melden Sie sich so bald wie möglich an, an manchen Locations werden die Plätze bereits knapp.

Wir freuen uns, Sie bei dieser Veranstaltung persönlich begrüßen zu dürfen!

Was benötigt der DBSentinel?

DBSentinel Version 2.x ist ab Oracle 11g R2 verfügbar. Die Primary und Standby Datenbanken müssen über eine identische Architektur, Plattform , Oracle Edition und Version verfügen. Zusätzlich werden auf allen Servern Java >= 1.6 und der Oracle Listener benötigt.
Darüber hinaus sind keine zusätzlichen Voraussetzungen erforderlich.