Oracle 12c news
In questo post verranno elencate le novità introdotte con la versione 12c.
"c" sta per Cloud perché è la prima versione di database disegnato per il cloud.
Processi di Background
Il processo LREG (listener registration process) fornisce al listener le seguenti informazioni:
- il nome dei servizi del database
- il nome delle istanze associate ai servizi e il carico attuale e quello massimo
- la gestione dei servizi disponibile per le istanze e quindi dedicated servers e dispatchers, includendo il loro tipo, indirizzo di protocollo e il carico attuale e quello massimo.
Quando è avviata l'istanza, il processo LREG tenta di collegarsi al listener per registrare il database instance e passare le informazioni di cui sopra. Se il listener sta giù, il processo cerca periodicamente di collegarsi ad esso.
Quando si avvia il lister il processo può impegnare fino a 1 minuto per registrare il database instance con il listner.
# ps -ef | grep lreg
oracle 10690 1 0 12:40 ? 00:00:00 ora_lreg_CDB12S03
oracle 13037 15723 0 12:54 pts/0 00:00:00 grep lreg
- zero o uno o più pluggable database (PDB) che sono un insieme di schema database associati logicamente ad una applicazione e/o utenza e sono separati tra loro.
I PDB condividono gli stessi processi di background, la shared memory, i metadati oracle, il Control file, Redolog file e Undo tablespace.
Ogni PDB contiene:
- Tablespace: System, Sysaux, Undo, Temp e Users (quindi un proprio data dictionary legato al tipo di applicazione)
DBUA
SYSDG è usato per operazioni Data Guard attraverso Data Guard Broker or dalla interfaccia linea di comando DGMGRL.
SYSKM è usato per operazioni Manage Transparent Data Encryption wallet.
AL32UTF8 è l'unicode database character set 'NLS_CHARACTERSET' di default per i database creati scegliendo General Purpose/Transaction Processing oppure il template Data Warehousing.
Privilegio di sistema CREATE CREDENTIAL
Questo privilegio di sistema non esiste nella versione 11.
GRANT CREATE CREDENTIAL TO <user>;
Nella versione 12 la procedura DBMS_CREDENTIAL.CREATE_CREDENTIAL sostituisce la procedura DBMS_SCHEDULER.CREATE_CREDENTIAL che rimane comunque valida nella 12.1 per compatibilità con le versioni precedenti.
Nella versione 11 il privilegio di sistema che permette di eseguire la suddetta procedura è CREATE JOB.
Per creare una credenziale in uno schema diverso dal proprio, è necessario invece disporre del privilegio CREATE ANY JOB.
Creazione Utente
Per creare un utente nel Container e che sia visibile nei suoi Pluggable database usare il prefisso C##.
USERNAME COM CON_ID
---------- --- ------------------------------
SYS YES 1
SYS YES 3
HR NO 3
Esempio di oggetti in locked.
Unified Auditing
Questa feature è in aggiunta al classico audit che memorizza le informazioni nelle tabelle SYS.AUD$. Fornisce una interfaccia standard e una singola location per gli audit trail.
Di default non è abilitata:
SQL> select * from V$OPTION where parameter = 'Unified Auditing';
DEFERRED_SEGMENT_CREATION
Questo parametro è abilitato di default e fa si che la creazione di una tabella diventa effettiva solo alla prima insert. Quindi quando viene effettuata la prima insert vengono creati i segmenti per la corrispettiva tabella, le sue colonne di tipo LOBS e gli indici.
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ---------------------------------------- -------------------------------
2 PDB$SEED READ ONLY NO
3 S12APP01 READ WRITE NO
SQL> alter session set container=S12APP01;
Session altered.
DATA DICTIONARY
SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> alter pluggable database all open;
SQL> select * from V$LOGFILE;
Viene fuori che i redolog file hanno con_id=0 e sono sotto il path
dove ORCL è il sid del database.
Control files
"c" sta per Cloud perché è la prima versione di database disegnato per il cloud.
Processi di Background
Il processo LREG (listener registration process) fornisce al listener le seguenti informazioni:
- il nome dei servizi del database
- il nome delle istanze associate ai servizi e il carico attuale e quello massimo
- la gestione dei servizi disponibile per le istanze e quindi dedicated servers e dispatchers, includendo il loro tipo, indirizzo di protocollo e il carico attuale e quello massimo.
Quando è avviata l'istanza, il processo LREG tenta di collegarsi al listener per registrare il database instance e passare le informazioni di cui sopra. Se il listener sta giù, il processo cerca periodicamente di collegarsi ad esso.
Quando si avvia il lister il processo può impegnare fino a 1 minuto per registrare il database instance con il listner.
# ps -ef | grep lreg
oracle 10690 1 0 12:40 ? 00:00:00 ora_lreg_CDB12S03
oracle 13037 15723 0 12:54 pts/0 00:00:00 grep lreg
Multitenant Architecture
La nuova architettura è costituita da un Container DB che prevede:
- un Root Container (CDB ROOT) che comprende:
una Istanza
una Sga
un set di Processi di Background
Tablespace: System, Sysaux, Undo, Temp e Users
Control file (viene aggiornato ogni volta che cambiano i dati dei pdbs)
Redolog file
un Data Dictionary
- un Root Container (CDB ROOT) che comprende:
una Istanza
una Sga
un set di Processi di Background
Tablespace: System, Sysaux, Undo, Temp e Users
Control file (viene aggiornato ogni volta che cambiano i dati dei pdbs)
Redolog file
un Data Dictionary
- zero o uno o più pluggable database (PDB) che sono un insieme di schema database associati logicamente ad una applicazione e/o utenza e sono separati tra loro.
I PDB condividono gli stessi processi di background, la shared memory, i metadati oracle, il Control file, Redolog file e Undo tablespace.
Ogni PDB contiene:
- Tablespace: System, Sysaux, Undo, Temp e Users (quindi un proprio data dictionary legato al tipo di applicazione)
- Datafile legati alla applicazione
Un CDB può raggruppare diverse applicazioni, ognuna con un suo PDB.
Un CDB può raggruppare diverse applicazioni, ognuna con un suo PDB.
DBUA
Database Upgrade Assistant è un tool che guida l'utente all'aggiornamento del db alla nuova release.
$ORACLE_HOME/bin> ./dbua
Processo LREG
Processo LREG
Il processo responsabile della registrazione del listener nelle versioni precedenti era PMON invece dalla 12c è LREG (listener registration process) che registra le informazioni dell'istanza del database e i dispatcher process con Oracle Net Listener.
Quando si avvia il listener con il comando "lsnrctl start"
Quando si avvia il listener con il comando "lsnrctl start"
[oracle@test bin]$ lsnrctl start
LSNRCTL for Linux: Version 18.0.0.0.0 - Production on 19-AUG-2020 17:04:34
Copyright (c) 1991, 2018, Oracle. All rights reserved.
Starting /u01/app/oracle/product/18/db_1/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 18.0.0.0.0 - Production
System parameter file is /u01/app/oracle/product/18/db_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/test/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=test.com)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 18.0.0.0.0 - Production
Start Date 19-AUG-2020 17:04:34
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/18/db_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/test/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=test.com)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
The listener supports no services
The command completed successfully
Il processo LREG ci mette circa 60 secondi per registrare i service name a meno che non si forzi con il comando seguente prima di avviare il listener.
[oracle@test bin]$ sqlplus / as sysdba
SQL> alter system register;
Modificato sistema.
Privilegi SYSBACKUP , SYSDG , SYSKM
In precedenti versioni, i privilegi di questi utenti erano associati a SYSDBA.
SYSBACKUP è usato per bakcup e recovery usando RMAN or SQL*PlusIn precedenti versioni, i privilegi di questi utenti erano associati a SYSDBA.
SYSDG è usato per operazioni Data Guard attraverso Data Guard Broker or dalla interfaccia linea di comando DGMGRL.
SYSKM è usato per operazioni Manage Transparent Data Encryption wallet.
AL32UTF8 è l'unicode database character set 'NLS_CHARACTERSET' di default per i database creati scegliendo General Purpose/Transaction Processing oppure il template Data Warehousing.
Privilegio di sistema CREATE CREDENTIAL
Questo privilegio di sistema non esiste nella versione 11.
GRANT CREATE CREDENTIAL TO <user>;
Nella versione 12 la procedura DBMS_CREDENTIAL.CREATE_CREDENTIAL sostituisce la procedura DBMS_SCHEDULER.CREATE_CREDENTIAL che rimane comunque valida nella 12.1 per compatibilità con le versioni precedenti.
Nella versione 11 il privilegio di sistema che permette di eseguire la suddetta procedura è CREATE JOB.
Per creare una credenziale in uno schema diverso dal proprio, è necessario invece disporre del privilegio CREATE ANY JOB.
Creazione Utente
Per creare un utente nel Container e che sia visibile nei suoi Pluggable database usare il prefisso C##.
Si chiama Common User e quelli di tipo amministrativi sono sys e system.
Un Local user è invece è un utente creato all'interno di un pdb e uno stesso local user può essere creato in differenti pdb.
SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> select username, common, con_id from cdb_users order by username;
---------- --- ------------------------------
SYS YES 1
SYS YES 3
HR NO 3
L'utente SYS è comune al container e al pdb (3) mentre HR è un local user perché è definito solo nel pdb.
Un Common User è invece definito da un prefisso come visibile dai parametri del db.
SQL> show parameter common_user_prefix
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
common_user_prefix string C##
SQL> create user pippo identified by pippo;
create user pippo identified by pippo
*
ERRORE alla riga 1:
ORA-65096: nome utente o ruolo comune non valido
SQL> create user C##pippo identified by pippo;
Utente creato.
SQL> select username, common, con_id from cdb_users where username ='C##PIPPO';
USERNAME COM CON_ID
---------- --- ----------
C##PIPPO YES 1
C##PIPPO YES 3
Dynamic Performance View
Sono viste di proprietà di sys che sono dinamicamente aggiornate quando il database è open e runnig e fanno riferimento principalmente alle performance infatti sono usati da EM e Oracle Trace.
Sono identificate dal prefisso V_$ ma si può usare il sinonimo pubblico V$.
Inoltre alcune leggono dalla memoria e quindi con il db in stato "started" e altre dal disco quindi con il database in stato mount o open.
Esempio di oggetti in locked.
select
oracle_username
os_user_name,
locked_mode,
object_name,
object_type
from
v$locked_object a,dba_objects b
where
a.object_id = b.object_id;
Unified Auditing
Questa feature è in aggiunta al classico audit che memorizza le informazioni nelle tabelle SYS.AUD$. Fornisce una interfaccia standard e una singola location per gli audit trail.
Di default non è abilitata:
SQL> select * from V$OPTION where parameter = 'Unified Auditing';
PARAMETER VALUE CON_ID
-------------------------------------------------
Unified Auditing FALSE 0
vedere post
DEFERRED_SEGMENT_CREATION
Questo parametro è abilitato di default e fa si che la creazione di una tabella diventa effettiva solo alla prima insert. Quindi quando viene effettuata la prima insert vengono creati i segmenti per la corrispettiva tabella, le sue colonne di tipo LOBS e gli indici.
SQL> show parameter deferred_
NAME TYPE VALUE
--------------------------------------------------------------------------
deferred_segment_creation boolean TRUE
SQL> show pdbs
NAME TYPE VALUE
--------------------------------------------------------------------------
deferred_segment_creation boolean TRUE
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ---------------------------------------- -------------------------------
2 PDB$SEED READ ONLY NO
3 S12APP01 READ WRITE NO
SQL> alter session set container=S12APP01;
Session altered.
SQL> conn fra/fra@S12APP01
Connected.
SQL> create table test_seg( x number);
Table created.
SQL> select segment_name from USER_SEGMENTS
Connected.
SQL> create table test_seg( x number);
Table created.
SQL> select segment_name from USER_SEGMENTS
where segment_name ='TEST_SEG';
no rows selected
SQL> insert into TEST_SEG values (10);
1 row created.
SEGMENT_NAME
----------------------------------
TEST_SEG
no rows selected
SQL> insert into TEST_SEG values (10);
1 row created.
SQL> select segment_name from USER_SEGMENTS
where segment_name ='TEST_SEG';
SEGMENT_NAME
----------------------------------
TEST_SEG
Contiene i metadati del database, è strutturato in tabelle e viste, appartiene allo schema SYS e non deve essere modificato usando istruzioni sql. Rispetto alla versione precedente sono state introdotte le viste CDB_
Redolog file
CON_NAME
------------------------------
CDB$ROOT
SQL> alter pluggable database all open;
SQL> select * from V$LOGFILE;
Viene fuori che i redolog file hanno con_id=0 e sono sotto il path
/u01/app/oracle/oradata/ORCL/redo01.log
I redo log sono comuni a tutti i pdbs e non per un particolare container.
Ricordiamo che i redolog file memorizzano tutte le modifiche apportate al database non appena si verificano.
Il database conserva i redolog file on line per proteggere dalla perdita di dati in particolare, dopo un errore di istanza.
I redolog file online consentono il ripristino di dati committati che non sono ancora stati scritti nei data file.
Abbiamo bisogno di almeno 2 file di redolog file di cui uno è sempre disponibile per la scrittura, mentre l'altro viene archiviato
Control files
Contiene i metadati sui datafiles e online redolog files ( come name, locations e stato) e queste informazioni sono rechieste dall'istanza di database per aprire il database.
Il Control file esiste nell'intera istanza non per un particolare container e quindi è unico per tutti i suoi pdbs.
SQL> select * from V$CONTROLFILE
Il Control file esiste nell'intera istanza non per un particolare container e quindi è unico per tutti i suoi pdbs.
SQL> select * from V$CONTROLFILE
Viene fuori che i control file hanno con_id=0 e sono sotto il path
/u01/app/oracle/oradata/ORCL/control01.ctl
dove ORCL è il sid del database.
