Oracle Migratie | Migreren naar de nieuwste versie van Oracle Database

Veel van onze klanten gebruiken (om goede redenen) nog Oracle versie 11g databases. Ondanks dat er over de bruikbaarheid en betrouwbaarheid daarvan eigenlijk niet te klagen valt is het inmiddels al wel meer dan 7 jaar geleden dat 11.2 werd uitgebracht. In 2013 is versie 12.1 van Oracle Database op de markt gekomen en ondertussen is versie 12.2 zelfs al beschikbaar voor zowel On-premise gebruik als voor de Oracle Cloud.

In dit artikel willen wij een lans breken voor de nieuwere database-versies. DBA.nl meent dat het voor iedereen de moeite waard is een upgrade naar versie 12 voor te bereiden. Oracle 12is het te gebruiken platform, enkel in gevallen waarin het echt niet anders kan, bijvoorbeeld de applicatie-leverancier ondersteunt alleen 11.2, zou het een overweging zijn om geen Oracle migratie uit te voeren. 

Waarom migreren vanaf database 11.2 ?

Wij kunnen ons voorstellen dat het niet voor de hand lijkt te liggen om tijd (en geld) te investeren in een upgrade wanneer de bestaande omgeving goed werkt. Tenslotte geeft elke wijziging onzekerheid en (ook) in de IT-wereld is het adagium “if it ain’t broken, don’t fix it” welbekend. Toch is de werkelijkheid genuanceerder. Zoals wij in onze publicatie aangaande Oracle Support ook aangeven zijn er grenzen aan de bereidheid van Oracle om oudere software tegen een normaal tarief actief te blijven ondersteunen, een Oracle update is dus een overweging. Voor een softwareproducent is het namelijk geen sinecure om complexe oudere software te blijven voorzien van (security)-fixes en te testen met de laatste platform-updates. Dit nog naast de noodzaak de kennis in hun support-organisatie op peil te houden en er zorg voor te dragen dat de software überhaupt nog “compileerbaar” is op moderne servers en operating systems. Het is dan ook niet gek dat Oracle de notie van “extended support” gebruikt om oudere Database-releases alleen tegen een hoger tarief dan dat van het gebruikelijke “premier” support te ondersteunen. In tegenstelling tot eerdere berichten heeft Oracle recent besloten het “gratis” extended support op het laatste patchlevel (11.2.0.4) te verlegen tot eind 2018. In juni 2018. Het is tot die datum nog zo dat Oracle een overgangsregeling hanteert waarin het support-tarief gelijk is aan dat van “premier”, hoewel 11.2 al sinds 2015 in “extended” support zit. Het houdt echter ooit een keer op. Hierbij een overzicht van Oracle’s ondersteuningstermijnen en niveaus:

Kort samengevat is de nuttige levensduur Oracle database versie 11.2 inzicht en gaat de ondersteuning ervan vanaf einde 2018 in beginsel extra kosten met zich meebrengen. Ondanks het feit dat eind 2018 nog ver weg lijkt komt er vanuit de kant van diverse applicatieleveranciers druk om te stap naar Oracle 12c te gaan maken, een update Oracle naar de nieuwste versie is altijd verstandig.

Wat brengt Oracle Database 12c?

We kunnen onderscheid maken tussen Oracle database 12c (12.1) en versie 12cR2 (12.2).

Releases 12.1 en 12.2 bevatten teveel nieuwe features om op te noemen; we beperken ons hier tot een selectie van punten die voor onze klanten waarschijnlijk het meest interessant zijn. Alle genoemde features bevinden zich al in de Oracle update van versie 12.1 en zijn waar mogelijk verder verbeterd in de 12.2 update Oracle.

Temporary undo

Het is nu mogelijk een database-parameter in te stellen die ervoor zorgt dat transactie-informatie voor expliciet tijdelijke data (zogenaamde global temporary tables) zélf ook als tijdelijke data wordt beschouwd. Dit vermindert de overhead voor dergelijke data enorm. Deze parameter kan op sessie-niveau (door een appplicatie) worden gezet en hoeft dus niet persé voor de hele database te worden gezet.

ASM Disk Scrubbing

Veel van onze klanten maken gebruik van Oracle’s ASM storage-software. Deze heeft in versie 12 veel verbeteringen gekregen waarvan één vooral van belang is voor lange-termijn betrouwbaarheid van data. Een standaard filesystem kan op termijn beschadigd raken zonder dat iemand het merkt (dat wordt wel “bit rot” genoemd). Dergelijke beschadigingen zijn niet vast te stellen als data niet van checksums is voorzien en zelfs áls dat het geval is wordt data-corruptie nog steeds pas zichtbaar wanneer deze data+checksums daadwerkelijk worden gelezen. In versie 12c kan ASM in de achtergrond pro-actief data lezen en corruptie automatisch herstellen (wanneer ASM met Host-Based Mirroring is geconfigureerd). Het is hierdoor geen zorg meer dat sommige data vrijwel nooit worden gelezen.

ACFS verbeteringen

Het ACFS-filesystem (een traditioneel ogend bestandssysteem bovenop ASM) is nu op een RAC-omgeving bruikbaar voor alle type database-bestanden. Hierdoor is het nu mogelijk om ASM te gebruiken en toch op een gebruiksvriendelijke manier de database-bestanden te benaderen via ACFS. ACFS biedt enkele voordelen t.o.v. een traditioneel filesystem zoals NTFS (Windows) en ext4 (Linux). Voordelen zijn bijvoorbeeld:

• Bruikbaar als shared storage (cluster aware en verhoogd beschikbaar)
• Ondersteunt snapshots
• Profiteert van redundancy, striping en auto-repair van ASM
• Data wordt automatisch herverdeeld wanneer een disk wordt toegevoegd en verwijderd.
• Performance: geoptimaliseerd voor database-workloads.

Flex ASM

Het is sinds versie 12 voor het eerst mogelijk om ASM-instances los te koppelen van databases die ASM-storage gebruiken. Met Flex ASM hoeft een ASM-instance niet meer op dezelfde server te staan als de databases. Een cluster van ASM-instances kan hoog beschikbare ASM-storage leveren aan databases op willekeurig welke server (zolang de fysieke storage maar voor alle servers benaderbaar is).

Multitenancy

Oracle 12 Enterprise Edition introduceerde de mogelijkheid om meerdere databases relatief eenvoudig te consolideren. Een standalone database kan eenmalig worden ingelezen in een “pluggable database” (PDB) en bevat daarna nog slechts een lichtgewicht subset van de Oracle Data Dictionary in plaats van het (zware) volledige systeem. Een PDB wordt beheerd via een overkoepelende Container databse (CDB). Grafisch weergegeven ziet dat er als volgt uit:

Een pluggable database gedraagt zich precies hetzelfde als een “standalone” database. Het is dus niet nodig applicaties op enigerlei wijze aan te passen.

Hiermee is consolidatie van applicatie-databases veel eenvoudiger geworden. Voorheen werd om redenen van afscherming en het voorkomen van conflicten in schema-naamgeving en rechten vaak gekozen voor het inzetten van één database per applicatie. Dit is weinig efficiënt omdat elke database-instance een gegarandeerde hoeveelheid geheugen moet krijgen en een minimum aantal huishoudelijke achtergrondprocessen moet draaien. Ook als de database niets staat te doen zijn deze geheugen en CPU-resources toch in gebruik. Voor elke database-instance wordt deze “overhead” gedupliceerd. Met de multitenant option is het mogelijk om meerdere databases onder één instance te plaatsen terwijl elke database voor de applicatie toch een volledige, zelfstandige instance lijkt te zijn. De pluggable databases kunnen profiteren van de aan de overkoepelende CDB toegewezen resources en hoeven ook niet elk hun eigen achtergrondtaken te draaien. Dit kan onnodige overhead voorkomen en vermindert bovendien de hoeveelheid te beheren/onderhouden/patchen database-instances. En ten slotte is het ook nog mogelijk om een pluggable database te verhuizen naar een andere (hogere versie) CDB op een ander systeem (“inpluggen”). Dit kan een voordeel opleveren bij toekomstige migraties.

Multitenant is een betaalde optie (de prijs is gelijk aan die van de “Spatial” optie) voor Enterprise Edition maar door de potentiële reductie van beheer en hardware-resources kan het wel degelijk interessant zijn. In sommige gevallen is het zelfs mogelijk dat uw bestaande licentie deze option al dekt.

Naast multitenant is het (zelfs in Standard Edition) mogelijk om dezelfde “database virtualisatie”-techniek toe te passen voor één enkele pluggable database. Dit wordt “single tenant” genoemd en vereist geen extra licentie. Ook dit kan toekomstige versie-upgrades vergemakkelijken omdat ook in dit geval uitpluggen-en-inpluggen kan worden gebruikt i.p.v. een in-place upgrade of datapump export/import.

RMAN tabel-niveau recovery

Met enige regelmaat zien wij situaties waarbij een onverwachte (applicatie-)fout ertoe leidt dat data teruggezet moet worden van back-up. Niet altijd is een up-to-date datapump-export aanwezig en dan moet worden teruggevallen op een volledige restore van de betreffende database. Dat is niet altijd gewenst; waarom zou de hele database moeten worden teruggezet als er slechts een deel is beschadigd ? Met Oracle 12c wordt het relatief eenvoudig om alleen de tabellen terug te lezen die nodig zijn. Onder water voert RMAN alle activiteiten uit die nodig zijn voor een restore+export+import van het stukje data waar het om gaat. Dit gaat veel sneller dan wanneer een DBA dit allemaal met de hand zou moeten opzetten en uitvoeren.

Meer DDL zonder locking

In 12c is het mogelijk om meer structurele aanpassingen aan tabellen/indexen te doen zonder dat actieve gebruikers hier hinder van hebben. Meer DDL-statements ondersteunen nu de “online”-optie waardoor het minder bezwaarlijk wordt om bijvoorbeeld index-onderhoud gedurende produktietijd uit te voeren.

Online datafile move

Het komt weleens voor dat over tijd een database bestanden krijgt op niet-optimale locaties. Mogelijk is een tablespace ooit verkeerd aangemaakt of zijn er disk-reorganisaties geweest. Om alle datafiles weer netjes te organiseren was voorheen downtime nodig. De datafile moest offline worden gezet en worden gekopieerd naar een andere locatie. Vanaf 12c kan de verplaatsing gebeuren terwijl alles gewoon online blijft.

DDL-logging

Database-auditing was altijd al mogelijk maar was verhoudingsgewijs lastig correct in te richten en te onderhouden en had invloed op de database-performance. Met 12c wordt het mogelijk om DDL-statements (“alter”,”drop”,”create”, etc.) naar een tekstbestand te laten schrijven zodat eenvoudig kan worden bekeken wanneer welke structurele wijzigingen zijn aangebracht aan de database. Dit is een hulpmiddel bij troubleshooten van storingen na wijzigingen.

Unified auditing

Ondanks dat auditing zoals vermeld niet heel simpel was kan het van grote waarde zijn bij het voldoen aan wettelijke data-beschermingseisen. In 12c is auditing sterk verbeterd en een stuk eenvoudiger te beheren dankzij de zogenaamde “unified audit trail” die alle auditing-informatie bundelt. De performance van auditing is bovendien sterk verbeterd zodat er meer situaties zullen zijn waarin het interessant kan worden auditing in te schakelen zonder de database-prestaties merkbaar negatief te beïnvloeden.

DataPump-verbeteringen

Datapump export en import worden veel gebruikt. In 12c is dit verder verbeterd met de mogelijkheid gedetailleerde informatie te krijgen over tijdsverloop. Bovendien is er nu de mogelijkheid om imports veel sneller te laten verlopen met een “nologging”-optie.

Algehele verbeteringen

Tenslotte nog is er veel werk gemaakt van verbeteringen op het gebied van performance en betere diagnostische informatie en zijn er weer extra SQL-functies toegevoegd voor ontwikkelaars.

In conclusie is Oracle Database 12c sterk verbeterd t.o.v. versie 11.2 en een waardige upgrade. Nog afgezien van het belang van het up-to-date blijven voor ondersteuning (Oracle support) is er eigenlijk geen reden te bedenken om níet te upgraden naar 12c en hebben wij ook niet meegemaakt dat een upgrade tot applicatieproblemen heeft geleid. Bij het upgrade-proces naar 12c zal DBA.nl u dan ook graag ondersteunen.