Oracle Database Enterprise versus Standard Edition 2

Oracle database enterprise

De Oracle Database Enterprise software is er zoals bekend in meerdere varianten. In de praktijk zijn er daarvan voor produktie on-premise gebruik twee echt relevant. De meest uitgebreide van deze twee wordt Enterprise Edition genoemd en is, zoals de naam al suggereert, gericht op het voldoen aan de meest uitgebreide eisen. De andere variant heet Standard Edition 2 en is de opvolger van de oude Standard Edition (One). Deze is bedoeld voor wie de extra features van Enterprise Edition niet nodig heeft en daarnaast ook geen noodzaak heeft voor het gebruik van servers met meer dan twee CPU-sockets.

Oracle heeft op haar website onder het kopje “Database Licensing Information User Manual” voor elke database-versie de details gepubliceerd van de onderscheidende karakteristieken. Die opsomming leest echter niet echt prettig.

In dit artikel zullen we proberen te duiden wat volgens ons belangrijke verschillen tussen de editions zijn en wanneer de keuze voor de ene of de andere het meest voor de hand ligt.

Zonder alles nu al te verklappen zouden we willen stellen dat Standard Edition 2 de ideale keuze is voor wie gehecht is aan zijn/haar data maar voor wie databases zelf niet de spil zijn van de te leveren IT-diensten. Denk daarbij aan de situatie dat de database vooral een goed opslag/raadpleeg medium moet zijn. Voor wie wel graag wat extra’s wil en de mogelijkheid zoekt om aan de database zelf toegevoegde waarde te ontlokken (waar DBA.nl natuurlijk bij kan helpen!) is er de Enterprise Edition.

Standard Edition 2 (SE2)

Dit is de basis-editie van Oracle Database maar is waarlijk geen kleine jongen. Voor situaties waarin u behoefte heeft aan een betrouwbare en krachtige database voor bescherming en 24×7 beschikbaarheid van uw data is SE2 een uitstekende keuze. U zult met deze edition in de praktijk niet tegen grenzen aan data-groei aanlopen en ook de basis-functionaliteit is al heel uitgebreid.

Features van SE2

SE2 is een modern systeem, uitstekend geschikt als database-backend voor uw bedrijfskritische applicaties.

De bekende Oracle-specifieke features zoals Multimedia (met Locator), Oracle Text, APEX, In-database Java en XMLDB zijn alle aanwezig en er worden geen beperkingen gesteld aan het aantal gebruikers of aan toewijzing van geheugen/disk resources. Het spreekt verder vanzelf dat er ondersteuning aanwezig is voor de modernste SQL-standaarden en dat de database-kern in de nieuwste versie 12.2 wederom is verbeterd op het gebied van veiligheid, betrouwbaarheid, diagnostiek en snelheid.

De beheerbaarheid van SE2 is prima; RMAN, DataPump, sql*loader zijn er voor data-backup en -transport en sql*plus, statspack,en de ADR diagnostics geven de DBA de nodige tools in handen voor beheer, foutopsporing en performance-analyse.

SE2 legt geen beperkingen op aan de omvang van de data en kan dus net als EE schalen als de beste. Weetje: de maximale grootte van een enkele Oracle database is ongeveer 8 Exabytes (8 miljoen Terabytes) en elke tablespace kan tot 128 Terabytes groot zijn.

Oracle biedt voor SE2 zonder meerprijs de Real Application Clusters optie waarmee u bij gebruik van gedeelde storage twee servers tegelijkertijd dezelfde database kunt laten aanbieden ter verhoging van de beschikbaarheid. Er geldt daarbij echter wel de beperkende voorwaarde dat het maximum gebruik van CPU-kracht in dat geval per server de helft is van wat voor een niet-RAC uitvoering is toegestaan (gecombineerd blijft de maximale CPU-kracht dus gelijk).

Beperkingen

De laatste jaren is het aantal cores per CPU drastisch toegenomen. Vier jaar geleden was een 6-core server-processor nog wel gebruikelijk; nu zijn 10 core-processors inmiddels gemeengoed en zijn 24-core Intel-processors exotisch maar verkrijgbaar.

