In-Database Archiving e Temporal Validity

lunedì 4 giugno 2018 alle 04:03 | Pubblicato su 12c, Diario | Lascia un commento

Con la versione 12c Oracle ha introdotto due nuove caratteristiche/funzionalità chiamate rispettivamente “In-Database Archiving” e “Temporal Validity”. Entrambe queste nuove funzionalità rientrano nel contesto del cosiddetto “Information Lifetime Management (ILM)” ovvero la gestione del ciclo di vita delle informazioni.

In-Database Archiving

è possibile attivare per una tabella, alla sua creazione o dopo, questa funzionalità con la clausola “row archival”.  Di fatto Oracle aggiunge semplicemente una colonna nascosta chiamata “ORA_ARCHIVE_STATE” che per default viene popolata con il valore ‘0’. Normalmente non succede nulla. Aggiornando esplicitamente il campo ORA_ARCHIVE_STATE con un valore diverso da ‘0’ Oracle durante tutte le DML sulla tabella filtrerà fuori le righe con il valore ORA_ARCHIVE_STATE, rendendole quindi “nascoste”, archiviate. Per cambiare il comportamento si posson usare i seguenti statement:

ALTER SESSION SET ROW ARCHIVAL VISIBILITY=ALL;

ALTER SESSION SET ROW ARCHIVAL VISIBILITY=ACTIVE;

Temporal Validity

similmente a quanto visto sopra è possibile aggiungere alle tabelle una “dimensione temporale”, cioè due campi “timestamp” che vengono gestiti in modo “automatico” da Oracle per filtrare i dati che risultano validi o meno in base a un fattore temporale. Di fatto vengono aggiunti due campi timestamp che rappresentano la data inizio validità e fine validità. Come per “In-Database Archiving” i due campi sono nascosti, c’è anche la possibilità di utilizzare due campi già definiti. La cosa curiosa qui è che per default vengono visualizzati tutti i dati. Per cambiare questo comportamento di può usare la seguente chiamata:

EXEC DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME(‘CURRENT’);

E’ neccessario dare da utente SYS il privilegio di execute sul package DBMS_FLASHBACK_ARCHIVE. In alternativa occorre usare la sintassi estesa nelle query con la clausola “PERIOD FOR”

Il motivo per cui ho dedicato un post a queste funzionalità non è tanto per la loro utilità quanto per l’ambiguità e scarsa chiarezza del loro supporto. Non mi è chiaro se “In-Database Archiving” e “Temporal Validity” siano sotto poste a limiti di licenza. Non ho trovato traccia sul manuale il che mi porta a credere che siano utilizzabili gia con Standard Edition, ed in effetti io le ho testate su una Standard Edition.

Altra cosa, viene detto che “Temporal Validity” non è supportata su CDB, io ho testato su un PDB dove ha funzionato regolarmente.  Non mi è chiaro che tipo di problema ci possa essere per non supportarla su CDB e mi sembra una grossa limitazione visto che l’architettura Multitenant è stata presentata come una delle novità più rilevanti.

P.S.

per approfondimenti sulle due funzionalità rimando al manuale di riferimento: https://docs.oracle.com/database/121/VLDBG/GUID-BD1D524E-A55F-4CD4-911E-092E596F0D80.htm#VLDBG14153

P.P.S.

spulciando il manuale sulle licenze ho notato che la “feature” “Flashback data archive” è diventanta disponibile su tutte le edizioni, quindi anche su Standard Edition, senza le ottimizzazioni nuove.

Annunci

Ottimizzatore Oracle 12cR1 note varie

venerdì 25 maggio 2018 alle 25:04 | Pubblicato su 12c, Diario, Performance Tuning | 2 commenti

Gli ultimi due post che ho scritto erano dedicati alle nuove funzionalità introdotte nell’ottimizzatore delle query in oracle 12c (12.1). Ho riassunto in due post relativamente brevi una serie di  funzionalità abbastanza consistente e su quegli argomenti si potrebbe veramente scrivere molto. In realtà è già stato scritto molto, il problema è leggere tutto e riordinare tutte le informazioni. Questo post prende spunto principalmente da una letta che ho dato a un paio di post sul blog di Christian Antognini sull’argomento “Adaptive query optimization”, in particolare questo, questo  e questo.  Volendo ce ne sono anche altri, basta aver tempo di leggerli con attenzione. Io riassumerei, anche leggendo la nota del supporto Oracle “Recommendations for Adaptive Features in Oracle Database 12c Release 1 (Adaptive Features, Adaptive Statistics and 12c SQL Performance) (Doc ID 2312911.1)” , che qualche problemino su Oracle 12.1 lo si può avere con queste nuove caratteristiche e usarle e tenerle sotto controllo con tutti i parametri e le variabili coinvolte non mi sembra affatto facile. In ogni caso per riuscirci è proprio il caso di leggere bene i post di Antognini  e le note del supporto Oracle che indica, seguendo anche gli ulteriori rimandi che si trovano. Forse con la versione 12.2 le cose vanno meglio.

Per quanto mi riguarda ho voluto provare su un database di sviluppo interno a mettere in opera le SQL Plan Baselines mettendo il parametro OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES a TRUE; dopo alcuni giorni però ho avuto alcune segnalazioni da sviluppatori che accedendo al database con SQL Developer avevano problemi di lentezza. Non ho avuto modo di fare una analisi seria, ho solo identificato la causa in una query lanciata da SQLDeveloper che recupera le informazioni sulle colonne delle tabelle, a quanto pare la query  rivista da oracle rimaneva per qualche motivo bloccata. Per risolvere velocemente il prolema ho dovuto reimpostare il parametro OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES a FALSE e siccome non risolveva il problema ho impostato anche OPTIMIZER_USE_SQL_PLAN_BASELINES a FALSE, perché immagino che avendo comunque creato una serie di SQL Plan Baselines l’ottimizzatore continuasse ad usarle, anche non ne creava più di nuove. Essendo la query su viste di sistema (in particolare la ALL_OBJECTS per il cui il solo count usa un piano con 129 righe) non sono riuscito a capirci molto, sono però rimasto un po’ deluso da una funzionalità che dovrebbe avere lo scopo di impedire peggioramenti di prestazioni.

