Was verbirgt DEFAULT TRACE?

  • Tutorial


Die erste Arbeit wird oft zurückgerufen ... Ein mittelmäßiges Büro, Monique 943N und Pentium D Heizung unter den Füßen. Als Boris (nein ... nicht Boris "Razor") mit einem Lineal in den Händen aus dem Nichts kam und eindringlich darum bat, den Server nicht zu "verletzen".

In diesen fernen Zeiten traf ich mich zum ersten Mal mit dem Profiler. Benutzerdefinierte Traces erwiesen sich beim Debuggen von Anwendungen und beim Auffinden langsamer Abfragen als sehr nützlich. Dann entdeckte ich DMV und XEvents für mich selbst ... und begann, den Profiler seltener zu verwenden. Der Grund für diesen Akt ist einfach - Spuren sind sehr ressourcenintensiv.

Diese Funktionalität sollte jedoch nicht vorzeitig anathematisiert werden. Ab Version 2005 bei der Installation von SQL ServerStandardmäßig wird eine einfache Systemablaufverfolgung erstellt, in der viele nützliche Informationen gespeichert sind.

Es befindet sich in dem Ordner, in dem SQL Server installiert ist , und besteht aus fünf Dateien mit der Erweiterung trc . Bei jedem Start des Servers wird automatisch eine neue Datei für den Trace erstellt und die älteste überschrieben. Das Aufzeichnen neuer Ereignisse erfolgt immer in der neuesten Datei, deren Größe auf 20 MB begrenzt ist. Wenn die Größe überschritten wird, wird automatisch eine neue Datei erstellt. Dieses Verhalten kann nicht geändert werden.

Sie können diese Funktionalität nur deaktivieren oder aktivieren:

EXEC sys.sp_configure 'show advanced options', 1
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure 'default trace enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO

Sie können überprüfen, ob die Standardablaufverfolgung durch die folgende Anforderung aktiviert ist:

SELECT name, value
FROM sys.configurations
WHERE configuration_id = 1568

Der Pfad zum Standard-Trace:

SELECT [path], start_time, last_event_time, event_count
FROM sys.traces
WHERE is_default = 1

Und jetzt beginnen wir mit dem interessantesten ... Mal sehen, welche Ereignisse in der Standardablaufverfolgung gespeichert werden können:

SELECT e.trace_event_id, e.name, c.category_id, c.name
FROM sys.trace_categories c
JOIN sys.trace_events e ON c.category_id = e.category_id

trace_event_id name                       category_id name
-------------- -------------------------- ----------- -----------------------------------
196            CLR                        20          Assembly Load
92             Database                   2           Data File Auto Grow
93             Database                   2           Log File Auto Grow
94             Database                   2           Data File Auto Shrink
95             Database                   2           Log File Auto Shrink
79             Errors and Warnings        3           Missing Column Statistics
80             Errors and Warnings        3           Missing Join Predicate
67             Errors and Warnings        3           Execution Warnings
69             Errors and Warnings        3           Sort Warnings
55             Errors and Warnings        3           Hash Warning
21             Errors and Warnings        3           EventLog
22             Errors and Warnings        3           ErrorLog
213            Errors and Warnings        3           Database Suspect Data Page
214            Errors and Warnings        3           CPU threshold exceeded
46             Objects                    5           Object:Created
47             Objects                    5           Object:Deleted
164            Objects                    5           Object:Altered
...

Schauen wir uns kleine Beispiele für die praktischen Vorteile von Informationen aus der Standardablaufverfolgung an.

1. Auto Grow-Ereignisse

Ich hoffe, es ist kein Geheimnis, dass für eine Transaktion eine bestimmte Menge an Speicherplatz erforderlich ist. In einer Datendatei oder einem Protokoll. Wir werden nicht angeben ... aber im allgemeinen Fall, wenn nicht genügend Speicherplatz vorhanden ist, erfolgt eine automatische Vergrößerung der Datei. Zu diesem Zeitpunkt ist die Datei gesperrt und SQL Server wartet, bis das Festplattensubsystem die erforderlichen Vorgänge zum Zuweisen von Speicherplatz ausführt.

