Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 12.0.1 (Deutsch) » SQL Anywhere Server - SQL-Benutzerhandbuch » Abfrage und Änderung von Daten » Abfragen » Fortgeschrittene Aufgaben: Abfrageoptimierung » So funktioniert der Optimierer

 

Plan-Caching

Normalerweise wählt der Optimierer einen Ausführungsplan für eine Abfrage jedesmal, wenn diese Abfrage ausgeführt wird. Durch die Optimierung zur Ausführungszeit kann der Optimierer den Plan aufgrund des gegenwärtigen Systemzustands sowie der Werte der aktuellen Selektivitätsschätzungen und Schätzungen basierend auf den Werten der Hostvariablen auswählen. Bei Abfragen, die häufig ausgeführt werden, können die Kosten der Abfrageoptimierung die Vorteile einer Optimierung zur Ausführungszeit aufwiegen. Um die Kosten für das wiederholte Optimieren dieser Anweisungen zu reduzieren, zieht der SQL Anywhere-Server für die folgenden Elemente ein Ablegen der Pläne im Cache in Betracht:

  • Alle Anweisungen, die in gespeicherten Prozeduren, benutzerdefinierten Funktionen und Triggern ausgeführt werden.

  • SELECT-, INSERT-, UPDATE- oder DELETE-Anweisungen, die sich zum Umgehen der Optimierung eignen.

    Bei INSERT-Anweisungen sind lediglich INSERT...VALUES-Anweisungen für die Aufnahme in den Cache geeignet. INSERT...ON EXISTING-Anweisungen sind nicht für die Aufnahme in den Cache geeignet.

    Bei UPDATE- und DELETE-Anweisungen muss die WHERE-Klausel verwendet werden und Suchbedingungen enthalten, die den Primärschlüssel zur Identifizierung einer Zeile verwenden. Wenn das Caching von Plänen gewünscht ist, sind keine zusätzlichen Suchbedingungen erlaubt. Außerdem wird eine UPDATE-Anweisung vom Caching ausgeschlossen, wenn sie eine SET-Klausel mit einer Variablenzuweisung enthält.

Wenn eine dieser Anweisungen mehrmals von einer Verbindung ausgeführt wurde, erstellt der Optimierer einen wieder verwendbaren Plan für die Anweisung, ohne die Hostvariablenwerte zu kennen. Der wieder verwendbare Plan verursacht möglicherweise höhere Kosten, weil Hostvariablenwerte nicht für Selektivitätsschätzungen oder semantische Abfragetransformationen verwendet werden können. Falls der wieder verwendbare Plan die gleiche Struktur hat wie die Pläne, die bei den vorherigen Ausführungen der Anweisung erstellt wurden, nimmt der Datenbankserver den wieder verwendbaren Plan in den Plancache auf. Der Ausführungsplan wird nicht in den Cachespeicher geschrieben, wenn der Nutzen einer Optimierung bei jeder Ausführung die Einsparungen einer Umgehung der Optimierung übersteigt.

Falls ein Ausführungsplan eine materialisierte Ansicht verwendet, die nicht durch die Anweisung referenziert wurde, und die Option "materialized_view_optimization" auf einen anderen Wert als "Stale" gesetzt wurde, wird der Ausführungsplan nicht im Cache abgelegt und die Anweisung wird wieder optimiert, wenn die gespeicherte Prozedur, die benutzerdefinierte Funktion oder der Trigger das nächste Mal aufgerufen wird.

Der Plancache ist ein Cache pro Verbindung für die Datenstrukturen, die zur Ausführung eines Zugriffsplans verwendet werden. Für die Wiederverwendung des im Cache abgelegten Plans wird der Plan im Cache herausgesucht und wieder in seinen anfänglichen Zustand versetzt. Üblicherweise ist dies signifikant schneller als die Anweisung in allen Abfrageverarbeitungsphasen abzuarbeiten. Im Cache abgelegte Pläne können auf der Festplatte gespeichert werden, wenn sie selten benötigt werden, und erhöhen so nicht das Caching. Der Optimierer optimiert Abfragen regelmäßig neu, um zu überprüfen, ob der im Cache abgelegte Plan immer noch effizient ist.

Die maximale Anzahl der im Cache abgelegten Pläne wird mit der Option "max_plans_cached" festgelegt. Standardwert ist "20". Um das Plan-Caching zu deaktivieren, setzen Sie diese Option auf 0.

Sie können die Statistik "QueryCachedPlans" verwenden, um zu zeigen, wie viele Abfrageausführungspläne zurzeit im Cache sind. Diese Eigenschaft können Sie mithilfe der Funktion CONNECTION_PROPERTY abrufen, um festzustellen, wie viele Abfrageausführungspläne für eine bestimmte Verbindung im Cache abgelegt sind. Mit der Funktion DB_PROPERTY kann die Anzahl der Ausführungspläne, die für alle Verbindungen im Cache sind, berechnet werden. Diese Eigenschaft kann mit "QueryCachePages", "QueryOptimized", "QueryBypassed" und "QueryReused" kombiniert werden, um die beste Einstellung für die Option "max_plans_cached" zu ermitteln.

Mit der Datenbank- oder QueryCachePages-Verbindungseigenschaft können Sie die Anzahl der verwendeten Seiten für das Caching von Ausführungsplänen ermitteln. Diese Seiten belegen zwar Speicherplatz in der temporären Datei, sind aber nicht unbedingt speicherresident.

 Siehe auch