Richiesta

Fochi Eugenio

Richiesta
Salve ! Vorrei sapere se la causa dei lunghi tempi di risposta dell' applicazione che gestisco potrebbero derivare dall'utilizzo al 100% della CPU da parte del processo DB2SYSC .

Segnalo che l'applicazione gira su un server applicativo unix dedicato dove non riscontro criticità di sorta.

Il database e definito su un secondo server unix dedicato dove riscontro l'utilizzo del 100% della CPU da parte del db processo DB2SYSC.

Il sistema operativo è uno unix 5.3 ed il db2 un 9.5 con i parametri del database in automatico come di default .

Non sò cosa fare per migliorare le performance dell'applicazione non riscontrando LOCK , DEADLOCK o quant'altro .


_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv

Giacomo Restuccia

Re: Richiesta
(in response to Fochi Eugenio)
Prova con DB2TOP a guardare i bottlenecks ( opzione B maiuscolo); potrebbe trattarsi di intense attività di LOGGING, LOCKING, SORT ...... Se nulla emerge dai bottlenecks, puoi provare a guardare il numero di connessioni in essere. In bocca al lupo
Giacomo

Da: "IDUG Regional Group - Italy" [login to unmask email]
A: [login to unmask email]
Cc:
Data: Tue, 3 May 2011 14:28:20 +0000
Oggetto: Richiesta


> Salve ! Vorrei sapere se la causa dei lunghi tempi di risposta dell' applicazione che gestisco potrebbero derivare dall'utilizzo al 100% della CPU da parte del processo DB2SYSC .
>
> Segnalo che l'applicazione gira su un server applicativo unix dedicato dove non riscontro criticità di sorta.
>
> Il database e definito su un secondo server unix dedicato dove riscontro l'utilizzo del 100% della CPU da parte del db processo DB2SYSC.
>
> Il sistema operativo è uno unix 5.3 ed il db2 un 9.5 con i parametri del database in automatico come di default .
>
> Non sò cosa fare per migliorare le performance dell'applicazione non riscontrando LOCK , DEADLOCK o quant'altro .
>
>
> _________________________________________________________________
>
> Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
> _________________________________________________________________
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
> is the home of IDUG's Listserv

_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv


Angelo Sironi

