Was ist Oracle AWR?

awr bezieht sich auf „Automatisches Workload-Datenarchiv“. Es handelt sich um ein Speicherlager, das von der Oracle-Datenbank zum Sammeln, Verwalten und Verwalten statistischer Daten zur Leistung während des gesamten Betriebszeitraums der Datenbank verwendet wird und Optimierung. Die von awr gesammelten Daten werden regelmäßig auf der Festplatte gespeichert und können aus dem Datenwörterbuch und den generierten Leistungsberichten abgefragt werden.

Die Betriebsumgebung dieses Tutorials: Windows 7-System, Oracle 11g-Version, Dell G3-Computer.

Bei der Optimierung und Anpassung der Leistung der Oracle-Datenbank kann die aktuelle Situation bzw. der wahre Zustand der gesamten Datenbank im Betrieb erst dann überprüft, bekannt, verglichen, spekuliert oder für die Zukunft optimiert werden, wenn Anpassungen vorliegen Grundlage für unterstützende Empfehlungen. In der Oracle-Datenbank wird dieser Mechanismus durch AWR implementiert.

AWR ist ein Speicherlager, das von der Oracle-Datenbank zum Sammeln, Verwalten und Verwalten statistischer Daten zur Leistung während des gesamten Betriebs der Datenbank verwendet wird. Es ist die Grundlage für die Leistungsanpassung und -optimierung der Oracle-Datenbank.

1. Was ist AWR?

AWR ist die Abkürzung für Automatic Workload Repository, was auf Chinesisch als automatisches Workload-Datenarchiv bezeichnet wird. Da es sich um ein Warehouse handelt und Ladedaten speichert, werden auch Daten zur Datenbankleistung gespeichert. Das heißt, die Gesamtleistung einer bestimmten Datenbank oder Instanz während vergangener Vorgänge. AWR kann Leistungsdaten sammeln, verarbeiten, pflegen und Anpassungsreferenzen bereitstellen. Diese gesammelten Daten werden regelmäßig auf der Festplatte gespeichert und können aus dem Datenwörterbuch abgefragt und Leistungsberichte erstellt werden.

2. Inhalte der AWR-Statistikerfassung und -verarbeitung

  Objektstatistiken zur Bestimmung des Zugriffs und der Nutzung von Datenbanksegmenten

Statistiken basierend auf dem aktiven Zeitmodell, gelegen in den Ansichten v$sys_time_model und v$sess_time_model

System und Statistiksammlung auf Sitzungsebene, befindet sich in den Ansichten v$sesstat und v$systat

  Basierend auf SQL-Anweisungen mit hoher Auslastung wie verstrichener Zeit und CPU-Zeit

  ASH-Statistiken, die den Verlauf der letzten aktiven Sitzungen darstellen

3 Zwei wichtige beteiligte Parameter sind

• statistics_level

   BASIC:

     stellt nur die grundlegendste Funktion zur Erfassung von Leistungsdaten bereit und viele für Leistungsbasislinien erforderliche Statistiken werden nicht erfasst. Oracle empfiehlt die Verwendung dieses Werts nicht.

 TYPISCH:

  Dies ist der Standardwert. Es werden Segmentstatistiken, Zeitstatistiken und alle Empfehlungsklassenstatistiken erfasst.

  ALLE:

    Sammeln Sie alle typischen Ebenendaten, Betriebssystemzeitstatistiken und Zeilenquellenausführungsstatistiken usw. Es wird hauptsächlich im Debugmodus verwendet und wird nicht für Produktionsumgebungen empfohlen.

• timed_statistics

    Gibt an, ob zeitbezogene statistische Informationen erfasst werden. Wenn „statistics_level“ den Wert „TYPICAL“ oder „ALL“ hat, wird dieser Wert auf „true“ gesetzt, andernfalls wird er auf „false“ gesetzt. Es wird empfohlen, diesen Parameter zu überprüfen und auf true zu setzen.

4. Snapshots und Baselines

• Snapshots

  AWR-Snapshot dient dazu, die gesammelten Leistungsdaten in einer bestimmten Häufigkeit auf der Festplatte zu speichern. Diese Persistenz dient vor allem der späteren Analyse oder dem Vergleich. Gleichzeitig werden diese Leistungsdaten auch zur Leistungsdiagnose und Ausgabe von Diagnoseergebnissen an ADDM bereitgestellt. Das heißt: AWR tastet v$active_session_history einmal pro Stunde ab, speichert die Informationen auf der Festplatte und bewahrt sie 8 Tage lang auf (Standardwert 11g). Die alten Datensätze werden nach 8 Tagen überschrieben. Diese Sampling-Informationen werden in der Ansicht wrh$_active_session_history gespeichert. Die Probenahmehäufigkeit (1 Stunde) und die Aufbewahrungszeit (8 Tage) können den tatsächlichen Bedingungen angepasst werden.

• Baseline

  Nur mit Daten und Vergleichen können wir den Kern des Problems wirklich widerspiegeln. In der Oracle-Datenbank können wir also die historischen Daten der aktiven Sitzung während der Spitzenzeit der Geschäftslast kennzeichnen, oder genauer gesagt, die AWR-Persistenzdaten. Diese Bezeichnung ist die sogenannte Basislinie. Daher ist die Baseline ein Benchmark-Bericht über die Gesamtleistung der Datenbank während der Spitzenzeit des Unternehmens in einem bestimmten Zeitraum. Sobald die nachfolgende Datenbank Leistungsprobleme aufweist oder schlecht läuft, wird die Baseline verwendet und mit den Leistungsstatistiken verglichen Während des Leistungsproblemzeitraums können wir einen Differenzbericht zwischen den beiden erhalten, der dabei hilft, das Problem zu lokalisieren und zu lösen.

 Da die Basislinie vom AWR-Snapshot abhängt, werden beim Festlegen der Baseline die entsprechenden AWR-Snapshot-Daten beibehalten. Um die Belegung von Speicherplatz zu vermeiden, können wir auch eine entsprechende Aufbewahrungsfrist für die Baseline festlegen. Sobald die Aufbewahrungsfrist erreicht ist, bedeutet dies, dass die Baseline ungültig wird und die entsprechenden AWR-Snapshot-Daten automatisch gelöscht werden. Basierend auf der Baseline-Aufbewahrungsstrategie gibt es verschiedene Formen von Baselines, wie folgt: Feste Baselines (feste Baselines) Feste Baselines dienen dazu, einen bestimmten Zeitraum auszuwählen (kann auf snap_id basieren oder die Zeit direkt angeben) und eine Baseline für zu erstellen Verwenden Sie es. Der AWR-Bericht wird später verglichen und ausgegeben.

    Fenster-Grundlinie verschieben

      Oracle Database verwaltet automatisch eine systemdefinierte Grundlinie für das bewegliche Fenster. Die Standardfenstergröße für die systemdefinierte Basislinie des beweglichen Fensters ist der aktuelle AWR-Aufbewahrungszeitraum, der standardmäßig acht Tage beträgt. Wenn Sie adaptive Schwellenwerte verwenden möchten, sollten Sie die Verwendung eines größeren gleitenden Fensters (z. B. 30 Tage) in Betracht ziehen, damit die Schwellenwerte genau berechnet werden können. Sie können die Größe der Basislinie des beweglichen Fensters ändern, indem Sie die Anzahl der Tage im beweglichen Fenster so ändern, dass sie gleich oder kleiner als die Anzahl der Tage im AWR-Aufbewahrungszeitraum ist. Wenn Sie daher das bewegliche Fenster vergrößern möchten, müssen Sie zunächst die AWR-Aufbewahrungsdauer entsprechend verlängern. Der AWR-Aufbewahrungszeitraum und die Fenstergröße der systemdefinierten Grundlinie des beweglichen Fensters sind zwei unabhängige Parameter. Der AWR-Aufbewahrungszeitraum muss größer oder gleich der Fenstergröße der systemdefinierten Grundlinie des beweglichen Fensters sein.
