EXPDP und IMPDP - hängen und schlechte Performance
Innerhalb von kurzer Zeit ist auf mehreren Systemen bei einem Kunden das gleiche Phänomen aufgetreten. Wenn man EXPDP oder IMPDP startet, kommt der Versionsprompt und dann passiert einmal 30-45 Minuten lang nichts. Danach werden die Tabelle sehr langsam exportiert bzw. importiert. Bei einem regelmäßigen Job, der normalerweise unter einer Minute braucht, dauerte es ca. 100 mal so lange wie üblich.
expdp \'/ as sysdba\' dumpfile=dbmtest.dmp tables=aud$
Export: Release 11.2.0.4.0 - Production on Mo Dez 1 12:42:09 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Angemeldet bei: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning option
Die Analyse
Sobald EXPDP bzw. IMPDP gestartet sind, gehen 1-2 Session im Enterprise Manager auf QUEUING wobei der Event immer "Streams AQ: enqueue blocked on low memory" ist. Wenn man sich die Sessions ansieht findet man Beispielsweise das folgende:
BEGIN sys.kupc$que_int.send(:1, :2, :3); END;
oder
BEGIN :1 := sys.kupc$que_int.transceive_int(:2, :3, :4, :5, :6); END;
Suche auf support.oracle.com
Die Suche auf support.oracle.com liefert (unter anderem):
-
EXPDP And IMPDP Slow Performance In 11gR2 and 12cR1 And Waits On Streams AQ: Enqueue Blocked On Low Memory (Doc ID 1596645.1)
-
DataPump Export Is Extremely Slow For Schema With Partitioned Tables (Doc ID 1515434.1)
-
BUG 18649769 (Oracle 11.2.0.3.5) SLOW EXPDP ACCORDING TO GROWS IN DUMPFILE SIZE
-
BUG 6440525 (Oracle 10.2.0.x) EXPDP VERY SLOW, GETTING ERROR ORA-25228
Abgesehen von den BUGs, die bei unserem Kunden auf Grund der Version nicht zutreffen, gibt es folgende Ursachen und Lösungsvorschläge:
-
Data Dictionary Statistik veraltet: DBMS_STATS.GATHER_DICTIONARY_STATS
-
Streams Pool zu klein: Auf 150-300MB vergrößern
-
Resumable Timeout verschleiert den Grund: RESUMABLE_TIMEOUT=0
Aber das brachte alles keinen Erfolg. Erst der Vergleich der Instance Parameter von einer Datenbank wo die Performance OK ist, mit einer wo die Performance nicht passt, brachte die Lösung
Die Lösung
Die Lösung war so einfach wie verblüffend. AQ_TM_PROCESSES war auf 0 wo die Performanceprobleme auftraten
alter system set aq_tm_processes=2 scope=both;
Interessant, dass in keinem Artikel auf support.oracle.com dieser hinweise zu finden war (zumindest nicht in jenen, die wir angesehen haben)