incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS eNUMLOCKMAXTS in ZPARM

Max Scarpa

incidenza sul elapsed time / CPU time dei paramentri NUMLOCKMAXUS eNUMLOCKMAXTS in ZPARM
Presumo che tale richiesta nasca da errori tipo 00C90096 durante
l'esecuzione di un pgm, senza LOCK ESCALATION. E la richiesta sia di un
applicativo che di solito si presentavasu batch che facevano massicci
update senza o con pochi commit. . Di solito succedeva così e si litigava
sulla politica di commit che di solito si materializzava su batch che
facevano massicci update senza o con pochi commit.

Innalzando questi valori 'stressi' di più il sistema nel senso che usi
memoria (ipotizzando LOCK IRLM puri senza lock avoidance), hai
potenzialmente più deadlock allargando 'l'area' di lock in caso di RR/RS
(senza dimenticare CURRENTDATA) . Magari LOCK TABLE in EXCLUSIVE MODE
potrebbe aiutarti. Io stresserei un pò gli applicativi prima di innalzare
i valori.

Ma di per se questi valori (sono dei 'troppo pieni' per il DB2) non sono
correlati al rollback che è proporzionale agli update che fai. Tieni
conto che anche il rollback deve comunque scrivere sul log per cui ai bei
tempi si diceva che il rollback durava il doppio + una parte variabile
(per es. se devo debordare negli archive log migrati da HSM o su cassetta,
se la macchina è carica, i BP che comunque sono utilizzati ecc. Tieni
conto che ROLLBACK è una must-complete operation e può far cadere un DB2,
da cui le possibilità di differire il rollback alla ripartenza delle
ultime versioni di DB2) come detto dal prode Max Biancucci. Sul campo l'ho
sperimentato diverse volte (per la maggior parte batch) e variava da 2,5x
a 4x la durata (elapsed) normale di un job, questo per la mia esperienza.

Quanto dura un lock varia, di solito è brevissimo (ipotizzando CS), ma
dipende, può succedere che hai messaggi DRX quando un batch che tiene
molti lock è poco servito da WLM (o peggio ancora IRLM è basso come
SERVICE CLASS) per es. per cui hai una lock elongation anche se il DB2 va
bene. Tanto per dire che non è sempre e solo una questione di DB2. Non hai
deadlock ma hai comunque lock che durano molto. Considera bene (si veda
per es. le note di Macera, note di S. Lawson) che la LOCK detection di per
se è un processo molto lungo in termini di tempi di computer (con il grace
period etc). Infatti Susan LAwosn (mi pare) proponeva di abbassare il
default.

Giusto qualche considerazione buttata lì. Ci sono molte paper che parlano
di lock e rollback (e commit).

HTH

Max Scarpa


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