Oracle Standard Edition 2 Hardware Einschränkungen

Oracle Standard Edition 2 (SE2) – Lizenzregeln und Auswirkungen

Wie bereits angekündigt hat Oracle mit 1. September 2015 die neue Datenbank Edition Oracle Standard Edition 2 (SE2) veröffentlicht (Link). Sie ersetzt ab sofort die Standard Edition One (SE1) und die Standard Edition ab der Version Oracle 12.1.0.2. Für die SE1 und SE können daher nicht mehr Lizenzen gekauft bzw. nachgekauft werden.

Aus der Perspektive der Software handelt es sich bei der Oracle Standard Edition 2 (SE2) um die gleichen Binaries wie die Vorgänger Editionen, jedoch ist sie aus lizenzrechtlicher Sicht ein eigenständiges, neues Produkt mit neuen Limitationen bei gleichbleibend bewährten Funktionalitäten.

Server Hardware Einschränkungen mit SE2

Die Oracle Standard Edition 2 (SE2) kann auf allen Servern eingesetzt werden, die eine maximale Kapazität von 2 Sockel am Motherboard aufweisen. Jeder belegte Sockel ist zu lizenzieren. Die exklusiv von unseren Technikern konfigurierte Maximum Performance Appliance MPA (Link) ist speziell für die für die Anforderung der SE2 bzgl. maximaler Performance pro Thread designed.

Real Application Cluster (RAC) mit Standard Edition 2 (SE2)

Es ist erlaubt mit Oracle Standard Edition 2 (SE2) einen RAC zu implementieren, der aber entsprechend den Lizenzvorgaben nur aus maximal 2 Server bestehen darf.
Jeder dieser Server kann über maximal zwei Sockel am Motherboard verfügen, wobei aber nur ein Sockel pro Server (CPU) für den RAC verwendet werden darf !
Um diese Vorgaben zu erreichen, können Sie den zweiten Sockel des Servers entweder unbesetzt lassen oder über eine unterstützte Hard Partitioning Software Lösung (z.B. Oracle VM, LPAR,…) binden.

Das Usage Cap der Oracle Standard Edition 2 (SE2)

Erstmals wurde bei der SE2 eine technische Obergrenze (Usage Cap) für die Verwendung von CPU Threads implementiert. Eine Single Server Oracle Standard Edition 2 (SE2) Datenbank verwendet nicht mehr als 16 CPU Threads. Achtung: Es hängt von der jeweiligen Plattform und Betriebssystem ab, ob ein CPU Thread gleich einem CPU Core zu setzen ist.
Bitte beachten Sie: Es besteht leider nicht auf jeder Plattform die Möglichkeit das Hyperthreading zu deaktivieren.

Das Usage Cap ist nur auf der Datenbank Ebene implementiert. Wenn Sie also auf einem Server mehrere Datenbanken betreiben, so kann jede Datenbank für sich 16 eigene CPU Threads verwenden.

Im Oracle Standard Edition 2 (SE2) RAC stehen pro Datenbank Instanz (auf zwei RAC Servern ist je eine Instanz die zusammen die RAC Datenbank bilden) jeweils maximal 8 CPU Threads zur Verfügung (in Summe wieder 16 Threads für den RAC).
Auch in diesem Fall ist es so, dass Sie natürlich mehrere Datenbanken anlegen können und jede neue RAC Datenbank Instanz für sich acht andere CPU Threads verwenden kann.

Änderung der Minimas bei Oracle Standard Edition 2 (SE2)

Für jeden SE2 Server müssen bei NUP Lizenzierung mindestens 10 NUPs erworben werden. Bei Standard Edition und Standard Edition One beträgt das Minima bei der Erstanschaffung 5 NUPs pro Unternehmen.

Lizenz Preise und Lizenz Migration

Eine Oracle Standard Edition 2 (SE2) Lizenz kostet exakt gleich viel wie eine Oracle Standard Edition (SE) Lizenz.
Standard Edition One und Standard Edition Kunden haben die Möglichkeit ihre Lizenzen 1:1 zu migrieren, d.h. es fallen keine weiteren Lizenzgebühren für Bestandslizenzen an.
Bitte beachten Sie: Bei einer Standard Edition One zu Oracle Standard Edition TWO ( SE2 ) Migration erhöhen sich die jährlichen Supportgebühren um 20%.

Bestehender Support für SE1 & SE 12.1.0.1

Der Premier Support für Oracle12c 12.1.0.1 SE ONE und SE endete am 31. August 2016.
Ab 1. September 2016 sind diese Produkte in den Sustaining Support übergegangen.

Fazit zu den Lizenzbedingungen der SE2

Die Lizenzbedingungen der Oracle Standard Edition 2 (SE2) haben sich gegenüber der SE und SEOne ohne Zweifel stark geändert. Vor allem Standard Edition Systeme mit vier Sockel Server sowie Standard Edition RAC Systeme sind dadurch stark betroffen.

