CV Edwin Kessels

In dit artikel worden enkele belangrijke nieuwe features van de Oracle 11g database beschreven. Deze nieuwe features kunnen van belang zijn bij de keuze van de manier van inrichting van een nieuwe database of de migratie van een bestaande database naar versie 11g.

Automatic Memory Management (AMM)

Oracle heeft al vele verbeteringen doorgevoerd op het gebied van geheugenmanagement. In Oracle9i werd Automated PGA ingevoerd, een nieuwe geintegreerde area ter vervanging van vele kleine gebieden zoals sort_area en dergelijke. Dit was al een flinke verbetering. In Oracle 10g werd de SGA_TARGET geintroduceerd. In Oracle 11g is het opnieuw verbeterd: een enkel geheugengebied voor zowel de SGA als de PGA: Automatic Memory Management.

Automatic Memory Management wordt geconfigureerd met slechts 2 parameters. Met behulp van de parameter MEMORY_TARGET kan worden gespecificeerd hoeveel shared memory er beschikbaar is voor het (dynamisch) zo optimaal mogelijk toekennen van geheugen voor de SGA en PGA. De parameter is dynamisch en de standaard waarde is 0.

De parameter MEMORY_MAX_TARGET specificeert de maximale waarde die voor MEMORY_TARGET kan worden ingesteld zonder dat een herstart van de instance noodzakelijk is. Om optimaal gebruik te kunnen maken van AMM in Oracle 11g, moeten de waarden van SGA_TARGET en PGA_AGGREGATE_TARGET op 0 worden gezet.

Case-sensitive wachtwoorden

In Oracle 11g is het mogelijk om gebruik te maken van wachtwoorden die case-sensitive zijn. Eindelijk zou ik zeggen want persoonlijk vind ik dit een belangrijk requirement. Wanneer er een nieuwe Oracle 11g database wordt aangemaakt, is dit de standaard situatie. Indien de database met DBCA (Database Configuration Assistant) wordt aangemaakt, bestaat er nog wel de mogelijkheid om hiervan af te wijken. Met behulp van de SEC_CASE_SENSITIVE_LOGON parameter kan het gewenste gedrag worden ingesteld:

 

Wanneer de parameter SEC_CASE_SENSITIVE_LOGON op FALSE staat, wordt er niet naar de case van het wachtwoord gekeken:

Bij het toekennen van een wachtwoord aan een gebruiker (ook al staat de parameter SEC_CASE_SENSITIVE_LOGON op FALSE), wordt het wachtwoord exact zo opgeslagen als ingevoerd. Wanneer SEC_CASE_SENSITIVE_LOGON op TRUE wordt gezet komt het wachtwoord dus precies overeen zoals het initieel is ingevoerd.

De wachtwoorden in de password-file zijn ook case-sensitive. Met de optie ingnorecase=y kan hiervan worden afgeweken (ingnorecase=y is default).

Onzichtbare indexen

Soms slaat de fantasie van de ontwikkelaars bij Oracle een beetje op hol. Invisible indexen is hiervan een voorbeeld. Waarschijnlijk is deze feature ontwikkeld voor hele specifieke doeleinden. Het enig wat ik kan bedenken waarvoor deze handig zou kunnen zijn, is dat een index die nodig is voor een bepaald bedrijfsproces nadelig zou kunnen zijn voor overige processen.

Een invisible index wordt niet door de Cost Based optimizer meegenomen bij het bepalen van het executie-plan; vandaar dat deze onzichtbaar is. Op sessie niveau kan echter worden ingesteld dat onzichtbare indexen wel mee moeten worden genomen door de optimizer. Hiermee zal het executie-plan in een dergelijkse sessie er dus anders kunnen uitzien. Hieronder volgt een voorbeeld van het gebruikt van een invisble index op sessie-niveau. Als voorbeeld wordt de tabel big_table gebruikt welke in het veld ID de waarde 0 tot en met 100000 bevat. Op deze tabel wordt de volgende invisible index aangemaakt:

 

Zoals uit bovenstaand plan blijkt, wordt de index niet gebruikt. Wanneer nu op sessie-niveau wordt ingesteld dat invisible indexes gebruikt moeten worden, zit het er ineens anders uit:

 

Een index die invisible is aangemaakt, kan weer visible worden gemaakt (en vice versa):

De visability van een index (zichtbaar of juist niet zichtbaar) kan worden bepaald aan de hand van de visibility-kolom in de [DBA|ALL|USER]_INDEXES views.

Read-only tabellen

Opnieuw een feature waarover wat langer moet worden nagedacht om er een toepassing voor te vinden: de read-only table. Tot Oracle 11g kan een read-only tabel worden aangemaakt door alleen maar het select-privilege aan gebruikters toe te kennen. Voor de owner van de tabel is deze wel altijd muteerbaar. Tot versie 11g waar het alter table .. read only commando de tabel ook voor de owner read-only maakt

Een read-only tabel kan weer muteerbaar worden gemaakt met behulp van het alter table read write commando. En en ander wordt hier onder uiteengezet met behulp van een voorbeeld:

 

Een DELETE en UPDATE (DML) commando geven uiteraard dezelfde foutmelding. Ook DDL (TRUNCATE, toevoegen nieuwe column) geven dezelfde foutmelding.

De status van de tabel (read-only of read-write) kan worden bepaald aan de hand van de READ_ONLY kolom in de [DBA|ALL|USER]_TABLES views.

Tablespace encryptie

In Oracle 10g was al een begin gemaakt met het encrypten van data in een datafiles. In Oracle 11g is dit doorgetrokken naar encryptie op tablespace-niveau.

Voor de encryptie van een tablespace wordt een sleutel gebruikt. Deze sleutel wordt opgeslagen in een wallet. Deze moet worden aangemaakt voordat de tablespace kan worden versleuteld. De locatie van de wallet kan worden opgegeven met de parameter ENCRYPTION_WALLET_LOCATION (eerste in zoekpad) in de sqlnet.ora file. Ook de parameter WALLET_LOCATION (tweede in zoekpad) in de sqlnet.ora file kan worden gebruikt voor het aangeven van de lokatie. Indien de lokatie niet met een van de twee parameters is gespecificeerd, zoekt Oracle in de default lokatie: $ORACLE_BASE/admin/$ORACLE_SID/wallet.

De volgende definitie kan worden opgenomen in de sqlnet.ora om de lokatie van de wallet te specificeren:

De directory moet wel bestaan (met de goede rechten); de directory wordt namelijk niet door Oracle automatisch aangemaakt. Een Wallet kan worden aangemaakt met behulp van onderstaand statement

Met behulp van het volgende commando kan een versleutelde tablespace worden aangemaakt:

 

Met behulp van ENCRYPTION kan worden gespecificeerd dat er versleuteling moet worden toegepast. Met USING (AES256) kan worden aangegeven welke encryptie-methode gebruikt moet worden. Indien de USING-clausule niet wordt gespecificeerd wordt AES128 gebruikt. Ook moet DEFAULT STORAGE (ENCRYPT) worden gespecificeerd voor versleuteling.

In de kolom encrypted in de DBA_TABLESPACES view kan worden bepaald of een tablespace versleuteld is of niet.