Capitolo 2. Modifiche all architettura di Oracle9i

Capitolo 2 Modifiche all architettura di Oracle9i 2.1 Modifiche alle tabelle organizzate a indice 2.2 Scansione a salto degli indici 2.3 Estrazione dei metadata degli oggetti 2.4 Operazioni sugli oggetti online 2.5 Gestione automatizzata dello spazio del segmento 2.6 Indici bitmap di join 2.7 Identificazione degli indici inutilizzati 2.8 Condivisione del cursore 2.9 Miglioramenti del server condiviso 2.10 Variazioni alle impostazioni predefinite di create tablespace 2.11 Sospensione del database In questo capitolo si passa dalle modifiche di amministrazione e gestione alle modifiche di architettura di Oracle9i, quindi dagli oggetti del database ai metodi utilizzati per gestire lo spazio interno di un oggetto; da Oracle8i sono infatti intercorse varie modifiche. Il Capitolo 2 descrive molti di questi argomenti e aiuta a sfruttare alcune nuove funzionalità di Oracle9i. 2.1 Modifiche alle tabelle organizzate a indice Oracle9i ha rafforzato le capacità delle tabelle organizzate a indice. In questa parte del capitolo si parlerà di alcune nuove opzioni introdotte da Oracle9i fra cui nuove opzioni di indicizzazione, di ricostruzione online degli indici secondari e il codice DML parallelo.

40 CAPITOLO 2 Opzioni di indicizzazione per le tabelle organizzate a indice Oracle8i ha introdotto il supporto degli indici secondari nelle tabelle organizzate a indice. Negli indici secondari di Oracle8i, una tabella organizzata a indice doveva avere indici B-tree. In Oracle9i, si possono creare anche indici bitmap su una tabella organizzata a indice. L aggiunta degli indici bitmap offre una maggiore flessibilità grazie alle seguenti funzionalità. Un indice bitmap è in genere più compatto rispetto un indice B-tree. L ottimizzatore ha più percorsi di accesso per la scelta del piano di esecuzione di una determinata query. Gli indici bitmap consentono di svolgere operazioni bit a bit estremamente veloci. Queste operazioni sono disponibili quando sono presenti due o più indici bitmap e una query prevede l utilizzo di operazioni AND o OR. Per creare un indice bitmap in una tabella organizzata a indice (IOT Index- Organized Table) occorre creare una tabella di mappaggio. Una tabella di mappaggio contiene il ROWID logico della tabella organizzata a indice associato a ogni bit dell indice bitmap. Pertanto la tabella di mappaggio traduce il bit dell indice bitmap in un ROWID della tabella organizzata a indice. Quando si crea una tabella organizzata a indice, occorre aggiungere al comando create table la causola mapping table. Ecco un esempio di creazione di una tabella organizzata a indice con una tabella di mappaggio e la creazione di un indice bitmap associato alla tabella organizzata a indice: CREATE TABLE state ( state_code VARCHAR2(2) PRIMARY KEY, state_name VARCHAR2(30), state_zip_prefix VARCHAR2(2) ) ORGANIZATION INDEX MAPPING TABLE TABLESPACE users; CREATE BITMAP INDEX bx_state_01 ON state (state_zip_prefix); Nel listato precedente, si è creata una tabella organizzata a indice chiamata STATE. Utilizzando la clausola mapping table è stata definita una tablespace di mappaggio per questa tabella organizzata a indice che fa in modo che Oracle crei un associazione fra ROWID logici e fisici che verrà memorizzata in una tabella a heap. Questo è necessario per consentire di creare l indice bitmap che si può vedere nell istruzione create bitmap index che segue la creazione della tabella organizzata a indice STATE. Si noti che la tabella di mappaggio verrà creata nella tablespace dell utente. Inoltre si noti che Oracle non offre la possibilità di assegnare un nome alla tabella di mappaggio. In questo caso, se si cerca nella vista del dizionario dati

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 41 DBA_TABLES, si troverà che la tabella di mappaggio ha ricevuto il nome SYS_IOT_MAP_<numero-sequenza>. Il valore numero-sequenza viene generato automaticamente da Oracle. Ecco un esempio di query che mostra una tabella di mappaggio: SELECT owner, table_name, iot_type FROM dba_tables WHERE table_name LIKE '%SYS_IOT%'; OWNER TABLE_NAME IOT_TYPE ---------------------- --------------------- ---------------- SCOTT SYS_IOT_MAP_5293 IOT_MAPPING NOTA Vi sono alcuni problemi di sovraccarico prestazionale legati alle tabelle di mappaggio. È opportuno crearle solo se ve ne è realmente bisogno. Tabelle organizzate a indice, codice DML parallelo e segmenti di overflow Oracle9i consente l impiego di codice DML sulle tabelle organizzate a indice partizionate. Questo può offrire un accesso più rapido alle tabelle organizzate a indice tramite query. Oracle9i consente anche di utilizzare il comando alter table move per spostare una tabella organizzata a indice con un segmento di overflow in un altra tablespace, un operazione che in Oracle8i non era possibile. Si noti che questa operazione può essere eseguita anche online. Ricostruzione degli indici secondari B-tree sulle tabelle organizzate a indice In Oracle9i, gli indici secondari nelle tabelle organizzate a indice possono essere ricostruiti online. Questo consente di ricostruire questi indici mentre continua l attività DML. Questa ricostruzione degli indici secondari online consente anche di ricostruire online i codici di riga. Si noti che durante un operazione di ricostruzione online non può essere utilizzato codice DML parallelo sulle tabelle organizzate a indice. Non è possibile ricostruire un indice bitmap o un indice a cluster in Oracle9i. NOTA Ora è anche possibile convalidare la struttura degli indici e delle tabelle online utilizzando il comando analyze validate.

