Oracle 12cR2 for DBA
La disponibilita' on-premise
della versione 12cR2 di Oracle [NdE 6 marzo 2017]
e' un argomento troppo importante per non analizzarlo compiutamente.
Non si tratta solo di una release di consolidamento,
come Oracle ci ha abituato con molte Release 2,
ma di una nuova versione con importanti e significative novita'
per la gestione e per l'utilizzo di Oracle anche in Cloud.
Le modifiche della versione 12cR2 sono tanto importanti e significative che cambieranno,
a mio avviso, la progettazione di architetture ed il modo di lavorare
per chi amministra database Oracle.
Questo documento riporta le principali novita' introdotte
nella nuova versione sottolineando le operative che hanno
maggior impatto per la bistrattata categoria dei DBA.
Il taglio del documento e' pratico.
Dopo una noiosa introduzione [NdE che si puo' saltare 🙂]
con le diverse release della versione 12c
e la descrizione dell'opzione multitenant
si passa a semplici esempi per ogni funzionalita' descritta.
Gli esempi riguardano
il Multitenant,
gli Application Containers,
l'In-Memory,
lo Sharding,
il Cloud,
...
Nonostante l'utilizzo di esempi per leggere questa pagina e' necessaria
una buona conoscenza dell'RDBMS Oracle e delle problematiche DBA.
Funzionalita' Oracle 12c
La versione 12c e' disponibile da luglio 2013 con molte novita'
nell'architettura:
Flex Cluster,
Multithreaded model,
Enterprise Manager Database Express,
Heat Map,
RMAN single table restore,
clausola LIMIT, ...
Oltre a queste e' stata sopratutto introdotta la Multitenant Option.
In tale architettura l'istanza del CDB (Container Database) mantiene al suo interno
diversi PDB utilizzando lo stesso set di processi e di strutture interne.
Dal punto di vista delle applicazioni invece i PDB vengono visti come
normali istanze Oracle.
Sono pero' presenti una serie di limitazioni sui PDB (Pluggable Database):
non sono infatti supportati sui PDB: Character Set differenti, l'Active DataGuard, il Flashback,
l'Hot Clone [NdA ed anche il clone aveva qualche problemino], ...
La versione 12.1.0.2, disponibile da luglio 2014, ha introdotto l'Option
In-Memory ed una serie di funzionalita'
minori ma molto utili (eg. advanced index compression, JSON support,
avvio automatico dei PDB, molteplici variazioni sul PDB cloning, ...).
L'architettura non-CDB e'
deprecata
con questo rilascio.
La versione 12c R2, 12.2.0.1 disponibile in Cloud da novembre 2016
ed on-premise da marzo 2017, presenta ulteriori nuove funzionalita'
come lo
Sharding, l'In-Memory su ADG,
...
Ma nella 12cR2 e' sopratutto l'opzione Multitenant
ad essere stata arricchita di nuove funzioni e liberata da molti limiti
in modo da renderla realmente efficace nel consolidamento di istanze Oracle
e nell'integrazione con i servizi Cloud.
Multitenant Option in 12cR2
Nella versione 12c e' possibile ospitare piu' istanze di database (PDB: Pluggable Database)
all'interno di un unico container chiamato CDB (Container Database).
Si tratta di una variazione significativa dell'architettura che consente una gestione
piu' flessibile del database Oracle.
Nella versione 12cR2 l'opzione multitenant trova la sua compiuta espressione:
sono supportati character set diversi tra il CDB ed i PDB,
sono supportati molti piu' PDB (da 252 a 4096),
e' supportato il flashback database a livello di PDB,
e' supportato l'Hot Cloning dei PDB,
le statistiche AWR sono a livello di PDB,
gli undo sono a livello di PDB,
e' possibile configurare/limitare i parametri di memoria e di I/O per PDB
[NdA l'eventuale limitazione dei parametri di CPU era gia' possibile con il DBRM in 12c Release1],
il DG Broker puo' effettuare un PDB failover
[NdA vanno usati due CDB per nodo per i ruoli Primary e Secondary],
l'Heat Map e' disponibile anche per le architetture CDB,
sono disponibili gli Application Containers,
sono disponibili i Proxy PDB,
sono disponibili i Refreshable PDB,
...
Nell'architettura Multitenant
l'istanza CDB mantiene al suo interno piu' PDB utilizzando lo stesso set di processi
e la stessa SGA (System Global Area). Le componenti di sistema (eg. control file,
redo log, spfile, ...) sono relative al solo CDB.
Alcune componenti (eg. data dictionary) sono disponibili a piu' livelli
mentre altri sono specifici del PDB.
La creazione di un'utenza e' locale al DB cui si e' connessi
ma e' possibile creare nel CDB
utenze comuni per tutti i PDB.
Le utenze comuni sono tipicamente utenze amministrative o di controllo.
In un PDB possono essere definiti tablespace temporanei,
ma se non viene fatto si utilizza il tablespace temporaneo del CDB.
Gli undo, presenti solo nel CDB in 12cR1, possono essere invece anche essere
presenti a livello di PDB in 12cR2, anzi e' questa la configurazione di default
e che offre le funzionalita' piu' complete [NdA Local Undo Mode].
Infine i datafile sono separati
semplicemente raccolti in una directory con nome uguale al nome del PDB;
i datafile possono utilizzare la modalita' OMF (Oracle Managed Files),
L'attivazione di un CDB avviene come quella di una normale instanza
con il comando di startup da SQL*Plus.
I PDB vanno invece aperti esplicitamente con un comando di OPEN,
altrimenti per default sono in stato MOUNTED e quindi non accessibili.
Dal punto di vista applicativo i PDB sono completamente separati
ed utilizzano oggetti, data dictionary, utenti, ... come se fossero istanze dedicate.
Multitenant by Example
Il multitenant della 12cR2 cambiera' in modo significativo l'attivita' del DBA.
Alcune attivita' risultano terribilmente piu' semplici,
altre risultano simpaticamente differenti...
Riassumendo molto un PDB e' un'istanza piu' semplice da gestire:
ma cosi' abbiamo davvero riassunto troppo!
Vediamo ora esempi pratici sul multitenant:
- Creare ed aprire un PDB
CREATE PLUGGABLE DATABASE pdb3
ADMIN USER sysp3 IDENTIFIED BY xxx;
CREATE PLUGGABLE DATABASE pdb4
ADMIN USER sysp4 IDENTIFIED BY xxx;
CREATE PLUGGABLE DATABASE pdb5
ADMIN USER sysp5 IDENTIFIED BY xxx;
alter pluggable database pdb3 open;
alter pluggable database pdb4 open read only;
|
Nella creazione di un PDB viene creata anche un'utenza amministrativa.
I PDB sono infatti amministrabili singolarmente e separatamente
mentre le utenze SYS e SYSTEM sono comuni a tutti i PDB ed al CDB.
I PDB appena creati sono in stato di MOUNT e vengono aperti come tutte le normali istanze Oracle.
Sono quindi disponibili le solite opzioni READ WRITE, READ ONLY, RESTRICTED,
FORCE, UPGRADE, RESETLOGS, ...
[NdA nell'ultimo statement c'e' un errore: ma ve lo raccontiamo la prossima puntata]
|
|
|
E' sempre presente il CDB$Root, che corrisponde al Container Database,
ed il PDB$Seed, che contiene l'immagine di partenza dei PDB.
Gli altri PDB sono quelli creati dai DBA e possono essere in stati diversi.
La figura mostra lo stato dei 3 PDB creati: OPEN in READ WRITE, OPEN in READ ONLY, MOUNTED.
Quanti PDB? Tanti!
12cR1 supportava fino a 252 PDB, 12cR2 arriva a 4096.
Naturalmente ci sono altri limiti...
|
- Cancellare un PDB
drop pluggable database pdb5 including datafiles;
|
La cancellazione dell'esempio rimuove definitivamente e completamente il PDB ed i suoi datafile.
|
- Collegarsi al CDB ed ai PDB
alter session set container=pdb3;
alter session set container=cdb$root;
conn sys/xxx@pdb3 as sysdba
export TWO_TASK=PDB3
/ as sysdba
|
Per connettersi ad un PDB o al CDB sono disponibili tre alternative:
- La variabile di sessione container
- Utilizzare un servizio sul listener
- Utilizzare la variabile d'ambiente TWO TASK
Attenzione l'OS authentication funziona solo con il CDB [NdA quindi l'OPS$ non funziona piu'].
|
- Capire dove si e' connessi
show con_name
select Sys_Context('Userenv', 'Con_Name') con_name from dual;
|
Facile... perdersi! Almeno le prime volta.
Pero' si puo' utilizzare un prompt in SQL*Plus
[NdE che funziona 2 volte su 3].
|
- Ottenere informazioni sui PDB presenti
SELECT PDB_ID, PDB_NAME, STATUS
FROM CDB_PDBS;
SELECT NAME, OPEN_MODE, RESTRICTED, OPEN_TIME, TOTAL_SIZE
FROM V$PDBS;
select CON_ID, NAME, OPEN_MODE, RESTRICTED, OPEN_TIME, CREATION_TIME,
TOTAL_SIZE, LOCAL_UNDO, PROXY_PDB, PDB_COUNT, MAX_SIZE, PDB_COUNT
from V$CONTAINERS;
select NAME, CDB, CON_ID from V$DATABASE;
|
Un'istanza CDB contiene inizialmente il solo PDB$SEED
in READ ONLY che viene utilizzato come base per la creazione dei successivi PDB.
Il conteggio dei PDB creati... ricomincia da tre:
<![CDATA[ CON_ID NAME OPEN_MODE RES CREATION_ TOTAL_SIZE
---------- --------------- ---------- --- --------- ----------
2 PDB$SEED READ ONLY NO 06-MAR-17 780140544
3 PDB3 READ WRITE NO 06-MAR-17 995098624
4 PDB4 READ ONLY NO 17-MAR-17 780140544
5 PDB5 MOUNTED 17-MAR-17 0
]]>
|
- Creare local e common users
create user meo identified by xxx;
create user c##meo identified by xxx container=all;
|
Gli utenti creati su un PDB sono e restano locali al PDB.
Gli utenti creati con il prefisso c## sono comuni a tutti i PDB ed al CDB.
[NdA ma nell'esempio non funzionano con PDB4, perche'?]
|
- Accedere al Data Dictionary
select count(*) from user_tables;
select count(*) from all_tables;
select count(*) from dba_tables;
select count(*) from cdb_tables;
|
Tutte le viste del Data Dictionary operano senza differenze quando utilizzate
con il Multitenant in un PDB secondo la normale gerarchia DBA_ --> ALL_ --> USER_.
Ma oltre a questa e' presente un'ulteriore livello di viste che contiene,
quando si e' collegati con sul CDB, tutti gli oggetti di tutti i PDB: CDB_.
|
- Configurare il listener
|
Pagina lasciata intenzionalmente vuota!
Non c'e' nulla da fare: creando un PDB viene automaticamente creato un servizio sul listener.
|
- Attivare in automatico i PDB
ALTER PLUGGABLE DATABASE pdb3 OPEN;
ALTER PLUGGABLE DATABASE pdb3 SAVE STATE;
|
Inizialmente era necessario utilizzare un trigger di After_Startup.
In 12cR2 e' molto piu' semplice: basta aprire il PDB e salvarne lo stato.
|
- Spostare un PDB (unplug e plug)
alter pluggable database pdb4 close;
alter pluggable database pdb4 unplug into '/stage/pdb4.xml';drop pluggable database pdb4 keep datafiles;
Sullo stesso CDB o su un altro CDB:
CREATE PLUGGABLE DATABASE pdb6
USING '/stage/pdb4.xml';
|
Migrare i PDB tra CDB diversi e' molto semplice.
La prima fase e' quella di effettuare l'unplug del PDB
ottenendo su un file XML la struttura.
Il PDB puo' essere spostato su un sistema diverso (quindi vanno copiati i datafile)
oppure su un sistema che condivide lo storage ovvero sullo stesso nodo ovvero sullo stesso CDB
(quindi non serve alcuna copia).
L'avvio del PDB si esegue con il comando di CREATE,
comunque resi disponibili i datafile (la clausola CREATE FROM XML prevede
tre alternative: NOCOPY, COPY, MOVE).
|
- Qual'e' il contenuto del file XML su cui si effettua l'unplug del PDB?
|
<![CDATA[<PDB>
<parameters>
<parameter>processes=320</parameter>
<parameter>nls_language='AMERICAN'</parameter>
<parameter>nls_territory='AMERICA'</parameter>
<parameter>db_block_size=8192</parameter>
<parameter>compatible='12.2.0'</parameter>
<parameter>heat_map='ON'</parameter>
<parameter>open_cursors=300</parameter>
<parameter>pga_aggregate_target=837812224</parameter>
<parameter>enable_pluggable_database=TRUE</parameter>
<parameter>max_pdbs=512</parameter>
</parameters>
</PDB>
]]>
|
Diamo un'occhiata a parametri salvati... ci sono tutte le caratteristiche del PDB.
|
- Visualizzare la storia dei PDB
select DB_NAME, CON_ID, PDB_NAME, OPERATION, OP_TIMESTAMP, CLONED_FROM_PDB_NAME
from CDB_PDB_HISTORY
order by OP_TIMESTAMP;
|
Molto semplice: c'e' una vista!
|
- Clonare un PDB remoto (o un non-CDB)
Source
CREATE USER c##rclone IDENTIFIED BY xxx CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE
TO c##rclone CONTAINER=ALL;
| |
Destination
CREATE DATABASE LINK clink1
CONNECT TO c##rclone IDENTIFIED BY xxx
USING '@SourceHost:1521/RemoteCDB';
CREATE PLUGGABLE DATABASE pdb7 FROM RemotePDB@clink1;
ALTER PLUGGABLE DATABASE pdb7 OPEN;
|
|
Dalla 12cR2 e' disponibile l'Hot Clone.
In Release 1 il source doveva essere in Read Only che era un grosso limite
per effettuare un clone di un DB di produzione.
Log archive, Local Undo, Grant, 12c, ... i prerequisiti tecnici sono semplici.
Se si utilizzano gli OMF (Oracle Managed Files) i comandi si semplificano ulteriormente.
La creazione di un clone consiste nel creare un DB link ed in un comando di CREATE PLUGGABLE DATABASE.
Se il DB di partenza non e' un CDB basta utilizzare la sintassi NON$CDB@dblink.
Non c'e' paragone rispetto al pur non complesso Duplicate con RMAN.
|
Riassumendo: l'opzione Multitenant cambia in modo significativo il modo di lavorare con Oracle
rendendo piu' semplici una serie di operazioni complesse (eg. cloning) e consentendo di ottenere
un significativo consolidamento delle istanze Oracle.
E' sicuramente da studiare e da valutare con molta attenzione per un impiego a breve.
Application Containers by Example
Con la 12cR2 la tecnica dei Pluggable database puo' essere utilizzata anche
per la gestione delle applicazioni.
E' infatti un problema comune quello di gestire diversi ambienti applicativi
(sviluppo, test, collaudo, pre-produzione, golden copy, ...) che condividono
strutture e dati comuni.
Gli Application Container consentono di centralizzare
la definizione delle tabelle utilizzate da un'applicazione
come struttura e/o come dati per tutti i PDB applicativi.
La sintassi e' quella gia' vista per il multitenant.
Vediamo ora gli esempi pratici:
- Creare un application container ed i sui PDB
create pluggable database xCally as application container
admin user db00 identified by xxx;
alter pluggable database xCally open;
alter session set container=xCally;
create pluggable database TestDB;
create pluggable database PreProdDB;
alter pluggable database TestDB open;
|
Abbiamo creato un Application Container xCally e due PDB.
Abbiamo aprerto quello che ci serviva.
La sintassi e' analoga a quella degli altri PDB.
|
|
Per implementare gli Application Containers si utilizza una gerarchia tra i PDB.
Prima viene creato l'Application Container, quindi all'interno di questo vengono
creati i PDB.
|
- Creare lo schema applicativo
alter pluggable database application Motion begin install '1.0';
create user xc identified by xxx;
grant connect, resource, unlimited tablespace to xc;
create table xc.emp7A SHARING=METADATA (empno integer not null, ename varchar2(20));
create unique index pkemp7a on xc.emp7A(EMPNO);
create table xc.emp7B SHARING=DATA (empno integer not null, ename varchar2(20));
create unique index pkemp7b on xc.emp7B(EMPNO);
create table xc.emp7C SHARING=EXTENDED DATA (empno integer not null, ename varchar2(20));
create unique index pkemp7c on xc.emp7C(EMPNO);
insert into xc.emp7A(empno, ename) select level, 'SMITH' from dual connect by level <= 7;
insert into xc.emp7B(empno, ename) select level, 'SMITH' from dual connect by level <= 14;
insert into xc.emp7C(empno, ename) select level, 'SMITH' from dual connect by level <= 7;
alter pluggable database application Motion end install '1.0';
|
Ora definiamo lo schema applicativo.
Viene definita la struttura delle tabelle applicative.
E' anche possibile popolare i dati nella root applicativa.
Ci sono 3 differenti modi di condividere gli oggetti:
la struttura (i dati vengono copiati sul PDB),
i dati (i dati sono mantenuti nell'Application Container ed il PDB non puo' modificarli),
la modalita' extendend (i dati sono mantenuti nell'AC ma il PDB puo' aggiungerne altri).
|
- Utilizzare i dati nei PDB
alter session set container=TestDB;
alter pluggable database application Motion sync;
insert into xc.emp7A(empno, ename) select level+7, 'SMITH' from dual connect by level <= 7;
select count(*)
from xc.emp7A;
select count(*)
from xc.emp7B;
insert into xc.emp7C(empno, ename) select level+7, 'SMITH' from dual connect by level <= 7;
select count(*)
from xc.emp7C;
|
Con SHARING=METADATA i dati sono mantenuti nel PDB applicativo.
Con SHARING=DATA i dati sono mantenuti nella ROOT applicativa.
Con SHARING=EXTENDED DATA parte dei dati sono nella ROOT applicativa e parte nel PDB applicativo.
|
Riassumendo: gli Application Container sfruttano l'opzione Multitenant
anche per gli aspetti di progettazione applicativa.
Da studiare con attenzione dai DBA applicativi e dai progettisti.
In-Memory by Example
L'opzione In-Memory consente significativi vantaggi prestazionali
nelle interrogazioni con dati raggruppati su tabelle di grandi dimensioni
(le tipiche ricerche sui DSS e sui DWH).
Si tratta di una nuova Option della versione 12c (12.1.0.2).
Dalla 12.2 e' possibile utilizzare l'opzione In-Memory su Active Data Guard
rendendo ancora piu' significativo l'utilizzo del secondary quale sistema per il reporting.
Vediamo ora esempi pratici sull'opzione InMemory:
- Configurare In-Memory
alter system set inmemory_size=8G scope=spfile;
shutdown immediate
startup
|
Attivare l'opzione In-Memory e' molto semplice.
Basta un parametro che indica la quantita' di memoria da dedicare.
|
- Utilizzare In-Memory
alter table schema.tabellona inmemory;
select owner, table_name, cache, inmemory_priority,
inmemory_distribute, inmemory_compression
from dba_tables
where inmemory='ENABLED';
select * from V$IM_SEGMENTS;
|
Per indicare che su una tabella e' opportuno il caching in memoria
basta una semplice ALTER TABLE.
In qualche caso puo' essere vantaggioso cancellare gli indici
(in particolare quelli utilizzati solo per le query DSS).
La cache e' chiamata IM Column Store perche' viene utilizzata
una memorizzazione dei dati per colonne.
Sono disponibili diverse viste di sistema per controllare gli oggetti
messi in cache e la memoria utilizzata.
|
- Variazioni nelle applicazioni per sfruttare In-Memory
|
Pagina lasciata intenzionalmente vuota!
Non c'e' nulla da fare nelle applicazioni.
L'ottimizzatore determina automaticamente la strategia migliore.
|
Riassumendo: l'opzione In-Memory si attiva facilmente e si prova altrettanto facilmente.
Su alcune applicazioni presenta notevoli vantaggi prestazionali (eg x10)
mentre su altre applicazioni non vi e' nessun miglioramento.
E' opportuno provarla per verificare gli eventuali vantaggi sulle applicazioni.
Se sono significativi si puo' adottarla (e' una Option...).
Sharding by Example
Oracle Sharding e' stato introdotto in Oracle 12c R2
e consente di suddividere i dati in shard ospitati su database differenti
separati anche geograficamente.
Lo sharding puo' essere immaginato come un'evoluzione del partitioning:
ogni partizione di una sharded table e' posta su un tablespace differente
ed ogni tablespace e' assegnato ad uno shard.
Lo sharding Oracle utilizza un'architettura shared nothing
con il supporto completo dell'SQL e delle transazioni:
i nodi sono costituiti da istanze Oracle indipendenti.
Dal punto di vista applicativo non vi e' nessuna differenza
nonostante gli shard non sono sullo stesso nodo ma su nodi diversi:
i listener indirizza le richieste allo shard corretto ricevendo la
chiave di partizionamento.
Vediamo ora alcuni esempi pratici sulla nuova opzione di Sharding:
- Creare una tabella sharded
ALTER SESSION ENABLE SHARD DDL;
CREATE SHARDED TABLE Customers
( CustNo NUMBER NOT NULL
, Name VARCHAR2(50)
, Address VARCHAR2(250)
, CONSTRAINT RootPK PRIMARY KEY(CustNo) )
PARTITION BY CONSISTENT HASH (CustNo)
PARTITIONS AUTO
TABLESPACE SET ts1;
|
Anche dal punto di vista sintattico lo sharding e' molto simile al partitioning...
|
- Creare family e duplicated tables
CREATE SHARDED TABLE Orders
( OrderNo NUMBER NOT NULL
, CustNo NUMBER NOT NULL
, OrderDate DATE
, CONSTRAINT OrderPK PRIMARY KEY (CustNo, OrderNo)
, CONSTRAINT CustFK FOREIGN KEY (CustNo) REFERENCES Customers(CustNo) )
PARTITION BY REFERENCE (CustFK);
CREATE DUPLICATED TABLE Products
( StockNo NUMBER PRIMARY KEY
, Description VARCHAR2(20)
, Price NUMBER(6,2)) );
|
Le family table sono le tabelle collegate alla tabella in shard che vengono
distribuite anch'esse su istanze differenti.
La tabella dei clienti e quella degli ordini debbono essere
distruibuite nello stesso modo altrimenti le operazioni di join avverrebbero
in modo distribuito.
Le duplicated tables sono... tabelle duplicate!
|
Riassumendo: opzione da conoscere da parte di un DBA.
Il Cloud con Oracle 12cR2
Sull'Oracle Public Cloud avevo gia' scritto un paio di paginette:
come accedere ed
utilizzare i DB.
In pratica c'e' tutto: IaaS, PaaS e SaaS sia senza, ma soprattutto con l'RDBMS Oracle.
Per utilizzare da remoto un DB su Oracle Public Cloud basta abilitare l'accesso:
E scaricare le credenziali:
A questo punto e' possibile accedere dalla propria rete con tutte le applicazioni/tool
alle basi dati in Cloud.
- Connettersi al Cloud con SQLcl
set cloudconfig credenziali.zip
|
Basta copiare il file delle credenziali nella directory ~/sqlcl/bin e lanciare il comando indicato.
Per essere onesti sono possibili diverse variazioni sul tema... ma sono facili!
[NdA jce_policy]
|
- Connettersi via SSH
|
$ ssh -i privateKey opc@129.152.xxx.xxx
[opc@Test12cr2 ~]$ sudo su -
[root@Test12cr2 ~]# whoami
root
With great power comes great responsibility.
|
Quando si utilizza un DB come IaaS IP e credenziali vengono fornite in fase di attivazione del servizio.
|
- Creare ed utilizzare un Proxy PDB
Cloud
CREATE USER c##rclone IDENTIFIED BY xxx CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE
TO c##rclone CONTAINER=ALL;
| |
On-Premise
CREATE DATABASE LINK clink2
CONNECT TO c##rclone IDENTIFIED BY xxx
USING '@SourceHost:1521/CloudCDB';
CREATE PLUGGABLE DATABASE pdb8
AS PROXY FROM pdb8_cloud@clink2;
ALTER PLUGGABLE DATABASE pdb8 OPEN;
|
|
Non e' strettamente necessario ma... e' terribilmente comodo utilizzare un PDB Proxy
per far puntare istanze verso il Cloud.
Ogni configurazione locale (TNSNAMES, Firewall rules, monitoring, ...) resta identica ed
il Proxy PDB si occupa di reindirizzare verso il PDB remoto
tutti i comandi SQL. Vengono eseguiti in locale solo i comandi relativi al PDB.
I tablespace di sistema (SYSTEM, SYSAUX, TEMP e UNDO)
sono presenti anche sul Proxy PDB e sono mantenuti sincronizzati.
|
- Migrare un PDB in Cloud
create pluggable database pdb9 from pdb91@clink3
relocate availability max;
ALTER PLUGGABLE DATABASE pdb9 OPEN;
|
Migrare un PDB in Cloud puo' essere fatto con due soli semplici comandi,
senza modificare le stringhe di connessione delle applicazioni ed online
senza interruzione di alcun servizio!
[NdA ma qualche dettaglio sara' descritto solo alla Masterclass].
|
Riassumendo: alcune cose con il Cloud si fanno bene e con costi minori:
la remotizzazione dei backup e la creazioni di ambienti temporanei
sono due esempi.
Anche l'implementazione del Disaster Recovery in Cloud presenta vantaggi.
Per altre implementazioni va studiata l'architettura: tra Application Server e Database
Server non vi deve essere una elevata latenza per gli accessi.
E' chiaro infine che su alcuni ambienti l'utilizzo con vantaggio del Cloud e' molto limitato.
L'architettura in Multitenant da un vantaggio per l'utilizzo del Cloud:
rende trasparenti gli accessi.
Ma e' anche vero che il Multitenant puo' ottenere vantaggi dal Cloud:
e' possibile spingere molto di piu' sul consolidamento
sapendo che e' possibile utilizzare per i picchi la remotizzazione dei servizi.
12cR2 by Example
Abbiamo visto diversi esempi pratici,
ma non si finisce mai di imparare!
Varie ed eventuali...
Il sito ufficiale riporta tutte le informazioni
sulla versione Oracle 12cR2.
Sulla precedente versione Oracle 12c Release 1 avevo scritto
questa pagina.