Nach der für jedes System irgendwann notwendigen Migration auf SE2 12.1.0.2 dürfen 4 Sockel Server nicht mehr eingesetzt werden. Bei den Standard Edition RAC Systemen wird es notwendig entweder jeweils eine CPU pro Server zu entfernen oder mittels Hard Partitioning zu deaktivieren.

Neue Anwender die bisher mit den Hardware-Einschränkungen einer Standard Edition One auskommen wären trifft die Neuerung der SE2 vorallem beim Preis, da eine Oracle Standard Edition TWO dreimal so viel kostet wie die Standard Edition One.

Die Beschränkung der CPU Threads sehen wir nicht als sehr dramatische Einschränkungen an, da dieses Limit nur auf Datenbank-Ebene und nicht auf Server-Ebene gilt.

Fragen & Antworten

Für weitere detailierte Auskünfte und Best-PracticeUmsetzungen kontaktieren Sie bitte unsere Experten (Link).

Sie haben auch die Möglichkeit einen Kommentar zu hinterlassen.

Die AOUG Anwenderkonferenz 2015 – wieder absolut gelungen

Am 16. Juni 2015 fand im Hotel Savoyen in Wien wieder die jährliche Anwenderkonferenz der Austrian Oracle User Group statt.

Unser Geschäftsführer Ing. Klaus-Michael Hatzinger konnte in seiner Funktion als AOUG Präsident bei seiner Eröffnungsrede wieder zahlreiche Teilnehmer/innen und Vortragende begrüßen.

Das sehr informative Programm mit vier verschiedenen Breakout Sessions bot ein sehr breites Spektrum an interessanten Vorträgen. Mit den Schwerpunkten Datenbank, Development, Middleware, Hardware und Führungskräfte war für alle Teilnehmer/innen ein spannender und kurzweiliger Konferenztag garantiert.

Wie jedes Jahr fand der Ausklang bei der traditionellen Cocktail Party statt, bei der noch so manche interessante Aussagen der Keynote Speaker und der Vortragenden in entspannter Atmosphäre vertieft wurden.

AOUG_AK2015_Blog

Keynote Speaker Patrick Wheeler, Kellyn Pot´Vin-Gorman, CEO Oracle Austria Martin Winkler, AOUG Präsident Klaus-Michael Hatzinger

 

Oracle APEX 5.0

Oracle APEX 5.0 released

Seit 15. April 2015 ist Oracle Application Express (APEX) 5.0 offiziell verfügbar. Schon im Vorfeld war es möglich sich mit den neuen Möglichkeiten im Rahmen einer Early Adopter Version vertraut zu machen. DBConcepts setzt intern die neue Version bereits für Projekte ein, auch von Kunden wurde schon Interesse an einem Upgrade gezeigt.

Sehr hervorzuheben sind folgende neue Features:

Ein komplett überarbeiteter Page Designer

Der neue Page Designer spielt seine Stärken nach einer kurzen Umstellungsphase voll aus. Sehr positiv fällt auf, dass nun alles auf einer Seite bearbeitbar ist. Keine Seitenwechsel mehr um Prozesse oder Regionen zu bearbeiten. Zusätzlich ergänzt durch ein „Rückgängig machen“ der letzten Schritte sind damit Bearbeitungen der Seite deutlich rascher möglich als früher. Das spart Zeit in der Entwicklung, gerade auch wenn eine Fernwartung auf Kundensystemen gemacht werden muss und jeder Seitenwechsel potentiell Zeit kostet.

Universal Theme

Ein neues „Universal-Thema“, das speziell für APEX 5 entwickelt wurde. Leicht anzupassen und anpassungsfähig an unterschiedliche Geräte (Stichwort Desktop-Mobil) ohne Expertenkenntnisse in HTML, CSS oder Javascript.

Modale Dialoge

APEX 5 bietet nun out-of-the-box modale Dialoge an. Mit wenigen Klicks sind so aufwändige „Fenster im Fenster“ möglich. Das eröffnet ganz neue Möglichkeiten in der Applikationsentwicklung was Usability und Ease-of-use betrifft.

Mobile Display

Zusätzlich zum Universalen Thema gibt es neue intelligente Möglichkeiten für mobiles Reporting. Dieses passt sich automatisch an schmale Bildschirme an indem Spalten ein- und ausgeblendet werden und zusätzliche Umbrüche automatisiert eingefügt werden.

 Kalender

Ein komplett neuer Kalender wurde integriert. Deutlich leichter anzupassen und mit Unterstützung für Tages-, Wochen- und Monatsansicht sowie Unterstützung für Drag and Drop Operationen.

Das war nur ein kurzer Überblick über die neuen Möglichkeiten.

Wir werden im Lauf der Zeit auf Basis der Erfahrung in unseren Projekten weitere interessante Informationen zu den einzelnen Punkten hier im Blog veröffentlichen.

 

Oracle Prozessor Lizenzierung Stolpersteine und Feinheiten

Oracle Prozessor Lizenzierung Stolpersteine und Feinheiten

Wie bereits im Blog Artikel Oracle Prozessor Lizenzierung >>  dargestellt, werden Oracle Datenbanken bei der Prozessor Lizenzierung anhand des Prozessortyps und der Anzahl der enthaltenen Cores lizenziert.

Ausnahmen davon sind die Oracle Standard Edition One (SEOne) und die Oracle Standard Edition (SE) Datenbank Prozessor Lizenzen.

Bei beiden Editionen sind der Prozessortyp und die Anzahl der enthaltenen Cores nicht relevant, sondern nur die Anzahl der vorhandenen, physischen CPU Sockel.

Sie können bei der SEOne also zum Beispiel 2 x 6 Core Prozessoren einsetzen und müssen lediglich zwei Sockel mit zwei SEOne Prozessor Lizenzen lizenzieren. Im Oracle Enterprise Bereich wären bei diesem Beispiel auf Basis Intel Xeon sechs Prozessorlizenzen fällig!

Bei der Oracle SEOne (Standard Edition ONE) darf der physische Server über maximal zwei Sockel verfügen und der Einsatz von RAC (Real Application Cluster) ist nicht erlaubt.

Bei der Oracle SE (Standard Edition) sind bei einem physischen Server bis zu maximal vier CPU Sockel erlaubt.
Mit der Oracle Standard Edition können Sie auch einen RAC betreiben, jedoch gibt es dazu von Oracle vorgegebene Installationsvoraussetzungen. Die Summe aller im RAC vorhandenen Sockel darf die Zahl 4 nicht überschreiten.

Der SE RAC stellt die lizenztechnisch kostengünstigste Variante für einen Real Application Cluster dar, zumal die RAC Option Lizenzen hier schon in der Basislizenz inkludiert sind!

Achtung Stolperstein

Es zählen zur Feststellung der möglichen Oracle Editionen (SE, SEOne) alle vorhanden Sockel, unabhängig davon ob sie leer sind oder mit CPUs belegt wurden!

Die Anzahl der benötigten Prozessor Lizenzen richtet sich natürlich nach der Anzahl der tatsächlich belegten Sockeln.

Wenn Sie zum Beispiel bei einem RAC mit vier Servern und je zwei Sockel pro Server nur einen Sockel mit jeweils einer CPU belegen, so sind in Summe acht Sockel vorhandenen und somit das Limit der SE Lizenz mit vier Sockel überschritten! In diesem Fall müssen Enterprise Lizenzen eingesetzt werden.

CPU Core Factor Table

Bei der Enterprise Edition spielt die Anzahl der Sockel keine Rolle, sondern nur die Anzahl der Cores pro CPU.
Die Core Factor Table >>  gibt Aufschluss darüber, welcher Prozessortyp pro Core mit welchem Factor multipliziert werden muss, um die korrekte Anzahl der notwendige EE Prozessor Lizenzen zu ermitteln. Es ist dabei auf die nächste ganze Zahl aufzurunden.

 

Grundlagen und Vorteile der Oracle Prozessor Lizenzierung

Grundlagen und Vorteile der Oracle Prozessor Lizenzierung

Die Oracle Prozessor Lizenzierung muss immer dann gewählt werden, wenn die genaue Anzahl an natürlichen Personen und/oder physischen Devices nicht festgestellt werden kann. Das kann zum Beispiel der Fall sein, wenn auf Ihrer Internet Webseite Zugriffe auf Ihre Oracle Datenbank möglich sind.

Beispiel aus der Praxis

Wenn die Kassiererin in einem Supermarkt die Produkte bei der Kassa mit einem Scanner erfasst, dann ist die Kassiererin ein Named User.

Named User Beispiel Produkt Scanner

Falls aber die Kunden Ihren Einkauf an der Selbstbedienungskassa selber scannen, dann sind die Kunden eine nicht feststellbare Anzahl an Datenbanknutzer und müssen daher via Prozessor Lizenz lizenziert werden. Der Scanner selber ist ein durch Menschen bedientes Gerät und muss nicht als Named User gezählt werden.

Der große Vorteile der Oracle Prozessor Lizenzierung

Die Anzahl der lizenzierten Datenbank Nutzer pro System ist theoretisch unbegrenzt. Ab einer bestimmten Anzahl an NUP Lizenzen wird der Breakeven überschritten (siehe Details im „Oracle Quick Pocket Licence Guide >>“) an dem die Prozessor Lizenzen günstiger sind.

Es ist möglich, bestehende NUP Lizenzen bei einem Umstieg auf Prozessor Lizenzierung anrechnen zu lassen.

Einsparungspotenzial

Ein Downgrade von CPU auf NUP Lizenzierung oder eine Reduzierung von bestehenden NUP Lizenzen (um die damit verbunden Supportkosten zu verringern) ist in den Lizenzvorgaben leider nicht vorgesehen und daher im Normalfall auch nicht möglich. Bei einer starken Reduktion der Datenbanknutzer bzw. Devices kann daher ein Neukauf aufgrund der geringeren Supportkosten finanziell sinnvoll sein!