SQL Plan Management e SQL Plan Baselines

venerdì 4 maggio 2018 alle 04:20 | Pubblicato su 12c, Diario, Performance Tuning | Lascia un commento
Tag:

Con la versione 11.1 Oracle ha sostituito il meccanismo chiamato “Stored Outlines” con uno nuovo chiamato “SQL Plan Baselines”. L’obiettivo è rimasto lo stesso, quello di prevenire il peggioramento delle prestazioni dovuto a cambiamenti di sistema, di versione dell’ottimizzatore o altro che possa far cambiare il piano di esecuzione scelto per una query SQL. Evidentemente le stored outlines erano limitate rispetto alle nuove “SQL Plan Baselines” tanto appunto da richiedere una cosa molto più sofisticata che quindi ha preso un nuovo nome. Cercherò di riportare una sintesi di quanto riporta il manuale “Oracle 12.1 Database SQL Tuning Guide”, capitolo 23: Managing SQL Plan Baselines” Posso dire che a suo tempo ho studiato le Stored Outlines ma non sono mai riuscito ad utilizzarle perché non si adattavano alle esigenze che avevo. Le SQL Plan Baselines le ho esplorate da poco e non potrò per ora portare esperienze pratiche, mi limiterò quindi a quanto trovo sul manuale.

SQL Plan Baseline

Una SQL plan baseline (SPB) è un insieme di piani accettati che l’ottimizzatore è autorizzato ad utilizzare per uno statement SQL. Tipicamente i piani vengono introdotti in una SQL plan baseline dopo che è stato verificato che non portano a maggior uso di risorse con conseguente peggioramento delle prestazioni. Questo sistema si affianca al meccanismo dei “SQL Profile”, generati dal SQL Tuning Advisor che però sono un meccanismo reattivo, mentre l’SPB vuole essere un meccanismo proattivo: ha lo scopo di prevenire situazioni di peggioramento di prestazioni. Questo nel quadro di un aggiornamento di versione Oracle, di cambiamento di parametri o di cambiamento dell’hardware sottostante. All’interno di una SQL plan baseline ogni piano è specificato usando un insieme di “outline hints” che lo definiscono completamente. Questo si contrappone a SQL Profiles che piuttosto specificano solo degli hint che cercano di correggere errate stime sui costi del piano e quindi non forzano l’uso di un preciso piano.

SQL Plan Capture

La gestione dei piani di esecuzione tramite le SQL Plan baseline avviene in diversi passi, il primo di questi è la cattura e il salvataggio di tutte le informazioni sui piani di esecuzione di un insieme di statement SQL.  Le informazioni vengono salvate nella “SQL Management Base” (SMB). La cattura dei piani può avvenire in modo automatico tramite il settaggio del parametro OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES a “true” (per default è “false”). Quando il parametro è a true il database crea una SQL plan baseline per ogni statement SQL “ripetibile” eseguito sul database stesso.

La cattura manuale avviene tramite procedure del package PL/SQL DBMS_SPM (DBMS_SPM.LOAD_PLANS_FROM_%) e consiste nel caricamento o da un “SQL tuning set (STS)” o dalla “share SQL area” o da una “tabella di staging” o da una “Stored Outline”. Non posso non riportare una immagine dal manuale che mi sembra molto chiara e completa:

Un piano caricato manualmente viene salvato come “accettato”

SQL Plan Selection

Come si vede dalla figura sopra nella SQL Management Base viene salvato anche la storia di un piano di esecuzione, cioè vengono registrati i cambi di piano

Quando il database esegue un “hard parse” di uno statement SQL l’ottimizzatore genera un piano ottimale per costo. Per default poi l’ottimizzatore cerca un piano che corrisponda nella SQL plan baseline di quello statement. Se non trova una SQL plan baseline per quello statement usa il piano gia generato (crea la SPB e aggiunge il piano come “accepted”), se la trova e il piano generato è gia nella baseline allora lo usa, se non c’è lo aggiunge alla “plan history” marcato come “unaccepted”. In quest’ultimo caso, se esistono piani fissati viene usato quello con il costo minore, se non esistono piani fissati viene usato il piano nella baseline con il costo minore, se non esistono piani riproducibili nella baseline (ad esempio perché nel frattempo è stato rimosso un indice) allora l’ottimizzatore usa il nuovo piano generato. Un piano fissato è un piano accettato e marcato manualmente come preferito.

SQL Plan Evolution

L’evoluzione di un piano è il procedimento che consiste nel verificare che i piani non accettati abbiano pretazioni almeno pari a quelli gia accettati (SQL Plan verification) e in tal caso nella loro aggiunta ai piani accettati della baseline. È possibile configurare il SQL Plan management affinché vengano eseguite tutte le possibili combinazioni dei due passi, cioè si può fare la verifica del piano senza l’aggiunta alla baseline e si può fare l’aggiunta senza fare la verifica. Il package PL/SQL DBMS_SPM fornisce le seguenti procedure:

  • SET_EVOLVE_TASK_PARAMETER
  • CREATE_EVOLVE_TASK
  • EXECUTE_EVOLVE_TASK
  • REPORT_EVOLVE_TASK
  • IMPLEMENT_EVOLVE_TASK
  • ACCEPT_SQL_PLAN_BASELINE

Queste procedure servono per avviare manualmente il processo di evoluzione. Oracle comunque raccomanda di lasciare al task automatico SYS_AUTO_SPM_EVOLVE_TASK (introdotto in Oracle 12c) il compito di fare il lavoro di verifica e accettazione durante la finestra di manutenzione pianificata (normalmente ogni notte)

SQL Management Base (SMB)

Si tratta della struttura logica dove vengono salvate le informazioni relative alle SQL plan baseline, fisicamente stanno nella tablespace SYSAUX. Le componenti sono quattro:

  • SQL statement log
  • SQL plan history (che include le sql plan baseline)
  • SQL profiles
  • SQL patches

SQL statement log

Durante il “parse” dello statement oracle calcola una “firma” (SQL signature)  normalizzando rispetto a maiuscole e minuscole e a spazi il testo, quando avviene la cattura automatica viene cercata la firma all’interno del “SQL statement log” (SQLLOG$), se non c’è l’aggiunge se c’è lo statement si può definire un “repeated SQL statement”

SQL Plan History

si tratta dell’insieme di piani di esecuzione catturati,  si quelli accettati, quindi nelle SQL plan baseline che quelli non accettati. Dalla versione 12c viene salvato il piano intero per tutti i piani, in questo modo non deve essere ricompilato lo statement per rigenerare il piano. I piani possono essere abilitati (enabled), che è il default o no. Nel caso non siano abilitati non vengono utilizzati anche se accettati.

La SQL Plan history può essere analizzata tramite la vista DBA_SQL_PLAN_BASELINES, tramite la procedure DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE è possibile vedere il dettaglio di una SQL plan baseline.

 

Oltre al parametro OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES citato prima c’è un’altro parametro OPTIMIZER_USER_SQL_PLAN_BASELINES che per default è impostato a true e fa si che comunque per gli statement che hanno gia SQL plan baseline esistenti vengano aggiunti nuovi piani come non accettati. Se viene impostato a false viene disabilitato completamente l’uso delle baseline.

Sul manuale si trovano ulteriori dettagli ed esempi sulla gestione che non sto qui a riportare per non appesantire troppo il post

Ottimizzatore delle query in Oracle 12c

venerdì 27 aprile 2018 alle 27:53 | Pubblicato su 12c, Diario, Performance Tuning | Lascia un commento
Tag:

Con questo post ho l’ambizione di riassumere le principali caratteristiche dell'”ottimizzatore” di query di Oracle. L’impresa sta nel far stare in un unico post tutte le principali informazioni, cosa che non so se sarò in grado di fare vista l’abbondanza di elementi che il soggetto ha in questa versione di Oracle. Premetto che la fonte principale delle informazioni è il manuale Oracle “Database SQL Tuning Guide” versione 12.1. Trovo che la manualistica Oracle sia molto ben fatta, molto ampia è approfondita quanto basta. Siccome studiando per la certificazione ho avuto qualche difficoltà a mettere insieme e in ordine nella mia memoria tutti gli argomenti trattati in questo capitolo ho sentito la necessità di scrivere questo post che seguirà il tracciato del manuale. Se dovesse diventare troppo lungo lo spezzerò in più post.

Cominciamo con un veloce ripasso dei concetti di base, a partire dalle definizioni, tenendo conto che tradurre tutto è difficile quindi per semplicità, a differenza di quello che ho fatto nel titolo, manterrò la nomenclatura originale in inglese.

Il “query optimizer”, chiamato più in breve semplicemente “optimizer” (o ottimizzatore) è quella parte del software Oracle che si occupa di determinare il modo più efficente di recuperare i dati richiesti tramite una query SQL; il risultato dell’elaborazione dell’ottimizzatore è il “piano di esecuzione”. Sappiamo che l’SQL è un linguaggio dichiarativo, quindi l’ottimizzatore può permettersi di scegliere abbastanza liberamente come recuperare e preparare i dati richiesti tramite SQL. In Oracle l’ottimizzatore è chiamato anche “cost-based optimizer” (CBO) perché le sue elaborazioni girano attorno al concetto di costo. Ogni elemento di accesso ed elaborazione dei dati da recuperare ha un costo che può essere tempo di CPU, tempo di accesso ai dischi e tempo di comunicazione. La somma dei costi di tutti i singoli passi di un piano di esecuzione da il costo del piano di esecuzione che sarà l’elemento di valutazione del piano stesso. Alla base di tutto ci sono una serie di statistiche, sui dati e sul sistema che l’ottimizzatore usa per stimare il costo finale di un piano.

Componenti dell’ottimizzatore

Il manuale ci dice che l’ottimizzatore consiste di tre componenti:

  1. Query transformer
  2. Estimator
  3. Plan generator

Query transformer

questo componente cerca di riscrivere un blocco SQL in uno semanticamente identico ma gestibile in modo più efficente, l’esempio banale fatto sul manuale è la trasformazione di una query con un “OR” in una query con una “UNION ALL”

Estimator

direi che questo è il compente più importante, quello che calcola il costo di un piano per un blocco SQL. Gli elementi di misura che usa l'”estimator” sono:

  1. Selectivity (selettività), percentuale dei dati estratti, questo dato non viene visualizzato nei piani di esecuzione.
  2. Cardinality (cardinalità), volume dati estratto
  3. Cost (costo), gli elementi base sono CPU, I/O e memoria. È la parte più complessa, tiene conto delle risorse utilizzate, nel numero stimato di righe restituite (cardinalità), della dimensione iniziale dell’insieme dei dati, della distribuzione dei dati e delle strutture di accesso.

 

Il costo non è necessariamente legato al tempo finale di esecuzione.

Plan generator

questo componente si occupa di generare possibili piani di esecuzione, confrontarne il costo e scegliere quello con il costo minore.

Sembra chiaro che le tre componenti in fase di generazione di un piano di esecuzione interagiscono continuamente e non lavorano semplicemente per stadi successivi.

Alla base di tutto vi sono delle statistiche di sistema, ad esempio: a certe operazioni che richiedono elaborazione di CPU verrà assegnato un costo in termini di cicli di CPU, poi il sistema in qualche modo terrà conto del costo di un ciclo di CPU. Poi ci sarà un costo per l’I/O, ad esempio il sistema stimerà che recuperare un blocco da disco costa tot e anche qui il costo potrebbe dipendere dalle prestazioni del sistema di I/O, mi vien da dire  che il tempo medio potrebbe essere 1 msec o 10 msec e fra i due c’è molta differenza. Ci sono poi operazioni come l'”hash join” che necessitano sia di CPU che di memoria per fare degli ordinamenti.