42 CAPITOLO 2 2.2 Scansione a salto degli indici Si è mai provato a eseguire una query per scoprire che in realtà non utilizzava alcun indice poiché le colonne della query non erano all inizio della query ma troppo in profondità nella struttura dell indice? Si supponga ad esempio di avere una tabella chiamata CHILD contenente tre colonne, PARENT_ID, CHILD_ID e un commento. Inoltre si supponga di aver creato su questa tabella un indice a chiave primaria composita utilizzando le colonne PARENT_ID e CHILD_ID dove PARENT_ID è la prima colonna dell indice (vedere la Figura 2.1). Se si esegue una query come la seguente: SELECT COUNT(*) FROM child WHERE parent_id=1; Oracle sarà in grado di utilizzare l indice a chiave primaria concatenata associato alla chiave primaria della tabella poiché PARENT_ID è la prima colonna dell indice. In Oracle8i, se si fosse voluto eseguire la seguente query: SELECT COUNT(*) FROM child WHERE child_id=1; si sarebbe stati costretti a eseguire una scansione completa della tabella invece di sfruttare gli indici poiché non venivano usate le colonne iniziali dell indice. Le versioni precedenti a Oracle9i, avrebbero usato un indice solo se si fossero usate le colonne iniziali. Oracle9i ha risolto questo problema introducendo la scansione a salto degli indici. Con la scansione a salto non è necessario utilizzare la prima colonna di un indice e si può usare qualsiasi colonna su cui si basa l indice, indipendentemente dall ordine dell indice. CHILD_TABLE Indice composto PARENT_ID CHILD_ID COMMENT PARENT_ID CHILD_ID ROW_ID Figura 2.1 Una tabella e il suo indice composito.

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 43 Pertanto, utilizzando la query precedente in Oracle9i, si sarebbe potuto usare l indice composito anche se PARENT_ID era la colonna iniziale. Oracle eseguirà la scansione di ogni ramo dell albero B-tree per determinare se i valori del blocco foglia associati a tale ramo potevano contenere valori che soddisfacevano la clausola where. Per esempio, si prenda la seguente query: SELECT COUNT(*) FROM child WHERE child_id=50; in questa query, Oracle deve trovare tutte le righe in cui CHILD_ID è equivalente a 50. Oracle eseguirà la scansione dei rami dell indice per ricercare quei rami in cui si può trovare il valore 50 di CHILD_ID spostandosi poi sulle foglie. I rami che non possono contenere un valore pari a 50 nella colonna CHILD_ID vengono potati durante la scansione, risparmiando molto tempo. La Figura 2.2 fornisce un esempio di questa operazione. Come si può vedere nella Figura 2.2, utilizzando la nuova funzionalità di scansione a salto si è eliminato l I/O di un terzo dei blocchi dell indice. Questa tecnica ha i seguenti risultati. Riduce il numero globale di indici necessari per una determinata tabella, riducendo anche il sovraccarico associato alla manutenzione di tali indici. Riduce i problemi provocati dal non poter determinare chiaramente quale colonna di un indice deve essere la colonna iniziale. È molto più rapido rispetto a una scansione completa della tabella e più veloce anche di alcune scansioni a intervallo. Radice dell indice PARENT_ID < 10 CHILD_ID < 30 PARENT_ID < 20 CHILD_ID < 60 PARENT_ID < 40 CHILD_ID < 50 PARENT_ID < 5 CHILD_ID < 20 PARENT_ID < 10 CHILD_ID < 30 PARENT_ID < 10 CHILD_ID < 30 PARENT_ID < 20 CHILD_ID < 60 PARENT_ID < 40 CHILD_ID < 20 PARENT_ID < 50 CHILD_ID < 40 Questo ramo dell indice non viene esaminato poiché CHILD_ID = 30 non è possibile Questo ramo dell indice viene esaminato poiché CHILD_ID = 30 è possibile Questo ramo dell indice viene esaminato poiché CHILD_ID = 30 è possibile Nessuna operazione di taglio I/O I/O Figura 2.2 Ricerca del valore CHILD_ID.

