Oracle 12cR2 Multitenant Environment: Introduzione

Dicono che nella vita e nel lavoro bisogna stabilire degli obiettivi, questi obiettivi devono essere ben definiti e devono essere “realistici”; questo allo scopo di trovare giuste motivazioni e stimoli, di crescere e di provare soddisfazione in ciò che si fa. Io non sono un gran esperto di questa materia, magari ne so qualcosa a livello pratico perché come ognuno di noi ho da risolvere molti problemi di vita quotidiana, sia personale che professionale, però non sono mai stato capace di studiarne la teoria; quando ci ho provato mi sono trovato a fare queste considerazioni: o si trattava di concetti banali che ognuno di noi conosce gia bene, oppure di cose che mi sembravano idiozie.

Il preambolo che ho fatto è dovuto al fatto che in un momento di ritrovata “tranquillità” ho deciso di provare a stabilire un nuovo obiettivo professionale. Dopo essere riuscito quantomeno a portarmi in pari con la preparazione su Oracle 12c (release 1) voglio avanzare con la versione 12cR2 e quindi 18c (che fra pochi mesi sarà 19…). Ho cominciato a scorrere i manuali e devo dire che la prima impressione che ho avuto è che la release 2 della versione 12c completi molte cose mancanti  della prima release.

Ho cominciato la mia analisi dall’argomento “multitenant enviroment”, cerco quindi, come ho sempre fatto qui, di riassumere un po’ di concetti. L’idea è di fare una panoramica generale, però usando come base di partenza la versione 12cR1, quindi non entrando nel dettaglio di cose che erano già state introdotte con la prima versione di Oracle 12c ma soffermandomi più nel dettaglio nelle novità introdotte con la seconda release.

Devo dire che ho sempre cercato di usare terminologie in un linguaggio coerente, in alcuni casi, dove era facil, con termini tradotti in italiano, il altri casi no. Questa cosa mi riesce sempre più difficile, quindi mi devo scusare se si troverà un po’ di confusione nei miei testi.

Multitenant Architecture

(Riferimento: Oracle Concepts)

Un container è un insieme di schemi, oggetti e strutture collegate in un multitenant container database (CDB). Il CDB root, anche chiamato “root” o “system root” (o anche root di sistema) è l’insieme di schemi e oggetti non di schema a cui tutti i PDB appartengono. Ogni CDB ha uno e uno solo “root container” chiamato CDB$ROOT. Tutti i PDB appartengono al root.  Si definisce “system container” il CDB root e tutti i PDB che appartengono a questo root. Oracle raccomanda di non creare oggetti e memorizzare dati utente nel CDB root.

Un PDB è un insieme di schemi, oggetti e strutture collegate che appaiono logicamente a una applicazione cliente come un database a se stante. Ogni PDB è di proprità di SYS che è un utente comune del CDB.

Ci sono diversi tipi di PDB:

  • Standard PDB, a loro volta possono essere:
    • PDB innestati nel CDB root
    • Application PDB
    • refreshable clone PDB (read only)
    • snapshot copy PDB, questi hanno la caratteristica di non poter essere poi scollegati (unplugged)
  • Application root, è un “root container” “application specific”, esso viene utilizzato come “repository” per la definizione globale (“master definition”) di un terminale per un’applicazione (“application back end”) dove sono inclusi dati e metadati comuni.
  • Seed PDB, si tratta di un modello di PDB da cui si possono creare nuovi PDB, ve n’è sempre uno di sistema nel CDB root chiamato PDB$SEED. Poi ci possono dei “application seed PDB” negli application container (nuovo oggetto introdotto in Oracle 12cR2 che verrà definito più avanti).
  • Proxy PDB, sono PDB che usano un database link per fare riferimento a un PDB su un CDB remoto. Per rendere l’idea si può pensare all’analogia con un link simbolico su un filesystem Linux.

E’ possibile accedere da un PDB a un’altro PDB con due metodi, uno gia dispobile con la prima release di Oracle 12c è quello del database link, l’altro invece, nuovo, è l’uso della clausola “CONTAINER()” nelle query. Per gli “application container”  esiste poi il concetto di oggetto comune.