Eine vorausschauende Planung der Datenbanknutzer ist aus diesem Grund immer ratsam, um Unter- oder Überlizenzierung zu vermeiden.

Oracle Prozessor Lizenzierung

Prozessortyp und Anzahl der Cores

Oracle Datenbanken werden bei der Oracle Prozessor Lizenzierung anhand des Prozessortyps und der Anzahl der enthaltenen Cores lizenziert.

Ausnahmen davon sind die Oracle Standard Edition One (SEOne) und die Standard Edition (SE) Prozessorlizenzen. Bei beiden Editionen sind der Prozessortyp und die Anzahl der enthaltenen Cores nicht relevant, sondern nur die Anzahl der vorhandenen, physischen CPU Sockel.

Sie können bei der SEOne also zum Beispiel 2 x 6 Core Prozessoren einsetzen und müssen lediglich zwei Sockel mit zwei SEOne Prozessor Lizenzen lizenzieren. Im Oracle Enterprise Bereich wären hier auf Basis Intel Xeon sechs Prozessorlizenzen fällig!

Bei der SEOne (Standard Edition ONE) darf der physische Server über maximal zwei Sockel verfügen und der Einsatz von RAC (Real Application Cluster) ist nicht erlaubt.

Bei der SE (Standard Edition) sind bei einem physischen Server bis zu maximal vier CPU Sockel erlaubt. Mit der SE können Sie auch einen RAC betreiben, jedoch gibt es dazu von Oracle vorgegebene Installationsvoraussetzungen. Die Summe aller im RAC vorhandenen Sockel darf die Zahl 4 nicht überschreiten.

Der SE RAC stellt die lizenztechnisch kostengünstigste Variante für einen Real Application Cluster dar, zumal die RAC Option Lizenzen hier schon in der Basislizenz inkludiert sind!

Achtung Stolperstein:
Es zählen zur Feststellung der möglichen Oracle Editionen (SE, SEOne) alle vorhanden Sockel, unabhängig davon ob sie leer sind oder mit CPUs belegt wurden! Die Anzahl der benötigten Prozessor Lizenzen richtet sich natürlich nach der Anzahl der tatsächlich belegten Sockeln.

Wenn Sie zum Beispiel bei einem RAC mit vier Servern und je zwei Sockel pro Server nur einen Sockel mit jeweils einer CPU belegen, so sind in Summe acht Sockel vorhandenen und somit das Limit der SE Lizenz mit vier Sockel überschritten! In diesem Fall müssen Enterprise Lizenzen eingesetzt werden.

Bei der Enterprise Edition spielt die Anzahl der Sockel keine Rolle, sondern nur die Anzahl der Cores pro CPU.
Die Core Factor Table gibt Aufschluss darüber, welcher Prozessortyp pro Core mit welchem Factor multipliziert werden muss, um die korrekte Anzahl der notwendige EE Prozessor Lizenzen zu ermitteln. Es ist dabei auf die nächste ganze Zahl aufzurunden.

 

Oracle Named User Plus versus Prozessor Lizenz

Oracle Named User Plus versus Oracle Prozessor Lizenzierung

Als „Named User Plus (NUP)“ wird eine natürliche Person oder ein physisches Device mit der Möglichkeit zum Zugriff auf eine Oracle Datenbank verstanden.

Es ist dabei völlig unerheblich, ob die einzelnen Personen oder Devices zum Beispiel über eine Applikation nur mit einem einzigen gemeinsamen Datenbankuser auf die Datenbank zugreifen, oder ob die natürlichen Personen über mehrere verschiedene Datenbankuser verfügen. Der große Vorteil der NUP Lizenzierung ist, dass auch die Anzahl der Datenbanken und Server  unerheblich ist, solange die von Oracle definierten Minimas der jeweiligen Edition eingehalten werden und es sich um die gleichen Personen handelt.

ACHTUNG Stolperstein:
Bei falsch verstandener Auslegung dieser Regel kann es leicht zu Überlizenzierungen kommen! Bitte beachten Sie, dass pro physischer Person und/oder nicht durch Menschen bediente Geräte (Sensoren) ein „Named User Plus (NUP)“ lizenziert werden muss.

Kann keine genaue Aussage über die genaue Anzahl der physischen Personen und/oder nicht durch Menschen bediente Geräte gemacht werden, wie zum Beispiel beim Zugriff durch Web User, ist auf jeden Fall eine Prozessor Lizenz notwendig.

Je nach Datenbank Edition ist ab einer bestimmten Menge an NUP Lizenzen die Prozessor Lizenzierung günstiger. Sie finden diesen Breakeven Wert im “Oracle Quick Pocket Lizenz Guide >>” bei den einzelnen Datenbank Editionen angeführt. Ebenso ist bei den NUP Lizenzen je nach Edition die Mindestmenge (Minima) zu beachten.