Deze trend heeft het mogelijk gemaakt om maximaal te profiteren van het feit dat Oracle’s Standard Edition database wordt aangekocht per CPU (en niet per core) waardoor steeds krachtiger hardware kan worden gebruikt zonder een toename van licentie- en support-kosten. Bovendien is het inmiddels minder gangbaar om servers te gebruiken met meer dan een paar sockets omdat multi-core veel efficiënter is dan multi-CPU. Dat laatste heeft dan weer tot gevolg dat Standard Edition kon worden gebruikt op meer server-modellen.

Oracle heeft dit natuurlijk ook onderkend maar blijft gelukkig nog altijd socket-licensing hanteren voor Standard Edition 2. Wel wil men de doelen voor Standard Edition (“normale” workloads) in het oog houden en worden er twee beperkingen opgelegd. Ten eerste mogen er per fysieke server niet meer dan twee CPU-sockets worden gebruikt en ingeval van RAC slechts één per server. Daarnaast is elke database begrensd tot het gebruik van 16 CPU-threads (bijvoorbeeld 8 cores met Hyperthreading of 16 cores zonder HT). Ingeval het een RAC-database betreft is dat 8 threads per RAC-instance. Dit zal voor reguliere tot zelfs tamelijk forse workloads nog altijd ruim voldoende zijn en bovendien geldt de thread-beperking slechts per database. Indien u meerdere databases op een server draait kunt u nog steeds prima profiteren van alle aanwezige CPU-capaciteit, ook als die 16 threads (ruim) overtreft. Dit maakt server-consolidatie met SE2 nog steeds mogelijk en aantrekkelijk!

Verder zijn er geen beperkingen aan SE2 waar u rekening mee zou moeten houden. Wél is het zo dat Enterprise Edition ten opzichte van SE2 meer features biedt. Daarover nu meer.

Enterprise Edition (EE)

De volledige kracht van Oracle Database komt tot uitdrukking in de Enterprise Edition. Niet alleen heeft deze t.o.v. SE2 meer ingebouwde beheersnufjes maar bovendien is het hierbij mogelijk om (weliswaar tegen meerprijs) nog meer specialistische functionaliteit toe te voegen.

Op SQL-niveau is de basisfunctionaliteit op zichzelf niet heel veel anders dan in SE2. Wel zijn er enkele uitbreidingen die voor sommige applicaties handig zijn en die dan ook wel worden gebruikt. In zulke gevallen zal uw applicatieleverancier dan ook Enterprise Edition vereisen. Denk hierbij bijvoorbeeld aan Spatial of Partitioning. Afgezien van die functionele verschillen is het onderscheid tussen EE en SE2 vooral een kwestie van handvatten die (database)-beheerders krijgen om de data beter te beschermen, hoger beschikbaar te maken en de database-prestaties beter te laten zijn.

Betere prestaties

EE heeft t.o.v. SE2 extra resultaat-caches, dynamische query-optimalisatie  en -parallelisatie alsmede meerdere gelijktijdige data-streams bij RMAN-backup en database-export. Afhankelijk van de applicatie, de kracht van de server en samenstelling van de data kan dit een kleinere of grotere performance-winst opleveren en ook de backup versnellen.

Ook is het in EE mogelijk om bitmap-indexen te gebruiken die heel effectief kunnen zijn in het versnellen van queries op data waarin een beperkte variatie zit (J/N-kolommen bijvoorbeeld). Wij zien bitmap-indexen door sommige applicaties wel worden ingezet. Een bitmap index bepaalt per waarde in welke rijen deze voorkomt en gebruikt hiervoor minimale opslagruimte (die dan ook snel te lezen is).

Het volgende voorbeeld laat zien hoe een bitmap-index aangeeft dat de provincie Zuid-Holland is ingevuld in rijen nummer 2, 4 en 5.

Er staat dus een eentje bij de rij waarin hij voorkomt en een nulletje waar dat niet zo is. De database hoeft alleen de “waarde” 01011 uit de index-regel die bij ZH hoort te lezen om te weten welke rijen moeten worden opgehaald. Een traditionele index zou voor elke waarde de veel langere ROWID’s moeten opslaan ongeveer zo:

Dat is duidelijk meer leeswerk en kan flink aantikken wanneer een waarde in veel rijen voorkomt.

