Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Datenbanklast
Die Datenbanklast (DB-Last) misst den Grad der Sitzungsaktivität in Ihrer Datenbank. DBLoadist die wichtigste Metrik in Performance Insights, und Performance Insights erfasst jede Sekunde die Datenbanklast.
Themen
Aktive Sitzungen
Eine Datenbank-Sitzung repräsentiert den Dialog einer Anwendung mit einer relationalen Datenbank. Eine aktive Sitzung ist eine Verbindung, die Arbeit an die DB-Engine gesendet hat und auf eine Antwort wartet.
Eine Sitzung ist aktiv, wenn sie entweder auf einer Ressource läuft CPU oder darauf wartet, dass eine Ressource verfügbar wird, sodass sie fortgesetzt werden kann. Beispielsweise kann eine aktive Sitzung darauf warten, dass eine Seite (oder ein Block) in den Arbeitsspeicher eingelesen wird, und dann verbraucht, CPU während Daten von der Seite gelesen werden.
Durchschnittliche aktive Sitzungen
Der Durchschnitt der aktiven Sitzungen (AAS) ist die Einheit für die DBLoad Metrik in Performance Insights. Es wird gemessen, wie viele Sitzungen gleichzeitig in der Datenbank aktiv sind.
Jede Sekunde ruft Performance-Insights eine Stichprobe der Anzahl der Sitzungen ab, die gleichzeitig eine Abfrage ausführen. Für jede aktive Sitzung sammelt Performance Insights die folgenden Daten:
-
SQLAussage
-
Sitzungsstatus (läuft weiter CPU oder wartet)
-
Host
-
Benutzer, der den ausführt SQL
Performance Insights berechnet das, AAS indem die Gesamtzahl der Sitzungen durch die Anzahl der Stichproben für einen bestimmten Zeitraum dividiert wird. Die folgende Tabelle zeigt beispielsweise 5 aufeinander folgende Stichproben einer laufenden Abfrage, die in Intervallen von 1 Sekunde abgefragt wurden.
| Beispiel | Anzahl der Sitzungen, die eine Abfrage ausführen | AAS | Berechnung |
|---|---|---|---|
| 1 | 2 | 2 | 2 Sitzungen insgesamt / 1 Stichprobe |
| 2 | 0 | 1 | 2 Sitzungen insgesamt / 2 Stichproben |
| 3 | 4 | 2 | 6 Sitzungen insgesamt / 3 Stichproben |
| 4 | 0 | 1.5 | 6 Sitzungen insgesamt / 4 Stichproben |
| 5 | 4 | 2 | 10 Sitzungen insgesamt / 5 Stichproben |
Im vorherigen Beispiel betrug die DB-Auslastung für das Zeitintervall 2. AAS Diese Messung bedeutet, dass im Durchschnitt 2 Sitzungen gleichzeitig während des Zeitraums aktiv waren, in dem die 5 Stichproben erfasst wurden.
Durchschnittliche aktive Ausführungen
Der Durchschnitt der aktiven Ausführungen (AAE) pro Sekunde bezieht sich aufAAS. Um das zu berechnenAAE, dividiert Performance Insights die Gesamtausführungszeit einer Abfrage durch das Zeitintervall. Die folgende Tabelle zeigt die AAE Berechnung für dieselbe Abfrage in der vorherigen Tabelle.
| Verstrichene Zeit | Gesamtausführungszeit | AAE | Berechnung |
|---|---|---|---|
| 60 | 120 | 2 | 120 Durchführungssekunden/60 verstrichene Sekunden |
| 120 | 120 | 1 | 120 Durchführungssekunden/120 verstrichene Sekunden |
| 180 | 380 | 2.11 | 380 Ausführungssekunden/180 verstrichene Sekunden |
| 240 | 380 | 1.58 | 380 Ausführungssekunden/240 verstrichene Sekunden |
| 300 | 600 | 2 | 600 Durchführungssekunden/300 verstrichene Sekunden |
In den meisten Fällen sind die AAE Werte AAS und für eine Abfrage ungefähr identisch. Da es sich bei den Eingaben zu den Berechnungen jedoch um unterschiedliche Datenquellen handelt, variieren die Berechnungen häufig geringfügig.
Dimensionen
Diedb.load Metrik unterscheidet sich von den anderen Zeitreihenmetriken, da Sie sie in Unterkomponenten aufteilen können, die als Dimensionen bezeichnet werden. Sie können sich Dimensionen als „Aufteilungs“-Kategorien für die verschiedenen Merkmale der DBLoad-Metrik vorstellen.
Wenn Sie Leistungsprobleme diagnostizieren, sind die folgenden Dimensionen oft am nützlichsten:
Eine vollständige Liste der Abmessungen für die Amazon RDS finden Sie unterDB-Last aufgeteilt nach Dimensionen.
Warteereignisse
Ein Wartungsereignis veranlasst eine SQL Anweisung, auf das Eintreten eines bestimmten Ereignisses zu warten, bevor sie weiter ausgeführt werden kann. Warteereignisse sind eine wichtige Dimension oder Kategorie für die DB-Last, da sie angeben, wo die Arbeit behindert wird.
Jede aktive Sitzung läuft entweder auf CPU oder wartet. Sitzungen verbrauchen beispielsweise viel, CPU wenn sie Speicher nach einem Puffer durchsuchen, eine Berechnung durchführen oder prozeduralen Code ausführen. Wenn Sitzungen nicht beansprucht werdenCPU, warten sie möglicherweise darauf, dass ein Speicherpuffer frei wird, eine Datendatei gelesen oder ein Protokoll geschrieben wird. Je länger eine Sitzung auf Ressourcen wartet, desto weniger Zeit läuft sie auf demCPU.
Wenn Sie eine Datenbank tunen, versuchen Sie oft, die Ressourcen herauszufinden, auf die Sitzungen warten. Beispielsweise könnten zwei oder drei Warteereignisse 90 Prozent der DB-Last ausmachen. Diese Maßnahme bedeutet, dass aktive Sitzungen im Durchschnitt die meiste Zeit damit verbringen, auf eine kleine Anzahl von Ressourcen zu warten. Wenn Sie die Ursache dieser Wartezeiten herausfinden können, können Sie eine Lösung versuchen.
Die Warteereignisse variieren je nach DB-Engine:
-
Informationen zu allen MariaDB- und My SQL Wait-Ereignissen finden Sie unter Übersichtstabellen für Warteereignisse
in der Dokumentation MeineSQL. -
Informationen zu allen SQL Postgre-Warteereignissen finden Sie in der SQLPostgre-Dokumentation unter The Statistics Collector > Tabellen mit Warteereignissen
. -
Informationen zu allen Oracle-Warteereignissen finden Sie unter Descriptions of Wait Events
in der Oracle-Dokumentation. -
Informationen zu allen SQL Server-Warteereignissen finden Sie in der Serverdokumentation unter Typen von Wartezeiten
. SQL
Anmerkung
Bei Oracle funktionieren Hintergrundprozesse manchmal auch ohne eine zugehörige SQL Anweisung. In diesen Fällen meldet Performance Insights die Art des Hintergrundprozesses, der mit einem Doppelpunkt und der diesem Hintergrundprozess zugeordneten Warteklasse verknüpft ist. Zu Arten des Hintergrundprozesses gehören LGWR, ARC0, PMON usw.
Wenn das Archivierungsprogramm beispielsweise I/O ausführt, ist der Performance Insights-Bericht ähnlic ARC1:System I/O. Gelegentlich fehlt auch der Hintergrundprozesstyp, und Performance Insights meldet nur die Warteklasse, z. B. :System
I/O.
Oben SQL
Während Warteereignisse auf Engpässe hinweisen, SQL zeigt oben, welche Abfragen am meisten zur Datenbanklast beitragen. Beispielsweise könnten derzeit viele Abfragen gleichzeitig in der Datenbank ausgeführt werden, aber eine einzelne Abfrage könnte 99 % der DB-Last verbrauchen. In diesem Fall könnte die hohe Belastung auf ein Problem mit der Abfrage hinweisen.
Standardmäßig zeigt die Performance Insights Insights-Konsole die wichtigsten SQL Abfragen an, die zur Datenbanklast beitragen. Die Konsole zeigt auch relevante Statistiken für jede Anweisung an. Um Leistungsprobleme für eine bestimmte Anweisung zu diagnostizieren, können Sie deren Ausführungsplan untersuchen.
Plans (Pläne)
Ein Ausführungsplan, auch einfach als Plan bezeichnet, ist eine Abfolge von Schritten, mit denen auf Daten zugegriffen wird. Ein Plan zum Verbinden der Tabellen t1 und t2 könnte beispielsweise alle Zeilen in t1 durchlaufen und jede Zeile mit einer Zeile in t2 vergleichen. In einer relationalen Datenbank ist ein Optimizer ein integrierter Code, der den effizientesten Plan für eine SQL Abfrage bestimmt.
Für DB-Instances sammelt Performance Insights automatisch Ausführungspläne. Um SQL Leistungsprobleme zu diagnostizieren, untersuchen Sie die erfassten Pläne für SQL Abfragen mit hohem Ressourcenbedarf. Die Pläne zeigen, wie die Datenbank Abfragen analysiert und ausgeführt hat.
Informationen zur Analyse der Datenbanklast mithilfe von Plänen finden Sie unter:
Erfassung der Pläne
Alle fünf Minuten identifiziert Performance Insights die ressourcenintensivsten Abfragen und erfasst deren Pläne. So müssen Sie nicht eine riesige Zahl von Plänen manuell erfassen und verwalten. Stattdessen können Sie die SQL Registerkarte „Top“ verwenden, um sich auf die Pläne für die problematischsten Abfragen zu konzentrieren.
Anmerkung
Performance Insights erfasst keine Pläne für Abfragen, deren Text die Obergrenze für erfassbaren Abfragetext überschreitet. Weitere Informationen finden Sie unter Zugreifen auf weiteren SQL Text im Performance Insights Insights-Dashboard.
Der Aufbewahrungszeitraum für Ausführungspläne ist der gleiche wie für Ihre Performance-Insights-Daten. Die Aufbewahrungseinstellung im kostenlosen Kontingent ist Standard (7 Tage). Um Ihre Leistungsdaten länger aufzubewahren, geben Sie 1–24 Monate an. Weitere Informationen zum Aufbewahrungszeitraum finden Sie unter Preisgestaltung und Datenspeicherung für Performance Insights.
Digest-Abfragen
Auf der SQL Registerkarte „Oben“ werden standardmäßig Digest-Abfragen angezeigt. Eine Digest-Abfrage hat selbst keinen Plan, aber alle Abfragen, die Literalwerte verwenden, haben Pläne. Eine Digest-Abfrage könnte beispielsweise den Text WHERE `email`=? enthalten. Das Digest kann zwei Abfragen enthalten, eine mit dem Text WHERE email=user1@example.com und eine mit WHERE
email=user2@example.com. Jede dieser Literalabfragen kann mehrere Pläne umfassen.
Wenn Sie eine Digest-Abfrage auswählen, zeigt die Konsole alle Pläne für untergeordnete Anweisungen der ausgewählten Digest-Abfrage an. So müssen Sie nicht alle untergeordneten Anweisungen durchsehen, um den Plan zu finden. Möglicherweise sehen Sie Pläne, die nicht in der angezeigten Liste der Top 10 der untergeordneten Anweisungen enthalten sind. Die Konsole zeigt Pläne für alle untergeordneten Abfragen an, für die Pläne erfasst wurden, unabhängig davon, ob sich die Abfragen unter den Top 10 befinden.