ACHTUNG Stolperstein:
Bei der Oracle Enterprise Edition kann ein Hardwaretausch durch eine im Anschluss etwaig höhere Core Anzahl schnell zur Unterschreitung der Minimas führen!

Die entsprechenden Minimas je Hardware finden Sie ebenfalls im „Oracle Quick Pocket Lizenz Guide“ bei jeder Datenbank Edition angeführt.

Beispiele für physische Devices

Ein physisches Device könnte zum Beispiel ein Sensor auf einer Produktionsstraße sein. Ein Sensor auf einer Produktionsstrasse wird nicht direkt durch Menschen bedient („non human operated device“) und muss daher selber als Named User gezählt werden.
Auch wenn diese Produktionsstraße über viele identische Sensoren verfügt, die alle in der Datenbank nur einen einzigen User verwenden, so ist für jeden einzelnen physischen Sensor eine Named User Plus (NUP) Lizenz notwendig.

Ein anderes Beispiel für ein physisches Device könnte das Terminal eines Zeiterfassungs- oder Zutrittssystems sein. Wann immer eine Person sich ein- oder auscheckt, wird das über einen zentralen Datenbankzugang in der Datenbank entsprechend gebucht.

Diese Terminals sind durch Menschen bediente Geräte („human operated device“) und werden durch diese Eigenschaft selber nicht als Named User gezählt. Es müssen in diesem Fall aber alle Personen gezählt werden, die dieses durch Menschen bediente Gerät benutzen.

Alle System-/Datenbankadministratoren, die Zugriff auf die Datenbank haben (egal ob sie den Zugang nutzen oder nicht), müssen ebenfalls als Named User gezählt werden. Dies gilt auch für alle jene natürlichen Personen und Devices die z.B. bei einem externen Dienstleister auf die Datenbank zugreifen bzw. zugreifen könnten.
Wenn zum Beispiel einer unserer Kollegen Ihre Datenbank via Remote Zugriff von der Ferne administrieren, dann benötigen Sie dafür natürlich ebenfalls einen NUP auf Ihrer Datenbank.

Vorteile der Oracle NUP Lizenzierung

Die Lizenzierung nach NUP kann in einem Standby Szenario (Primary + Standby Datenbank) wesentlich kostengünstiger als die Lizenzierung nach CPU sein, weil es sich auf der Standby Seite um den identischen Benutzerkreis handelt und diese NUPs daher nur einmal zu lizenzieren sind.

Bei der Enterprise Edition sind natürlich die Minimas für das Gesamtsystem zu berücksichtigen.

 

Oracle VMware lizenzieren

Oracle VM – Datenbank lizenzieren in virtueller Umgebung

Um Oracle Datenbanken in virtueller Umgebung wie zum Beispiel VMware entsprechend den Lizenzvorgaben korrekt zu lizenzieren, müssen vorab einige wichtige und richtige Entscheidungen getroffen werden.

Mit Hilfe unseres „Oracle Quick Pocket Licence Guide“ und unserer Email Serie „Oracle Lizenzierung. Teure Fehler vermeiden.“ möchten wir Sie auf einige dieser Besonderheiten hinweisen.

Ein ausschlaggebendes Kriterium welches über die korrekte Lizenzierung von Oracle Standard Edition One (SEOne), Oracle Standard Edition (SE) oder Oracle Enterprise Edition (EE) Datenbanken entscheidet, ist die Hardwareausstattung.

Bitte beachten Sie auch die im Pocket Guide je Datenbank Edition angeführten Minima.

Die Minima sind jene Anzahl an Named User Plus Lizenzen, die Sie mindestens benötigen, falls Sie noch keine Lizenzen besitzen.

Zum kostenlosen Download des „Oracle Quick Pocket Licence Guide >>“

 

Soft Partitioning vs Hard Partitioning

Eine virtualisierte Umgebung mittels VMware fällt bei Oracle immer unter Softpartitioning!

Dabei muss die physikalische Gesamtleistung des einzelnen Servers zur Lizenzierung betrachtet werden und nicht bloß die virtuell zugeteilte Leistung. Weitergehend muss man je nach eingesetzter vSphere Version einen ganzen Cluster (bis 5.0), das ganze vCenter (ab 5.1), und ab vSphere 6.0 voraussichtlich alle vCenter oracleseitig auslizenzieren. Siehe dazu: Oracle Partitioning Policy >>

Oracle sieht auf x86 Hardware Plattformen unter bestimmten Konfigurationen OracleVM_for_x86 und Oracle_Solaris_Zones als harte Eingrenzungen und lizenztechnisch korrekt unter Hardpartitioning.

Siehe dazu: Hard Partitioning with Oracle VM >>

Unsere Erfahrung hat gezeigt, dass Unternehmen speziell in virtualisierten Serverlandschaften sich immer wieder durch falsche Auslegung des Softpartitioning große Probleme mit fehlerhafter Lizenzierung einhandeln.
Durch rechtzeitige Überlegungen und durch unser Knowhow können wir Sie aktiv unterstützen, um spätere Diskussionen im Zuge eines Lizenz Audit mit Oracle schon vorab zu vermeiden.

