Best Practices Hints & Tips e Novità SQL

Transcript

1 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

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 3 Ipotesi Processore da Mips Ignorato effetto MP Dati indicativi SQL Statement Consumo di CPU minimo (microsec ( microsec.) Istruzioni equivalenti SET :h = CURRENT DATE SELECT INTO :h FETCH 1 riga Multi-row FETCH 100 righe

3 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

4 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

5 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

6 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 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

7 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

8 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

9 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 : 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 <> OR ( C10 = 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 :

10 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 <> OR ( C10 = AND C11 <> XXXXXXXXX' )) ), TEMP2 AS (SELECT COUNT(*) AS CONTA FROM TEMP1) SELECT T1.*, T2.CONTA FROM TEMP1 T1, TEMP2 T

11 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 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

12 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

13 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

14 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

15 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

16 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 HIGH-END = (standard Java e SQL ISO/ANSI Temporal Support) oppure 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 ' ' -- valid date (ISO format) DATE ' ' -- valid date (EUR format) DATE ' ' -- invalid date (bad year) DATE ' ' -- invalid date (bad day) TIME '24:00:00' -- valid time (JIS, ISO format) TIME '24:00:01' -- invalid time (bad hour) TIME ' ' -- valid time (EUR format) TIME '12:01 AM' -- valid time (USA format) TIMESTAMP ' :55: ' -- valid (space and colons) Raccomandazione: specificare DATE invece di DATE( 2010 ( ) 06 ) per migliorare la portabilità e, forse, anche le prestazioni Evitare codifiche del tipo WHERE CHAR(data, ISO) = :h 32 16

17 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 = 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 SG 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

18 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

19 Caso tipico di inapplicabilità Elaborazione guidata da file sequenziale SQL_CALL STMT SQL CPUPCT INDB2_TIME INDB2_CPU GETPAGE SELECT % 01:40: : SELECT % 19: : SELECT % 06: : OPEN % 00: : FETCH % 00: : CLOSE % 00: : SELECT % 00: : OPEN % 00: : FETCH % 00: : SELECT % 00: : CLOSE % 00: : 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

20 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

21 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

22 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

23 SQL_CALL STMT SECT SQL CPUPCT INDB2_TIME INDB2_CPU FETCH % 03: : OPEN % 01: : SELECT % 00: : FETCH % 00: : FETCH % 00: : OPEN % 00: : OPEN % 00: : CLOSE % 00: : La OPEN 4053 e le FETCH 6943 operano su una tabella di righe Oltre 36,3 milioni di Fetch Mediamente, ogni riga viene letta ca 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 1234fr pr tr bdf jkefhy 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

24 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

25 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

26 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,

27 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 = 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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