Freigeben über

  • Artikel

Generischer SQL-Ablaufverfolgungs-Auflistertyp

Der generische SQL-Ablaufverfolgungs-Auflistertyp verwendet die SQL-Ablaufverfolgung zum Überwachen des relationalen Moduls von SQL Server. Die Ablaufverfolgungsdaten können von einer Standardablaufverfolgung oder von einer oder mehreren benutzerdefinierten Ablaufverfolgungen stammen. Dieser Auflistertyp ist in der core.supported_collector_types-Sicht registriert.

Die von einer serverweiten Einstellung gesteuerte Standardablaufverfolgung wird kontinuierlich auf dem Server ausgeführt und zeichnet allgemeine Ereignisse auf, die von Interesse sind. Diese Ereignisse beziehen sich nicht auf eine einzelne Batchausführung. Hierbei handelt es sich um eine Ablaufverfolgung mit geringen Auswirkungen. Benutzerdefinierte Ablaufverfolgungen können Ereignisse erfassen und starke oder geringe Auswirkungen haben. Dies hängt von der Auswahl der Ereignisse und der Serveraktivität ab, die zum Zeitpunkt der Ablaufverfolgung stattgefunden hat. In den meisten Fällen werden benutzerdefinierte Ablaufverfolgungen nicht kontinuierlich ausgeführt.

Der generische SQL-Ablaufverfolgungs-Auflistertyp führt eine serverseitige Ablaufverfolgung aus, die Daten in einer Datei oder einer Gruppe von Dateien speichert. Die Ablaufverfolgungsdaten werden mit der fn_trace_gettable()-Systemfunktion aus Ablaufverfolgungsdateien abgerufen. Der Auflister verarbeitet die Daten und lädt sie anschließend auf das Verwaltungs-Data Warehouse hoch, sofern er dafür konfiguriert ist.

Der generische SQL-Ablaufverfolgungs-Auflistertyp ist so konfiguriert, dass nicht verwendete Dateien entfernt werden und der Speicherplatz für gespeicherte Ablaufverfolgungsdaten konstant bleibt.

Eingabeschema der generischen SQL-Ablaufverfolgung

Der generische SQL-Ablaufverfolgungs-Auflistertyp verwendet das folgende Schema für Eingabeparameter.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="DataCollectorType">
  <xs:element name="SqlTraceCollector">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Events">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" maxOccurs="unbounded" name="EventType">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element maxOccurs="unbounded" name="Event">
                      <xs:complexType>
                        <xs:attribute name="id" type="xs:unsignedByte" use="required" />
                        <xs:attribute name="name" type="xs:string" use="required" />
                        <xs:attribute name="columnslist" type="xs:string" use="optional" />
                      </xs:complexType>
                    </xs:element>
                  </xs:sequence>
                  <xs:attribute name="id" type="xs:unsignedByte" use="optional" />
                  <xs:attribute name="name" type="xs:string" use="required" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:element name="Filters">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="Filter" minOccurs="0" maxOccurs="unbounded">
                <xs:complexType>
                  <xs:attribute name="columnid" type="xs:unsignedByte" use="required" />
                  <xs:attribute name="columnname" type="xs:string" use="required" />
                  <xs:attribute name="logical_operator" type="xs:string" use="required" />
                  <xs:attribute name="comparison_operator" type="xs:string" use="required" />
                  <xs:attribute name="value" type="xs:string" use="required" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="use_default" type="xs:boolean" />
    </xs:complexType>
  </xs:element>
</xs:schema>

Wie im Schema gezeigt, enthält der Auflistertyp wichtige Elemente, Parameter gespeicherter Prozeduren und spezielle Spalten.

Wichtige Elemente

  • Die Eingabe-Ablaufverfolgungsdefinition enthält eine Liste der Ereignisse sowie eine Liste der Filter, die die Ablaufverfolgung definieren.

  • Ereignisse werden innerhalb eines EventType-Knotens gruppiert, der der Ereigniskategorie in SQL Server Profiler entspricht.

  • Für den EventType-Knoten muss das ID-Attribut mit dem Wert der sys.trace_category-Systemsicht übereinstimmen. Das name-Attribut ist optional.

  • Für den Event-Knoten muss das ID-Attribut mit dem Wert der sys.trace_events-Systemsicht übereinstimmen. Das name-Attribut ist optional.

  • IDs werden beim Generieren eines Ablaufverfolgungs-Startskripts verwendet. Die Namen werden aus Gründen der Lesbarkeit und zum Rendering der Eingabedefinition in der Benutzeroberfläche verwendet.

  • Der Event-Knoten verfügt über die folgenden Attribute:

    • ID, name. Weiter oben erklärt.

    • columnslist. Eine durch Trennzeichen getrennte Liste der Spalten-IDs, die für das Ereignis ausgewählt werden sollen. Wenn columnslist nicht angegeben wird, werden alle Spalten für dieses Ereignis eingeschlossen.

  • Der Filter-Knoten definiert einen Filter, der auf die Ablaufverfolgung angewendet wird. Die Attribute haben die folgende Bedeutung:

    • columnid. ID einer Spalte, auf die der Filter angewendet wird.

    • columnname. Der Name der Spalte, die von columnid angegeben wird. Dies wird für das Rendering verwendet.

    • logical_operator. Ein Operator, der zwischen mehreren Filtern derselben Spalte angewendet werden soll. Zulässige Werte sind AND und OR.

    • comparison_operator. Ein Operator, der zwischen der Spalte und dem Filterwert angewendet werden soll. Zulässige Werte sind: EQ, NE, GT, GE, LT, LE, LIKE und NOTLIKE.

    • value. Der für den Vergleich zu verwendende Wert. Beachten Sie, dass der Wert des Filters und der Vergleichsoperator mit dem Typ der Spalte übereinstimmen müssen, auf die der Filter angewendet wird. Wenn der Spaltentyp beispielsweise string lautet, dürfen nur der LIKE-Operator und der NOTLIKE-Operator verwendet werden. Außerdem werden für den Filterwert nur Zeichenfolgenwerte akzeptiert.

Parameter gespeicherter Prozeduren

Die folgenden Parameter der gespeicherten Prozedur sp_trace_create werden auf Basis des Auflistsatzes oder der Auflisteroptionen definiert.

  • @options. Die Ablaufverfolgung wird immer mit festgelegter Rolloveroption (TRACE_FILE_ROLLOVER) gestartet.

  • @tracefile. Der Speicherort der Ablaufverfolgungsdateien wird von der CollectorTempDir-Variable bestimmt. Der Name der Ablaufverfolgungsdatei wird durch Verketten der folgenden Elemente generiert: "DataCollector_" + instanceName + CollectionSetUid + CollectionItemId + ".trc".

  • @maxfilesize. Ist immer auf 5 Megabyte (MB) festgelegt.

  • @stoptime. Wird nicht verwendet.

  • @filecount. Ist passend zum maximalen temporären Speicher festgelegt, der pro Auflistsatz zulässig ist (in MB). @filecount = Speichergrenze/5.

Spezielle Spalten

Es werden zusätzliche Spalten für jedes Ereignis angezeigt, selbst wenn sie in den Eingabeparametern für dieses Ereignis nicht vorausgewählt sind. Es handelt sich dabei um die folgenden Spalten:

  • StartTime

  • EndTime

  • EventSequence

  • SPID

Die genannten Spalten geben den Ursprung des Ereignisses an und ermöglichen die Ereigniskorrelation.

Das folgende Codebeispiel veranschaulicht die Verwendung des Eingabeschemas, das vom generischen SQL-Ablaufverfolgungs-Auflistertyp verwendet wird.

<?xml version="1.0" encoding="utf-8"?>

<ns:SqlTraceCollector xmlns:ns="DataCollectorType" normalize_sql="0" normalize_plans="0" normalize_procedures="0" normalize_connections="0" 
normalize_default="1">

<Events>
<EventType id ="6" name="Performance">
<Event id="58" name="Auto Stats"/>
<Event id="165" name="Performance statistics"/>
<Event id="146" name="Showplan XML Statistics Profile"/>
</EventType>
<EventType id="13" name="TSQL">
<Event id="12" name="SQL:BatchCompleted" columnslist="1, 3, 9, 10, 13, 16, 17, 18"/>
<Event id="13" name="SQL:BatchStarting"/>
<Event id="41" name="SQL:StmtCompleted"/>
<Event id="166" name="SQL:StmtRecompile"/>
</EventType>
<EventType id="20" name="CLR">
<Event id="196" name="Assembly Load"/>
</EventType>
<EventType id="1" name="Cursors">
<Event id="53" name="CursorOpen"/>
<Event id="75" name="CursorRecompile"/>
<Event id="76" name="CursorImplicitConversion"/>
<Event id="78" name="CursorClose"/>
</EventType>
</Events>

<Filters>
<Filter columnid="13" columnname="Duration" logical_operator="AND" comparison_operator="GE" value="1000L"/>
<Filter columnid="10" columnname="ApplicationName" logical_operator="AND" comparison_operator="LIKE" value="Data Collector"/>
<Filter columnid="10" columnname="ApplicationName" logical_operator="AND" comparison_operator="EQ" value="NULL"/>
<Filter columnid="18" columnname="CPU" logical_operator="AND" comparison_operator="EQ" value="20"/>
<Filter columnid="14" columnname="StartTime" logical_operator="AND" comparison_operator="GT" value="2007-02-09 13:40:00"/>
</Filters>

</ns:SqlTraceCollector>

Verarbeiten und Ausgeben

Diese Version des generischen SQL-Ablaufverfolgungs-Auflistertyps unterstützt ein Laden der vollständigen Ablaufverfolgungsdaten, bei dem in der Standardablaufverfolgung des Servers aufgezeichnete Ereignisse verarbeitet werden.

Laden der vollständigen Ablaufverfolgungsdaten

Mit diesem Datenladetyp werden die Ablaufverfolgungsdaten ohne jegliche Verarbeitung in eine einzige Tabelle geladen, die alle möglichen Ablaufverfolgungsspalten enthält. Daten aus mehreren Ablaufverfolgungen können in dieselbe Tabelle geladen werden. Dadurch wird das Zusammenführen der Daten vereinfacht. Neben den Ablaufverfolgungsdaten wird an jede Zeile eine Snapshot-ID angehängt. Dadurch ist es möglich, die Quelle der Ablaufverfolgungsdaten und den Zeitpunkt der Ablaufverfolgung zu identifizieren.

Das Laden der vollständigen Ablaufverfolgung bietet folgende Vorteile:

  • Es steht eine einfache Möglichkeit zur Verfügung, um Ablaufverfolgungsdaten vom Server in eine Datenbank zu übertragen, wo sie problemlos abgefragt und weiter verarbeitet werden können, ohne die Ablaufverfolgung in SQL Server Profiler öffnen zu müssen.

  • Daten von mehreren Ablaufverfolgungen können zusammengeführt und miteinander in Beziehung gesetzt werden.

  • Es gehen keine Daten der ursprünglichen Ablaufverfolgung verloren. Alle aufgezeichneten Daten bleiben erhalten.

  • Die Daten können mit vorhandenen Tools, wie z. B. SQL Server Profiler, durchsucht werden.

Zielschema

Das Zielschema ist als eine Tabelle definiert, die Details zu den im Verwaltungs-Data Warehouse gespeicherten Ablaufverfolgungen aufzeichnet, und eine Tabelle, in der alle Ablaufverfolgungsereignisse der Ablaufverfolgungen gespeichert werden. Die Ablaufverfolgungsdaten werden in den folgenden Tabellen des Verwaltungs-Data Warehouses gespeichert:

  • snapshots.trace_info. Diese Tabelle enthält Informationen über alle Ablaufverfolgungen, die in die Instanz des Verwaltungs-Data Warehouses hochgeladen wurden.

  • snapshots.trace_data. Diese Tabelle enthält von allen Ablaufverfolgungen aufgezeichnete Daten. Sie definiert eine Spalte für jede mögliche Ablaufverfolgungsspalte. Wenn die Ablaufverfolgungsdaten auf diese Weise gespeichert werden, kann der Datenauflister die Daten in der gleichen Form, in der sie mit der fn_trace_gettable()-Systemfunktion ausgegeben werden, in die Tabelle einfügen. Die Tabelle kann auch direkt in SQL Server Profiler geladen werden.

Weitere Informationen zu diesen Tabellen finden Sie unter Das Verwaltungs-Data Warehouse.

Änderungsverlauf

Aktualisierter Inhalt

Eingabeschema der generischen SQL-Ablaufverfolgung korrigiert.

Codebeispiel korrigiert, das die Verwendung des Eingabeschemas veranschaulicht, das vom generischen SQL-Ablaufverfolgung-Auflistertyp verwendet wird.