Zum kostenlosen Download des „Oracle Quick Pocket Licence Guide >>“

Oracle Datenbank Upgrade 12c

Upgrade auf Oracle 12c

Vieles scheint sich zu verändern: Ganze Datacenter wandern in die Cloud, neue Lösungsangebote wie Database as a Service betreten den Markt, der Trend zur Virtualisierung scheint ungebrochen, Solid State Drives werden herkömmliche Festplatten wohl bald gänzlich ersetzen, Big Data und Datamining sind in aller Munde.

Doch manches verändert sich nicht so schnell: Genauso wichtig wie unternehmerische Innovationen und technologische Paradigmenwechsel ist die Fortführung von bewährten Technologien. Entgegen mancher kurzzeitiger Moden bildet das relationale Datenmodell immer noch das stabile Fundament für viele Anwendungen.

Die IT-Landschaft verändert sich in rasendem Tempo, und Oracle bildet hier keine Ausnahme.
Im Gegenteil: Mit dem Release der Datenbankversion 12c ebnet Oracle diesen Ent-wicklungen den Weg und eröffnet neue und vielversprechende Perspektiven für den Betrieb von Datenbanken, ohne dabei die Stärken einer relationalen Datenbank aufzugeben.

Mit 12c ist es Oracle gelungen, beide Anforderungen zu erfüllen:
Mit der Entwicklung von Features wie Pluggable Database und InMemory wird ein zukunftsweisender Weg aufgezeigt, mit der kontinuierlichen Weiterentwicklung der Stärken der Release 11gR2 eine Erfolgsgeschichte weitergeschrieben.

Wie sich auch entscheiden, wir möchten Sie mit unserem Know-How auf ihrem Weg unterstützen. Doch bevor die Reise beginnt, werfen wir noch einen Blick auf die Gegenwart.

Roadmap 11gR2

Wie bereits über verschiedene Kanäle angekündigt, neigt sich die Unterstützung von Release 11gR2 dem Ende zu. Die Version 11gR2 wurde im Jahr 2009 erstmals veröffentlicht, seitdem erschienen mehrere Subreleases. Momentan ist die Version 11.2.0.4 aktuell, wobei diese Version auch die letzte sein wird (Oracle spricht hier vom terminal patchset).

Das Release 11gR2 wird zwar in Form von PSUs (Patch Set Updates) noch weiter gepflegt, aktuelle Entwicklung findet aber keine mehr statt.

Release  Patching End Date

11.2.0.1  13.09.2011
11.2.0.2  31.10.2013
11.2.0.3  27.08.2015
11.2.0.4  31.01.2018

Wie aus der Tabelle ersichtlich wird, endet das Patching für die Version 11.2.0.3 noch dieses Jahr, bei 11.2.0.4 bleibt noch ein wenig mehr Zeit. Dies betrifft jedoch nur die Bereitstellung von Patches und PSUs, nicht den Support. Hier sieht es anders aus.

 

Premier Support Ends

Achtung: Der Premier Support für 11gR2 ist mit Ende Jänner 2015 ausgelaufen!

Oracle bietet die Möglichkeit, für ein zusätzliches Jahr den sog. „Free Extended Support“ in Anspruch zu nehmen.

Dies ist für alle Kunden mit einem aufrechten Support-Vertrag möglich.

Um in den Genuss von „Free Extended Support“ zu kommen, ist es erforderlich, dass sie bei Oracle einen Vertrag anfordern. Sie bekommen dann eine Rechnung über den Betrag von 0 Euro ausgestellt, der die Aktivierung des „Free Extended Supports“ ausweist. Nach Ablauf des kostenlosen „Free Extended Support“erfolgt keine automatische Verlängerung des Supportvertrags. Ab dem zweiten Jahr (also nach 31.01.2016) würden die vollen Sup-portgebühren anfallen. Sofern sie den „Free Extended Support“ beantragen, ist nach Ablauf des Vertrags nichts mehr zu machen. Sie brauchen den Vertrag weder kündigen, noch wird dieser zu den regulären Supportpreisen verlängert.

Wie aus der Tabelle (siehe unten) ersichtlich wird, ist der „Free Extended Support“ nur für die Version 11.2.0.4 von Relevanz.

Für die Version 11.2.0.3 endet der Support bereits in wenigen Monaten.

Oracle Support Roadmap

 

Release  Free Extended Support Ends

11.2.0.1 No Extended Support available
11.2.0.2 No Extended Support available
11.2.0.3 27.08.2015
11.2.0.4 31.01.2016

Der „Free Extended Support“ für 11.2.0.4 endet mit Ende Jänner 2016. Ab diesem Zeitpunkt gibt es nur mehr den kostspieligen „Extended Support“, der maximal bis Ende Jänner 2018 verlängert werden kann.

 

Release 12c

