Newsgroup: it.lavoro.informatica
Titolo: [REQ] - Manuali DB2

Ciao a tutti,
premesso che ho cercato di reperire informazioni su quello che sto 
cercando mi permetto di chiedere a voi:
Da qualche anno lavoro come programmatore Cobol+Db2+Cics per una ditta 
fornitrice di software per banche.
Mi sono tristemente accorto di mie lacune di base nell'utilizzo delle 
query.
Quindi sto cercando un manuale che mi possa aiutare a colmare questa 
lacuna, come penso abbiate capito essendo un programmatore vorrei 
evitare quei manuali completissimi ma dispersivi che mi spiegano tutto 
il db2 (comprese informazioni di interesse soprattuto per un 
sistemista) e invece puntare su un manuale piu diretto ad un 
programmatore.
Considerando peraltro il fatto che con il lavoro la "scrittura" della 
query non ï¿œ sostanzialmente un problema mi interesserebbe in ultima 
analisi un manuale che mi insegni come ottimizzare le mie queries e 
che nello spiegarmi i "trucchi" me ne spieghi anche la logica che vi 
sta dietro.
Faccio un esempio pratico: scrivo una query il boss si accorge che ci 
mette un secolo allora mi dice "definiamo un indice cosi e cosa" ecco, 
definito l'indice la query ci mette effettivamente solo 50 anni e non 
piu un secolo perï¿œ io non ho imparato nulla peche' non so la logica 
che vi sta dietro, non so perchï¿œ in questo modo ci mette meno tempo 
ecco vorrei qualcosa che mi dica per migliorare le prestazioni i passi 
sono i seguenti e che mi spieghi anche le motivazioni etc etc..
Logicamente sono ben accetti sia manuali in italiano che in inglese..
Grazie,
Saluti
A.
 

 sta dietro.
http://books.google.co.uk/books?id=1Fnf7C4JGsIC&printsec=frontcover&dq=oracle+tuning&ei=vIkrS5idMqnGywTw_MTQBA&client=firefox-a&cd=3#v=onepage&q=&f=false
Letto oltre 10 anni fa (forse addirittura la prima edizione, perchè la
copertina me la ricordo diversa).
Quello che ho imparato su quel libro l'ho poi usato non solo su
Oracle, ma su tutti gli altri DBMS con cui ho avuto a che fare.
Ovvio che ogni DBMS ha le sue particolarità (tante), ma certi concetti
sono utili in generale. Immagino ci sarà comunque qualcosa di simile
per DB2.
--
ale
http://ale.riolo.co.uk

 A.
scusa ma da un paio di anni sei COBOL CICS DB2 e ti manca la parte
DB2???, scommetto che di CICS sai solo quelle 4 istruzioni che ti
servono "exec sql, exec cics, return transid ecc"???
niente JCL???
comunque a parte il mio stupore di definirti DB2 (non so CICS, ho
fatto una deduzione), non voglio essere in alcun modo offensivo, ti
serve imparare la teoria delle basi di dati, e se puoi cerca di
affiancarti al dba dove lavori.
per venire al tuo esempio, si crea un indice per come dice la parola
stessa indicizzare una tabella in riferimento ad un campo, fare una
ricerca sugli indici indica al dbms di andare a cercare il record non
sulla tabella stessa ma su una partizione del db dove è memorizzato
l'indice e poi andare a colpo sicuro sul record della tabella, questo
ha il vantaggio che il dbms non deve scorrere riga per riga l'intera
tabella, ma ci arriva a colpo secco.
mettere troppi indici, equivale ad non metterne nessuno, fare una
where condition dove non si utilizza l'indice equivale a scorrere la
tabella riga per riga(table scan), effettuare join su campi di tabelle
senza indice equivale a "castrare" la query, strutturare le query in
maniera che prima vengono utilizzate le condition con gli indici e
dopo senza, ricorda che il db2 prima esegue le subselect e poi
l'intera select, quindi se hai una query del tipo :
select x.bla, x.bla1, x.bla2
  from
     (select bla1,
                bla2,
                bla3
       from tabella
     where x = y
        and z=w ) x,
     (select bla1,
                bla2,
                bla3
       from tabella1
     where xy > 12) y
where x.bla1 = 'valore'
and x.bla1 like '%prova%'
ricorda che prima viene eseguita le query interne, quindi le query
tabella(x) e tabella1(y) poi la query generale, ricorda che la like
uccide un dbms se il campo non è indice in quanto non solo si deve
scorrere la tabella (in questo caso il risultato della query) riga per
riga, ma ne deve anche esaminare il contenuto per vedere se
corrisponde alla condizione.
l'SQL è un liguaggio che interpreta la teoria degli insiemi (logica
matematica)
di manuali parti da qualsiasi testo che spieghi la teoria degli
insiemi, teoria sulla base di dati, poi SQL (ansi 92 per l'sql
standard, e poi concentrati sulle particolarità del DBMS che utilizzi)
per la teoria degli insiemi puoi anche partire da wikipedia
http://it.wikipedia.org/wiki/Teoria_degli_insiemi
per la teoria di base di dati 
http://fondamentidibasididati.it/
 (
per sql ansi 92 
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
per DB2 va benissimo (ci ho studiato) l'help in linea che trovi
sull'MVS che utilizzi.
Ciao

 and x.bla1 like '%prova%'
mi scuso, nella query precedente l'esecuzione comporta un prodotto
cartesiano (ogni riga di x viene ripetuta per le righe di y) non
avendo nessun campo di confronto x=y.
ciao

 programmatore.
L'ottimizzazione delle prestazioni spesso non può prescindere da una
buona conoscenza del modo di funzionare del db.
Voglio dire, è difficile ottimizzare una query senza avere un minimo
di conoscenza più sistemistica e meno di programmazione.
Tanto che, al limite, tu potresti scrivere le query in modo
"ingenuo",  fartele ottimizzare da qualcuno più esperto, e poi
riportarle ottimizzate pari pari nei tuoi programmi.

 sull'MVS che utilizzi.
Perfetto grazie per i consigli..

 riportarle ottimizzate pari pari nei tuoi programmi.
posso chiederti che ci azzecca il sistemista con il db???
in quel caso ti serve un DBA, non certo un sistemista.
Ciao

 in quel caso ti serve un DBA, non certo un sistemista.
Si, è più affare del Dba. Che d'altronde è una "sottospecie" (nel
senso di classificazione scientifica) di sistemista ;-)



scusarsi per il quoting alla cazzo è fuori discussione suppongo...
S.

 S.
se ti riferisci all'intero quote, invece della parte di query, hai
ragione, ma se ti riferisci al quote della sola query, dove è che ho
quotato alla cazzo???
ho quotato la parte di query e aggiunto una where condition
Ciao

 Ciao
se, come spero, accetti le mie scuse, ammetto di aver preso un colossale 
granchio.
my bad, sorry :-)

Stefano Zamboni ha scritto:

non c'è bisogno di scusarsi, è che non sapevo se avevo veramente quotato 
alla pene di segugio e chiedevo dove avessi sbagliato (ho pensato 
all'intero quoting e che ripetevo successivamente una parte di esso) 
comunque una critica e autocritica al fine di migliorare ci può anche 
stare, anche se hai preso un granchio. :)
Ciao

 A.
Dipende tutto dal livello di ottimizzazione che vuoi ottenere. Se come
dire non c'è un livello di ottimizzazione elevato puoi tenere a mente
alcune semplici regole:
1)mettere gli indici secondo la regola del 95/5 ossia se la tua query
tira fuori un numero di righe pari o meno del 5% del numero di righe
(record) totali allora conviene mettere un indice su quel campo
2)Non usare between ma cercare di limitarne l'uso. Ad esempio io
dovevo fare una ricerca usando un between su un certo range e  la
query era lentissima(si parla di 5 ore di tempo). al che capendo che
era quello il collo di bottiglia ho pensato di scrivermi una procedura
pl/sql che splitta il range in valori successivi cioè voglio dire se
devo valutare se un mio campo è compreso tra 1 e 10, con 1 e 10 che
sono però non due numeri ma due altri campi, si fa molto prima a
splittare 1 e 10 in 10 righe anzichè una sola riga in modo tale da
usare poi una condizione di uguaglianza sul campo piuttosto che una
between. In tal modo sono passato da 5 ore a 1 minuto come velocità di
esecuzione.
3)Per lo stesso motivo cercare di limitare l' uso di like.
4)Non usare not in e sostituirlo con una outer join
5) stessa cosa per exists
Direi che con queste regole ottieni già un discreto miglioramento
delle performance. Se poi vuoi vedere quale è l' impatto delle
modifiche che fai, ad esempio tramite l' aggiunta di indici,
analizzati la tabella in cui si vede il percorso compiuto dall'
ottimizzatore nell' esecuzione della query. Se nonostante tu hai messo
gli indici ti ritrovi con un full table scan vuol dire che hai
sbagliato qualcosa.

 performance. 
io direi invece di partire analizzando l'execution plan della query 
invece di mettersi a tirare a caso come di fatto suggerisci tu.

 5) stessa cosa per exists
Dipende dalla query e dal DBMS.
Ad esempio su varie versioni di Oracle, usando in maniera opportuna
exists invece che join, sono spesso riuscito a diminuire il tempo di
esecuzione medio di query complesse (report su OLTP-oriented database,
per cui bisogna stare attenti all'introduzione di indici) anche di 2
ordini di grandezza (tieni conto che lavoro da anni su un sistema con
centinaia se non migliaia di installazioni, spesso quando modifichiamo
una query per questioni prestazionali magari andava già benissimo per
il 99% dei clienti, ma l'1% ha esigenze particolari, e la modifica
ovviamente la testiamo su n database di prova differenti, sia Oracle
che Sql Server, varie versioni). Ovvio che in alcuni casi è meglio
usare i join, ma non è generalizzabile. Al solito, explain_plan e
tkprof sono i tuoi migliori amici, per fare tuning su Oracle.
--
ale
http://ale.riolo.co.uk

invece di mettersi a tirare a caso come di fatto suggerisci tu.
Chi parla senza conoscere anche a livello elementare le istruzioni sql
mi pare sei tu. Senza polemica, al contrario tuo. D' altronde,
parlando in generale senza riferirmi assolutamente a te, uno meno sa,
più pensa di sapere e di conseguenza è più arrogante.

 di sapere e di conseguenza è più arrogante.
ma smettila di fare la verginella violata...

 ma smettila di fare la verginella violata...
Dai rootkit si può discutere senza arrabbiarsi? Sei tu che non so
quale motivo mi hai attaccato peraltro su cose che credo siano
scontate, non perchè le dico io ma perchè si trovano in qualunque
manuale base.

 sbagliato qualcosa.- Nascondi testo citato
Esistono gli Explai Plan che ti danno tutte le regole correntemente
seguite dall'ottimizzatore.
Non è raro il caso di scoprire che non usa un indice, pur se
esistente, perchè il db non persegue l'obiettivo di limitare il tempo
di esecuzione ma altri obiettivi, ad es. mimimizzare l'uso della
memoria. In tali casi si forza ll'uso dell'indice con opportuni hints
per l'ottimizzatore.
Ho queste eseprienze su Oracle, ma non dubito che sia la stessa cosa
sugli altri db.

 fornitrice di software per banche.
in quale città?
--
FabMind