Standardmäßig initialisiert SQL Server einen neuen Speicherplatz mit Nullen. Bei Datendateien kann dieses Verhalten mithilfe der sofortigen Dateiinitialisierung deaktiviert werden .. Bei den Protokolldateien erfolgt die Initialisierung jedoch weiterhin und ist definitiv langsam. Daher wird empfohlen, Auto Grow- Ereignisse ständig zu überwachen :

SELECT
      StartTime
    , Duration = Duration / 1000
    , DatabaseName = DB_NAME(DatabaseID)
    , [FileName]
    , GrowType = CASE WHEN EventClass = 92 THEN 'DATA' ELSE 'LOG' END
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
WHERE t.EventClass IN (
            92, -- Data File Auto Grow
            93  -- Log File Auto Grow
        ) 
    AND i.is_default = 1

Und wenn ihre Zahl stark zunimmt:

StartTime            Duration    DatabaseName           FileName                   GrowType
-------------------- ----------- ---------------------- -------------------------- --------
2016-01-16 02:52:48  36          tempdb                 templog                    LOG
2016-01-16 02:52:49  50          tempdb                 tempdev                    DATA
2016-01-16 02:52:50  216         tempdb                 tempdev                    DATA
2016-01-16 02:52:51  43          tempdb                 tempdev                    DATA
2016-01-16 02:52:52  760         tempdb                 tempdev                    DATA
2016-01-16 02:52:54  270         tempdb                 tempdev                    DATA
2016-01-16 02:52:55  273         tempdb                 tempdev                    DATA
2016-01-16 02:52:56  286         tempdb                 tempdev                    DATA
2016-01-16 02:52:58  206         tempdb                 tempdev                    DATA
2016-01-16 02:52:59  513         tempdb                 tempdev                    DATA
2016-01-16 02:53:01  363         tempdb                 tempdev                    DATA
2016-01-16 02:53:03  300         tempdb                 tempdev                    DATA
2016-01-16 02:53:05  303         tempdb                 tempdev                    DATA
2016-01-16 02:53:08  200         tempdb                 tempdev                    DATA
2016-01-16 02:53:10  60          tempdb                 tempdev                    DATA
2016-01-16 02:53:12  350         tempdb                 tempdev                    DATA
2016-01-16 02:53:15  370         tempdb                 tempdev                    DATA
2016-01-16 02:53:17  243         tempdb                 tempdev                    DATA
2016-01-16 02:53:21  446         tempdb                 tempdev                    DATA
2016-01-16 02:53:25  163         tempdb                 tempdev                    DATA
2016-01-16 02:53:30  286         tempdb                 tempdev                    DATA
2016-01-16 02:53:36  426         tempdb                 tempdev                    DATA
2016-01-16 02:53:42  376         tempdb                 tempdev                    DATA
2016-01-16 02:53:49  120         tempdb                 tempdev                    DATA
2016-01-16 02:53:58  200         tempdb                 tempdev                    DATA
2016-01-16 02:54:06  186         tempdb                 tempdev                    DATA
2016-01-16 02:54:17  43          tempdb                 tempdev                    DATA
2016-01-16 02:54:27  6           tempdb                 tempdev                    DATA
2016-01-16 02:54:42  3           tempdb                 tempdev                    DATA
2016-01-16 02:55:04  30          tempdb                 tempdev                    DATA
2016-01-16 14:19:47  63          AdventureWorks2012     AdventureWorks2012_Log     LOG
2016-01-16 14:19:47  20          AdventureWorks2012     AdventureWorks2012_Log     LOG
2016-01-16 16:51:32  100         tempdb                 tempdev                    DATA
2016-02-16 17:31:02  66          tempdb                 templog                    LOG
...

Dies kann nicht nur zu einer Fragmentierung der Datei auf der Festplatte führen, sondern auch zu erheblichen Verzögerungen bei der Ausführung von Anforderungen:

SELECT
      GrowType = CASE WHEN EventClass = 92 THEN 'DATA' ELSE 'LOG' END
    , GrowCount = COUNT(1)
    , Duration = SUM(Duration) / 1000
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
WHERE t.EventClass IN (92, 93) 
    AND i.is_default = 1
    AND t.DatabaseID = DB_ID('tempdb')
GROUP BY EventClass

GrowType GrowCount   Duration
-------- ----------- --------------------
DATA     36          7296
LOG      2           102

Schauen wir uns die Einstellungen der Problembasis an:

USE tempdb
GO
SELECT
      d.type_desc
    , d.name
    , d.physical_name
    , current_size_mb = ROUND(d.size * 8. / 1000, 0)
    , initial_size_mb = ROUND(m.size * 8. / 1000, 0) 
    , auto_grow =
        CASE WHEN d.is_percent_growth = 1
            THEN CAST(d.growth AS VARCHAR(10)) + '%'
            ELSE CAST(ROUND(d.growth * 8. / 1000, 0) AS VARCHAR(10)) + 'MB'
        END
FROM sys.database_files d
JOIN sys.master_files m ON d.[file_id] = m.[file_id]
WHERE m.database_id = DB_ID('tempdb')

Die anfängliche Datenbankgröße beträgt 8 MB für die Datendatei und 1 MB für das Protokoll:

type  name       physical_name                  current_size_mb    initial_size_mb    auto_grow
----- ---------- ------------------------------ ------------------ ------------------ ---------
ROWS  tempdev    D:\SQL_2012\DATA\tempdb.mdf    258.000000         8.000000           10%
LOG   templog    D:\SQL_2012\DATA\templog.ldf   3.000000           1.000000           1MB

... was im Vergleich zur aktuellen Größe eindeutig nicht ausreicht. Darüber hinaus müssen Sie berücksichtigen, dass bei jedem Neustart von SQL Server die Tempdb neu erstellt wird. Unter dem Strich erhalten wir beim nächsten Start erneut eine Datei mit 9 MB, Verzögerungen bei der Ausführung von Anforderungen und einen neuen Stapel von Nachrichten in der Standardablaufverfolgung.

Was ist der Ausweg aus dieser Situation? Überwachen Sie die Dateigröße und reservieren Sie freien Speicherplatz für sie:

SELECT
      s.[file_id]
    , s.name
    , size = CAST(s.size * 8. / 1024 AS DECIMAL(18,2))
    , space_used = CAST(t.space_used * 8. / 1024 AS DECIMAL(18,2))
    , free_space = CAST((s.size - t.space_used) * 8. / 1024 AS DECIMAL(18,2))
    , used_percent = CAST(t.space_used * 100. / s.size AS DECIMAL(18,2))
    , s.max_size
    , s.growth
    , s.is_percent_growth
FROM sys.database_files s
CROSS APPLY (
    SELECT space_used = FILEPROPERTY(s.name, 'SpaceUsed')
) t

2. Auto Shrink Events

Kürzlich habe ich bereits geschrieben, dass die Option AUTO_CLOSE die Leistung verringert. So AUTO_SHRINK geht noch schlimmer ... alle 30 Minuten SQL Server versucht , den Verkürzungs freien Speicherplatz in den Datenbankdateien zu tun. Dieser Prozess ist sehr ressourcenintensiv und kann zur Fragmentierung von Dateien auf der Festplatte führen. Beim Abschneiden von Dateien kommt es zu einer hohen Fragmentierung der Indizes, wodurch die logischen Lesevorgänge erhöht und die Abfrageleistung verringert werden.

Stellen Sie sich eine einfache Situation vor ... Daten wurden aus der Kürzung der Tabellendatei gelöscht. Wir haben neue Daten eingefügt - es war nicht genügend Speicherplatz vorhanden und SQL Server musste die Dateigröße erhöhen. Sie haben die Daten gelöscht und wieder alles auf eine neue Art ...

SELECT
      StartTime
    , EndTime
    , Duration = Duration / 1000
    , DatabaseName = DB_NAME(DatabaseID)
    , [FileName]
    , GrowType = CASE WHEN EventClass = 94 THEN 'DATA' ELSE 'LOG' END
    , NTDomainName
    , ApplicationName
    , LoginName
    , TextData
    , IsSystem
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
WHERE t.EventClass IN (
            94, -- Data File Auto Shrink
            95  -- Log File Auto Shrink
        ) 
    AND i.is_default = 1

StartTime           Duration    DatabaseName              FileName                 GrowType
------------------- ----------- ------------------------- ------------------------ --------
2016-02-10 11:57:54 116         AdventureWorks2012        AdventureWorks2012_Log   LOG
2016-02-10 14:58:21 113         AdventureWorks2012        AdventureWorks2012_Log   LOG
2016-02-10 19:30:02 113         AdventureWorks2012        AdventureWorks2012_Log   LOG
2016-02-10 21:00:26 16          AdventureWorks2012        AdventureWorks2012_Log   LOG