Systemdefinierte Baselines bieten eine Standardbaseline für den OEM-Leistungsbildschirm, um seine Leistung mit der aktuellen Datenbankleistung zu vergleichen.
Hinweis: In Oracle Database 11g wurde die standardmäßige Aufbewahrungsfrist für Snapshot-Daten von sieben Tagen auf acht Tage geändert, um sicherzustellen, dass eine ganze Woche Leistungsdaten erfasst werden.

     Baseline-Vorlagen

     Baseline-Vorlagen können verwendet werden, um Baselines für zukünftige Zeiträume zu erstellen. Es gibt zwei Arten von Basislinienvorlagen: einzelne und sich wiederholende.
Eine einzelne Basislinienvorlage kann verwendet werden, um eine Basislinie für einen einzelnen zusammenhängenden Zeitraum in der Zukunft zu erstellen. Diese Methode ist nützlich, wenn Sie im Voraus einen bestimmten Zeitraum kennen, den Sie in Zukunft erfassen möchten. Beispielsweise möchten Sie möglicherweise AWR-Daten für einen Systemtest erfassen, der für das kommende Wochenende geplant ist. In diesem Fall kann eine separate Basisvorlage erstellt werden, um den Zeitraum, in dem der Test durchgeführt wird, automatisch zu erfassen.

        Baselines, die auf wiederkehrenden Zeitplänen basieren, können mithilfe der Vorlage für wiederkehrende Baselines erstellt und gelöscht werden. Dies ist nützlich, wenn Sie möchten, dass Oracle Database automatisch einen kontinuierlichen Zeitraum erfasst, um eine Basislinie dafür zu erstellen. Beispielsweise möchten Sie möglicherweise einen Monat lang jeden Montagmorgen AWR-Daten erfassen. In diesem Fall können Sie eine Vorlage für wiederkehrende Baselines erstellen, sodass Baselines jeden Montag automatisch nach einem wiederkehrenden Zeitplan erstellt werden und alte Baselines nach einem angegebenen Ablaufintervall (z. B. 1 Monat) automatisch gelöscht werden.

• Adaptive Schwellenwerte

Adaptive Schwellenwerte können Ihnen dabei helfen, Leistungsprobleme mit dem geringsten Overhead zu überwachen und zu erkennen. Adaptive Schwellenwerte legen automatisch Schwellenwerte für Warnungen und kritische Alarme für Systemmetriken anhand von Statistiken fest, die aus Metriken abgeleitet werden, die in einer Baseline mit gleitendem Fenster erfasst wurden. Diese Statistiken werden wöchentlich neu generiert und können aufgrund von Änderungen der Systemleistung im Laufe der Zeit zu neuen Schwellenwerten führen.

 Zum Beispiel sind viele Datenbanken tagsüber ein OLTP-System, müssen aber nachts einige Batch-Prozesse (z. B. das Erstellen von Berichten) ausführen. Leistungsmessungen der Reaktionszeit pro Transaktion können tagsüber nützlich sein, um Probleme mit der OLTP-Leistungsverschlechterung zu erkennen, aber dieser Schwellenwert ist für Batch-Jobs oft zu niedrig und löst häufig Alarme aus. Adaptive Schwellenwerte erkennen solche Arbeitsbelastungsmuster und legen automatisch unterschiedliche Schwellenwerte für Tag und Nacht fest.

  Es gibt zwei Arten von adaptiven Schwellenwerten:

 Prozentsatz des Maximalwerts: Der Schwellenwert wird als Vielfaches des Prozentsatzes des Maximalwerts der in der Basislinie des gleitenden Fensters beobachteten Daten berechnet.

 Wichtigkeitsgrad: Der Schwellenwert wird auf ein statistisches Perzentil festgelegt, um Werte über dem Schwellenwert basierend auf den Basisdaten des gleitenden Fensters zu beobachten, um den Grad der Anomalie widerzuspiegeln. Perzentile können wie folgt angegeben werden: Hoch (0,95), nur 5 von 100 können diesen Wert überschreiten; Sehr hoch (0,99): Nur 1 von 100 kann diesen Wert überschreiten; Schwerwiegend (0,999): 1000 Nur 1 Uhr kann diesen Wert überschreiten Wert; Extremwert (0,9999): Nur 1 Takt von 10.000 kann diesen Wert überschreiten.

  Prozentsätze der maximalen Schwellenwerte sind nützlich, wenn ein System für Spitzenlasten ausgelegt ist und Sie einen Alarm auslösen möchten, wenn sich die aktuelle Arbeitslast einem vorherigen Höchstwert nähert oder diesen überschreitet. Ein typisches Beispiel ist die Messung der pro Sekunde erzeugten Redo-Menge.

 Wichtigkeitsschwellenwerte sind in Situationen nützlich, in denen das System bei normalem Betrieb stabil ist, aber bei Leistungsverschlechterung innerhalb eines weiten Bereichs schwanken kann. Beispielsweise ist ein Maß für die Antwortzeit pro Transaktion auf einem optimierten OLTP-System stabil, kann jedoch stark schwanken, wenn Leistungsprobleme offensichtlich werden. Legen Sie Schwellenwerte für Wichtigkeitsstufen fest, um Alarme auszulösen, wenn die Umgebung ungewöhnliche Metrikwerte und eine abnormale Systemleistung erzeugt.

   Autor: Leshami

   Blog: http://blog.csdn.net/leshami

