Oracle Database 12c

Inmiddels alweer een aantal jaren geleden heeft Oracle de meest recente versie van z’n RDBMS software uitgebracht; 12c. Eind 2016 heeft release 12.2 het licht gezien en zit de eerstvolgende patchset 12.2.0.2 (ook bekend als Oracle Database 18, maar daarover later meer) eraan te komen. Tijd voor een korte update over de meest in het oog springende features van deze versie en een vooruitblik naar wat er gaat veranderen m.b.t. de naamgeving van dit product.

Multi-tenant

De grootste en meest opvallende wijziging in 12c is waarschijnlijk de introductie van de zogenoemde multitenant architectuur. Waar voorheen elke database altijd z’n eigen set aan systeem tablespaces bijvoorbeeld SYSTEM, SYSAUX, UNDO en TEMP had en daarnaast ook z’n eigen set aan achtergrond processen en geheugenstructuren (de instance), kan dit vanaf 12c ook op een andere manier opgezet worden. De multitenant optie introduceert de concepten van container database, CDB, en pluggable database, PBD. Het onderstaande plaatje toont in de basis de nieuwe opzet:

Van buitenaf gezien ziet een Container database, CDB, er vergelijkbaar uit met een conventionele Oracle database. Het bevat alle noodzakelijke onderdelen die nodig zijn om het geheel als database te laten functioneren. Denk hierbij aan de controlfiles, de (systeem) datafiles en de online redo logs, maar ook de achtergrond processen en geheugenstructuren. Alles wat samen de instance maakt, valt onder de CDB.

Elke CDB heeft daarnaast altijd de volgende containers:

• Root Container. Elke CDB heeft slechts één root container met de naam cdb$root. In de root zijn bijvoorbeeld de systeemtabellen, v$views en dbms-packages aanwezig. Ook eventuele extra opties zoals Spatial zitten in deze root container. Daarnaast bevat de root alle algemene gebruikers (bijv. SYS en SYSTEM) en rollen die nodig zijn om de CDB als geheel te kunnen beheren. De root bevat dus geen gebruikers data.
• Pluggable Databases, PBD. Een CDB bevat één of meerdere PBD’s. Een PBD is een door de gebruiker gecreëerde set van schema’s, objecten en gerelateerde structuren die er voor de buitenwereld uitzien en benaderbaar zijn als een aparte database. Aangezien alle basis onderdelen van een database in de root container zitten, hoeft de PDB dus alleen maar informatie te bevatten die specifiek voor hemzelf zijn. Hij hoeft zich niet druk te maken om controlfiles, archivelogs, etc.. Een PDB bestaat dan ook alleen maar uit datafiles en tempfiles om z’n eigen gebruikers objecten op te slaan. Daarnaast bevat het een eigen data dictionary met daarin alleen de metadata specifiek voor die PDB.
• Seed Database Dit is een template database die gebruikt wordt om snel een nieuwe PBD aan te kunnen maken.

Het belangrijkste dat uit bovenstaande opgemaakt kan worden, is dat met de multitenant optie de gebruikers data gescheiden wordt van de rest van de database. Dit heeft een aantal voordelen:

• Een PDB kan eenvoudig gekopieerd of verplaatst worden naar een andere CDB met dezelfde versie. Het enige dat daarvoor gedaan hoeft worden is de PBD loskoppelen van de oorspronkelijke CDB en deze weer koppelen aan de nieuwe CDB. Dit kan bijvoorbeeld van pas komen als een test database nodig is, of als deze ververst moet worden met productie data.
• Het aanmaken van een nieuwe database gaat in de multitenant omgeving sneller en eenvoudiger dan voorheen; dit is een kwestie van een kopie maken van de altijd aanwezige ‘seed’ database. Er hoeft nu geen aparte instance gecreëerd te worden en niet de gehele data dictionary en alle dbms-packages hoeven opnieuw aangemaakt te worden; dit kost in de huidige non-CDB-architectuur meestal veel tijd.
• Het upgrade proces is eenvoudiger en in theorie sneller. In het kort komt het erop neer dat je de PBD loskoppelt van de oude CDB en vervolgens koppelt aan een CDB die met de nieuwe software versie draait. Je moet dan nog een soort upgrade script uitvoeren en de database is geüpgraded.

