Eine Abfrage wird mit größerer Wahrscheinlichkeit Parallelität verwenden, wenn die Abfrage wesentlich mehr Zeilen verarbeitet als zurückgegeben werden. In diesem Fall umfasst die Anzahl der verarbeiteten Zeilen die Größe aller gescannten Zeilen plus die Größe aller Zwischenergebnisse. Sie umfasst nur Zeilen, die gescannt wurden, weil ein Index zum Überspringen der meisten Teile der Tabelle verwendet wird. Ein idealer Fall ist ein GROUP BY für eine Einzelzeile über eine große Tabelle, wobei viele Zeilen gescannt werden und nur eine zurückgegeben wird. Abfragen für mehrere Gruppen kommen ebenfalls in Frage, falls die Gruppen groß sind. Auch Prädikate oder Join-Bedingungen, die viele Zeilen löschen, eignen sich für die parallele Verarbeitung.
In der folgenden Liste werden die Situationen aufgeführt, in denen eine Abfrage die Vorteile der Parallelität nicht nutzen kann, weder bei der Optimierung noch während der Ausführungszeit:
Der Computer verfügt nicht über mehrere Prozessoren.
Der Servercomputer ist nicht für die Verwendung mehrerer Prozessoren lizenziert. Sie können dies anhand der Servereigenschaft "NumLogicalProcessorsUsed" prüfen. Beachten Sie jedoch, dass Hyperthread-Prozessoren für abfrageinterne Parallelität nicht gezählt werden. Wenn es sich also um einen Hyperthread-Computer handelt, müssen Sie den Wert von "NumLogicalProcessorsUsed" durch 2 teilen.
Die Option "max_query_tasks" ist auf 1 gesetzt.
Die Option "priority" ist auf "background" gesetzt.
Die Anweisung, die die Abfrage enthält, ist keine SELECT-Anweisung.
Der Wert von "ActiveReq" war kürzlich größer oder gleich dem Wert von "NumLogicalProcessorsUsed" (teilen Sie die Anzahl der Prozessoren durch 2, wenn es sich um einen Hyperthread-Computer handelt).
Es gibt nicht genug verfügbare Aufgaben.
Siehe auch |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |