简介
自 ODBC Trace 发布以来，我一直在期待面向数据访问的良好的通用内置跟踪工具。OLE DB 有许多不同类型的跟踪方式；我想到的两个是与 Visual Studio 分析器兼容的工具和 ATLTRACE（用于 ATL OLE DB 模板的跟踪宏）。OLE DB 和 MDAC 的问题不在于它们没有跟踪，而在于有太多不同种类的跟踪，每个跟踪都绑定到不同的评估机制。很难（如果不是不可能的话）跟踪到各层的数据访问堆栈并获得一 个跟踪输出。
ADO.NET 2.0 和 SQL 本机客户端（一个新的 OLE DB/ODBC/网络库功能）包含一个灵活而丰富的内置数据跟踪工具。Microsoft 已经实现了其全部四个 .NET 数据提供程序（SqlClient、OracleClient、OleDb 桥和 Odbc 桥）、ADO.NET DataSet 和友员、SQL 本机客户端 OLE DB 和 ODBC 提供程序/驱动程序，以及最终的 SQL Server 2005 网络库。本文中的信息旨在让您迅速熟悉跟踪，并向您展示如何执行某个粗略的跟踪文件分析，还介绍了简单的跟踪用例。在本文的结尾，我将讨论如何构造跟踪层 以使其能够扩展到不同的跟踪技术，并建议了使用它的更多方法。
跟踪点已经编程到 .NET 和 SQL 本机客户端库中。在使用 IL 反汇编程序（如 Reflector）时，您可能已经注意到跟踪点。第一步是配置可允许您获得基本输出的功能。
[@more@]使用跟踪的基本步骤如下：1. | 设置数据跟踪 DLL 注册表项、ETW 提供程序和 WMI 架构。 |
2. | 配置和运行跟踪。 |
3. | 将跟踪结果采集到以逗号分隔的值文件中。 |
如果您暂时不熟悉某些缩写（如 ETW 和 WMI），请不必担心。让我们逐一回顾这些步骤，然后返回来讨论它们如何工作。
注 如果您希望在开始设置数据跟踪之前先了解它如何工作，请阅读本文临近结尾处的数据跟踪原理。
设置数据跟踪
设置跟踪 DLL 注册表项：该 步骤包括运行注册表脚本或手动编辑注册表，其目的在于将数据跟踪挂钩到它的 Event Tracing for Windows (ETW) 提供程序。目前，编辑注册表是完成该步骤的唯一方法；在将来，可能会有一个控制面板应用程序或配置文件机制。我们将在以后详细地讨论如何使用该注册表项； 现在，我们只针对计算机上每个与数据相关的进程来启用跟踪。
1. | 找到注册表项 HKLMSoftwareMicrosoftBidInterfaceLoader。 |
2. | 添加一个新的字符串值（在 Loader 项下面）： |
Name=":Path" Value="C:WINDOWSMicrosoft.NETFrameworkv2.0.40607AdoNetDiag.dll"
这里假设您安装了 Beta 1 版的 .NET Framework 2.0，并且您的系统驱动器为 C: 驱动器。请注意，Path 之前的冒号非常重要。您还可以运行本文中包含的 setup_trace.reg 文件。
注册数据跟踪架构：您 刚刚注册的 AdoNetDiag.dll 是一个适配器组件，它使得针对数据跟踪而实现的任何库看上去像 Event Tracing for Windows 提供程序。现在，您可以使用提供程序了，但是为了让它们在公共提供程序列表和 WMI 工具中显示，您需要为 AdoNetDiag.dll 所公开的事件注册 ETW 提供程序及其 WMI 架构。这可以通过一个称为 MOF 文件的特殊格式架构文件和一个名为 mofcomp 的实用工具来实现。ADO.NET 2.0 在 C:WINDOWSMicrosoft.NETFrameworkv2.0.40607 目录中提供了 MOF 文件，但是，由于数据跟踪是进行中的工作，因此为了获得最佳结果，您应当使用本文附带的 MOF 文件。运行本文附带的 Windows register_mof.cmd 脚本；它将运行注册代码。如果您从命令行手动发出该命令，它将如下所示。
1. | mofcomp adonetdiag_beta1.mof |
使用如下命令列出 ETW 提供程序，可以检查提供程序是否已正确注册
1> logman query providers
您应当看到已注册的提供程序，以及 OS 或其他产品所附带的其他提供程序。请注意，每个提供程序都由一个 GUID 来标识。提供程序列表应如下所示：
Provider GUID
--------------------------------------------------------------------------
*System.Data.1 {914ABDE2-171E-C600-3348-C514171DE148}
ACPI Driver Trace Provider {dab01d4d-2d48-477d-b1c3-daad0ce6f06b}
Active Directory: Kerberos {bba3add2-c229-4cdb-ae2b-57eb6966b0c4}
IIS: SSL Filter {1fbecc45-c060-4e7c-8a0e-0dbd6116181b}
IIS: WWW Server {3a2a4e84-4c21-4981-ae10-3fda0d9b0f83}
IIS: Active Server Pages (ASP) {06b94d9a-b15e-456e-a4ef-37c984a2cb4b}
MSSQLSERVER Trace {2373A92B-1C1C-4E71-B494-5CA97F96AA19}
Local Security Authority (LSA) {cc85922f-db41-11d2-9244-006008269001}
*System.Data.SNI.B1 {C22CFA1B-A312-354C-33F7-ACACA46CE990}
*SQLNCLI.1 {BA798F36-2325-EC5B-ECF8-76958A2AF9B5}
Windows Kernel Trace {9e814aad-3204-11d2-9a82-006008a86939}
*System.Data.OracleClient.1 {DCD90923-4953-20C2-8708-01976FB15287}
*ADONETDIAG.ETW {8B98D3F2-3CC6-0B9C-6651-9649CCE5C752}
ASP.NET Events {AFF081FE-0247-4275-9C4E-021F3DC1DA35}
NTLM Security Protocol {C92CF544-91B3-4dc0-8E11-C580339A0BF8}
IIS: WWW Isapi Extension {a1c2040e-8840-4c31-ba11-9871031a19ea}
HTTP Service Trace {dd5ef90a-6398-47a4-ad34-4dcecdef795f}
Spooler Trace Control {94a984ef-f525-4bf1-be3c-ef374056a592}
我对输出进行了少许改动 — 在我们所关心的提供程序旁边添加了一个星号。您还可以检查使用 WMI CIM Studio 工具注册的 WMI 架构。您可以下载 WMI 管理工具。WMI 数据跟踪架构相当简单，我们将在以后讨论它们。
运行跟踪
运 行跟踪由以下操作组成：定义已命名的跟踪并发出 ETW 命令，以便通过名为 logman（日志管理器）的实用工具来使用这些跟踪。通过运行本文附带的 traceon.cmd 脚本来启动跟踪。本文假设您运行的是 Windows 2003，并且该文件中的命令如下所示：
@Logman start MyTrace -pf ctrl.guid.adonet.beta1 -ct perf -o Out.etl -ets
该命令文件定义了一个已命名的跟踪实例 (MyTrace)，并指定了刚刚注册的所有提供程序。提供程序的列表和选项在一个名为 ctrl.guid.adonet.beta1 的独立文件中指定。该文件的内容如下所示：
{7ACDCAC8-8947-F88A-E51A-24018F5129EF} 0x00000000 0 ADONETDIAG.ETW
{914ABDE2-171E-C600-3348-C514171DE148} 0x00000000 0 System.Data.1
{C22CFA1B-A312-354C-33F7-ACACA46CE990} 0x00000000 0 System.Data.SNI.B1
{DCD90923-4953-20C2-8708-01976FB15287} 0x00000000 0 System.Data.OracleClient.1
{BA798F36-2325-EC5B-ECF8-76958A2AF9B5} 0x00000000 0 SQLNCLI.1
以上各行对每个提供程序、提供程序选项和提供程序名称都包含了一个 GUID（换行是为了便于查看）。我们将在以后更详细地讨论提供程序选项。
如 果按这种方式调用 logman，会将所有的事件以一种简洁的二进制格式写入到事件跟踪日志文件中。这些文件的后缀约定为 .etl。打开该文件之后，请运行本文下载内容中包含的示例程序 GetDataSet.exe。通过运行 traceoff.cmd 脚本来关闭跟踪。这只是发出以下命令：
@Logman stop MyTrace -ets
在发出该命令的目录中，您应当看到一个名为“out.etl”的文件，该文件大约有 150 KB。因为我们已经在每个细节级别（ADO.NET 提供程序、网络调用和来自 SQL Server 的响应 — 如果 SQL Server 运行在同一台计算机上）打开了跟踪提供程序，所以将有大量输出。我们将在以后看到对输出进行筛选的方法。请注意，如果使用 Visual Studio 2005 来运行测试程序，可能会在某些情况下（例如，当服务器资源管理器运行数据访问代码时）生成额外的跟踪事件。
将结果采集到 CSV 文件中：
除 非您是那种少有的喜欢读取二进制格式的人，否则 out.etl 文件对您来说是不可读的格式。ETW 实用工具包括一个名为 tracerpt.exe 的基本格式化程序，以便将该文件转换为以逗号分隔的值文件。要获得 CSV 文件，请运行 report.cmd，它会发出以下命令：
@TraceRPT /y Out.etl
该实用工具可生成两个文件：summary.txt（在会话中捕获的跟踪事件的摘要）和 dumpfile.csv。这些文件是 tracerpt 默认的文件名输出，您可以通过命令行选项来更改它们。Dumpfile.csv 是包含所需信息的文件。现在，该文件可以使用 Excel 来浏览；以后，您可以执行进一步的后处理，如将数据加载到 SQL Server 中并用 SQL 查询它。就是这么简单！现在，您拥有了第一个跟踪方式。下面让我们看一下输出。
读取跟踪输出
数据跟踪提供程序公开了三种主要类型的信息：跟踪点信息和提供程序标识、事件类型以及线程和计时信息。具体来说，信息列由以下内容组成：
事件名称 — 数据跟踪事件提供程序的名称
事件类型 — TextW 或 TextA
TID — 线程 ID
时钟时间 — 事件的时间戳
内核 (ms) — 处于内核模式下的毫秒数（CPU 时间）
用户 (ms) — 处于用户模式下的毫秒数（CPU 时间）
用户数据 — 有关跟踪点的详细信息
尽 管允许 WMI 提供程序公开复杂的架构，但是数据跟踪提供程序只公开两个简单的事件类型：TextW 和 TextA。TextW 面向 Unicode 字符消息，TextA 面向 ANSI 字符消息。请注意，许多数据跟踪事件都括有“begin”和“end”对，这些对便于在以后执行嵌套的 API 调用。例如，在该跟踪中，“用户数据”域看上去如下所示：
"enter_01 1# dataSet"
"enter_02 1# dataSet startRecord
maxRecords srcTable command behavior=16{ds.CommandBehavior}"
" 1#"
" 1#"
"enter_03 1#"
"enter_04 1#"
"enter_05 pmo: 00000000{void}"
... many events deleted
"leave_05"
" 1# created session 2"
" 1# Pooled
database connection created."
"leave_04"
"leave_03"
很容易看出，用户程序调用了 DataAdapter.Fill(DataSet)，而 DataAdapter.Fill(DataSet) 调入了另一个重载 DataAdapter.Fill，而 DataAdapter.Fill 又调入了 SqlConnection.Open，以此类推。每个 enter_nn 事件都有相应的 leave_nn 事件。在本例中，您将跟踪对基础 SNI（SQL Server 网络接口）低级协议事件的调用。但是，由“主流”跟踪程序 System.Data.1 生成的用户数据有什么样的有趣括号格式呢？
用户数据和 ADO.NET 跟踪
顾名思义，用户数据域的内容和格式完全由用户（在本例中为跟踪提供程序）自行决定。对 System.Data.dll 和 System.OracleClient.dll 的调用使用的是可方便解码的特殊格式。例如，从上一个跟踪记录序列中提取以下条目：
"enter_04 1#"
这可被解码为：
parms
因此，上述示例意味着，有一个对 System.Data.ProviderBase.DbConnectionBase 的 Open 方法的 API 调用。之所以使用缩写的命名空间，是因为这会保持较小的输出。后跟磅符号 (1#) 的参数编号用于标识 DbConnectionBase 对象的特定实例；当您使用复杂的跟踪并查看许多实例时，这很有用。下面的几个图表将有助于对用户数据进行解码：
| 表 1. .NET 跟踪点中使用的命名空间缩写 | ||
| 说明 | 说明 | 命名空间 |
| SqlClient 托管提供程序 | sc | System.Data.SqlClient |
| OleDb 托管提供程序 | oledb | System.Data.OleDb |
| Odbc 托管提供程序 | odbc | System.Data.Odbc |
| Oracle 托管提供程序 | ora | System.Data.OracleClient |
| DataSet/DataTable/Data* | ds | System.Data |
| Common 代码 | comn | System.Data.Common |
| Provider 基本实现类 | prov | System.Data.ProviderBase |
| 表 2. .NET 跟踪点中使用的类别 | |
| 表 2. .NET 跟踪点中使用的类别 | 类别 |
| API | 调用了公共 API（方法，属性） |
| OLEDB | 代码调用 OLEDB 组件 |
| ODBC | 代码调用 ODBC API |
| SNI | 代码调用 SNI |
| ERR | 错误 |
| WARN | 警告 |
| INFO | 信息 |
| RET | 返回值，通常采用 API|RET 形式 |
| THROW | 将引发 new 异常（不适用于将重新引发的异常） |
| CATCH | 代码捕捉异常 |
| CPOOL | 连接池活动 |
| ADV | 高级跟踪点 |
使 用这些信息，您可以对跟踪输出进行后处理，并只查看与 DataSet 相关的事件，也可以在 OleDb 托管事件和 OLE DB 本机事件之间进行选择。您还可以将这些信息保留在一起，以便进行事件关联。您所需的只是一个使用 LIKE 运算符的简单查询。但是，数据跟踪还不成熟，其格式和内容的确切细节可能会在将来有所更改。一定要随着功能的发展重新测试任何后处理代码。
配置要跟踪的应用程序
在本文的开头，我提到过配置 Loader 注册表项的 :Path 字符串值。因为数据访问跟踪还不成熟，所以还需要手动配置。具体来说，使用数据跟踪的程序员不应当依赖这个将在未来版本中可手动配置的注册表项。它已经由 ACL（安全访问控制列表）保护，使其只能由管理员更新；在未来的版本中，它可能是只读的。
如 果不理会该警告，那么只配置 :Path 值可使跟踪在运行于给定计算机上的所有应用程序上可用。例如，如果程序员正在其计算机上运行 SQL Server 2005 实例和数据访问客户端，那么打开 SNI 跟踪将跟踪来自这两端的 SNI 调用。这可能会生成一些较大的输出，尽管在某些用例中，这恰好是所需的输出类型。如果没有 :Path 值，或者要将 :Path 值从跟踪中排除，则可以配置要跟踪的应用程序。
如果没有 :Path 值，将只跟踪特别配置的应用程序。通过指定 REG_SZ 或 REG_EXPAND_SZ 条目，并将程序的主可执行文件的完整路径指定为值名，以及将 AdoNetDiag.dll 的完整路径指定为值，您可以将应用程序配置为“可跟踪的”。您还可以使用路径名和 * 通配符将整个目录配置为可跟踪的。
如果有 :Path 值，则可以通过添加 REG_SZ 或 REG_EXPAND_SZ 条目以及值 :（一个冒号），来限制对应用程序或特定目录中应用程序的跟踪。允许在目录名中使用通配符。例如，包含目录名 (C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBinn*) 和 : 值的名称域将阻止 SQL Server Binn 目录中的所有程序（如 SQL Server、SQL Trace 等）出现在跟踪中。如果我正在应用程序所在的同一台计算机上运行 SQL Server，则通常希望如此。请记住，配置注册表项只是对数据跟踪提供程序 DLL 进行命名（此时，只有 AdoNetDiag.dll 可供选择）；它不打开跟踪。这是一个特别有用的功能，因为您可以在不打开长期运行的程序（如 Web 服务器或 Windows 服务）的情况下，在它执行之前配置和设置数据跟踪。然后，您可以在该程序运行时，使用 logman 打开和关闭跟踪，而不必干扰该程序。在您不使用跟踪时，不会因它而影响性能。如果您要跟踪网络问题，则不必用任何特殊的跟踪标志运行 SQL Server，即可获得详细信息。
您还可以配置要将哪些提供程序信息跟踪到哪些文件，并精确控制跟踪程度。您可以像对 traceon.cmd 文件一样，将所有四个提供程序的输出跟踪到一个文件中，或者将每个提供程序的输出分隔到一个文件中。这可以通过使用 logman 实用工具创建命名的跟踪来完成。下面的示例将创建四个跟踪：
logman create trace test1 -p System.Data.1
logman create trace test2 -p System.Data.OracleClient.1
logman create trace test3 -p SQLNCLI.1
logman create trace test4 -p System.Data.SNI.B1
除了从命令行使用 logman 以外，您还可以使用 Snap-in for Performance Logs And Alerts 来配置、运行和停止跟踪。对如何使用这个 MMC 管理单元的描述超出了本文的范围。
通 过在 logman control.guid 文件中操作位，您可以对要跟踪的内容进行一些控制。如果您像上例显示的那样，对每个跟踪都使用一个提供程序并采用默认值，则不需要 control.guid 文件，但是 traceon.cmd 使用了一个。要刷新内存，可以使用 control.guid 中的下行：
{914ABDE2-171E-C600-3348-C514171DE148} 0x00000000 0 System.Data.1
该行中的信息由以下各部分组成：
提供程序指南 — 哪个 ETW 提供程序
控制位 — 在本例中为 0x00000000
控制值 — 在本例中为 0
提供程序名称 — ETW 所必需的，但是 logman 实用工具会忽略它
通过在 Control Bits 和 Control Value 字段中设置位，您可以拥有一个宏级别的事件预筛选机制。有效值是：
0x0002 Regular tracepoints
0x0004 Execution flow (function enter/leave)
0x0080 Advanced Output
还有一个仅对 System.Data.1 具有特殊含义的位
0x1000 Connection Pooling specific trace
当然，这些位可以是连在一起的“OR'd”。如果指定了 0x00000000，则假设为 0x00000006。
在控制值中，可以设置两个可能的非默认值：
128 - Convert Unicode text to ASCII text (reduces etl file size)
64 - Disable tracing in this component
尽管控制位是位屏蔽，但是控制值必须设置为数字。请注意，设置这些控制位不会提供用来配置单个组件的粒度机制，但这会便于筛选事件类型，而无需您亲自对 CSV 文件进行后处理。
使用跟踪解决参数绑定问题
现在，我们已经快速概览了跟踪，下面我将提供一个简单的用例。当应用程序将“吃掉”丰富的错误信息并生成礼貌但“缺乏信息”的消息时，我通常使用 ODBC 跟踪来确定问题所在。这样的应用程序代码看上去将如下所示：
string s = GetConnectionStringFromConfigFile();
using (SqlConnection conn = new SqlConnection(s))
using (SqlCommand cmd = new SqlCommand(
"select * from authors where au_id = @auid", conn))
{
// the error is hardcoded here but could have come from suboptimal
// editing in a graphic user interface
cmd.Parameters.Add("@auid", SqlDbType.Int);
cmd.Parameters[0].Value = 123456789;
SqlDataReader rdr = null;
try {
// some code that could fail goes here
conn.Open();
rdr = cmd.ExecuteReader();
while (rdr.Read())
Console.WriteLine(rdr[0]);
rdr.Close();
}
catch (Exception e) {
MessageBox.Show("polite error message");
}
}
在本例中，错误是由参数类型不匹配引起的，并且诊断该错误的人员可能无法访问程序的源代码。在打开跟踪后，我们将看到如下所示的输出：
"enter_01 1#"
" 1#"
" 1#"
" 1# created session 3"
" 1# adding session 3 to pool"
" 1# using session 3"
" 1# getting session 3 from pool"
" 1# Command executed as RPC."
" 1#"
"leave_01"
"enter_01 1#"
" infoNumber=245 errorState=1 errorClass=16
errorMessage='Syntax error converting the varchar value '172-32-1176' to a
column of data type int.' procedure='' lineNumber=1"
"leave_01"
这会直接向我们显示存在参数值不匹配的情况。本文中的代码提供了示例和跟踪文件。请注意，因为我们只是用 System.Data.1 提供程序进行跟踪，所以本例中的跟踪文件简洁得多。
两个关键的诊断案例
有 时，可以使用数据跟踪来阐明以其他方式可能需要数天或数周才能发现的问题。通过回收资源来诊断问题就是这样一个例子。有时，程序逻辑错误可能会导致程序最 终失去连接或者重载连接池。例如，开始一个事务并具有一个永不调用 COMMIT 或 ROLLBACK 的逻辑路径，将导致连接保留在事务连接池中，直到该事务超时。这会导致一些奇怪的连接池行为，从而使应用程序程序员（和诊断人员）感到困惑。一个相关的情 形可能只是无法关闭连接，并让 pooler 和超时功能执行该工作 — 婉转地说，这是关闭连接的“次最优”方法。如果针对后处理的跟踪运行 SELECT 语句来观察连接池活动并将其与事务活动相关联，那么会对解决这些棘手的问题大有帮助。在本例中，正如事务超时跟踪条目一样，“enter-leave”对 尤其有用。
另一个情形就是当应用程序的连接时间似乎异常得长时。例如，由于网络库的可能配置方式，SQL Server 可能会尝试通过 TCP/IP 建立连接，然后在 TCP/IP 失败时，使用已命名的管道或客户端协议列表中的其他协议。如果该列表中的第一个协议因超时而失败，那么这可能会使连接看上去很慢或者使响应时间看上去很 长。您可以使用数据跟踪在图形详细信息中看到这种情况，这是因为对 SqlClient 和其他 .NET 数据托管提供程序的跟踪与来自非托管堆栈和网络的跟踪集成在了一起。事件的整个进展甚至将为您包含在“enter-leave”块中，时间戳将允许您查看 Open() 调用将时间花在何处。
我们只是浅谈了这个复杂而强大的功能的用法。在将来进行实验时，您可以考虑以下想法：
1. | 将跟踪集成到单元测试中 |
2. | 对 DataSet 和 DataReader 调用进行比较分析，以确定 DataSet 将时间花在何处 |
3. | 将数据跟踪与 ASP.NET 和其他 ETW 提供程序结合使用 |
4. | 使用 SQL Server ETW 提供程序一起执行数据跟踪和 SQL Server 跟踪 |
5. | 诊断其他网络协议问题 |
数据跟踪原理
现在，您获得了一种在 Microsoft 数据访问堆栈中设置、运行和解释跟踪的指导方法。但是，除了发出命令行脚本以外，接着会发生什么事情呢？
数 据跟踪基于提供程序模型本身。ADO.NET 数据提供程序或其他数据访问代码使用标准的 API（这些 API 本身使用标准的跟踪挂钩）来将跟踪信息填充到模型中，并且在将来可能会生成多个数据跟踪提供程序。目前只有 AdoNetDiag 可用，但是您可以作出如下设想：数据跟踪用户将在粒度级别提供事件预筛选功能，或者使用另一个跟踪输出系统（如 OutputDebugString）或直接输出到 SQL Server 中，以便于搜索/查询。您甚至还可以将数据跟踪挂钩到 .NET System.Diagnostics.Trace。
ADO.NET 2.0 和 SQL 本机客户端附带了一个针对 Event Tracing for Windows (ETW) 系统的适配器。您可以顺利地从托管堆栈跟踪到非托管堆栈，以及从非托管堆栈跟踪到托管堆栈。ETW 是一个高性能的跟踪系统，最初引入它的目的是为编写设备驱动程序的人员实现内核级别的跟踪。下面将以数据跟踪作为示例来更深入地介绍 ETW。
什么是 ETW？
与 Windows Performance Monitor 相比，Event Tracing for Windows 旨在提供较低开销的跟踪。ETW 通常占用不超过 5% 的 CPU，它每秒可以记录多达 20,000 条事件。启用实时跟踪会相当快。ETW 使用基于提供程序的模型；在本例中，提供程序是向事件系统发送事件的系统组件或应用程序组件。Active Directory、IIS 和 ASP.NET 都是事件提供程序的示例。ADO.NET 和 SQL 本机客户端的数据跟踪注册了五个 ETW 事件提供程序。
1. | System.Data.1 — System.Data.dll 中的 ADO.NET 提供程序和类 |
2. | System.Data.OracleClient.1 — System.OracleClient.dll 中的 OracleClient 提供程序 |
3. | System.Data.SNI.B1 — 来自 System.Data 的 SNI（在 .NET 2.0 Beta 2 中，它更改为 System.Data.SNI.1） |
4. | SQLNCLI.1 — SQL 本机客户端提供程序和来自 SQL 本机客户端的 SNI |
5. | ADONETDIAG.ETW — 提供来自 ETW 适配器本身的事件 |
ETW 提供程序日志为每个事件都生成一个时间戳。当您启动跟踪时，可以指定一个高精度的时间戳，也可以指定一个低精度的时间戳。在我们的 traceon.cmd 文件中，我们使用 -ct perf 选项选择了一个高精度的时间戳。在上面的“单个文件”脚本中，我们选择了默认的（低精度）时间戳。在高性能和易于使用之间，ETW 选择了前者。用 tracerpt.exe 格式化 ETW 跟踪时会生成粗略的解码。WMI 中记录了 ETL 文件的格式以及单个跟踪提供程序的架构，因此可让程序员构建自己的专用格式化程序。使用 ETW 有一个非常好的功能，那就是所生成的跟踪可以与 ASP.NET 跟踪（在这方面为低级别的 OS 内核跟踪）结合使用。所有的事件都可以按每个提供程序记录到单个文件中以便进行关联，也可以记录到单独的文件中。有关 Event Tracing For Windows 的信息，可以在 patterns & practices 站点的 Performances Best Practices At A Glance 页上找到。
ETW 输出可以由各种工具使用，如果任何工具都无法满足您的特定需要，则可以构建您自己的工具。logparser 就是此类用户工具的一个例子。Logparser 不只是使用来自 ETW 的输出，它还可以使用诸如 IIS 日志文件和 Windows 事件日志之类的其他输出。Logparser 随后允许您使用类似于 SQL 的语法来查询事件。Logparser 可作为 IIS 6.0 Resource Kit Tools 的一部分来使用。
小结
在 ADO.NET 2.0 版本中，已经在提供程序级别、网络协议级别以及数据库访问所使用的某些组件（如 ADO.NET DataSet）中添加了跟踪。该模型的灵活性将适应未来的各种跟踪引擎；API 非常简单，因此，编写提供程序和用户应用程序的人员可以向其产品中添加跟踪。当前的实现方式是将 ETW 用于跟踪，并提供一种中断最少的低级别方法来收集已公开的跟踪点事件。用于后处理跟踪数据或在执行时筛选跟踪的不同方法，将允许不同的组（如内部的软件支 持诊断人员和 Microsoft 产品支持服务人员）来使用跟踪。
数据跟踪与当前跟踪收集工具的集成以及对未来的跟踪收集工具的扩展，造就了疑难解答和管理员工具箱中的一个有效而耐用的工具。祝您跟踪愉快！
Bob Beauchemin 是 DevelopMentor 的教员、课程作者和数据库课程联系人。他作为以数据为中心的分布式系统的架构师、程序员和管理员，拥有二十五年以上的经验。他为 Microsoft Systems Journal、SQL Server Magazine 和其他杂志撰写了有关 ADO.NET、OLE DB 和 SQL Server 的文章，他还是 A First Look at SQL Server 2005 for Developers 和 Essential ADO.NET 的作者。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/1697933/viewspace-888506/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/1697933/viewspace-888506/
扫一扫
423
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