Een andere EE-optimalisatie is de mogelijkheid voor het gebruiken van data-compressie in tabellen. Met het in EE standaard aanwezige Basic Table Compression kunnen bepaalde acties (data-loads, Create Table as Select-statements, table moves) gebruik maken van sterk geoptimaliseerde data-opslag in de database. Aangezien database-prestaties doorgaans worden begrensd door de snelheid van het opslag-medium is het verminderen van de hoeveelheid te lezen en schrijven data normaliter de beste weg naar verbetering van prestaties. Anders dan je zou verwachten is het echter geen echte compressie zoals “zip” wat Oracle doet. In plaats daarvan werkt het voornamelijk via de-duplicatie van data en her-rangschikking voor maximale vulling van blokken bij het verwerken van in bulk aangeboden data. Vandaar ook dat de compressie alleen actief is tijdens de uitvoering van bepaalde bewerkingen; de tabel-data zelf wordt niet gezipped opgeslagen.

In EE is het mogelijk om aanvullende beheerfuncties in te zetten als onderdeel van het optionele Tuning Pack. Hiermee kan een DBA nauwkeuriger vaststellen waar eventuele vertraging optreedt en zo effectiever suggesties doen ter verbetering. Het Tuning Pack wordt gebruikt in combinatie met het Diagnostics Pack waardoor tevens meer real-time informatie beschikbaar is over de “gezondheid” van het database-systeem zelf.

Hogere beschikbaarheid, betere bescherming

Met EE kunt u Oracle Data Guard gebruiken voor het inrichten van uitwijkdatabases die altijd up-to-date zijn. Een Data Guard standby-database is eigenlijk een permanent meelopende backup-en-restore van een primaire produktie-database. Ingeval van beschadiging van een produktie-database kan een standby-database de functie snel overnemen zonder verlies van data. Het is een veelgebruikte feature van EE voor het opzetten van uitwijk-omgevingen en is in onze ervaring buitengewoon betrouwbaar.

Ook “onder water” zijn er in EE handige toevoegingen te vinden op het gebied van data-bescherming. Zo is het in de EE-uitvoering van RMAN mogelijk om beschadigde datafiles te herstellen zonder dat deze in hun geheel hoeven te worden gerestored en bijgewerkt. Dit scheelt tijd en bovendien is het mogelijk om dit zonder downtime van de getroffen tablespace te doen. Dit heet Block Media Recovery. Dergelijke beschadigingen kunnen bijvoorbeeld optreden door disk-defecten of disk-controller-problemen en komen in de dagelijkse praktijk helaas weleens voor. Voor degenen met de luxe van een Read-only query standby-database kan deze recovery zelfs geheel automatisch plaatsvinden door de database zelf.

Een ander handigheidje m.b.t. data-herstel is Flashback database. Standard Edition 2 biedt al de mogelijkheid om met “Flashback query” na te gaan hoe bepaalde data er eerder deze dag uitzag. Er wordt dan undo-data gebruikt om oudere inhoud van tabellen te raadplegen en u kunt terugkijken tot de oudst beschikbare undo-informatie in de UNDO-tablespace. Daar houdt het echter wel zo’n beetje mee op; data-herstel zal met de hand moeten gebeuren. Met de Enterprise Edition is het echter ook mogelijk om tabellen te “un”-droppen en zelfs de hele database zonder restore terug in de tijd te draaien. Dit kan heel waardevol zijn ingeval per ongeluk een ernstige data-entry fout is gemaakt die moet worden hersteld!

Tenslotte nog een ander beschikbaarheids-gerelateerd feature: online index-rebuild. In een SE2-database zal het eventuele herbouwen van indexen tot gevolg hebben dat deze indexen tijdelijk niet beschikbaar zijn en daardoor mag gedurende de herbouw-tijd de geïndexeerde data zelf ook niet worden gewijzigd. U zult daarvan tenminste hinder ondervinden en waarschijnlijk in de praktijk ook echt downtime. In EE is het mogelijk om index-rebuilds uit te voeren zonder downtime omdat Oracle dan bijhoudt welke wijzigingen plaatsvinden en deze aan het eind van de herbouw alsnog verwerkt in de nieuwe index. Bij grote indexen kan dat flink in downtime schelen.

Nog betere beveiliging

Enterprise Edition geeft de mogelijkheid om nauwkeuriger te volgen wat er in uw database gaande is. Dat geldt niet alleen voor performance-gerelateerde informatie maar ook voor “security”.