Architettura del dizionario dati in un CDB

Al fine di ottimizzare e rendere flessibile il funzionamento del dizionario dati con l’architettura multitenant Oracle ha implementato delle soluzioni particolari.

Metadata e Data links

l’architettura multitenant si basa su dei “link” che permettono la condivisione di dati e/o metadati tra root e PDB. Giusto per fare un esempio semplice su una di queste tipologie di link si basa la condivisione delle definizione degli oggetti di sistema predefiniti sul database Oracle, si pensi giusto per citare un caso i vari package PL/SQL forniti. Ci sono tre tipologie di link:

  • Metatada link, i metadti degli oggetti di sistema (ad esempio la definizione delle tabelle TAB$, OBJ$, ….)stanno solo sul root, nei PDB ci sono dei metadata link che puntano ai metadati contenuti nel root per questi oggetti.
  • Data link, in 12cR1 venivano chiamati “Object Link”, usato ad esempio per i dati di AWR.
  • Extended data link, novita della R2 è un ibrido tra il data link e il metadata link. Riferisce oggetti nell'”application root” ma anche a corrispondenti oggetti negli “application PDB”

Oracle crea e gestisce metadata e data link verso CDB$ROOT, gli utenti non possono aggiungere, modificare o rimuovere questi link.

Container Data Objects

Un “container data object” è una tabella o vista contenente dati che riguardano più container o l’intero CDB. Un esempio di questa tipologia di oggetti sono le viste V$ e CDB_. Tutti i “container data object” hanno una colonna di nome CON_ID che permette di associare il dato della riga a un container.

Cross-Container Operations

Una “cross-container operation” (o operazione inter-container) è un comando DDL o DML che agisce su più container in una volta. Solo un utente comune connesso o al CDB root a un application root può eseguire “cross-container operation”.

Una cross-container operation può toccare:

  • il CDB
  • più container dentro il CDB
  • più “fenomeni” come ad esempio utenti comuni o role comuni
  • un container su cui l’utente che sta eseguendo il comando DDL o DML non è correntemente connesso

Esempi di operazioni inter-container sono la concessione di privilegi in modo comune a un utente comune da parte dell’utente SYSTEM, oppure un comando “ALTER DATABASE … RECOVER” che si applica all’intero CDB.

Quando si è collegati al CDB root a un application root si può eseguire un singolo comando DML per modificare tabelle o viste in più PDB nel container (CDB). Il database deduce i PDB obiettivo del comando dal valore della colonna CON_ID specificato nel comando DML. Se non è specificato nessuno CON_ID allora il database usa il valore della proprietà CONTAINERS_DEFAULT_TARGET specificato dal comando “ALTER PLUGGABLE DATABASE CONTAINERS DEFAULT TARGET.

Riporto un esempio dal manuale:

CONNECT sales_admin@saas_sales_ac
Password: *******

UPDATE CONTAINERS(sh.sales) sal 
  SET sal.country_name = 'USA' 
  WHERE sal.CON_ID IN (7,8);

Affinché funzioni questa tipologia di comandi l’oggetto deve essere definito allo stesso modo su tutti i PDB coinvolti.

Application Container

Siamo a una delle grosse novità della seconda release di Oracle 12c. Un “application container” (container per applicazioni?) è una componente opzionale, creata dagli  utenti di un CDB che può memorizzare dati e metadati per uno o più “application back end”. In un CDB ci possono essere zero o più application container. Per ogni application container ci sono essere zero o più PDB. Un application container ha una sua root chiamata “application root”, analoga alla root del CDB (che si chiama anche “system root”). Un application container viene create con il comando “CREATE PLUGGABLE DATABASE” con l’aggiunta della clausola “AS APPLICATION CONTAINER”, in questo modo viene create la “root” dell’application container, senza alcun PDB. La root rappresenta l’application container stesso. Per aggiungere PDB all’application container occorre collegarsi alla application root e da li lanciare i comandi di creazione.

Un application container ha un nome univoco all’interno del CDB e un service name che viene registrato sul listener per permettere un accesso remoto.

