SQL-Tracing in Autonomous Database on Dedicated Exadata Infrastructure verwenden
Mit SQL-Tracing können Sie mit Autonomous Database on Dedicated Exadata Infrastructure die Quelle einer übermäßigen Datenbank-Workload identifizieren, beispielsweise eine High-Load-SQL-Anweisung in Ihrer Anwendung.
SQL-Tracing
Wenn ein Anwendungsvorgang länger als erwartet dauert, können Sie mit einem Trace aller im Rahmen dieses Vorgangs ausgeführten SQL-Anweisungen mit Details wie der Zeit, die diese SQL-Anweisung in den Parse-, Ausführungs- und Abrufphasen verbracht hat, die Ursache des Performanceproblems identifizieren und beheben. Um dies zu erreichen, können Sie SQL-Tracing in einer Autonomous Database verwenden.
- Beginnen Sie mit der Konfiguration der Datenbank, um SQL Trace-Dateien zu speichern. Weitere Informationen finden Sie unter SQL-Tracing in Autonomous Database konfigurieren.
- Aktivieren Sie dann das SQL-Tracing. Siehe SQL-Tracing in Autonomous Database aktivieren.
Hinweis:
Das Aktivieren von SQL-Tracing kann die Anwendungsperformance für die Session beeinträchtigen, während die Traceerfassung aktiviert ist. Diese Performanceauswirkungen sind aufgrund des Overheads beim Erfassen und Speichern von Tracedaten zu erwarten. - Um die Erfassung der SQL-Tracingdaten zu stoppen, müssen Sie das SQL-Tracing deaktivieren. Siehe SQL-Tracing deaktivieren.
- Wenn Sie SQL-Tracing deaktivieren, werden die Tracingdaten, die während der Ausführung der Session mit aktiviertem Tracing erfasst wurden, in die Ansicht
SESSION_CLOUD_TRACE
in Ihrer Session und in eine Tracedatei im Bucket geschrieben, die Sie beim Einrichten von SQL-Tracing konfigurieren. Sie haben zwei Möglichkeiten, die Tracedaten anzuzeigen:- SQL Trace-Daten in der im Cloud-Objektspeicher gespeicherten Tracedatei anzeigen und analysieren. Weitere Informationen finden Sie unter Im Cloud-Objektspeicher gespeicherte Tracedatei in Autonomous Database anzeigen.
- Die in der View
SESSION_CLOUD_TRACE
gespeicherten SQL Trace-Daten anzeigen und analysieren. Weitere Informationen finden Sie unter Tracedaten in der SESSION_CLOUD_TRACE-View in Autonomous Database anzeigen.
SQL-Tracing in Autonomous Database konfigurieren
SQL-Tracing in Autonomous Database aktivieren
Hinweis:
Das Aktivieren von SQL-Tracing kann die Anwendungsperformance für die Session beeinträchtigen, während die Traceerfassung aktiviert ist. Diese Performanceauswirkungen sind aufgrund des Overheads beim Erfassen und Speichern von Tracedaten zu erwarten.So aktivieren Sie SQL-Tracing für eine Datenbank-Session:
SQL-Tracing deaktivieren
Im Cloud-Objektspeicher gespeicherte Tracedatei in Autonomous Database anzeigen
DEFAULT_LOGGING_BUCKET
konfigurierten Cloud-Objektspeicher-Bucket geschrieben.
Die SQL Trace-Funktion schreibt die in der Session erfassten Tracedaten im folgenden Format in den Cloud-Objektspeicher:
default_logging_bucket/sqltrace/clientID/moduleName/sqltrace_numID1_numID2.trc
Der Dateiname besteht aus folgenden Komponenten:
-
default_logging_bucket: Der Wert der Datenbankeigenschaft
DEFAULT_LOGGING_BUCKET
. Weitere Informationen finden Sie unter SQL-Tracing in Autonomous Database konfigurieren. -
clientID
: Die Client-ID. Weitere Informationen finden Sie unter SQL-Tracing in Autonomous Database aktivieren. -
moduleName
: Der Modulname. Weitere Informationen finden Sie unter SQL-Tracing in Autonomous Database aktivieren. -
numID1
_numID2
: Zwei IDs, die von der SQL Trace-Funktion bereitgestellt werden. Die numerischen WertenumID1
undnumID2
unterscheiden jeden Trace-Dateinamen eindeutig von anderen Sessions, die Tracing verwenden und Trace-Dateien im selben Bucket im Cloud-Objektspeicher erstellen.Wenn der Datenbankservice Parallelität unterstützt und eine Session eine parallele Abfrage ausführt, kann die SQL Trace-Funktion mehrere Trace-Dateien mit unterschiedlichen Werten für
numID1
undnumID2
erstellen.
Hinweis:
Wenn SQL-Tracing innerhalb derselben Session mehrmals aktiviert und deaktiviert wird, generiert jede Traciteration eine separate Tracedatei im Cloud-Objektspeicher. Um zu vermeiden, dass vorherige Traces überschrieben werden, die in der Session generiert wurden, folgen nachfolgend generierte Dateien derselben Namenskonvention und fügen ein numerisches Suffix zum Namen der Trace-Datei hinzu. Dieses numerische Suffix beginnt mit der Zahl 1 und wird für jede nachfolgende Tracingiteration um 1 erhöht.Beispiel: Der folgende Name ist ein Beispiel für eine generierte Trace-Datei, wenn Sie die Client-ID auf "sql_test"
und den Modulnamen auf "modname"
setzen:
sqltrace/sqlt_test/modname/sqltrace_5415_56432.trc
Sie können TKPROF
ausführen, um die Tracedatei in eine lesbare Ausgabedatei zu übersetzen.
Tracedaten in der SESSION_CLOUD_TRACE-View in Autonomous Database anzeigen
SESSION_CLOUD_TRACE
in der Session, in der das Tracing aktiviert wurde, dieselben Traceinformationen verfügbar, die in der Tracedatei im Cloud-Objektspeicher gespeichert wurden.
SESSION_CLOUD_TRACE
anzeigen. Die View SESSION_CLOUD_TRACE
enthält zwei Spalten: ROW_NUMBER
und TRACE
.DESC SESSION_CLOUD_TRACE
Name Null? Type
---------- ----- ------------------------------
ROW_NUMBER NUMBER
TRACE VARCHAR2(32767)
ROW_NUMBER
gibt die Reihenfolge der in der Spalte TRACE
gefundenen Tracedaten an. Jede Zeile der Traceausgabe in einer Tracedatei wird zu einer Zeile in der Tabelle und ist in der Spalte TRACE
verfügbar.
Nachdem Sie SQL-Tracing für die Session deaktiviert haben, können Sie Abfragen in der View SESSION_CLOUD_TRACE
ausführen.
SELECT trace FROM SESSION_CLOUD_TRACE ORDERBY row_number;
Die Daten in SESSION_CLOUD_TRACE
bleiben für die Dauer der Session erhalten. Nachdem Sie sich abgemeldet oder die Session geschlossen haben, sind die Daten nicht mehr verfügbar.
Wenn SQL Trace innerhalb derselben Session mehrere Male aktiviert und deaktiviert wird, zeigt SESSION_CLOUD_TRACE
die Trace-Daten für alle Iterationen kumulativ an. Daher werden Tracedaten, die durch eine frühere Iteration erzeugt wurden, nicht entfernt, wenn Sie Tracing in einer Session erneut aktivieren, nachdem Sie es zuvor deaktiviert haben.