incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS e NUMLOCKMAXTS in ZPARM

Massimo Biancucci

incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS e NUMLOCKMAXTS in ZPARM
Prima l'obiezione: non necessariamente. Mediamente potrebbe essere vero nel senso che permetti ad un'applicazione di tenere più lock in contemporanea. Se questi sono derivanti da aggiornamenti veri e propri e non da "intenti di aggiornamento" su cui possono gravare altri parametri tipo ISOLATION(RS/RR), allora i tempi possono espandersi. Possiamo poi fare il caso limite contrario; aggiorno una pagina N milioni di volte, quindi mantengo un solo lock (nel caso di LOCKSIZE a pagina) e comunque il rollback mi costa una vita.

La fase di rollback è normalmente più gravosa a causa della necessità di leggere i log records anche appartenenti ad altre UOR da cui l'affermazione solita per cui il rollback dura almeno quanto la UOR + un delta X variabile.

Quanto costa un lock in termini di CPU: dipende dalla configurazione (data sharing o meno) e dalla potenza del processore. Non ti so dare un valore assoluto comunque si parla di pochi microsecondi. Se vuoi una risposta ufficiale, basta aprire un APAR informativo ad IBM e, sulla base della tua configurazione, ti risponderanno quasi certamente.

Se hai un'esigenza applicativa per innalzare il valore dei locks contemporanei allora dovrebbe essere analizzata meglio prima di dire un no categorico. Certo i numeri richiesti non sono da poco e, probabilmente, anche dal punto di vista applicativo occorre interrogarsi sino in fondo prima di procedere.

Tenete conto anche dell'eventuale aumento di richiesta di memoria per il mantenimento dei locks.

Spero di essere stato utile.

Ciao.

-----Messaggio originale-----
Da: DB2 User Group - Italy List [mailto:[login to unmask email] Per conto di No Name Available
Inviato: giovedì 3 agosto 2006 11.54
A: [login to unmask email]
Oggetto: ZOS: incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS e NUMLOCKMAXTS in ZPARM

Ciao a tutti.
Ho necessità di avere qualche parere e consiglio su una obiezione che mi è stata fatta nel momento in cui ho richiesto di innalzare i valori dei due parametri seguenti in ZPARM:
NUMLKTS
NUMLKUS

attualmente i valori sono rispettivamente 1000 e 10000.

Ho proposto di innalzarli a 20000 e 200000 per esigenze di carattere applicativo.

L'obiezione che mi è sta sollevata è che "verrebbe allungato troppo il tempo necessario al rollback".

Da cui la mia domanda:
In fase di rollback l'IRLM fa qualcosa di più rispetto alla fase di forward della UR?
Ed un altra domanda:
quale può essere il tempo medio in microsecondi speso per l'aquisizione di un singolo lock?

Grazie a tutti in anticipo per le risposte.


Cassinadri Pierluigi
Database administrator
System and Support Specialist
Information Tecnology
Direct Line Insurance S.p.A.
Piazza Monte Titano, 10
20132 Milano - Italy
Tel. : (+39) 02-21725203
Fax. : (+39) 02-21725092
e-mail: [login to unmask email]
http://www.directline.it



Naviga e telefona senza limiti con Tiscali
Scopri le promozioni tiscali adsl: navighi e telefoni senza canone Telecom

http://abbonati.tiscali.it/adsl/

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy pu essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novit sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

Moschelli Mauro

Re: incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS e NUMLOCKMAXTS in ZPARM
(in response to Massimo Biancucci)
Un altro motivo per cui potrebbe innalzarsi il tempo di rollback è il caso in cui nonostante i parametri innalzati, l'applicazione raggiunga comunque il limite. In questo caso avrebbe 200 volte piu' aggiornamenti rispetto alla situazione iniziale in quanto i limiti sono 200 volte i precedenti, quindi il rollback durerà di più.

ciao




Mauro Moschelli
SanPaoloIMI S.p.A.


> -----Original Message-----
> From: DB2 User Group - Italy List
> [mailto:[login to unmask email]On
> Behalf Of MASSIMO BIANCUCCI
> Sent: Thursday, August 03, 2006 1:49 PM
> To: [login to unmask email]
> Subject: R: incidenza sul elapsed time / CPU time dei paramentri
> NUMLOCKMAXUS e NUMLOCKMAXTS in ZPARM
>
>
> Prima l'obiezione: non necessariamente. Mediamente potrebbe
> essere vero nel senso che permetti ad un'applicazione di
> tenere più lock in contemporanea. Se questi sono derivanti da
> aggiornamenti veri e propri e non da "intenti di
> aggiornamento" su cui possono gravare altri parametri tipo
> ISOLATION(RS/RR), allora i tempi possono espandersi. Possiamo
> poi fare il caso limite contrario; aggiorno una pagina N
> milioni di volte, quindi mantengo un solo lock (nel caso di
> LOCKSIZE a pagina) e comunque il rollback mi costa una vita.
>
> La fase di rollback è normalmente più gravosa a causa della
> necessità di leggere i log records anche appartenenti ad
> altre UOR da cui l'affermazione solita per cui il rollback
> dura almeno quanto la UOR + un delta X variabile.
>
> Quanto costa un lock in termini di CPU: dipende dalla
> configurazione (data sharing o meno) e dalla potenza del
> processore. Non ti so dare un valore assoluto comunque si
> parla di pochi microsecondi. Se vuoi una risposta ufficiale,
> basta aprire un APAR informativo ad IBM e, sulla base della
> tua configurazione, ti risponderanno quasi certamente.
>
> Se hai un'esigenza applicativa per innalzare il valore dei
> locks contemporanei allora dovrebbe essere analizzata meglio
> prima di dire un no categorico. Certo i numeri richiesti non
> sono da poco e, probabilmente, anche dal punto di vista
> applicativo occorre interrogarsi sino in fondo prima di procedere.
>
> Tenete conto anche dell'eventuale aumento di richiesta di
> memoria per il mantenimento dei locks.
>
> Spero di essere stato utile.
>
> Ciao.
>
> -----Messaggio originale-----
> Da: DB2 User Group - Italy List
[mailto:[login to unmask email] Per conto di No Name Available
Inviato: giovedì 3 agosto 2006 11.54
A: [login to unmask email]
Oggetto: ZOS: incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS e NUMLOCKMAXTS in ZPARM

Ciao a tutti.
Ho necessità di avere qualche parere e consiglio su una obiezione che mi è stata fatta nel momento in cui ho richiesto di innalzare i valori dei due parametri seguenti in ZPARM:
NUMLKTS
NUMLKUS

attualmente i valori sono rispettivamente 1000 e 10000.

Ho proposto di innalzarli a 20000 e 200000 per esigenze di carattere applicativo.

L'obiezione che mi è sta sollevata è che "verrebbe allungato troppo il tempo necessario al rollback".

Da cui la mia domanda:
In fase di rollback l'IRLM fa qualcosa di più rispetto alla fase di forward della UR?
Ed un altra domanda:
quale può essere il tempo medio in microsecondi speso per l'aquisizione di un singolo lock?

Grazie a tutti in anticipo per le risposte.


Cassinadri Pierluigi
Database administrator
System and Support Specialist
Information Tecnology
Direct Line Insurance S.p.A.
Piazza Monte Titano, 10
20132 Milano - Italy
Tel. : (+39) 02-21725203
Fax. : (+39) 02-21725092
e-mail: [login to unmask email]
http://www.directline.it



Naviga e telefona senza limiti con Tiscali
Scopri le promozioni tiscali adsl: navighi e telefoni senza canone Telecom

http://abbonati.tiscali.it/adsl/

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy pu essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novit sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm


Il contenuto e gli allegati di questo messaggio sono strettamente
confidenziali, e ne sono vietati la diffusione e l'uso non autorizzato.

Le opinioni ivi eventualmente espresse sono quelle dell'autore: di
conseguenza il messaggio non costituisce impegno contrattuale tra
il Gruppo Sanpaolo ed il destinatario, e la banca non assume alcuna
responsabilita' riguardo ai contenuti del testo e dei relativi allegati,
ne' per eventuali intercettazioni, modifiche o danneggiamenti.

Qualora il presente messaggio Le fosse pervenuto per errore, Le saremmo
grati se lo distruggesse e, via e-mail, ce ne comunicasse l' errata
ricezione all'indirizzo [login to unmask email]


This e-mail (and any attachment(s)) is strictly confidential and for use
only by intended recipient(s). Any opinions therein expressed are those
of the author. Therefore its content doesn't represent any commitment
between Sanpaolo Group and the recipient(s) and no liability or
responsibility is accepted by Sanpaolo Group for the above mentioned
content.

Sanpaolo IMI S.p.A. is a Bank authorised by Banca d'Italia; Sanpaolo IMI
S.p.A., London Branch, is regulated by the Financial Services Authority
for the conduct of investment business in the UK.

If you are not an intended recipient(s), please notify
[login to unmask email] promptly and destroy this message.