Ich rate Ihnen auf jeden Fall, diese Option zu deaktivieren:

SELECT 'ALTER DATABASE ' + QUOTENAME(name) + ' SET AUTO_SHRINK OFF WITH NO_WAIT;'
FROM sys.databases
WHERE is_auto_shrink_on = 1

3. DBCC-Ereignisse

Eine weitere Nützlichkeit der Standardablaufverfolgung ist die Möglichkeit zu verfolgen, wer wann DBCC- Befehle gestartet hat . Es lohnt sich normalerweise nicht, DBCC CHECKDB zu schelten , aber wenn jemand in der Produktion verrückt ist, tut er Folgendes :

DBCC SHRINKDATABASE
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS

es kann leicht verfolgt werden:

SELECT t.TextData, t.ApplicationName, t.LoginName, t.StartTime
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
WHERE i.is_default = 1
    AND t.EventClass = 116 -- Audit DBCC Event
    AND t.ApplicationName IS NOT NULL

und ein vorbeugendes Gespräch mit jemandem über die Vorteile des Stehens in einer Ecke auf Buchweizen führen:

TextData                ApplicationName     LoginName    StartTime               
----------------------- ------------------  -----------  ----------------------- 
DBCC SHRINKDATABASE(1)  SSMS - Query        PC\IgorS     2016-02-10 20:03:46.307 
DBCC FREEPROCCACHE      SSMS - Query        PC\IgorS     2016-02-10 20:03:43.430 
DBCC DROPCLEANBUFFERS   SSMS - Query        PC\IgorS     2016-02-10 20:03:44.767 

4. Fehler- und Warnereignisse

In einer Situation, in der SQL Server nicht über genügend freien Speicher verfügt, um die Abfrage auszuführen, wird die Verarbeitung der Ergebnisse einiger Anweisungen in tempdb ausgeführt . Das gleiche Verhalten tritt auf, wenn der Optimierer die erwartete Anzahl von Zeilen falsch geschätzt hat.

Lassen Sie uns versuchen , eine Abfrage zu schreiben , die verursachen Leckagen in der Tempdb :

SELECT *
FROM Sales.SalesOrderHeader
WHERE DueDate > ShipDate
ORDER BY OrderDate DESC



Dank der Nachricht aus dem Standard-Trace können wir diese Anforderungen verfolgen:

SELECT TOP(10)
      EventName = e.name
    , t.TextData
    , t.ApplicationName
    , t.LoginName
    , t.StartTime
    , DatabaseName = DB_NAME(t.DatabaseID)
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
JOIN sys.trace_events e ON e.trace_event_id = t.EventClass
WHERE i.is_default = 1
    AND e.category_id = 3
ORDER BY t.StartTime DESC

EventName          ApplicationName   LoginName     StartTime               DatabaseName
------------------ ----------------- ------------- ----------------------- ---------------------
Sort Warnings      SSMS - Query      PC\SergeyS    2016-02-11 13:06:44.867 AdventureWorks2012

Finden Sie ihren Ausführungsplan und versuchen Sie, die Abfrage zu optimieren:

USE AdventureWorks2012
GO
SELECT TOP(5)
      p.query_plan
    , e.[text]
    , qyery_cost = p.query_plan.value(
            '(/*:ShowPlanXML/*:BatchSequence/*:Batch/*:Statements/*:StmtSimple/@StatementSubTreeCost)[1]',
            'FLOAT'
        )
    , s.last_execution_time
    , last_exec_ms = s.last_worker_time / 1000
    , s.execution_count
FROM sys.dm_exec_query_stats s
CROSS APPLY sys.dm_exec_query_plan(s.plan_handle) p
CROSS APPLY sys.dm_exec_sql_text(s.plan_handle) e
WHERE e.[text] NOT LIKE '%sys%'
    AND s.last_execution_time >= DATEADD(MS, -2500, '2016-02-10 19:41:45.983')
    AND e.[dbid] = DB_ID()
ORDER BY s.last_execution_time

query_plan        text                             qyery_cost  execution_time      last_exec_ms  
----------------- -------------------------------- ----------- ------------------- --------------

