Ecco la spec:

create or replace package mmp is
function goAlone return number;
end;
/

Molto semplice, la funzione goAlone avvia una nuova partita e la gioca, restituendo il numero di tentativi che sono stati necessari a trovare la soluzione.

Vediamo un esempio:

SQL> select mmp.goAlone from dual;

   GOALONE
----------
         6
#######################################
01 C6 C2 C1 C5:BW
#######################################
TRY AGAIN.
After this guess there are still 660 possible solutions
#######################################
01 C6 C2 C1 C5:BW
02 C3 C2 C8 C1:W
#######################################
TRY AGAIN.
After this guess there are still 147 possible solutions
#######################################
01 C6 C2 C1 C5:BW
02 C3 C2 C8 C1:W
03 C5 C1 C4 C5:BW
#######################################
TRY AGAIN.
After this guess there are still 23 possible solutions
#######################################
01 C6 C2 C1 C5:BW
02 C3 C2 C8 C1:W
03 C5 C1 C4 C5:BW
04 C4 C6 C3 C5:B
#######################################
TRY AGAIN.
After this guess there are still 6 possible solutions
#######################################
01 C6 C2 C1 C5:BW
02 C3 C2 C8 C1:W
03 C5 C1 C4 C5:BW
04 C4 C6 C3 C5:B
05 C7 C5 C2 C5:BBW
#######################################
TRY AGAIN.
After this guess there are still 1 possible solutions
#######################################
01 C6 C2 C1 C5:BW
02 C3 C2 C8 C1:W
03 C5 C1 C4 C5:BW
04 C4 C6 C3 C5:B
05 C7 C5 C2 C5:BBW
06 C2 C5 C5 C5:BBBB
#######################################
YOU GOT IT! WELL DONE!!!
C2 C5 C5 C5

Qualche dettaglio sull’algoritmo:
All’inizio il package memorizza in un array associativo tutte le 4096 possibili combinazioni in ordine casuale.

procedure fillSolTab is
begin

  if solTab.count > 0 then
     solTab.delete(solTab.first,solTab.last);
  end if;

  with t as (
    select mm.c1 col from dual union all
    select mm.c2 from dual union all
    select mm.c3 from dual union all
    select mm.c4 from dual union all
    select mm.c5 from dual union all
    select mm.c6 from dual union all
    select mm.c7 from dual union all
    select mm.c8 from dual)
  select t1.col, t2.col, t3.col, t4.col
    bulk collect into solTab
    from t t1, t t2, t t3, t t4
  order by dbms_random.value;

end;

Poi prende la prima e la prova.

function nextTry return number is
res mm.t_res;
sol t_sol := solTab(solTab.first);
begin
  res := mm.tryThis(sol.s1,sol.s2,sol.s3,sol.s4);

  if res.game_over = 0 then
     cleanSolTab(res.r1||res.r2||res.r3||res.r4);
  end if;

  return res.game_over;
end;

Ovviamente ottiene dal package mm un feedback che viene utilizzato per eliminare dalla tabella di tutte le combinazioni quelle che non possono essere più valide.

procedure cleanSolTab(p_res in varchar2) is
i number;
currSol t_sol;
markForDelete number;
begin
  i := solTab.first;
  currSol := solTab(i);
  solTab.delete(i);
  i := solTab.first;
  loop
    if nvl(checkSol(solTab(i),currSol),'x') != nvl(p_res,'x') then
       markForDelete := i;
    else
       markForDelete := 0;
    end if;
    exit when i=solTab.last;
    i := solTab.next(i);
    if markForDelete>0 then
       solTab.delete(markForDelete);
    end if;
  end loop;

  if markForDelete>0 then
     solTab.delete(markForDelete);
  end if;

  dbms_output.put_line('After this guess there are still '||solTab.count||' possible solutions');
end;

Dopodiché continua a provare in questo modo finché non trova la combinazione giusta.

function goAlone return number is
num number:=0;
begin
  startGame;
  loop
    num := num+1;
  exit when nextTry != 0;
  end loop;

  return num;

end;

Se si gioca un numero molto alto di partite (non vi dimenticate di spegnere il serverout!!) si vede che il mio metodo ottiene la soluzione con un numero medio di circa 5,5 tentativi:

SQL> select min(g), max(g), avg(g), stddev(g)
  2  from (select mmp.goalone g from dual connect by level<=100);

    MIN(G)     MAX(G)     AVG(G)  STDDEV(G)
---------- ---------- ---------- ----------
         3          8       5.47 .968754277

Se qualcuno trova un algoritmo che consente di ottenere una media più bassa mi faccia sapere…

Massimo

La notte scorsa, turbato dai primi caldi estivi, ho scritto un package pl/sql che mi consente di giocare a MAster Mind contro il mio database Oracle.

Il package mm include tutte le funzionalità per generare una chiave composta di quattro colori (su otto) e dare il feedback sui tentativi del giocatore.

Ecco la spec del package:

create or replace package mm is

c1 constant char(2) := 'C1';
c2 constant char(2) := 'C2';
c3 constant char(2) := 'C3';
c4 constant char(2) := 'C4';
c5 constant char(2) := 'C5';
c6 constant char(2) := 'C6';
c7 constant char(2) := 'C7';
c8 constant char(2) := 'C8';

type t_res is record (r1 char(1), r2 char(1), r3 char(1), r4 char(1), game_over number(1));

procedure startGame(p_maxAttempts in number default 12);

procedure tryThis(s1 in char, s2 in char, s3 in char, s4 in char);

function tryThis(p_s1 in char, p_s2 in char, p_s3 in char, p_s4 in char) return t_res;

end;
/

Gli otto colori si chiamano c1, c2…c8.
La procedura startGame avvia la partita selezionando la combinazione in maniera casuale. Il giocatore può indicare il numero massimo di tentativi che devono essere consentiti (il default è 12).
La procedura tryThis si utilizza per fare un tentativo con una combinazione, l’esito del tentativo è stampato a video con DBMS_OUTPUT.

Vediamo un esempio:

SQL> set feed off
SQL> set serverout on
SQL> exec mm.startGame
SQL> exec mm.tryThis(mm.c1,mm.c2,mm.c3,mm.c4)
#######################################
01 C1 C2 C3 C4:W
#######################################
TRY AGAIN.

Ogni volta che chiamo tryThis vedo tutti i tentativi precedenti ed i relativi feedback (una lettera B per ogni colore esatto nel posto esatto, una lettera W per ogni colore esatto ma nel posto sbagliato).

In questo caso ho beccato la soluzione con sei tentativi:

SQL> exec mm.tryThis(mm.c5,mm.c6,mm.c7,mm.c8)
#######################################
01 C1 C2 C3 C4:W
02 C5 C6 C7 C8:BW
#######################################
TRY AGAIN.
SQL> exec mm.tryThis(mm.c5,mm.c7,mm.c1,mm.c1)
#######################################
01 C1 C2 C3 C4:W
02 C5 C6 C7 C8:BW
03 C5 C7 C1 C1:W
#######################################
TRY AGAIN.
SQL> exec mm.tryThis(mm.c2,mm.c6,mm.c2,mm.c7)
#######################################
01 C1 C2 C3 C4:W
02 C5 C6 C7 C8:BW
03 C5 C7 C1 C1:W
04 C2 C6 C2 C7:WW
#######################################
TRY AGAIN.
SQL> exec mm.tryThis(mm.c3,mm.c3,mm.c7,mm.c6)
#######################################
01 C1 C2 C3 C4:W
02 C5 C6 C7 C8:BW
03 C5 C7 C1 C1:W
04 C2 C6 C2 C7:WW
05 C3 C3 C7 C6:BBWW
#######################################
TRY AGAIN.
SQL> exec mm.tryThis(mm.c6,mm.c3,mm.c7,mm.c3)
#######################################
01 C1 C2 C3 C4:W
02 C5 C6 C7 C8:BW
03 C5 C7 C1 C1:W
04 C2 C6 C2 C7:WW
05 C3 C3 C7 C6:BBWW
06 C6 C3 C7 C3:BBBB
#######################################
YOU GOT IT! WELL DONE!!!
C6 C3 C7 C3
SQL>

Il codice completo del package può essere scaricato qui, è un file di testo, anche se l’estensione è .doc.

Il continuo nell’articolo successivo.

Massimo

Massimo

DBMS_PROFILER scrive i risultati del profiling in tabelle di database che devono essere create lanciando lo script proftab.sql (si trova nella directory RDBMS/ADMIN sotto la Oracle Home del server).
Una volta lanciato lo script saranno presenti nel DB le seguenti tre tabelle:

Sessioni di profiling attivate:

SQL> desc plsql_profiler_runs
 Name                    Null?    Type
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 RELATED_RUN                      NUMBER
 RUN_OWNER                        VARCHAR2(32)
 RUN_DATE                         DATE
 RUN_COMMENT                      VARCHAR2(2047)
 RUN_TOTAL_TIME                   NUMBER
 RUN_SYSTEM_INFO                  VARCHAR2(2047)
 RUN_COMMENT1                     VARCHAR2(2047)
 SPARE1                           VARCHAR2(256)

Unità di codice controllate:

SQL> desc plsql_profiler_units
 Name                    Null?    Type
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 UNIT_NUMBER             NOT NULL NUMBER
 UNIT_TYPE                        VARCHAR2(32)
 UNIT_OWNER                       VARCHAR2(32)
 UNIT_NAME                        VARCHAR2(32)
 UNIT_TIMESTAMP                   DATE
 TOTAL_TIME              NOT NULL NUMBER
 SPARE1                           NUMBER
 SPARE2                           NUMBER

Tempi di esecuzione per i singoli elementi delle unità di codice:

SQL> desc plsql_profiler_data
 Name                    Null?    Type
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 UNIT_NUMBER             NOT NULL NUMBER
 LINE#                   NOT NULL NUMBER
 TOTAL_OCCUR                      NUMBER
 TOTAL_TIME                       NUMBER
 MIN_TIME                         NUMBER
 MAX_TIME                         NUMBER
 SPARE1                           NUMBER
 SPARE2                           NUMBER
 SPARE3                           NUMBER
 SPARE4                           NUMBER

Si tenga presente che i campi SPARE non sono utilizzati quindi saranno omessi anche nelle query che seguono.

Prima di tutto attiviamo una sessione di profiling. Per fare questo esistono due funzioni e due prcedure del package che rispondono tutte al nome di START_PROFILER.

FUNCTION START_PROFILER RETURNS BINARY_INTEGER
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 RUN_COMMENT                    VARCHAR2                IN     DEFAULT
 RUN_COMMENT1                   VARCHAR2                IN     DEFAULT
 RUN_NUMBER                     BINARY_INTEGER          OUT
PROCEDURE START_PROFILER
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 RUN_COMMENT                    VARCHAR2                IN     DEFAULT
 RUN_COMMENT1                   VARCHAR2                IN     DEFAULT
 RUN_NUMBER                     BINARY_INTEGER          OUT
FUNCTION START_PROFILER RETURNS BINARY_INTEGER
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 RUN_COMMENT                    VARCHAR2                IN     DEFAULT
 RUN_COMMENT1                   VARCHAR2                IN     DEFAULT
PROCEDURE START_PROFILER
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 RUN_COMMENT                    VARCHAR2                IN     DEFAULT
 RUN_COMMENT1                   VARCHAR2                IN     DEFAULT

Come si vede i vari metodi sono più o meno equivalenti e consentono di passare un paio di commenti in input tornando l’identificativo della sessione di profiling.
Attiviamo la sessione usando una funzione:

SQL> select dbms_profiler.start_profiler from dual;

START_PROFILER
--------------
             0

E poi lanciamo la procedura P1 definita per l’articolo precedente:

SQL> exec p1

PL/SQL procedure successfully completed.

Per arrestare definitivamente la sessione di profiling possiamo usare:

SQL> exec DBMS_PROFILER.STOP_PROFILER

PL/SQL procedure successfully completed.

Mentre se avessimo voluto interromperla solo momentaneamente avremmo usato:

SQL> exec DBMS_PROFILER.PAUSE_PROFILER

PL/SQL procedure successfully completed.

Ed in seguito avremmo potuto riprenderla con:

SQL> exec DBMS_PROFILER.RESUME_PROFILER

PL/SQL procedure successfully completed.

In ogni caso, giunti al termine dell’attività di raccolta dei dati, per scaricarli in tabella dobbiamo usare:

SQL>  exec DBMS_PROFILER.FLUSH_DATA

PL/SQL procedure successfully completed.

Vediamo adesso cosa abbiamo raccolto.
Nella tabella delle sessioni di profiling abbiamo ovviamente un solo record:

SQL> select RUNID, RUN_OWNER, RUN_DATE, RUN_TOTAL_TIME
  2  from plsql_profiler_runs;

     RUNID RUN_OWNER                        RUN_DATE  RUN_TOTAL_TIME
---------- -------------------------------- --------- --------------
         1 MAXR                             03-APR-10     1.4904E+13

Dove RUN_TOTAL_TIME e tutti i tempi delle tabelle seguenti sono espressi in nanosecondi.

Ci sono anche le unità di codice esaminate:

SQL> select RUNID, UNIT_NUMBER, UNIT_TYPE, UNIT_OWNER, UNIT_NAME
  2  from plsql_profiler_units;

     RUNID UNIT_NUMBER UNIT_TYPE                        UNIT_OWNER                       UNIT_NAME
---------- ----------- -------------------------------- -------------------------------- ------------------
         1           1 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>
         1           2 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>
         1           3 PROCEDURE                        MAXR                             P1
         1           4 FUNCTION                         MAXR                             F1
         1           5 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>
         1           6 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>
         1           7 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>
         1           8 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>
         1           9 ANONYMOUS BLOCK                  <anonymous>                      <anonymous>

9 rows selected.

E le singole linee eseguite delle unità di codice suddette:

SQL> select RUNID, UNIT_NUMBER, LINE#, TOTAL_OCCUR, TOTAL_TIME, MIN_TIME, MAX_TIME
  2  from plsql_profiler_data;

     RUNID UNIT_NUMBER      LINE# TOTAL_OCCUR TOTAL_TIME   MIN_TIME   MAX_TIME
---------- ----------- ---------- ----------- ---------- ---------- ----------
         1           1          1           2   50444120    3074971   21215545
         1           2          1           3   14592916     633600   10932115
         1           3          1           0    1302400    1302400    1302400
         1           3          4           1    5114057    5114057    5114057
         1           3          5           1     854857     854857     854857
         1           4          1           4    4837486     155885    1226971
         1           4          4           4 8847138952   41797491 8690106703
         1           4          5           3    3665829     125714    1840457
         1           4          7           1          0          0          0
         1           4          8           1    1272228    1272228    1272228
         1           4          9           4    2740571     251428    1322514
         1           5          1           2   81628810    5199543   37538290
         1           6          1           2   88246411    5576686   38242290
         1           7          1           2   86234982    5456000   37372347
         1           8          1           2   89101268    5637029   38383090
         1           9          1           2   18485030    1015771   15467887

16 rows selected.

In Oracle11g è stato aggiunto un nuovo package per il profiling, DBMS_HPROF.

Anche questo ha bisogno di sue tabelle che possono essere create lanciando lo script dbmshptab.sql. Eccole:

SQL> desc dbmshp_runs
 Name                    Null?    Type
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 RUN_TIMESTAMP                    TIMESTAMP(6)
 TOTAL_ELAPSED_TIME               NUMBER(38)
 RUN_COMMENT                      VARCHAR2(2047)

SQL> desc dbmshp_function_info
 Name                    Null?    Type
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 SYMBOLID                NOT NULL NUMBER
 OWNER                            VARCHAR2(32)
 MODULE                           VARCHAR2(32)
 TYPE                             VARCHAR2(32)
 FUNCTION                         VARCHAR2(4000)
 LINE#                            NUMBER
 HASH                             RAW(32)
 NAMESPACE                        VARCHAR2(32)
 SUBTREE_ELAPSED_TIME             NUMBER(38)
 FUNCTION_ELAPSED_TIME            NUMBER(38)
 CALLS                            NUMBER(38)

SQL> desc dbmshp_parent_child_info
 Name                    Null?    Type
 ----------------------- -------- ----------------
 RUNID                            NUMBER
 PARENTSYMID                      NUMBER
 CHILDSYMID                       NUMBER
 SUBTREE_ELAPSED_TIME             NUMBER(38)
 FUNCTION_ELAPSED_TIME            NUMBER(38)
 CALLS                            NUMBER(38)

Ricalcano più o meno quelle viste prima.
La sessione di profiling si avvia così:

SQL> exec DBMS_HPROF.START_PROFILING('TEST_DIR','profile_test.txt')

PL/SQL procedure successfully completed.

Assegnando una directory ed un file in cui scrivere i dati raccolti.

Poi si esegue il pl/sql che ci interessa:

SQL> exec p1

PL/SQL procedure successfully completed.

E si chiude la sessione in questo modo:

SQL> exec DBMS_HPROF.STOP_PROFILING

PL/SQL procedure successfully completed.

Per scrivere i dati in una forma leggibile nelle tabelle di DB, si usa la seguente funzione:

SQL> var id number;
SQL> exec :id := DBMS_HPROF.ANALYZE('TEST_DIR','profile_test.txt');

PL/SQL procedure successfully completed.

Che ritorna l’id della sessione di profiling.

Ecco infine i dati raccolti.

Sessioni di profiling:

SQL> select RUNID, RUN_TIMESTAMP, TOTAL_ELAPSED_TIME
  2* from dbmshp_runs

     RUNID RUN_TIMESTAMP             TOTAL_ELAPSED_TIME
---------- ------------------------- ------------------
         1 03-APR-10 01:11:01.296000              18620

Blocchi di codice analizzati:

SQL> select RUNID, SYMBOLID, OWNER, MODULE, TYPE,
  2  FUNCTION, LINE#, SUBTREE_ELAPSED_TIME, FUNCTION_ELAPSED_TIME, CALLS
  3* from dbmshp_function_info

 RUNID   SYMBOLID OWNER MODULE      TYPE         FUNCTION                 LINE# SUBTREE_ELAPSED_TIME FUNCTION_ELAPSED_TIME CALLS
------ ---------- ----- ----------- ------------ ----------------------- ------ -------------------- --------------------- -----
     1          1                                __anonymous_block            0                18564                   420     4
     1          2                                __plsql_vm                   0                18620                    56     4
     1          3 MAXR  F1          FUNCTION     F1                           1                18020                    84     1
     1          4 MAXR  F1          FUNCTION     F1@1                         1                17702                    24     1
     1          5 MAXR  F1          FUNCTION     F1@2                         1                17590                    22     1
     1          6 MAXR  F1          FUNCTION     F1@3                         1                17484                    77     1
     1          7 MAXR  P1          PROCEDURE    P1                           1                18043                    23     1
     1          8 SYS   DBMS_HPROF  PACKAGE BODY STOP_PROFILING              53                    0                     0     1
     1          9 SYS   DBMS_OUTPUT PACKAGE BODY GET_LINE                   129                   13                    13     2
     1         10 SYS   DBMS_OUTPUT PACKAGE BODY GET_LINES                  180                  101                    88     2
     1         11 MAXR  F1          FUNCTION     __static_sql_exec_line4      4                17813                 17813     4

11 rows selected.

E singole chiamate (PARENTSYMID è il codice del chiamante, CHILDSYMID è il codice del chiamato). I tempi qui sono tutti in microsecondi.

SQL> select * from dbmshp_parent_child_info;

 RUNID PARENTSYMID CHILDSYMID SUBTREE_ELAPSED_TIME FUNCTION_ELAPSED_TIME      CALLS
------ ----------- ---------- -------------------- --------------------- ----------
     1           1          7                18043                    23          1
     1           1         10                  101                    88          2
     1           1          8                    0                     0          1
     1           2          1                18564                   420          4
     1           3          4                17702                    24          1
     1           3         11                  234                   234          1
     1           4          5                17590                    22          1
     1           4         11                   88                    88          1
     1           5          6                17484                    77          1
     1           5         11                   84                    84          1
     1           6         11                17407                 17407          1
     1           7          3                18020                    84          1
     1          10          9                   13                    13          2

13 rows selected.

Abbiamo visto come tenere sotto osservazione i tempi d’esecuzione dei singoli step all’interno dei nostri programmi pl/sql.
Queste funzionalità ci consentono di individuare gli eventuali colli di bottiglia da rimuovere.

Alla prossima,
Massimo

Il package offre le seguenti funzionalità:

CLEAR_PLSQL_TRACE
Procedura che consente di stoppare una sessione di tracing

GET_PLSQL_TRACE_LEVEL
Funzione che restituisce il livello di tracing corrente

PLSQL_TRACE_VERSION
Procedura che restituisce la versione del package DBMS_TRACE

SET_PLSQL_TRACE
Procedura che avvia una sessione di tracing impostando il livello di tracing.

Per fare un semplice test creiamo una semplice funzione ricorsiva ed una procedura che la chiama:

SQL> create or replace function f1(p number) return number is
  2  a number;
  3  begin
  4    select 1/p into a from dual;
  5    return f1(p-1);
  6  exception
  7    when others then
  8       return 0;
  9  end;
 10  /

Function created.

SQL> create or replace procedure p1 is
  2  a number;
  3  begin
  4    a := f1(3);
  5  end;
  6  /

Procedure created.

La funzione richiama se stessa decrementando il parametro in input finché otterrà un errore (divisione per zero) gestito ritornando zero (e dunque fermando il ciclo).
La procedura innesca la funzione passando il valore 3 come parametro.

Innanzi tutto dobbiamo dire che il package DBMS_TRACE scrive in un paio di tabelle del database che devono essere create lanciando (da SYS) lo script tracetab.sql che si trova nella directory RDBMS/ADMIN sotto la Oracle Home del server.

Una volta lanciato lo script e create le tabelle

SQL> desc sys.plsql_trace_runs
 Nome                    Nullo?   Tipo
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 RUN_DATE                         DATE
 RUN_OWNER                        VARCHAR2(31)
 RUN_COMMENT                      VARCHAR2(2047)
 RUN_COMMENT1                     VARCHAR2(2047)
 RUN_END                          DATE
 RUN_FLAGS                        VARCHAR2(2047)
 RELATED_RUN                      NUMBER
 RUN_SYSTEM_INFO                  VARCHAR2(2047)
 SPARE1                           VARCHAR2(256)

SQL> desc sys.plsql_trace_events
 Nome                    Nullo?   Tipo
 ----------------------- -------- ----------------
 RUNID                   NOT NULL NUMBER
 EVENT_SEQ               NOT NULL NUMBER
 EVENT_TIME                       DATE
 RELATED_EVENT                    NUMBER
 EVENT_KIND                       NUMBER
 EVENT_UNIT_DBLINK                VARCHAR2(4000)
 EVENT_UNIT_OWNER                 VARCHAR2(31)
 EVENT_UNIT                       VARCHAR2(31)
 EVENT_UNIT_KIND                  VARCHAR2(31)
 EVENT_LINE                       NUMBER
 EVENT_PROC_NAME                  VARCHAR2(31)
 STACK_DEPTH                      NUMBER
 PROC_NAME                        VARCHAR2(31)
 PROC_DBLINK                      VARCHAR2(4000)
 PROC_OWNER                       VARCHAR2(31)
 PROC_UNIT                        VARCHAR2(31)
 PROC_UNIT_KIND                   VARCHAR2(31)
 PROC_LINE                        NUMBER
 PROC_PARAMS                      VARCHAR2(2047)
 ICD_INDEX                        NUMBER
 USER_EXCP                        NUMBER
 EXCP                             NUMBER
 EVENT_COMMENT                    VARCHAR2(2047)
 MODULE                           VARCHAR2(4000)
 ACTION                           VARCHAR2(4000)
 CLIENT_INFO                      VARCHAR2(4000)
 CLIENT_ID                        VARCHAR2(4000)
 ECID_ID                          VARCHAR2(4000)
 ECID_SEQ                         NUMBER
 CALLSTACK                        CLOB
 ERRORSTACK                       CLOB

Possiamo attivare la trace:

SQL> begin
  2  DBMS_TRACE.SET_PLSQL_TRACE (
  3      DBMS_TRACE.TRACE_ALL_CALLS+
  4      DBMS_TRACE.TRACE_ALL_EXCEPTIONS+
  5      DBMS_TRACE.TRACE_ALL_SQL);
  6  end;
  7  /

PL/SQL procedure successfully completed.

Nell’attivazione della trace dobbiamo impostare il livello di tracing, cioè definire quali eventi monitorare.
Ciò si fa sommando le costanti relative agli eventi che interessano, le costanti di maggiore interesse sono:

TRACE_ALL_CALLS             1
TRACE_ENABLED_CALLS         2
TRACE_ALL_EXCEPTIONS        4
TRACE_ENABLED_EXCEPTIONS    8
TRACE_LIMIT                 16
TRACE_ALL_SQL               32
TRACE_ENABLED_SQL           64
TRACE_ALL_LINES             128
TRACE_ENABLED_LINES         256
NO_TRACE_ADMINISTRATIVE     32768
NO_TRACE_HANDLED_EXCEPTIONS 65536

Ad ogni costante è associato come valore numerico una potenza di due e dunque è possibile scomporre ogni possibile livello di tracing nelle singole costanti che lo compogono.
Per ottenere il livello di tracing si può fare:

SQL> select dbms_trace.GET_PLSQL_TRACE_LEVEL from dual;

GET_PLSQL_TRACE_LEVEL
---------------------
                   37

Per ottenere invece la versione del package:

SQL> var v1 number;
SQL> var v2 number;
SQL> exec dbms_trace.PLSQL_TRACE_VERSION(:v1,:v2)

Procedura PL/SQL completata correttamente.

SQL> print v1

        V1
----------
         1

SQL> print v2

        V2
----------
         0

Tornando al nostro esempio, siamo pronti per eseguire p1 con la trace attiva:

SQL> exec p1

Procedura PL/SQL completata correttamente.

SQL> select runid, count(0) from sys.plsql_trace_events
  2  group by runid;

     RUNID   COUNT(0)
---------- ----------
         1          7
         2          7
         3         52
         4          7
         5         24

Come si vede ci sono vari runid in tabella dovuti a diverse prove che ho fatto. L’ultimo è quello che ci interessa.
La tabella plsql_trace_events contiene molte informazioni utili, per ragioni di formattazione della pagina io sono costretto a mostrarne solo poche:

SQL> select EVENT_SEQ, event_kind, event_unit, event_comment
  2  from sys.plsql_trace_events
  3  where runid=5;

 EVENT_SEQ EVENT_KIND EVENT_UNIT
---------- ---------- -------------------------------
EVENT_COMMENT
----------------------------------------------------------------------
         1         38
PL/SQL Trace Tool started

         2         40
Trace flags changed

         3         50 DBMS_TRACE
Return from procedure call

         4         50 DBMS_TRACE
Return from procedure call

         5         50 DBMS_TRACE
Return from procedure call

         6         44
PL/SQL Virtual Machine stopped

         7         43 <anonymous>
PL/SQL Virtual Machine started

         8         45 <anonymous>
Procedure Call

         9         45 P1
Procedure Call

        10         54 F1
SELECT 1/:B1 FROM DUAL

        11         45 F1
Procedure Call

        12         54 F1
SELECT 1/:B1 FROM DUAL

        13         45 F1
Procedure Call

        14         54 F1
SELECT 1/:B1 FROM DUAL

        15         45 F1
Procedure Call

        16         54 F1
SELECT 1/:B1 FROM DUAL

        17         52 F1
Exception raised

        18         53 F1
Exception handled

        19         50 F1
Return from procedure call

        20         50 F1
Return from procedure call

        21         50 F1
Return from procedure call

        22         50 F1
Return from procedure call

        23         50 P1
Return from procedure call

        24         44
PL/SQL Virtual Machine stopped


Selezionate 24 righe.

Come si vede ci sono alcuni eventi di sistema (la cui tracciatura può essere soppressa utilizzando la costante NO_TRACE_ADMINISTRATIVE) e molti eventi applicativi che avevo richiesto (le query eseguite, le eccezioni sollevate e gestite, le chiamate tra programmi).

Un altro utile campo è il CALLSTACK, valorizzato solo su alcuni eventi particolari:

SQL> select event_seq, CALLSTACK
  2  from sys.plsql_trace_events
  3  where runid=5;

 EVENT_SEQ CALLSTACK
---------- ----------------------------------------------------------
         1
         2 ----- PL/SQL Call Stack -----
             object      line  object
             handle    number  name
           1CDCDB88        21  package body SYS.DBMS_TRACE
           1CDCDB88        75  package body SYS.DBMS_TRACE
           1CDCDB88        80  package body SYS.DBMS_TRACE
           1CDCFD7C         2  anonymous block

         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17 ----- PL/SQL Call Stack -----
             object      line  object
             handle    number  name
           1CF6A894         4  function MAXR.F1
           1CF6A894         5  function MAXR.F1
           1CF6A894         5  function MAXR.F1
           1CF6A894         5  function MAXR.F1
           1CDB5A58         4  procedure MAXR.P1
           1CDC5888         1  anonymous block

        18 ----- PL/SQL Call Stack -----
             object      line  object
             handle    number  name
           1CF6A894         8  function MAXR.F1
           1CF6A894         5  function MAXR.F1
           1CF6A894         5  function MAXR.F1
           1CF6A894         5  function MAXR.F1
           1CDB5A58         4  procedure MAXR.P1
           1CDC5888         1  anonymous block

        19
        20
        21
        22
        23
        24

Selezionate 24 righe.

Che visualizza proprio la pila di chiamate tra programmi.

Una volta raccolte le informazioni necessarie ricordiamoci di disattivare la trace usando:

SQL> exec DBMS_TRACE.CLEAR_PLSQL_TRACE

Procedura PL/SQL completata correttamente.

Altrimenti la tabella degli eventi si riempe molto velocemente…

Alla prossima,
Massimo

Cominciamo dalla funzione XMLCAST, creata al fine di consentire il cast esplicito del contenuto di un nodo XML ad un tipo di dato scalare SQL.

Ipotizziamo ad esempio di avere il semplicissimo documento

SQL> select extract(xmltype('<a>2010-03-20</a>'),'//a') from dual;

EXTRACT(XMLTYPE('<A>2010-03-20</A>'),'//A')
--------------------------------------------------------------------------------------------------
<a>2010-03-20</a>

Contenente soltanto un elemento valorizzato con una data.

Per estrarre il contenuto dell’elemento a in forma di data facciamo:

SQL> select xmlcast(extract(xmltype('<a>2010-03-20</a>'),'//a') as date) from dual;

XMLCAST(E
---------
20-MAR-10

Dove il formato ottenuto è il default corrente (il valore del parametro NLS_DATE_FORMAT). Proviamo a cambiarlo per ottenere un formato diverso:

SQL> alter session set nls_date_format='dd/mm/yyyy hh24:mi:ss';

Session altered.

SQL> select xmlcast(extract(xmltype('<a>2010-03-20</a>'),'//a') as date) from dual;

XMLCAST(EXTRACT(XML
-------------------
20/03/2010 00:00:00

Ovviamente se avessimo effettuato il cast a VARCHAR2 anziché a data avremmo ottenuto:

SQL> select xmlcast(extract(xmltype('<a>2010-03-20</a>'),'//a') as varchar2(20)) from dual;

XMLCAST(EXTRACT(XMLT
--------------------
2010-03-20

Si noti che la funzione XMLCAST vuole in input un elemento XML, se forniamo invece un dato scalare otteniamo un errore:

SQL> select xmlcast('2010-03-20' as date) from dual;
select xmlcast('2010-03-20' as date) from dual
*
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected - got -

La funzione XMLEXISTS è una funzione booleana che indica se una query XQuery ritorna un risultato non nullo.
La possiamo considerare un’estensione di EXISTSNODE visto che quest’ultima prende in input una query XPath che è un sottoinsieme di XQuery.

Per fare un esempio utilizziamo il documento seguente:

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
----------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>
  </employee>
  <employee>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Presente nella tabella MYXML.
Una semplice query potrebbe essere:

SQL> select XMLQuery(
  2          'for $i in //employee
  3           where $i/SAL > 1000
  4           return $i/ENAME' passing x returning content) NAMES
  5    FROM myxml;

NAMES
--------------------------------------------------------------------
<ENAME>ALLEN</ENAME><ENAME>WARD</ENAME>

Che ritorna gli ENAME dei dipendenti che guadagnano più di 1000. Applicando XMLEXISTS:

SQL> select 1 from myxml
  2  where xmlexists(
  3   'for $i in //employee
  4    where $i/SAL > 1000
  5    return $i/ENAME' passing x);

         1
----------
         1

SQL> select 1 from myxml
  2  where xmlexists(
  3   'for $i in //employee
  4    where $i/SAL > 10000
  5    return $i/ENAME' passing x);

no rows selected

Se utilizziamo XMLEXISTS nella condizione di WHERE, oppure

SQL> select case when xmlexists(
  2   'for $i in //employee
  3    where $i/SAL > 1000
  4    return $i/ENAME' passing x) then 'TRUE' else 'FALSE' end "Exists?"
  5* from myxml

Exists?
--------------------
TRUE

SQL> select case when xmlexists(
  2   'for $i in //employee
  3    where $i/SAL > 10000
  4    return $i/ENAME' passing x) then 'TRUE' else 'FALSE' end "Exists?"
  5  from myxml;

Exists?
--------------------
FALSE

Se invece la mettiamo in una CASE.

Come detto XPath è un sottoinsieme di XQuery, quindi XMLEXISTS avrebbe accettato anche le seguenti:

SQL> select case when xmlexists('//ENAME[../SAL>1000]' passing x)
  2         then 'TRUE' else 'FALSE' end "Exists?"
  3  from myxml;

Exists?
--------------------
TRUE

SQL> select case when xmlexists('//ENAME[../SAL>10000]' passing x)
  2         then 'TRUE' else 'FALSE' end "Exists?"
  3  from myxml;

Exists?
--------------------
FALSE

La funzione XMLDIFF fornisce la differenza tra due documenti XML.
Per provarla partiamo da una versione leggermente modificata della tabella MYXML:

SQL> select xmlserialize(document x) x,
  2         xmlserialize(document y) y
  3  from myxml;

X                              Y
------------------------------ ------------------------------
<emps>                         <emps>
  <employee>                     <employee>
    <EMPNO>7369</EMPNO>            <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>           <ENAME>TOM</ENAME>
    <JOB>CLERK</JOB>               <JOB>CLERK</JOB>
    <SAL>800</SAL>                 <SAL>800</SAL>
  </employee>                    </employee>
  <employee>                     <employee>
    <EMPNO>7499</EMPNO>            <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>           <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>            <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>                <SAL>3000</SAL>
  </employee>                    </employee>
  <employee>                     <employee>
    <EMPNO>7521</EMPNO>            <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>            <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>            <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>                <SAL>1250</SAL>
  </employee>                    </employee>
</emps>                        </emps>

Come si vede i due documenti differiscono per due valori, un ENAME ed un SAL.

Eseguendo la XMLDIFF:

SQL> select xmldiff(x,y) differenze
  2  from myxml;

DIFFERENZE
---------------------------------------------------------
<xd:xdiff xsi:schemaLocation=
          "http://xmlns.oracle.com/xdb/xdiff.xsd 
           http://xmlns.oracle.com/xdb/xdiff.xsd" 
          xmlns:xd="http://xmlns.oracle.com/xdb/xdiff.xsd" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <?oracle-xmldiff operations-in-docorder="true" 
                   output-model="snapshot" 
                   diff-algorithm="global"?>
  <xd:update-node xd:node-type="text" 
                  xd:xpath="/emps[1]/employee[1]/ENAME[1]/text()[1]">
    <xd:content>TOM</xd:content>
  </xd:update-node>
  <xd:update-node xd:node-type="text" 
                  xd:xpath="/emps[1]/employee[2]/SAL[1]/text()[1]">
    <xd:content>3000</xd:content>
  </xd:update-node>
</xd:xdiff>

(Il risultato è stato formattato manulamente per una migliore visualizzazione nel blog…)

Si ottengono le differnze cercate. La funzione XMLDIFF è un’iterfaccia SQL verso l’API C XmlDiff

Esattamente allo stesso modo la funzione XMLPATCH è un’interfaccia SQL per l’API C XmlPatch.

Questa consente di modificare un documento XML applicando una “patch” espressa esattamente nel formato XDIFF che abbiamo visto come risultato della XMLDIFF.
Praticamente se applichiamo alla colonna X il risultato della XMLDIFF precedente mediante XMLPATCH otteniamo la colonna Y:

SQL> select xmlserialize(document XMLPATCH(X,XMLDIFF(X,Y)))
  2  from myxml;

XMLSERIALIZE(DOCUMENTXMLPATCH(X,XMLDIFF(X,Y)))
-------------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>TOM</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>3000</SAL>
  </employee>
  <employee>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Ricordate sempre che XMLSERIALIZE è lì solo per ottenere una visualizzazione più leggibile…

Questo è tutto per stasera.

Alla prossima,
Massimo

Come documento di partenza utilizzeremo il seguente xml presente nella tabella myxml:

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
-------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>
  </employee>
  <employee>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Cominciamo dalla funzione ultima arrivata, INSERTXMLAFTER.
Questa funzione, novità di Oracle 11gR1, serve ad aggiungere un frammento XML subito dopo un elemento del documento individuato mediante un’espressione XPATH.
Vediamo un esempio:

SQL> update myxml set
  2  x=INSERTXMLAFTER(x,
  3                    '//EMPNO[text()=7521]',
  4                    xmlelement("newel",'newval')
  5                   );

1 row updated.

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
--------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>
  </employee>
  <employee>
    <EMPNO>7521</EMPNO>
    <newel>newval</newel>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

INSERTXMLAFTER riceve in input il doc xml di partenza, l’espressione xpath che indica l’elemento dopo il quale bisogna inserire il nuovo elemento ed appunto il nuovo elemento.
In questo caso abbiamo deciso di inserire l’elemento <newel>newval</newel> subito dopo l’elemento EMPNO avente valore 7521.
Utilizzando la funzione INSERTXMLBEFORE avremmo potuto invece inserire il nuovo elemento subito prima del riferimento:

SQL> update myxml set
  2  x=INSERTXMLBEFORE(x,
  3                    '//EMPNO[text()=7521]',
  4                    xmlelement("newel",'newval')
  5                   );

1 row updated.

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
--------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>
  </employee>
  <employee>
    <newel>newval</newel>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Attenzione! sebbene INSERTXMLAFTER sia disponibile in teoria in tutte le versioni della 11gR1, in realtà a causa di un bug funziona solo a partire dalla versione 11.1.0.7.0

Simile, ma leggermente differente, è la funzione APPENDCHILDXML. Questa, infatti, inserisce il nuovo elemento come figlio (e dunque ad un livello inferiore nell’albero gerarchico) dell’elemento a cui punta l’espressione XPATH:

SQL> update myxml set
  2  x=appendchildxml(x,
  3                    '//EMPNO[text()=7521]',
  4                    xmlelement("newel",'newval')
  5                   );

1 row updated.

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
-----------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>
  </employee>
  <employee>
    <EMPNO>7521<newel>newval</newel>
    </EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Come si vede “newel” è finito dentro EMPNO, a pari livello con il contenuto testuale di quest’ultimo.

Si ottiene lo stesso risultato anche utilizzando INSERTCHILDXML, questa funzione, però, non garantisce la posizione dell’elemento inserito, ma solo che questo sarà figlio del riferimento dato.
APPENDCHILDXML, invece, garantisce che il nuovo elemento inserito sia proprio l’ultimo figlio del riferimento.

SQL> update myxml set
  2  x=insertchildxml(x,
  3                    '//EMPNO[text()=7521]',
  4                    'newel',
  5                    xmlelement("newel",'newval')
  6                   );

1 row updated.

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
---------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1600</SAL>
  </employee>
  <employee>
    <EMPNO>7521<newel>newval</newel>
    </EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Viste le funzioni per aggiungere frammenti XML passiamo a quelle che consentono di modificare ed eliminare gli elementi esistenti.

UPDATEXML riceve in input il documento di partenza ed un insieme di coppie (espressione XPATH, valore) che indicano le modifiche da apportare.
Se ad esempio vogliamo portare a 2000 lo stipendio di ALLEN e contestualmente cambiare il mestiere di WARD facciamo:

SQL> update myxml set
  2  x=updatexml(x,
  3              '//employee[EMPNO=7499]/SAL/text()',
  4              2000,
  5              '//employee[EMPNO=7521]/JOB/text()',
  6              'disoccupato'
  7             );

1 row updated.

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
-----------------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>2000</SAL>
  </employee>
  <employee>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>disoccupato</JOB>
    <SAL>1250</SAL>
  </employee>
</emps>

Per finire la funzione che consente di eliminare frammenti xml da un documento. Una volta che abbiamo dichiarato che WARD è disoccupato tanto vale eliminarlo del tutto dal documento:

SQL> update myxml set
  2  x=deletexml(x,
  3              '//employee[EMPNO=7521]'
  4             );

1 row updated.

SQL> select xmlserialize(document x) from myxml;

XMLSERIALIZE(DOCUMENTX)
--------------------------------------------------------
<emps>
  <employee>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <SAL>800</SAL>
  </employee>
  <employee>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <SAL>2000</SAL>
  </employee>
</emps>

La funzione riceve in input il documento di partenza ed un riferimento XPATH, eliminando l’elemento (o gli elementi) che si trova al riferimento.

Questo è tutto per gli aggiornamenti dei documenti XML, alla prossima
Massimo.

L’articolo sarà sempre disponibile in questo blog alla pagina Codd

Massimo

In questo articolo mi propongo di mostrare un’altra novità, la clausola UNPIVOT.

Della clausola PIVOT abbiamo detto che serve a trasformare record in colonne.

Ad esempio la somma degli stipendi per dipartimento (sulle colonne) e per impiego (sulle righe):

select job, sum(d10),sum(d20),sum(d30) from emp
pivot (sum(sal) for deptno 
         in (10 as D10, 20 as d20, 30 as d30))
group by job;


JOB         SUM(D10)   SUM(D20)   SUM(D30)
--------- ---------- ---------- ----------
SALESMAN                              5600
CLERK           1300       1900        950
PRESIDENT       5000
MANAGER         2450       2975       2850
ANALYST                    6000

La clausola UNPIVOT serve a fare esattamente il contrario, cioè a leggere in diversi record i dati che in partenza abbiamo su diverse colonne.

Ipotizziamo ad esempio di avere la tabella VENDITE:

SQL> select * from vendite;

    DEPTNO  ANNO_2008  ANNO_2009  ANNO_2010
---------- ---------- ---------- ----------
        10     350000     400000     500000
        20     185000     220000     330000
        30     400000     500000     600000

e di voler ottenere nove record, uno per ogni dipartimento e per ogni anno.

SQL> select *
  2  from vendite
  3  UNPIVOT
  4  (importo for anno in (
  5           anno_2008 as '2008',
  6           anno_2009 as '2009',
  7           anno_2010 as '2010')
  8  );

    DEPTNO ANNO    IMPORTO
---------- ---- ----------
        10 2008     350000
        10 2009     400000
        10 2010     500000
        20 2008     185000
        20 2009     220000
        20 2010     330000
        30 2008     400000
        30 2009     500000
        30 2010     600000

9 rows selected.

Guardiamo la clausola UNPIVOT. Ho chiesto un campo importo per anno indicando nella clausola IN come trascodificare l’header della colonna in un valore.
Facciamo una piccola modifica ai dati:

SQL> update vendite set anno_2010 = null where deptno=20;

1 row updated.

SQL> select * from vendite;

    DEPTNO  ANNO_2008  ANNO_2009  ANNO_2010
---------- ---------- ---------- ----------
        10     350000     400000     500000
        20     185000     220000
        30     400000     500000     600000

e ripetiamo la stessa query di prima:

SQL> select *
  2  from vendite
  3  UNPIVOT
  4  (importo for anno in (
  5           anno_2008 as 2008,
  6           anno_2009 as 2009,
  7           anno_2010 as 2010)
  8  );

    DEPTNO ANNO    IMPORTO
---------- ---- ----------
        10 2008     350000
        10 2009     400000
        10 2010     500000
        20 2008     185000
        20 2009     220000
        30 2008     400000
        30 2009     500000
        30 2010     600000

8 rows selected.

Le righe selezionate sono solo otto perché il valore nullo è stato ignorato.
Se vogliamo che i valori nulli siano invece presi in considerazione basta chiederlo con l’aggiunta dell’opzione “INCLUDE NULLS”:

SQL> select *
  2  from vendite
  3  UNPIVOT INCLUDE NULLS
  4  (importo for anno in (
  5           anno_2008 as 2008,
  6           anno_2009 as 2009,
  7           anno_2010 as 2010)
  8  );

    DEPTNO ANNO    IMPORTO
---------- ---- ----------
        10 2008     350000
        10 2009     400000
        10 2010     500000
        20 2008     185000
        20 2009     220000
        20 2010
        30 2008     400000
        30 2009     500000
        30 2010     600000

9 rows selected.

Ovviamente questi dati possono essere successivamente manipolati a piacere, ad esempio possiamo calcolare al volo la media annua delle vendite:

SQL> select deptno, min(anno), max(anno), avg(importo)
  2  from vendite
  3  UNPIVOT INCLUDE NULLS
  4  (importo for anno in (
  5           anno_2008 as 2008,
  6           anno_2009 as 2009,
  7           anno_2010 as 2010)
  8  )
  9  group by deptno;

    DEPTNO  MIN(ANNO)  MAX(ANNO) AVG(IMPORTO)
---------- ---------- ---------- ------------
        30       2008       2010       500000
        20       2008       2010       202500
        10       2008       2010   416666.667

Alla prossima,
Massimo

SQL> Analyze table EMP compute statistics;

Analizzata tabella.

Già in Oracle8, però, è stato introdotto il package DBMS_STATS che offre molte utili funzionalità per la raccolta e la gestione delle statistiche, in quest’articolo le vediamo velocemente.

Le funzioni presenti in DBMS_STATS consentono di

Raccogliere Statistiche

Le seguenti procedure consentono di raccogliere statistiche:

GATHER_DATABASE_STATS
GATHER_DICTIONARY_STATS
GATHER_FIXED_OBJECTS_STATS
GATHER_INDEX_STATS
GATHER_SCHEMA_STATS
GATHER_SYSTEM_STATS
GATHER_TABLE_STATS

Si passa dalla raccolta delle statistiche per l’intero DB a quelle per il singolo indice o tabella.
Tutte le procedure raccolgono statistiche relative agli oggetti di DB ad eccezione della GATHER_SYSTEM_STATS che raccoglie statistiche sulle capacità dell’hardware del sistema (CPU e dischi).
Le statistiche possono essere scritte nel dizionario dati (ed utilizzate dall’ottimizzatore), oppure in una tabella appositamente creata, vedremo come più avanti.

Gestire Statistiche

Le procedure seguenti:

PREPARE_COLUMN_VALUES
PREPARE_COLUMN_VALUES_NVARCHAR2
PREPARE_COLUMN_VALUES_ROWID
SET_COLUMN_STATS
SET_INDEX_STATS
SET_SYSTEM_STATS
SET_TABLE_STATS
GET_COLUMN_STATS
GET_INDEX_STATS
GET_SYSTEM_STATS
GET_TABLE_STATS

Consentono di gestire le statistiche settando o leggendo specifici valori con le procedure SET* e GET*.
Le procedure PREPARE* servono a convertire un insieme di valori di una colonna al formato interno oracle per poi settarli utilizzando SET_COLUMN_VALUE.

Cancellare Statistiche

Alcune procedure consentono la cancellazione delle statistiche:

DELETE_COLUMN_STATS
DELETE_DATABASE_STATS
DELETE_DICTIONARY_STATS
DELETE_FIXED_OBJECTS_STATS
DELETE_INDEX_STATS
DELETE_SCHEMA_STATS
DELETE_SYSTEM_STATS
DELETE_TABLE_STATS

Trasferimento di Statistiche

Come detto le statistiche possono essere registrate nel dizionario oppure in una tabella appositamente creata.
Le statistiche collezionate in tabella non vengono utilizzate dall’ottimizzatore.
Per creare una tabella adatta a tale scopo si può utilizzare la procedura

CREATE_STAT_TABLE

Che può essere poi eliminata mediante la procedura

DROP_STAT_TABLE

Ci sono poi alcune procedure che servono a spostare le statistiche dal dizionario alla tabella:

EXPORT_COLUMN_STATS
EXPORT_DATABASE_STATS
EXPORT_DICTIONARY_STATS
EXPORT_FIXED_OBJECTS_STATS
EXPORT_INDEX_STATS
EXPORT_SCHEMA_STATS
EXPORT_SYSTEM_STATS
EXPORT_TABLE_STATS

oppure dalla tabella al dizionario:

IMPORT_COLUMN_STATS
IMPORT_DATABASE_STATS
IMPORT_DICTIONARY_STATS
IMPORT_FIXED_OBJECTS_STATS
IMPORT_INDEX_STATS
IMPORT_SCHEMA_STATS
IMPORT_SYSTEM_STATS
IMPORT_TABLE_STATS

Bloccare e sbloccare Statistiche

Se vogliamo congelare le statistiche di un oggetto è possibile utilizzare le procedure
LOCK_SCHEMA_STATS
LOCK_TABLE_STATS

Il procedimento inverso può essere ottenuto mediante le procedure
UNLOCK_SCHEMA_STATS
UNLOCK_TABLE_STATS

Questa funzionalità è particolarmente utile quando si vuole che per una tabella non vengano più raccolte le statistiche.
E’ sufficiente infatti cancellare le statistiche e poi chiamare la procedura LOCK_SCHEMA_STATS:

SQL> BEGIN
  2  DBMS_STATS.DELETE_TABLE_STATS('MAXR','EMP');
  3  DBMS_STATS.LOCK_TABLE_STATS('MAXR','EMP');
  4  END;
  5  /

Procedura PL/SQL completata correttamente.

In questo modo le statistiche sono e resteranno nulle.

Ripristino e svecchiamento delle Statistiche

La procedura PURGE_STATS elimina tutte le statistiche cancellate prima di un certo timestamp fornito in input.

Se invece si vogliono ripristinare le statistiche come erano ad un certo timestamp si possono utilizzare le procedure:

RESTORE_DICTIONARY_STATS
RESTORE_FIXED_OBJECTS_STATS
RESTORE_SCHEMA_STATS
RESTORE_SYSTEM_STATS
RESTORE_TABLE_STATS

Pending Statistics

A volte può essere utile verificare l’impatto della raccolta delle statistiche sui piani d’esecuzione prima di renderle attive.
Per questo motivo esistono le “Pending Statistics”.
Per fare in modo che le statistiche raccolte siano considerate pending, e quindi momentaneamente non utilizzate dall’ottimizzatore, bisogna impostare a FALSE il parametro PUBLISH utilizzando una delle seguenti procedure:

SET_DATABASE_PREFS
SET_GLOBAL_PREFS
SET_SCHEMA_PREFS
SET_TABLE_PREFS

Ad esempio, per definire pending le statistiche sulla tabella EMP:

SQL> begin
  2  DBMS_STATS.SET_TABLE_PREFS ('MAXR', 'EMP', 'PUBLISH', 'FALSE');
  3  end;
  4  /

Procedura PL/SQL completata correttamente.

Una volta poi raccolte le statistiche e valutato l’impatto sui piani d’esecuzione si può decidere di cancellarle:
DELETE_PENDING_STATS

Esportarle in una tabella utente:
EXPORT_PENDING_STATS

Pubblicarle, cioè renderle valide ed utilizzabili dall’ottimizzatore:
PUBLISH_PENDING_STATS

Comparing Statistics

E’ possibile ottenere un report delle differenze tra due versioni delle statistiche mediante le funzioni
DIFF_TABLE_STATS_IN_HISTORY
DIFF_TABLE_STATS_IN_PENDING
DIFF_TABLE_STATS_IN_STATTAB

Si tratta di funzioni pipelined che possono essere utilizzate nella clausola FROM di una query.
Vediamo un esempio.

Innanzitutto creiamo una tabella di test:

SQL> create table testtab as select * from emp;

Tabella creata.

E’ identica alla EMP, anche come contenuto.
Raccogliamone le statistiche:

SQL> exec DBMS_STATS.GATHER_TABLE_STATS('MAXR','TESTTAB')

Procedura PL/SQL completata correttamente.

SQL> select systimestamp  from dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
28-FEB-10 21:44:41,859000 +01:00

Adesso inseriamo un po’ di record aggiuntivi:

SQL> insert into testtab
  2  select * from testtab;

Create 14 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 28 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 56 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 112 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 224 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 448 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 896 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 1792 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 3584 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 7168 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 14336 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 28672 righe.

SQL> r
  1  insert into testtab
  2* select * from testtab

Create 57344 righe.

SQL> commit;

Commit completato.

E raccogliamo di nuovo le statistiche:

SQL> exec DBMS_STATS.GATHER_TABLE_STATS('MAXR','TESTTAB');

Procedura PL/SQL completata correttamente.

A questo punto siamo pronti per vedere il report delle differenze:

SQL> set long 5000
SQL> select * from
  2* table(DBMS_STATS.DIFF_TABLE_STATS_IN_HISTORY(
           'MAXR',
           'TESTTAB',
           to_timestamp('20100228214442','yyyymmddhh24miss'),
           systimestamp,
           0)
           );

REPORT                                                                           MAXDIFFPCT
-------------------------------------------------------------------------------- ----------
###############################################################################      819100

STATISTICS DIFFERENCE REPORT FOR:
.................................

TABLE         : TESTTAB
OWNER         : MAXR
SOURCE A      : Statistics as of 28-FEB-10 21:44:42,000000 +01:00
SOURCE B      : Statistics as of 28-FEB-10 21:50:16,359000 +01:00
PCTTHRESHOLD  : 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

REPORT                                                                           MAXDIFFPCT
-------------------------------------------------------------------------------- ----------

TABLE / (SUB)PARTITION STATISTICS DIFFERENCE:
.............................................

OBJECTNAME                  TYP SRC ROWS       BLOCKS     ROWLEN     SAMPSIZE
...............................................................................

TESTTAB                     T   A   14         4          37         14
                                B   114688     751        37         114688
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


REPORT                                                                           MAXDIFFPCT
-------------------------------------------------------------------------------- ----------
COLUMN STATISTICS DIFFERENCE:
.............................

COLUMN_NAME     SRC NDV     DENSITY    HIST NULLS   LEN  MIN   MAX   SAMPSIZ
...............................................................................

COMM            A   4       ,25        NO   10      2    80    C20F  4
                B   4       ,25        NO   81920   2    80    C20F  32768
MGR             A   6       ,166666666 NO   1       4    C24C4 C2500 13
                B   6       ,166666666 NO   8192    4    C24C4 C2500 106496
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

REPORT                                                                           MAXDIFFPCT
-------------------------------------------------------------------------------- ----------


NO DIFFERENCE IN INDEX / (SUB)PARTITION STATISTICS
###############################################################################

Statistiche Estese

Il package DBMS_STATS ci dà anche la possibilità di calcolare statistiche su gruppi di colonne o espressioni. Queste vengono dette “Statistiche Estese”.
Le statistiche su gruppi di colonne sono utilizzare dall’ottimizzatore quando in una query ci sono condizioni su diverse colonne. Una eventuale correlazione tra le colonne (valutata appunto leggendo le statistiche estese) può far cambiare il piano d’esecuzione.

Per creare le statistiche estese utilizziamo la funzione
CREATE_EXTENDED_STATS

Per cancellarle:
DROP_EXTENDED_STATS

E per vedere i nomi delle estensioni la funzione:
SHOW_EXTENDED_STATS_NAME

Ad esempio per creare una statistica estesa sulla correlazione tra EMPNO ed ENAME facciamo:

SQL> exec dbms_output.put_line(DBMS_STATS.CREATE_EXTENDED_STATS('MAXR','TESTTAB','(EMPNO,ENAME)'))
SYS_STU7CJ_LJ#28ARDED17#AUWYJZ

Procedura PL/SQL completata correttamente.

Ho stampato il valore di ritorno che è il nome dell’estesione creata.

Se mi perdo questo nome posso ricavarlo mediante la funzione SHOW_EXTENDED_STATS_NAME:

SQL> select dbms_stats.SHOW_EXTENDED_STATS_NAME('MAXR','TESTTAB','(ENAME, EMPNO)')
  2  from dual;

DBMS_STATS.SHOW_EXTENDED_STATS_NAME('MAXR','TESTTAB','(ENAME,EMPNO)')
---------------------------------------------------------------------------------------
SYS_STU7CJ_LJ#28ARDED17#AUWYJZ

SQL> select dbms_stats.SHOW_EXTENDED_STATS_NAME('MAXR','TESTTAB','(DEPTNO, ENAME)')
  2  from dual;
select dbms_stats.SHOW_EXTENDED_STATS_NAME('MAXR','TESTTAB','(DEPTNO, ENAME)')
       *
ERRORE alla riga 1:
ORA-20000: extension "(DEPTNO, ENAME)" does not exist
ORA-06512: a "SYS.DBMS_STATS", line 25416

Che come si vede nell’ultimo esempio torna un errore se cerchiamo di leggere il nome di un’estensione che non è stata definita.

Un’altro tipo di estensione che si può creare è su un’espressione, ad esempio:

SQL>  exec dbms_output.put_line(DBMS_STATS.CREATE_EXTENDED_STATS('MAXR','TESTTAB','(TO_CHAR(EMPNO))'))
SYS_STUM9HJB83_TSA6P91FJMZ84U9

Procedura PL/SQL completata correttamente.

Questo è tutto per quanto riguarda il package DBMS_STATS.

Alla prossima,
Massimo