Die Anforderungsprotokollierung zeichnet die einzelnen von einer Anwendung empfangenen Anforderungen bzw. die an eine Anwendung gesendeten Antworten auf. Das ist besonders hilfreich, um herauszufinden, welche Aktion die Anwendung vom Datenbankserver verlangt.
Die Anforderungsprotokollierung ist auch ein guter Ausgangspunkt für die Performanceanalyse einer bestimmten Anwendung, wenn es nicht offensichtlich ist, ob der Datenbankserver oder der Client der Verursacher des Fehlers ist. Sie können eine Anforderungsprotokollierung durchführen, um die spezielle Anforderung an den Datenbankserver zu ermitteln, die für Probleme verantwortlich sein könnte.
Die gesamte Funktionalität sowie die Daten, die von der Anforderungsprotokollierungsfunktion geliefert werden, stehen auch bei der Diagnoseprotokollierung zur Verfügung. Die Diagnoseprotokollierung bietet außerdem zusätzliche Funktionen und Daten. Siehe Erweiterte Anwendungsprofilerstellung mithilfe der Diagnoseprotokollierung.
Zu den protokollierten Daten gehören beispielsweise Zeitstempel, Verbindungs-IDs und Anforderungstyp. Bei Abfragen umfassen die Daten außerdem die Isolationsstufe, die Anzahl der abgerufenen Zeilen und den Cursortyp. Für die Anweisungen INSERT, UPDATE und DELETE werden auch die Anzahl der betroffenen Zeilen und die Anzahl der ausgelösten Trigger erfasst.
Das Anforderungslog kann vertrauliche Daten enthalten, da es den vollständigen Text von SQL-Anweisungen einschließlich Kennwörtern enthält, wie etwa bei den Anweisungen GRANT CONNECT, CREATE DATABASE und CREATE EXTERNAL LOGIN. Wenn dies Sicherheitsprobleme verursacht, sollten Sie den Zugriff auf die Anforderungslogdatei einschränken.
Mit der Serveroption -zr können Sie die Anforderungsprotokollierung einschalten, wenn Sie den Datenbankserver starten. Sie können die Ausgabe in eine Anforderungslogsatei zur späteren Analyse speichern, indem Sie die -zo-Serveroption verwenden. Mit den Optionen -zn und -zs legen Sie fest, wie viele Anforderungslogdateien gespeichert werden und welche maximale Größe die Anforderungslogdateien haben können.
Weitere Hinweise zu diesen Optionen finden Sie unter:
Diese Serveroptionen wirken sich nicht auf die Diagnoseprotokollierung in Sybase Central aus. Die Anforderungsprotokollierung auf Dateibasis ist vollkommen getrennt von der Diagnoseprotokollierungsfunktion in Sybase Central, welche dbo-eigene Diagnosetabellen in der Datenbank verwendet, um Daten des Anforderungslogs zu speichern.
Die Systemprozedur "sa_get_request_times" liest ein Anforderungslog und befüllt die globale temporäre Tabelle (satmp_request_time) mit Anweisungen aus dem Protokoll und ihren Ausführungszeiten. Die aufgezeichneten Zeitangaben für die Anweisungen INSERT/UPDATE/DELETE beziehen sich auf die Zeit, zu denen die Anweisungen ausgeführt wurden. Bei Abfragen bestehen die aufgezeichneten Zeitdaten aus der Zeitspanne von PREPARE bis DROP (describe/open/fetch/close). Das bedeutet, dass Sie auf geöffnete Cursor achten müssen.
Prüfen Sie "satmp_request_time" für Anweisungen, die Kandidaten für Verbesserungen sein könnten. Anweisungen, die kostengünstig sind, aber häufig ausgeführt werden, können ein Performance-Problem darstellen.
Sie können "sa_get_request_profile" verwenden, um "sa_get_request_times" aufzurufen und "satmp_request_time" in einer anderen globalen temporären Tabelle namens "satmp_request_profile" zusammenzufassen. Diese Prozedur gruppiert überdies die Anweisungen und liefert die Anzahl der Aufrufe, die Ausführungszeiten usw. Siehe sa_get_request_times-Systemprozedur und sa_get_request_profile-Systemprozedur.
Wenn das Log mithilfe des Perl-Skripts tracetime.pl analysiert werden soll und das clientseitige Zwischenspeichern von Anweisungen aktiviert ist, sollte die Option max_client_statements_cached auf 0 gesetzt werden, um das clientseitige Zwischenspeichern von Anweisungen während der Aufzeichnung des Anforderungslogs zu deaktivieren. Siehe max_client_statements_cached-Option.
Anforderungslogs filternSie können die Ausgabe in ein Anforderungslog filtern, um nur Anforderungen von einer bestimmten Verbindung oder einer bestimmten Datenbank aufzuzeichnen, indem Sie die Systemprozedur "sa_server_option" verwenden. Dies kann den Umfang des Protokolls verringern, wenn Sie einen Datenbankserver mit vielen aktiven Verbindungen oder einer Vielzahl von Datenbanken überwachen. Siehe sa_server_option-Systemprozedur.
♦ So filtern Sie anhand einer VerbindungVerwenden Sie die folgende Syntax:
CALL sa_server_option( 'RequestFilterConn' , Verbindungs-ID ); |
Sie können die Verbindungs_ID abrufen, indem Sie CALL sa_conn_info( ) ausführen.
♦ So filtern Sie anhand einer DatenbankVerwenden Sie die folgende Syntax:
CALL sa_server_option( 'RequestFilterDB' , Datenbank-ID ); |
Die Datenbank_ID kann durch die Ausführung von SELECT CONNECTION_PROPERTY( 'DBNumber' ) bezogen werden, wenn Sie mit der Datenbank verbunden sind. Das Filtern bleibt aktiviert, bis es explizit zurückgesetzt bzw.
der Datenbankserver heruntergefahren wird.
♦ So setzen Sie das Filtern zurückVerwenden Sie eine der beiden folgenden Anweisungen, um das Filtern anhand der Verbindung bzw. anhand der Datenbank zurückzusetzen:
CALL sa_server_option( 'RequestFilterConn' , -1 ); |
CALL sa_server_option( 'RequestFilterDB' , -1 ); |
Hostvariable in Anforderungslogs ausgebenHostvariablenwerte können in ein Anforderungsprotokoll ausgegeben werden.
♦ So nehmen Sie Hostvariablenwerte aufSo nehmen Sie Hostvariablenwerte in das Anforderungslog auf:
Verwenden Sie die Option -zr mit einem Wert von hostvars
Führen Sie Folgendes aus:
CALL sa_server_option( 'RequestLogging' , 'hostvars' ); |
Die Prozedur "sa_get_request_times" für die Anforderungsprotokollanalyse erkennt Hostvariablen im Protokoll und fügt sie der globalen temporären Tabelle "satmp_request_hostvar" hinzu.
 |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |