Oracle 12cR2 Resource Manager: Performance profiles

lunedì 3 settembre 2018 alle 03:13 | Pubblicato su 12c, Diario | Lascia un commento

In questo post in cui ho passato in rassegna velocemente le nuove caratteristiche dell’archiettettura multitenant in Oracle 12cR2 ho citato anche i Performance Profile. Oggi, testatando l’implementazione di un CDB resource plan mi sono imbattutto in quella che sembra l’unica parte della documentazione che parla di questa carattaristica. E’ quasi inutile che io riporti qui un esempio quanto oltre a quello che si trova sul manuale c’è una descrizione ancora più completa sul solito sito di Tim Hall, la si trova qui. Io posso aggiungere che ho provato a fare un piano misto, definendo cioè direttive sia per PDB che per profilo. Sul manuale dice:

…Each PDB that uses a profile adopts the CDB resource plan for that profile…

io lo interpetro nel senso che se si definisce un piano come ho fatto io, per cui per un PDB c’è sia una direttiva che riferisce esplicitamente quel PDB che una direttiva per il profilo attivato su quel PDB allora ha precedenza la direttiva sul profilo. Cerco di spiegarmi meglio, riportando la situazione che ho creato:

PLAN PLUGGABLE_DATABASE PROFILE SHARES UTIL PARALLEL
------------------------------ ------------------------- ------------------------- ---------- ---------- ----------
TEST122_PLAN ORA$AUTOTASK 1 85 85
TEST122_PLAN ORA$DEFAULT_PDB_DIRECTIVE 1 50 50
TEST122_PLAN SVIL122P1 1 70 70
TEST122_PLAN TEST122P1 3 100 100
TEST122_PLAN BRONZE 1 20 20
TEST122_PLAN GOLD 3 100 100
TEST122_PLAN SILVER 2 40 40

ora, se sul mio PDB svil122p1 ho attivato il profilo “GOLD” anziché avere a disposizione una sola share e un limite del 70% su CPU e processi paralleli, come definito dalla direttiva esplicita, il resource manager darà al PDB svil122p1 3 share  e nessuna limitazione su CPU e processi paralleli. Certamente non è questo il modo in cui Oracle intende in cui vengano utilizzati i performance profile. Sembra che siano fatti per non non dovere definire una direttiva per ogni PDB, anche quando i PDB possono essere molti; da ricordare che su Exadata con la release due si possono avere oltre quattromila PDB. A conferma di questo c’è il fatto che il parametro DB_PERFORMANCE_PROFILE sui PDB è statico, cioè per attivare un dato profilo occorre chiudere e riaprire il PDB, il che non è comodo a mio avviso. Altrimenti io avrei visto i performance profile un modo per cambiare dinamicamente il “profilo” o il ruolo di un PDB per il resource manager, nell’eventualità ad esempio di voler assegnare temporaneamente più risorse a un solo PDB all’interno del CDB.

Annunci

Oracle 12cR2, primi test con gli Application Container

lunedì 3 settembre 2018 alle 03:43 | Pubblicato su 12cR2, Diario | Lascia un commento
Tag:

Dopo aver letto un po’ di documentazione sull’argomento “application container” in Oracle 12cR2 sono passato a dei “test sul campo”. Ho recuperato una installazione fatta qualche mese fa e ho cominciato a fare un po’ di prove. Va premesso che l’argomento è abbastanza complesso, nel senso che le cose che si possono fare sono tante, io mi limito a riportare delle semplici prove che credo siano utili per cominciare a “entrare” nell’argomento.

L’ambiente di partenza era una installazione 12.2.0.1, siccome c’è stato un cambio di macchina per la precisione ho spostato il database da una macchina ad un’altra. Il database era stato gia creato come CDB (se non ho capito male non c’è modo di passare da non-CDB a CDB se non creando un nuovo database, qui si parla di qualcosa di simile). In quel CDB avevo gia creato un PDB che poi era stato usato per un breve test di una funzionalità.

Tramite la query:

select * from database_properties where property_name=’LOCAL_UNDO_ENABLED’;

ho verificato che il database era gia in modalità “LOCAL UNDO”, infatti è il default.

A questo punto ho creato il mio primo application container:

12:45:46 SQL> CREATE PLUGGABLE DATABASE test122ac AS APPLICATION CONTAINER ADMIN USER psystem IDENTIFIED BY manager ROLES = (DBA)
FILE_NAME_CONVERT = (‘/u01/app/oracle/oradata/test122/pdbseed/’, ‘/u01/app/oracle/oradata/test122/test122ac/’);12:45:54 2

Pluggable database created.

Elapsed: 00:00:16.18

select name,open_mode,application_root,local_undo from v$pdbs;
12:51:48 SQL> select name,open_mode,application_root,local_undo from v$pdbs;

NAME OPEN_MODE APP LOCAL_UNDO
——————– ———- — ———-
PDB$SEED READ ONLY NO 1
TEST122P1 READ WRITE NO 1
TEST122AC MOUNTED YES 1

 

Bene, a questo punto volevo portare dentro l’application container il PDB esistente (test122p1). Quindi i passi fatti sono brevemente:

  • avvio application container test122ac
  • arresto PDB test122p1
  • unplug PDB test122p1
  • drop PDB test122p1
  • plug PDB test122p1 in test122ac

Ecco, fin qui non ho avuto problemi, sono passato alla creazione di un nuovo PDB sotto lo stesso application container test122ac:

SQL> CREATE PLUGGABLE DATABASE svil122p1 ADMIN USER psystem IDENTIFIED BY manager ROLES = (DBA)
FILE_NAME_CONVERT = (‘/u01/app/oracle/oradata/test122/pdbseed/’, ‘/u01/app/oracle/oradata/test122/svil122p1/’); 2

Pluggable database created.

A questo punto sono andato a dare un’occhiata all’alert.log e vi ho trovato questo messaggio:

TEST122P1(5):Database Characterset for TEST122P1 is AL32UTF8
2018-08-29T16:06:53.458517+02:00
TEST122P1(5):Opatch validation is skipped for PDB TEST122P1 (con_id=0)
TEST122P1(5):***************************************************************
TEST122P1(5):WARNING: Pluggable Database TEST122P1 with pdb id – 5 is
TEST122P1(5): altered with errors or warnings. Please look into
TEST122P1(5): PDB_PLUG_IN_VIOLATIONS view for more details.
TEST122P1(5):***************************************************************

In effetti interrogando la vista PDB_PLUG_IN_VIOLATIONS ho trovato questo messaggio:

Non-Application PDB plugged in as an Application PDB, requires pdb_to_apppdb.sql be run

Come utente SYS ho eseguito lo script pdb_to_apppdb.sql, sulla vista PDB_PLUG_IN_VIOLATIONS la colonna STATUS è passata da “PENDING” a “RESOLVED” (quindi il record rimane li) e il problema è rientrato.

Ora è arrivato il momento di testare la creazione di una applicazione. Qui la cosa secondo me si fa complessa perché occorre tenere conto di un po’ di vincoli, legati al fatto che un’applicazione che viene definita sull’application container poi verrà in qualche modo “replicata” o installata sui vari PDB. Questo implica che occorre fare attenzione che il “contesto” si replicabile. Un primo esempio, con la spiegazione di un limite di cui tenere conto viene ben descritto in questo post, come l’autore spiega nel post di aggiornamento infatti  se la definizione dell’applicazione prevede la creazione di tablespace allora si è vincolati a usare la struttura OMF, come ha fatto Tim Hall nel suo eccellente articolo. Ora, io sono partito con una prova molto più semplice, in cui nell’applicazione creavo solo una tabella, solo che l’ho fatto con l’utenza PSYSTEM creata assieme all’application container. Ecco qui ho incontrato il primo problema, quando sono andato su TEST122p1 ed ho cercato di fare la sincronizzazione. Infatti anche utilizzando l’utenza SYS (prima avevo provato sempre con PSYSTEM) ottenevo sempre l’errore di privilegi insufficenti:

alter pluggable database application appcri1 sync
*
ERROR at line 1:
ORA-01031: insufficient privileges

Non ci sono arrivato subito, è nel tentativo di risolvere quel problema che sono incappato prima nel problema oggetto del mio post precedente e poi nel post di Anju Garg che ho citato prima. Per farla breve il problema era che il role PDB_DBA su TEST122p1 non aveva il role DBA. In mezzo avevo provato disperatamente a dare anche SYSDBA a PSYSTEM e comunque non funzionava. In realtà questo prova che nel definire un’applicazione occorre usare un approccio come quello esemplificato da Tim Hall, quindi creando anche tablespace (per cui però occorre usare OMF) e utenti/schemi.

Ho quindi testato la funzionalità di disinstallazione di una applicazione da un application container, ho lanciato questi comandi:

alter pluggable database application appcri2 begin uninstall;
drop table common_table_appcri2;
alter pluggable database application appcri2 end uninstall;

Ritengo interessante riportare un estratto dell’alert.log da cui si vede ciò che i comandi sopra hanno scatenato, ovvero la creazione un clone dell’application root che permette di mantenere la versione dell’applicazione com’era prima della disintallazione:

TEST122AC(4):alter pluggable database application appcri2 begin uninstall
CREATE PLUGGABLE DATABASE “F1450013744_4_1” AS APPLICATION CONTAINER from “TEST122AC” CREATE_FILE_DEST=’/u01/app/oracle/oradata/test122/test122ac/’
2018-08-30T12:47:51.000009+02:00
TEST122AC(4): APEX_050000.WWV_FLOW_ADVISOR_CHECKS (CHECK_STATEMENT) – CLOB populated
2018-08-30T12:48:05.018535+02:00
F1450013744_4_1(6):Endian type of dictionary set to little
****************************************************************
Pluggable Database F1450013744_4_1 with pdb id – 6 is created as UNUSABLE.
If any errors are encountered before the pdb is marked as NEW,
then the pdb must be dropped
local undo-1, localundoscn-0x00000000000000e0
****************************************************************
F1450013744_4_1(6):Media Recovery Start
2018-08-30T12:48:05.263003+02:00
F1450013744_4_1(6):Serial Media Recovery started
2018-08-30T12:48:05.323789+02:00
F1450013744_4_1(6):Recovery of Online Redo Log: Thread 1 Group 3 Seq 144 Reading mem 0
F1450013744_4_1(6): Mem# 0: /u01/app/oracle/oradata/test122/redo03.log
2018-08-30T12:48:05.361129+02:00
F1450013744_4_1(6):Incomplete Recovery applied until change 6934636 time 08/30/2018 12:48:04
2018-08-30T12:48:05.368956+02:00
F1450013744_4_1(6):Media Recovery Complete (test122)
F1450013744_4_1(6):Autotune of undo retention is turned on.
2018-08-30T12:48:06.332381+02:00
F1450013744_4_1(6):[20290] Successfully onlined Undo Tablespace 2.
2018-08-30T12:48:06.370038+02:00
F1450013744_4_1(6):Undo initialization finished serial:0 start:3099160625 end:3099160912 diff:287 ms (0.3 seconds)
F1450013744_4_1(6):Database Characterset for F1450013744_4_1 is AL32UTF8
F1450013744_4_1(6):JIT: pid 20290 requesting stop
Completed: CREATE PLUGGABLE DATABASE “F1450013744_4_1” AS APPLICATION CONTAINER from “TEST122AC” CREATE_FILE_DEST=’/u01/app/oracle/oradata/test122/test122ac/’
ALTER PLUGGABLE DATABASE “F1450013744_4_1” OPEN
F1450013744_4_1(6):Autotune of undo retention is turned on.
F1450013744_4_1(6):Endian type of dictionary set to little
2018-08-30T12:48:07.583580+02:00
F1450013744_4_1(6):[20290] Successfully onlined Undo Tablespace 2.
F1450013744_4_1(6):Undo initialization finished serial:0 start:3099161622 end:3099162160 diff:538 ms (0.5 seconds)
F1450013744_4_1(6):Deleting old file#16 from file$
F1450013744_4_1(6):Deleting old file#17 from file$
F1450013744_4_1(6):Deleting old file#18 from file$
F1450013744_4_1(6):Adding new file#30 to file$(old file#16)
F1450013744_4_1(6):Adding new file#31 to file$(old file#17)
F1450013744_4_1(6):Adding new file#32 to file$(old file#18)
****************************************************************
Post plug operations are now complete.
Pluggable database F1450013744_4_1 with pdb id – 6 is now marked as NEW.
****************************************************************
F1450013744_4_1(6):Database Characterset for F1450013744_4_1 is AL32UTF8
F1450013744_4_1(6):Opatch validation is skipped for PDB F1450013744_4_1 (con_id=0)
2018-08-30T12:48:13.067787+02:00
F1450013744_4_1(6):Opening pdb with no Resource Manager plan active
Pluggable database F1450013744_4_1 opened read write
Completed: ALTER PLUGGABLE DATABASE “F1450013744_4_1” OPEN
ALTER PLUGGABLE DATABASE “F1450013744_4_1” CLOSE
F1450013744_4_1(6):JIT: pid 20290 requesting stop
2018-08-30T12:48:14.643037+02:00
Pluggable database F1450013744_4_1 closed
Completed: ALTER PLUGGABLE DATABASE “F1450013744_4_1” CLOSE
ALTER PLUGGABLE DATABASE “F1450013744_4_1” OPEN READ ONLY INSTANCES=ALL
F1450013744_4_1(6):Autotune of undo retention is turned on.
F1450013744_4_1(6):Endian type of dictionary set to little
F1450013744_4_1(6):Undo initialization finished serial:0 start:3099169330 end:3099169330 diff:0 ms (0.0 seconds)
F1450013744_4_1(6):Database Characterset for F1450013744_4_1 is AL32UTF8
F1450013744_4_1(6):Opatch validation is skipped for PDB F1450013744_4_1 (con_id=0)
F1450013744_4_1(6):Opening pdb with no Resource Manager plan active
Pluggable database F1450013744_4_1 opened read only
Completed: ALTER PLUGGABLE DATABASE “F1450013744_4_1” OPEN READ ONLY INSTANCES=ALL
TEST122AC(4):Completed: alter pluggable database application appcri2 begin uninstall
2018-08-30T12:49:02.396116+02:00
TEST122AC(4):alter pluggable database application appcri2 end uninstall
TEST122AC(4):Completed: alter pluggable database application appcri2 end uninstall

In verità non mi sembra sia possibile ripristinare una applicazione disintallata… però il clone serve a gestire il fatto che ci siano PDB collegati all’application container su cui non è stata fatta la sincronizzazione e quindi l’applicazione rimane installata.

Come avevo scritto nel mio post di introduzione agli “application container” ho testato la possibilità di creare più applicazioni su uno stesso application container; è possibile quindi, seppur non so quanto abbia senso, creare più applicazioni su uno stesso application container.

Dopo il primo test di base ho quindi disinstallato entrambe le applicazioni che avevo creato trovandomi con due cloni della application root. Ho quindi fatto un nuovo test cercando di creare un’applicazione “completa”, quindi sulla base dell’esempio di Tim Hall creando tablespace e schema al cui interno poi creare gli oggetti. Mi sono trovato un po’ in difficoltà a capire i privilegi necessari, negli esempi, anche  sui manuali si utlizza l’utenza SYS, però mi sembra un po’ eccessivo dover utilizzare una utenza superprivilegiata per installare delle applicazioni. Ho deciso di rimandare l’approfondimento sul tema privilegi ad  un’altra occasione e sono andato avanti con l’utenza SYS per creare una nuova applicazione con queste istruzioni:

alter session set db_create_file_dest=’/u01/app/oracle/oradata/test122/test122ac’;
alter pluggable database application appcri3 begin install ‘1.0’;
create tablespace apptbs1 datafile size 1 M autoextend on maxsize 2 g;
create user app1user identified by app1user default tablespace apptbs1 quota unlimited on apptbs1 container=ALL;
grant create session, create table to app1user;
create table app1user.apptable1 sharing=extended data (a number,b varchar2(100 char));
insert into app1user.apptable1 (a,b) values (1,’a’);
commit;
alter pluggable database application appcri3 end install;

Ho fatto una scelta un po’ bizzarra, ho usato OMF ma ho impostato il parametro DB_CREATE_FILE_DEST a livello di sessione, questo comporta occorrerà fare attenzione in fase di sincronizzazione dell’applicazione sui PDB, infatti se non si setta prima della sincronizzazione opportunamente il parametro accade questo:

SYS@//svil122p1 AS SYSDBA> alter pluggable database application appcri3 sync;
alter pluggable database application appcri3 sync
*
ERROR at line 1:
ORA-02236: invalid file name

Se invece si imposta prima il parametro DB_CREATE_FILE_DEST tutto fila liscio; mi sembra chiaro che se si vuole gestire in modo efficiente è utile impostare il parametro a livello di system root, quindi usare OMF per la gestione degli application container e dei PDB.

Ho fatto poi un banale test di aggiornamento dell’applicazione con questi comandi:

alter pluggable database application appcri3 begin upgrade ‘1.0’ to ‘1.1’;
create table app1user.apptable2 sharing=metadata (a number,b varchar2(100 char));
insert into app1user.apptable2 (a,b) values (2,’b’);
commit;
alter pluggable database application appcri3 end upgrade;

Mi sono trovato quindi con tre cloni della application root. A questo punto mi sono chiesto se è possibile contenere la prolificazione di questi cloni. In effetti un metodo c’è ed è l’impostazione del livello di compatibilità. Lanciando questo comando:

alter pluggable database application appcri3 set compatibility version ‘1.1’;

Sull’alert.log ho trovato questo:

TEST122AC(4):alter pluggable database application appcri3 set compatibility version ‘1.1’
ALTER PLUGGABLE DATABASE “F1450013744_23_1” CLOSE
2018-08-31T14:43:06.003621+02:00
F1450013744_23_1(8):JIT: pid 20697 requesting stop
Pluggable database F1450013744_23_1 closed
Completed: ALTER PLUGGABLE DATABASE “F1450013744_23_1” CLOSE
DROP PLUGGABLE DATABASE “F1450013744_23_1” INCLUDING DATAFILES
TEST122AC(4):Deleted Oracle managed file /u01/app/oracle/oradata/test122/test122ac/TEST122/74A7AB8E0E337014E0533B00640AEA9C/datafile/o1_mf_apptbs1_frhtnv92_.dbf
TEST122AC(4):Deleted Oracle managed file /u01/app/oracle/oradata/test122/test122ac/TEST122/74A7AB8E0E337014E0533B00640AEA9C/datafile/o1_mf_temp_frhtnv92_.dbf
TEST122AC(4):Deleted Oracle managed file /u01/app/oracle/oradata/test122/test122ac/TEST122/74A7AB8E0E337014E0533B00640AEA9C/datafile/o1_mf_undotbs1_frhtnv92_.dbf
TEST122AC(4):Deleted Oracle managed file /u01/app/oracle/oradata/test122/test122ac/TEST122/74A7AB8E0E337014E0533B00640AEA9C/datafile/o1_mf_sysaux_frhtnv91_.dbf
TEST122AC(4):Deleted Oracle managed file /u01/app/oracle/oradata/test122/test122ac/TEST122/74A7AB8E0E337014E0533B00640AEA9C/datafile/o1_mf_system_frhtnv90_.dbf
Completed: DROP PLUGGABLE DATABASE “F1450013744_23_1” INCLUDING DATAFILES
TEST122AC(4):Completed: alter pluggable database application appcri3 set compatibility version ‘1.1’

E in effetti il clone è stato rimosso:

SYS@//test122ac AS SYSDBA> select con_id,name,APPLICATION_ROOT_CON_ID,APPLICATION_ROOT_Clone from v$containers;

CON_ID NAME APPLICATION_ROOT_CON_ID APP
———- —————— ———————– —
1 CDB$ROOT NO
2 PDB$SEED NO
3 SVIL122P1 4 NO
4 TEST122AC NO
5 TEST122P1 4 NO
6 F1450013744_4_1 4 YES
7 F1450013744_3_1 4 YES

Esiste anche l’opzione di impostare il livello di compatibilità al valore “corrente”:

alter pluggable database application appcri1 set compatibility version current;

In questo modo anche i cloni creati in seguiti alla disinstallazione delle applicazioni sono stati rimossi, cosa che mi è piaciuta. Nel dizionario dati, come scritto sulla documentazione rimangono comunque le informazioni sulle applicazioni:

SYS@//test122ac AS SYSDBA> select * from DBA_APP_PDB_STATUS;

CON_UID APP_NAME APP_ID APP_VERSION APP_STATUS
———- ——————– ———- —————————— ———–
4143301262 APP$7491A9CF30E3674F 2 1.0 NORMAL
E0533B00640A0B7F

1030522367 APP$7491A9CF30E3674F 2 1.0 NORMAL
E0533B00640A0B7F