Un application container per certi versi può essere visto come un nuovo livello di astrazione ed è come un CDB all’interno di un’altro CDB, con in più la possibilità di avere dati e metadati condivisi tra più CDB. Questi dati e metadati vengono salvati nella application root.

In un application container si definisce “application” (applicazione) un insieme di dati e metadati che hanno un nome e che possono essere versionati. Una tipica applicazione installa utenti comuni dell’applicazione, oggetti comuni “metadata linked” (stessa definizione/struttura ma dati diversi nei vari PDB) e oggetti comuni “data linked” (dati e struttura comuni ai PDB).

Riporto una immagine dal manuale “Concepts” che mi sembra rappresenti in modo chiaro un esempio di uso di un “application container”:

Description of Figure 19-8 follows

Gli esempi fanno molti riferimenti a SaaS, Software as a Service, che sembra essere l’ambito per cui si è pensata  questa architettura. Si fanno anche esempi di architetture per datawarehouse, poi ognuno penso possa cercare di sfruttare questa nuova possibilità per sviluppare nuove idee.

Come accennato sopra nella application root di possono creare oggetti comuni, di tre tipologie:

  • data-linked common object. l’oggetto viene condiviso tra tutti i PDB sia come struttura che come dati
  • metadata-linked common object. Viene condivisa solo la struttura, ogni PDB avrà un suo insieme di dati.
  • extended data. In questo caso c’è sempre una struttura comune, poi c’è un insieme di dati comuni e infine ogni PDB aggiunge una sua parte di dati.

Per creare un oggetto comune nella application root si aggiunge alla DDL la clausola SHARING con il tipo di condivisione che può essere  “METADATA”, “DATA”,  “EXTENDED DATA” o “NONE”. Esiste anche un parametro “DEFAULT_SHARING” che stabilisce la tipologia di condivisione da adottare per default. Anche qui preferisco riportare dal manuale una tabellina riassuntiva:

Object Type SHARING Value Metadata Storage Data Storage
Data-Linked DATA Application root Application root
Extended Data-Linked EXTENDED DATA Application root Application root and application PDB
Metadata-Linked METADATA Application root Application PDB

Sul manuale vengono riportati anche degli esempi che aiutano a chiarire e comprendere meglio.

Quando abbiamo definito il concetto di “application” abbiamo detto che può essere versionata, non entro qui nel dettaglio ma voglio riportare un’altra immagine significativa dal manuale:

Description of Figure 19-9 follows

Il concetto importante secondo me è che l’applicazione viene aggiornata nella root. Aggiornare l’applicazione in sostanza significa eseguire alcune DDL (creare tabelle, aggiungere campi, ecc., …). Dopo ogni PDB viene sincronizzato, ovvero recepisce l’aggiornamento. Per gestire questa cosa Oracle crea un clone dell’application root a cui saranno collegati i PDB non sincronizzati. Se vogliamo alla fine il concetto è quello che si applica anche al meccanismo dell'”UNDO” del database.

Leggendo il manuale mi è venuta la curiosità di sapere se è possibile creare più “applicazioni” in uno stesso application container, voglio fare un prova per soddisfare questa curiosità.

Container Map

Una “container map” (mappa di container?) è un costrutto che permette a una sessione collegata a un application root di lanciare statement SQL che vengono indirizzati ad appropriati PDB, a seconda del valore di un predicato utilizzato nello statement SQL.

Una “map table” (mappa) specifica una colonna in una tabella comune “metadata-linked” e usa partizioni per associare ogni PDB dell’application container a diversi valori della colonna. Si tratta insomma di un partizionamento dati che ripartisce i dati fra PDB. Le compenenti per una “container map” sono quindi:

  • una tabella “metadata-linked”
  • una tabella mappa (o mappa o map table). Si tratta di una tabella con una sola colonna partizionata per liste, hash o range. I nomi delle partizioni di questa tabella mappa devono corrispondere ai nomi dei PDB e il nome della colonna deve corrispondere a una colonna della tabella “metadata-linked” del punto precedente.
  • Container map. E’ una proprietà del database che specifica il nome della mappa, si imposta dall’application root con il comando “ALTER PLUGGABLE DATABASE SET CONTAINER_MAP=>map_table>

