Mit Veröffentlichung des Oracle Datenbank Release 19c schlug die Abkündigung der Oracle RAC und Oracle RAC One Node Funktionalität für die Standard Edition Two (My Oracle Support Note 2504078.1) bereits hohe Wellen. Mittlerweile ist der Aufregung Ernüchterung gefolgt und gerade mit Blick auf die Oracle Database Release und Support Timeline gilt es nun zu handeln.
Für alle 11g RAC Infrastrukturen kann man sich mit einem Update auf das Release 12.1.0.2 – verbunden mit der Option des aufschlagspflichtigen Extended Supports – zumindest eine Fristverlängerung für eine supportete Infrastruktur bis Ende Juli 2022 erkaufen! Allerdings ist dabei zu beachten, dass der RAC dann nur noch mit maximal zwei CPUs, verteilt auf zwei Nodes (mit jeweils max. zwei CPU Sockets und einer gesteckten CPU pro Node) betrieben werden darf.
Möchte man darüber hinaus nicht auf die Vorteile des Real Application Clusters verzichten – Stichwort Lastverteilung (CPU-Last und RAM-Anforderung, nicht I/O) oder der insgesamt höheren Verfügbarkeit und Ausfallsicherheit – ist man mit 19c gezwungen, die Oracle Database Enterprise Edition zu nutzen. Geht man diesen Schritt, ist in jedem Fall die Beschaffung der Oracle DB Enterprise Edition Lizenzen und der kostenpflichtigen RAC Option erforderlich.
Wem der Weg in die Oracle Enterprise Edition zu teuer ist, dem bleibt nur, sich noch einmal mit den grundsätzlichen Anforderungen an die Datenbankinfrastruktur auseinanderzusetzen und bestehende Best Practice Lösungen für SE2 unter den Gesichtspunkten Verfügbarkeit, Skalierbarkeit und Performance zu evaluieren.
Ehrlicherweise ergeben sich aber nur Alternativen im Hinblick auf die Verfügbarkeit, sind doch Überlegungen zu Skalierbarkeit und Performance allein schon durch die technische Limitierung der Standard Edition Two auf die Nutzung von max. 16 CPU Threads pro Datenbankinstanz und der nun abgekündigten RAC Funktionalität obsolet.
Allerdings gibt es einige Optionen für eine hochverfügbare Oracle Datenbank Architektur. Für On Premise wären dies sowohl der bewährte Failover Cluster als auch die Standby Datenbank Architektur – beispielsweise mit Dbvisit Standby. Letztere ist übrigens praktikabel auch mit einer Hybridinfrastruktur (On Premise / Cloud) realisierbar. Alternativ zu On Premise besteht selbstverständlich auch die Möglichkeit, gleich komplett auf die hohe Verfügbarkeit eines Database Cloud Services, beispielsweise von Oracle, Microsoft Azure und Amazon AWS oder EC2 zurückzugreifen.
Und wenn man sich schon einmal mit der Zukunft beschäftigt und es seitens des Anwendungsherstellers keine Einwände geben sollte:
PostgreSQL bietet nahezu alle Funktionalitäten für Availability, Performance und Security im Rahmen der GPL-Lizenz kostenfreien Community Edition. Für den professionellen Support der geschäftskritischen PostgreSQL Datenbanken steht euch die ASPICON in gewohnter Art und Weise zur Verfügung.
Gern sind unsere Spezialisten sowohl bei der Planung und Umsetzung deiner Datenbankinfrastrukturprojekte behilflich. Solltest du weitere Fragen haben oder Unterstützung bei der Konzeptionierung und Umsetzung benötigen, zögere nicht, dich gleich mit uns in Verbindung zu setzen.
Share this article