在之前的讨论中，提到了不直接查询SharePoint数据库的诸多原因和潜在问题。如果还没有阅读那篇文章，建议在继续阅读本文之前先去看一看。现在，将讨论的是 SharePoint 2010 版本，它带来了一些新的特性和改进。
首先，让来了解什么是 SharePoint 日志数据库。打开 SQL Management Studio 并展开数据库列表，会发现一个名为 WSS_Logging 的新数据库。SharePoint 2010 通过将所有操作记录到这个 WSS_Logging 数据库中来跟踪它的所有活动。它将 14 号文件夹下累积的原始日志数据聚合起来，并导入到这个日志数据库中。这是 SharePoint 中唯一一个 Microsoft 允许开发者直接读取、查询和构建报告的数据库。
在 WSS_Logging 数据库中，有许多有用的视图供使用，现在要向展示的是 "RequestUsage" 视图。每当用户访问生成页面请求时，就会将记录插入到这个数据库中的一个分区表中，而 "RequestUsage" 视图则会将所有分区表中的数据合并起来，供在自定义解决方案（Web 部件、报告、应用程序页面等）中使用。下面是一个示例：
让更深入地了解背后的机制以及这些数据的来源。首先，导航到 SharePoint 2010 中央管理 > 监控 > 配置使用情况和健康数据收集。接下来，将通过指定要记录到 14 号文件夹下文本文件中的事件来配置数据收集。使用下面的截图来配置自己的 SharePoint 系统。
注意到 "Log Collection Schedule" 部分了吗？这意味着有一个定时任务负责收集位于 14 号文件夹下的日志文件，并将指定的事件复制到日志数据库中，以便后续用于报告目的。甚至可以根据服务器的负载模式来安排这个定时任务，正如下一步将看到的那样。
出于好奇，打开了最喜欢的故障排除工具（SharePointManager 2010）来跟踪这个任务。如下图所示，已经配置了 "Microsoft SharePoint Foundation Usage Data Import" 任务，从中央管理每分钟运行一次。
出于好奇，决定使用 .NET Reflector 来查看这个定时任务是如何工作的，注意到了两件事情。第一件是构造函数中指定的 Job lock 类型是 SPJobLockType.None，这指示定时服务在所有 Web 前端上运行这个任务，这是有意义的！Job 和 None LockTypes 之间的差异在于，Job LockType 确保定时任务只在一台服务器上运行，而 None 确保任务在每台服务器上运行。
第二件是 execute 方法中的 ImportUsageData() 方法，当定时任务运行时会调用这个方法，这个方法负责将事件从日志文件复制到日志数据库中。如果需要了解更多，可以进一步扩展这个方法。
那么，所说的四个好处是什么呢？
1. 直接读取、查询和构建报告的日志数据库完全得到 Microsoft 的支持。第三方应用程序甚至可以将数据写回其中。
2. 它在所有SharePoint部署中默认启用。
3. 保留策略是可定制的，允许管理想要累积的数据量（默认为 14 天，但可以使用 PowerShell 修改）。
4. 架构将被记录，这无疑会方便其使用。
还想指出，日志数据库是许多使用情况和健康报告的基础。例如，Web Analytics 功能严重依赖于它，因为它取出数据，对其进行一些额外的处理，将其放入分析数据库，并基于此生成报告。