DB2 - Performance Tuning  DB2 - Locking ('insert-select')

DB2 - Performance Tuning

Basierend auf die Erfahrungen aus Performancetests mit DB2 sollte der TableSpace am besten in einem Verzeichnis auf einer anderen Festplatte erzeugt werden z.B.:
create tablespace ts1 managed by database using (file '/temp/db2/ts1' 100000) (...wo die Log-Files stehen sieht man mit 'db2 get db cfg for ez' unter dem Parameter 'Path to log files')
Zudem sind noch folgende Befehle abzusetzten:

• db2set db2_rr_to_rs = yes
• db2 update db cfg for ez using LOGFILSIZ 50000
• db2 update db cfg for ez using LOGPRIMARY 50
• db2 update db cfg for ez using LOCKLIST 500

DB2 - Locking ('insert-select')

Es gibt im Prinzip 2 Möglichkeiten, dem Lock-Konflikt 'insert-select' aus dem Wege zu gehen. Das Setzen von DB2_RR_TO_RS verringert zwar Sperren auf dem Index, hilft in Ihrem Fall jedoch nicht. Entscheidend ist, ob der Zugriffspfad beim select über die neu eingefügte row führt oder nicht. Wie Sie richtigerweise festgestellt haben, erzeugt der uncommitted insert einen x-lock auf den betroffenen Datensatz und einen ix-lock auf die Tabelle. Ein 'select *' des anderen users verursacht stets einen tablescan und dieser führt auch über die gesperrte row. Die Folge ist bei isolation=CS der timeout des select.

Möglichkeit 1:
Wenn der select rein über den Index abgearbeitet wird und der vom anderen user eingefügte Datensatz nicht zur Ergebnismenge gehört, so stört sich der select nicht am gehaltenen x-lock vom insert. Beisp.: Index ist definiert auf 'wert' user a:insert into tabelle values(99) , user b: select * from tabelle where wert=5 (nur mal als einfaches Beispiel) der select ginge rein über einen IndexScan und bekommt keinen timeout. Wenn Sie dagegen reine 'select *' ohne weitere Qualifizierung durch eine where Klausel absetzen, so läuft der daraus resultierende TableScan gegen den harten x-lock.

Möglichkeit 2:
Sie ändern den Isolation Level auf UR wie in meiner vorherigen mail beschrieben. Also von cmdline 'change isolation to ur' vor dem connect, oder (bei Zugriff über JAVA/JDBC) durch die setTransactionIsolation method of java.sql.Connection. Accepted values are:
TRANSACTION_READ_UNCOMMITTED : Uncommitted Read
TRANSACTION_READ_COMMITTED : Cursor Stability
TRANSACTION_REPEATABLE_READ : Read Stability
TRANSACTION_SERIALIZABLE : Repeatable Read
Auswirkung von UR beim user, der das select absetzt: der 'select *' kann alle Datensätze lesen, auch wenn uncommitted inserts existieren und x-locks auf einzelne Sätze halten. Dies ist eigentlich eine naheliegende Möglichkeit in Ihrem Fall. Ob Sie es aus Sicht der Anwendungslogik jedoch wollen/dürfen, dass u.U. auch noch nicht durch commit abgeschlossene Sätze gelesen werden können, müssen Sie dabei entscheiden bzw. berücksichtigen.