44 CAPITOLO 2 La tecnica di scansione a salto introduce un certo sovraccarico dovuto al fatto che Oracle deve eseguire la scansione degli indici per ogni singolo valore nella colonna dell indice. Dopo l analisi iniziale, Oracle ricerca i valori nelle colonne interne. L operazione può essere molto costosa in termini di prestazioni ma spesso è molto più veloce rispetto a una scansione completa della tabella. Oltre agli indici standard B-tree, l ottimizzatore può utilizzare delle scansioni a salto anche per elaborare gli indici a cluster, le scansioni discendenti o le istruzioni con clausole connect by. NOTA Gli indici a chiave inversa e gli indici bitmap non possono sfruttare la tecnica di scansione a salto. 2.3 Estrazione dei metadata degli oggetti Uno dei problemi più grossi e gravi di un amministratore di database è l estrazione del codice DDL (Data Definition Language) per gli oggetti contenuti nel database. Oracle9i ha tentato di semplificare questa operazione con l introduzione dell API per metadati. Il dizionario dati può essere particolarmente ostico per gli amministratori meno esperti e questa API elimina la necessità di eseguire query sulle viste del dizionario dati per estrarre informazioni necessarie per ricreare un oggetto. L API Metadata di Oracle9i fornisce un interfaccia alternativa che consente di estrarre il codice DDL dal dizionario dati. Questa funzionalità è supportata dal nuovo package Oracle9i dbms_metadata. È possibile estrarre le informazioni sugli oggetti come codice DDL SQL o XML per successive trasformazioni ed esistono interfacce per programmi anche in dbms_metadata. Il package dbms_metadata consente di utilizzare varie funzioni. Le principali per l utilizzo all esterno dei programmi sono get_ddl e get_xml. La funzione get_ddl restituisce informazioni su un oggetto sotto forma di codice DDL SQL eseguibile, mentre la funzione get_xml restituisce metadati in formato XML. È disponibile anche un foglio di stile XSL in $ORACLE_HOME/rdbms/xml/xsl. Le due funzioni hanno il seguente formato: FUNCTION get_xml ( object_type IN VARCHAR2, name IN VARCHAR2, schema IN VARCHAR2 DEFAULT NULL, version IN VARCHAR2 DEFAULT 'COMPATIBLE', model IN VARCHAR2 DEFAULT 'ORACLE', transform IN VARCHAR2 DEFAULT NULL) RETURN CLOB;

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 45 FUNCTION get_ddl ( object_type IN VARCHAR2, name IN VARCHAR2, schema IN VARCHAR2 DEFAULT NULL, version IN VARCHAR2 DEFAULT 'COMPATIBLE', model IN VARCHAR2 DEFAULT 'ORACLE', transform IN VARCHAR2 DEFAULT 'DDL') RETURN CLOB; La procedura GET_DDL rappresenta un buon esempio d uso del package dbms_metadata. In questo esempio si è estratto il codice DDL per la tabella DEPT dello schema SCOTT. SELECT DBMS_METADATA.GET_DDL ('TABLE','DEPT','SCOTT') FROM DUAL; DBMS_METADATA.GET_DDL('TABLE','DEPT','SCOTT') -------------------------------------------------- CREATE TABLE "SCOTT"."DEPT" ( "DEPTNO" NUMBER(2,0), "DNAME" VARCHAR2(14), "LOC" VARCHAR2(13) ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 LOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "USERS" In questo esempio si noti che il primo parametro è il tipo dell oggetto che si vuole estrarre. Tutti i tipi di oggetti validi sono documentati in Oracle9i Supplied PL/SQL Packages and Types Manual. Quindi si fornisce il nome dell oggetto da estrarre e dello schema cui appartiene. Si noti che l output include tutte le parti dell istruzione create table che sono necessarie per ricostruire correttamente questa tabella e che l output non termina con un punto e virgola o una barra. Il secondo esempio estrae il codice DDL dalla funzione my_procedure contenuta nello schema SCOTT: SELECT DBMS_METADATA.GET_DDL ('FUNCTION','MY_FUNCTION','SCOTT') FROM DUAL; DBMS_METADATA.GET_DDL('FUNCTION','MY_FUNCTION','SCOTT') -------------------------------------------------------------------- CREATE OR REPLACE FUNCTION "SCOTT"."MY_FUNCTION" return number as

46 CAPITOLO 2 begin dbms_output.put_line('this is a test'); return 0; end; Anche qui si definisce il tipo dell oggetto (FUNCTION) che si vuole estrarre. Inoltre si definisce il nome e il proprietario dell oggetto. Si noti che Oracle crea tutto il codice DDL, compresa la parola riservata create function. Oracle fornisce un interfaccia programmatica tramite il package dbms_metadata anche per il linguaggio PL/SQL. Esempi d uso di questa funzionalità si trovano agli indirizzi $ORACLE_HOME/rdbms/demo/mddemo.sql e $ORA- CLE_HOME/rdbms/demo/mddemo2.sql. 2.4 Operazioni sugli oggetti online Oracle9i offre varie funzionalità relative alla gestione online degli oggetti dello schema, fra cui varie estensioni alle operazioni online sugli indici, la capacità di portare online il segmento di overflow di una tabella organizzata a indici e la capacità di ridefinire e riorganizzare le tabelle online. Operazioni online sugli indici Oracle9i ha introdotto molte nuove funzionalità che aggiungono flessibilità alla ricostruzione degli indici online. Ora è possibile ricostruire e mettere online i seguenti tipi di indici: indici a chiave inversa facilitando gli aggiornamenti dei ROWID; indici di funzioni; indici compressi a chiave su tabelle organizzate a indice e hash; indici secondari di tabelle organizzate a indice. Oracle ha introdotto alcuni nuovi comandi che supportano le operazioni di ricostruzione online. Il comando alter table coalesce consente di riunire l indice B-tree primario di una tabella organizzata a indice. Il nuovo comando alter index update block references consente di eseguire aggiornamenti online di ROWID logiche per gli indici di una tabella organizzata a indice. L uso del comando update block references provoca l avvio della ricostruzione e dunque non occorre includere la parola riservata online.

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 47 Messa online di un segmento di overflow di una tabella organizzata a indice Ora è possibile portare online il segmento di overflow di una tabella organizzata a indice utilizzando il comando alter table e includendo il comando overflow tablespace come nel seguente esempio: ALTER TABLE my_iot_table MOVE ONLINE TABLESPACE production_data OVERFLOW TABLESPACE production_overflow; Riorganizzazione e ridefinizione delle tabelle online Oracle9i offre la possibilità di riorganizzare e ridefinire online le tabelle e i relativi indici con un livello minimo di indisponibilità degli oggetti costruiti. Questo consente di ricostruire una tabella (ad esempio con un istruzione create table as select) senza coinvolgere le operazioni online. Pertanto è possibile rimuovere i dati abbassando il contrassegno di troppo pieno, ridurre il numero di extent nella tabella o correggere problemi di inefficienza dei blocchi del database causati da un impostazione errata dei parametri del database. Inoltre è possibile trasformare una tabella hash in una tabella organizzata a indice o viceversa. Talvolta si vuole partizionare la tabella o modificare il metodo di partizionamento. Tutte queste operazioni sono supportate dalle operazioni di ricostruzione e ridefinizione delle tabelle online. Di seguito si parlerà un po più in dettaglio queste operazioni. Esecuzione della riorganizzazione In precedenza, per poter riorganizzare una tabella in Oracle era necessario impedire l accesso con codice DML. Infatti, a causa della ricostruzione degli indici, le prestazioni della query select potevano degradare notevolmente durante la riorganizzazione, tanto che era preferibile attendere piuttosto che subire il degrado prestazionale introdotto. Oracle9i offre un nuovo processo che consente di eseguire ricostruzioni e ridefinizioni di tabelle online comprendendo i relativi indici e riducendo al minimo il periodo di indisponibilità del database. Questa nuova operazione si concentra sull impiego del nuovo package Oracle dbms_redefinition. La procedura seguita per ricostruire una tabella è un po complessa e dunque se ne parlerà un passo alla volta. NOTA Si troveranno molti riferimenti alle procedure dbms_redefinition. Se ne parlerà in dettaglio in questa stessa parte del capitolo. 1. Usare la procedura dbms_redefinition.can_redef_table() per verificare che la tabella che si vuole ricostruire online possa essere ricostruita. Vi sono varie restri-

48 CAPITOLO 2 zioni riguardanti la ricostruzione online delle tabelle di cui si parlerà più avanti in questo stesso capitolo. Ecco un esempio d uso della procedura can_redef_table: EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE('SCOTT', 'EMP'); Ecco un esempio in cui la tabella non può essere ridefinita. BEGIN dbms_redefinition.can_redef_table('scott','emp'); END; * ERROR at line 1: ORA-12089: cannot online redefine table "SCOTT"."EMP" with no primary key ORA-06512: at "SYS.DBMS_REDEFINITION", line 8 ORA-06512: at "SYS.DBMS_REDEFINITION", line 236 ORA-06512: at line 1 Si noti che nel listato precedente, Oracle dice che il problema è la mancanza della chiave primaria sulla tabella da ridefinire. Dopo l aggiunta di una chiave primaria, lo stesso test ha successo: SQL> exec dbms_redefinition.can_redef_table('scott','emp'); PL/SQL procedure successfully completed. Questa volta la procedura can_redef_table non ha rilevato alcun errore e dunque si può procedere. 2. Ora si deve creare una tabella vuota che rappresenta la tabella di destinazione dell operazione. Si noti che occorre creare questa tabella nello stesso schema della tabella che si vuole riorganizzare. Per eseguire questo tipo di operazione si può impiegare il comando create table as select. Inoltre occorre assicurarsi di aver definito la chiave primaria per questa tabella di destinazione poiché questo è il requisito necessario per poter eseguire operazioni online sulla tabella. Ecco un esempio: connect scott/tiger CREATE TABLE new_emp PCTFREE 10 PCTUSED 60 STORAGE (INITIAL 100k NEXT 100k) PARTITION BY RANGE(empno) (PARTITION emp_id_50000 VALUES LESS THAN (3000) TABLESPACE emp_tbs_3000, PARTITION emp_id_100000 VALUES LESS THAN (6000) TABLESPACE emp_tbs_60000, PARTITION emp_id_all_others VALUES LESS THAN (MAXVALUE) TABLESPACE emp_tbs_maxvalue)

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 49 AS SELECT * FROM EMP WHERE 1 = 2; ALTER TABLE new_emp ADD PRIMARY KEY (empno); Si noti che a questo punto si potrebbe scegliere di ridefinire la tabella. Inoltre si noti che in questa fase in realtà non si copia alcun record nella tabella. Si possono solo aggiungere, cancellare o modificare le definizioni di una colonna. Tutte queste operazioni sono supportate dal processo di ricostruzione online. In questo caso si è deciso di partizionare la tabella che in precedenza non era partizionata. 3. Dopo aver costruito la tabella sostituta, occorre indicare a Oracle che si sta iniziando una ricostruzione online della tabella SCOTT.EMP. A tale scopo si impiega la procedura start_redef_table() del package dbms_redefinition. Questa procedura accetta tre parametri. Il primo è la tabella da ridefinire o riorganizzare, il secondo è il nome della tabella sostituta e il terzo è un mappaggio opzionale fra le colonne. Se il mappaggio non viene fornito, Oracle presuppone che la struttura della tabella originale e della tabella sostituta sia la stessa. Se viene utilizzato il mappaggio delle colonne, allora solo le colonne elencate nel mappaggio potranno essere trasferite nella tabella sostituta e solo tali colonne verranno verificate da Oracle quando verranno modificate. Ecco un esempio di esecuzione della funzione dbms_redefinition.start_redef_table() per questo esempio: EXEC DBMS_REDEFINITION.START_REDEF_TABLE( UNAME=>'SCOTT', ORIG_TALBE=>'EMP',INT_TABLE=>'NEW_EMP'); Oracle inserirà nella tabella NEW_EMP i record attualmente contenuti nella tabella EMP e inizierà anche a verificare ogni nuova modifica apportata alla tabella EMP ma senza applicarla. Si noti che nell esempio precedente non è necessario definire nuove colonne poiché si utilizzano le stesse colonne. Se invece si fosse deciso di modificare la definizione delle colonne, si sarebbe dovuto includere la definizione di una colonna nella chiamata della procedura. Ad esempio nella tabella EMP sono contenute le seguenti colonne: EMPNO, ENAME, JOB, MGR, HIREDATE, SAL, COMM, DEPTNO Si supponga di volere applicare una stessa percentuale di commissione pari al 10%. Inoltre si supponga di voler rinominare la colonna ENAME chiamandola EMP_NAME. In questo caso il comando da eseguire sarà il seguente: DBMS_REDEFINITION.START_REDEF_TABLE('SCOTT','EMP','NEW_EMP', 'empno empno, ename emp_name, job job, mgr mgr, hiredate hiredate, sal sal, 10 comm, deptno deptno');

50 CAPITOLO 2 Si noti che sono state incluse tutte le colonne di entrambe le tabelle. Inoltre per la colonna ENAME è stato specificato il nuovo nome EMP_NAME. Questo indica un mappaggio di ENAME sulla nuova colonna EMP_NAME. Inoltre si è deciso che nella nuova colonna COMM deve essere inserito il valore 10. 4. Ora occorre creare ogni trigger, indice e vincolo da applicare alla tabella NEW_EMP. In generale questi saranno gli stessi oggetti presenti nella tabella EMP, cambiano solo i nomi. Assicurarsi di creare tutti i vincoli referenziali disattivati. Inoltre creare sulla nuova tabella ogni grant richiesto. Nel seguente esempio si crea il vincolo della chiave primaria, un vincolo di integrità referenziale fra la tabella NEW_EMP e la tabella DEPT e un indice secondario sulla colonna DEPT della tabella NEW_EMP. Tutti questi oggetti sostituiranno gli oggetti definiti nella tabella di origine EMP alla fine di questo processo. ALTER TABLE new_emp ADD CONSTRAINT fkredef_dept_emp FOREIGN KEY(deptno) REFERENCES dept DISABLE; 5. Ora si completa il processo di ridefinizione utilizzando il sottoprogramma finish_redef_table del package dbms_redefinition. Questa operazione provoca un breve periodo di indisponibilità mentre Oracle blocca il dizionario dati per concludere la ricostruzione della tabella. Inoltre Oracle risincrononizzerà la nuova tabella e tutti gli indici ad essa associati con la vecchia tabella prima di eliminare la vecchia tabella. Ecco un esempio d uso di questa procedura: EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE('SCOTT', 'EMP', 'NEW_EMP'); 6. Dopo aver completato con successo il passo precedente, si può cancellare la tabella sostituta che non è più necessaria: DROP TABLE new_emp CASCADE CONSTRAINTS; Risincronizzazione manuale delle tabelle Durante il processo di ridefinizione si potrebbe voler risincronizzare la tabella sostituta con la tabella di origine. Si può eseguire la procedura dbms_redefinition.sync_interim_table. Questo aiuta a ridurre il tempo della chiamata a exec dbms_redefinition.finish_redef_table alla fine del processo di ridefinizione. Ecco un esempio di una chiamata alla procedura sync_interim_table: EXEC DBMS_REDEFINITION.SYNC_INTERIM_TABLE( SCOTT, DEPT, NEW_DEPT );

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 51 Cosa accade se si verifica un errore Se si verifica un errore e appare chiaro che il processo di ridefinizione dovrebbe essere bloccato, si può utilizzare la procedura dbms_redefinition.abort_redef_table che interrompe tutte le operazioni di sincronizzazione fra la tabella di origine e la tabella sostituta in modo da poter cancellare la tabella sostituita senza alcun errore. Oracle consente di eseguire questa procedura anche se si e già cancellata la tabella sostituta. Regole e restrizioni per la ricostruzione online Quando si ricostruisce o ridefinisce una tabella online, occorre applicare un insieme di regole e restrizioni. Se una di queste condizioni non è esaudita, la tabella non può essere ricostruita online. Sia la tabella di origine che la tabella sostituta devono avere delle chiavi primarie e queste chiavi devono essere costruite sulle stesse colonne. Le tabelle di proprietà di SYS o SYSTEM non possono essere gestite in questo modo. Inoltre non si può spostare una tabella in un altro schema e non è possibile dichiarare nuove colonne come NOT NULL se non dopo aver concluso il processo di ricostruzione. Non è possibile ricostruire tabelle che fanno parte di una vista materializzata. Inoltre le tabelle con log di viste materializzate non possono essere ricostruite online. Le tabelle a cluster non possono essere impiegate per una ridefinizione online. Le tabelle container di viste materializzate e le tabelle di query avanzate non possono essere ricostruite. Le tabelle che usano colonne dei seguenti tipi non possono essere ridefinite online: oggetti; REF; tabelle nidificate; VARRAY; tabelle a tipi; FILE; LONG (le colonne LOB possono essere ridefinite). Le tabelle temporanee e a cluster non possono essere ridefinite online. Le tabelle che appartengono a SYS e SYSTEM non possono essere ridefinite online. Le nuove colonne da aggiungere nell ambito della ridefinizione possono essere dichiarate NOT NULL solo se la ridefinizione è completa. Infine non è possibile definire alcun vincolo referenziale fra la tabella da ridefinire e la tabella sostituta. Privilegi necessari per la ricostruzione online Per ridefinire una tabella occorre avere i seguenti privilegi: alter any table;

52 CAPITOLO 2 create any table; drop any table; execute sul package dbms_redefinition (execute_catalog_role ha questo privilegio); lock any table; select any table. Le procedure del package dbms_redefinition Il package dbms_redefinition viene utilizzato nella ridefinizione delle tabelle per mantenere sincronizzata la tabella sostituta con la tabella ridefinita. Il package contiene cinque sottoprogrammi: can_redef_table; start_redef_table; finish_redef_table; sync_interim_table; abort_redef_table. Di seguito si parlerà un po più in dettaglio di queste procedure. La procedura can_redef_table Questa procedura viene utilizzata per determinare se una determinata tabella è un buon candidato per una ridefinizione online. Ecco la sintassi del comando: Procedure DBMS_REDEFINITION.CAN_REDEF_TABLE ( uname IN VARCHAR2, -- Nome utente tname IN VARCHAR2 ); -- Tabella da controllare Un esempio d uso di questa procedura si trova nel paragrafo L esecuzione della riorganizzazione. La procedura start_redef_table Questa procedura viene utilizzata per indicare che Oracle deve iniziare a trasferire i dati dalla tabella di origine alla tabella sostituta iniziando così il processo di ridefinizione. Quando viene eseguita questa istruzione, Oracle inizia a registrare ogni modifica apportata alla tabella di origine per replicare tale modifica nella tabella sostituta. Tutte le modifiche registrate vengono trasferite alla tabella sostituita durante l esecuzione della procedura finish_redef_table o sync_interim_table. Ecco la sintassi da impiegare: Procedure DBMS_REDINITION.start_redef_table ( uname IN VARCHAR2, -- Nome utente orig_table IN VARCHAR2, -- Tabella di origine

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 53 int_table IN VARCHAR2, -- Tabella sostituta col_mapping IN VARCHAR2 := NULL ); -- Mappaggio fra le colonne Un esempio d uso di questa procedura si trova nel paragrafo L esecuzione della riorganizzazione. La procedura finish_redef_table Questa procedura viene utilizzata per indicare al server Oracle che il processo di ridefinizione è terminato e che l amministratore di database è pronto per sincronizzare la tabella sostituta con la tabella di origine. Dopo aver eseguito questa operazione, la tabella sostituta e tutti gli indici, i trigger, i grant e i vincoli creati sulla tabella sostituta verranno ridefiniti sostituendo la tabella di origine e i suoi oggetti. Durante questa elaborazione vi è un breve periodo in cui il dizionario dati risulta indisponibile. La sintassi del comando è la seguente: Procedure DBMS_REDFINITION.finish_redef_table ( uname IN VARCHAR2, -- Nome utente orig_table IN VARCHAR2, -- Tabella di origine int_table IN VARCHAR2 ) -- Tabella sostituta Un esempio d uso di questa procedura si trova nel paragrafo L esecuzione della riorganizzazione. La procedura sync_interim_table Questa procedura fa in modo che Oracle sincronizzi la tabella sostituta con la tabella di origine. La sintassi del comando è la seguente: DBMS_REDFINITION.sync_interim_table ( uname IN VARCHAR2, -- Nome utente orig_table IN VARCHAR2, -- Tabella di origine int_table IN VARCHAR2 ) -- Tabella sostituta Un esempio d uso di questa procedura si trova nel paragrafo Risincronizzazione manuale delle tabelle. La procedura abort_redef_table Questa procedura provoca l annullamento di tutti i processi di ridefinizione. Tutta l attività di logging sulla tabella di origine viene bloccata e i log vengono rimossi. Una volta eseguita questa procedura, è possibile rimuovere la tabella sostituta. La sintassi del comando è la seguente: DBMS_REDEFINITION.abort_redef_table ( uname IN VARCHAR2, -- Nome utente orig_table IN VARCHAR2, -- Tabella di origine

54 CAPITOLO 2 int_table IN VARCHAR2 ) -- Tabella sostituta Un esempio d uso di questa procedura si trova nella sezione Cosa accade se si verifica un errore. 2.5 Gestione automatizzata dello spazio del segmento Oracle9i introduce due modi per gestire lo spazio libero di un segmento. Il vecchio metodo che prevede l impiego di free list è tuttora supportato ma ora è disponibile anche il nuovo metodo di gestione automatizzata dello spazio del segmento. Come il vecchio metodo (che è ancora il metodo standard) Oracle usa una struttura chiamata free list che registra i blocchi liberi all interno di un segmento. In Oracle9i (al posto della free list) è possibile creare una tablespace definita per utilizzare la gestione automatizzata dello spazio. Quando viene creato un oggetto in una tablespace che utilizza la gestione automatizzata dello spazio, Oracle crea un bitmap all interno di blocchi nel segmento, chiamato BMB. Normalmente i BMB occupano i primi tre blocchi del segmento mentre il quarto blocco è rappresentato dall intestazione del segmento stesso. Il bitmap descrive lo stato dei blocchi contenuti nel segmento, indicando quanto spazio è disponibile nel blocco per l inserimento di nuove righe. Quando cambia il blocco cambia anche il valore contenuto nel bitmap. L utilizzo di un bitmap è più semplice ed efficiente rispetto all impiego di una free list in quanto consente di utilizzare al meglio lo spazio ed elimina la necessità di specificare pctused, freelists e freelists groups quando si definiscono gli oggetti nella tablespace. La gestione automatica dello spazio del segmento è disponibile solo nelle tablespace a gestione locale. Oracle ha semplificato notevolmente questa funzionalità. Basta includere la clausola segment space management auto quando si usa il comando create tablespace per creare una tablespace. La gestione automatica dello spazio dei segmenti si applica a tutti i segmenti creati all interno di una tablespace creata con la clausola segment space management. Ecco un istruzione create tablespace che crea una tablespace che utilizza la gestione automatizzata dello spazio del segmento. CREATE TABLESPACE my_auto_tbs DATAFILE 'c:\oradata\mydb\mydb_my_auto_tbs_01.dbf' SIZE 100m EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANGEMENT AUTO;

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 55 La gestione automatizzata dello spazio è molto più efficiente rispetto alle free list se utilizzata all interno di tablespace che contengono tabelle con righe di dimensioni variabili. Infatti fra le estensioni pianificate di Oracle vi sarà l obbligo di utilizzare la gestione automatica dello spazio del segmento. Quando si utilizza la gestione automatizzata dello spazio del segmento occorre considerare alcune restrizioni. Innanzitutto questa funzionalità è disponibile solo per le tablespace permanenti e a gestione locale. Inoltre non è possibile creare colonne LOB in una tablespace progettata per la gestione automatica dello spazio del segmento. Infine una tablespace creata utilizzando la gestione automatica dello spazio del segmento non può essere modificata per utilizzare la gestione a free list. 2.6 Indici bitmap di join Gli indici bitmap sono stati introdotti fin da Oracle8. Ora, con Oracle9i, è possibile creare indici bitmap di join. Gli indici bitmap di join rappresentano l operazione di join delle colonne in due o più tabelle. Con un indice di join, il valore di una colonna in una tabella (generalmente una tabella dimensione) viene memorizzato nei relativi codici ROWID del valore corrispondente nelle altre tabelle su cui è definito l indice. Questo garantisce un accesso di join più rapido fra le tabelle (se tale query usa le colonne dell indice bitmap di join). Nella Figura 2.3, si vede un indice bitmap di join creato fra due diverse tabelle: una tabella dei fatti e una tabella dimensione. In un ambiente di data-warehouse, un indice bitmap di join può essere il modo più efficiente per accedere ai dati rispetto ai join su viste materializzate. Quando si usa un indice di join in un ambiente data-warehouse o EIS, si utilizza una equiinner join fra le colonne della chiave primaria delle tabelle dimensione e le colonne della chiave esterna della tabella dei fatti. Si può creare un indice bitmap di join utilizzando il comando create bitmap index. Ecco un esempio di creazione di questo tipo di indice : CREATE BITMAP INDEX my_bitmap_index ON fact_table(dimension_table.col_2) FROM dimension_table, fact_table WHERE dimension_table.col1=fact_table.col1; Occorre considerare alcune restrizioni sulla creazione degli indici bitmap di join. L indice bitmap di join viene costruito su un unica tabella. Nell esempio precedente, l indice bitmap di join era costruito sulla tabella FACT_TABLE.

56 CAPITOLO 2 Indice bitmap di join La query richiede solo l uso delle tabelle degli indici e dei fatti. Oracle non deve accedere alla tabella dimensione. Figura 2.3 Un indice bitmap di join. Oracle consente di aggiornare, inserire o cancellare una sola delle tabelle di un indice bitmap di join per volta. Non è possibile eseguire un operazione di join di una tabella con se stessa ovvero nessuna tabella può comparire due volte nella clausola from. Un indice bitmap di join non può essere creato su una tabella organizzata a indice o una tabella temporanea. Ogni colonna di un indice bitmap di join deve essere presente in una delle tabelle dimensione specificate. Le operazioni di join degli indici bitmap devono formare uno schema a stella. Sulle colonne di join dell indice bitmap di join devono essere creati dei vincoli sulle colonne della chiave primaria o dei vincoli di univocità.

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 57 Tutte le colonne della chiave primaria della tabella dimensione devono far parte dei criteri di join dell indice bitmap di join. Agli indici bitmap di join si applicano tutte le restrizioni dei normali indici bitmap. Non è possibile creare un indice bitmap di join su una tabella organizzata a indice. 2.7 Identificazione degli indici inutilizzati Oracle8i ha introdotto il monitoraggio dell uso delle tabelle per migliorare il processo di raccolta delle statistiche. Con Oracle9i è anche possibile monitorare l uso degli indici all interno del database. Gli indici inutilizzati rappresentano naturalmente uno spreco di spazio e possono provocare problemi prestazionali in quanto Oracle deve gestire l indice ogni volta che la relativa tabella è coinvolta in un operazione DML. Per iniziare a monitorare l indice si usa il comando alter index con la clausola monitoring usage: ALTER INDEX index_name MONITORING USAGE; Per terminare il monitoraggio di un indice, si usa nuovamente il comando alter index ma con la clausola nomonitoring usage: ALTER INDEX index_name NOMONITORING USAGE; Mentre l indice è in modalità di monitoraggio, si può usare la vista V$OB- JECT_USAGE per determinare se l indice è stato utilizzato. Si noti che la vista mostrerà le informazioni d uso solo quando viene interrogata dal proprietario dell indice. Si può eseguire la query sulla colonna USED della vista V$OB- JECT_USAGE. Se il valore della colonna è NO, l indice non è stato usato. Se il valore della colonna è YES, l indice è stato usato. Questa vista include anche le colonne START_MONITORING ed END_MONITORING che indicano il tempo di inizio e fine del monitoraggio su tale indice. Il nome dell indice e della relativa tabella viene fornito rispettivamente dalle colonne INDEX_NAME e TABLE_NAME. Infine la colonna MONITORING indica se l indice è attualmente monitorato. Ogni volta che viene eseguito il comando alter table monitoring usage, la riga di V$OBJECT_USAGE relativa a tale indice viene reinizializzata. Ecco un esempio di query su questa tabella: SQL> select * from v$object_usage;

58 CAPITOLO 2 INDEX_NAME TABLE_NAME MON USE ------------------------------ ------------------------------ --- --- START_MONITORING END_MONITORING ------------------- ------------------- MY_BITMAP_INDEX TEST_DIM NO NO 10/20/2001 00:01:42 10/20/2001 00:04:56 SYS_C002155 EMP YES YES 10/20/2001 00:05:20 In questo esempio vi sono due indici. Innanzitutto vi è l indice MY_BIT- MAP_INDEX che è stato costruito sulla tabella TEST_DIM. Poiché si trova nella vista V$OBJECT_USAGE, si può sapere che è stata monitorata. Un indice non compare nella vista V$OBJECT_USAGE se non è stato monitorato in qualche momento della sua vita. MY_BITMAP_INDEX attualmente non è monitorato; inoltre la colonna USE indica NO, ovvero l indice non è stato utilizzato mentre era monitorato. In secondo luogo viene indicato l indice SYS_C002155. Si può vedere che attualmente è monitorato osservando la colonna MONITORING che riporta il valore YES. Il valore YES nella colonna USED dice anche che è stato utilizzato. 2.8 Condivisione del cursore Oracle9i introduce vari miglioramenti che riguardano la condivisione del cursore. La condivisione del cursore consente il riutilizzo di un cursore da parte di altre sessioni, riducendo il tempo richiesto da Oracle per analizzare l istruzione SQL. Sono state aggiunte molte nuove funzionalità che irrobustiscono la condivisione del cursore. La prima riguarda il modo in cui l ottimizzatore basato su costi (CBO) interagisce con le istruzioni che contengono le variabili associate. In Oracle9i, quando un istruzione contiene una variabile bind, la prima volta che viene eseguita l istruzione, l ottimizzatore CBO ricerca i valori associati a tale variabile. L ottimizzatore poi utilizzerà il valore delle variabili bind per determinare il percorso di esecuzione più efficiente. Oracle utilizzerà lo stesso percorso di esecuzione per tutte le successive esecuzioni di tale istruzione SQL, indipendentemente dal valore della variabile bind dell istruzione. Pertanto l operazione può portare a una condivisione sicura o non sicura del cursore. Se il letterale della clausola where è tale che modificandolo non viene alterato il piano di esecuzione della query, allora si dice che la condivisione del cursore è sicura. Un esempio prevede una lista di nomi di pazienti ai quali è associato un identificatore univoco. In questo caso, un istruzione come la seguente: SELECT patient_name FROM patient WHERE patient_id=12345;

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 59 verrebbe considerata un cursore sicuro poiché la sostituzione di 12345 con qualsiasi altro valore non modificherebbe il piano di esecuzione. Oracle può determinare se un cursore è sicuro quando lo analizza. Per determinare se il cursore è sicuro usa le statistiche raccolte sugli oggetti cui si fa accesso e gli istrogrammi. In un cursore non sicuro, una variazione del letterale può provocare una modifica al piano di esecuzione. Ad esempio, si supponga di interrogare con una query la tabella PATIENT ma questa volta ricercando il cognome Freeman: SELECT patient_name FROM patient WHERE last_name='freeman'; Supponendo che nella tabella PATIENT vi sia un indice costruito sulla colonna LAST_NAME, Oracle potrebbe scegliere di utilizzare l indice per questa query. Il problema è che, dato che successivamente si esegue la seguente query: SELECT patient_name FROM patient WHERE last_name='smith'; Oracle utilizzerà lo stesso piano di esecuzione impiegato per la prima query. Se scegliesse di utilizzare l indice per risolvere la prima query, la scansione a indice potrebbe essere un idea non adatta alla seconda query. Questo è dovuto al fatto che probabilmente vi saranno pochi cognomi Freeman e molti cognomi Smith. Oracle9i consente di istruire l ottimizzazione per condividere solo i cursori sicuri tramite l impiego del nuovo valore similar del parametro cursor_sharing. Il valore similar limita la condivisione ai soli cursori che sono ritenuti sicuri. Pertanto, utilizzando similar si riduce l instabilità che può essere introdotta impostando cursor_sharing su force. In associazione al nuovo parametro similar vi è l opzione SQL cursor_sharing_exact che disattiva la condivisione del cursore costringendo l istruzione SQL a ricercare corrispondenze esatte di un istruzione nell area condivisa. Inoltre si possono usare i comandi alter session e alter system per modificare il valore dei parametri cursor_sharing. 2.9 Miglioramenti del server condiviso Oracle9i ha rinominato il server MTS (Multi-Threaded Server) chiamandolo server condiviso. L architettura a server condiviso aumenta la scalabilità delle applicazioni e il numero di client che possono essere simultaneamente connessi al database. L architettura a server condiviso consente anche di estendere la scala delle applicazioni esistenti senza apportare alcuna modifica all applicazione. Per questo motivo sono stati aggiunti e modificati numerosi parametri. Oracle suggerisce di utilizzare i nuovi parametri al posto dei vecchi. Ecco la tabella delle sostituzioni fra parametri vecchi e nuovi.

60 CAPITOLO 2 VECCHIO PARAMETRO mts_dispatchers mts_max_dispatchers mts_servers mts_max_servers mts_circuits mts_sessions NUOVO PARAMETRO dispatchers max_dispatchers shared_servers max_shared_servers circuits shared_server_sessions Inoltre Oracle ha introdotto una nuova vista che può essere utilizzata per monitorare il server condiviso. Questa vista si chiama V$SHARED_SERVER_MO- NITOR e il suo scopo è quello di fornire informazioni utili per l ottimizzazione del server condiviso. La vista contiene le seguenti colonne. COLONNA MAXIMUM_CONNECTIONS MAXIMUM_SESSIONS SERVERS_STARTED SERVERS_TERMINATED SERVERS_HIGHWATER DESCRIZIONE Il massimo numero di circuiti virtuali che sono stati in uso contemporaneamente dall avvio dell istanza. Può essere necessario incrementare il parametro circuts quando questo numero si avvicina al valore impostato per circuits. Il numero numero massimo di sessioni del server condiviso che sono state in uso dall avvio dell istanza. Può essere necessario incrementare il parametro shared_server_sessions quando questo numero si avvicina al valore impostato per shared_server_sessions. Il numero totale di server condivisi avviati dall avvio dell istanza. Il numero totale di server condivisi che sono stati fermati da Oracle dall avvio dell istanza. Il numero massimo di sessioni del server condiviso che sono state in uso dall avvio dell istanza. Può essere necessario incrementare il parametro max_shared_servers se questo numero si avvicina al valore impostato per max_shared_servers. Inoltre Oracle ha riprogettato i protocolli di connessione fra il processo client, il listener Oracle e il processo dispatcher semplificando così le operazioni. Questa nuova connessione direct handoff riduce il sovraccarico della rete e riduce anche il livello medio di traffico di rete necessario per creare una connessione fra il client e il processo dispatcher. Il processo dispatcher è stato migliorato e gli eventi della rete e del database vengono ora gestiti utilizzando un modello a eventi interno. Questo nuovo modello a eventi riduce i requisiti di CPU del processo dispatcher e favorisce un utilizzo efficiente della rete. Infine si può usare Oracle Performance Manager da OEM (fa parte di OEM Performance Pack) per monitorare i dispatcher del server condiviso, i server condivisi e i listener. Oracle Performance Manager semplifica la gestione dei server condivisi in un interfaccia grafica.

MODIFICHE ALL ARCHITETTURA DI ORACLE9I 61 NOTA I database Oracle9i che usano server condivisi possono supportare il package dbms_ldap. In Oracle8i ciò non era possibile. 2.10 Variazioni alle impostazioni predefinite di create tablespace In Oracle9i, sono state cambiate le impostazioni predefinite del comando create tablespace. Innanzitutto quando si crea una tablespace in Oracle9i, viene creata una tablespace gestita localmente utilizzando il metodo di allocazione degli extent SYSTEM; il parametro compatibility deve però essere impostato sul valore 9.0.0.0 o un valore superiore. 2.11 Sospensione del database Se si è provato a sostituire un package PL/SQL in un database molto impegnato, si sa quanti problemi possono sorgere, in quanto le transazioni bloccano il package, impedendo all amministratore di modificarlo. Vi sono anche altre operazioni che soffrono di problemi di bloccaggio, come ad esempio i comandi alter table o alter index o la riorganizzazione o ridefinizione di una tabella. Naturalmente una soluzione consiste nel chiudere il database e riavviarlo in una sessione limitata ma sfortunatamente questo produce effetti indesiderati: vengono vuotate le aree cache della memoria; gli utenti vengono espulsi dal sistema; può essere necessario uccidere le transazioni in corso; i tempi di avvio e di chiusura possono allungarsi per il ripristino dell istanza. Oracle9i offre una soluzione a questi problemi sotto forma dello stato di sospensione. Quando il database viene posto in questo stato, tutte le istruzioni in corso vengono lasciate completare e quindi la sessione viene congelata. Inoltre quando il database è in stato di sospensione, tutte le nuove connessioni (che non siano dell amministratore) vengono sospese e la connessione non può completarsi finché il database non viene fatto uscire dallo stato di sospensione. Per portare il database nello stato di sospensione si usa il seguente comando: ALTER SYSTEM QUIESCE RESTRICTED; Dopo aver completato le attività, l amministratore di database può riportare il database nello stato di funzionamento normale utilizzando il comando:

62 CAPITOLO 2 ALTER SYSTEM UNQUIESCE; Per poter portare il database in modalità di sospensione occorre aver attivato Resource Manager il quale questo deve essere attivato dall ultimo avvio del sistema. Se si ferma e poi si riavvia il Resource Manager fra i cicli del database, non si sarà in grado di portare il database in stato di sospensione finché non si chiude il database e non lo si riavvia con Resource Manager in esecuzione. Se questo requisito non è esaudito, ogni tentativo di portare il database in stato di sospensione provocherà un errore. Infine se si esegue un backup mentre il database è in stato di sospensione, tale backup verrà considerato incoerente. Pertanto l esecuzione di un backup di un database aperto in modalità di sospensione richiede comunque un backup a caldo e questa modalità non può essere utilizzata per sospendere il database.