R: Richiesta
(in response to Giacomo Restuccia)
DB2SYSC è l'engine dell'istanza del DB2. Quindi, sarei portato a ritenere che le applicazioni stanno saturando la CPU della macchina su cui gira il DB2. Ora, è naturale che questo possa incidere in maniera negativa sul tempo di risposta (è lo stesso problema che succede quando c'è un intasamento in autostrada....).

Non sapendo nulla delle applicazioni in esame, del fatto se il fenomeni indicato sia nuovo o meno, ecc. è difficile dare indicazioni. Direi che probabilmente si tratta di contese sulla CPU e non di contese sui dati o altre contese, perché in simili situazioni si avrebbe l'effetto opposto alla saturazione della CPU...

Domande: l'applicazione come accede ai dati? Usa SQL statico oppure come succede ormai nel 99% dei casi su queste piattaforme usa chiamate JDBC oppure ODBC con uso di SQL dinamico? Le query sono ottimizzate?
Se usano SQL dinamico, hai provato a prendere uno Snapshot degli statement SQL, per vedere se ce ne sono di inefficienti? O anche più sinteticamente uno snapshot di database per controllare quanto lavoro sta facendo il DB2 e quanto efficiente o inefficiente è il suo modo di lavorare?

A presto,
Angelo Sironi

-----Messaggio originale-----
Da: IDUG Regional Group - Italy [mailto:[login to unmask email] Per conto di Fochi Eugenio
Inviato: martedì 3 maggio 2011 16.28
A: [login to unmask email]
Oggetto: Richiesta

Salve ! Vorrei sapere se la causa dei lunghi tempi di risposta dell' applicazione che gestisco potrebbero derivare dall'utilizzo al 100% della CPU da parte del processo DB2SYSC .

Segnalo che l'applicazione gira su un server applicativo unix dedicato dove non riscontro criticità di sorta.

Il database e definito su un secondo server unix dedicato dove riscontro l'utilizzo del 100% della CPU da parte del db processo DB2SYSC.

Il sistema operativo è uno unix 5.3 ed il db2 un 9.5 con i parametri del database in automatico come di default .

Non sò cosa fare per migliorare le performance dell'applicazione non riscontrando LOCK , DEADLOCK o quant'altro .


_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv

_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv

Losio Matteo

I: Richiesta
(in response to Angelo Sironi)


BANCA CARIGE S.p.A.
I.C.T. - Gestione Sistemi
Ufficio Produzione - 825
Reparto DB2 Administration - 825-5
Via G. D'Annunzio, 101 - 16121 Genova (GE) - ITALY
V phone: +39 010 579.2936 - Sig.ra Paola De Biase
phone: +39 010 579.2500 - Sig. Renato Latuati
- phone: +39 010 579.4993 - Sig.ra Teresa Iozzo
phone: +39 010 579.2974 - Sig. Matteo Losio
fax: +39 010 579.2980
mailto: [login to unmask email]


-----Messaggio originale-----
Da: [login to unmask email]
Inviato: mercoledì 4 maggio 2011 8.20
A: [login to unmask email]
Oggetto: R: Richiesta

Buongiorno Eugenio,
potrebbe essere opportuno attivare un event monitor for statements per tracciare le istruzioni sql che arrivano sul tuo database. Ottenuto questo report dovresti cercare al suo interno le istruzioni che hanno il tempo di esecuzione maggiore, le isoli (copi e incolli gli statements da qualche parte) e successivamente utilizzi questi statement come input da passare al tool db2advis di modo da ottenere un explain dettagliato dove ti vengono indicati eventuali indici da creare e le percentuali di miglioramento che potresti raggiungere.

Nel caso avessi bisogno di un esempio dimmelo che te lo invio.
Matteo Losio

BANCA CARIGE S.p.A.
I.C.T. - Gestione Sistemi
Ufficio Produzione - 825
Reparto DB2 Administration - 825-5
Via G. D'Annunzio, 101 - 16121 Genova (GE) - ITALY
V phone: +39 010 579.2936 - Sig.ra Paola De Biase
phone: +39 010 579.2500 - Sig. Renato Latuati
- phone: +39 010 579.4993 - Sig.ra Teresa Iozzo
phone: +39 010 579.2974 - Sig. Matteo Losio
fax: +39 010 579.2980
mailto: [login to unmask email]

-----Messaggio originale-----
Da: IDUG Regional Group - Italy [mailto:[login to unmask email] Per conto di Angelo Sironi
Inviato: martedì 3 maggio 2011 19.04
A: [login to unmask email]
Oggetto: R: Richiesta

DB2SYSC è l'engine dell'istanza del DB2. Quindi, sarei portato a ritenere che le applicazioni stanno saturando la CPU della macchina su cui gira il DB2. Ora, è naturale che questo possa incidere in maniera negativa sul tempo di risposta (è lo stesso problema che succede quando c'è un intasamento in autostrada....).

Non sapendo nulla delle applicazioni in esame, del fatto se il fenomeni indicato sia nuovo o meno, ecc. è difficile dare indicazioni. Direi che probabilmente si tratta di contese sulla CPU e non di contese sui dati o altre contese, perché in simili situazioni si avrebbe l'effetto opposto alla saturazione della CPU...

Domande: l'applicazione come accede ai dati? Usa SQL statico oppure come succede ormai nel 99% dei casi su queste piattaforme usa chiamate JDBC oppure ODBC con uso di SQL dinamico? Le query sono ottimizzate?
Se usano SQL dinamico, hai provato a prendere uno Snapshot degli statement SQL, per vedere se ce ne sono di inefficienti? O anche più sinteticamente uno snapshot di database per controllare quanto lavoro sta facendo il DB2 e quanto efficiente o inefficiente è il suo modo di lavorare?

A presto,
Angelo Sironi

-----Messaggio originale-----
Da: IDUG Regional Group - Italy [mailto:[login to unmask email] Per conto di Fochi Eugenio
Inviato: martedì 3 maggio 2011 16.28
A: [login to unmask email]
Oggetto: Richiesta

Salve ! Vorrei sapere se la causa dei lunghi tempi di risposta dell' applicazione che gestisco potrebbero derivare dall'utilizzo al 100% della CPU da parte del processo DB2SYSC .

Segnalo che l'applicazione gira su un server applicativo unix dedicato dove non riscontro criticità di sorta.

Il database e definito su un secondo server unix dedicato dove riscontro l'utilizzo del 100% della CPU da parte del db processo DB2SYSC.

Il sistema operativo è uno unix 5.3 ed il db2 un 9.5 con i parametri del database in automatico come di default .

Non sò cosa fare per migliorare le performance dell'applicazione non riscontrando LOCK , DEADLOCK o quant'altro .


_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv

_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv

AVVERTENZA
Chi riceve la presente è tenuto a verificare che la stessa sia effettivamente a lui indirizzata; in caso contrario, considerate le conseguenze penali connesse alla cognizione e/o diffusione di corrispondenza non a sé diretta, lo si invita ad avvisare tempestivamente il mittente, distruggendo comunque le eventuali copie o stampe della medesima.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this message. Any unauthorized copying, disclosure or distribution of the material contained in this e-mail is strictly forbidden.

Prima di stampare, pensa all'ambiente! Please consider the environment before printing this e-mail!

_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
International DB2 User Group (IDUG) - Independent, not-for-profit, User Run
Your only source for independent, unbiased, and trusted DB2 information


Biffi Franco

R: Richiesta
(in response to Losio Matteo)
Ciao, spesso questo dipende da query che per cause diverse leggono parecchi dati, dati che magari potrebbero essere già presenti nei buffer pool.
Prova a verificare:
1) quante SYSIBMADM.SNAPDB.ROWS_READ e quante SYSIBMADM.SNAPDB.ROWS_SELECTED ci sono a livello di DB;
2) quante SYSIBMADM.SNAPTAB.ROWS_READ, SYSIBMADM.SNAPTAB.ROWS_WRITTEN per ciascuna tabella. Dalle tabella poi cerchi di risalire alle query;
3) se ci sono query che durano molto e leggono-scrivono molto e/o fanno molti sort;

spero di esserti stato d'aiuto
ciao
fb


Franco Biffi

Kedrios S.p.A.
Via Taramelli, 26
20124 Milano
Italy

Tel.: +39 02 62365814
Email: [login to unmask email]
Web: www.kedrios.com

Società soggetta alla direzione e coordinamento di Xchanging Plc (www.xchanging.com).
Prima di stampare questa mail considera l'impatto ambientale.

-----Messaggio originale-----
Da: IDUG Regional Group - Italy [mailto:[login to unmask email] Per conto di Fochi Eugenio
Inviato: martedì 3 maggio 2011 16.28
A: [login to unmask email]
Oggetto: Richiesta

Salve ! Vorrei sapere se la causa dei lunghi tempi di risposta dell' applicazione che gestisco potrebbero derivare dall'utilizzo al 100% della CPU da parte del processo DB2SYSC .

Segnalo che l'applicazione gira su un server applicativo unix dedicato dove non riscontro criticità di sorta.

Il database e definito su un secondo server unix dedicato dove riscontro l'utilizzo del 100% della CPU da parte del db processo DB2SYSC.

Il sistema operativo è uno unix 5.3 ed il db2 un 9.5 con i parametri del database in automatico come di default .

Non sò cosa fare per migliorare le performance dell'applicazione non riscontrando LOCK , DEADLOCK o quant'altro .


_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv

*******************Internet Email Confidentiality Footer*******************
Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite al mittente e non possono essere necessariamente considerate come autorizzate da Kedrios S.p.A.; le medesime dichiarazioni non impegnano Kedrios S.p.A. nei confronti del destinatario o di terzi. Kedrios S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of Kedrios S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by Kedrios S.p.A.. Kedrios S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.


_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
International DB2 User Group (IDUG) - Independent, not-for-profit, User Run
Your only source for independent, unbiased, and trusted DB2 information

Fabrizio Seghizzi

Re: Richiesta
(in response to Biffi Franco)
Buongiorno,
io proverei a disabilitare l'health monitor:
db2 update dbm cfg using HEALTH_MON OFF
db2stop/db2start
Saluti,
Cordiali Saluti / Best Regards,
Fabrizio Seghizzi - Senior IT Specialist
IBM Italia S.p.A.
Global Technology Services - DB2 for LUW and Z/OS Support &
Services
e-mail: [login to unmask email]
Mobile: (+39)335.5437098

Il contenuto di questa email e degli allegati può avere natura
confidenziale ad uso esclusivo del destinatario effettivo. Qualora
riceviate questa email per errore, Vi preghiamo di informarci restituendo
l'email e di procedere all'eliminazione della stessa dalla vostra
macchina. E' vietata la riproduzione e la diffusione del contenuto a chi
non è effettivo destinatario.

This email and its attachments might be confidential and are only for use
of intended recipient. If you are not the intended recipient, please
notify us immediatly by sending back the email and delete it from your
machine. You are not allowed to disseminate nor to copy the content of the
email if you are not the intended recipient.



From: Fochi Eugenio <[login to unmask email]>
To: [login to unmask email]
Date: 03/05/2011 16.49
Subject: Richiesta
Sent by: IDUG Regional Group - Italy <[login to unmask email]>



Salve ! Vorrei sapere se la causa dei lunghi tempi di risposta dell'
applicazione che gestisco potrebbero derivare dall'utilizzo al 100% della
CPU da parte del processo DB2SYSC .

Segnalo che l'applicazione gira su un server applicativo unix dedicato
dove non riscontro criticità di sorta.

Il database e definito su un secondo server unix dedicato dove riscontro
l'utilizzo del 100% della CPU da parte del db processo DB2SYSC.

Il sistema operativo è uno unix 5.3 ed il db2 un 9.5 con i parametri del
database in automatico come di default .

Non sò cosa fare per migliorare le performance dell'applicazione non
riscontrando LOCK , DEADLOCK o quant'altro .


_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv



IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI)
Cap. Soc. euro 384.506.359,00
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società soggetta all?attività di direzione e coordinamento di
International Business Machines Corporation

(Salvo che sia diversamente indicato sopra / Unless stated otherwise
above)

_________________________________________________________________

Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
_________________________________________________________________
International DB2 User Group (IDUG) - Independent, not-for-profit, User Run
Your only source for independent, unbiased, and trusted DB2 information