Das Datenbank-Release 12c wurde am 22.06.2013 zum ersten Mal veröffentlicht. Mittlerweile (Stand: Februar 2015) steht die Release 12.1.0.2 zur Verfügung. Allerdings betrifft dies nur die Enterprise Edition der Datenbank, für die Standard Edition ist das letzte verfügbare Patchlevel 12.1.0.1.6.

 

Edition      Release and PSU-Level

Enterprise   12.1.0.2.2 (includes PSU Jan2015)

Standard      12.1.0.1.6 (includes PSU Jan2015)

 

Ein „Direct Upgrade“ auf 12c ist nur von folgenden Versionen aus möglich:

•             ≥ 10.2.0.5
•             ≥ 11.1.0.7
•             ≥ 11.2.0.2

Sollten sie eine ältere Version im Einsatz haben, ist ein Zwischenschritt notwendig. Doch auch hier gibt es wie immer mehrere Möglichkeiten.

Wir beraten sie gerne hinsichtlich der möglichen Upgrade-Szenarien und stimmen dieses gerne auf ihre Anforderungen hinsichtlich Downtime und Applikationstests ab.

 

Neben der in Verwendung befindlichen Version des RDBMS spielt das Client-Umfeld eine entscheidende Rolle für ein erfolgreiches Upgrade auf 12c.

  • Welche JDBC-Versionen sind im Einsatz?
  • Welche Client-Versionen verbinden sich zur Datenbank?
  • Wurde am Applikationsserver ein Connection Pool konfiguriert?
  • Und wie authentifizieren sich die Clients gegenüber der Datenbank?

Das sind nur einige der Fragen, die es im Vorfeld zu erheben gilt.

Wir unterstützen sie bei der Erfassung dieser Informationen und der möglicherweise notwendigen Konfigurationsänderungen.

 

Are you ready for Oracle 12c?

Um ihnen den Umstieg auf 12c so einfach wie möglich zu machen, bieten wir ihnen umfassende Prüfung ihrer Datenbanken und ihrer Clients im Vorfeld des Upgrades an.

 

Basierend auf unserer Erfahrung, die wir bei diversen Upgrades auf 12c sammeln konnten, haben wir einen Upgrade-Check erarbeitet, der in nicht-invasiver Weise die vorhandene Datenbank-Landschaft prüft und auf mögliche Stolpersteine beim Upgrade hinweist.

 

Am Ende des Prüfvorgangs erhalten Sie von uns einen detaillierten Bericht, wie sich ein Upgrade-Szenario darstellen würde, was hinsichtlich Datenbank und Client-Umfeld zu tun wäre und mit welchen Serviceeinschränk-ungen während des Upgrades zu rechnen wäre.

Dieser Check bildet die Grundlage für ein erfolgreiches Upgrade auf 12c.

Also: Sind sie dabei? Oder anders gefragt: Are you ready for 12c?

 

 

 

Oracle Solaris Cluster Cheat Sheet

Der Oracle Solaris Cluster ist eine Hochverfügbarkeitslösung für Oracle SPARC und x86 basierten Oracle Solaris Systemen. In 24×7 Umgebungen kontrolliert die Solaris Cluster Software mit vordefinierten Cluster Agenten die Funktion und den ordnungsgemäßen Betrieb der überwachten Komponenten. Neben dem Support von über 40 Standard Software Produkten wie die Oracle Datenbank oder SAP bietet der Cluster auch die Verwaltung von hochverfügbarer Virtualisierung mittels Solaris Zones oder OracleVM for SPARC (LDOM).

Durch die Verwendung von Betriebssystem-Funktionen und die Integration in den Solaris Kernel garantiert der Solaris Cluster rasche Fehlererkennung und ein beschleunigtes, kontrolliertes Wiederherstellen im Fehlerfall.

Neben einen Web basierten Administrations GUI steht eine funktionelle CLI zur Verwaltung und Konfiguration zur Verfügung.

Dieses Command Line Interface möchten wir mit einem kurzen Cheat Sheet vorstellen.

 

JavaScript Object Notation Support in Oracle 12c

JavaScript Object Notation Support in Oracle 12.1.0.2

Mit der Oracle 12c Release 12.1.0.2 hat die Oracle Datenbank JSON Unterstützung erhalten. JSON kann nun direkt gespeichert, abgefragt und auch indiziert werden. Im Folgenden soll dazu ein kurzer Überblick gegeben werden.

JSON steht für JavaScript Object Notation und beschreibt wie der Name schon ausdrückt eine Möglichkeit komplexe Objekte zu notieren und zu verarbeiten. Die Datenbank verwendet intern grundsätzlich immer UTF-8, entsprechend notwendige Konvertierungen bei der Ein- und Ausgabe werden automatisch durchgeführt.

Folgendes Beispiel eines Studenten soll dies verdeutlichen:

{    „Matrikelnummer“    : 123564869,
    „Name“    : „Otto Mayer“,
    „Studiengang“    : „Informationstechnik“,
    „aktuelles Semester“    : „WS2014/15“,
    „Fächer“    : [    „Business Englisch“,
            „Objektorientiertes Programmieren“,
            „Mathematik 3“]
}

