Estrema lentezza query eseguite da programmi Java

[Scorpio]

Salve ng,

il subject del mio post credo sia uno di quegli argomenti che " a volte
ritornano "...
Dunque il problema è questo, per farla breve. Devo eseguire delle query su
alcune tabelle db2/400 e i tempi di risposta purtroppo sono spesso
"biblici", almeno se confrontati con i tempi di accesso ai dati dei
programmi nativi RPG. Ora, so che è come comparare le pere con le mele (RPG
accede nativamente al file, le query ovviamente passano attraverso l'engine
Db2), però chiedo lo stesso lumi a voi che senz'altro ne sapete più di me...

Le query molto spesso non sono complicate, sono del tipo SELECT * FROM
TABELLA WHERE KEY = X,
e ragionevolmente non credo possano essere ottimizzate :-). Va detto, a onor
del vero, che tabella può contenere centinaia di migliaia di righe, e che
possono essere accedute, simultaneamente, anche da programmi 5250 (e questo
penso che possa impattare).

Abbiamo spesso sostituito TABELLA con una VISTA opportuna tenendo conto
dell'indicizzazione di KEY, ma i benefici, in termini di tempo di risposta,
anche se presenti sono minimali.

Non so che pesci pigliare: qualche consiglio ?

Grazie ancora !

Scorpio.

[Stefano P.]

Post by Scorpio
Salve ng,

Ciao :-)

Post by Scorpio
il subject del mio post credo sia uno di quegli argomenti che " a volte
ritornano "...
Dunque il problema è questo, per farla breve. Devo eseguire delle query su
alcune tabelle db2/400 e i tempi di risposta purtroppo sono spesso
"biblici", almeno se confrontati con i tempi di accesso ai dati dei
programmi nativi RPG. Ora, so che è come comparare le pere con le mele (RPG
accede nativamente al file, le query ovviamente passano attraverso l'engine
Db2), però chiedo lo stesso lumi a voi che senz'altro ne sapete più di me...

Più che altro dovresti comparare con sql eseguito da AS, cioè sql
interattivo o sql "embedded" in programmi...

Post by Scorpio
Le query molto spesso non sono complicate, sono del tipo SELECT * FROM
TABELLA WHERE KEY = X,
e ragionevolmente non credo possano essere ottimizzate :-).

Ma, la faccio corta, se non hai indici sul campo KEY allora quasi
sicuramente costringi la macchina ad un full scan table :-|
Se li hai (file logici con select e/o omit) il nuovo ottimizzatore
potrebbe ignorarli...

Post by Scorpio
Abbiamo spesso sostituito TABELLA con una VISTA opportuna tenendo conto
dell'indicizzazione di KEY, ma i benefici, in termini di tempo di risposta,
anche se presenti sono minimali.

Prima cosa: NON usare la select from vista logica (creata con dds, con
select e/o omit, ma crea una view equivalente:
usa il Navigator per generare la view equivalente ;-)

Post by Scorpio
Non so che pesci pigliare: qualche consiglio ?

Do per scontato che sei almeno a V5R2 (con le ptf per il nuovo
ottimizzatore, l'sqe), meglio ancora V5R3 o R4:
visto che avete file logici (con l'rpg tradizionale è inevitabile),
inizia a cambiare il qaqqini,
update qusrsys/qaqqini set qqval = '*YES' where qqparm =
'IGNORE_DERIVED_INDEX'
(vado a memoria, magari lunedì ricontrollo),
ciò ti permetterà di sfruttare meglio i file logici a chiave.

Poi, se non sei a V5R4, prendi il dbmon del lavoro che gestisce la
connessione odbc ed analizzalo col Visual Explain (se non sai di cosa
parlo allora un altro post sarà indispensabile); questo si poteva già a
V4R3...
Se invece sei a V5R4 allora la plan cache sarà tua amica: è fantastico
quano tempo fa risparmiare in questi casi! :-)

Comunque, tramite Navigator (almeno da V5R3, forse già da V5R2), puoi
effettuare la "simulazione" della query senza farla davvero (il
risparmio di tempo e di risorse del server è notevole) e scoprire cosa
ti serve :-)

Post by Scorpio
Grazie ancora !
Scorpio.

HTH,
buon fine settimana
Stefano P.

[Scorpio]

Post by Stefano P.
Prima cosa: NON usare la select from vista logica (creata con dds, con
usa il Navigator per generare la view equivalente ;-)

Interessante.. mi spieghi il perchè di questo suggerimento ? Le viste create
con SQL sono diverse dalle viste create con DDS ?

[CUT]

Aggiungo che sono a V5R2. Non capisco però come query semplici possano
essere
ottimizzate tramite i suggerimenti di Visual Explain....

Ciao e grazie,
Scorpio.

[Stefano P.]

Post by Scorpio

Post by Stefano P.
Prima cosa: NON usare la select from vista logica (creata con dds, con
usa il Navigator per generare la view equivalente ;-)

Interessante.. mi spieghi il perchè di questo suggerimento ? Le viste create
con SQL sono diverse dalle viste create con DDS ?

Si, una view (creata con sql, con il "ddl") è una definizione, che poi a
tempo di esecuzione determina cosa devi andare a selezionare;
un file logico tradizionale (con select e/o omit), invece, è un vero e
proprio percorso di accesso ai dati: se metti quello nella query il
sistema ti obbedirà... ma non sempre è il più adatto, anzi quasi mai lo
è :-|
(poi potrei mostrarti un esempio pratico di un caso nel quale ho dovuto
abbandonare l'idea di usare la view sostituente il logico ma è stata
l'eccezione e non la regola)

Post by Scorpio
[CUT]
Aggiungo che sono a V5R2.

A suo tempo uscì un aggiornamento del nuovo motore dell'sql (l'sqe)
disponibile tramite apposite ptf, proprio per la V5R2; forse Tassi ne ha
segnato da qualche parte il riferimento... a suo tempo le ordinai
prontamente, se le ritrovo o ritrovo le informazioni relative te le
faccio avere.

Post by Scorpio
Non capisco però come query semplici possano
essere
ottimizzate tramite i suggerimenti di Visual Explain....

Tramite l'indicazione di indici da creare e - comunque - rendendo
disponibili le informazioni relative a come il sistema ha eseguito la query:
il Visual Explain è LO strumento per l'analisi delle performance del DB2
su i5/OS ;-)
Provare per credere...

Per altro forse già a V5R2 si poteva provare a simulare la query senza
eseguirla (da Navigator), avendo una buona stima della situazione;
nel tuo caso la stima è anche più indicativa che nei casi che seguo io,
in quanto il Navigator va di odbc (quindi credo acceda ai dati in
maniera analoga al jdbc) mentre io in genere faccio tuning su job che
sono in altri sottosistemi/pool di memoria e lavorano con jobd diverse.

Post by Scorpio
Ciao e grazie,
Scorpio.

Saluti
Stefano P.

[Scorpio]

Post by Stefano P.

Post by Scorpio

Post by Stefano P.
Prima cosa: NON usare la select from vista logica (creata con dds, con
usa il Navigator per generare la view equivalente ;-)

Interessante.. mi spieghi il perchè di questo suggerimento ? Le viste create
con SQL sono diverse dalle viste create con DDS ?

Si, una view (creata con sql, con il "ddl") è una definizione, che poi a
tempo di esecuzione determina cosa devi andare a selezionare;
un file logico tradizionale (con select e/o omit), invece, è un vero e
proprio percorso di accesso ai dati: se metti quello nella query il
sistema ti obbedirà... ma non sempre è il più adatto, anzi quasi mai lo è
:-|

[CUT]

Ti ringrazio per le informazioni. Ora come ora, lavoriamo su tabelle e viste
logiche
(create come DDS) a seconda del tipo di query che dobbiamo eseguire. Per
esempio,
per un file fisico F0, esiste sempre un certo numero di viste logiche (F1L,
F2L etc) - file "compilati", scusami il termine grezzo ma NON sono un
tecnico as400 - che almeno per RPG sono indicizzate rispetto ad una certa
chiave. Giusto oggi ho verificato se, per un certo file, Operation Navigator
mostrava degli indici collegati: risposta negativa: non esistono indici,
semplicemente viste logiche.

Se creassimo indici, pensi che potremmo avere migliorie nelle prestazioni ?
Se si parlasse di Oracle o SQLServer risponderei ad occhi chiusi "sì", su
As400 non so che pensare.

Grazie comunque di cuore per l'aiuto.
Scorpio.

[Stefano P.]

Post by Scorpio
[CUT]
Ti ringrazio per le informazioni.

Di niente, è un percorso che ho fatto anche io...

Post by Scorpio
Ora come ora, lavoriamo su tabelle e viste
logiche
(create come DDS) a seconda del tipo di query che dobbiamo eseguire. Per
esempio,
per un file fisico F0, esiste sempre un certo numero di viste logiche (F1L,
F2L etc) - file "compilati", scusami il termine grezzo ma NON sono un
tecnico as400 - che almeno per RPG sono indicizzate rispetto ad una certa
chiave.

Ok, è normale e - tanto per dire - ci siamo passati anche noi.

Visto che sei a V5R2 puoi fare 2 cose:
1) creare - il Navigator su richiesta lo fa - le viste (proprio le view
dell'sql) equivalenti ai logici che avete deciso di usare: immagino che
quei file logici (che - è vero - vanno "compilati") descrivano le
condizione di selezione e/o omissione (select/omit) che vi interessano;
ignorate l'ordinamento (che per altro nelle view non si può indicare), a
quello penserete con la clausola "order by" nella query;
2) modificare il file qaqqini come ti scrivevo nel post precedente: male
non fa e, soprattutto, quando si viene dalle applicazioni tradizionali è
praticamente indispensabile.

Poi prova a fare le query con le view al posto dei logici...

Post by Scorpio
Giusto oggi ho verificato se, per un certo file, Operation Navigator
mostrava degli indici collegati: risposta negativa: non esistono indici,
semplicemente viste logiche.

In genere nella tradizionale programmazione rpg (e cobol) + dds non si
possono generare index (le dds non li creano) ma solo "file logici",
ordinati secondo le chiavi indicate, quindi non c'è niente di strano:
non fartene un cruccio, il sistema sa usare anche i file creati con le dds.

Poi, per nostra comodità, view, index e file logici con ordinamento e/o
selezione/omissione sono tutti oggetti *file lf; ad usarli correttamente
pensa il "motore" dell'sql.

Post by Scorpio
Se creassimo indici, pensi che potremmo avere migliorie nelle prestazioni ?

"It depends" ;-)

Gli indici giusti, qualora "azzeccati" (ma c'è una logica per
determinare quali occorrano) possono fornire risultati a volte
spettacolari; di sicuro una corretta indicizzazione è indispensabile per
qualsiasi database e va mantenuta col crescere o col mutare del database
stesso.

Post by Scorpio
Se si parlasse di Oracle o SQLServer risponderei ad occhi chiusi "sì", su
As400 non so che pensare.

Anche il DB2 (e nello specifico quello per OS/400 o i5/OS che dir si
voglia) ha bisogno degli indici opportuni:
quali e quanti dipende dalle query e dal database sul quale le esegui (e
dalla macchina e dal carico di lavoro e dalla ram disponibile e...)

Apri il Run Sql Script del Navigator, incolla la tua query (sistemando
opportunamente le librerie) e aziona il Visual Explain...
...il sistema ti suggerirà se ha bisogno di indici.
Attenzione: magari poi non li usa ma gli servono per altri motivi ;-)

Impara a leggere il grafico del Visual Explain e a vedere dove poter
intervenire; l'Index Advisor spesso è la cosa che si guarda per prima ma
se proprio vuoi fare meglio occorre indagare più a fondo...

Post by Scorpio
Grazie comunque di cuore per l'aiuto.

Non preoccuparti, è una ruota: io sono stato introdotto ai segreti
esoterici delle performance del database dall'ottimo Stefano Tassi :-)
Poi, si sa, il compito dei bravi allievi è superare i maestri... ed io
cerco di applicarmi ;-)

Post by Scorpio
Scorpio.

Saluti e benvenuto nel simpatico mondo dei casini dell'sql :-)
Stefano P.

[Franco Lombardo]

Post by Stefano P.
2) modificare il file qaqqini come ti scrivevo nel post precedente: male
non fa e, soprattutto, quando si viene dalle applicazioni tradizionali è
praticamente indispensabile.

In realtà può fare male, soprattutto se vieni da applicazioni tadizionali e
non hai indici SQL.
In tal caso l'opzione impedisce di utilizzare come indici i file logici,
obbligando il sistema a dei table scan.
L'opzione e' utile quando tu abbia sia indici SQL che LF. A quel punto il
sistema trascura i LF, consentendo di fare elaborare la query dal moderno
motore SQE invece che dal più lento CQE. Ovviamente ciò porta ad un aumento
di prestazioni qualora gli indici SQL siano adatti alla tua interrogazione.

Ciao

Franco

[Stefano P.]

Ciao a tutti :-)

Premessa:
spero che questa discussione non diventi noiosa o improduttiva, comunque
vada credo che sia normale non poter risolvere un tale problema con una
sola risposta.

A mio modesto parere lo scenario può essere visto in molti modi (ognuno
di noi può vedere aspetti diversi), uno dei quali, imho, è il seguente:
sembrerebbe che dalle applicazioni che per brevità chiamo
"tradizionali", da Scorpio stiano passando ad usare l'sql; avendo appena
iniziato, non hanno ancora tutto quello che occorre, né gli index (per
dirne una) né una conoscenza approfondita dei problemi.
Sono anche, sempre a mio modesto parere, in (parte di) uno degli scenari
descritti nella "roadmap to modernization"...
...in questi casi non è immediato trovare una soluzione, men che meno
una soluzione immediata sul newsgroup: con questo in testa io provo a
suggerire qualcosa, ben sapendo - per esperienza personale - che per
arrivare a dei bei risultati *globali* (quindi non solo su una singola
query) ci vuole tempo e pazienza.

Post by Franco Lombardo

Post by Stefano P.
2) modificare il file qaqqini come ti scrivevo nel post precedente: male
non fa e, soprattutto, quando si viene dalle applicazioni tradizionali è
praticamente indispensabile.

In realtà può fare male, soprattutto se vieni da applicazioni tadizionali e
non hai indici SQL.

Se inizi ad usare l'sql, permettimi, allora ti tocca fare gli indici...
ed allora tanto vale farli ;-)
Senza esagerare, controllandone l'uso dopo la creazione ma tocca farli...


Inoltre, riconosco, più correttamente avrei dovuto suggerire:
crea un altro qaqqini, cambiagli quel parametro, fai chgqrya per quel
lavoro e vedi come reagisce (sempre col dbmon...)

Post by Franco Lombardo
In tal caso l'opzione impedisce di utilizzare come indici i file logici,
obbligando il sistema a dei table scan.

Mah, direi che - visti i tempi, probabilmente gli indici - se presenti -
non vengono usati comunque, già col qaqqini presumibilmente "standard".

Post by Franco Lombardo
L'opzione e' utile quando tu abbia sia indici SQL che LF. A quel punto il
sistema trascura i LF, consentendo di fare elaborare la query dal moderno
motore SQE invece che dal più lento CQE. Ovviamente ciò porta ad un aumento
di prestazioni qualora gli indici SQL siano adatti alla tua interrogazione.

Mah, errori vari di gioventù a parte (ma ho aperto chiamate anche per
errori del cqe), in generale la mia esperienza con sqe a V5R2 era di
performance migliori e questo già prima di iniziare a fare index...
...e comunque quella query va già piano, giusto?! :-)

Post by Franco Lombardo
Ciao
Franco

Con stima e simpatia
Stefano P.

[Scorpio]

Post by Stefano P.
Ciao a tutti :-)
spero che questa discussione non diventi noiosa o improduttiva, comunque
vada credo che sia normale non poter risolvere un tale problema con una
sola risposta.
A mio modesto parere lo scenario può essere visto in molti modi (ognuno di
sembrerebbe che dalle applicazioni che per brevità chiamo "tradizionali",
da Scorpio stiano passando ad usare l'sql; avendo appena iniziato, non
hanno ancora tutto quello che occorre, né gli index (per dirne una) né una
conoscenza approfondita dei problemi.
Sono anche, sempre a mio modesto parere, in (parte di) uno degli scenari
descritti nella "roadmap to modernization"...
...in questi casi non è immediato trovare una soluzione, men che meno una
soluzione immediata sul newsgroup: con questo in testa io provo a
suggerire qualcosa, ben sapendo - per esperienza personale - che per
arrivare a dei bei risultati *globali* (quindi non solo su una singola
query) ci vuole tempo e pazienza.

[Cut]

Ti correggo su un punto: sono 4/5 anni che stiamo usando WebSphere + Java
per diversissimi tipi di applicativi e progetti. Come le ciambelle, alcuni
hanno avuto un buon successo, mentri altri, beh, non sono uscite
propriamente con il buco. In questi anni mi sono preoccupato principalmente
di tutta quella parte relativa allo sviluppo J2EE. Che comprende,
ovviamente, anche e soprattutto - visto che si parla della modernizzazione
di un gestionale - diverse problematiche di accesso ai dati di AS400. Ora si
tratta di fare il "grande salto" e di scrivere un sistema che non sia solo
il corollario e il fratello povero del gestionale: le performance, che
potevano essere prima tollerabili, ora non lo sono più: ecco perchè stanno
venendo al pettine tutti i nodi che prima erano un po' messi da parte. Tardi
? Beh, vero. Meglio tardi che mai, però.
Ora si dovrà sgobbare, come & più di prima.

Intanto, ringrazio te e tutti coloro che hanno voluto darmi una mano: non
abbiamo ancora trovato la soluzione, forse non la troveremo tanto in fretta,
però le dritte sull'uso di indici etc etc sono state davvero illuminanti. E
non siate modesti, ragazzi : qui c'è gente che davvero sa di quel che
parla, e che non fa propaganda o marketing... vabbè, mi fermo qui sennò
deraglio, meglio che mi morda la lingua :-)

Scorpio.

[Stefano P.]

Post by Scorpio

sembrerebbe...

Il condizionale era d'obbligo ;-)
[cut]

Post by Scorpio
le performance, che
potevano essere prima tollerabili, ora non lo sono più: ecco perchè stanno
venendo al pettine tutti i nodi che prima erano un po' messi da parte.

Sia pur per altra via ci siamo arrivati pure noi:
ad un certo punto l'sql, che pure ci aveva semplificato molte cose,
"andava piano" ma non ne capivamo il perché :-|

Post by Scorpio
Tardi
? Beh, vero. Meglio tardi che mai, però.
Ora si dovrà sgobbare, come & più di prima.

Le analogie proseguono :-)
Se ci incontriamo ti chiederò di offrirmi un caffé :-)
(Ed io lo offrirò a Franco ;-)

Post by Scorpio
Scorpio.

Saluti
Stefano P.

[Franco Lombardo]

Stefano,

il mio post non voleva in alcun modo essere polemico. Chiedo scusa se ho
dato questa impressione. Volevo solamente precisare un dettaglio tecnico,
senza istigare nessuno a non creare indici :-).

Ciao

Franco

[Stefano P.]

Post by Franco Lombardo
Stefano,
il mio post non voleva in alcun modo essere polemico.

Non l'ho assolutamente inteso come tale!
Casomai posso essere stato un po' irruento io ma NON per motivi legati
al thread, grazie al quale (e a voi, ovviamente) mi sono sfogato un po'...

Post by Franco Lombardo
Chiedo scusa se ho
dato questa impressione.

A me non l'hai data quindi - per quanto mi riguarda - non occorrono
neanche le scuse ;-)
Semmai potrei essere io a dovermi scusare...

Post by Franco Lombardo
Volevo solamente precisare un dettaglio tecnico,
senza istigare nessuno a non creare indici :-).

Index aedificandum est! :-P

Post by Franco Lombardo
Ciao
Franco

Con simpatia e stima
Stefano P.

p.s.: come scrivevo in un altro post "ti devo" un caffè :-)

[stefano[dot]tassi[at]gruppopro[dot]it]

Post by Scorpio

Post by Stefano P.
Prima cosa: NON usare la select from vista logica (creata con dds, con
usa il Navigator per generare la view equivalente ;-)

Interessante.. mi spieghi il perchè di questo suggerimento ? Le viste create
con SQL sono diverse dalle viste create con DDS ?
[CUT]
Aggiungo che sono a V5R2. Non capisco però come query semplici possano
essere
ottimizzate tramite i suggerimenti di Visual Explain....
Ciao e grazie,
Scorpio.

la PTF (che abilita SQE) è la SI07650, *potrebbe* risolvere qualche
problema (in effetti SQE e' generalmente molto piu' performante di
CQE), ma, prima di incolpare il motore db2 prova ad analizzare se,
appunto, necessiti di indicizzazione.
Hai indici costruiti sulla tabella?
Che tipo di statement? e' veramente select * from x where a=b?

Saluti

[Scorpio]

Post by stefano[dot]tassi[at]gruppopro[dot]it
la PTF (che abilita SQE) è la SI07650, *potrebbe* risolvere qualche
problema (in effetti SQE e' generalmente molto piu' performante di
CQE), ma, prima di incolpare il motore db2 prova ad analizzare se,
appunto, necessiti di indicizzazione.
Hai indici costruiti sulla tabella?
Che tipo di statement? e' veramente select * from x where a=b?

Ciao,

grazie innanzitutto per aver risposto al mio post.
Dunque, come ho scritto nei post precedenti...da profano dell'AS400 non so
se gli indici o le viste create con DDS siano equivalenti. Da quanto mi
dicono i colleghi RPG, la risposta è SI. Da quanto le prove effettuate
sembrano confermare la risposta è NO.

Comunque, la query è davvero una select * from tabella where campo = 'XXXX'.
Non c'è trucco, non c'è inganno. Totale righe: circa 200.000; tempo di
risposta: circa un minuto (!) per estrarre circa 40, 60 record.

Ciao,
Scorpio.

[Stefano P.]

Post by Scorpio
Dunque, come ho scritto nei post precedenti...da profano dell'AS400 non so
se gli indici o le viste create con DDS siano equivalenti. Da quanto mi
dicono i colleghi RPG, la risposta è SI. Da quanto le prove effettuate
sembrano confermare la risposta è NO.

NON sono uguali:
gli index permettono performance migliori con sql in quanto il
"pagesize" è di 64 kb (mentre quello dei logici tradizionali è di 8 kb).

Da V5R4, poi, il pagesize si può impostare all'atto della creazione
dell'index...

Post by Scorpio
Comunque, la query è davvero una select * from tabella where campo = 'XXXX'.
Non c'è trucco, non c'è inganno. Totale righe: circa 200.000; tempo di
risposta: circa un minuto (!) per estrarre circa 40, 60 record.

Scommetto che il sistema ha dovuto fare un full table scan... (ma vista
l'ora posso sbagliare più che di giorno ;-)
Per saperlo con esattezza devi ottenere il database monitor dettagliato
ed analizzarlo col Visual Explain.

Prova a create un index con chiave "campo" (se la query è esattamente
quella che scrivi)... e rifai la query.

Post by Scorpio
Ciao,
Scorpio.

A domani
Stefano P.

[Franco Lombardo]

Post by Scorpio
Comunque, la query è davvero una select * from tabella where campo = 'XXXX'.
Non c'è trucco, non c'è inganno. Totale righe: circa 200.000; tempo di
risposta: circa un minuto (!) per estrarre circa 40, 60 record.

E tu hai un logico in cui hai specificato come _prima_ colonna "campo"? Mi
pare strano, a meno che non sia stato impostato 'IGNORE_DERIVED_INDEX' =
*yes.

Ciao

Franco

[Uomo Mascherato]

Post by Scorpio

Post by Scorpio
Comunque, la query è davvero una select * from tabella where campo =

'XXXX'.

Post by Scorpio
Non c'è trucco, non c'è inganno. Totale righe: circa 200.000; tempo di
risposta: circa un minuto (!) per estrarre circa 40, 60 record.

E tu hai un logico in cui hai specificato come _prima_ colonna "campo"? Mi
pare strano, a meno che non sia stato impostato 'IGNORE_DERIVED_INDEX' =
*yes.
Ciao
Franco

ma i programmi java come accedono al database? via driver ODBC o
mediante il driver nativo della toolbox? E quanto lungo è il record
della tabella (se fai select * e importi tutto il record può fare la
differenza..). e poi come usano il resultset? tutto in una unica
soluzione o per un numero limitato di record? in questo caso sarebbe
meglio limitare la select per il numero di record richiesto.

[Stefano P.]

[cut]

Post by Uomo Mascherato
e poi come usano il resultset? tutto in una unica
soluzione o per un numero limitato di record? in questo caso sarebbe
meglio limitare la select per il numero di record richiesto.

Vero, un bel
optimize for n rows
spesso è assai d'aiuto :-)


Ciao
Stefano P.

[Scorpio]

Post by Stefano P.
[cut]

e poi come usano il resultset? tutto in una unica soluzione o per un
numero limitato di record? in questo caso sarebbe meglio limitare la
select per il numero di record richiesto.

Utilizziamo sempre, come da "best practice" tecniche di paginazione dei
resultset. Ora non utilizziamo direttamente la classe ResultSet di Java,
diciamo che abbiamo costruito un wrapper che ci consente di ottenere una
struttura dati "sconnessa" per poter liberare subito, prima di qualunque
altra operazione, la connessione e le risorse correlate.

Otteniamo la paginazione con query ripetute del tipo:

SELECT * FROM TABELLA WHERE CONDIZIONE FETCH FIRST x ROWS ONLY

mentre

Post by Stefano P.
un bel
optimize for n rows

questa istruzione sinceramente non è mai applicata ( e peraltro non so che
faccia ). Il valore di x nella query precedente è calcolato sulla "pagina
richiesta": per esempio se una pagina ha 10 righe , si avrà una situazione
del tipo:

x=1 : record da 1 a 10
x=2 : record da 1 a 20
x=3 : record da 1 a 30


In questi casi, però, per ottenere coerenza dei dati aggiungiamo anche un
ORDER BY, che rallenta l'esecuzione della query.

Ignoro se la FETCH FIRST possa essere resa più efficace.

Scorpio.

[Stefano P.]

Post by Scorpio
SELECT * FROM TABELLA WHERE CONDIZIONE FETCH FIRST x ROWS ONLY

Ok, stai comunque indicando al sistema che subito ti occorrono x records
e non tutti:
i piani di accesso nei due casi (nessuna specifica quindi "tutti" oppure
"i primi n") saranno differenti.

Post by Scorpio

Post by Stefano P.
un bel
optimize for n rows

questa istruzione sinceramente non è mai applicata ( e peraltro non so che
faccia ).

Si usa in una select e "significa" che non vuoi avere tutti i records
risultanti subito ma ti interessa avere subito i primi n:
il piano di accesso risultante velocizzerà l'arrivo dei primi records...

Post by Scorpio
In questi casi, però, per ottenere coerenza dei dati aggiungiamo anche un
ORDER BY, che rallenta l'esecuzione della query.

Non preoccuparti troppo dell'order by:
di per sé fa parte del gioco; è chiaro che può rallentare le cose ma,
d'altra parte, non si possono restituire sempre i dati a casaccio!

Con pazienza (ed un po' di fortuna) sono riuscito a migliorare un order
by fatto su tre campi di 3 file diversi della join... certo senza order
by era più veloce ma l'elenco era illeggibile!

Post by Scorpio
Ignoro se la FETCH FIRST possa essere resa più efficace.

"It depends" (c) :-)

Post by Scorpio
Scorpio.

A domani
Stefano P.

[Scorpio]

Grazie al vostro aiuto, ho cominciato ad avventurarmi nel processo di
gestione degli indici, affiancato anche da chi, a differenza di me, di AS400
se ne intende. A dire il vero il discorso degli indici era nuovo pure a lui,
ma poco male, evidentemente in RPG non sono usati.

Su suo suggerimento, abbiamo cominciato a creare viste logiche ottimizzate
per tipologia di accesso: in pratica, si cerca di matchare al meglio
l'ordinamento interno della vista utilizzando come chiave quella specificata
nella clausola where delle nostre query. I risultati ci sono, ma sono molto,
molto lontani da quelli che si vorrebbero o che, comunque, sono ottenibili
con RPG.

Però qualche precisazione/ aggiornamento sulla situazione si può fare (che
so, magari interessa pure a qualcun'altro). Innanzitutto, probabilmente
qualche *problema* è presente anche nella strutturazione delle tabelle e
nelle relazioni logiche fra esse. Per esempio, per recuperare dati
essenziali a questa o quella funzione devo poi andare a cercare altri dati
su altre tabelle, altrettanto importanti in termini di numero di righe. Per
quanto si ottimizzi, temo che non si potrà mai raggiungere l'efficienza del
sistema di accesso diretto al record. In ambito websphere, però, non vorrei
neppure minare la portabilità utilizzando la toolbox in modo *scorretto* dal
punto di vista di J2EE. Mi voglio limitare ad utilizzare la toolbox come
sorgente dati JDBC.

Ora, la macchina AS400 è decisamente scafata, ma mi sorge il dubbio che
buona parte del tempo di query speso sia dovuto anche al delay che
intercorre tra l'istante in cui la query è lanciata su DBMS e l'istante in
cui la query viene eseguita dal sistema. E' corretta o comunque sostenibile
questa ipotesi, o è campata in aria ?

Purtroppo siamo ancora in fase di studio, e una delle possibilità che ci è
passata per la testa è che esista qualche parametro della toolbox che renda
le query più performanti. Questa mi sembra un'ipotesi peregrina, ma non si
sa mai... qualcuno ha notizie in merito ?

Saluti,
Scorpio

[Stefano P.]

Post by Scorpio
Grazie al vostro aiuto, ho cominciato ad avventurarmi nel processo di
gestione degli indici, affiancato anche da chi, a differenza di me, di AS400
se ne intende. A dire il vero il discorso degli indici era nuovo pure a lui,
ma poco male, evidentemente in RPG non sono usati.

Il "piano di accesso" in rpg (o in cobol) è codificato esplicitamente
dal programmatore (non sto parlado di programmi con sql "embedded"):
si creano le viste logiche e le si scorre (setll, read*, chain etc.)
avendo ben chiaro in mente cosa fare.

L'sql si deve inventare come fare a reperire i record (è l'"access
plan") in base alla query...

Post by Scorpio
Su suo suggerimento, abbiamo cominciato a creare viste logiche ottimizzate
per tipologia di accesso: in pratica, si cerca di matchare al meglio
l'ordinamento interno della vista utilizzando come chiave quella specificata
nella clausola where delle nostre query. I risultati ci sono, ma sono molto,
molto lontani da quelli che si vorrebbero o che, comunque, sono ottenibili
con RPG.

Premesso che gli index - per questioni relative all'oggetto creato -
creati con l'sql ("create index...) offrono usualmente prestazioni
migliori dei file logici creati con le dds (in quanto il buffer è più
grande),
la regola per *iniziare* a buttare giù degli indici (poi dipende dalla
query...) è di mettere come prime chiavi i campi delle where e poi
quelli della join; questo è per iniziare...
...poi ci sono order by e group by che complicano le cose.

Inoltre, il "nuovo" sqe in particolare può decidere di riscrivere
(internamente) la query cambiando l'ordine delle join e sfruttando le
eventuali (se presenti) relazioni di integrità referenziale (look ahed
predicate generator o "lpg")...

Mettici infine che mancano ancora i meta dati sul contenuto delle
tabelle, indispensabili all'sql stesso per farsi un'idea di quanti
record dovrà estrarre: questi sono desumibili dagli indici/file logici
già presenti e dalle statistiche sulle tabelle stesse (che non ricordo
se a V5R2 venissero già raccolte) e sono la causa per cui talvolta il
Visual Explain suggerisce indici che poi non usa per l'accesso diretto:
servono per sapere "cosa c'è" nei file ;-)

Da tutto questo derivava il mio suggerimento di raccogliere il dbmon
dettagliato ed analizzarlo col Visual Explain:
lì si trova tutto (o quasi) quello che la query ha dovuto "mettere in
moto", compresi i tempi macchina indispensabili ad ogni singola fase,
gli indici temporanei realizzati, i riordinamenti indispensabili fatti
per onorare i "distinct" etc. etc.

Post by Scorpio
Però qualche precisazione/ aggiornamento sulla situazione si può fare (che
so, magari interessa pure a qualcun'altro). Innanzitutto, probabilmente
qualche *problema* è presente anche nella strutturazione delle tabelle e
nelle relazioni logiche fra esse.

Ma questo, nel mondo reale, è il problema di quasi tutti...
...e cambiarlo "in corsa" non è facile :-|

Post by Scorpio
Saluti,
Scorpio

Buon divertimento, stai scoprendo un mondo nuovo :-)
Con stima
Stefano P.

[Suarez (dall'ufficio)]

Post by Scorpio
Grazie al vostro aiuto, ho cominciato ad avventurarmi nel processo di
gestione degli indici, affiancato anche da chi, a differenza di me, di AS400
se ne intende. A dire il vero il discorso degli indici era nuovo pure a lui,
ma poco male, evidentemente in RPG non sono usati.

mi aggancio qua ed intervengo anche se in ritardo, se ho ben capito il lavoro
che state facendo (migrazione/reingegnerizzazione di un gestionale) essendoci
passato gia lo scorso anno mi sento di suggerirti un pajo di accorgimenti che se
non risolutivi spero cmq possano essere di aiuto:
- Le tabelle anzitutto. Via le dds per i cari vecchi file fisici e pensate di
creare anche questi via sql (indicizzando gia questi magari, diversamente da
come un tempo si operava con i PF), in questa sede puo' essere d'aiuto ripensare
le relazioni fra i campi e razionalizzare/snellire il db.
- Non e' che nel codice state utilizzando qualche classe del toolbox che simuli
il record level access? a volte possono costituire un collo di bottiglia, se si
e' scelto la strada del sql, sql piu' "puro" possibile sia (anche se la chain e
la setll sono imvho le migliori possibilita' di accesso ai dati mai create in un
linguaggio di programmazione)
- La persistenza di accesso al db? do per scontato che abbiate gia
*investigato* in quella direzione ed ottimizzato l'ottimizzabile
- Come gia' detto da altri, non posso non ribadire di affidarti al monitor del
navigator, anche se non sempre chiarissimo e' uno strumento incredibile (imho la
miglior risorsa in piu' per il l'iSeries rispetto alle altre piattaforme di
sviluppo)

In bocca al lupo e tienici aggiornati

Post by Scorpio
Su suo suggerimento, abbiamo cominciato a creare viste logiche ottimizzate
per tipologia di accesso: in pratica, si cerca di matchare al meglio
l'ordinamento interno della vista utilizzando come chiave quella specificata
nella clausola where delle nostre query. I risultati ci sono, ma sono molto,
molto lontani da quelli che si vorrebbero o che, comunque, sono ottenibili
con RPG.

attento a non confondere le mele con le pere, quando lanci un pgm rpg *classico*
(con le sue belle specifiche F per intenderci) hai gia risolto un pajo di
problemini che in java deve risolvere diversamente, infatti nell'rpg hai gia
impostato sia l'accesso implicito o esplicito al db sia il piano di accesso ai
dati come gia ti e' stato fatto rilevare da StefanoP, queste due operazioni ora
le deve gestire (e di conseguenza ottimizzare) fuori dal *ciclo* del programma

Post by Scorpio
Però qualche precisazione/ aggiornamento sulla situazione si può fare (che
so, magari interessa pure a qualcun'altro). Innanzitutto, probabilmente
qualche *problema* è presente anche nella strutturazione delle tabelle e
nelle relazioni logiche fra esse. Per esempio, per recuperare dati
essenziali a questa o quella funzione devo poi andare a cercare altri dati
su altre tabelle, altrettanto importanti in termini di numero di righe. Per
quanto si ottimizzi, temo che non si potrà mai raggiungere l'efficienza del
sistema di accesso diretto al record. In ambito websphere, però, non vorrei
neppure minare la portabilità utilizzando la toolbox in modo *scorretto* dal
punto di vista di J2EE. Mi voglio limitare ad utilizzare la toolbox come
sorgente dati JDBC.

un problema come quello su esposto ha come unica uscita (decente) la revisone
delle tabelle (anche per i dati numerici, packed e zoned a volte risultano un
po' stomachevoli) e la struttura delle relazioni tra di loro

Post by Scorpio
Ora, la macchina AS400 è decisamente scafata, ma mi sorge il dubbio che
buona parte del tempo di query speso sia dovuto anche al delay che
intercorre tra l'istante in cui la query è lanciata su DBMS e l'istante in
cui la query viene eseguita dal sistema. E' corretta o comunque sostenibile
questa ipotesi, o è campata in aria ?

uhmm se la macchina e' come dici ben scafata credo di no

In bocca al lupo e tienici aggiornati

[Scorpio]

Post by Suarez (dall'ufficio)
mi aggancio qua ed intervengo anche se in ritardo, se ho ben capito il lavoro
che state facendo (migrazione/reingegnerizzazione di un gestionale) essendoci
passato gia lo scorso anno mi sento di suggerirti un pajo di accorgimenti che se
- Le tabelle anzitutto. Via le dds per i cari vecchi file fisici e pensate di
creare anche questi via sql (indicizzando gia questi magari, diversamente da
come un tempo si operava con i PF), in questa sede puo' essere d'aiuto ripensare
le relazioni fra i campi e razionalizzare/snellire il db.

Dipendesse da me, la reingegnerizzazione del database sarebbe stato il passo
0, dal momento
che sebbene le tabelle siano estremamente coerenti fra loro, sono cresciute
nel tempo
e presentano ridondanze e caratteristiche che non sono certo l'optimum per
linguaggi non-RPG.

Però purtroppo il pregresso dobbiamo tenercelo in toto, e su questo non
esiste trattativa.

Post by Suarez (dall'ufficio)
- Non e' che nel codice state utilizzando qualche classe del toolbox che simuli
il record level access? a volte possono costituire un collo di bottiglia, se si
e' scelto la strada del sql, sql piu' "puro" possibile sia (anche se la chain e
la setll sono imvho le migliori possibilita' di accesso ai dati mai create in un
linguaggio di programmazione)

No. La toolbox viene utilizzata, esclusivamente in situazioni "specifiche"
come la verifica
dell'esistenza, ad esempio, di un certo utente sul sistema as400.
L'obiettivo finale è comunque
svincolarsi dalla piattaforma as400, almeno il più possibile.

Post by Suarez (dall'ufficio)
- La persistenza di accesso al db? do per scontato che abbiate gia
*investigato* in quella direzione ed ottimizzato l'ottimizzabile

Bella domanda. In realtà l'uso di standard J2EE come EJB o, nella nuova
release, della JPA, non sono adottabili
tout-court per il semplice fatto che i "motori di persistenza" suppongo che
sulle tabelle siano previste chiavi univoche. E ahimè - altra cosa su cui
non posso farci nulla - praticamente tutte le tabelle in uso sono privi di
vincoli di univocità. Al che, per ridurre l'indubbia "verbosità" della
scrittura di codice Java per l'accesso ai dati, col tempo abbiamo creato una
infrastruttura che oserei definire abbastanza solida per gestire apertura,
chiusura di connessioni, rilascio delle risorse, creazione di cursori
"detached" dal db... funziona bene.

Post by Suarez (dall'ufficio)
- Come gia' detto da altri, non posso non ribadire di affidarti al monitor del
navigator, anche se non sempre chiarissimo e' uno strumento incredibile (imho la
miglior risorsa in piu' per il l'iSeries rispetto alle altre piattaforme di
sviluppo)

L'ho provato, e in effetti è davvero bello. Però,pur creando gli indici
suggeriti, ed altri indici sulla base dell'intuito, ho notato che l'uso di
viste logiche ottimizza parecchio le prestazioni.

Post by Suarez (dall'ufficio)
In bocca al lupo e tienici aggiornati

Crepi il lupo ! Per il momento posso dire che riusciamo ad eseguire query di
"filtro dei risultati" su archivi di circa un milione di righe in sei, sette
secondi (compreso il tempo necessario di decodifica di eventuali codici
(classico esempio: codice articolo e sua descrizione) ) "paginando" il
cursore dei risultati. I tempi si avvicinano a valori che
definirei accettabili.... Temo che per abbassarli ulteriormente - ammesso
che ci si riesca ! - si debba però mettere mano al database in modo
massiccio.

grazie ancora,
Scorpio.

PS. Suarez, se non sono indiscreto: per la reingegnerizzazione voi che
strumenti / linguaggi avete usato ?

[Stefano P.]

[cut]

Post by Scorpio

Post by Suarez (dall'ufficio)
- Come gia' detto da altri, non posso non ribadire di affidarti al monitor del
navigator, anche se non sempre chiarissimo e' uno strumento incredibile (imho la
miglior risorsa in piu' per il l'iSeries rispetto alle altre piattaforme di
sviluppo)

L'ho provato, e in effetti è davvero bello. Però,pur creando gli indici
suggeriti, ed altri indici sulla base dell'intuito, ho notato che l'uso di
viste logiche ottimizza parecchio le prestazioni.

Mi permetto di aggiungere un paio di osservazioni:
1) spesso gli indici vengono suggeriti per avere informazioni sul
contenuto dei file così da poter valutare meglio la selettività delle
query; un altro strumento del Navigator permette poi di controllare
quanto gli indici (sia dds che index veri e propri) vengano usati per le
informazioni statistiche che forniscono e quanto per l'accesso vero e
proprio ai dati (in sql);
2) alla vostra release non vengono suggeriti gli "EVI" (di cui mi pare
che finora - nel thread - non si sia parlato): a V5R4, OS + Navigator li
possono suggerire, talvolta anche con OS a V5R3 e Navigator V5R4; gli
EVI, soprattutto in casi di query con "where" relativamente complesse
(rispetto alla struttura del database) possono essere una manna e
comunque sono utilissimi per le statistiche; ho notato che vengono usati
maggiormente in tabelle di dimensioni elevate (a spanne milioni di
record, non meno).

A proposito di statistiche: ne avete attivato la raccolta?! ;-)

Post by Scorpio
Crepi il lupo ! Per il momento posso dire che riusciamo ad eseguire query di
"filtro dei risultati" su archivi di circa un milione di righe in sei, sette
secondi (compreso il tempo necessario di decodifica di eventuali codici
(classico esempio: codice articolo e sua descrizione) ) "paginando" il
cursore dei risultati. I tempi si avvicinano a valori che
definirei accettabili.... Temo che per abbassarli ulteriormente - ammesso
che ci si riesca ! - si debba però mettere mano al database in modo
massiccio.

Mah, più che il numero di record totale nella tabella occorre sapere
anche quanti sono quelli che complessivamente vengono restituiti dala
query; il numero totale è rilevante solo se occorre eseguire la
scansione di tutta la tabella (ad esempio con un "like '%xyxz'" su un
campo della tabella più grande).

Post by Scorpio
grazie ancora,
Scorpio.

Buona giornata
Stefano P.

[Scorpio]

[cut]

[CUT]

Mah, più che il numero di record totale nella tabella occorre sapere anche
quanti sono quelli che complessivamente vengono restituiti dala query; il
numero totale è rilevante solo se occorre eseguire la scansione di tutta
la tabella (ad esempio con un "like '%xyxz'" su un campo della tabella più
grande).

Sfortunatamente la query richiede una clausola like "xyz%" su tre campi.
Questo certamente aumenta il tempo di risposta....

Scorpio.

[Stefano P.]

Post by Scorpio

Mah, più che il numero di record totale nella tabella occorre sapere anche
quanti sono quelli che complessivamente vengono restituiti dala query; il
numero totale è rilevante solo se occorre eseguire la scansione di tutta
la tabella (ad esempio con un "like '%xyxz'" su un campo della tabella più
grande).

Sfortunatamente la query richiede una clausola like "xyz%" su tre campi.
Questo certamente aumenta il tempo di risposta....

Ah, ma allora ditelo! :-D


Se non ricordo male il "like" - a V5R2 - va sicuramente nel cqe.
Credo ci vada ancora a V5R4...

Però se il like è "xyz%" e *non* "%xyz%" allora un indice su campo del
like per iniziare va più che bene ;-)
(indici con prima i campi della "where" e poi quelli della join)


...non è che usate pure "UPPER(..."?!

Post by Scorpio
Scorpio.

Ciao
Stefano P.

[Scorpio]

Post by Stefano P.
...non è che usate pure "UPPER(..."?!

No no, almeno quella NO !

Ciao,
Scorpio.

[Stefano P.]

Post by Scorpio

Post by Stefano P.
...non è che usate pure "UPPER(..."?!

No no, almeno quella NO !

Beh, alle volte, per non aver problemi di maiuscole e minuscole, non è
inusuale scrive qualcosa tipo " where UPPER(descrizione) like '%PIPPO%'" ;-)

Post by Scorpio
Ciao,
Scorpio.

Buon fine settimana
Stefano P.

[Suarez (dall'ufficio)]

Post by Scorpio
Dipendesse da me, la reingegnerizzazione del database sarebbe stato il passo
0, dal momento
che sebbene le tabelle siano estremamente coerenti fra loro, sono cresciute
nel tempo
e presentano ridondanze e caratteristiche che non sono certo l'optimum per
linguaggi non-RPG.
Però purtroppo il pregresso dobbiamo tenercelo in toto, e su questo non
esiste trattativa.

Mi permetto cmq di suggerirti una prova: la creazione via sql anche delle
tabelle, al posto delle dds, magari solo una parte del tutto solo per una prova.
Tieni presente che in questi casi non esiste un solo trucco che *magicamente*
risolve tutto, si tratta di *rosicare* millesimi di secondo un po' ovunque (a
meno di non voler acquistare una macchina piu' potente, cosa che di solito
risolve il 50-70% dei problemi ;-))

Post by Scorpio
Crepi il lupo ! Per il momento posso dire che riusciamo ad eseguire query di
"filtro dei risultati" su archivi di circa un milione di righe in sei, sette
secondi (compreso il tempo necessario di decodifica di eventuali codici
(classico esempio: codice articolo e sua descrizione) ) "paginando" il
cursore dei risultati. I tempi si avvicinano a valori che
definirei accettabili.... Temo che per abbassarli ulteriormente - ammesso
che ci si riesca ! - si debba però mettere mano al database in modo
massiccio.

cmq la c.d. gestione dei metadati per tabelle di svariati milioni di record e
statement che magari presentano join e varie condizioni di selezione non e' mica
roba da poco, non scartate l'ipotesi a priori che possa occorrere anche una
nuova macchina (non hai detto su quale modello e processore state operando
adesso, io do' per scontato che si tratti almeno di un decente power5 gia un
power4 avrebbe, temo, qualche problemuccio)
Una curiosita state usando WAS? quale versione?

Post by Scorpio
PS. Suarez, se non sono indiscreto: per la reingegnerizzazione voi che
strumenti / linguaggi avete usato ?

gli stessi che state usando voi a quel che ho capito. Tieni presente che noi
avevamo una procedura scritta originariamente per il S/38 e sostanzialmente mai
modificata (giusto verso la fine degli anni '90 si era iniziato ad introdurre i
prtf esterni). Inizialmente bbiamo provato con i vari tool di conversione
distribuiti da ACG ma in realta' il risultato (magari funzionante) era una
ciofeca in termini di manutenibilita' futura. Cosi abbiamo cambiato rotta, il
primo passo e' stato di convertire in ILE i pgm RPG (e pure li' ci abbiamo messo
mano ai pgm), tieni presente che noi non avevamo il problema di doverci
*staccare* dall'AS quindi sotto certi aspetti il alvoro ci era facilitato, in
seguito abbiamo distinto parti *interattive* da lavori che potevano girare in
*batch* (in realta abbiamo ragionato molto semplicemente su quali funzioni
richiedevano una iterazione con l'utente e quali potevano invece - assunti i
parametri operativi - girare in maniera *indipendente*), per i primi siamo
passati ad una situazione full jee con WAS 6 e consueti corollari
(jsf/ejb/struts/hibernate) per i secondi abbiamo lasciato spesso i vecchi pgm
RPG convertiti in ILE e magari trasformati in SQLRPGLE (ma questi sono stati una
minoranza causa limiti temporali) tieni presente che partivamo da una procedura
di qualche migliaio di oggetti (tra pgm, prtf, ...) ed in 4 mesi lavorandoci in
6 (di cui 4 persone quasi continuatamente) ne siamo venuti a capo (si poi ci
sono stati altri 6 mesi di correzioni ed affinamenti ma quelli fanno parte del
gioco)

[Scorpio]

Post by Suarez (dall'ufficio)
cmq la c.d. gestione dei metadati per tabelle di svariati milioni di record e
statement che magari presentano join e varie condizioni di selezione non e' mica
roba da poco, non scartate l'ipotesi a priori che possa occorrere anche una
nuova macchina (non hai detto su quale modello e processore state operando
adesso, io do' per scontato che si tratti almeno di un decente power5 gia un
power4 avrebbe, temo, qualche problemuccio)

825, 6 processori, 7Gb Ram. Tieni presente però che ci lavorano circa 3000
postazioni,
a spanne, più programmi di utilità varia che utilizzano questa macchina come
dbms.

Post by Suarez (dall'ufficio)
Una curiosita state usando WAS? quale versione?

Abbiamo iniziato nel 2003 con WAS 5.0. Bell'application server, direi. Poi
siamo passati direttamente
a WAS 6.1, più performante come JRE ma secondo me uscito un po' troppo
prematuramente. Facciamo girare
WAS 6.1 su Linux RH4 e di suo è una bellezza.

Post by Suarez (dall'ufficio)
gli stessi che state usando voi a quel che ho capito. Tieni presente che noi
avevamo una procedura scritta originariamente per il S/38 e
sostanzialmente mai
modificata (giusto verso la fine degli anni '90 si era iniziato ad introdurre i
prtf esterni). Inizialmente bbiamo provato con i vari tool di conversione
distribuiti da ACG ma in realta' il risultato (magari funzionante) era una
ciofeca in termini di manutenibilita' futura. Cosi abbiamo cambiato rotta, il
primo passo e' stato di convertire in ILE i pgm RPG (e pure li' ci abbiamo messo
mano ai pgm), tieni presente che noi non avevamo il problema di doverci
*staccare* dall'AS quindi sotto certi aspetti il alvoro ci era facilitato, in
seguito abbiamo distinto parti *interattive* da lavori che potevano girare in
*batch* (in realta abbiamo ragionato molto semplicemente su quali funzioni
richiedevano una iterazione con l'utente e quali potevano invece - assunti i
parametri operativi - girare in maniera *indipendente*), per i primi siamo
passati ad una situazione full jee con WAS 6 e consueti corollari
(jsf/ejb/struts/hibernate) per i secondi abbiamo lasciato spesso i vecchi pgm
RPG convertiti in ILE e magari trasformati in SQLRPGLE (ma questi sono stati una
minoranza causa limiti temporali) tieni presente che partivamo da una procedura
di qualche migliaio di oggetti (tra pgm, prtf, ...) ed in 4 mesi lavorandoci in
6 (di cui 4 persone quasi continuatamente) ne siamo venuti a capo (si poi ci
sono stati altri 6 mesi di correzioni ed affinamenti ma quelli fanno parte del
gioco)

Vi faccio i complimenti...con un po' di invidia. Noi siamo solo in due, però
purtroppo
non certo impiegati a full time (spesso siamo impiegati anche su altri
progetti). Poco male,
nel senso che in questi anni abbiamo fatto un bel po' di roba, peccato che,
come accade
con le ciambelle, i progetti non siano usciti tutti con il buco.
Sono contento però che ci sia stato qualcun altro che si sia avventurato
nell'uso di WAS.

Se le query non migliorano e mi mandano a quel paese, quasi quasi vi mando
il CV :-)

Scorpio.

[Stefano P.]

Post by Scorpio
825, 6 processori, 7Gb Ram.

Stando a qualche guru Ibm ("il" guru: Mike Cain), per (un uso
relativamente "pesante" del) l'sql quella ram è comunque un po' pochina...

Post by Scorpio
Scorpio.

Saluti
Stefano P.

[Scorpio]

Post by Stefano P.

Post by Scorpio
825, 6 processori, 7Gb Ram.

Stando a qualche guru Ibm ("il" guru: Mike Cain), per (un uso
relativamente "pesante" del) l'sql quella ram è comunque un po' pochina...

... e questo è una delle cose che mi lascia perplesso, circa l'AS400. Non
voglio essere frainteso, nè fare il polemico, ma...credo che se avessi a
disposizione un server linux con mysql, con tutti quei processori e quella
ram, il DBMS *volerebbe*. Però, ovviamente, non tengo in considerazione
taaaanti fattori come, in primis, la scalabilità dell'architettura.

Scorpio.

[Stefano P.]

[cut]

Post by Scorpio
...credo che se avessi a
disposizione un server linux con mysql, con tutti quei processori e quella
ram, il DBMS *volerebbe*. Però, ovviamente, non tengo in considerazione
taaaanti fattori come, in primis, la scalabilità dell'architettura.

Può darsi, bisognerebbe provare:
dopo tutto scaricare il DB2 9.5 (anche per versioni a 64 bit,
indispensabile per gestire più di 2 GB di ram) per Linux può essere
gratuito:
qualche prova la si può fare...

La mia sensazione è che, quando il server inizia a fare il server
davvero, allora le cose cambiano (sia le richieste dell'utenza che le
risposte di OS e DB) e la bilancia inizi a pendere a favore dell'i5/OS;
d'altra parte è pur vero che - mentre di OS/400 ormai ho un po' di
esperienza - di Linux sono ancora un grande ignorante (giochicchio con
Ubuntu...)

Post by Scorpio
Scorpio.

Saluti
Stefano P.

p.s.: è vero, la configurazione della nostra macchina principale è ben
diversa dalla vostra, ma quando fai un indice nuovo e nel giro di un ora
è già stato usato più di 100 volte per le query e 300 per le
statistiche... occorrono ram e dischi in abbondanza, a prescindere dal
sistema operativo ;-)

[Scorpio]

[cut]
La mia sensazione è che, quando il server inizia a fare il server davvero,
allora le cose cambiano (sia le richieste dell'utenza che le risposte di
OS e DB) e la bilancia inizi a pendere a favore dell'i5/OS;
d'altra parte è pur vero che - mentre di OS/400 ormai ho un po' di
esperienza - di Linux sono ancora un grande ignorante (giochicchio con
Ubuntu...)

Ho fatto un esempio esclusivamente basato su prove molto, ma molto
empiriche.
Quindi vale per quel che vale....

p.s.: è vero, la configurazione della nostra macchina principale è ben
diversa dalla vostra, ma quando fai un indice nuovo e nel giro di un ora è
già stato usato più di 100 volte per le query e 300 per le statistiche...
occorrono ram e dischi in abbondanza, a prescindere dal sistema operativo
;-)

Se ti è possibile: qual'è la vostra configurazione ?

[Stefano P.]

Post by Scorpio

Post by Stefano P.
p.s.: è vero, la configurazione della nostra macchina principale è ben
diversa dalla vostra, ma quando fai un indice nuovo e nel giro di un ora è
già stato usato più di 100 volte per le query e 300 per le statistiche...
occorrono ram e dischi in abbondanza, a prescindere dal sistema operativo
;-)

Se ti è possibile: qual'è la vostra configurazione ?

Allora: l'825, con 3 processori (gli altri 3 non sono stati mai
attivati) e 20 GB di ram, è diventato la macchina di backup più di 2
anni fa; a breve ci lascerà del tutto...

La macchina di produzione attuale - ma non per molto ancora - è un 570
con 3 processori P5, 24 GB di RAM (8 GB per processore, come da
richieste per l'SQL) e 3 TB di disco:
Dati delle performance alla mano, ne stiamo già usando i 52 dischi un
po' al di sopra delle possibilità loro e dei controller...


Saluti
Stefano P.

[Suarez (dall'ufficio)]

Post by Scorpio
... e questo è una delle cose che mi lascia perplesso, circa l'AS400. Non
voglio essere frainteso, nè fare il polemico, ma...credo che se avessi a
disposizione un server linux con mysql, con tutti quei processori e quella
ram, il DBMS *volerebbe*. Però, ovviamente, non tengo in considerazione
taaaanti fattori come, in primis, la scalabilità dell'architettura.
Scorpio.

AAALLLLLTTTT STOP FERMA, e' un tipico errore concettuale il tuo, se pensi ad un
server db pensi ad una macchina che fa' esclusivamente quello, mentre il tuo
*povero* 825 (bella macchinetta ce l'ho pure io ma con 4 gb di ram) oltre a
sopportare le vostre menate sql ;-) ospita 3000 postazioni (3000 utenti credo e
relative menate, device, cazzi e mazzi), più programmi di utilità varia che
utilizzano questa macchina come dbms (e se tanto mi da tanto sotto sotto ci
saranno qualche migliaio di oggetti vari da gestire tra pgm legacy con annessi e
connessi e qualche centinajo de' journal). Con tutto il rispetto ma faje fa'
tutte 'ste cose ad una macchina, contemporaneamente, linux e/o *unix non
importa, eppoi ragionamo sulle prestazioni ;-))

[Scorpio]

Post by Suarez (dall'ufficio)
AAALLLLLTTTT STOP FERMA, e' un tipico errore concettuale il tuo, se pensi ad un
server db pensi ad una macchina che fa' esclusivamente quello, mentre il tuo
*povero* 825 (bella macchinetta ce l'ho pure io ma con 4 gb di ram) oltre a
sopportare le vostre menate sql ;-) ospita 3000 postazioni (3000 utenti credo e
relative menate, device, cazzi e mazzi), più programmi di utilità varia che
utilizzano questa macchina come dbms (e se tanto mi da tanto sotto sotto ci
saranno qualche migliaio di oggetti vari da gestire tra pgm legacy con annessi e
connessi e qualche centinajo de' journal). Con tutto il rispetto ma faje fa'
tutte 'ste cose ad una macchina, contemporaneamente, linux e/o *unix non
importa, eppoi ragionamo sulle prestazioni ;-))

Calma calma calma..... NON ho detto che le prestazioni e la scalabilità
dell'AS siano
pessime, tutt'altro. Il nostro as400 NON è una macchina dedicata (e ci
mancherebbe!!!)
a fare la "DBMS machine" per le nostre applicazioni. E', anzi, già di suo
sovraccarica
già per quanto riguarda i programmi nativi, dal momento che i clienti ci
fanno di tutto
(ci manca solo che facciano il caffè...). Per quanto possa essere un
sostenitore dei
sistemi open, non ho i paraocchi: far fare *tutto* ciò che fa l'as400 ad un
sistema
linux significa, se la machina unix / linux non è più che scafata, ammazzare
semplicemente
la macchina (vale un discorso di scalabilità).

Il mio era un discorso un po'.... deviante dal seminato. In pratica mi sto
convincendo che
soluzioni Java+i5 sono certamente fattibili, e, quando ben progettate e
realizzate,anche
efficaci e molto scalabili (vuoi per J2EE che è ben scalabile, vuoi,
soprattutto, per il sistema
i5), ma occorre una disponibilità economica non indifferente: se con una
macchina pagata
molto, ma molto (non entro nei dettagli) otteniamo tempi di risposta scarsi,
tutti pensano
subito che il difetto sia nel manico (cioè in J2EE) perchè in pochi sono
disposti a fare
il tuo ragionamento (che è quello IMHO *giusto*, considerare il carico di
sistema).

Con la stessa cifra avrei potuto benissimo, e con largo, larghissimo
risparmio, mettere in pista
un application server su macchina dedicata (già è cosi) e una dozzina di
server linux scafati
a fare da DBMS dedicato, con tempi di risposta IMHO molto migliori. Ripeto,
sto valutando
solo "Java + DBMS" e non tutto il resto, tra cui ad esempio la prob. di
guasti che a quel punto
salirebbe non di poco, fattori di cui al lato pratico poi in pochi pensano
(e sicuramente a cui
non pensano i clienti !)

Scorpio.

[Stefano P.]

[cut]

Post by Scorpio
Ripeto,
sto valutando
solo "Java + DBMS" e non tutto il resto, tra cui ad esempio la prob. di
guasti che a quel punto
salirebbe non di poco, fattori di cui al lato pratico poi in pochi pensano
(e sicuramente a cui
non pensano i clienti !)

Sai, all'incontro con Robert Bestgen - di cui si parlò in un altro
thread - egli ci riferì di essere stato ad una conferenza di Google
nella quale si parlava del loro sistema di server distribuito:
alla (forse sua) domanda "cosa fate se un server non risponde" la
risposta (di quelli di Google) fu che "l'utente è abituato a cliccare di
nuovo (nel browser)".
Semplificando molto, questo - lo sai bene - nelle nostre (di questo
newsgroup) applicazioni (con transazioni di mezzo ;-) non è credo quasi
mai accettabile...

Post by Scorpio
Scorpio.

Saluti
Stefano P.

[Scorpio]

Post by Stefano P.
Sai, all'incontro con Robert Bestgen - di cui si parlò in un altro
thread - egli ci riferì di essere stato ad una conferenza di Google nella
alla (forse sua) domanda "cosa fate se un server non risponde" la risposta
(di quelli di Google) fu che "l'utente è abituato a cliccare di nuovo (nel
browser)".
Semplificando molto, questo - lo sai bene - nelle nostre (di questo
newsgroup) applicazioni (con transazioni di mezzo ;-) non è credo quasi
mai accettabile...

Sacrosanto, ma nel mondo del web (per una larghissima classe di
applicazioni, ovviamente, non necessariamente per tutte le applicazioni)
questa risposta può comunque essere adeguata. E sufficiente.
Sono d'accordo sul discorso delle transazioni. Ma quanto il problema della
transazionalità delle operazioni è sentito ? Io lo do per scontato. Qualcuno
lo considera un fardello inutile. E sto parlando di sviluppatori RPG e Java
indifferentemente.

Scorpio.

[Stefano P.]

Post by Scorpio

Post by Stefano P.
alla (forse sua) domanda "cosa fate se un server non risponde" la risposta
(di quelli di Google) fu che "l'utente è abituato a cliccare di nuovo (nel
browser)".

Ovviamente chi ce ne ha parlato ha un evidente (e di parte) punto di
vista...

Post by Scorpio

Post by Stefano P.
Semplificando molto, questo - lo sai bene - nelle nostre (di questo
newsgroup) applicazioni (con transazioni di mezzo ;-) non è credo quasi
mai accettabile...

Sacrosanto, ma nel mondo del web (per una larghissima classe di
applicazioni, ovviamente, non necessariamente per tutte le applicazioni)
questa risposta può comunque essere adeguata. E sufficiente.
Sono d'accordo sul discorso delle transazioni. Ma quanto il problema della
transazionalità delle operazioni è sentito ? Io lo do per scontato. Qualcuno
lo considera un fardello inutile. E sto parlando di sviluppatori RPG e Java
indifferentemente.

Lo si potrebbe chiedere (ed aprire un altro thread) ai colleghi che
usano sia cgidev che java; dopo tutto da domani dovremmo di nuovo essere
tutti all'opra :-)

Vai avanti tu, che... sei più esperto ;-)

Post by Scorpio
Scorpio.

Saluti
Stefano P.