La sintassi per creare la mappa è quella per le tabelle partizionate di Oracle Partitioning ma non è un tabella partizionata e non è neccessaria l’opzione Oracle Partitioning.

Services

Come accennato in precedenza per ogni PDB e per ogni application container viene creato per default un service name che viene registrato sul listener. Questo service name è uguale al nome del PDB o dell’application container. E’ possibile definirne altri fino a un massimo globale di 10mila. La sintassi del comando “ALTER SESSION SET CONTAINER” è stata estesa con la possibilità di specificare anche il service con la clausola “SERVICE”.

Shared e Local Undo Mode

Altra notevole novità è la possibilità di impostare un CDB nella modalità “local undo mode” in cui ogni PDB ha la sua tablespace di undo (il db crea automaticamente la tablespace in ogni PDB). Uno dei vantaggi di questa modalità è la possibilità di fare copie a caldo dei PDB. L’altra modalità viene definita “shared undo mode” ed è quella gia presente sulla prima release e che consiste nella condivisione di una unica tablespace di UNDO per tutto il CDB. Il passaggio da una modalità all’altra è possibile ma richiede il riavvio del database.

Flashback

Pur non essendo un accanito utilizzatore della funzionalità “Flashback database” credo che questa fosse perlomeno una cosa che mancava nella prima release, la possibilità di fare il flashback di un singolo PDB; a livello di PDB è possibile definire “restore point” normali o “guaranteed” (che non scadono mai e devono essere rimossi esplicitamente). Senza questa possibilità obiettivamente la funzionalità con l’architettura multitenant era inutile.

Resource Manager

Anche il resource manager  è stato migliorato per supportare meglio le nuove caratteristiche dell’architettura multitenant oltre per migliorare quanto gia presente.

Performance profile

Un performance profile specifica le “share” di risorse di sistema per un insieme di PDB. I PDB performance profile permettono di gestire risorse per un gran numero di PDB specificando direttive del resource manager per profile anziché per singolo PDB. Le direttive controllano l’allocazione di CPU e di processi per l’esecuzione parallela (parallel execution server), com’era gia nella versione 12.1 e come gia in quella versione è possibile definire dei limiti assoluti per CPU e processi paralleli.

Controllo della memoria a livello di PDB

E’ possibile configurare l’uso di memoria (SGA e PGA) a livello di singolo PDB usando i tre seguenti parametri per ciascun PDB:

  • SGA_MIN_SIZE. stabilisce una quantità minima di SGA riservata al PDB
  • SGA_TARGET, stabilisce la quantità massima di SGA utilizzabile dal PDB
  • PGA_AGGREGATE_LIMIT. stabilisce la quantità massima di PGA utilizzabile dal PDB.

Controllo dell’I/O a livello di PDB

Anche sull’I/O sono stati introdotti due parametri per limitare il consumo di risorse a livello di singolo PDB per sistemi non ingegnerizzati (cioè ad esempio non Exadata che ha gia meccanismi suoi per fare la stessa cosa), i parametri sono:

  • MAX_IOPS. limita il numero di IOPS per singolo PDB
  • MAX_MBPS. limita la banda in MB/s per le operazioni di I/O a livello di singolo PDB.

Character Set

Con la versione 12.2 è possibile avere PDB con diversi character set, questo a condizione che il CDB abbia come character set AL32UTF8, Oracle raccomanda (ed è impostato come default) l’uso del character set AL32UTF8 per il CDB. La documentazione dice che si possono anche creare (oltre che “innestare”) PDB con character set diversi, questa affermazione però pare fuorviante, qui si chiarisce quanto ho dedotto io cercando nella documentazione: non è possibile specificare un character set nella creazione di un nuovo PDB, occorre fare giri diversi.

 

Annunci

2 pensieri su “Oracle 12cR2 Multitenant Environment: Introduzione

  1. Pingback: Oracle 12cR2, primi test con gli Application Container | Oracle and other

  2. Pingback: Oracle 12cR2 Resource Manager: Performance profiles | Oracle and other

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...