Leb wohl RAC! Hochverfügbarkeit in der Oracle 19c SE2

Mit Version 19c hat Oracle die Real Application Cluster (RAC) Option aus der Standard Edition 2 genommen. Ein solches Vorgehen hatte sich im Vorfeld bereits angekündigt, da mit der Standard Edition 2 die Anzahl der erlaubten Threads pro Knoten auf 8 beschränkt wurde. Damit war ein 2-Knoten-RAC-System, bedingt durch den verwaltungstechnischen Overhead, bereits weniger leistungsfähig als ein vergleichbares Single Instance System, das auf 16 Threads limitiert ist.

Viele Anwender setzten in der Vergangenheit, wenn es um Hochverfügbarkeit ging, genau auf den Einsatzes der RAC Option. Für die Zukunft entfällt diese Möglichkeit ersatzlos. Oracle bietet, im Gegensatz zu Dataguard in der Enterprise Edition, in der Standard Edition 2 keinerlei auch nur annähernd ähnliche Option an.

Was nun?

Da der Anwender auf interne Mechanismen, die Dataguard verwendet, nicht zugreifen kann bzw. darf, bleibt nur die altbewährte Methode: die Verwendung eines Standby Systems, basierend auf der Oracle Backup/Recovery-Technologie. Eine solche Implementierung wird als physikalische Replikation bezeichnet.

Ein solches System kann durch selbstgeschriebene Skripte realisiert werden. Der Aufwand steht in keinem Verhältnis zum Nutzen.

Ein Partner von uns bietet ein Produkt an, das genau in diese Bedarfslücke passt und mit dem ich in diesem Umfeld schon sehr gute Erfahrungen machen durfte.  Dbvisit Standby ist eine einfach zu bedienende Lösung , um eine effiziente und zuverlässige Hochverfügbarkeit in der Oracle Standard Edition 2 abzubilden. Zudem kann Dbvisit Standby, im Gegensatz zu einem RAC System, sowohl über weite Entfernungen, als auch ganz oder teilweise als hybride Lösung in der Cloud implementiert werden.

Mit Dbvisit Standby kann mittels eines sog. Switchover vom Primärsystem auf das Standbysystem innerhalb weniger Minuten ohne Datenverlust umgeschaltet werden. Es erfolgt ein Rollentausch beider Systeme.

Im Katastrophenfall, d. h. falls das Primärsystem durch äußere Einflüsse oder auf Grund von Hard- bzw. Softwareproblemen nicht mehr verfügbar sein sollte, kann durch das Aktivieren des „überlebenden“ Standby Systems ein Weiterbetrieb der Datenbank mit einem geringen Datenverlust (in der Regel weniger als 5 Minuten) gewährleistet werden.

Wenn in Oracle 19c Standard Edition 2 eine Hochverfügbarkeit weiterhin gewährleistet werden soll, ist Dbvisit Standby eine einfache und kostengünstige Lösung.

Falls Sie Interesse an einer Demo oder eine testweisen Implementation von Dbvisit Standby haben, kommen Sie gerne auf mich zu.

5 thoughts on “Leb wohl RAC! Hochverfügbarkeit in der Oracle 19c SE2”

  1. Mit Dbvisit Standby haben wir auch schon sehr gute Erfahrungen in diversen Projekten gemacht. Es ist ein wirklich ein ausgereiftes und robustes Produkt und eine Oracle Standby-Umgebung auszubauen.

    Wer dennoch weiterhin ein Oracle Cluster mit SE2 19c nutzen möchte, könnte alternativ auch einen Single Instance Failover Cluster statt RAC nutzen. Eine Implementation habe ich in meinem Blog-Artikel unter https://frankgerasch.de/2019/05/oracle-se2-im-cluster-es-geht-auch-ohne-rac/ beschrieben.

  2. Hallo Herr Gerasch,

    Danke für die Anmerkung! Schön, wenn das Thema ein wenig tiefer diskutiert werden kann!

    Ja, ein Hot/Cold Standby System ist sicher eine bedenkenswerte Alternative.

    Vorteil: es wird keine Lizenz für das Standbysystem benötigt, solange die „10 Tage“ Regel eingehalten wird. Das bedeutet, dass das Standbysystem nicht mehr als 10 Tage im Jahr in Betrieb sein darf (jeder angefangene Tag zählt!).

    Nachteil: da, wie beim RAC auch, ein gemeinsames Plattensystem benutzt wird, besteht hier ein SIngle Point of Failure. Das System ist daher nicht Disaster-Recovery-fähig.

    VG Rainier Kaczmarczyk

    1. Hallo Herr Kaczmarczyk,

      wenn man das Ganze als Extended Distance Cluster realisiert, sprich mit zwei separaten Storage-Arrays, die mittels ASM gespiegelt werden, besteht kein Single Point of Failure mehr. Leider lässt sich die 10-Tage-Regel aufgrund der Lizenzrestrikionen wegen der Spiegelung des Storage-Arrays dann nicht mehr anwenden. Dieses Modell empfiehlt sich also insbesondere, wenn man mehr als 1 Datenbank absichern möchte. Dann kann man die zweite Datenbank auf dem 2-Knoten laufen lassen und dessen Ressourcen bleiben nicht ungenutzt.

      Ich finde, dass beide Lösungen ihre jeweiligen Vor- und Nachteile haben und der Einsatz immer zusammen mit den Anforderungen und Möglichkeiten der Auftraggeber erörtert werden muss. Ich persönlich habe mit beiden Lösungen gute Erfahrungen machen können!
      Vielleicht kann man ja mal einen Blog-Beitrag „DBVisit Standby vs Single Instance Extended Distance Cluster“ machen, falls dies noch von keinem anderem germacht worden ist. Wenn ich in den nächsten Wochen Zeit finde, kann ich hier ja mal eine Gegenüberstellung in meinem Blog posten – Kommentare willkommen 🙂

      VG
      Frank Gerasch

      1. Hallo Herr Gerasch,

        Sie haben absolut Recht: es gibt sie nicht, die 100% Lösung. Jede hat ihren eigenen Charme. Deshalb machen solche Diskussionen auch soviel Spaß!

        Nur eins: die Spiegelung ist ja nichts anderes als quasi ein RAID 1 System. Wenn auf die eine Seite des Spiegels ein Fehler geschrieben wird, landet dieser auch auf der anderen. Das meinte ich mit Single Point of Failure.

        Und: ich freue mich schon auf Ihren Artikel!

        VG
        Rainier Kaczmarczyk

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

%d Bloggern gefällt das: