Forum

Hallo zusammen,

Rolf, nachdem was ich jetzt gelesen habe spielt der Release(commit) auf package-Ebene keine Rolle.

Zitat: The duration of the claim on the object doesn’t depend on the RELEASE parameter (COMMIT or DEALLOCATE) specified during the BIND of a plan or package.

Link:
http://www.quest-pipelines.com/newsletter-v4/0203_A.htm

Meine Vermutung zur Situation:

REORG SHRLEVEL(CHANGE) läuft an und kommt bis zur SWITCH-Phase sehr schnell durch.
Bei etlichen erfolgreichen REORGs braucht er für die SWITCH-Phase 2 Sekunden.

Im Problemfall ist er 50 Sekunden in der Switch-Phase (vermutlich 48 davon beim drainen) bis er alle Lesesperren gedrained hat.

In der Zwischenzeit kommt mein RB5013 und möchte Lesen. Es muss sich jetzt hinter dem DRAIN-Lock vom REORG anstellen, da dieser keine weiteren Lesezugriffe mehr zuläßt.
Er bekommt jetzt 3 mal (ist so programmiert) -911 (alle 15 Sekunden) und stirbt dann endgültig.

Maßnahmen:

Gemäß dem Vorschlag von Ulrich bauen wir jetzt mal ein paar -DISPLAYS auf die zu reorganisierende resource RBDIUS unmittelbar vor dem REORG ein. Wir hoffen damit die Anwendung, die uns blockiert, finden zu können.

Dann sehen wir mal weiter.

Zusätzlich bin ich noch auf den DRAIN_WAIT gestossen.

Wenn ich den auf z. B. 10 Sekunden setzte, würde nach meinem Verstänsdniss das REORG-Utility nach 10 Sekunden erfolglosem Warten in der SWITCH-Pahse aufgeben und der Tablespace wäre wieder frei für Lesezugriffe. Dann käme vermutlich mein RB5013 ohne -911 durch.

Man müßte dann halt irgendwie sicherstellen, dass der REORG auch mal erfolgreich läuft, sonst fängt man sich durch den nicht reorganiserten tablespace ein neues Problem ein.

Was haltet ihr davon?

Gruß Klaus