Um nun ein JSON speichern zu können wird eine simple VARCHAR2 oder bei größeren Objekten eine CLOB Spalte verwendet. Neu dazukommen ist der Check-Constraint IS JSON um sicherzustellen, dass die Spalte auch wirklich immer valide JSON-Syntax enthält.

Eine Tabelle mit einer JSON Spalte sieht dann z.B. folgendermaßen aus:

CREATE TABLE students
    (id            RAW(16) NOT NULL,
    date_loaded   DATE,
    student_info  CLOB
    CONSTRAINT ensure_json CHECK (student_info IS JSON));

In diese Tabelle kann nun in die Spalte STUDENT_INFO ein Text im JSON-Format eingefügt ([…] wurde hier als Platzhalter verwendet) werden.

INSERT INTO students
VALUES ( sys_guid(),
        sysdate,
        ‘{      „Matrikelnummer“    : 123564869,
           „Name“            : „Otto Mayer“,
           [...] }’);

Die Daten können nun über eine ganz einfache Punkt-getrennte-Notation wie man sie von JavaScript kennt ausgelesen werden. Folgende SQL-Query ergibt z.B. das Ergebnis 123564869.

select st.student_info.Matrikelnummer
from students st

Es muss folgendes beachtet werden:

Die Schlüsselwerte sind case-sensitive – das gleiche muss in SQL berücksichtigt werden – das Statement oben würde kein Ergebnis liefern wenn statt „Matrikelnummer“ „matrikelnummer“ oder „MATRIKELNUMMER“ geschrieben wird. Sollten Leerzeichen oder Sonderzeichen wir Umlaute im Key sein – was grundsätzlich zu vermeiden ist – dann muss die entsprechende Angabe unter Anführungszeichen gesetzt werden also z.B.:

select st.student_info.”aktuelles Semester”
from students st

Sollte es sich um ein verschachteltes Objekt handeln so wird die Punkt-getrennte-Notation einfach auf allen Ebenen angewandt bis man bei dem gewünschten Wert angelangt ist.

Oracle bietet noch drei Funktionen die in SQL oder PL/SQL verwendet werden können die ich hier noch kurz beschreiben will: JSON_VALUE, JSON_QUERY, JSON_TABLE und JSON_EXISTS.

Allgemein nutzen alle JSON-Pfad-Notationen. Diese entspricht der Punkt-getrennten Notation die bereits besprochen wurde, und kann auch Elemente aus Arrays nutzen.

JSON_VALUE

Selektiert einen Wert wie zum Beispiel mit dem Ergebnis „Business English“ bei folgendem Query:

select json_value(st.student_info, '$.Faecher[0]')
from students st

JSON_EXISTS

Prüft ob ein bestimmer Schlüssel im JSON existiert. Das erste Query gibt ein Datum zurück bei allen Zeilen, denn das Array hat ein zweites Element (0 ist der Start-Index). Das zweite Query gibt nichts zurück da das Array nur 3 Elemente hat (und [3] das vierte Element abfragt).

select date_loaded
from students st
where json_exists(student_info, '$.Faecher[1]')


select date_loaded
from students st
where json_exists(student_info, '$.Faecher[3]')

JSON_QUERY

Im Gegensatz zu JSON_VALUE wird hier ein Teilstück des JSON selektiert und nicht nur ein Wert, folgendes Query gibt die Liste der Fächer zurück:

select json_query(student_info, '$[*].Faecher')
from students

JSON_TABLE

Diese Funktion dient dazu JSON-Daten in eine virtuelle Tabellenform zu überführen. Sie bietet damit die Möglichkeit im FROM-Teil der Query eingesetzt zu werden und dadurch mehrere Werte auf einmal ohne mehrmaliges Aufrufen von JSON_VALUE oder JSON_QUERY zu selektieren. Das bringt einen Geschwindigkeitsvorteil da die Daten so nur einmal geparst werden und nicht für jeden Funktionsaufruf immer wieder.

select jt.matrikelnummer, jt.fach1, jt.fach2, jt.fach3
from students st,
       json_table(st.student_info,
                 '$' COLUMNS(matrikelnummer NUMBER PATH '$.Matrikelnummer',
                         fach1 VARCHAR2(240) PATH '$.Faecher[0]',
                         fach2 VARCHAR2(240) PATH '$.Faecher[1]',
                         fach3 VARCHAR2(240) PATH '$.Faecher[2]')) jt

Die neuen JSON Funktionen bieten nützliche Werkzeuge, gerade im Zusammenhang mit APEX, dass durch seine Web-Browser Basis JavaScript massiv nutzt können sich dadurch hilfreiche Vereinfachungen implementieren lassen.

Weitere Infos zu JSON in der Oracle Datenbank finden sie hier:

http://docs.oracle.com/database/121/ADXDB/json.htm