Warum neue Hardware für Oracle nicht immer sinnvoll ist

Wenn Sie momentan eine Oracle DB in einer Standard Edition einsetzen und planen, diese zukünftig auf neue Hardware “umzuziehen“, kann dies ungeahnte Folgen für die Compliance haben.

Hier ein konkretes Beispiel:

Angenommen eine Oracle DB SE2 auf einem physischen Host (siehe Abbildung 1, linker Bereich) soll auf neuere Hardware umgezogen werden. Der neue Server besitzt zwei Sockel, die jeweils bestückt sind mit einem neuen Epyc Prozessor von AMD mit 32 Kernen (siehe Abbildung 1, rechter Bereich).

Frage: Laut Oracle dürfen Oracle DB SE2 auf Systemen mit bis zu zwei Sockeln eingesetzt werden. Also alles richtig gemacht?

Das Problem mit dem Kleingedruckten

Nicht ganz, denn im Kleingedruckten der Oracle Preisliste befindet sich folgende Einschränkung:

„When licensing Oracle programs with Standard Edition One, Standard Edition 2 or Standard Edition in the product name […], a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.“

https://www.oracle.com/assets/technology-price-list-070617.pdf

Übersetzt bedeutet dies: Bei der Lizenzierung von Oracle Programmen mit der Standard Edition One, Standard Edition 2 oder Standard Edition in der Produktbezeichnung […] wird ein Prozessor gleichwertig zu einem belegten Sockel gezählt; bei Multi-Chip-Modulen wird jedoch jeder Chip im Multi-Chip-Modul als ein belegter Sockel gezählt.

Doch zunächst mal eine Erläuterung, was überhaupt Multi-Chip-Module (MCM) sind: Das sind (im Sinne von Oracle) Prozessoren, deren Kerne sich auf mehrere Chips verteilen. In unserem Fall verteilen sich die 32 Kerne des Epyc Prozessors auf jeweils vier Chips (siehe Abb.1 die kleinen blauen Kästen innerhalb der CPU). Das heißt, der Prozessor ist nicht wie es scheint ein Modul, sondern dessen Rechenwerke sind auf mehreren physisch voneinander getrennten Chips untergebracht.

Für unser Szenario bedeutet dies, dass die Migration eine Incompliance verursacht, da von Oracle jedes einzelne Modul als eigener belegter Sockel angesehen wird. Bei den genannten Prozessoren wären das zwei Prozessoren mit jeweils vier Modulen, das ergibt laut Oracle acht belegte Sockel. Da die SE2 nur auf Systemen eingesetzt werden darf, die maximal zwei Sockel besitzen, liegt in dem Fall eine nicht lizenzierbare Nutzung der SE2 vor. In diesem Fall muss nach der deutlich teureren Enterprise Edition lizenziert werden. Dadurch entsteht eine Kostensteigerung von über 4300 % oder ein Compliancerisiko von ca. 1,5 Mio. US-Dollar (Listenpreis).

Die Problematik wird zusätzlich kompliziert, da

1. die Information, ob ein Prozessor ein MCM ist oder nicht, in den wenigsten Produktdatenbanken der Prozessorhersteller verzeichnet ist und
2. selbst wenn die Information vorliegt, dass der Prozessor ein MCM ist, dies immer noch nicht garantiert, dass die Anzahl der Module ebenfalls aufgeführt ist.

Diese Besonderheit der Oracle-Metrik ist leider in den wenigsten Oracle-Lizenzierungstools transparent umgesetzt oder überhaupt implementiert.

Fazit

Aus diesem Grund kann es in Zukunft häufig ungewollt zu einer Incompliance kommen, wenn Oracle DB Standard Editionen auf neue Hardware migriert werden. Daher ist es unerlässlich, vorher eine genaue Analyse der zu beschaffenden Hardware durchzuführen, um das Risiko einer falschen Lizenzierung zu minimieren.

Lesen Sie auch…

…den ersten Teil dieser Blogserie: Oracle(n) oder fundiert analysieren und

…den zweiten Teil dieser Blogserie: Oracle Virtualisierung mit Hard- und Softpartitioning.