SE biedt al goede voorzieningen voor het uitvoeren van database-auditing. De database kan (zonder dat een gebruiker dit kan voorkomen) vastleggen welke tabel-raadplegingen/wijzigingen door “wie” worden gedaan. Overigens moet hierbij wel worden aangetekend dat de database niet altijd kan zien wie een eindgebruiker is omdat een applicatie dat vaak niet aan de database laat weten. Enfin, de database kan in ieder geval noteren wat hij wél weet en mogelijk kan dan in de applicatie worden nagetrokken met welke eindgebruiker dit overeenstemt.

Met Fine-grained auditing biedt EE daarboven de mogelijkheid om audit-gegevens vast te leggen wanneer specifieke kolommen worden geraadpleegd of gewijzigd. U kunt hiermee voor specifieke (gevoelige) informatie dus aanduiden of de database moet vastleggen dat deze is ingezien. In SE kan dat alleen op tabelniveau, wat mogelijk een hoop valse meldingen geeft omdat het geen onderscheid kan maken tussen wél en níet gevoelige informatie die zich in dezelfde tabel kan bevinden. Bovendien kan Fine-grained auditing zo worden geconfigureerd dat audit-informatie wordt vastgelegd bij raadpleging op bepaalde (verdachte) tijdstippen.

Het is aan de hand van de audit-informatie tamelijk eenvoudig om overzichten te genereren van opvallende activiteiten die met de juiste parameters een beeld kunnen opleveren van “verdachte transacties”. Natuurlijk is het, hopelijk veel vaker voorkomende, omgekeerde scenario ook interessant: database-auditing kan helpen bij het constateren dat bepaalde data niet door onbevoegden benaderd is geweest.

Een wel wat op Fine-grained auditing lijkende EE-feature is Virtual Private Database. VPD is een beetje de “handhavende” tegenhanger van het “registrerende” auditing. VPD werkt op rij-niveau en is bedoeld om te voorkomen dat bepaalde informatie überhaupt kán worden benaderd, zelfs als de gebruiker op tabel-niveau voldoende rechten zou hebben. VPD is een slimmigheid waarbij door middel van instelbare policies de toegangsrechten van een gebruiker worden beperkt tot alleen de data waar deze gebruiker zicht op mag hebben. Het lijkt wel een beetje op het gebruik van views maar is flexibeler en robuuster. VPD is zonder meerkosten inbegrepen bij EE.

Stel bijvoorbeeld dat een vestigingsmanager alle omzet wil opvragen uit de door zijn vestiging verkochte produkten. Het probleem is alleen dat er maar één tabel is waar alles instaat en dat deze alle verkopen bevat van alle vestigingen bij elkaar. Je zou dan d.m.v. views en meerdere schema’s zo’n opvraagfunctie speciaal voor deze vestiging kunnen bouwen maar dergelijke constructies worden na verloop van tijd kwetsbaar, er worden fouten gemaakt in rechten-toekenning en views kunnen problematisch zijn omdat ze niet altijd “updateable” zijn. VPD is in staat om met een policy aan te geven dat de vestigingsmanager zelfs bij een “select *” alleen de rijen terugkrijgt die aan bepaalde criteria voldoen, zoals bijvoorbeeld het feit dat ze bij zijn vestiging horen. Andere rijen zijn simpelweg onzichtbaar. Een doeltreffend beschermingsmechanisme dat complexe view/functie-constructies onnodig kan maken.

Tenslotte nog het summum van data-beveiliging in Oracle Database: Database Vault. Dit is een aanvullend gelicentieerde optie bovenop EE speciaal bedoeld voor het voldoen aan strenge wettelijke eisen zoals die van Sarbanes-Oxley en het Amerikaanse HIPAA. Het voert te ver om hier op te sommen wat daarmee allemaal mogelijk is; DV gaat qua mogelijkheden in ieder geval ver genoeg om uit te sluiten dat zelfs zogenaamde superusers/administrators zoals DBA’s en systeembeheerders uw data nog kunnen zien!

Wij hopen dat bovenstaande informatie een voldoende duidelijk inzicht geeft in de extra’s die EE biedt boven SE2 en of ze in uw ogen de benodigde meerkosten rechtvaardigen. Wij menen dat er voor elke omgeving in ieder geval de juiste Oracle-editie te vinden is!