К слову скажу, актуальные планы выполнения недоступны через DMV. Их можно получить только на этапе Post Query Execution Showplan, через соответствующий Trace event, или по команде SET STATISTICS XML ON. Начиная с SQL Server 2012 специально для таких целей добавили новый XEventpost_query_execution_showplan.

Меня лично радует, что отслеживать можно разного рода предупреждения:

SELECT DISTINCT d.SalesOrderID, d.UnitPrice, h.OrderDate
FROM Sales.SalesOrderHeader h
JOIN Sales.SalesOrderDetail d ON h.SalesOrderID = d.SalesOrderID
WHERE h.DueDate > h.ShipDate



EventName        ApplicationName   LoginName     StartTime               DatabaseName
---------------- ----------------- ------------- ----------------------- ---------------------
Hash Warning     SSMS - Query      PC\SergeyS    2016-02-11 13:14:44.433 AdventureWorks2012

Например, когда по ошибке забыли указать поля по которым идет соединение:

SELECT *
FROM Sales.Currency c, Sales.CountryRegionCurrency r
--WHERE c.CurrencyCode = r.CurrencyCode



EventName               ApplicationName   LoginName     StartTime           DatabaseName
----------------------- ----------------- ------------- ------------------- ---------------------
Missing Join Predicate  SSMS - Query      PC\SergeyS    2016-02-11 13:18:20 AdventureWorks2012

или, когда на столбце по которому идет фильтрация отсутствует статистика:

SELECT DatabaseLogID
FROM dbo.DatabaseLog
WHERE PostTime = '2012-03-14 13:14:18.847'



EventName                   TextData                                   DatabaseName
--------------------------- ------------------------------------------ --------------------
Missing Column Statistics   NO STATS:([dbo].[DatabaseLog].[PostTime])  AdventureWorks2012

5. Object Events

В дефолтном трейсе можно отслеживать создание и удаление объектов:

USE [master]
GO
IF DB_ID('test') IS NOT NULL
    DROP DATABASE [test]
GO
CREATE DATABASE [test]
GO
USE [test]
GO
CREATE TABLE dbo.tbl (ID INT)
GO
ALTER TABLE dbo.tbl ADD Col VARCHAR(20)
GO
CREATE UNIQUE CLUSTERED INDEX ix ON dbo.tbl (ID)
GO
USE [master]
GO
IF DB_ID('test') IS NOT NULL
    DROP DATABASE [test]
GO

SELECT
      EventType = e.name
    , t.DatabaseName
    , t.ApplicationName
    , t.LoginName
    , t.StartTime
    , t.ObjectName
    , ObjectType =
        CASE t.ObjectType
            WHEN 8259 THEN 'Check Constraint'
            WHEN 8260 THEN 'Default Constraint'
            WHEN 8262 THEN 'Foreign Key'
            WHEN 8272 THEN 'Stored Procedure'
            WHEN 8274 THEN 'Rule'
            WHEN 8275 THEN 'System Table'
            WHEN 8276 THEN 'Server Trigger'
            WHEN 8277 THEN 'Table'
            WHEN 8278 THEN 'View'
            WHEN 8280 THEN 'Extended Stored Procedure'
            WHEN 16724 THEN 'CLR Trigger'
            WHEN 16964 THEN 'Database'
            WHEN 17222 THEN 'FullText Catalog'
            WHEN 17232 THEN 'CLR Stored Procedure'
            WHEN 17235 THEN 'Schema'
            WHEN 17985 THEN 'CLR Aggregate Function'
            WHEN 17993 THEN 'Inline Table-valued SQL Function'
            WHEN 18000 THEN 'Partition Function'
            WHEN 18004 THEN 'Table-valued SQL Function'
            WHEN 19280 THEN 'Primary Key'
            WHEN 19539 THEN 'SQL Login'
            WHEN 19543 THEN 'Windows Login'
            WHEN 20038 THEN 'Scalar SQL Function'
            WHEN 20051 THEN 'Synonym'
            WHEN 20821 THEN 'Unique Constraint'
            WHEN 21075 THEN 'Server'
            WHEN 21076 THEN 'Transact-SQL Trigger'
            WHEN 21313 THEN 'Assembly'
            WHEN 21318 THEN 'CLR Scalar Function'
            WHEN 21321 THEN 'Inline scalar SQL Function'
            WHEN 21328 THEN 'Partition Scheme'
            WHEN 21333 THEN 'User'
            WHEN 21572 THEN 'Database Trigger'
            WHEN 21574 THEN 'CLR Table-valued Function'
            WHEN 21587 THEN 'Statistics'
            WHEN 21825 THEN 'User'
            WHEN 21827 THEN 'User'
            WHEN 21831 THEN 'User'
            WHEN 21843 THEN 'User'
            WHEN 21847 THEN 'User'
            WHEN 22601 THEN 'Index'
            WHEN 22611 THEN 'XMLSchema'
            WHEN 22868 THEN 'Type'
        END
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
JOIN sys.trace_events e ON t.EventClass = e.trace_event_id
WHERE e.name IN ('Object:Created', 'Object:Deleted', 'Object:Altered')
    AND t.ObjectType != 21587
    AND t.DatabaseID != 2
    AND i.is_default = 1
    AND t.EventSubClass = 1

