DSN TIAUL und DSN TEP4 Multi-Row-Fetch
- Dieses Thema hat 1 Antwort und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 14 Jahre von
Anonym.
-
AuthorPosts
-
5. September 2009 um 19:11 Uhr #4048
AnonymInaktivHi Forum,
aufgrund immer wiederkehrender Nachfrage:
DSN TIAULÂ wurde von IBM, wie DSN TEP4Â mit DB2 Version 8 auf Multi-Row-Access umgestellt.
Der 2. DSN TIAUL -Parameter bietet Einflußnahme auf den Wert "Rows per Fetch", wobei der Default Wert 100 beträgt. Der Wert 1 schaltet Multi-Row-Fetch aus, der höchster Wert kann 32767 sein.
Lt. Performance Messungen sollen alleine durch Nutzung des DSN TIAUL -Defaults gegenüber dem DSN TIAUL der Version 7 bereits 7% CPU-Kosten eingespart werden. In einer Testanordnung soll der Wert 32767 die größte Ersparnis gebracht haben, sich aber nicht linear sondern nur degressiv zum Default Wert 100 verhalten haben. Das Ergebnis mag auch abhängig von der Länge einer Row und natürlich dem Selektionsumfang sein.
Weitere Informationsquellen:
- Why move to V8 NFM: Reason #2: Because Multi-row FETCH is just so cool : http://it.toolbox.com/blogs/db2zos/why-move-to-v8-nfm-reason-2-because-multirow-fetch-is-just-so-cool-12229
- http://blogs.ittoolbox.com/database/db2zos/archives/kewl-db2-for-zos-version-8-feature-part-2a-multirow-insert-fetch-7377
- http://it.toolbox.com/blogs/db2zos/
- http://www.redbooks.ibm.com/abstracts/sg246465.html
Gruß
Gernot
23. September 2009 um 9:21 Uhr #4213
AnonymInaktivHi Gernot,
hast Du eine Idee, warum der Default bei 100 Sätzen liegt? Auch wenn die weitere Ersparnis nicht im gleichen Masse grösser wird, wenn bei 32.767 die grösste Ersparnis vorliegt, sollte man den Wert doch auch einsetzen.
Irgend einen Nachteil muss der doch dann haben. Krallt sich der TIAUL vllt. immer den Speicher, um die 32767 Sätze unterzubringen; was dann ggfs Nachteile für das "Rest-System" nach sich zieht?
Grüsse
Alexander
-
AuthorPosts
You must be logged in to reply to this topic.