Das Wichtigste, was man über die Oracle-Parallelität wissen muss, ist, dass sie kompliziert ist. Die Optimierung der Parallelität erfordert viel Oracle-Wissen, das Lesen der Handbücher, das Überprüfen vieler Parameter, das Testen lang laufender Abfragen und viel Skepsis.
Stellen Sie die richtigen Fragen
Parallele Probleme beinhalten wirklich drei verschiedene Fragen:
- Wie viele parallele Server wurden angefordert?
- Wie viele parallele Server wurden zugewiesen?
- Wie viele parallele Server wurden sinnvoll eingesetzt?
Verwenden Sie die besten Tools
Gehen Sie direkt zum besten Tool – SQL Monitoring mit aktiven Berichten. Suchen Sie Ihre SQL_ID und generieren Sie den HTML-Bericht:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual;
. Nur so kann festgestellt werden, wie viel Zeit für jeden Schritt im Ausführungsplan aufgewendet wurde. Und es wird Ihnen sagen, wie viel Parallelität effektiv eingesetzt wurde und wo. Zum Beispiel:
Eine weitere gute Option ist type => 'text'
. Es enthält nicht ganz so viele Informationen, lässt sich aber schneller anzeigen und ist einfacher zu teilen.
Die SQL-Überwachung umfasst auch die angeforderte DOP und die zugewiesene DOP:
Ein 100-zeiliges paralleles select
kann wunderbar laufen, aber dann hält alles wegen einer ungecachten Sequenz in einem einzigen Schritt an. Sie können stundenlang auf einen Erklärungsplan, eine Ablaufverfolgung oder einen AWR-Bericht starren, ohne das Problem zu sehen. Der aktive Bericht macht es fast trivial, die langsamen Schritte zu finden. Verschwenden Sie keine Zeit damit, zu raten, wo das Problem liegt.
Es werden jedoch noch andere Werkzeuge benötigt. Ein Explain-Plan, der mit explain plan for ...
generiert wurde und select * from table(dbms_xplan.display)
; wird einige wichtige Informationen liefern. Insbesondere die Notes
Abschnitt kann viele Gründe enthalten, warum die Abfrage keine Parallelität angefordert hat.
Aber WARUM habe ich diese Anzahl paralleler Server bekommen?
Die relevanten Informationen sind auf mehrere verschiedene Handbücher verteilt, die sehr nützlich, aber gelegentlich ungenau oder irreführend sind. Es gibt viele Mythen und viele schlechte Ratschläge über Parallelität. Und die Technologie ändert sich mit jeder Version erheblich.
Fasst man alle seriösen Quellen zusammen, ist die Liste der Einflussfaktoren auf die Anzahl paralleler Server erstaunlich groß. Die folgende Liste ist ungefähr nach den meiner Meinung nach wichtigsten Faktoren geordnet:
- Parallelität zwischen Operationen Jede Abfrage, die Sortierung oder Gruppierung verwendet, weist doppelt so viele parallele Server wie der DOP zu. Dies ist wahrscheinlich für den Mythos „Oracle weist so viele parallele Server wie möglich zu!“ verantwortlich.
- Abfragehinweis Vorzugsweise ein Hinweis auf Anweisungsebene wie
/*+ parallel */
, oder möglicherweise ein Hinweis auf Objektebene wie/*+ noparallel(table1) */
. Wenn ein bestimmter Schritt eines Plans seriell ausgeführt wird, liegt dies normalerweise an Hinweisen auf Objektebene, die nur einen Teil der Abfrage betreffen. - Rekursives SQL Einige Operationen können parallel ausgeführt werden, können jedoch durch rekursives SQL effektiv serialisiert werden. Zum Beispiel eine nicht zwischengespeicherte Sequenz auf einer großen Einfügung. Rekursives SQL, das zum Analysieren der Anweisung generiert wird, ist ebenfalls seriell; B. dynamische Stichprobenabfragen.
- Sitzung ändern
alter session [force|enable] parallel [query|dml|ddl];
Beachten Sie, dass paralleles DML standardmäßig deaktiviert ist. - Tabellengrad
- Indexgrad
- Index war billiger Parallele Hinweise weisen den Optimierer nur an, einen vollständigen Tabellenscan mit einem bestimmten DOP in Betracht zu ziehen. Sie erzwingen nicht wirklich Parallelität. Dem Optimierer steht es immer noch frei, einen seriellen Index-Zugriff zu verwenden, wenn er es für billiger hält. (Die
FULL
Hinweis kann helfen, dieses Problem zu lösen.) - Planverwaltung SQL Plan Baselines, Outlines, Profile, Advanced Rewrite und SQL Translators können alle den Grad der Parallelität hinter Ihrem Rücken verändern. Überprüfen Sie den Hinweisabschnitt des Plans.
- Ausgabe Nur Enterprise und Personal Editions erlauben parallele Operationen. Außer für das Paket DBMS_PARALLEL_EXECUTE.
- PARALLEL_ADAPTIVE_MULTI_USER
- PARALLEL_AUTOMATIC_TUNING
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVER Dies ist die Obergrenze für das gesamte System. Hier gibt es einen Kompromiss. Der gleichzeitige Betrieb zu vieler paralleler Server schadet dem System. Das Herunterstufen einer Abfrage auf eine serielle Abfrage kann jedoch für einige Abfragen katastrophal sein.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVER
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- Anzahl der RAC-Knoten Ein weiterer Multiplikator für den Standard-DOP.
- CPU_COUNT Wenn das Standard-DOP verwendet wird.
- RECOVERY_PARALLELISM
- FAST_START_PARALLEL_ROLLBACK
- Profil
SESSIONS_PER_USER
schränkt auch parallele Server ein. - Ressourcenmanager
- Systemlast Wenn parallel_adaptive_multi_user wahr ist. Wahrscheinlich unmöglich zu erraten, wann Oracle mit der Drosselung beginnen wird.
- PROZESSE
- Parallel-DML-Einschränkungen In folgenden Fällen funktioniert Parallel DML nicht:
- KOMPATIBEL <9.2 für Intra-Partition
- WERTE EINFÜGEN, Tabellen mit Triggern
- Replikation
- selbstreferenzielle Integrität oder Löschkaskade oder zurückgestellte Integritätsbedingungen
- Zugriff auf eine Objektspalte
- nicht partitionierte Tabelle mit LOB
- partitionsinterne Parallelität mit einem LOB
- verteilte Transaktion
- geclusterte Tabellen
- temporäre Tabellen
- Skalare Unterabfragen werden nicht parallel ausgeführt? Das steht im Handbuch, und ich wünschte, das wäre stimmt, aber meine Tests zeigen, dass die Parallelität hier in 11g funktioniert.
- ENQUEUE_RESOURCES Versteckter Parameter in 10g, ist das noch relevant?
- Index-organisierte Tabellen Kann nicht parallel direkt in IOTs eingefügt werden? (Ist das immer noch wahr?)
- Anforderungen an parallele Pipeline-Funktionen Muss einen
CURSOR
verwenden (?). TODO. - Funktionen müssen PARALLEL_ENABLE sein
- Art der Aussage Ältere Versionen beschränkten die Parallelität auf DML abhängig von der Partitionierung. Einige der aktuellen Handbücher enthalten dies immer noch, aber es ist sicherlich nicht mehr wahr.
- Anzahl der Partitionen Nur für partitionsweise Joins in älteren Versionen.(?)
- Fehler Insbesondere habe ich viele Fehler beim Parsen gesehen. Oracle weist die richtige Anzahl paralleler Server zu, aber es passiert nichts, da sie alle auf Ereignisse wie
cursor: pin s wait on x
warten .
Diese Liste ist sicherlich nicht vollständig und enthält keine 12c-Funktionen. Und es behebt keine Betriebssystem- und Hardwareprobleme. Und es beantwortet nicht die schrecklich schwierige Frage:"Was ist der beste Grad an Parallelität?" (Kurze Antwort:mehr ist normalerweise besser, aber auf Kosten anderer Prozesse.) Hoffentlich gibt es Ihnen zumindest ein Gefühl dafür, wie schwierig diese Probleme sein können, und einen guten Ausgangspunkt, um mit der Suche zu beginnen.