Keine Zwischen-/Innovation-Releases der Oracle DB mehr für IBM-Kunden

Mit Neuordnung der DB-Releases und Nummerierung deselben hat Oracle vor ein paar Jahren eingeführt, dass es sogenannte „Innovation Releases“ (Zwischenreleases) mit relativ kurzer Supportlaufzeit gibt, und sogenannte LongTerm-Releases mit der üblichen Supportlaufzeit von 5 Jahren plus 3 Jahren Extended Support-Möglichkeit.

Innovation Releases der DB sind die 18c, die 21c, die 22c, 24c (oder welcher Buchstabe dann modern ist), 25, ….
LongTerm-Releases sind bspw. die 19c und 23c.

Mit der MyOracleSupport Note … hat Oracle nun angekündigt, dass Nutzer der IBM Power Systems mit AIX und Kunden mit IBM Z Systemen keine Innovation Releases mehr bekommen werden, sondern nur noch die LogTerm-Releases.

Siehe MyOracleSupport Doc ID 2766930.1 (Account für MyOracleSupport erforderlich)

Vielen Dank an meinen Kollegen Christian Ballweg für den Hinweis!

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , | Kommentar hinterlassen

Preissenkung bei Oracle (Tech-Produkte)

Soeben habe ich die neue ab 01.06.2021 gültige Tech-Preisliste von Oracle erhalten.

Aufgrund von Wechselkursanpassungen wurden die Preise aller Produkte um ca. 5% gesenkt!

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Oracle Segregation-Approval / VLAN-Approval – aktuelle FAQ

Nachdem immer wieder irritierende Aussagen von Kunden, DOAG-Mitgliedern und auch Oracle-Mitarbeitern mich erreichen, möchte ich den aktuellen Kenntnisstand zum Oracle VLAN-Approval (auch Segregation Approval oder Reconfiguration-Approval genannt) in einem FAQ-Dokument zusammenfassen:

F: Was ist das Segregration-Approval ?

A: Oracle beurteilt VMware-Virtualisierung als Softpartitioning (siehe Oracle Partitioning Policy (https://www.oracle.com/assets/partitioning-070609.pdf)). Ferner ist nach der Oracle-Bewertungslogik die gesamte Hardware einer VMware-Umgebung zu lizenzieren, auf die eine VM mit Oracle-Produkt zur Laufzeit hin verschoben werden kann. Da mit VMware 6.0 und höher eine VM sogar über vCenter-Grenzen hinweg verschoben werden könnte, wären theoretisch alle ESX-Hosts aller VMware-Umgebungen des Kunden mit Version 6.0 und höher zu lizenzieren. Ferner hat Oracle zu dem Zeitpunkt der Bekanntgabe, dass nicht mehr nur das VMware-Cluster lizenziert werden muss, die Sichtweise auch auf Shared Storages erweitert und festgelegt, dass alle VMware-Umgebungen lizenziert werden müssen, die an einem SAN hängen, wenn auf einer dieser Umgebungen sich Oracle-Produkte befinden. Da diese beiden Ankündigungen verständlicherweise nicht auf Akzeptanz bei Kunden gestoßen ist, hat Oracle das VLAN-Approval eingeführt, das dann zum Segregation Approval erweitert wurde.

F: Aber ich kann doch in VMware DRS Host Affinity Rules definieren um das Verschieben auf bestimmte Server zu begrenzen oder auch vSphere CPU Affinity konfigurieren um nur eine begrenzte Anzahl von Cores in einem Server für eine VM zu nutzen.

A: Das ist zwar technisch möglich, ABER es wird von Oracle lizenztechnisch nicht anerkannt. Was immer wieder die Diskussionen erschwert, ist die Tatsache, dass VMware genau dies in ihrem Whitepaper (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/understanding_oracle_certification_support_licensing_vmware_environments-white-paper.pdf) seit 2015 behauptet. Allerdings ist dies die Ansicht von VMware, die von Oracle LMS (neuer Name GLAS (Global Licensing and Advisory Services)) nicht bestätigt wird.

F: Die Oracle Allgemeinen Vertragsbedingungen (OLSA, OMA, TOMA), enthalten oder verlinken auf die Definitionen, und dort ist der Prozessor definiert als „Prozessor bezeichnet alle Prozessoren, auf denen die Oracle Programme installiert sind und/oder ablaufen.“ Da steht nichts von „könnte ablaufen“ oder „könnte dahin verschoben werden“. OMA bzw. TOMA und früher OLSA ist doch neben der Rechnung die einzige vertragliche Basis, die zwischen Oracle und dem Kunden besteht. Wie kommt Oracle also dazu, hierzu erweiterte Regeln einzuführen?

A: Das kann leider nicht eindeutig beantwortet werden. Zu Beginn der Nutzung von Virtualisierung (vor allem VMware) unterhalb von Oracle-Produkten hat Oracle die oben beschriebene Sichtweise festgelegt, dann 2014 anhand der erweiterten Verschiebe-Möglichkeiten von VMware ebenfalls erweitert und beharrt seitdem darauf. Demgegenüber kommen auch die beiden Gutachten, die die Deutsche Oracle Anwendergruppe (DOAG) hierzu hat erstellen lassen, zu dem Schluss, dass Oracle Sichtweise der Lizenzierung nicht mit der vertraglichen Grundlage zusammenpasst. Gleiches gilt für das von der Österreichischen Oracle User Group (AOUG) erstellte Gutachten. Da es hierzu aber weltweit noch kein Gerichtsurteil gibt, das dieses abschließend geklärt hat, gibt es daher noch keine endgültige Rechtsprechung, so dass die Sichtweise von Oracle der der Kunden entgegensteht.

F: Was kann ich als Kunde denn nun tun?

A: Grundsätzlich gibt es zwei Wege: den konfrontativen und den kooperativen Weg. Der konfrontative Weg bedeutet, dass man sich auf den Standpunkt stellt, man lizenziert nur die genutzten Prozessoren, und Oracle soll doch versuchen, seine vermeintlichen Ansprüche durchzusetzen. Dies wird im englischsprachigen Raum und auch von niederländischen Lizenzberater Daniel Hesselink stark propagiert. Man muss sich dabei aber im Klaren sein, dass man sich – salopp ausgedrückt – dann mit Oracle in einem kriegsähnlichen Zustand befindet, dieses aushalten wollen und können, das Unternehmen intern entsprechen instruieren (z.B. Single Point of Contact, etc.) und genauestens loggen, wann Oracle wo genau in Betrieb war. In Deutschland wird daher eher der kooperative Weg eingeschlagen, und der wiederum bedeutet die Nutzung des Segregataion-Approvals, womit wir wieder beim eigentlichen Thema dieses FAQ wären.

F: Na endlich. Was ist denn nun das VLAN-Approval ?

A: Immer mit der Ruhe. Es muss ja auch der Hintergrund erläutert werden, damit das Problem verstanden wird. Im Gespräch mit Andrew Mendelsohn, Executive Vice President for Database Server Technologies bei Oracle, während der DOAG Konferenz 2015 wurde von ihm als Ausweg aus dem VMware-Lizenzierungsdilemma das VLAN-Approval erstmal hier in Deutschland erwähnt. Es bedeutet, dass man auf Netzwerkebene (!!!) VLANs definiert, diese von der VMware-Umgebung aus nutzt und somit ein Verschieben der VMs mit Oracle-Produkten außerhalb des per VLAN „eingezäunten“ Bereichs verhindert. Als Ergebnis braucht man dann nur die Prozessoren der ESX-Hosts zu lizenzieren, die sich in dem „einzäunenden“ VLAN befinden. Als Grenze wird meist das VMware-Cluster per VLAN abgetrennt. Zusätzlich betrachtet man dann auch das Storage. Hier muss man mit geeigneter Trennung (z.B. LUN-Zoning, NTFS-Mounts, etc.) dafür sorgen, dass der von/für Oracle genutzte Bereich des Storage nur von dem Oracle-Cluster gesehen werden kann und nicht von anderen VMware-Clustern. Dies beides (Netzwerk UND Storage) muss man entsprechend konfigurieren und zusammen mit einer Architekturskizze, erläuterndem Text und entsprechend beweisenden Screenshots in einem englischsprachigen Dokument dokumentieren. Dieses Dokument muss man dann beim Oracle-Vertrieb einreichen um das VLAN-Approval zu erlangen.

F: Und was ist dann das Segregation Approval ?

A: Nach einigen Monaten hat Oracle die Anzahl der möglichen Trennungstechnologien erweitert. Anstatt VLANs zu nutzen, kann man bspw. auch eine Firewall entsprechend platzieren und konfigurieren, die das Verschieben von VMs mit Oracle aus dem definierten Bereich verhindert, das Migration Netzwerk weglassen o.Ä.. Die Art der Trennung muss aber immer auf Netzwerkebene erfolgen, nicht nur in der VMware-Konfiguration. Da nun auch andere Trennungsarten als VLAN genehmigt werden können, wurde der Name von VLAN-Approval zu Segregation-Approval (manchmal auch Reconfiguration-Approval) geändert. Umgangssprachlich und auch hier in diesem FAQ werden Segregation-, Reconfiguration- und VLAN-Approval synonym benutzt.

F: OK, also hat man eine Vorgabe, was man tun muss um dann compliant zu sein (vorausgesetzt man hat ausreichend Lizenzen) ?

A: Leider nein. Es ist jedes mal eine Einzelgenehmigung, die zwischen dem Endkunden und Oracle getroffen wird. Daher wird das Segregation-Approval von vielen Beratern bedingt kritisch gesehen, weil man damit implizit dem Ansinnen von Oracle, abweichend von der vertraglichen Regelung zu lizenzieren, implizit zustimmt. Und auch aus Sicht der DOAG ist das leider nur ein Workaraound. Den aber seither viele Kunden in Anspruch genommen haben, weil sie damit bei den Vorteilen der VMware-Nutzung bleiben können und das Lizenzierungsthema damit einigermaßen im Griff ist.

F: Was wären denn Alternativen ?

A: Wenn man nicht den oben beschriebenen konfrontativen Weg gehen möchte, bleiben als Alternativen zum VLAN-Approval nur der Wechsel auf Blech, der Wechsel auf einen anderen Hypervisor für entweder den Oracle-Workload oder den Nicht-Oracle-Workload (was zumindest so lange funktioniert wie ein Verschieben von bspw. VMware zu HyperV zur Laufzeit nicht möglich ist), der Wechsel in die Cloud oder die Lizenzierung der Nicht-Oracle-Umgebungen mit sogenannten „passiven“ Lizenzen. Diese passiven Lizenzen sind extrem hoch rabattierte Oracle-Lizenzen, auf denen dann auch kein Oracle laufen darf, sondern die nur die Nicht-Oracle-VMware-Umgebungen legalisieren. Man kann aus dem Geschriebenen schon die Widersinnigkeit erkennen, und so rate ich von dieser Lösung „passive Lizenzen“ ab, denn hier muss man bei jeglicher Änderung im Nicht-Oracle-VMware-Bereich die Lizenzierung bzgl. der passiven Lizenzen beachten und ggf. nachkaufen.

F: Was kostet denn das Segregation- bzw. VLAN-Approval ?

F: Eigentlich nichts. Oracle (namentlich Andy Mendelsohn und auch Paul Wehner (Leiter der Systemberatung in Deutschland)) betont immer wieder, dass es keine Vorschrift bei Oracle gebe, dass das VLAN-Approval was kosten muss. Allerdings haben in der Vergangenheit die Oracle-Vertriebler die Erteilung des VLAN-Approvals an einen Cloud- oder Lizenzkauf gebunden um die dafür verwendete Arbeitszeit über den Umweg vergütet zu bekommen. Da es hierfür keinen einheitlichen Preis gab, sondern dieser vom jeweiligen Vertriebler anhand seiner persönlichen Einschätzung festgelegt wurde, wirkte dies doch sehr nach „Gutsherrenart“ und führte in der Praxis zu einer Bandbreite von „das bekommt der Kunde ‚für umme‘, weil der hat noch einen gut bei mir“ bis hin zu „das bekommt der Kunde gar nicht weil…“. Oder man konnte sich schlicht nicht einigen, weil der Kunde nichts brauchte und daher nichts kaufen wollte, der Oracle-Vertrieb aber trotzdem auf kompensierenden Umsatz bestanden hatte. Insgesamt also eine sehr unglückliche Situation, die sich aber inzwischen bessert.

F: Wie ? Das Segregation-Approval kostet nichts mehr?

A: Jein…. Hier muss man unterscheiden: der direkte Oracle Vertrieb ist ja grob in zwei Bereiche unterteilt: größere Kunden werden vom sogenannten „Feld“-Vertrieb betreut, die anderen Kunden werden von „Oracle Direct“ aus Amsterdam betreut. Zumindest aus dem Feld-Vertrieb hört man, dass seit Sommer 2020 die Bearbeitung des VLAN-Approvals nicht mehr mit einem kompensierenden Geschäft verbunden sein muss. Und auch aus Amsterdam sind erste Tendenzen in diese Richtung wahrzunehmen.

F: OK. Nehmen wir nun an, wir haben unser VMware-Cluster entsprechend abgetrennt, beim Storage die entsprechende Trennung konfiguriert und das Ganze dokumentiert und bei Oracle eingereicht. Was ist denn das Approval ?

A: Das Approval meint eigentlich den internen Genehmigungsprozess bei Oracle. Ein Oracle-intern genehmigtes Approval nützt dem Kunden erstmal noch gar nichts. Er braucht eine vertragliche Regelung um sich dann darauf berufen zu können. Hier empfehle ich dringend, dass darauf geachtet wird, dass in der vertraglichen Regelung die Genehmigungen sich auf alle vorhandenen Lizenzen beziehen und dass das idealerweise auch für zukünftig zu beschaffende Lizenzen geht. Aus meiner Sicht ist am besten, wenn zwischen Oracle und dem Kunden ein Oracle Master Agreement (OMA) unterzeichnet wird, an den dann per Amendment die vertragliche Regelung des Segregation Approvals (manchmal auch Segregation Clause genannt) gehängt wird. Da der OMA nach Abschluss 5 Jahre gültig ist (auf 10 Jahre verlängerbar), können zukünftige Lizenzkäufe auf Basis des OMA erfolgen, so dass diese zukünftig beschafften Lizenzen dann auch der Segregation Clause unterliegen.

F: Und wie lange ist das gültig ?

A: Für die in der vertraglichen Genehmigung (evtl. per Nennung der CSI-Nummern) genannten Lizenzen bzw. für die Lizenzen, die auf Basis eines OMA mit Segregation-Clause Amendment beschafft werden, gilt das Approval theoretisch unbefristet bzw. bis zu einer zwischen Oracle und dem Kunden abgeschlossenen neuen vertraglichen Basis.

F: Wann benötigt man denn ein Re-Approval?

A: Hier wurde zumindest in der Vergangenheit viel Unfug erzählt um Kunden vom Segregation-Approval abzuschrecken und lieber stattdessen eine ULA (Unilimited License Agreement) zu verkaufen. So wurde gerne behauptet, dass bei jeglicher Änderung (Server hinzu, Versionswechsel vSphere, neue Netzwerk-Switche, …) ein Re-Approval nötig sei. Das ist Unfug! Der reine Approval-Text ist so abstrakt, dass dort bei einem Approval auf VLAN-Trennung sinngemäß nur drinsteht, dass der Kunden eine Separierung auf Netzwerkebene mittels VLANs vornimmt, die die VMs, auf denen Oracle-Programme ablaufen, auf einen bestimmten Bereich isoliert, und dass die Migration von VMs nur auf die Server beschränkt ist, aus denen das VLAN besteht. Bzgl. Storage ist nur formuliert, dass durch Storage Segregation Technologie der Speicherbereich mit Oracle-Programmen von anderen Servern außer denen im VLAN nicht zugreifbar ist. Daraus ergibt sich, dass ein Re-Approval nur notwendig ist, wenn die Art der Trennung grundlegend geändert wird. Also wenn man bspw. von der VLAN-Trennung zur Trennung mittels Firewall wechselt. Analog beim Storage: wenn man bspw. LUN-Zoning im VLAN-Approval genehmigt bekommen hat, und man auf NTFS-Mounts umstellt, benötigt man ein Re-Approval. Aber nicht wenn man die NetApp gegen eine EMC austauscht, grundsätzlich aber beim LUN-Zoning bleibt.

F: Also braucht man kein Re-Approval, wenn man Server austauscht, Server hinzufügt, Betriebssystem-Versionen oder VMware-Versionen ändert, die Switche austauscht etc.?

A: nein. Man muss natürlich eine analoge VLAN-Konfiguration auf dem neuen Switch vornehmen. Und natürlich müssen entsprechende Lizenzen vorhanden sein, wenn man das abgetrennte Oracle.-Cluster vergrößert indem Server hinzugefügt oder gegen Server mit mehr Prozessoren/Cores getauscht werden.

F: Wie gesichert ist diese Aussage ?

A: Wie leider üblich, findet man solche Detailinformationen nicht bei Oracle, da Oracle sowas nicht veröffentlicht. Aber die Aussagen bzgl. des Re-Approvals wurden in meinem Beisein von einem LMS/GLAS-Mitarbeiter Kunden gegenüber getätigt.

F: Betrifft das eigentlich nur VMware ?

A: Nein. Da VMware generell sowie auch bei den Oracle-Nutzern die größte Verbreitung hat, werden alle Regeln immer auf VMware bezogen. Sie gelten aber gleichermaßen auch für andere Hypervisor, wenn sie die selben Features haben wie VMware.

F: Wie sieht’s denn bzgl. der neuen Technologien wie Hyperconverged Systems und Containerisierung aus ?

A: Ebenfalls analog zur Virtualisierung. Bzgl. Containers and Kubernetes Clusters hat Oracle das – nicht Vertragsbestandteil seiende – Partitioning-Policy Dokument (https://www.oracle.com/assets/partitioning-070609.pdf) im Oktober 2020 angepasst und die Regel hinzugefügt, dass ein Server bzgl. Oracle lizenziert werden muss, sobald ein Container mit dem Oracle-Programm dorthin deployed wurde. Wenn dieser Server kein physikalischer Server sondern eine VM ist, gelten die o.g. Regeln. Auch bei Hyperconverged Systems gelten lt. Oracle die hier beschriebenen Regeln. Da mittlerweile bspw. der Akropolis Hypervisor von Nutanix ebenfalls clusterübergreifendes Verschieben ermöglicht, muss also auch hier entsprechende Netzwerk-Trennung erfolgen.

F: Wie ist das Fazit zum Segregation Approval ?

A: Ich habe – zusammen mit meinen Kollegen, die bzgl. Netzwerk-, Storage und VMware-Konfiguration und Beurteilung der Dokumentation unterstützen – seit Anfang 2016 mehr als 40 Segregation-Approvals erfolgreich bearbeitet, so dass die Kunden mit unserer Unterstützung bei Konzeption und Dokumentation das Segregation Approval erlangt haben. Wir hatten darüber hinaus einen Kunden, der aus gesetzlichen Gründen bereits eine solch komplizierte Netzwerk-Architektur benötigt, dass eine zusätzliche VLAN-Einführung nicht denkbar war, dann hatten wir einen Kunden, bei dem keine Einigung über den damals noch seitens des Oracle-Vertriebs gewünschten kompensatorischen Kauf zwischen Oracle und dem Kunden erzielt werden konnte und einen Kunden, bei dem Oracle das Approval nicht bearbeiten wollte, weil der Kunde hosten lässt und man befürchtete, dass dann alle Kunden des Hosters das Approval haben wollen. Wenn man von solchen negativen Ausnahmen mal absieht, die zudem auch mittlerweile der Vergangenheit angehören sollten, ist das Segregation Approval die sinnvolle Möglichkeit, Oracle weiter compliant auf virtualisierten Umgebungen zu betreiben. Man erhält die HA-Vorteile und das gewohnte Management von VMware, ist aber mit dem VLAN-Approval und entsprechender Lizenzierung aber compliant. Allerdings ist ärgerlich, dass jeder Kunde dieses Approval einzelvertraglich beantragen und erhalten muss. Daher ist es aus meiner Sicht weiterhin nicht als „gute Lösung“, sondern nur als „Workaround“ zu bewerten. Der aber für viele Kunden eine sinnvollen Weg darstellen kann, wenn die Kunden nicht den konfrontativen Weg gehen wollen.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , | Kommentar hinterlassen

Neues bei kostenfreien Java-Distributionen

Mit dem 06.03.2021 ist AdoptOpenJDK nun zur Eclipse Foundation gewandert und heißt nun neuerdings: „Ecliopse Adoptium“. Es bleibt bei: kostenfrei und LongTermSupport (LTS)

Dafür gibt es nun einen weiteren Anbieter für kostenfreies Java und kostenfreien LongTermSupport:

Nähere Informationen und Downloads gibt es hier: https://www.microsoft.com/openjdk

Vielen Dank an meinen Kollegen Klaus Kramer für den HInweis.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , | Kommentar hinterlassen

OnPrem und Cloud: einmal addieren, einmal nicht. Oder: Konsistenz wäre schön!

Was will ich nun mit dieser kryptischen Überschrift sagen…

Es geht um die Ermittlung der Anzahl der benötigten Prozessoren und um den Umgang mit Rundungsnotwendigkeiten.

Gucken wir uns erstmal OnPrem an:
Nicht immer ist das Zählen so einfach wie Oracle es in den wenigen Beispielen in den veröffentlichten Dokumenten vorsieht. Zum Einen gibt es Betriebssysteme, bei denen man ganz offiziell Bruchteile von Prozessoren zuweisen kann (z.B. IBM capped LPAR), und dann stellt sich noch die Frage, wann mit dem jeweiligen Core-Faktor mutipliziert wird, und dadurch können Ergebnisse mit Bruchteilen entstehen, und es stellt sich die Frage, wann dann auf die jeweils nächst-höhere ganze Zahl gerundet werden muss, denn Oracle verkauft nur ganzzahlige Prozessorlizenzen.
Nehmen wir mal an, wir haben folgende Umgebung, auf der die Oracle DB Enterprise Edition läuft:
1 IBM Server (Power8-Prozessoren (Core-Faktor=1,0)), auf dem 3 capped LPARs mit der DB-EE laufen
– 1 LPAR hat Entitled Capacity = 0,6
– 1 LPAR hat Entitled Capacity = 0,9
– 1 LPAR hat Entitled Capacity = 1,2
1 Oracle/Sun-Server (SPARC T5 (Core-Faktor=0,5)) mit 1 capped Zone mit 3 Cores
1 Oracle VM mit 3 zugeordneten Cores Intel Xeon E7-48xx (Core-Faktor=0,5)
Man sieht, alle Server sind Hard-Partitioniert.
Um bei solchen komplexeren Umgebungen die Anzahl der zu lizenzierenden Prozessoren zu ermitteln, gibt bei On-Prem gibt es nun folgendes Regelwerk:
Erst die Server gleichen Prozessortyps addieren, die jeweilige Summe mit dem Core-Faktor multiplizieren, dann addieren und erst dann ggf. runden. D.h.:
LPAR: (0,6+0,9+1,2)*1,0 = 2,7*1,0 = 2,7
Oracle/Sun: 3*0,5 = 1,5
Oracle VM: 3*0,5 = 1,5
Summe: 2,7+1,5+1,5 = 5,7   also aufrunden auf 6 Prozessorlizenzen

 

Kommen wir jetzt zur Cloud:
In dem Whitepaper zu Licensing Oracle in Cloud Computing Environments (Azure, AWS) steht folgendes zur Lizenzierung der DB SE1/SE/SE2:

When licensing Oracle programs with Standard Edition One, Standard Edition 2, or Standard Edition in the product name, the pricing is based on the size of the instance. Authorized Cloud Environment instances with four or fewer Amazon vCPUs, or four or fewer Azure vCPUs, are counted as 1 socket, which is considered equivalent to an Oracle processor license. For Authorized Cloud Environment instances with more than four Amazon vCPUs, or more than four Azure vCPUs, every four Amazon vCPUs used (rounded up to the nearest multiple of four), and every four Azure vCPUs used (rounded up to the nearest multiple of four) equate to a licensing requirement of one socket.

Gleiches gilt auch für die OCPUs in der Oracle Cloud.
Stellt sich nun die Frage, wie hier addiert und gerundet wird. Nehmen wir mal an, die DB-EE läuft in der AWS-Cloud in zwei Cloud-Instanzen (=VMs) mit je 2 vCPUs.
Im Unterschied zu OnPrem wird in der Cloud  jede Cloud-Instanz separat betrachtet.
Man darf also hier nicht erst addieren und dann ggf. runden (2 vCPU + 2 vCPU = 4 vCPU = 1 Prozessorlizenz DB SE1/SE/SE2 wäre hierfür das falsche Ergebnis), sondern es muss jeweils pro Instanz gerundet und dann addiert werden: 2 vCPU -> 1 Prozessorliz. + 2 vCPU -> 1 Prozessorliz = 2 Prozessorlizenzen.

1

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | Kommentar hinterlassen

Ende der Fix-Term-Lizenzen … fast !!!

Oracle hat heute informiert, dass ab 01.09.2020 die zeitlich befristeten Lizenzen (Fix-Term-Lizenzen (FTL), die für 1, 2, 3, 4 oder 5 Jahre angeboten wurden), nicht mehr angeboten werden. Auch hierdurch sollen die Kunden in die Cloud motoviert werden. Bestehende Kunden, die Support für ihre befristeten Lizenzen zahlen, werden bis zum Ende ihrer Laufzeit weiterhin unterstützt.

Es gibt allerdings eine Ausnahme: 1-Jahres-Lizenzen sind auch nach dem 01.09.2020 noch für bestimmte Oracle-Produkte kaufbar. Aktuell sind diese Produkte auch nach dem 01.09.2020 als 1-Jahres-Lizenz lizenzierbar:

Datenbank:
Oracle Database Standard Edition 2
Oracle Database Enterprise Edition

Optionen der Datenbank:
Oracle Active Data Guard
Oracle Advanced Compression
Oracle Advanced Security
Oracle Database In-Memory
Oracle Database Vault
Oracle Multitenant
Oracle OLAP
Oracle Partitioning
Oracle Real Application Clusters
Oracle Real Application Clusters One Node
Oracle Real Application Testing

Management Packs der Datenbank:
Oracle Diagnostics Pack
Oracle Tuning Pack

Middleware:
Oracle Forms and Reports
Oracle Internet Application Server Enterprise Edition
Oracle WebLogic Server Standard Edition
Oracle WebLogic Server Enterprise Edition
Oracle WebLogic Suite
Oracle SOA Suite for Oracle Middleware

Sonstiges:
Oracle GoldenGate
Exadata Storage Server Software

 

 

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | 2 Kommentare

Update in Beitrag „Failover und die 10-Tage Regel – äh … 10×24-Stunden Regel“

Gestern habe ich von der Änderung der „10-Tage-Regel“ beim Failover berichtet, die ja noch einige offene Fragen zurückgelassen hat. Die Fragen bzgl. der Berechnung der 24-Stunden-Perioden konnten schnell geklärt werden:
Jede 24-Stunden-Periode beginnt mit dem Ausfall des Primär-Servers und dem Umschalten auf den Sekundär-Server. Ich habe die im verlinkten Beitrag aufgezählten Varianten bzgl. der neuen Regelung entsprechend aktualisiert.

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | Kommentar hinterlassen

Failover und die 10-Tage Regel – äh … 10×24-Stunden Regel

Gerade durch einen Newsletter von Redress Compliance drüber gestolpert:

 

 

 

 

 

Aber auch hier … es wäre nicht Oracle, würde das nicht wieder mehr Fragen aufwerfen als es beantwortet:

  • im aktuell auf den Oracle-Seiten verfügbare LDR vom 11.06.2020, und nur der ist vertraglich bindend, steht da noch nichts von drin, sondern der alte Text von den
    10 Tagen.

    • wann kommt ein entsprechend angepasster LDR ?
  • Strenggenommen gilt das dann doch nur für neu gekaufte Lizenzen, denn von einer rückwirkend geltenden Änderung steht da nichts.
  • Im am 28.07.2020 geänderten Dokument „Licensing Data Recovery Environments“ steht folgendes:

    Das ist soweit klar, weil in dem Beispiel im Text der Primärserver einmal am Dienstag und einmal am Freitag ausfällt, und das kann man ja nicht in eine 24-Stunden-Periode packen. Es wird aber nicht deutlich, wie zu rechnen ist, wenn die Maschine am Donnerstag 2 Stunden und am Freitag 3 Stunden ausfällt, denn hier gibt es drei Möglichkeiten:
    ◊ Maschine fällt aus von Donnerstag 22 Uhr bis Freitag 03 Uhr
    → Alte Regelung: 2 Tage von 10 Tagen sind weg
    → Neue Regelung: Eine 24-Stunden-Periode ist weg
    ◊ Maschine fällt aus Donnerstag von 09 bis 11 Uhr und Freitag von 03 bis 06 Uhr
    → Alte Regelung: 2 Tage von 10 Tagen sind weg
    → Neue Regelung: Zwei 24-Stunden-Perioden sind weg
    ◊ Maschine fällt aus Donnerstag von 09 bis 11 Uhr und Freitag von 14 bis 17 Uhr
    → Alte Regelung: 2 Tage von 10 Tagen sind weg
    → Neue Regelung: Zwei 24-Stunden-Perioden sind weg

Update 25.08.2020: Inzwischen ist bzgl. der Zeiträume Klarheit geschaffen worden: Jede 24-Stunden-Periode beginnt mit dem Ausfall des Primär-Servers und dem Umschalten auf den Sekundärserver. Ich habe die oben aufgezählten Varianten bzgl. der neuen Regelung entsprechend aktualisiert.

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | 4 Kommentare

Neues zum kostenpflichtigen Oracle-Java

Java Logo Klassisch" von kleversonk | Redbubble Gute und nicht ganz so gute Nachrichten zum kostenpflichtigen Oracle JDK gibt es heute zu vermelden.

Fangen wir mit den nicht ganz so guten Nachrichten an, die sich aus der Frage ergeben, welche Versionen und Patch-Stände des Oracle-JDK überhaupt kostenpflichtig sind:
Hier wurde immer nur von Oracle JDK8 ab inklusive Patchlevel 211 sowie Oracle JDK11, 12, ff berichtet. Das ist auch grundsätzlich richtig, man vergisst dabei aber die späten Patchlevel von Oracle JDK6 und Oracle JDK7. Letzte frei verfügbare Patchlevel für diese Versionen waren Oracle JDK6u45 (April 2013) und Oracle JDK7u80 (April 2015). Alle Patchlevel von OracleJDK6 höher Level45 und Oracle JDK7 höher Level80 sind kostenpflichtig. Und diese Versionen sind durchaus häufig noch im Einsatz.

Übersicht:
OracleJDK 6
frei bis einschließlich Patchlevel 45 (April 2013)
Premier Support bis Dezember 2015
Extended Support bis Dezember 2018

OracleJDK 7
frei bis einschließlich Patchlevel 80 (April 2015)
Premier Support bis Juli 2019
Extended Support bis Juli 2022

OracleJDK8
frei bis einschließlich Patchlevel 202 (Januar 2019)
Premier Support bis März 2022
Extended Support bis Dezember 2030

 

Kommen wir nun zu den guten Nachrichten:
Wer das oben Stehende genau gelesen hat, dem ist aufgefallen, dass Oracle den Zeitraum für den Extended Support für Oracle JDK 8 verlängert hat. Und zwar bis zum Dezember 2030. Kunden, die die kostenpflichtigen Patches des Oracle JDK 8 einsetzen wollen, haben nun sehr viel mehr Zeit, die mit Java 8 letztmalig unterstützten Features (z.B. Applets, Java Webstart, …) weiterhin nutzen zu können. Und das in einer bzgl. Security-Patches aktuellen Umgebung.
Die zweite gute Nachricht ist, dass – lt. Oracle und nach heutigem Kenntnisstand – der Extended Support für Java keine Zusatzkosten mit sich bringt. Hoffen wir, dass das bis 2030 so bleibt.

 

 

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | 2 Kommentare

Oracle Multitenant: wie viele PDBs sind möglich ohne Multitenant Option?

Weil ich selbst es gerne vergesse, hier die Übersicht, wie viele PDBs pro CDB „erlaubt“ sind ohne die Multitenant Option lizenzieren zu müssen. Denn dies ist abhängig von der verwendeten Version der Oracle-Database:

11.1 und 11.2:
Diese Versionen beinhalteten noch nicht die Multitenant-Technologie

12.1:
SE1/SE/SE2: 1 CDB + 1 PDB frei
EE: 1 CDB + 1 PDB frei, darüber Multitenant Option

12.2.:
SE2: 1 CDB + 1 PDB frei
EE: 1 CDB + 1 PDB frei, darüber Multitenant Option
jeweils +1 Application Root und +1 Proxy PDB

18c:
SE2: 1 CDB + 1 PDB frei
EE: 1 CDB + 1 PDB frei, darüber Multitenant Option
jeweils +1 Application Root und +1 Proxy PDB

19c:
SE2: 1 CDB + 3 PDB frei
EE: 1 CDB + 3 PDB frei, darüber Multitenant Option

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | Kommentar hinterlassen