Een algemeen voordeel van de multitenant optie is dat het gebruikt kan worden om een consolidatie slag te maken, waarbij een aantal losse database servers met veel kleine databases, teruggebracht kan worden naar 1 of enkele database servers met een multitenant architectuur.

Zoals dat voor meer Oracle Database opties geldt, is ook de multitenant optie alleen beschikbaar in de Enterprise Editie (EE) en is het daar een extra te licentiëren optie. Desondanks heeft Oracle de non-CDB architectuur vanaf 12.1.0.2 aangemerkt als deprecated, wat inhoudt dat het op de langere termijn zal gaan verdwijnen. Om niet EE klanten tegemoet te komen is het mogelijk om een container database aan te maken met daarin een enkele pluggable database. Dit wordt een ‘Single Tenant’ of ‘Lone-PDB’ genoemd en is vrij beschikbaar in alle database edities. Dat betekent ook dat het toegestaan is om meerdere CDB’s op één server te hebben, elk met een enkele PDB. Op die manier is het dus mogelijk om een vergelijkbare omgeving te creëren als bij het gebruik van de klassieke non-CDB architectuur. Alleen wanneer men gebruik wil maken van meerdere PBD’s in een enkele CDB, moet de multitenant optie aangeschaft worden.

Daarmee is de weg vrij om toekomstige database omgevingen in te richten op basis van deze nieuwe architectuur. Ook als men niet beschikt over de benodigde licenties kan men toch gebruik maken van een aantal van de voordelen, zoals het vereenvoudigde upgrade proces en het gemak waarmee een kloon van een database gemaakt kan worden.

Migratie en Upgraden

Om van een klassieke non-CDB database een single tenant PDB dan wel multitenant PDB te maken, zijn er twee mogelijkheden:

1. 1. Gebruik van datapump export en import.Deze methode werkt ook voor het omzetten van een pre-12c database naar de nieuwe tenant architectuur. Daarbij wordt de data geïmporteerd in een vooraf aangemaakte lege PDB.
   2. De bestaande non-CDB database converteren naar een PDB.In hoofdlijnen komt het er op neer dat met de procedure DBMS_PBD.DESCRIBE een xml gemaakt wordt van de bestaande non-CDB database, met daarin informatie over de database structuur. Op basis van dit xml bestand wordt dan een PDB aangemaakt waarbij de datafiles van de non-CDB hergebruikt worden. Het script ‘noncdb_to_pdb.sql’ converteert vervolgens de database daadwerkelijk naar een bruikbare PDB.

Een bestaande CDB in z’n geheel upgraden, kan eenvoudig op de gebruikelijke manier uitgevoerd worden m.b.v. de DBUA, of door het handmatig uitvoeren van de benodigde scripts.
Het upgraden van een enkele PDB kan worden gedaan door deze los te koppelen van bestaande CDB en vervolgens te koppelen aan een CDB met een hogere versie. Na het uitvoeren van een upgrade script in de PDB is deze geüpgraded. Er moet dus nog steeds een upgrade script uitgevoerd worden, maar deze zal in de praktijk sneller klaar zijn dan hetzelfde catupgrd.sql script in de klassieke non-CDB database.

Nieuwe naamgeving Patchsets

Vanaf de eerste patchset voor 12.2 gaat Oracle de naamgeving van zijn Oracle Database product volledig op de schop nemen. Dit betekent dat patchset 12.2.0.2 in de praktijk “Oracle18” zal gaan heten en de daarop volgende patchset (12.2.0.3) “Oracle 19”. De term patchset zal daarmee geheel verdwijnen en er zullen in de toekomst jaarlijkse releases komen waarbij de versie gelijk zal zijn aan de laatste twee cijfers van het release jaar. De huidige patch terminologie wordt vervangen door Release Updates (RU) en Release Update Revisions (RUR). Beide worden elke kwartaal uitgebracht waarbij de eerste vergelijkbaar is met een proactieve bundle patch en de tweede met de huidige CPU’s. De nieuwe naamgeving is met ingang van Q1 2018 al ingegaan voor de Oracle Public Cloud en de on-premise engineered systems, zoals ODA en Exadata. Vanaf juli 2018 zullen de overige on-premise platformen (non-Engineered Systems) overgaan naar deze nieuwe naamgeving.

