Best Practices Hints & Tips e Novità SQL

Best Practices Hints & Tips e Novità SQL A cura di Angelo Sironi 1 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 2 1

Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 3 Ipotesi Processore da 1.000 Mips Ignorato effetto MP Dati indicativi SQL Statement Consumo di CPU minimo (microsec ( microsec.) Istruzioni equivalenti SET :h = CURRENT DATE 3 3.000 SELECT INTO :h 13 13.000 FETCH 1 riga 10 10.000 Multi-row FETCH 100 righe 500 500.000 4 2

Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 5 Funzione Fornire informazioni sulla strategia di accesso ai dati scelta dall ottimizzatore Tipo di accesso (es. guidato da uno o più indici) Sequenza di join Metodo di join Ecc. Invocazione SQL statico Opzione EXPLAIN ( NO, YES, ONLY) del comando BIND PACKAGE Statement EXPLAIN PACKAGE (nuovo in DB2 10) SQL statico o dinamico Statement EXPLAIN Pre-requisiti requisiti (minimi) Esistenza di una copia della tabella user.plan_table 6 3

EXPLAIN PAKAGE COLLECTION collection -name PAKAGE package-name VERSION version-name COPY copy-id Provoca l Explain di tutti gli statement del Package Il DB2 esternalizza in PLAN_TABLE una copia delle informazioni sulle strategia di accesso esistenti in formato interno Diversamente dal comando BIND EXPLAIN(ONLY), non viene generata una nuova strategia di accesso Non viene effettuato un BIND Si applica solo a Package bound con DB2 V9 o successivi 7 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 8 4

SQL Request SQL Result RELATIONAL DATA SERVICES DATA MANAGER Evaluates STAGE 2 predicates Evaluates STAGE 1 ( sargable ) predicates BUFFER MANAGER 9 Efficienza Predicati Stage 1 Indexable Adeguatamente supportati da indici Stage 1 Gestiti dal Data Manager nell accesso al Buffer Pool Inibitori più comuni: presenza nei predicati di Funzioni scalari (es. T1.C1 = SUBSTR(T2.C1,1,4) ) Espressioni (es. T1.C1 + :h1 = :h2 ) Mismatch di tipo dato (es. T1.C1 = :h1 con C1 SMALLINT e :h1 DECIMAL(7,0)) 10 5

Tecniche/costrutti da non usare nei predicati CASE Expression :hostvar1 = costante OR Colonna = :hostav2.. ecc. Tecniche tollerate (ottimizzabili( esternamente) WHERE COL1 BETWEEN :hostvar1 AND :hostvar2 AND COL2 BETWEEN : hostvar3 AND :hostvar4 AND ecc. Uso di BETWEEN raccomandato al posto di predicati del tipo WHERE COL1 >= :hostvar1 AND COL1 <= :hostvar2 AND ecc. Eccezione: :hv BETWEEN COL1 AND COL2 Tecniche tollerate ( 11 2,3 FETCH per OPEN (di cui una con SQLCODE=100) Ca. 5.000 GETPAGE / OPEN 3 millisec.. di CPU in media) DECLARE CURS01 CURSOR FOR SELECT ecc. FROM TABLE_1 T1 INNER JOIN TABLE_2 T2 ON predicati di join WHERE T1.C1 = :H1 AND T1.C2 = :H2 AND ((CASE :H5 WHEN 0 THEN T1.C3 END = :H3 AND CASE :H5 WHEN 0 THEN T1.C4 END = :H4 ) OR (CASE :H3 WHEN 0 THEN T1.C5 = :H5 ) ) ORDER BY ecc. 12 6

Caso 1: 1 : sono noti i valori di ricerca di C3 e C4 DECLARE CURS01 CURSOR FOR SELECT ecc. FROM TABLE_1 T1 INNER JOIN TABLE_2 T2 ON predicati di join WHERE T1.C1 = :H1 AND T1.C2 = :H2 AND T1.C3 = :H3 AND T1.C4 = :H4 ORDER BY ecc. Caso 2: 2 : sono noti i valori di ricerca di C5 DECLARE CURS01 CURSOR FOR SELECT ecc. FROM TABLE_1 T1 INNER JOIN TABLE_2 T2 ON predicati di join WHERE T1.C1 = :H1 AND T1.C2 = :H2 AND T1.C5 = :H5 ORDER BY ecc. 7

Flusso originale (semplificato) OPEN CURS01 FETCH CURS01 Gestisci Riga CLOSE CURS01 ecc. 15 Flusso modificato (semplificato) Caso 1 Caso 2 IF OPEN CURS01A OPEN CURS01B FETCH CURS01A Gestisci Riga FETCH CURS01B CLOSE CUSR01A CLOSE CURS01B ecc. 16 8

Cardinalità della Tabella: 3,0 milioni SELECT ecc. INTO :H, FROM TABLE WHERE C1 = :H1 AND ( '' = :HX OR ID = :HID ) AND ( ( '' = :HY AND 0 = :HZ ) OR ( CX = :HX AND CY = :HY ) ) Valori medi per singola esecuzione Elapsed Time : 10,59 sec. Consumo di CPU : 2,074 sec. (ca. 2 miliardi di istr.) Getpage : 409.406 17 Cardinalità della Tabella: 7,5 milioni SELECT COUNT ( * ) INTO :H FROM TABLE WHERE C1 = :H AND DATA BETWEEN :H AND :H AND ( C2 IN ( :H, :H ) ) AND ( :H IN ( C3, C4, ' ' ) ) AND ( :H IN ( C5, 0 ) ) AND ( :H IN ( C6, ' ' ) ) AND ( :H IN ( C7, ' ' ) ) AND ( :H IN ( C8, C9, ' ' ) ) AND ( C10 <> 12345 OR ( C10 = 12345 AND C11 <> XXXXXXXXX' )) Valori medi per singola esecuzione Elapsed Time : 7,097 sec. Consumo di CPU : 4,432 sec. (ca. 4,5 miliardi di istr.) Getpage : 193.443 18 9

Soluzione raccomandata Del tutto simile alla precedente Più semplice, non dovendo gestire OPEN/CLOSE e ciclo di FETCH Si suddivide in due, tre o più casi, a seconda della frequenza d uso e della capacità di filtro, usando dove possibile predicati di uguaglianza Caso 1: 1 predicati su C1, C2 (e C5?) Caso 2: 2 predicati su C1, C2 e C6 Caso 3: 3 ecc. Invece dell operatore CASE, si usino condizioni di BETWEEN, ed eventualmente hint per REOPT Riduzione del consumo di CPU attesa Uno o anche due ordini di grandezza Similmente per il caso 2B 19 WITH TEMP1 AS (SELECT C1, C2, C3, ecc. FROM TABLE WHERE C1 = :H AND DATA BETWEEN :H AND :H AND ( C2 IN ( :H, :H ) ) AND ( :H IN ( C3, C4, ' ' ) ) AND ( :H IN ( C5, 0 ) ) AND ( :H IN ( C6, ' ' ) ) AND ( :H IN ( C7, ' ' ) ) AND ( :H IN ( C8, C9, ' ' ) ) AND ( C10 <> 12345 OR ( C10 = 12345 AND C11 <> XXXXXXXXX' )) ), TEMP2 AS (SELECT COUNT(*) AS CONTA FROM TEMP1) SELECT T1.*, T2.CONTA FROM TEMP1 T1, TEMP2 T2 20 10

SELECT omissis FROM TABLE_1 T1 LEFT OUTER JOIN TABLE_2 T2 ON omissis WHERE T1.C1 = COALESCE (CAST (? AS VARCHAR(8)), T1.C1 ) AND T1.C2 = COALESCE (CAST (? AS VARCHAR(5)), T1.C2 ) AND omissis AND T1.END_DATE <= CURRENT TIMESTAMP AND COALESCE ( T1.END_DATE, ( CURRENT TIMESTAMP + 1 SECOND ) ) > ( CURRENT TIMESTAMP ) Ambiente DRDA JDBC / ODBC Il DB2 non riesce ad usare in modo efficiente (Matching Mode) eventuali indici su T1.C1 e/o T1.C2 Ogni esecuzione della query provoca mediamente la scansione di 17.000 pagine e un consumo di CPU di oltre 170 millisecondi (per Prepare, Open, 2-3 Fetch, Close) 21 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 22 11

Problemi «logici» in presenza di NULL Risultati potenzialmente errati Maggiore complessità della codifica SQL Inefficienze Spazio disco e memoria Non abusare nell uso dei NULL Evitare di definire colonne come NULL-able, a meno che non se ne possa proprio fare a meno Attenzione: NULL è il default! 23 D1: Trovare i Fornitori che è noto che forniscono il Prodotto P1, ma di certo non in una quantità pari a 100 Q1a SELECT DISTINCT FX.COD_F FROM FORNITORI FX WHERE FX.PRODOTTO = 'P1' AND 100 NOT IN ( SELECT FY.QTA FROM FORNITORI FY WHERE FY.COD_F = FX.COD_F AND FY.PRODOTTO = 'P1') ; R1a 12

D1: Trovare i Fornitori che è noto che forniscono il Prodotto P1, ma di certo non in una quantità pari a 100 Q1b SELECT DISTINCT FX.COD_F FROM FORNITORI FX WHERE FX.PRODOTTO = 'P1' AND NOT EXISTS ( SELECT FY.QTA FROM FORNITORI FY WHERE FY.COD_F = FX.COD_F AND FY.PRODOTTO = 'P1' AND FY.QTA = 100 ) ; R1b Q2a (tautologia?) SELECT * FROM FORNITORI WHERE QTA = 100 OR QTA <> 100 R2a Q2t (tautologia!) SELECT * FROM FORNITORI WHERE QTA = 100 OR QTA <> 100 OR QTA IS NULL R2t 13

Q3 SELECT AVG(SALARIO) + AVG(COMM) AS AVG_SAL_1, AVG(SALARIO+COMM) AS AVG_SAL_2 FROM FORNITORI Esempio CREATE TABLE TEST (KEY INTEGER NOT NULL, VALID_FROM TIMESTAMP NOT NULL, VALID_TO TIMESTAMP ) Trovare il record con KEY = :h valido ora SELECT * FROM TEST WHERE VALID_FROM <= CURRENT TIMESTAMP AND (VALID_TO >= CURRENT TIMESTAMP OR VALID_TO IS NULL) Esistono un certo numero di varianti della soluzione precedente Alcune decisamente inefficienti 28 14

SELECT omissis FROM TABLE_1 T1 LEFT OUTER JOIN TABLE_2 T2 ON omissis WHERE T1.C1 = COALESCE (CAST (? AS VARCHAR(8)), T1.C1 ) AND T1.C2 = COALESCE (CAST (? AS VARCHAR(5)), T1.C2 ) AND omissis AND T1.END_DATE <= CURRENT TIMESTAMP AND COALESCE ( T1.END_DATE, ( CURRENT TIMESTAMP + 1 SECOND ) ) > ( CURRENT TIMESTAMP ) La colonna END_DATE, essendo NULLable,, non può essere parte della chiave di univocità Il DB2 non riesce ad usare in modo efficiente un eventuale indice sulla colonna END_DATE 29 NULL Non è un valore della colonna È un indicatore associato alla colonna Ogni colonna NULL-able richiede un byte in più Nel tablespace In ogni eventuale indice di cui risulta parte della chiave Su disco e nei buffer pool 30 15

Colonne Carattere Usare una stringa di blank SE VARCHAR, impostare LL = 0 Colonne DATE e TIMESTAMP usate per delimitare intervalli di validità Esempio per datatype DATE LOW-END = valore a scelta / default 01.01.0001 HIGH-END = 30.12.9999 (standard Java e SQL ISO/ANSI Temporal Support) oppure 31.12.9999 Reperimento del record valido ora SELECT * FROM TEST WHERE VALID_FROM <= CURRENT TIMESTAMP AND VALID_TO > CURRENT TIMESTAMP 31 Il DB2 10 per z/os introduce il supporto dello standard ANSI/ISO SQL per le costanti datetime Esempi della sintassi DATE '1977-01-18' -- valid date (ISO format) DATE '18.01.1977' -- valid date (EUR format) DATE '0000-01-18' -- invalid date (bad year) DATE '2010-02-29' -- invalid date (bad day) TIME '24:00:00' -- valid time (JIS, ISO format) TIME '24:00:01' -- invalid time (bad hour) TIME '00.00.00' -- valid time (EUR format) TIME '12:01 AM' -- valid time (USA format) TIMESTAMP '2007-05-14 11:55:00.1234' -- valid (space and colons) Raccomandazione: specificare DATE 2010-08 08-06 06 invece di DATE( 2010 ( 2010-08 08-06 ) 06 ) per migliorare la portabilità e, forse, anche le prestazioni Evitare codifiche del tipo WHERE CHAR(data, ISO) = :h 32 16

Prima del DB2 10, il formato del tipo dato TIMESTAMP era fisso e forniva una precisione al microsecondo (10-6 secondi) Con il DB2 10, l utente può definire la precisione che preferisce minima = 0 (precisione al secondo) massima = 12 (precisione al picosecondo = 10-12 secondi) Esempi: TS1 TIMESTAMP(0) TS2 TIMESTAMP(9) TS3 TIMESTAMP(12) CURRENT TIMESTAMP(12) La lunghezza della colonna varia di conseguenza Per i dettagli: si veda il Redbook SG24-7892 33 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 34 17

Premessa Batch = elaborazione di massa Elaborazione di massa richiama in modo connaturale elaborazione di insiemi / set processing Set Processing Uno dei cardini del Modello Relazionale Fonte di continui progressi funzionali e prestazionali nell implementazione dei sistemi e del linguaggio SQL Le varie forme di Prefetch e Block Fetch Query Parallelism Multi-row fetch OLAP Specification Inibitori Applicazioni Batch che pretendono di operare come applicazioni OLTP 35 Sintomi Elaborazione guidata da file sequenziale Elevato numero di SELECT INTO e/o elevato numero di OPEN CURSOR con pochissime FETCH per OPEN Spesso associato ad un limitato uso degli operatori relazionali Non infrequente un elevato numero di accessi a tabelle di pochi record Motivazioni addotte Riutilizzo del codice 36 18

Caso tipico di inapplicabilità Elaborazione guidata da file sequenziale SQL_CALL STMT SQL CPUPCT INDB2_TIME INDB2_CPU GETPAGE -------- ------- --------- ------- ------------ ------------ -------- SELECT 0005103 13676256 47.77% 01:40:18.094 02:56.577296 8941179 SELECT 0004771 11320907 40.53% 19:49.657642 02:29.812458 8348682 SELECT 0003826 1641730 7.82% 06:40.676105 00:28.905415 3647381 OPEN 0004846 221613 2.51% 00:22.988164 00:09.285109 638606 FETCH 0004874 795415.96% 00:08.288251 00:03.549874 0 CLOSE 0005048 221613.21% 00:01.728707 00:00.788970 0 SELECT 0004548 12495.11% 00:11.031098 00:00.429413 55388 OPEN 0004334 1265.03% 00:04.849223 00:00.115000 8823 FETCH 0004362 16049.02% 00:00.185866 00:00.087877 0 SELECT 0004035 1871.00% 00:01.110174 00:00.028994 878 CLOSE 0004615 1265.00% 00:00.009167 00:00.004745 0 37 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Nuovi costrutti SQL Generazione di Chiavi di Univocità: Oggetto SEQUENCE Temporary Table Stored Procedure Extended Indicator Variable 38 19

Integrato in alcuni programmi di utilità utilità Es. DSNTIAUL Operano con valore di default = 100 Ogni FETCH legge 100 righe Punto di massimo vantaggio Vantaggi Mediamente, 50% ca. di riduzione del consumo di CPU Su letture di milioni di record per OPEN di cursore Pre-requisiti requisiti Set Processing Modifiche al codice applicativo 39 Un unico statement di INSERT può inserire una molteplicità di righe (<32,768) da un array Opzioni: ATOMIC: se va male l inserimento anche di una sola riga, tutto lo statement fallisce NOT ATOMIC: ciascuna riga trattata separatamente dale altre Lo statement GET DIAGNOSTICS fornisce informazioni diagnostiche per ciascuna riga per la quale l inserimento non è andato a buon fine L SQLCODE indica se L inserimento non è andato a buon fine per nessuna riga L inserimento è andato a buon fine per tutte le righe L inserimento non è andato a buon fine per almeno una riga 40 20

Ci si può aspettare fino al 40% di riduzione del consumo di CPU Minore se maggiore è il numero delle colonne e/o il numero degli indici Maggiore al crescere del numero delle righe inserite per statement di Insert 41 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioneidei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Nuovi costrutti SQL Generazione di Chiavi di Univocità: Oggetto SEQUENCE Temporary Table Stored Procedure Extended Indicator Variable 42 21

Pre-requisiti requisiti Elaborazione per insiemi / query gravosa Tabelle partizionate Disponibilità di risorse hw (macchina non satura) Attivazione SQL statico Attivabile al BIND tramite opzione DEGREE (ANY) SQL dinamico Attivabile tramite comando SQL SET CURRENT DEGREE = ANY (oppure :hostvar impostata al valore ANY ) Vantaggi Parte del consumo (non solo DRDA) scaricato su ziip Miglioramento dei tempi di esecuzione Trasparenza applicativa Cfr. Riferimenti [4] 43 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazione dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Nuovi costrutti SQL Generazione di Chiavi di Univocità: Oggetto SEQUENCE Temporary Table Stored Procedure Extended Indicator Variable 44 22

SQL_CALL STMT SECT SQL CPUPCT INDB2_TIME INDB2_CPU -------- ------- ----- --------- ------- ------------ ------------ FETCH 0006943 00002 36380455 61.43% 03:14.944890 02:33.245450 OPEN 0004053 00002 403910 26.34% 01:28.554185 01:05.707429 SELECT 0007088 00011 403910 3.83% 00:12.454234 00:09.571059 FETCH 0007144 00004 807836 2.63% 00:08.712145 00:06.562709 FETCH 0007120 00003 807828 2.55% 00:08.419207 00:06.373773 OPEN 0005797 00003 403910.79% 00:02.534090 00:01.974218 OPEN 0006305 00004 403918.74% 00:02.356381 00:01.845975 CLOSE 0006588 00002 403910.57% 00:01.847810 00:01.436934 La OPEN 4053 e le FETCH 6943 operano su una tabella di 14.966 righe Oltre 36,3 milioni di Fetch Mediamente, ogni riga viene letta ca. 2.430 volte! Evitabile, senza stravolgere l architettura dell applicazione? 45 Letture duplicate: evitabili? Sort del file guida sulla base dei criteri di ricerca Se i criteri di ricerca non cambiano, i dati sono già nelle aree di memoria del programma 1234fr345 3245pr543 5639tr321 1847 bdf5678798 1847 jkefhy7980 1849 kjfh769i89j. oldkey = 0000 newkey = 1234 IF oldkey <> newkey do EXEC SQL SELECT C1, C2, C4 INTO :c1, :c2, :c3 FROM T1 WHERE K = :newkey ** test SQLCODE MOVE newkey to oldkey enddo 46 23

E se non è possibile pre-ordinare il file guida sulla chiave di ricerca? Alternative 1. Provare comunque ad utilizzare la tecnica appena indicata anche in assenza di ordinamento ottimale 2. Pre-caricare la tabella in memoria e effettuare ricerche binarie 47 Disponibile in Cobol da diversi lustri SEARCH - ricerca seriale (Attenzione ai costi!) SEARCH ALL ricerca binaria Consumi Per tabelle di cardinalità > 1000, fino a due ordini di grandezza di risparmio rispetto ad una SELECT INTO Pre-requisiti requisiti 1. La tabella deve presentare un criterio di univocità 2. Deve essere caricata in memoria ordinata secondo tale criterio 3. La ricerca deve prevedere predicati di uguaglianza in AND logico su tutte le colonne della chiave di univocità 4. La dimensione della tabella deve essere compatibile con al disponibilità di memoria 48 24

http://shaddy-ethical-hacking.blogspot.it/2013/05/a-c-program-to-binary-search-any-element.html 49 Se la ricerca Non qualifica tutte le colonne della chiave di univocità Qualifica una o più colonne con predicato di range Deve reperire più di una riga Opzioni Ricerca binaria su valore minimo del predicato di range o della colonna priva di predicato (se noto ); oppure Assegnazione di una chiave di univocità surrogata (v. esempio alla pagina successiva) 50 25

Caso tipico Ricerca del valore corrente ad una certa data Tasso di interesse Costo o prezzo di vendita di un articolo Ecc. Struttura dati essenziale KEY Chiave naturale INI_VAL Data di inizio validità END_VAL - Data di fine validità Valore - Dato di interesse Ricerca del VALORE in vigore alla data di interesse SELECT VALORE FROM T1 WHERE KEY =? AND INI_VAL <=? AND END_VAL >? 51 Il programma carica in memoria il risultato della query seguente SELECT KEY, ROW_NUMBER() OVER(PARTITION BY KEY ORDER BY END_VAL ASC ) AS ROWNUM, INI_VAL, END_VAL, VALORE FROM TABLE DESC ORDER BY KEY, 2 52 26

Il programma, invece di interrogare il DB2 esegue una ricerca binaria per uguaglianza sul valore di KEY di interesse e RWNUM =1 Prosegue con una ricerca sequenziale del dato di interesse (predicati temporali) fino a rottura di KEY Efficienza garantita se il numero medio di righe per chiave naturale (KEY, nell esempio) ) è almeno di un ordine di grandezza inferiore alla cardinalità di KEY Es. Card di KEY = 1.000; Table Card = 10.000 53 Esempio Tabella con chiave di univocità su (C1, C2, C3) Esigenza: Reperire tutte le righe on valori noti per C1 e C3 Caricamento in memoria da tabella DB2 tramite SELECT * FROM (SELECT T.*, ROW_NUMBER() OVER(PARTITION BY C1,C3 ORDER BY C2) AS ROW_NUM FROM TABC123 T ) AS X ORDER BY C1, C3, ROW_NUM Note: 1. (C1, C3, ROW_NUM) è chiave di univocità 2. Tecnica applicabile anche se (C1, C2, C3) non è chiave di univocità 54 27

Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row e linguaggio SQL Temporary Table Extended Indicator Variable 55 Fetch First n Rows Only Indica al DB2 che l applicazione è interessata solo alle prime n righe dell answer set Originariamente utilizzabile solo nell outer SELECT Ora (dal DB2 9) utilizzabile anche nelle sub-select Fetch First 1 Row Utilizzare nelle SELECT INTO che potrebbero restituire più di una riga Utilizzare nella definizione dei cursori dai quali si leggerà sempre solo la prima riga Trasformare questi cursori in SELECT INTO Utilizzare quando la SELECT INTO è interessata alla riga più recente o più vecchia, evitando la sub- Select 56 28

SELECT FROM MYTABLE A WHERE A.COL1 = :H1 AND AND A.COLX = ( SELECT MAX ( B.COLX ) FROM MYTABLE B WHERE B.COL_1 = :H1 AND ) SELECT FROM MYTABLE A WHERE A.COL1 = :H1 AND ORDER BY COLX DESC FETCH FIRST 1 ROWS ONLY 57 Optimize For n Row Un indicazione all Ottimizzatore per privilegiare la strategia di accesso meno costosa per il reperimento delle prime n righe L applicazione può comunque recuperare tutte le righe di interesse dell answer set Optimize For 1 Row (modifiche del DB2 10) Simile al comportamento pre DB2 10, ma il DB2 evita di prendere in considerazione qualunque strategia di accesso, anche se meno costosa, che comporti una fase di sort La strategia scelta può risultare più costosa delle attese L Apar PM56845 permette di operare come pre DB2 10 Alternativa suggerita, se non si usa l opzione dell apar PM56845 OPTIMIZE FOR 2 ROWS 58 29

Permette di condizionare l esecuzione di Insert e Update di una tabella a partire da un elenco di variabili o un array di variabili Quando le condizioni imposte sono verificate, si esegue l Update Quando le condizioni non sono verificate, si esegue l Insert Provoca l esecuzione di eventuali Trigger di Update / Insert La sequenza di esecuzione di Update / Insert può avere un impatto sulle prestazioni Questa implementazione è meno potente di uella resa disponibile dal DB2 for LUW, che permette Una subselect come input all operazione di Merge L esecuzione condizionata di Update, Insert e Delete 59 MERGE INTO items AS T USING (VALUES (:item_id, :qty)) AS N(id, qty) ON T.id = N.id WHEN MATCHED THEN UPDATE SET qty_on_hand = T.qty_on_hand + N.qty, T.upsert_ts = current timestamp WHEN NOT MATCHED THEN INSERT (id, qty_on_hand, upsert_ts) VALUES (N.id, N.qty, current timestamp) Si veda un esempio con un array come input in Materiale di Riferimento [3] 60 30

Il DB2 V8 ha introdotto SELECT From INSERT Il DB2 V9 ha aggiunto SELECT From MERGE, UPDATE, DELETE FROM data-change-table-reference 61 SELECT FROM INSERT Già disponibile con il DB2 V8 Esempio SELECT id, qty_on_hand, upsert_ts, row_nr FROM FINAL TABLE (INSERT INTO items ( id, qty_on_hand) INCLUDE (row_nr SMALLINT) VALUES (101, 100, 1),(102, 200, 2)) ORDER BY row_nr; 62 31

SELECT FROM UPDATE SELECT id, qty_on_hand, upsert_ts FROM FINAL TABLE (UPDATE items SET qty_on_hand = qty_on_hand + 100, upsert_ts = current timestamp WHERE id = 12345) ; SELECT FROM DELETE SELECT id, qty_on_hand, upsert_ts FROM OLD TABLE (DELETE FROM items WHERE id = 12345) ; 63 SELECT * FROM FINAL TABLE ( MERGE INTO items AS T USING (VALUES (:item_id, :qty)) AS N(id, qty) ON T.id =N.id WHEN MATCHED THEN UPDATE SET qty_on_hand = T.qty_on_hand + N.qty, T.upsert_ts= current timestamp WHEN NOT MATCHED THEN INSERT(id, qty_on_hand, upsert_ts) VALUES (N.id, N.qty, current timestamp) ) 64 32

TRUNCATE table Un alternativa efficace ed efficiente a DELETE FROM table LOAD REPLACE con input vuoto (dummy) Ise la tabella è una base table, vengono TRUNCATEd anche eventuali porzioni di tipo LOB e XML, e tutti gli indici associati Sintassi 65 DROP STORAGE (default) Tutto lo spazio disco assegnato alla tabella viene liberato e reso disponibile alla medesima tabella o ad altre tabelle residenti nel medesimo Tablespace REUSE STORAGE Tutto lo spazio disco assegnato alla tabella viene svuotato, ma continua ad essere asegnato alla tabella IGNORE DELETE TRIGGERS (default) Auto-esplicativo RESTRICT WHEN DELETE TRIGGERS Restituisce un errore se sulla tabella è definito almeno un Trigger di Delete IMMEDIATE ROLLBACK non ha effetto; se omesso, in caso di ROLLBACK viene ripristinata la situazione iniziale 66 33

Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 67 Temporary Table Utili quando si ha la necessità di memorizzare delle informazioni solo per la durata della transazione Due tipi di Temporary Table CGTT (Created Global Temporary Table) No logging, no locking DGTT (Declared Global Temporary Table) «Limited logging», «limited locking» 68 34

Caratteristiche e limiti Definizione tramite comando CREATE GLOBAL TEMPORARY TABLE No valori di default diversi da NULL No LOB o ROWID Nessun tipo di constraint (Ref. Integrity, ecc,) Struttura condivisa No logging No locking Nessuna possibilità di definire indici Update non permessi Delete permessi solo se privi della clausola WHERE Istanziazione Copia privata istanziata al primo riferimento da uno statement SQL di Delete, Insert, SELECT o OPEN Cursor 69 Commit If no pending «WITH HOLD» open cursor, all rows of every temporary table of the application process are deleted If also RELEASE(COMMIT) in effect, all logical work files for every temporary table are also deleted Rollback all rows and all logical work files of every temporary table of the application process are deleted. 70 35

Uso Quando si ha necessità di memorizzare dati solo per la durata di un processo applicativo e non si ha necessità di condividere la struttura della tabella Definizione Tramite comando DECLARE GLOBAL TEMPORARY TABLE L istanza è nota solo all applicazione che l ha definita La definizione non è memorizzata nel Catalogo DB2 ed esiste solo finchè è attivo il pocesso applicativo che l ha creata Implicitamente (o esplicitamente) qualificata con SESSION Istanziazione Una copia vuota quando viene eseguito il comando DECLARE GLOBAL TEMPORARY TABLE 71 Opzioni di COMMIT DELETE ROWS Applicata se nessun cursore con WITH HOLD è aperto sulla DGTT PRESERVE ROWS DROP TABLE Applicata se nessun cursore con WITH HOLD è aperto sulla DGTT Molti meno vincoli rispetto alle CGTT Colonne con valori di default Possibilità di definire indici Supporto di UPDATE e DELETE con predicati Supporto di SAVEPOINT Ecc. 72 36

Created GTT Declared GTT Definizione DBA tramite CREATE Utente tramite DECLARE Memoria nel Catalogo Si No Valori di default Solo NULL Si Colonne LOB e ROWID Non permesse Permesse Struttura Condivisa Non condivisa Logging Locking Definizione di indici No No Non permessa Limitato Limitato Permessa SQL Update Non permesso Permesso SQL Delete Solo senza WHERE Permesso Supporto SAVEPOINT No Si Opzioni di Commit Nessuna - righe cancellate in assenza di cursore WITH HOLD aperto DELETE / PRESERVE ROWS DROP TABLE 73 Statement SQL: Costi di riferimento EXPLAIN: Prevenire è meglio che curare Ricerche generiche: Tecniche da evitare e loro alternative NULL: Uso e abuso Architettura Batch e ottimizzazioni Multi-row Fetch / multi-row Insert Query Parallelism Ricerca binaria (aka ( dicotomica) Ulteriori ottimizzazioni dei consumi di CPU Fetch 1 Row Only; Optimize For 1 Row Temporary Table Extended Indicator Variable 74 37

Il dilemma degli sviluppatori Come predisporre del codice capace di gestire tutte le operazioni di UPDATE e INSERT di una tabella, non sapendo fino al momento dell esecuzione quali colonne inserire o aggiornare. Tutti gli approcci in uso sono insoddisfacenti Costruzione dinamica dello statement SQL Codifica in anticipo di tutte le possibili combinazioni di statement SQL Codifica di un unico statement SQL in grado di gestire tutte le possibili combinazioni di colonne 75 Permette di specificare 1. Che per una o più colonne oggetto di Insert, Update o Merge non viene fornito nessun valore 2. Come il DB2 deve trattare i valori mancanti L uso può essere abilitato A livello del Package, tramite l opzione EXTENDEDINDICATOR dei comandi BIND e REBIND PACKAGE Per l SQL dinamico, tramite l attributo WITH EXTENDED INDICATORS dello statement PREPARE NOTE L impostazione modifica iil risultato dell esecuzione dello statement SQL 76 38

Quando un Indicator Variabile è usata in input, il valore assegnato condiziona il comportamento del DB2, come segue: -5 Valore di Default, se Extended Indicator Variable abilitata NULL, in caso contrario -7 Non impostata (= come se non presente nello statement), se Extended Indicator Variable abilitata NULL, in caso contrario -1, -2, -3, -4, or -6 NULL 0 o qualunque valore positivo La variabile contiene un vaore valido I valori diversi da -1 non vengono assegnati dal DB2 a (Extended) Indicator Variable usate in output 77 Per INSERT I valori -5 e -7 conducono allo stesso risultato, perché la semantica dell Insert è quella di impostare la colonna a NULL o inserire un valore di default (a seconda della definizione adottata) per ogni colonna alla quale non è stato assegnato un valore Per UPDATE o MERGE UPDATE Il valore -5 provoca l aggiornamento della colonna al valore di default Il valore -7 fa sì che la colonna non venga aggiornata 78 39