Database Reference
In-Depth Information
Die jeweilige Remote-Session wartete auf „SQL*Net message from client“:
(YHQW6HFLQ:DLW
64/1HWPHVVDJHIURPFOLHQW
64/1HWPHVVDJHWRFOLHQW
64/1HWPRUHGDWDWRFOLHQW
Man könnte sagen, dass diese 40 s von insgesamt 492 nicht so viel ausmachen. Das ist aber
lediglich ein Test, bei dem ich speziell die Tabellen ohne Indices angelegt habe, damit die
Laufzeit groß genug wäre, um mir alle Messungen auf den 2 relativ kleinen Tabellen zu
ermöglichen. Stellen Sie sich aber vor, dass die beiden Tabellen wesentlich größer sind
und die Tabelle T2 einen Index hat, so dass der Zugriff nicht über einen Full Table Scan,
sondern über einen Index Range oder Unique Scan erfolgt. Dann sollte die Wartezeit auf
„SQL*Net message from client“ und deren Anteil in der Gesamtlaufzeit viel größer sein.
Fazit
Auch die Leerlauf-Wartestatistiken können manchmal helfen, dem Problem auf die
Spur zu kommen.
3.2.2.2 Ein Fall mit der Wartestatistik „PX Deq Credit: send blkd“
Bei einer Firma lief ein Reorganisationsprozess auf einer Oracle 10.2.0.4 Datenbank weit
über ein dafür vorgesehenen Zeitfenster hinaus. Das führte dazu, dass die Daten mona-
telang nicht reorganisiert blieben und die Performanz sich immer mehr verschlechterte.
In Abb.
3.1
sind Wartestatistiken dargestellt, die während eines Testlaufs dieses Reorga-
nisationsprozesses entstanden sind.
Wie man sieht, wartete das System hauptsächlich auf „PX Deq Credit: send blkd“ und
auf „enq: CF - contention“. Was sagen uns diese 2 Warteereignisse? Das erste deutet darauf
hin, dass man parallele Operationen also PDML-Kommandos einsetzte (PDML bedeu-
tet „parallel data manipulation language“). Das zweite sagt uns, dass man diese Operatio-
nen sehr wahrscheinlich im NOLOGGING Modus ausführte. In diesem Fall protokolliert
Oracle nicht wiederherstellbare (unrecoverable) SCNs (system change number) in dem
Control File. Dies kann eine Wartezeit auf „enq: CF - contention“ verursachen.
Da das Warteereignis „PX Deq Credit: send blkd“ zu den „idle events“ zählt, hat nie-
mand versucht, diese Wartezeit zu reduzieren. Es gibt in der Tat keine allgemeinen Me-
thoden zur Reduzierung der Wartezeit für dieses Warteereignis. Man hätte aber versuchen
können, die Kommunikation zwischen den parallelen Prozessen generell zu beschleuni-
gen. Das hätte man durch die Erhöhung der Parametereinstellung
parallel_execution_mes-
sage_size
probieren können. Aus meiner Erfahrung wusste ich, dass man oft auf diesem
Wege auch die Wartezeit auf „PX Deq Credit: send blkd“ reduzieren kann. Bei Oracle 10.2