Overige verbeteringen

Zoals gezegd is de introductie van de multitenant architectuur de grootste verandering in Oracle Database 12c en mogelijk zelfs de grootste verandering ooit. Daarnaast zijn er echter nog 500+ verbeteringen waarvan een aantal voor het dagelijks gebruik door een dba zeker interessant zijn. Hieronder volgt een kleine selectie:

Rman DUPLICATE

Er is een optie ‘NOOPEN’ aan het Rman DUPLICATE commando toegevoegd. Hiermee kan voorkomen worden dat het duplicaat wordt geopend aan het eind van de dupliceer actie. Dit maakt het mogelijk om eerst nog aanpassingen te doen voordat de database definitief geopend wordt. Ook is deze feature erg handig bij upgrade scenario’s waarbij de database niet geopend mag worden voordat de upgrade scripts zijn uitgevoerd.

Data Pump

Vanaf 12c is het mogelijk om, specifiek alleen voor de geïmporteerde data, het redo log mechanisme uit te zetten. Hiervoor is de nieuwe parameter TRANSFORM geïntroduceerd. Wanneer DISABLE_ARCHIVE_LOGGING wordt meegegeven aan deze parameter, zal er voor de objecten die geïmporteerd worden geen redo data aangemaakt worden. Deze optie voorkomt het aanmaken van enorm veel redo data en archivelogs tijdens de import van grote tabellen en zal daarmee ook de import versnellen. Tot nu toe kon dit alleen voorkomen worden door de gehele database tijdelijk uit archivelog mode te halen, wat inhoud dat de database 2x herstart diende te worden.

Restore/Recover datafiles over het netwerk

Een andere grote verbetering in 12c is dat het nu mogelijk is om in een DataGuard configuratie een enkele data file, control file, spfile, tablespace of zelfs gehele database via het netwerk te kunnen kopiëren van de primaire database naar standby databases en visa versa.
Dit is vooral handig voor het synchroniseren van standby databases in een situatie waarbij deze ver achterloopt op de primary database en bijvoorbeeld de benodigde archivelogs niet direct meer voor handen zijn. Niet langer is een complexe roll-forward procedure nodig om het gat te dichten, maar nu kan m.b.v. RMAN een incrementele back-up gemaakt worden van de primaire database en via het netwerk wordt de standby database hier dan rechtstreeks mee bijgewerkt. Andersom is het ook mogelijk om een datafile in de primaire database te herstellen door deze rechtstreeks te kopiëren vanuit de standby database.

Parallelle upgrade

De doorlooptijd van een database upgrade is direct gerelateerd aan het aantal componenten aanwezig in de database en minder aan de grootte van de database. In voorgaande versies was het niet mogelijk om een upgrade te versnellen, maar vanaf 12c kan dit wel door gebruik te maken van parallellisatie. Hiervoor wordt de parallel-upgrade utility meegeleverd in de vorm van een perl script. Hiermee kunnen 2 of meer parallelle processen gestart worden die de uiteindelijke upgrade uitvoeren. De DBUA geeft grafisch de mogelijkheid om het aantal processen aan te geven en maakt onderwater automatisch gebruik van deze nieuwe utility.

Online hernoemen en verplaatsten van een actieve datafile

In tegenstelling tot in voorgaande versies, is het in 12c niet meer noodzakelijk om een datafile eerst offline te brengen voordat deze hernoemd of verplaatst kan worden. Het is nu mogelijk om dit direct met een eenvoudig ALTER DATABASE MOVE DATAFILE statement uit te voeren. Gebruikers kunnen, terwijl de datafile wordt verplaatst, gewoon DML en DDL uitvoeren op de objecten in de datafile. Dit is erg handig in een situatie dat een datafile per ongeluk op een verkeerde locatie staat, maar kan ook gebruikt worden om datafiles te verplaatsen naar nieuwe storage zonder dat de database gestopt hoeft te worden. Ook een online migratie van en naar ASM storage hoort hiermee tot de mogelijkheden.