EventType        DatabaseName   ApplicationName  StartTime               ObjectName    ObjectType
---------------- -------------- ---------------- ----------------------- ------------- ------------
Object:Created   test           SSMS - Query     2016-02-11 13:36:46.727 NULL          Database
Object:Created   test           SSMS - Query     2016-02-11 13:36:46.760 tbl           Table
Object:Altered   test           SSMS - Query     2016-02-11 13:36:46.803 tbl           Table
Object:Created   test           SSMS - Query     2016-02-11 13:36:46.837 ix            Index
Object:Deleted   test           SSMS - Query     2016-02-11 13:36:56.347 NULL          Database

6. Server Events

Также через дефолтный трейс существует возможность следить за тем, кто и когда делал бекапы и ресторил базы:

SELECT
    CASE WHEN t.EventSubClass = 1
        THEN 'BACKUP' 
        ELSE 'RESTORE'
    END, t.TextData, t.ApplicationName, t.LoginName, t.StartTime
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
WHERE i.is_default = 1
    AND t.EventClass = 115 -- Audit Backup/Restore Event

TextData             ApplicationName                 LoginName   StartTime
-------------------- ------------------------------- ----------- -------------------------
BACKUP DATABASE      SSMS - Query                    PC\SergeyS  2016-01-21 13:05:26.390
RESTORE DATABASE     dbForge Studio for SQL Server   PC\SergeyS  2016-01-22 12:46:45.717
BACKUP DATABASE      SQLCMD                          sa          2016-01-24 10:16:40.317

Или отслеживать потребление памяти SQL Server-ом:

SELECT
      t.StartTime
    , [Type] = CASE WHEN EventSubClass = 1 THEN 'UP' ELSE 'DOWN' END
    , t.IntegerData
FROM sys.traces i
CROSS APPLY sys.fn_trace_gettable([path], DEFAULT) t
WHERE t.EventClass = 81 -- Server Memory Change
    AND i.is_default = 1

StartTime                Type  IntegerData
------------------------ ----- -----------
2016-02-10 02:52:42.887  UP    191
2016-02-10 02:53:00.640  UP    371
2016-02-10 02:53:34.917  UP    734
2016-02-10 02:53:52.140  UP    916
2016-02-10 10:05:00.027  DOWN  736
2016-02-10 10:17:17.417  UP    921
2016-02-10 11:52:14.930  DOWN  735
2016-02-10 12:00:32.577  DOWN  553
2016-02-10 13:06:11.540  UP    751
2016-02-10 15:11:10.487  UP    936
2016-02-10 15:15:26.107  DOWN  714

Небольшое послесловие

Дефолтный трейс является достаточно мощным средством для отслеживания состояния сервера. Разумеется, он имеет много недостатков, например, упомянутое ограничение в 20Мб и заявление от Microsoft что данная функциональность начиная с SQL Server 2008 объявлена устаревшей. Но все же иногда дефолтный трейс бывает очень полезным на этапе первичной диагностики проблем с SQL Server. Надеюсь мои примеры выши смогли это наглядно показать.

Все тестировалось на Microsoft SQL Server 2012 (SP3) (KB3072779) — 11.0.6020.0 (X64).

Если хотите поделиться этой статьей с англоязычной аудиторией:
Hidden gems of DEFAULT TRACE in SQL Server

Jetzt auch beliebt: