De Database Experts!
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.
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:
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 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.
Om van een klassieke non-CDB database een single tenant PDB dan wel multitenant PDB te maken, zijn er twee mogelijkheden:
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.
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.
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:
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.
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.
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.
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.
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.
DBA.nl is de allround database expert gespecialiseerd in het inrichten, onderhouden, monitoren van database omgevingen. Daarnaast geven wij advies en nemen performance problemen weg.
Regelmatig brengt Microsoft nieuwe versies uit van Microsoft Windows Server. Wat zijn hier de gevolgen van? En hoe zorgt...
Details +
Regelmatig brengt Microsoft nieuwe versies uit van SQL Server. Lees hier meer. ...
Details +
Oracle brengt regelmatig nieuwe updates uit voor haar RDBMS. Door deze te installeren blijft uw database omgeving veilig...
Details +