• Platzverbrauch

   Die folgenden Faktoren können zur Beurteilung des Platzverbrauchs von AWR herangezogen werden:

    Zu jedem gegebenen Zeitpunkt Zeit Die Zahl der aktiven Sitzungen im Zeitsystem;

    Snapshot-Zeitintervall, desto häufiger werden Snapshots generiert, was den von AWR erfassten Speicherplatz erhöht;

 Standardmäßig werden Snapshots stündlich erfasst und 8 Tage lang in der Datenbank gespeichert. Bei Verwendung dieser Standardeinstellungen benötigt ein typisches Parallelitätssystem mit 10 Sitzungen etwa 200–300 MB Speicherplatz zum Speichern von AWR-Daten. Beachten Sie jedoch bei der Reduzierung der Aufbewahrungszeit, dass unzureichende Daten in AWR die Genauigkeit und Präzision einiger Komponenten und Funktionen beeinträchtigen können: ADDM, SQL Tuning Advisor, Undo Advisor, Segment Advisor.

  Wenn möglich empfiehlt Oracle, die AWR-Aufbewahrungszeit so einzustellen, dass sie groß genug ist, um mindestens einen vollständigen Workload-Zyklus zu erfassen. Wenn Ihr System-Workload-Zyklus beispielsweise eine Woche beträgt, es sich um einen OLTP-Workload an Wochentagen handelt und Batch-Jobs an Wochenenden ausgeführt werden, muss die Standardaufbewahrungszeit von 8 Tagen nicht geändert werden. Wenn die Spitzenzeit Ihres Systems am Ende eines jeden Monats liegt, können Sie diese Aufbewahrungsfrist auf einen Monat ändern.

  In Ausnahmefällen können Sie das Snapshot-Intervall auf 0 ändern, um die automatische Snapshot-Sammlung zu deaktivieren. In diesem Fall wird die automatische Erfassung von Arbeitslast- und Statistikdaten gestoppt und viele der automatischen Verwaltungsfunktionen von Oracle Database sind nicht verfügbar. Darüber hinaus können Sie Snapshots nicht manuell erstellen. Daher empfiehlt Oracle dringend, die automatische Erfassung von Snapshots nicht zu deaktivieren.

5. AWR-Strukturdiagramm

Empfohlenes Tutorial: „Oracle Tutorial“

Das obige ist der detaillierte Inhalt vonWas ist Oracle AWR?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!