Le statistiche di sistema insomma sono dati “fissi” legati essenzialmente alle potenza computazionale della macchina su cui gira il database. Vi sono poi altre statistiche più complesse e molto importanti che sono quelle sui dati, ad esempio il numero di record in una tabella, la distribuzione dei valori in un campo di una tabella ecc. Mi sento di poter semplificare molto dicendo che le statistiche sui dati vengono moltiplicate per dei coefficenti fissi che sono dati dal tipo di operazione e le statistiche di sistema. Quindi potremmo avere due sistemi con lo stesso insieme di dati ma con caratteristiche computazionali molto diverse, supponiamo uno con tanta CPU e Memoria ma un I/O “lento” e uno opposto con poca CPU e memoria ma I/O molto veloce e nei due casi una stessa query SQL potrebbe dare origine a due piani molto diversi sui due sistemi. Ovviamente vale anche la situazione inversa (più comune), sistemi con caratteristiche computazionali uguali ma insiemi dati diversi. L’esempio più facile da capire è una select su una tabella voluminosa, se il filtro fa si che venga richiesta una percentuale molto piccola dei dati della tabella tipicamente il piano di esecuzione più efficente consiste nell’utilizzare un indice (dando per pressupposto che l’indice esista), viceversa se il filtro fa si che ad essere richiesti siano quasi tutti i dati della tabella allora è più efficente scandire direttamente tutta la tabella piuttosto che perdere tempo palleggiando tra indice e tabella.

Fin qui abbiamo fatto un ripasso generale su concetti di base che valgono anche in vecchie versioni Oracle, ora vediamo un po’ di cose nuove.

Automatic tuning optimizer

L’ottimizzatore può lavorare in due modalità

  • “normal optimization”, quella con cui normalmente genera i piani di esecuzione
  • “SQL Tuning Advisor optimization”, una modalità avanzata in cui l’ottimizzatore fa una analisi più accurata di uno statement SQL, il risultato però non è il piano di esecuzione ma una serie di suggerimenti con la loro motivazione (rationale) e la stima dei benefici

In realtà questa cosa forse esiste gia dalla versione Oracle 10g….

Adaptive Query Optimization

Questa funzionalità abilita l’ottimizzatore a fare delle correzioni al volo sul piano di esecuzione e a rilevare ulteriori informazioni che possono aiutare alle successive esecuzioni. L'”ottimizzazione adattiva” è utile quando le statistiche esistenti non permettono di generare un piano ottimale.

Gli elementi che rientrano nella “Adaptive query optimization” sono diversi:

  • Adaptive plans
    • Join methods
    • Parallel distribution methods
    • Bitmap index pruning
  • Adaptive Statistics
    • Dynamic Statistics
    • Automatic reoptimization
      • statistics feedback
      • performance feedback
    • SQL Plan Directives

Mi permetto di riportare un collegamento alla figura del manuale che rende meglio l’idea:

Adaptive Query Plans

Con questo nome di definisce la caratteristica per cui l’ottimizzatore è in grado di cambiare parte del piano di esecuzione anche dopo l’inizio dell’esecuzione del piano. Un adaptive plan (piano adattivo?) è un piano che contiene più sottopiani precalcolati e comprende un “optimizer statistics collector” (raccoglitore di statistiche). Durante l’esecuzione l’ottimizzatore tramite il “collector” inizia a raccogliere informazioni sull’esecuzione e se si accorge che le stime iniziali erano sbagliate può decidere di cambiare il “default plan” (quello scelto in partenza) con un altro piano, cambiandone un pezzo, quello che può cambiare è un metodo di join (hash piuttosto che nested loop). A questo punto il collettore di statistiche si ferma e il nuovo piano diventa quello definitivo.

Affinché questa funzionalità sia operativa devono essere impostati i seguenti parametri:

  • OPTIMIZER_FEATURES_ENABLE=12.1.0.1
  • OPTIMIZER_ADAPTIVE_REPORTING_ONLY=FALSE

Entrambi hanno quei valori per default.

Il parametro “FORMAT=>’ADAPTIVE'” della funzione DBMS_XPLAN.DISPLAY_CURSOR permette di visualizzare informazioni sugli “adaptive query plan”

Sul manuale vengono riportati degli esempi per ciascuno dei tre casi possibili, metodo di join, metodo di distribuzione parallela (al riguardo credo che l’argomento meriti un approfondimento, per ora mi limito a riportare il link al manuale) e “bitmap index pruning”.

Adaptive statistics

Quando i predicati nelle query sono molto complessi le statistiche di base sui dati da sole non garantiscono stime precise, per questo c’è il supporto delle “adaptive statistics” (statistiche adattive) che sono di tre tipi, Dynamic statistics, Automatic reoptimization e SQL Plan Directives

Dynamic Statistics

durante la compilazione di una query SQL l’ottimizzatore valuta se le statistiche disponibili sono sufficienti, altrimenti per aumentare i dati a disposizione usa le statistiche dinamiche che sono una estensione di quello che nelle versioni precedenti di Oracle veniva chiamato “dynamic sampling”. Queste statistiche possono venir usate per “table scans”, “index access”, join e GROUP BY.

Le statistiche dinamiche sono attivate in funzione del valore del parametro OPTIMIZER_DYNAMIC_SAMPLING che per default ha valore 2  che indica che il campionamento viene fatto solo se una delle tabelle coinvolte non ha statistiche. Il parametro accetta valori da 0 (dynamic statistics disabilitate completamente) a 11 dynamic statistics completamente automatiche

Automatic Reoptimization

Con l’adaptive query plan abbiamo visto può solo cambiare per un piano il tipo di join o il metodo di distribuzione parallela o applicare il bitmap index pruning. Per casi più complessi, ad esempio per cambiare l’ordine dei join può intervenire la automatic reoptimization, la quale però può solo stabilire un nuovo piano di esecuzione al termine della prima esecuzione della query in modo da utilizzarlo alle successive richieste. Non è in grado di cambiare un piano in esecuzione. Questo processo può continuare anche alle successive esecuzioni con l’obbiettivo di usare gli ulteriori dati raccolti per ottimizzare. La ri-ottimizzazione avviene sulla base di due tipologie di dati: “statistics feedback” e “performance feedback”

Statistics feedback

si tratta di quello che in precedenza si chiamava “cardinality feedback”. Se durante l’esecuzione di una query SQL l’ottimizzatore verifica una delle seguenti situazioni:

  • tabelle senza statistiche
  • predicati multipli congiuntivi o disgiuntivi  (traduzione mia, spero corretta)
  • predicati contenenti operatori complessi

allora attiva il monitoraggio delle statistiche di feedback. Se al termine dell’esecuzione c’è una differenza sostanziale fra dati rilevati e stime allora l’ottimizzatore salva le informazioni ad uso futuro sotto forma di SQL plan directive. In verità nel manuale dice che le salva e anche crea una SQL plan directive. Dopo la prima esecuzione il monitoraggio delle statistiche di feedback viene disabilitato.

Performance feedback

In questo caso vengono raccolte informazioni per stabilire un grado di parallelismo ottimale. Per attivare questa funzionalità occorre settare il parametro:

  • PARALLEL_DEGREE_POLICY=ADAPTIVE

Il principio rimane lo stesso, viene confrontato il grado di parallelismo calcolato a priori con quello calcolato alla fine dell’esecuzione sulla base dei dati raccolti (ad esempio tempo di CPU).

Sul manuale una nota dice che anche si parametro PARALLEL_DEGREE_POLICY non è settato a ADAPTIVE le “statistics feedback” possono influenzare il grado di parallelismo scelto per una query.

SQL Plan Directives

Si tratta di informazioni aggiuntive che l’ottimizzatore usa per generare  un piano ottimale. Si tratta di informazioni legate a “query expressions”, non all’intera query, questo permette di utilizzarle anche per query non uguali (seppur simili).

Durante la compilazione l’ottimizzatore verifica se mancano “statistiche estese” o istogrammi e ne registra la mancanza. Alle successive chiamate di raccolta delle statistiche tramite il package DBMS_STATS verranno calcolati eventuali istogrammi mancanti e statistiche estese.

Le SQL Plan Directives (SPD) vengono salvate nella SHARED POOL e ogni 15 minuti in modo permanente sulla tablespace SYSAUX . Se per 53 settimane non vengono usate vengono eliminate automaticamete. Possono essere gestite con il package PL/SQL DBMS_SPD, sul manuale riporta un esempio d’uso dei seguenti due metodi:

  • FLUSH_SQL_PLAN_DIRECTIVE (forza la scrittura su disco)
  • DROP_SQL_PLAN_DIRECTIVE

Vi sono poi dei metodi per esportare e importare le SPD

Le viste per vedere le SPD sono:

  • DBA_SQL_PLAN_DIRECTIVES
  • DBA_SQL_PLAN_DIR_OBJECTS

Extended Statistics

Le statistiche estese sono statistiche su gruppi di colonne o statistiche su espressioni. Le normali statistiche sulle singole colonne possono non bastare se i dati di due colonne  hanno una correlazione “imprevedibile”. Tramite il package DBMS_STAT e precisamente i seguenti metodi:

  • SEED_COL_USAGE
  • REPORT_COL_USAGE
  • CREATE_EXTENDED_STATS

É possibile, in maniera semiautomatica creare estensioni basandosi un test di carico. Una volta creata l'”estensione” le statistiche verranno raccolte anche sull’estensione e utilizzate dall’ottimizzatore.

È possibile visualizzare le estensioni esistenti tramite la vista USER_STAT_EXTENSIONS

 

Con questo penso di potermi fermare qui. La lunghezza del post mi pare accettabile e il livello di approfondimento è medio, spero di riuscire a trascrivere ancora qualcosa per approfondire ed estendere la tematica.

Competenza e Certificazione

lunedì 16 aprile 2018 alle 16:39 | Pubblicato su Diario | Lascia un commento

Nell’intento di riprendere a scrivere qualcosa con una certa regolarità continuo con un altro post poco tecnico, inspirato dal mio attuale impegno per aggiornare la mia certificazione Oracle alla versione 12c e questo post di Connor McDonald. Penso valga la pena sottolineare e ribadire i concetti espressi in quel post in quanto io li condivido (in tutti i sensi). Se c’è un motivo per cui in tre anni ancora non ho fissato una data per fare l’esame di certificazione, è perché non sono riuscito ad approfondere ogni argomento oggetto dell’analisi fino ad avere acquisito confidenza con quella particolare caratteristica ed averla almeno collaudata e toccata con mano. Il cosiddetto “hand on”. Questo perché la certificazione per me non è tanto un fine ma un mezzo. Di fatto molti degli argomenti che ho studiato sulla guida per me erano veramente nuovi, molti tutt’ora non riescono a trovare applicazione pratica nel mio attuale impiego. Anche cose che però oggi non vengono impiegate a livello pratico possono essere oggetto di valutazione perché un cliente potrebbe esprimere determinate esigenze e allora è meglio avere gia una conoscenza per poter dare una consulenza.

Per me studiare ha sempre significato anche provare, sbattere la testa su esempi concreti, questo quantomeno aiuta a memorizzare le cose, anche perché io confesso che leggendo un libro faccio molta fatica a memorizzare molti dettagli, al contrario di quello che mi accade facendo le prove direttamente su un database. Se vogliamo poi, uno dei due libri che ho acquistato tre anni fa è apparantemente molto completo ma contiene un sacco di piccoli errori che mi costringono a verificare sui manuali Oracle e fare le prove pratiche per vedere qual’è la situazione reale.

Quindi, nel mio caso vedo una scarsa utilità della certificazione come fine ma una grande utilità come mezzo per un aggiornamento serio delle mie competenze di amministratore di database Oracle.

Ritorno di fiamma

venerdì 13 aprile 2018 alle 13:20 | Pubblicato su Diario | 2 commenti

Ho iniziato a scrivere su questo blog  oltre 11 anni fa, facendo una piccola ricerca ho individuato il primo post scritto il 23 novembre 2006. C’è stato un periodo in cui il mio lavoro era dedicato prevalentemente alla gestione di database Oracle e in quel periodo ho imparato un sacco di cose. Per tenere traccia di ciò che imparavo ho scritto tanti post sul blog, dove poi c’è la possibilità di venire corretti e di scambiare opinioni tramite i commenti. A me è servito molto per dare un ordine alle cose nella mia mente e per fissarle e verificarle. Poi gli anni sono passati e le cose sono cambiate, il lavoro e cambiato, dandomi meno opportunità di approfondire nuove tematiche e nuove funzionalità e caratteristiche del mondo Oracle Database e dirottando il mio tempo su altre attività. Questo ha fatto si che anche la mia passione nel tempo si sia un po’ spenta. Anche la mia vita privata ha subito drastici cambiamenti e questo ha ridotto drasticamente il tempo libero che dedicavo agli approfondimenti e alla scrittura dei post che come ribadisco sono anche un modo per riordinare le idee. Nel tempo ho avuto però dei ritorni di fiamma più o meno forti.  Di fatto questi ritorni di fiamma non sono casuali, sono associati a periodi in cui sul lavoro riesco ad essere meno pressato su attività che non riguardano database o attività banali e quindi a dedicarmi ad aggiornarmi sulle novità o a cercare di recuperare argomenti su cui sono rimasto indietro. Ora sono in uno di quei periodi, da qualche giorno ho ripreso con un minimo di serietà a studiare sui libri per provare ad aggiornare la mia certificazione Oracle alla versione 12c. Sui due libri che uso annotai la data di quando iniziai a leggerli: 22/05/2015. Sono passati quasi tre anni, un tempo decisamente alto, definirei assurdo. Ricordo che prima di prenderli avevo il dubbio se puntare alla certificazione su Oracle 11g o passare direttamente alla 12c, dubbio che ora non può più sussistere visto che 11gR2 è sia ancora molto in uso almeno dai nostri clienti ma è decisamente obsoleta come versione. C’è di buono che almeno ho finito una prima lettura dei testi e quindi degli argomenti oggetto dell’esame 1Z0-060 per l'”upgrade” della certificazione. Quindi la mia speranza è di portare a termine questo obiettivo. Non tanto per la certificazione in se quanto per riportarmi in pari con le conoscenze sul database Oracle.

Constato che fuori il mondo dei blog su Oracle è sicuramente cambiato,  però alcuni esperti continuano a scrivere e condividere conoscenza, ad esempio Connor McDonald e Jonathan Lewis che nei miei feed sembrano essere, fra quelli storici, i più attivi. Ce n’è invece un’altro che con mio dispiacere qualche tempo fa a annunciato di volersi dedicare dopo tanti anni ad altre cose, Howard Rogers. Questo mi dispiace anche perché prossimamente anche il suo materiale non sarà più pubblicamente disponibile.

Stamattina ho letto un paio di interessanti post di Connor McDonald che fra l’altro sono anche datati ma comunque interessanti e questo mi ha un po’ eccitato e fatto riflettere. Per questo ho scritto questo post che di tecnico non ha nulla ma che spero stabilisca un nuovo punto di partenza per me.

Gestione audit su database Oracle – parte 2, 12c architettura multitenant

martedì 27 febbraio 2018 alle 27:34 | Pubblicato su Diario | Lascia un commento

Torno sull’argomento gia trattato in un paio di post precedenti per riportare alcuni dettagli emersi ricontrollando la configurazione sui database interni. In particolare nei miei vari tentativi ho un po’ pasticciato sui database versione 12.1 in modalità multitenant. Come ho scritto in chiusura del post precedente sull’argomento, occorre fare attenzione che sulla versione 12 a tutte le procedure del package PL/SQL DBMS_AUDIT_MGMT è stato aggiunto il parametro “CONTAINER” che ha come default il valore CONTAINER_CURRENT. Quello che ho combinato io è stato di invocare, collegandomi al container root la procedura DBMS_AUDIT_MGMT.INIT_CLEANUP senza specificare il parametro, cosa che quindi ha significato l’inizializzazione solo per il container corrente, però ho invocato la procedura di creazione del job di puliza, DBMS_AUDIT_MGMT.PURGE_JOB con il parametro container valorizzato a DBMS_AUDIT_MGMT.CONTAINER_ALL. In questo modo la creazione del job non da errore, però durante l’esecuzione del job di pulizia c’erano degli errori che venivano registrati sull’alert con il messaggio: “ORA-46273: DBMS_AUDIT_MGMT operation failed in one of the PDB”. Nel file di trace specifico del job c’era la spiagazione chiara con un messaggio come questo:

“KZAM_TRC:Exception encountered in “PDBXXXP1″
KZAM_TRC:Exception is ORA-46258, message is: ORA-46258: Cleanup not initialized for the audit trail”

Fin qui niente di che, il problema sta nel trovare il modo di rattoppare, infatti secondo me in questa versione di Oracle il package manca di una gestione seria degli errori, per cui, nella mia situazione descritta sopra, invocando nuovamente DBMS_AUDIT_MGMT.INIT_CLEANUP con parametro CONTAINER=>DBMS_AUDIT_MGMT.CONTAINER_ALL si ottiene l’errore “ORA-46273: DBMS_AUDIT_MGMT operation failed in one of the PDB”, invocando la procedura DBMS_AUDIT_MGMT.DEINIT_CLEANUP sempre con parametro CONTAINER=>DBMS_AUDIT_MGMT.CONTAINER_ALL  si ottiene un errore che dice che in uno dei PDB il “cleanup” non è inizializzato (vado a memoria in questo caso con il messaggio perché ora ho sistemato tutto e mi sono perso la console con il messaggio). Collegandosi sui singoli container ho trovato una situazione un po’ strana, risultava inizializzata la pulizia per gli audit su file (così per lo meno risultava con una chiamata alla funzione “DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED”) però se cercavo di deinizializzare questi specifici canali mi dava errore. Alla fine ho risolto invocando per ciascun PDB in sequenza le procedure DBMS_AUDIT_MGMT.DEINIT_CLEANUP e DBMS_AUDIT_MGMT.INIT_CLEANUP con parametro CONTAINER=>DBMS_AUDIT_MGMT.CONTAINER_CURRENT. A quel punto la situazione era pulita la configurazione per la pulizia degli audit su tutti i container ha funzionato senza problemi. La soluzione non era difficile ma ho dovuto trovarla per tentativi.

Oracle Database 18c

venerdì 23 febbraio 2018 alle 23:43 | Pubblicato su Diario | Lascia un commento

Ieri, andando a cercare una cosa sui manuali oracle mi sono accorto di una novità, fra le versioni compariva un “Oracle Database 18c”, cosa che mi ha un po’ impressionato. Sono andato allora alla pagina principale del sito Oracle e quindi a questo annuncio che ho letto molto frettolosamente. Chiaramente il “18” è riferito all’anno e come spiega il comunicato il salto di nome nella versione è più legato alla politica di rilascio di nuove versioni che sarà d’ora in avanti annuale, con aggiornamenti trimestrali. Il comunicato spiega che di fatto, tecnicamente questa versione può essere vista come un aggiornamento della versione 12cR2. I tre pilastri su cui sembra voglia concentrarsi Oracle sono “in-memory”, che non ho mai visto; poi c’è l’architettura multitenant che sta progredendo e infine un’altra cosa per me lo “sharding” che dovrebbe essere una architettuttura di database distribuito. Prima ho dato un’occhiata e nelle mie fonti non ho trovato nessun annuncio, o le mie fonti sono vecchie ed abbandonate oppure effettivamente la novità è solo nel nome e poco nei contenuti per cui poco interessante.

Gestione Audit su database Oracle

giovedì 1 febbraio 2018 alle 01:05 | Pubblicato su 11g, 12c, Diario, Installation and Configuration | Lascia un commento
Tag:

Il titolo del post è pretenzioso e di fatto non rispecchia il vero contenuto in quanto coprire l’argomento “Audit” in Oracle è una cosa abbastanza difficile per la sua complessità. Il manuale “Security Guide” della versione 12.1 copre l’argomento con tre capitoli. Vi sono poi un po’ di novità sulla versione 12.1 rispetto alla 11.2. E’ un argomento su cui faccio fatica a raccapezzarmi, quindi provo ad affrontarlo per gradi.

Il post precedente è un esempio di quanto faccia fatica a dedicarmi all’approfondimento di nuovi (per me) temi. Cerco di rimediare alla confusione di quel post con un post più specifico e spero più ordinato e preciso in cui parlo esclusivamente della gestione della pulizia degli “audit” generati da Oracle.

Comincio con una informazione certificata dal supporto Oracle con la nota 308066.1 la quale spiega che anche con i parametri audit_trail=NONE e audit_sys_operations=FALSE vengono generati sotto il percorso indicato dal parametro audit_file_dest dei file .aud. In particolare vengono sempre e comunque generati dei file in cui si registrano le connessioni con utenti SYSDBA o SYSOPER e le operazioni di avvio e arresto dell’istanza. Questo vale sia per Oracle 11.2 che 12.1

Ora, i file sono piccoli ma possono diventare numerosi, nel mio caso ci sono procedure che si collegano con utenze privilegiate per fare dei controlli automatici e quindi vengono generati centinaia di file al giorno. Dopo qualche mese i file diventano migliaia. Da notare che se il filesystem si riempie non si riesce neppure ad accedere al database con l’utenza SYSDBA perché il sistema si lamenta di non riuscire a scrivere il file di audit. Ora, per gestire tutti i tipi di Audit Oracle mette a disposizione un package PL/SQL che si chiama DBMS_AUDIT_MGMT. I tipi di Audit che Oracle gestisce sono diversi, con la versione 12 è stato introdotto lo UNIFIED Audit Trail per mettere in un unico posto tutte le informazioni ma per retrocompatibilità esistono i tipi presenti nella versione precedente e questi sono:

  • File xml (AUDIT_TRAIL_XML)
  • File normali (AUDIT_TRAIL_OS
  • Record standard sulla tabella SYS.AUD$
  • record di Fine Grained Audit (FGA) sulla tabella SYS.FGA_LOG$)
  • Per la 12 record sulla vista UNIFIED_AUDIT_TRAIL

Ora per ciascuno di questi “canali” di audit c’è una costante nel package DBMS_AUDIT_MGMT.

Se ci si vuole limitare alla pulizia dei file .aud senza alcun criterio particolare il modo più semplice è l’uso della procedura DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL in questo modo:

BEGIN
 DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
 USE_LAST_ARCH_TIMESTAMP => FALSE );
END;
/

Con l’aiuto della procedura DBMS_AUDIT_MGMT.CREATE_PURGE_JOB si può pianificare una pulizia automatica periodica, ad esempio:

begin
 DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, 
 AUDIT_TRAIL_PURGE_INTERVAL => 24,
 AUDIT_TRAIL_PURGE_NAME => 'OS_Audit_Trail_PJ',
 USE_LAST_ARCH_TIMESTAMP => FALSE );
END;
/

Con gli esempi sopra vengono eliminati solo gli audit su file, se si vuole eliminare tutto, quindi ad esempio anche il contenuto della tabella AUD$ occorre fare un passo preliminare di inizializzazione. Occorre utilizzare la procedura DBMS_AUDIT_MGMT.INIT_CLEANUP che stando alla documentazione semplicemente sposta le tabelle dalla tablespace SYSTEM a SYSAUX, cosa che forse è sempre e comunque utile (al punto da chiedersi perché Oracle non le metta direttamente li in automatico. Infatti con lo unified audit trail è così). Quindi, ad esempio:

BEGIN
 DBMS_AUDIT_MGMT.INIT_CLEANUP(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 DEFAULT_CLEANUP_INTERVAL => 12 );
END;
/

La nota del supporto Oracle 1243324.1 riferendosi a Oracle 10.2.0.5 riferisce che il parametro DEFAULT_CLEANUP_INTERVAL è di fatto inusato, non mi è chiaro se cambia qualcosa sulle versioni 11 e 12.  Di sicuro l’intervallo da indicare sulla procedura CREATE_PURGE_JOB è obbligatorio e quello viene usato.

begin
 DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL, 
 AUDIT_TRAIL_PURGE_INTERVAL => 24,
 AUDIT_TRAIL_PURGE_NAME => 'ALL_Audit_Trail_PJ',
 USE_LAST_ARCH_TIMESTAMP => FALSE );
END;
/

 

Su Oracle 12 le procedure hanno dei parametri in più per gestire l’architettura multitenant, quindi nel mio caso alla procedura CREATE_PURGE_JOB ho aggiunto il parametro:

 container=>DBMS_AUDIT_MGMT.CONTAINER_ALL

Il default del parametro “container” è CONTAINER_CURRENT.

Combinando in maniera saggia i parametri o usando il parametro LAST_ARCHIVE_TIMESTAMP si possono organizzare politiche più elaborate; alla fine, capiti i concetti di base le cose sono abbastanza semplici e facili da capire

Manutenzione log e audit in Oracle

martedì 30 gennaio 2018 alle 30:35 | Pubblicato su 11g, 12c, Diario, Installation and Configuration | Lascia un commento
Tag:

Una cosa che non ho mai realmente approfondito, prima di adesso, era la manutenzione e pulizia dei vari file di log che un database server Oracle genera. In realtà, in condizioni normali, non c’è questo gran bisogno di fare manutenzione, per questo non me ne sono mai curato seriamente.  Ultimamente però mi è capitato spesso di dover fare pulizia in emergenza, in particolare ho avuto difficoltà con i file generati dal sistema di “Auditing” di Oracle. Il sistema di Auditing di Oracle fra l’altro è una cosa che nelle ultime versioni si è evoluto ed è abbastanza complesso.  Senza entrare quindi troppo nel dettaglio mi limito a dire che sembra che in qualunque condizione Oracle generi sempre e comunque un nuovo file .aud sotto $ORACLE_BASE/admin/<dbname>/adump ogni volta che avviene un accesso con una utenza SYSDBA. A causa di sistemi che fanno accessi automatici con questa utenza mi sono trovato quindi dopo un breve periodo di attività un numero esorbitante di file .aud. Il fatto è che oltre un certo numero anche rimuoverli con un semplice “rm” diventa difficile perché si ottiene un errore perché il sistema si lamenta che la lista dei file è troppo lunga…. Per un po’ ho sopperito come potevo manualmente, poi ho deciso di affrontare la questione in modo un po’ più  serio. Ho verificato quanto si riporta qui, ovvero che la generazione di questi file non può essere disattivata, infatti confermo che continua anche impostando il parametro AUDIT_TRAIL al valore “NONE”. Quello che è più importante secondo me di quel post è il primo commento, il quale riporta una procedura abbastanza semplice per gestire in modo automatico la pulizia di questi file direttamente da Oracle. Si tratta di usare il package PL/SQL DBMS_AUDIT_MGMT. Io al momento ho semplificato con queste tre chiamate:

BEGIN
 DBMS_AUDIT_MGMT.INIT_CLEANUP(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 DEFAULT_CLEANUP_INTERVAL => 1 );
END;
/
exec sys.dbms_audit_mgmt.set_last_archive_timestamp(audit_trail_type => sys.dbms_audit_mgmt.audit_trail_os,last_archive_time => sysdate - 3);
BEGIN
 DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL, 
 AUDIT_TRAIL_PURGE_INTERVAL => 1,
 AUDIT_TRAIL_PURGE_NAME => 'ALL_Audit_Trail_PJ',
 USE_LAST_ARCH_TIMESTAMP => TRUE );
END;
/

 

Di fatto viene schedulato un “job” di pulizia dei file di audit. Prima di poter creare il job vero e proprio occorre fare una inizializzazione. Secondo la documentazione uno dei passi dell’inizializzazione è spostare le tabelle su cui vengono registrati i dati di audit dalla tablespace SYSTEM a SYSAUX. In effetti ho avuto su un paio di database, durante la chiamata della procedura INIT_CLEANUP, errori di spazio sulla tablespace SYSAUX. La cosa bizzarra è che anche se la tablespace era in autoestensione la procedura mi dava errore comunque, l’unico modo quindi è allocare manualmente lo spazio espandendo il datafile.

La procedura CREATE_PURGE_JOB crea il “job” che si occuperà della pulizia dei file (e per come l’ho impostato io anche dei dati a db) più vecchi. Il punto è stabilire il periodo di ritenzione. Infatti la procedura di pulizia posso confermare gira appena si crea il job, poi dovrebbe girare secondo la schedulazione impostata, nel mio caso ogni ora (forse è un po’ esagerato ma sono ancora in fase sperimentale).  Senza la chiamata di SET_LAST_ARCHIVE_TIMESTAMP non si otterrà molto. Infatti il principio è che bisogna prima “archiviare” i file, quindi si dice a Oracle fino a che data e ora  i dati sono stati archiviati e così Oracle con il job schedulato li cancellerà….. ora il dubbio che mi è venuto scrivendo è che se non aggiorno almeno periodicamente il timestamp con la chiamata di quella procedura il job di cancellazione dopo la prima chiamata non cancellerà più nulla. Ipotizzo sia così ma mi riservo di verificare nei prossimi giorni. In ogni caso va detto che uno dei pregi di queste procedure è che sono molto rapide, nel mio caso con centinaia di migliaia di file l’operazione è stata molto più rapida che non a farla cancellando i file a mano.

Molto banalmente, leggendo la documentazione ho capito che, se non mi interessa un tubo degli audit, basta chiamare la procedura di creazione del job con il parametro USE_LAST_ARCH_TIMESTAMP  a false, secondo la documentazione il job in questo modo cancellerà tutto.

Un’altra parte importante di gestione log è la gestione del cosiddetto ADR, Automatic Diagnostic Repository, il posto dove Oracle scrive log e trace vari.  In questo caso Oracle prevede gia per default delle procedure di pulizia di questa area. Utilizzando l’utility ADRCI con il comando “show control” si possono estrapolare i due parametri SHORTP_POLICY e LONGP_POLICY che indicano il periodo di ritenzione in ora per rispettivamente per quelli che Oracle definisce file di “breve vita” e “lunga vita”. Per default i valori sono rispettivamente 30 giorni e 365 giorni. A parte l’inghippo derivante alla possibilità di avere più “homes” i valori si possono facilmente modificare con i comandi “set control” ad esempio nel mio caso:

set control (shortp_policy=100)
set control (longp_policy=300)

 

In automatico sembra che la pulizia giri o due giorni dopo l’avvio dell’istanza o ogni 7 giorni (note oracle 1196437.1 e 1446242.1). Per forzare una pulizia immediata basta il semplice comando “purge”

L’unico inghippo è il file alert in formato testo che si trova sotto la directory trace, quello non viene gestito da adrci, quindi va gestito a “mano”, si può fare tranquillamente a caldo facendo da sistema operativo un “mv”. (conferma qui)

Rileggendo velocemente il post, scritto abbastanza in fretta mi rendo conto sia un po’ confuso, come confusa è stata la mia ricerca a causa della scarsità di tempo a disposizione. Siccome però il tempo continuerà a scarseggiare per ora lo pubblico così e spero poi di poter fare qualche approfondimento.

« Pagina precedentePagina successiva »

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