Nel documento precedente
erano state analizzate le principali problematiche DBA della versione 12c Release 2.
Ma le tematiche piu' complesse ed interessanti della 12cR2 le abbiamo lasciate
per questo documento consigliato solo ad un pubblico DBA adulto!
In questa pagina sono trattati argomenti quali il Resource Managment,
le viste di sistema, le Heat Map, ...
molto importanti quando si vuole sfruttare al massimo il consolidamento
delle istanze con il multitenant in 12c.
Il taglio del documento e' pratico: senza alcuna noiosa introduzione
si passa direttamente a semplici esempi per ogni funzionalita' descritta.
Gli esempi riguardano
il Resource Management in Multitenant,
Cosa c'e' sotto,
...
Nonostante l'utilizzo di esempi per leggere questa pagina e' necessaria
una buona conoscenza dell'RDBMS Oracle
e delle problematiche DBA su Oracle 12c.
Consolidare un numero elevato di istanze all'interno di un unico container pone nuovi problemi al DBA.
Vediamo ora esempi pratici sulla gestione delle risorse utilizzate da PDB:
select con_id, name, value from V$CON_SYSSTAT where name like 'physical % total bytes' order by con_id, name; select * from V$PDBS; select * from CDB_PDBS; select con_id, count(*) from cdb_users group by con_id; select con_id, name, display_value from V$SYSTEM_PARAMETER where ismodified<>'FALSE' order by 1,2; select * from containers(dual) where con_id<5; |
Le viste di sistema V$ riportano dati relativi al PDB corrente.
Quando lanciate sul CDB riportano i dati del CDB e di tutti i PDB.
Naturalmente sono presenti gli analoghi GV$ per il RAC!
Un'eccezione e' costituita dalle viste V$SYSSTAT, V$SYS_TIME_MODEL, V$SYSTEM_EVENT e V$SYSTEM_WAIT_CLASS che riportando i dati del solo PDB/CDB corrente e per cui esiste l'analogo V$CON_ (eg. V$CON_SYSSTAT) con la colonna CON_ID per selezionare il PDB di interesse. Ci sono sottili differenze nelle informazioni contenute nelle viste. Ad esempio un PDB appena creato risulta MOUNTED nella V$PDBS, ma lo stato della CBD_PDB non e' NORMAL ma NEW: quindi deve completare la configurazione [NdA e la prima volta non puo' essere aperto in READ ONLY]. Vi sono comunque centinaia di nuove viste... selezionare per credere! |
alter system set max_pdbs=1 scope=both; alter system set max_pdbs=200 scope=both; |
Utilizzando un solo PDB si utilizza l'architettura Multitenant
senza pagare l'opzione: configurazione Singletenant.
E' particolarmente importante perche' l'architettura Non-CDB e' stata
deprecata [NdE dalla versione 12.1.0.2].
Consiglio pratico? Limitare il massimo dei PDBS anche con il Multitenant. |
begin dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.create_cdb_plan(plan =>'base01_plan', comment =>'Resource Management Sample Plan'); dbms_resource_manager.create_cdb_plan_directive( plan => 'base01_plan', pluggable_database => 'pdb3', shares => 5, utilization_limit => 100, parallel_server_limit => 100); dbms_resource_manager.create_cdb_plan_directive( plan => 'base01_plan', pluggable_database => 'pdb4', shares => 5, utilization_limit => 50, parallel_server_limit => 50); dbms_resource_manager.update_cdb_plan_directive( plan => 'base01_plan', new_shares => 1, new_utilization_limit => 50, new_parallel_server_limit => 100); dbms_resource_manager.validate_pending_area(); dbms_resource_manager.submit_pending_area(); end; / alter system set resource_manager_plan = 'base01_plan' scope=both; -- PDB Performance Profiles BEGIN ... DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE( plan => 'newcdb_plan', profile => 'gold', shares => 10, utilization_limit => 100, parallel_server_limit => 100); ... END; / ... alter session set container=PDB3; alter system set db_performance_profile='gold' scope=spfile; |
La gestione della condivisione delle risorse tra i PDB puo' essere controllata
con il Resource Management. Gli shares indicano la frazione di risorse
di CPU da riservare ad un PDB; l'utilization_limit definisce il limite
massimo di CPU utilizzabile anche nel caso in cui non vi sia contesa sulla CPU;
il parallel_server_limit definisce il limite sull'utilizzo del parallelismo.
L'esempio sembra lungo in realta' la sintassi e' molto semplice...
si tratta solo di un elenco.
Per utilizzare un Management Plan un PDB deve essere riavviato.
I limiti possono essere definiti sui singoli PDB e come default per tutti i nuovi PDB. Dalla 12.2 sono disponibili i profili che consentono di definire profili generali ed associare i PDB a ciascuno di essi. Quando il numero dei PDB cresce l'utilizzo dei profili semplifica notevolmente la gestione. Per analizzare il dettaglio delle risorse utilizzate sono disponibili le viste: V$RSRCPDBMETRIC V$RSRCPDBMETRIC_HISTORY DBA_HIST_RSRC_PDB_METRIC: SELECT r.snap_id, r.con_id, p.pdb_name, r.begin_time, r.end_time, r.CPU_CONSUMED_TIME, r.AVG_RUNNING_SESSIONS, r.iops, r.iombps FROM dba_hist_rsrc_pdb_metric r, cdb_pdbs p WHERE r.con_id = p.con_id ORDER BY r.begin_time; |
alter session set container=PDB3; ALTER SYSTEM SET SGA_TARGET = 1G SCOPE = BOTH; ALTER SYSTEM SET SGA_MIN_SIZE = 500M SCOPE = BOTH; ALTER SYSTEM SET max_iops=100 SCOPE=BOTH; ALTER SYSTEM SET max_mbps=400 SCOPE=BOTH; SELECT NAME FROM V$PARAMETER WHERE ISPDB_MODIFIABLE ='TRUE'; |
Limitare l'utilizzo di memoria da parte dei PDB e' una nuova feature della 12.2.
Sono centinaia i parametri di personalizzazione disponibili per i PDB. Tra gli altri DB_CACHE_SIZE, SHARED_POOL_SIZE, PGA_AGGREGATE_LIMIT, PGA_AGGREGATE_TARGET, SGA_MIN_SIZE, SGA_TARGET, ... In ogni caso abbiamo riportato nell'esempio i piu' significativi! La verifica su quali parametri siano modificabili a livello di PDB si effettua sulla vista V$PARAMETER. |
ALTER SYSTEM SET HEAT_MAP = ON; select * from DBA_HEATMAP_TOP_TABLESPACES; select * from DBA_HEATMAP_TOP_OBJECTS; ALTER TABLE fatture_attive ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 12 MONTHS OF NO ACCESS; ALTER TABLE fatture_passive ILM ADD POLICY TIER TO tbs_economico SEGMENT AFTER 6 MONTHS OF LOW ACCESS; |
Con il semplice comando indicato nell'esempio si abilitano le Heat Map
che consentono di scoprire gli oggetti ed i segmenti di disco piu' utilizzati.
Una volta attivato sono disponibili diverse viste di sistema per monitorare i segmenti piu' utilizzati: V$HEAT_MAP_SEGMENT, ALL_, DBA_ e USER_HEAT_MAP_SEGMENT, ALL_, DBA_ e USER_HEAT_MAP_SEG_HISTOGRAM che vengono riassunte nelle: DBA_HEATMAP_TOP_OBJECTS DBA_HEATMAP_TOP_TABLESPACES. In corrispondenza all'Heat Map si abilita anche l'Automatic Data Optimization (ADO) che implementa eventuali politiche di migrazione e compressione dei dati [NdE utilizza l'Advanced Compression Option]. Dalla 12cR2 tali funzionalita' sono disponibili anche sulle architetture CDB. |
Mi e' sempre piaciuto guardare cosa c'e' sotto...
| Beh, c'e' molto di piu' dei soli parametri mostrati in precedenza! |
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \ -n 1 -d $ORACLE_HOME/rdbms/admin -l /home/oracle/upgrade \ -b preupgrd preupgrd.sql |
Eseguire lo stesso comando su tutti i PDB e' un esigenza comune quando si usa
il Multitenant...
lo script perl catcon.pl serve appunto a questo.
Nell'esempio viene eseguito lo script di pre-upgrade su tutti i PDB. |
shutdown immediate startup upgrade alter database local undo on; shutdown immediate startup SQL> select name,con_id from v$tablespace; NAME CON_ID --------------- ------ SYSAUX 1 SYSTEM 1 UNDOTBS1 1 USERS 1 TEMP 1 SYSTEM 2 SYSAUX 2 UNDO_1 2 |
Il Local Undo Mode e' stato introdotto con la 12cR2 ed e' fondamentale
per il flashback e per l'Hot Cloning.
Sulla 12.2 il Local Undo Mode e' il default ma in caso di upgrade dalla 12.1 e' definito lo Shared Undo Mode. Nel caso non fosse attivo ecco come fare [NdA richiede un upgrade quindi un riavvio del CDB]. Dal punto di vista tecnico il funzionamento e' molto semplice. Sul PDB$Seed viene aggiunto il tablespace di UNDO. Ogni nuovo PDB ereditera' il tablespace e non utilizzera' quello comune sul CDB. E' cosi' possibile effettuare l'Hot Cloning dei PDB ed il Flashback. |
shutdown immediate startup mount alter database archivelog; alter database open; | Questo argomento non e' da Masterclass... ma l'ho inserito solo per ricordare che il Log Archiving e', con il Local Undo Mode, un prerequisito per tutte le funzionalita' piu' significative dei PDB (eg. Hot Clone, Refresh, ...) della versione 12cR2. |
CREATE PLUGGABLE DATABASE pdb4 FROM pdb3 FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdb1/pdb3/', '/u01/app/oracle/oradata/cdb1/pdb4/'); alter system set DB_CREATE_FILE_DEST='/u01/app/oracle/oradata/db12' scope=both; CREATE PLUGGABLE DATABASE pdb4 FROM pdb3; |
Utilizzare gli OMF (Oracle Managed Files) non e' un prerequisito...
ma e' comodo!
Nell'esempio viene utilizzato lo stesso comando senza l'utilizzo dell'OMF e dopo averlo impostato. |
create pluggable database pdb9 from pdb91@clink refresh mode manual; create pluggable database pdb9 from pdb91@clink3 relocate availability max; create pluggable database pdb9 as proxy from pdb0@clink; |
Alcune tipologie di PDB sono state riportate come esempio in precedenza,
ma ve ne sono molte di piu'.
Vi sono variazioni possibili sull'allineamento tra PDB
oppure per la modalita' di puntamento da parte dei listener.
Refreshable Clone PDB, Tombstone PDB, Proxy PDB, ... sono alcuni esempi. Vengono reati rispettivamente dalle clausole REFRESH MODE, AVAILABILITY MAX, AS PROXY.
Sono fantastici anche gli stati dei PDB.
Ad esempio
un PDB appena creato non puo' essere aperto in READ ONLY
(perche' e' necessario scrivere per terminare il setup del PDB)
oppure un PDB aperto in READ ONLY non vede i common users
(perche' e necessario aprirlo in scrittura per far aggiornare il Data Dictionary)...
|
Intenzionalmente vuoto! |
La creazione di un PDB registra automaticamente il servizio corrispondente sul listener.
La RELOCATE di un PDB, al termine delle operazioni, registra la nuova locazione del PDB e rimuove la precedente.
Con i Proxy PDB e' possibile remotizzare gli accessi.
Con il multitenant e' possibile migrare i database in modo trasparente alle applicazioni/utenti e con un minimo disservizio. |
select con_id,TABLESPACE_NAME,ENCRYPTED from cdb_tablespaces order by 1,2; CON_ID TABLESPACE_NAME ENC ---------- ------------------------------ --- 1 SYSAUX NO 1 SYSTEM NO 1 TEMP NO 1 UNDOTBS1 NO 1 USERS YES 3 SYSAUX NO 3 SYSTEM NO 3 TEMP NO 3 UNDOTBS1 NO 3 USERS YES |
Il Transparent Data Encryption (TDE) e' un componente dell'opzione Oracle Advanced Security.
Si tratta di un componente fondamentale per la sicurezza dei dati e viene utilizzato nei
casi in cui e' richiesto un elevato livello di sicurezza.
Sembrerebbe un dettaglio di interesse limitato, perche' parlarne?
Perche' su Oracle Public Cloud i tablespace non di sistema sono tutti
crittografati (encrypt_new_tablespaces=CLOUD_ONLY)!
Nota non "tecnica": il TDE in Cloud e' compreso nel prezzo ma on-premises e' una Oracle Option e quindi ha un costo. |
Master Note For Oracle Database 12c Release 2 (12.2) Database/Client Installation/Upgrade/Migration Standalone Environment (Non-RAC) (Doc ID 2195547.1) Creating A Container Database (CDB) With A Subset Of Options (Doc ID 2001512.1) How to Control and Monitor the Memory Usage (Both SGA and PGA) Among the PDBs in Mutitenant Database - 12.2 New Feature (Doc ID 2170772.1) Managing OS Resources Among PDBs Using PDB Perfromance Profiles - 12.2 New Feature (Doc ID 2171135.1) How to execute sql scripts in Multitenant environment (catcon.pl) (Doc ID 1932340.1) Oracle Database Backup Service - FAQ (Doc ID 1640149.1) ORA-12012 Error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY... in 12.2 Database (Doc ID 2127675.1) |
Il MOS (My Oracle Support) e' il riferimento per tutta la documentazione ufficiale e gli aggiornamenti.
Nell'elenco a sinistra sono riportati i riferimenti piu' significativi
(eg. Avete un errore sulle SYS.DBMS_STATS? Controllate l'ultima nota e lanciate:
EXEC dbms_stats.init_package()).
Naturalmente e' necessario un contratto di supporto valido ed un CSI per accedere al MOS.
Molto interessanti sono anche i White Paper ufficiali tra cui questo. Ovviamente al 1 Aprile 2017 parte della documentazione e' in lavorazione ;-) |
Il sito ufficiale riporta tutte le informazioni sulla versione Oracle 12cR2.
La pagina riporta le principali informazioni per il DBA che utilizza Oracle 12c Release 2, mentre questa pagina riporta le caratteristiche dell'architettura 12c Release 1.
Titolo: Oracle 12c R2 Masterclass
Livello: Esperto
Data: 6 Marzo 2017
Versione: 1.0.2 -
1 Aprile 2017
Autore:
mail [AT] meo.bogliolo.name