In der letzten Woche musste ich in möglichst kurzer Zeit (und im zum Teil weiter laufenden Betrieb) eine größere Zahl von Aggregationstabellen neu aufbauen und möglicherweise hätte ich dabei Zeit sparen können, wenn ich bei der Abarbeitung meines Blog-Readers nicht so weit im Rückstand wäre. Immerhin hat Jonathan Lewis zuletzt ein Verhalten beschrieben, das mir unter Umständen ein paar Anregungen geliefert hätte. In seinem Beispiel erfolgte eine CTAS-Operation in 4 min, während eine entsprechende INSERT APPEND Operation 45 min erforderte. Den ersten Hinweis in diesem Zusammenhang lieferte (mal wieder) der Plan, in dem deutlich zu erkennen ist, dass zwischen den Schritten INSERT STATEMENT und LOAD AS SELECT keine PX Schritte zu finden sind - offenbar war hier parallel dml nicht aktiviert worden - und das war unter anderem auch etwas, was mir bei meinem Wiederherstellungseinsatz zunächst unterlaufen war. Im Beispiel des Artikels half die Parallelisierung des INSERTs allerdings nicht deutlich weiter: hier erschien nach der Aktivierung von parallel dml im Plan ein Schritt PX SEND RANDOM LOCAL, der darauf hin deutet, dass Oracle im Fall einer partitionierten Zieltabelle versucht, die Verwendung der Slaves möglichst effektiv an die Partitionsanzahl anzupassen. Ist die Anzahl der Slaves größer als die Anzahl der Partitionen, dann kann das PX SEND RANDOM LOCAL auftreten. Um das Verhalten zu ändern, kann man einen pq_distribute Hint einsetzen, der im Beispiel nicht nur den PX SEND RANDOM LOCAL Schritt (und das korrespondierende PX RECEIVE) beseitigt, sondern auch einen HASH JOIN statt eines HASH JOIN BUFFERED hervorruft. Damit konnte die Laufzeit auf 7 min reduziert werden.
Tatsächlich hätte mir der Artikel aber vermutlich nur bedingt geholfen, da ich in der gegebenen Situation hauptsächlich versucht habe, die erforderlichen Operationen ohne größere Pausen und massivere Fehler über die Bühne zu bringen. Oder wie der Herr Lewis es ausdrückt: "but real-world DBAs don’t necessarily have all the time for investigations that I do." Jedenfalls nicht, wenn die Anwender warten.
Keine Kommentare:
Kommentar veröffentlichen