4143301262 APPCRI3 23 1.1 NORMAL
1030522367 APPCRI3 23 1.1 NORMAL
4143301262 APPCRI1 3 1.0 UNINSTALLED
1030522367 APPCRI1 3 1.0 UNINSTALLED
1030522367 APPCRI2 4 1.0 UNINSTALLED
4143301262 APPCRI2 4 1.0 UNINSTALLED

8 rows selected.

Oracle RDBMS 12.2 bug noti: 25710407

giovedì 30 agosto 2018 alle 30:53 | Pubblicato su Diario | 1 commento

Sto lentamente configurando e studiando una installazione di della versione 12.2 del database Oracle. Stamattina cercando informazioni nell’alert.log per un problema con un application container ho trovato un errore ricorrente con questo testo:

ORA-12012: error on auto execute of job “SYS”.”ORA$AT_OS_OPT_SY_3476″
ORA-20001: Statistics Advisor: Invalid task name for the current user
ORA-06512: at “SYS.DBMS_STATS”, line 47207
ORA-06512: at “SYS.DBMS_STATS_ADVISOR”, line 882
ORA-06512: at “SYS.DBMS_STATS_INTERNAL”, line 20059
ORA-06512: at “SYS.DBMS_STATS_INTERNAL”, line 22201
ORA-06512: at “SYS.DBMS_STATS”, line 47197

 

Ho fatto una breve ricerca e dopo essere passato per la nota del supporto oracle 2127675.1 che indica che l’errore è dovuto a qualche problema in fase di installazione sono passato anche dal forum ufficiale di oracle che a sua volta rimanda a questa sezione della documentazione ufficiale: “DBCA Known Bugs“.  La soluzione indicata è rapida e sembra risolvere. Dico sembra perché verificherò domani se il messaggio non compare più. Il “readme” della documentazione contiene una sezione “Open bugs” piuttosto corposa che conviene esaminare, magari trovo la soluzione anche per il problema da cui sono partito.

 

Oracle 12cR2 Multitenant Environment: Introduzione

domenica 12 agosto 2018 alle 12:57 | Pubblicato su 12cR2, Diario | 2 commenti
Tag:

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.

 

Oracle 12cR1 e 12cR2

lunedì 30 luglio 2018 alle 30:03 | Pubblicato su 12cR2, Diario, Oracle Certification | Lascia un commento

Ebbene, con un certo ritardo, ma sempre meglio tardi che mai dico io, sono riuscito a recuperare un po’  di ritardo e istruirmi un po’ su Oracle 12c R1; alcuni giorni fa sono riuscito a superare l’esame per aggiornare la certificazione Oracle database OCP alla versione 12c, non è stata una passeggiata. Per la verità ho fallito un primo tentativo, cosa che ha colpito un po’ il mio orgoglio e mi aveva anche un po’ abbattuto. Fra l’altro la cosa forse peggiore era il fatto che avessi fallito la sezione dell’esame “Key DBA Skills” superando invece quella “12c new features”. Sta di fatto che alla fine, studiando alla fine ce l’ho fatta e sento anche di aver dato un po’ una smossa alla mia testa che fino a un paio di mesi fa faceva assai fatica a ordinare i tanti concetti nuovi. Ora vorrei approfittare del fatto di aver lubrificato il mio cervello cercando di mantenermi al passo facendo un nuovo scalino e studiando le nuove caratteristiche introdotte con la versione 12cR2, d’altra parte è una versione disponibile “on-premise” da quasi un anno e mezzo, mentre da pochi giorni è disponibile la 18c che vorrei iniziare a vedere e provare in breve tempo ma dopo aver preso dimestichezza con la 12cR2.

La mia idea è di partire da qui, magari prendendo un po’ di appunti e pubblicandoli pure come post su questo blog. A occhio non mi sembra ci siano poche cose, quindi credo che mi ci vorrà un po’.

SQLcl, UTF-8 e windows

giovedì 26 luglio 2018 alle 26:19 | Pubblicato su 12c, Diario, Installation and Configuration | Lascia un commento

Oggi ho provato a scaricare e vedere com’è l’ultima versione di SQL Developer, la 18.2. Ho dato una rapida occhiata e non ho visto cose stratosferiche. Il problema è che più invecchio più mi sento distante dall’informatica moderna dove tutti vogliono interfacce grafiche, mentre io mi ostino a usare  e preferire per molte attività interfacce a linea di comando. Continuo a non vedere grandi vantaggi. D’altra parte continuo a ritenere che i migliori sistemi sono quelli che hanno la possibilità di essere controllati con comandi a linea di comando che permettono di prepare script che rendono le attività ripetitive una cosa assai facile. Poi sopra ci si può implementare interfacce grafiche che aiutano per attività più sporadiche o per dare delle panoramiche di un sistema. Anche Oracle implementa tutto o quasi via SQL, poi c’è la console grafica Cloud Control che permette senz’altro una gestione globale e generale più facile. Ho un po’ divagato rispetto al tema che voglio trattare in questo post. Su SQL Developer ho visto un link a SQLcl, una sorta di sostituto di SQL*Plus, ovvero un client a linea di comando SQL. SQLcl mi sembra per molte cose compatibile con SQL*Plus ma con in più qualche miglioria, anche qui mi vien da dire non cose stratosferiche. Ho provato a vedere se c’è la “dynamic linesize”, come su SQL*Plus 18.1, ma non l’ho trovato, con un certo sconforto. Poi mi è venuto in mente di controllare come gestisce la codifica in UTF-8, al riguardo negli anni ho avuto sempre qualche problema ed ho scritto una serie di post, l’ultimo dovrebbe essere questo. Quel post è del 2013, siamo arrivati al 2018 e poco è cambiato. Ho fatto un rapido test per vedere come SQLcl gestisce la codifica e il risultato è stato negativo. Ho quindi fatto una rapida ricerca, arrivando qui. Credo di esserci gia passato qualche tempo fa ma probabilmente non ho avuto modo di approfondire ne’ scrivere qualcosa, ho quindi deciso di farlo oggi. Senza farla tanto lunga, per gestire un po’ la codifica di caratteri particolari in UTF-8 occorre, sotto windows sempre settare il font a “Lucida Console”, settare il codepage a 65001 (chcp 65001) e poi, non basta. A quanto pare SQLcl non usa le variabili d’ambiente, quindi settare o meno NLS_LANG=.AL32UTF8 come faccio con SQL*Plus non sembra fare differenza e lo stesso Jeff Smith afferma che non vengono lette variabili d’ambiente per settare gli NLS. Siccome quanto affermato nel post con la mia installazione di SQLcl su win7 non funziona,

-----------
Luned�
Marted�
Mercoled�
Gioved�
Venerd�
Sabato
Domenica

ho scorso i commenti, fino ad arrivare a questo. Le cose migliorano:

 Lunedì

 Martedì

 Mercoledì

 Giovedì

 Venerdì

 Sabato
 Domenica

C’è una anomalia nella formattazione che sembra che in coda al carattere accentato venga messo un accapo, anche se non è così… boh.

Le cose se facciamo una prova con una cosa tipo: “select ‘è’ from dual;” non vanno benissimo:


CRISTIAN@svil > select '�' from dual;



è

Che poi è sempre meglio di SQL*Plus:

CRISTIAN@svil > select 'è' from dual;
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

 

La risposta secondo me sta tutta in questo commento in cui Jeff Smith aspetta da MSFT un terminale decente…secondo me non c’è speranza

Trasportare Dati

lunedì 18 giugno 2018 alle 18:24 | Pubblicato su 12c, Diario | Lascia un commento

Titolo breve e semplice, tratto da questo capitolo del manuale Oracle. Quello che voglio fare in effetti è solamente un breve riassunto del contenuto di quel capitolo del manuale “Oracle Database Administrator’s Guide” che parla di una tecnica per trasportare in modo efficente e veloce grosse moli di dati da un database Oracle a un’altro. Il principio di base è quello di saltare un passaggio rispetto a un classico export e import tramite Oracle Data Pump. Infatti, se pensiamo di utilizzare un dump per portare dei dati da un database a un’altro dobbiamo esportare i dati su un file di dump, copiare il file di dump sulla macchina dove si trova il database di destinazione e li importare i dati dal dump al database. Con l’opzione TRANSPORTABLE=ALWAYS è possibile in Oracle 12c (e a certe condizioni gia dalla versione 11.2.0.3) effettuare un export che in realtà nel dump generato metterà solo i metadati e nel caso di FULL=Y (intero database) eventualmente anche i dati di oggetti utente che dovessero stare su tablespace di sistema (SYSTEM e SYSAUX).  Credo che nel banale caso di tabelle utente che risiedano su una di queste due tablespace sarebbe anche meglio sanare la situazione prima, poi non so se ci possono essere casi particolari o motivazioni per cui non possa essere fatto. In ogni caso il principio è che in questo modo anche se dobbiamo spostare grossi volumi di dati l’operazione di export dovrebbe essere relativamente veloce. Preventivamente occorre mettere in modalità READ-ONLY le tablespace contenenti i dati utente, infatti, una volta lanciato il comando di export che come scritto sopra si limiterà, nel caso migliore,  a genere un file di dump che conterrà solo i metadati del database di origine. A quel punto si deve copiare sul file di destinazione questo file di dump e i datafile delle tablespace contenenti i dati utente (quelle che abbiamo messo in modalità READ-ONLY). Sul database di destinazione l’operazione di import farà specularmente le operazioni fatte sul database di origine con l’export, importerà i metadati degli oggetti e in più ricollegherà i datafile al nuovo database.  Come si può intuire, se il volume di dati è molto alto con questa tecnica il tempo necessario è solo quello di trasporto dei datafile, le operazioni di export e import non devono elaborare tutti i dati e quindi il risparmio di tempo può essere notevole.

Quello che ho descritto sinteticamente è il caso di Full transportable export/import, ovvero export e import di un intero database e che si attiva con i due parametri FULL=Y e TRANSPORTABLE=ALWAYS. Il parametro (e la modalità) TRANSPORTABLE=ALWAYS in associazione con FULL=Y è una novità di Oracle 12c, con Oracle 11.2.0.1 era stato introdotto ma era utilizzabile solo con il parametro TABLES per esportare tabelle o partizioni con la stessa logica. Già da prima di Oracle 11g esisteva la modalità “Transportable Tablespace Mode” che si basa sempre sullo stesso principio, ovvero esportare sul file di dump solo i metadati e affidarsi direttamente alla copia dei datafile per i dati veri e propri.

Vi sono una serie di limitazioni e casi particolari a cui porre attenzione per poter usare la modalità “TRANSPORTABLE”, prima di tutto occorre verificare l'”endianess” delle piattaforme di origine e destinazione, se sono diverse occorre convertire i datafile. La conversione può essere fatta con i metodi GET_FILE/PUT_FILE del package PL/SQL DBMS_FILE_TRANSFER o con il comando CONVERT di RMAN. Occorre porre attenzione alle tablespace criptate e nel caso di tablespace e tabelle/partizioni occorre fare attenzione al tipo dato TIMESTAMP WITH TIME ZONE, se i database di origine e destinazione hanno versioni diverse del file delle timezone i dati non vengono importati. Un problema analogo vale per tutti i casi, TABLE/PARTITION, TABLESPACE e FULL,  per il tipo dato TIMESTAMP WITH LOCAL TIME ZONE se i database di origine e destinazione hanno diversa “DBTIMEZONE”.

Rimando al capitolo del manuale indicato all’inizio per esempi molto ben fatti e chiari e maggiori dettagli sulle limitazione e casi particolari.

Oracle Resource Manager con CDB e PDB

venerdì 15 giugno 2018 alle 15:42 | Pubblicato su 12c, Diario, Installation and Configuration, Performance Tuning | Lascia un commento

Con l’introduzione dell’architettura “multitenant” in Oracle 12 si sono stati degli aggiornamenti e delle estensioni al funzionamento di Oracle Resource Manager che è lo strumento per ripartire in base a determinate esigenze le risorse disponibili su un server.  Confesso di non aver mai potuto testare e vedere in azione veramente il resource manager, credo di avere fatto solo delle piccole prove per gestire sessioni inattive e bloccanti ma non sono andato oltre. Oltre dieci anni fa (!) ho scritto un mio riassunto di cui ho parlato in questo post.  Dopo tanto tempo ho l’ambizione di fare un post riassuntivo delle novità del resource manager nell’ambito di Container database e Pluggable database.

Con l’architettura multitenant si è aggiunto un livello ulteriore su cui gestire le risorse in un database Oracle. Per cui in Oracle 12 su un database CDB il resource manager lavora a due livelli:

  • a livello CDB, in cui smista le risorse fra i PDB
  • a livello di PDB che come nella versione precedente smista le risorse fra gli utenti del singolo PDB.

Faccio riferimento a questa sezione del manuale Oracle.

CDB Resource Plans

un CDB resource plan alloca le risorse ai PDB in base al suo insieme di direttive (resource plan directives).

C’è una relazione padre-figlio tra un CDB resource plan e le sue direttive. Ogni direttiva fa riferimento a un PDB e non ci possono essere due direttive nel piano correntemente attivo che fanno riferimento allo stesso PDB.

Le direttive controllano l’allocazione delle seguenti risorse ai PDB:

  • CPU
  • Parallel execution server.

Le direttive di un CDB resource plan sono molto semplici, hanno tre parametri:

  • SHARE: rappresenta la fetta di CPU e di parallel server riservata al PDB
  • UTILIZATION_LIMIT: è un limite superiore alla percentuale di CPU utilizzabile dal PDB
  • PARALLEL_SERVER_LIMIT: è un limite superiore percentuale (sul valore impostato tramite il parametro PARALLEL_SERVERS_TARGET)

Esiste una direttiva di default per i PDB per cui non è stata definita una direttiva e assegna uno share e un limite del 100% sia per UTILIZATION_LIMIT e PARALLEL_SERVER_LIMIT.   Questa direttiva può essere modifica con la procedura dedicata del package DBMS_RESOURCE_MANAGER UPDATE_CDB_DEFAULT_DIRECTIVE.

C’è poi un’altra direttiva predefinita, chiamata AUTOTASK che si applica ai task di gestione automatica (automatic maintenance tasks) che girano nel root duranto le finestre di manutenzione. Questa direttiva può essere modificata con la procedura UPDATE_CDB_AUTOTASK_DIRECTIVE

Una cosa curiosa, scritta sul manuale, è che se un PDB viene scollegato “unplugged” la direttiva che lo riferisce viene mantenuta e nel caso il PDB venga ricollegato viene riutilizzata. Qui ho una lacuna da colmare perché mi sembra di ricordare dai miei test che dopo l’unplug l’unica cosa che si può fare con un PDB e la rimozione, dopodiché si riesce a ricollegare; mi sembra strano che venga mantenuto un riferimento a un PDB rimosso… spero di poter fare una prova al riguardo.

PDB Resource Plans

A livello di PDB si definiscono dei piani in maniera analoga a quanto si faceva prima su database non-CDB, ci sono però dei limiti:

  • un PDB resource plan non può avere sottopiani
  • un PDB resource plan può avere un massimo di otto consumer group
  • un PDB resource plan non può avere politiche di schedulazione multi-livello (multiple-level scheduling policy)

Se si collega come PDB un database non-CDB che ha dei resource plan che non rispettano i vincoli sopra Oracle modificherà i piani per farli rientrare nei vincoli.

P.S. 18/06/2018

sono riuscito a fare una prova riguardo al definire un CDB plan con delle direttive che fanno riferimento a un PDB. Ho fatto successivamente l’unplug e poi il drop del PDB ed effettivamente la direttiva che riferisce il pluggable database rimosso rimane.

Copiare, spostare o rinominare un datafile in Oracle

martedì 12 giugno 2018 alle 12:05 | Pubblicato su 12c, Diario, Installation and Configuration | 2 commenti

Breve post promemoria sui concetti che si possono trovare su questa parte dei manuali Oracle. Il motivo per cui lo faccio è che faccio fatica a memorizzare la sintassi dei vari comandi Oracle e con la versione 12.1 c’è la possibilità di copiare o spostare o rinominare i file “online”.  Per supportare questa nuova funzionalità Oracle ha introdotto una nuova sintassi, il comando è:

ALTER DATABASE MOVE DATAFILE ( ‘filename’ | ‘ASM_filename’ | file_number )
[ TO ( ‘filename’ | ‘ASM_filename’ ) ]
[ REUSE ] [ KEEP ]

Il bello di questo comando è che si occupa lui anche di copiare “fisicamente” il file. L’unica restrizione che trovo sul manuale è che il datafile deve essere in modalità “online” altrimenti il comando restituisce errore. Pare quasi una banalità…

Nella modalità pre-12 c’erano due possibili comandi:

  • ALTER DATABASE RENAME FILE…

  • ALTER TABLESPACE <tbsname> RENAME DATAFILE …

 

in entrambi in casi occorre prima portare i datafile offline in qualche modo (nel secondo si può mettere offline solo la tablespace interessata, nel primo si può mettere in stato mount l’intero database, questo nel caso la rinomina o lo spostamento riguardi più file…) in questo caso poi, dopo aver portato in modalità offline i file occorre, prima di eseguire i comandi copiare/spostare/rinominare i file “manualmente”,  il comando si limita ad aggiornare le informazioni registrate sul controlfile.

Real-Time Database Operation Monitoring

giovedì 7 giugno 2018 alle 07:24 | Pubblicato su 11g, 12c, Diario, Performance Tuning | Lascia un commento

Con la versione 11.1 Oracle ha introdotto un nuovo strumento di diagnosi e analisi delle prestazioni chiamato “Real-Time SQL Monitoring”. Si tratta di uno strumento che permette di controllare o monitorare in tempo reale l’esecuzione di query o statement SQL che durano a lungo e consumano risorse in modo significativo. Oracle in determinate condizioni, quando in una sessione gira una query che attiva l’esecuzione in parallelo o consuma più di 5 secondo di tempo CPU o I/O, comincia a registrare le principali statistiche di esecuzione dello statement quali tempo CPU, letture su disco, letture da buffer ecc e le espone tramite due viste chiamate V$SQL_MONITOR e V$SQL_PLAN_MONITOR.  Le statistiche vengono aggiornate ogni secondo e successivamente mantenute per almeno 5 minuti (qui dice così, qui dice un minuto), dopodiché se l’area di memoria in SGA dove risiedono queste informazioni è in esaurimento le statische possono venir cancellate. Si tratta di una evoluzione significativa rispetto alle analisi che si potevano e si possono ancora fare sulle classiche viste V$SQL e V$SQL_PLAN perché ad esempio le statistiche esposte sulle nuove viste sono legate alla singola esecuzione e non cumulative come nelle tradizionali V$SQL e V$SQL_PLAN. Vi è poi la possibilità, tramite procedure del package DBMS_SQLTUNE, di   avere dei report dettagliati e completi sull’esecuzione di una singola query: troviamo piano di esecuzione, valori delle bind variables. Ci sono  statistiche come il numero di righe attese e quello reale che prima era difficile avere. Naturalmente queste informazioni sono accessibili in modo comodo dalle console grafiche Cloud Control e, per 12c,  EM Express.

Con la versione 12.1 il concetto di Real-Time SQL Monitoring è stato esteso ed è diventato “Real-Time Database operation monitoring”. E’ possibile dalla versione 12c avere le stesse informazioni ma non più solo a livello di singolo statement SQL o blocco PL/SQL ma anche per un blocco di istruzioni delimitato temporalmente all’interno di una sessione che è definito appunto Database Operation. Ad esempio è possibile così monitorare complesse procedure ETL o altri tipo di procedure batch per tenere traccia dell’esecuzione ed individuare problemi di prestazioni o controllarne il consumo di risorse. Con oracle 12c è stato introdotto un nuovo package PL/SQL chiamato DBMS_SQL_MONITOR che fornisce le procedure “BEGIN_OPERATION” e “END_OPERATION” che servono appunto a delimitare le istruzioni che compongono la “database operation” che si vuole monitorare e analizzare. Oltre a quelle due procedure nel package si ritrovano le procedure “REPORT_SQL_MONITOR” e “REPORT_SQL_MONITOR_LIST” che si trovano ancora nel package DBMS_SQLTUNE, non so quale sia la differenza.

Posso solo segnalare una mancanza nel report, che da un lato da indicazioni in tempo reale anche sul punto in cui si trova l’esecuzione, dall’altro però non include le “predicate information” che si hanno ad esempio con la funzione “dbms_xplan.display_cursor”. Questo è un peccato perché costringe a fare una analisi con più strumenti per avere tutte le informazioni che possono essere utili ad analizzare le prestazioni di una query.

“Real-Time Database operation monitoring” è una “feature” del pacchetto “Oracle Database Tuning Pack” (per il quale quindi serve apposita licenza).

 

Pagina successiva »

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.