将日志导出到 SQL 数据库

将日志导出到 SQL 数据库

对于许多用户，Log Parser 所实现的查询功能并不能满足他们的需求。譬如，管理流量繁重的网站的公司通常需要将网站日志保存在中央数据库中，从而可以在其中运行任意数量的查询，并在 多台 Web 服务器间关联数据。Windows 事件日志及其它日志文件也可能存在这样的情况。

Log Parser 也可通过提供一个可用于将查询结果上载到数据库表的“SQL”输出格式，来应对上述情况。

一般而言，从日志文件到 SQL 表的简单“SELECT *”查询就可能解决问题，但是大多数时候，日志包含的一些条目，并不值得永久保存在数据包中。譬如，您可能想排除对图像文件的请求；也可能存在对不存在的页的请求。

以下命令可以做到这一点：

C:/Logs>logparser "SELECT * INTO LogsTable FROM ex*.log WHERE TO_LOWERCASE (EXTRACT_EXTENSION(cs-uri-stem)) NOT IN ('gif';'jpg';'png') AND sc-status <> 404" –i:IISW3C –o:SQL –database:LogsDatabase

这个命令要求 Log Parser 筛选出以“.gif”、“.jpg”和“.png”结尾的页的条目（URL 不分大小写）。该命令还将排除 HTTP 错误代码“404”（即“page not found”）产生的请求。

所有其它请求都将传递给 SQL 输出格式，后者将把记录保存到 INTO 子句所指定的表中。另外，这个输出格式还接受“database”参数（可用于指定目标数据库的名称）以及其它许多参数（可用于指定到 SQL 数据库连接的其它属性）。

若要实现上述操作，您可以将上面的命令放在一个批处理文件中，并使用 SCHTASKS.EXE 工具，设定该批处理文件每小时运行一次——好了！——您就得到了一个自动的机制，可定期将日志文件中的条目，上载到 SQL 数据库。

请注意，每次执行上述命令时，Log Parser 都会反复检查 所有 日志条目，并将所有这些条目多次上载到数据库。我们真正需要的是一个“仅分析尚未分析过的日志条目”的机制。

Log Parser 2.2 的一个新功能正好可以满足这一要求：“增量分析”功能，也称为“检查点 (checkpointing)”。

大 多数 Log Parser 输入格式支持一个名为“iCheckpoint”的参数。该参数可告诉输入格式将所分析的所有文件的当前状态，都保存在一个专门的数据文件（“检查点 (checkpoint)”文件）中。当您使用上一次分析期间生成的检查点文件执行查询时，输入格式将只分析输入文件中那些尚未分析过的部分——即 新的 条目。

所以，只需指定通过“iCheckpoint”参数，指定一个检查点文件的名称，具体如下：

C:/Logs>logparser "SELECT * INTO LogsTable FROM ex*.log WHERE TO_LOWERCASE (EXTRACT_EXTENSION(cs-uri-stem)) NOT IN ('gif';'jpg';'png') AND sc-status <> 404" –i:IISW3C –o:SQL –database:LogsDatabase –iCheckpoint:MyCheckpoint.lpc

在 您第一次执行该命令时，并不存在“MyCheckpoint.lpc”文件，而且 IISW3C 输入格式分析了所有日志文件中的所有条目，并对结果数据进行筛选，最后再上载到数据库。在分析了所有日志后，IISW3C 输入格式会将每个日志文件的当前大小保存到“MyCheckpoint.lpc”文件。

当您稍后运行相同的命令时，IISW3C 输入格式将从上次分析结束的地方，开始加载检查点文件，并分析日志，从而仅处理、筛选和上载新的日志条目。完成后，将针对日志文件的新大小更新检查点文件，随后这个过程将再次循环。

假如认真理解了本文开头处的设计说明，那么您可能已经知道：只需更改输入格式，您就重复使用该命令，将 Log Parser 输入格式支持的 任何 日志上载到数据库。想要上载事件日志条目吗？只需使用 EVT 输入格式，具体如下：

C:/Logs>logparser "SELECT * INTO EventLogsTable FROM System" –i:EVT –o:SQL – database:LogsDatabase –iCheckpoint:MyCheckpoint.lpc