RThomas's questions

我正在设置数据库审核。我想捕获由数据库用户发出的任何 DML 更改，而不是与应用程序相关的服务帐户。

简而言之，这是为了向我们的外部审计员证明，没有用户篡改应用程序之外的数据。

以下脚本设置了对所有原则都是全局的 DML 审计。

CREATE DATABASE AUDIT SPECIFICATION [OurDatabaseAuditSpec]
FOR SERVER AUDIT [OurAudit]
ADD (DELETE ON OBJECT::[dbo].[SensitiveData] BY [public]),
ADD (INSERT ON OBJECT::[dbo].[SensitiveData] BY [public]),
ADD (UPDATE ON OBJECT::[dbo].[SensitiveData] BY [public])
WITH (STATE = ON)
GO

我该如何修改此审计规范以捕获除应用程序服务帐户正在执行的操作之外的所有内容？

我是否仅限于单独指定每个原则，或者我可以指定一个例外？通读 BOL 似乎我只能列出要审核的原则 - 而不是要忽略的原则。

本周我发现，数据库恢复选项NORECOVERY和数据库恢复选项KEEP_CDC是互斥的。所以，这就引出了问题。您如何使用完整备份和日志备份进行数据库还原，保持 CDC 完整？

KEEP_CDC对 MSDN 等进行研究。除了指定的单个完整数据库还原之外，我找不到任何关于使用任何其他选项还原数据库的文档RECOVERY。

我能够找到一个尝试完成完整日志和后续日志的尝试，而无需keep_cdc等待最终日志。RECOVERY直到那时，表才使用andKEEP_CDC选项联机。结果是损坏的 CDC 架构，如此处所示。

如果打算进行KEEP_CDC还原，您是否真的仅限于完整备份，或者是否有类似于上述尝试的机制在除原始服务器之外的服务器上的多文件还原期间保持其完整？

我们的开发人员一直在存储过程中使用游标来删除旧密码历史记录。要删除的记录数由变量传递。

DECLARE hist_cursor CURSOR LOCAL FOR
    SELECT history_nr   FROM usr_pwd_hist   WHERE usr_id = @usr_id
    ORDER BY    history_nr ASC

OPEN hist_cursor

WHILE @to_delete > 0
BEGIN
    FETCH NEXT FROM hist_cursor INTO @hist_val

    DELETE FROM usr_pwd_hist WHERE CURRENT OF hist_cursor

    SET @to_delete = @to_delete-1
END

CLOSE hist_cursor; 
DEALLOCATE hist_cursor;

我想用基于集合的方法代替它。我不能做一个简单的 top 语句，因为要删除的记录数是一个变量。我不能在没有动态 sql 的情况下使用带有变量的 top，并且根据政策我们不允许在生产中使用动态 sql。

我正在考虑下面的这种方法，但它让我感到紧张，因为我知道 Microsoft 正计划改变 ROWCOUNT 影响返回结果的方式。通过将删除目标放在子查询中，我应该可以使用未来的 SQL 版本，但我仍然想知道是否有更好的方法来按时间顺序删除可变数量的记录。

SET ROWCOUNT @to_delete;  /* limit records to be deleted */
DELETE FROM usr_pwd_hist WHERE history_nr IN
(
    SELECT history_nr 
    FROM usr_pwd_hist
    WHERE usr_id = @usr_id
    ORDER BY history_nr ASC  
);
SET ROWCOUNT 0;  /* return rowcount to default setting */

想要从一天中获取所有记录。2013-03-05 00:00:00.000所以和之间的一切2013-03-05 23:59:59.999。我们在后端与发生在2013-03-06 00:00:00.000.

因此，在测试中我在 SSMS 中运行：

select cast('2013-03-05 23:59:59.999' as datetime)
select cast('2013-03-05 23:59:59.996' as datetime)
select cast('2013-03-05 23:59:59.994' as datetime)

并得到：

2013-03-06 00:00:00.000
2013-03-05 23:59:59.997
2013-03-05 23:59:59.993

毫秒部分回来了一点。在第一行的情况下，它真的很重要。因为我不想要 2013-03-06 00:00:00.000 - 我想要午夜前的一毫秒。

TSQL 在文档中声明它使用小数秒，而不是使用毫秒的 .Net datetime。这似乎只是语法差异，但如果您真的关心 TSQL 中的毫秒精度，您是否被迫全面使用DateTime2。将 from 转换为datetime2todatetime仍然会使事情恶化几毫秒。

在 c#DateTime.Parse("03/5/2013 23:59:59.999").Millisecond中仍然返回 999。

我解释得好吗？如果我关心毫秒精度，我datetime2只会坚持。

通常这将是一个简单的修复，但在这种情况下，我们使用的是datetime作为参数接收的 Microsoft 系统函数。

我们正在使用 CDC 来捕获对生产表所做的更改。更改的行正在导出到数据仓库 (informatica)。我知道 __$update_mask 列存储了哪些列以 varbinary 形式更新。我也知道我可以使用各种 CDC 函数从掩码中找出那些列是什么。

我的问题是这个。谁能为我定义该掩码背后的逻辑，以便我们可以识别仓库中已更改的列？由于我们在服务器之外进行处理，因此我们无法轻松访问那些 MSSQL CDC 函数。我宁愿自己在代码中分解面具。SQL 端的 cdc 函数的性能对于此解决方案是有问题的。

简而言之，我想从 __$update_mask 字段中手动识别更改的列。

更新：

作为替代方案，将更改列的人类可读列表发送到仓库也是可以接受的。我们发现这可以在性能上远远高于我们原来的方法。

以下 CLR 对此问题的回答符合此替代方案，并包括为未来访问者解释掩码的详细信息。然而，对于相同的最终结果，使用 XML PATH 的公认答案是最快的。

我们正在做一个 ETL 过程。总而言之，有一堆表应该是相同的。验证这些表（在两个不同的服务器上）实际上是否相同的最快方法是什么。我说的是模式和数据。

我可以像在单个文件或文件组上那样对自己的表进行哈希处理 - 将一个与另一个进行比较。我们有 Red-Gate 数据比较，但由于相关表包含数百万行，我想要一些性能更高的东西。

一种让我感兴趣的方法是对 union 声明的创造性使用。但是，如果可能的话，我想进一步探索哈希的想法。

发布答案更新

对于任何未来的游客......这是我最终采取的确切方法。它工作得很好，我们在每个数据库的每个表上都这样做。感谢下面的答案为我指明了正确的方向。

CREATE PROCEDURE [dbo].[usp_DatabaseValidation]
    @TableName varchar(50)

AS
BEGIN

    SET NOCOUNT ON;

    -- parameter = if no table name was passed do them all, otherwise just check the one

    -- create a temp table that lists all tables in target database

    CREATE TABLE #ChkSumTargetTables ([fullname] varchar(250), [name] varchar(50), chksum int);
    INSERT INTO #ChkSumTargetTables ([fullname], [name], [chksum])
        SELECT DISTINCT
            '[MyDatabase].[' + S.name + '].['
            + T.name + ']' AS [fullname],
            T.name AS [name],
            0 AS [chksum]
        FROM MyDatabase.sys.tables T
            INNER JOIN MyDatabase.sys.schemas S ON T.schema_id = S.schema_id
        WHERE 
            T.name like IsNull(@TableName,'%');

    -- create a temp table that lists all tables in source database

    CREATE TABLE #ChkSumSourceTables ([fullname] varchar(250), [name] varchar(50), chksum int)
    INSERT INTO #ChkSumSourceTables ([fullname], [name], [chksum])
        SELECT DISTINCT
            '[MyLinkedServer].[MyDatabase].[' + S.name + '].['
            + T.name + ']' AS [fullname],
            T.name AS [name],
            0 AS [chksum]
        FROM [MyLinkedServer].[MyDatabase].sys.tables T
            INNER JOIN [MyLinkedServer].[MyDatabase].sys.schemas S ON 
            T.schema_id = S.schema_id
        WHERE
            T.name like IsNull(@TableName,'%');;

    -- build a dynamic sql statement to populate temp tables with the checksums of each table

    DECLARE @TargetStmt VARCHAR(MAX)
    SELECT  @TargetStmt = COALESCE(@TargetStmt + ';', '')
            + 'UPDATE #ChkSumTargetTables SET [chksum] = (SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM '
            + T.FullName + ') WHERE [name] = ''' + T.Name + ''''
    FROM    #ChkSumTargetTables T

    SELECT  @TargetStmt

    DECLARE @SourceStmt VARCHAR(MAX)
    SELECT  @SourceStmt = COALESCE(@SourceStmt + ';', '')
            + 'UPDATE #ChkSumSourceTables SET [chksum] = (SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM '
            + S.FullName + ') WHERE [name] = ''' + S.Name + ''''
    FROM    #ChkSumSourceTables S

    -- execute dynamic statements - populate temp tables with checksums

    EXEC (@TargetStmt);
    EXEC (@SourceStmt);

    --compare the two databases to find any checksums that are different

    SELECT  TT.FullName AS [TABLES WHOSE CHECKSUM DOES NOT MATCH]
    FROM #ChkSumTargetTables TT
    LEFT JOIN #ChkSumSourceTables ST ON TT.Name = ST.Name
    WHERE IsNull(ST.chksum,0) <> IsNull(TT.chksum,0)

    --drop the temp tables from the tempdb

    DROP TABLE #ChkSumTargetTables;
    DROP TABLE #ChkSumSourceTables;

END

跟踪由 CDC 确定的进行更改的人员。

按照我的 datetime hack的思路，我尝试了相同的方法，将 suser_sname 添加为 cdc 更改跟踪表上具有默认值的新字段。但是，这似乎返回了 cdc 进程的所有者，而不是在基表上发起更改的用户。我也尝试了 original_login ，但它返回了 sql 服务帐户登录名。同样，可能与 cdc 进程相关联，而不是与发起更改的用户相关联。

我在 stack-overflow 上发现了一个类似的问题，但除了从前端或通过触发器跟踪更改之外没有其他答案，这似乎违背了使用 cdc 的目的。我不会重新发布，但由于原版在 stackoverflow 上，我想我会在这里尝试一下，特别是如果 R2 或 2012 引入了更好的方法。

所以，简而言之：我怎么知道是谁在变更数据捕获中做出了改变？

因此，我们开始探索在我们的一个生产数据库上使用变更数据捕获。我们想知道每次更改的日期时间。通读演练和教程等似乎标准方法是使用 LSN 与cdc.lsn_time_mapping系统表相关。这种方法有效，但在谈论每天成千上万的更改时不是很简单也不是很高效。

在测试环境中，我对更改跟踪表进行了以下调整。我发表了一条ALTER TABLE声明，在名为的末尾添加一列并将其设为[__ChangeDateTime]默认值GetDate()。该方法似乎有效，更改跟踪仍然正常运行，正在捕获日期时间。 但是乱搞系统表让我有点紧张。

如果这不是微软从一开始就添加的系统字段，他们一定有他们的理由。由于他们改为选择 LSN 到 cdc.lsn_time_mapping 方法，我是否通过这种方式创建自己的 hack 来解决问题？

更新：

在测试期间发现 GetDate() 有时不足以满足我们的需求 - 多个更改共享同一时间。建议使用sysdatetime() 和 datetime2将值移到纳秒级。显然只有 2008+ 的选项。

所以今天早上我们有一个长时间运行的过程导致问题（30 秒 + 运行时间）。我们决定检查参数嗅探是否是罪魁祸首。因此，我们重写了 proc 并将传入的参数设置为变量，以击败参数嗅探。一种尝试/真实的方法。Bam，查询时间得到改善（不到 1 秒）。在查看查询计划时，可以在原始索引未使用的索引中发现改进。

只是为了验证我们没有得到误报，我们对原始 proc 执行了 dbcc freeproccache 并重新运行以查看改进的结果是否相同。但是，令我们惊讶的是，原来的 proc 仍然运行缓慢。我们再次尝试了 WITH RECOMPILE，但仍然很慢（我们尝试在调用 proc 和 proc 内部重新编译）。我们甚至重新启动了服务器（显然是开发箱）。

所以，我的问题是......当我们在一个空的计划缓存上得到同样的慢查询时，参数嗅探怎么能怪罪......不应该有任何参数来嗅探？

相反，我们是否受到与计划缓存无关的表统计信息的影响。如果是这样，为什么将传入参数设置为变量会有所帮助？

在进一步的测试中，我们还发现在 proc 的内部插入 OPTION (OPTIMIZE FOR UNKNOWN) 确实得到了预期的改进计划。

所以，你们中的一些人比我聪明，你能提供一些线索来说明幕后发生的事情会产生这种结果吗？

另一方面，慢速计划也有理由提前中止，GoodEnoughPlanFound而快速计划在实际计划中没有提前中止原因。

总之

• 根据传入参数创建变量（1 秒）
• 重新编译（30+秒）
• dbcc freeproccache (30+ 秒)
• 选项（针对 UKNOWN 进行优化）（1 秒）

更新：

在此处查看慢速执行计划： https ://www.dropbox.com/s/cmx2lrsea8q8mr6/plan_slow.xml

在此处查看快速执行计划： https ://www.dropbox.com/s/b28x6a01w7dxsed/plan_fast.xml

注意：出于安全原因，表、模式、对象名称已更改。

我正在尝试获取我的冲突查看器中列出的所有合并复制冲突失败者的行 guid。导致冲突发生的错误已被识别并解决，但现在我需要去从订阅者中删除冲突失败者，以便他们停止尝试上传与每个新同步冲突的行。

我可以单独经历每个冲突以获得 rowguid，但其中有几千个。因此，肯定必须有一个我可以编写的查询来一次性获取这些数据。

任何人都有查询合并复制系统表以获取冲突信息或知道我应该查看哪个系统表的经验。我在互联网上找不到太多帮助。

有没有办法（可以接受注册表破解）从 SSMS 的上下文菜单中删除选项？

具体来说，当您右键单击合并复制发布时，我想从上下文菜单中删除删除选项。如果我们真的想删除它，我们将通过 tsql 来完成。

是的，有一个悲惨的故事激发了这个问题。

假设性问题 - 帮助情景规划。

假设我有一个 2008 R2 合并出版物，其中有 5 个活跃订阅者。删除发布并删除所有订阅。一周左右的时间过去了，数据不断添加或更新到曾经是订阅者的本地数据库中。

一周后，在原始数据库上创建了一个新发布，并且 5 个本地盒子都获得了新订阅。在不存在订阅的那一周在本地添加的数据会发生什么变化？

• A：新订阅创建后是否上传到发布者？

• B：下线那一周的数据是不是删了？

• C：发布者（以及其他订阅者）是否忽略了离线一周的数据？

• D：发生其他事情

如果 C? 有没有办法标记这些记录以进行复制，以便将它们提交给发布者，并最终提交给其他订阅者？

我有一个几个月前创建的复制方案。从那时起，架构发生了各种变化。所有现有订阅都在进行这些更改时进行了更新，因为发布也被设置为推送架构更改。

然而，最近在尝试添加新订阅时，初始快照无法应用。错误的原因是两个不同的视图应用失败，因为它们所依赖的表还没有被快照创建。

我知道我可以通过 sp_changemergearticle 存储过程指定文章的处理顺序。但是据我了解...这里的处理顺序设置是用于指定在同步期间将数据更改应用于订阅者的顺序。有没有办法指定初始化新订阅时应用文章的顺序？它使用相同的设置吗？

我认为生成新快照会导致引擎找出正确的顺序，但就我当前的出版物而言，它没有。即使在我生成新快照后，新订阅也无法应用快照。它告诉我失败的确切脚本，当手动应用时，很明显它失败了，因为视图所需的表尚不存在。

解决此问题的最佳方法是什么？设置文章的处理顺序是否会影响架构顺序和数据顺序，或者我是否需要查看其他地方来设置文章基于新订阅的顺序。

据我所知，处理顺序设置对快照在初始化期间应用其文章的顺序没有任何影响。主要是因为目前我所有的文章的处理顺序都为 0。那么，这是我可以控制的事情还是我受快照生成过程的支配？

我的合并复制方案突然开始失败。尝试同步时，它会抱怨存在无效对象。'dbo.myfunction'。该功能曾经存在但已被删除。只有一个表值函数对它的引用，它也已更新。我生成了一个新快照，但它继续抱怨该对象无效并且不会在订阅者处同步。

在复制中的某个地方，它仍在寻找该功能。我如何找到并删除它 - 当它不再存在时。

我什至查看了快照中的文件，但找不到任何引用它的地方。

我的发布者是 SQL 2008 R2 - 我所有的订阅者都是 SQL 2008 Express

只是好奇，根据 BOL

Wait Time (ms/sec) 是自上次更新以来等待该类别中的一个或多个资源的所有任务的等待时间（以毫秒为单位）。

Average Waiter Count 是等待的任务数。

在我的服务器上平均服务员计数总是等待时间/1000 四舍五入到最接近的第 10 位是巧合吗？这里有链接吗？当答案非常合乎逻辑但出于某种原因此时正在逃避我时，我会感到尴尬吗？

即这里是 latch 的最后 15 分钟的样本值，但其他等待类别是相同的（当任何值存在时）——我已经注意到它很长一段时间了（比最后 15 分钟长得多）它从来没有引起我足够的兴趣调查到现在。

Wait Time         Average Waiter Count
______________________________________
576               0.6
1403              1.4
1856              1.9
1233              1.2
1365              1.4

在我看来，由于等待时间是一个累积计数，而服务员是一个平均值，所以这些数字不应该像它们看起来那样严格地遵循彼此的比例。

我们有一个非常活跃的数据库服务器，上面运行着各种各样的应用程序。其中最繁忙的两个是一个全天进行文档扫描和工作流处理的 Laserfiche 数据库（平均大约 2800 个批处理请求/秒）和一个路由电子邮件的黑莓服务器应用程序。还有大约 25 个其他小型应用程序数据库。

我们是一个政府机构，所以我们只获得了单个数据库服务器许可证的预算。

最近，我们获得了一个 SAN 来解决磁盘争用问题。

所以目前我们在它自己的磁盘上运行了 TempDB（raid 1 镜像对），并且我们已经将事务日志和数据文件移动到了 SAN 上。事务日志放在一个逻辑位置，数据文件放在另一个位置。物理上它是相同的阵列，但它是一个由 14 个总主轴（磁盘）组成的阵列，采用 raid 1+0 配置。

一个非常强大的 SAN - 事情运行得更好。队列长度减半。

就在今天，我们还获得了另一种选择。如果我们当前在文件服务器上需要它，我们也可以有一个 4 磁盘阵列。我知道通常建议在两个单独的阵列上使用 MDF 和 LDF，但在我们的情况下，这样做的唯一方法是将数据或事务日志从 SAN 移到配置为 Raid 5 的 4 磁盘阵列上。请记住，它们是当前位于单独的逻辑卷中，但共享相同的物理阵列。

从臀部射击我觉得将 MDF 和 LDF 放在一个 14 轴 raid 1+0 阵列上可能与将它们与一个在 4 轴 raid 5 阵列上分开一样好。但是，我不会在这里问我是否是磁盘逻辑专家。两个选项都使用基本相同的 15k SAS 磁盘 - 即每个主轴基本相同。

所以，本质上问题是。通过将数据或日志移动到它自己的 4 轴 raid 5 阵列，在配置为 raid 1+0 的单个 14 轴阵列上具有 MDF / LDF 是否会得到任何显着改善（或根本没有）？

想法？

更新信息：

我还要注意，当前日志卷上的平均队列长度始终保持在 0.55 左右。数据量上的平均队列长度很少超过 0.01（通常为 0.00）

sys.dm_io_virtual_file_stats 查询结果：

<table>
 <tr>
  <td>database
  id</td>
  <td>Volume</td>
  <td>io_stall_read_ms</td>
  <td>num_of_reads</td>
  <td>avg_read_stall_ms</td>
  <td>io_stall_write_ms</td>
  <td>num_of_writes</td>
  <td>avg_write_stall_ms</td>
  <td>io_stalls</td>
  <td>total_io</td>
  <td>avg_io_stall_ms</td>
 </tr>
 <tr>
  <td>25</td>
  <td>h</td>
  <td>175086</td>
  <td>1411</td>
  <td>124</td>
  <td>69</td>
  <td>41</td>
  <td>1.6</td>
  <td>175155</td>
  <td>1452</td>
  <td>120.5</td>
 </tr>
 <tr>
  <td>16</td>
  <td>h</td>
  <td>54691</td>
  <td>748</td>
  <td>73</td>
  <td>34</td>
  <td>23</td>
  <td>1.4</td>
  <td>54725</td>
  <td>771</td>
  <td>70.9</td>
 </tr>
 <tr>
  <td>41</td>
  <td>h</td>
  <td>192255</td>
  <td>982</td>
  <td>195.6</td>
  <td>5232</td>
  <td>2142</td>
  <td>2.4</td>
  <td>197487</td>
  <td>3124</td>
  <td>63.2</td>
 </tr>
 <tr>
  <td>24</td>
  <td>h</td>
  <td>8616</td>
  <td>178</td>
  <td>48.1</td>
  <td>55</td>
  <td>22</td>
  <td>2.4</td>
  <td>8671</td>
  <td>200</td>
  <td>43.1</td>
 </tr>
 <tr>
  <td>29</td>
  <td>h</td>
  <td>54617</td>
  <td>1247</td>
  <td>43.8</td>
  <td>71</td>
  <td>41</td>
  <td>1.7</td>
  <td>54688</td>
  <td>1288</td>
  <td>42.4</td>
 </tr>
 <tr>
  <td>40</td>
  <td>h</td>
  <td>132664</td>
  <td>3158</td>
  <td>42</td>
  <td>184</td>
  <td>85</td>
  <td>2.1</td>
  <td>132848</td>
  <td>3243</td>
  <td>41</td>
 </tr>
 <tr>
  <td>15</td>
  <td>h</td>
  <td>26556</td>
  <td>763</td>
  <td>34.8</td>
  <td>33</td>
  <td>23</td>
  <td>1.4</td>
  <td>26589</td>
  <td>786</td>
  <td>33.8</td>
 </tr>
 <tr>
  <td>37</td>
  <td>h</td>
  <td>6943152</td>
  <td>500214</td>
  <td>13.9</td>
  <td>310706380</td>
  <td>9083273</td>
  <td>34.2</td>
  <td>317649532</td>
  <td>9583487</td>
  <td>33.1</td>
 </tr>
 <tr>
  <td>32</td>
  <td>h</td>
  <td>14832</td>
  <td>426</td>
  <td>34.7</td>
  <td>42</td>
  <td>38</td>
  <td>1.1</td>
  <td>14874</td>
  <td>464</td>
  <td>32</td>
 </tr>
 <tr>
  <td>43</td>
  <td>h</td>
  <td>46937</td>
  <td>947</td>
  <td>49.5</td>
  <td>1203</td>
  <td>844</td>
  <td>1.4</td>
  <td>48140</td>
  <td>1791</td>
  <td>26.9</td>
 </tr>
 <tr>
  <td>17</td>
  <td>h</td>
  <td>23166</td>
  <td>786</td>
  <td>29.4</td>
  <td>260</td>
  <td>125</td>
  <td>2.1</td>
  <td>23426</td>
  <td>911</td>
  <td>25.7</td>
 </tr>
 <tr>
  <td>44</td>
  <td>h</td>
  <td>65563</td>
  <td>2968</td>
  <td>22.1</td>
  <td>451</td>
  <td>334</td>
  <td>1.3</td>
  <td>66014</td>
  <td>3302</td>
  <td>20</td>
 </tr>
 <tr>
  <td>27</td>
  <td>h</td>
  <td>73622</td>
  <td>3325</td>
  <td>22.1</td>
  <td>547</td>
  <td>483</td>
  <td>1.1</td>
  <td>74169</td>
  <td>3808</td>
  <td>19.5</td>
 </tr>
 <tr>
  <td>31</td>
  <td>h</td>
  <td>19557</td>
  <td>978</td>
  <td>20</td>
  <td>218</td>
  <td>128</td>
  <td>1.7</td>
  <td>19775</td>
  <td>1106</td>
  <td>17.9</td>
 </tr>
 <tr>
  <td>13</td>
  <td>h</td>
  <td>5238308</td>
  <td>176396</td>
  <td>29.7</td>
  <td>70537264</td>
  <td>4109175</td>
  <td>17.2</td>
  <td>75775572</td>
  <td>4285571</td>
  <td>17.7</td>
 </tr>
 <tr>
  <td>26</td>
  <td>h</td>
  <td>849303</td>
  <td>57475</td>
  <td>14.8</td>
  <td>496337</td>
  <td>19098</td>
  <td>26</td>
  <td>1345640</td>
  <td>76573</td>
  <td>17.6</td>
 </tr>
 <tr>
  <td>28</td>
  <td>h</td>
  <td>12707</td>
  <td>799</td>
  <td>15.9</td>
  <td>103</td>
  <td>62</td>
  <td>1.6</td>
  <td>12810</td>
  <td>861</td>
  <td>14.9</td>
 </tr>
 <tr>
  <td>42</td>
  <td>h</td>
  <td>28630</td>
  <td>1233</td>
  <td>23.2</td>
  <td>1139</td>
  <td>883</td>
  <td>1.3</td>
  <td>29769</td>
  <td>2116</td>
  <td>14.1</td>
 </tr>
 <tr>
  <td>14</td>
  <td>h</td>
  <td>91425</td>
  <td>5480</td>
  <td>16.7</td>
  <td>3762</td>
  <td>2470</td>
  <td>1.5</td>
  <td>95187</td>
  <td>7950</td>
  <td>12</td>
 </tr>
 <tr>
  <td>35</td>
  <td>h</td>
  <td>8253</td>
  <td>546</td>
  <td>15.1</td>
  <td>193</td>
  <td>174</td>
  <td>1.1</td>
  <td>8446</td>
  <td>720</td>
  <td>11.7</td>
 </tr>
 <tr>
  <td>12</td>
  <td>h</td>
  <td>33008</td>
  <td>1852</td>
  <td>17.8</td>
  <td>2179</td>
  <td>1335</td>
  <td>1.6</td>
  <td>35187</td>
  <td>3187</td>
  <td>11</td>
 </tr>
 <tr>
  <td>36</td>
  <td>h</td>
  <td>4322</td>
  <td>470</td>
  <td>9.2</td>
  <td>150</td>
  <td>119</td>
  <td>1.3</td>
  <td>4472</td>
  <td>589</td>
  <td>7.6</td>
 </tr>
 <tr>
  <td>6</td>
  <td>h</td>
  <td>537</td>
  <td>61</td>
  <td>8.7</td>
  <td>21</td>
  <td>22</td>
  <td>0.9</td>
  <td>558</td>
  <td>83</td>
  <td>6.6</td>
 </tr>
 <tr>
  <td>33</td>
  <td>h</td>
  <td>4172</td>
  <td>585</td>
  <td>7.1</td>
  <td>63</td>
  <td>59</td>
  <td>1.1</td>
  <td>4235</td>
  <td>644</td>
  <td>6.6</td>
 </tr>
 <tr>
  <td>30</td>
  <td>h</td>
  <td>633</td>
  <td>71</td>
  <td>8.8</td>
  <td>57</td>
  <td>38</td>
  <td>1.5</td>
  <td>690</td>
  <td>109</td>
  <td>6.3</td>
 </tr>
 <tr>
  <td>10</td>
  <td>h</td>
  <td>479</td>
  <td>65</td>
  <td>7.3</td>
  <td>63</td>
  <td>22</td>
  <td>2.7</td>
  <td>542</td>
  <td>87</td>
  <td>6.2</td>
 </tr>
 <tr>
  <td>38</td>
  <td>h</td>
  <td>635</td>
  <td>70</td>
  <td>8.9</td>
  <td>54</td>
  <td>40</td>
  <td>1.3</td>
  <td>689</td>
  <td>110</td>
  <td>6.2</td>
 </tr>
 <tr>
  <td>19</td>
  <td>h</td>
  <td>867</td>
  <td>125</td>
  <td>6.9</td>
  <td>133</td>
  <td>40</td>
  <td>3.2</td>
  <td>1000</td>
  <td>165</td>
  <td>6</td>
 </tr>
 <tr>
  <td>20</td>
  <td>h</td>
  <td>2157</td>
  <td>342</td>
  <td>6.3</td>
  <td>107</td>
  <td>37</td>
  <td>2.8</td>
  <td>2264</td>
  <td>379</td>
  <td>6</td>
 </tr>
 <tr>
  <td>18</td>
  <td>h</td>
  <td>655</td>
  <td>84</td>
  <td>7.7</td>
  <td>109</td>
  <td>44</td>
  <td>2.4</td>
  <td>764</td>
  <td>128</td>
  <td>5.9</td>
 </tr>
 <tr>
  <td>9</td>
  <td>h</td>
  <td>22017</td>
  <td>1269</td>
  <td>17.3</td>
  <td>12187</td>
  <td>4510</td>
  <td>2.7</td>
  <td>34204</td>
  <td>5779</td>
  <td>5.9</td>
 </tr>
 <tr>
  <td>11</td>
  <td>h</td>
  <td>1641</td>
  <td>226</td>
  <td>7.2</td>
  <td>158</td>
  <td>94</td>
  <td>1.7</td>
  <td>1799</td>
  <td>320</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>7</td>
  <td>h</td>
  <td>556</td>
  <td>66</td>
  <td>8.3</td>
  <td>40</td>
  <td>40</td>
  <td>1</td>
  <td>596</td>
  <td>106</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>20</td>
  <td>t</td>
  <td>639</td>
  <td>90</td>
  <td>7</td>
  <td>118</td>
  <td>43</td>
  <td>2.7</td>
  <td>757</td>
  <td>133</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>24</td>
  <td>t</td>
  <td>1031</td>
  <td>167</td>
  <td>6.1</td>
  <td>67</td>
  <td>29</td>
  <td>2.2</td>
  <td>1098</td>
  <td>196</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>25</td>
  <td>t</td>
  <td>1269</td>
  <td>210</td>
  <td>6</td>
  <td>111</td>
  <td>47</td>
  <td>2.3</td>
  <td>1380</td>
  <td>257</td>
  <td>5.3</td>
 </tr>
 <tr>
  <td>29</td>
  <td>t</td>
  <td>680</td>
  <td>94</td>
  <td>7.2</td>
  <td>113</td>
  <td>54</td>
  <td>2.1</td>
  <td>793</td>
  <td>148</td>
  <td>5.3</td>
 </tr>
 <tr>
  <td>30</td>
  <td>t</td>
  <td>233</td>
  <td>25</td>
  <td>9</td>
  <td>145</td>
  <td>47</td>
  <td>3</td>
  <td>378</td>
  <td>72</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>13</td>
  <td>t</td>
  <td>11947937</td>
  <td>55092</td>
  <td>216.9</td>
  <td>163346886</td>
  <td>33789532</td>
  <td>4.8</td>
  <td>175294823</td>
  <td>33844624</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>15</td>
  <td>t</td>
  <td>693</td>
  <td>119</td>
  <td>5.8</td>
  <td>82</td>
  <td>29</td>
  <td>2.7</td>
  <td>775</td>
  <td>148</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>16</td>
  <td>t</td>
  <td>731</td>
  <td>119</td>
  <td>6.1</td>
  <td>48</td>
  <td>29</td>
  <td>1.6</td>
  <td>779</td>
  <td>148</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>29</td>
  <td>h</td>
  <td>176</td>
  <td>34</td>
  <td>5</td>
  <td>1</td>
  <td>1</td>
  <td>0.5</td>
  <td>177</td>
  <td>35</td>
  <td>4.9</td>
 </tr>
 <tr>
  <td>18</td>
  <td>t</td>
  <td>305</td>
  <td>44</td>
  <td>6.8</td>
  <td>165</td>
  <td>52</td>
  <td>3.1</td>
  <td>470</td>
  <td>96</td>
  <td>4.8</td>
 </tr>
 <tr>
  <td>5</td>
  <td>h</td>
  <td>500</td>
  <td>75</td>
  <td>6.6</td>
  <td>60</td>
  <td>40</td>
  <td>1.5</td>
  <td>560</td>
  <td>115</td>
  <td>4.8</td>
 </tr>
 <tr>
  <td>8</td>
  <td>t</td>
  <td>462</td>
  <td>74</td>
  <td>6.2</td>
  <td>118</td>
  <td>48</td>
  <td>2.4</td>
  <td>580</td>
  <td>122</td>
  <td>4.7</td>
 </tr>
 <tr>
  <td>5</td>
  <td>t</td>
  <td>294</td>
  <td>33</td>
  <td>8.6</td>
  <td>80</td>
  <td>47</td>
  <td>1.7</td>
  <td>374</td>
  <td>80</td>
  <td>4.6</td>
 </tr>
 <tr>
  <td>3</td>
  <td>h</td>
  <td>520</td>
  <td>109</td>
  <td>4.7</td>
  <td>3</td>
  <td>4</td>
  <td>0.6</td>
  <td>523</td>
  <td>113</td>
  <td>4.6</td>
 </tr>
 <tr>
  <td>39</td>
  <td>h</td>
  <td>394</td>
  <td>62</td>
  <td>6.3</td>
  <td>77</td>
  <td>40</td>
  <td>1.9</td>
  <td>471</td>
  <td>102</td>
  <td>4.6</td>
 </tr>
 <tr>
  <td>39</td>
  <td>t</td>
  <td>124</td>
  <td>16</td>
  <td>7.3</td>
  <td>165</td>
  <td>47</td>
  <td>3.4</td>
  <td>289</td>
  <td>63</td>
  <td>4.5</td>
 </tr>
 <tr>
  <td>8</td>
  <td>h</td>
  <td>459</td>
  <td>78</td>
  <td>5.8</td>
  <td>93</td>
  <td>43</td>
  <td>2.1</td>
  <td>552</td>
  <td>121</td>
  <td>4.5</td>
 </tr>
 <tr>
  <td>41</td>
  <td>t</td>
  <td>8295</td>
  <td>470</td>
  <td>17.6</td>
  <td>4035</td>
  <td>2359</td>
  <td>1.7</td>
  <td>12330</td>
  <td>2829</td>
  <td>4.4</td>
 </tr>
 <tr>
  <td>31</td>
  <td>t</td>
  <td>637</td>
  <td>91</td>
  <td>6.9</td>
  <td>170</td>
  <td>95</td>
  <td>1.8</td>
  <td>807</td>
  <td>186</td>
  <td>4.3</td>
 </tr>
 <tr>
  <td>7</td>
  <td>t</td>
  <td>242</td>
  <td>29</td>
  <td>8.1</td>
  <td>80</td>
  <td>47</td>
  <td>1.7</td>
  <td>322</td>
  <td>76</td>
  <td>4.2</td>
 </tr>
 <tr>
  <td>22</td>
  <td>h</td>
  <td>298</td>
  <td>80</td>
  <td>3.7</td>
  <td>0</td>
  <td>1</td>
  <td>0</td>
  <td>298</td>
  <td>81</td>
  <td>3.6</td>
 </tr>
 <tr>
  <td>38</td>
  <td>t</td>
  <td>139</td>
  <td>22</td>
  <td>6</td>
  <td>115</td>
  <td>47</td>
  <td>2.4</td>
  <td>254</td>
  <td>69</td>
  <td>3.6</td>
 </tr>
 <tr>
  <td>40</td>
  <td>t</td>
  <td>1016</td>
  <td>159</td>
  <td>6.4</td>
  <td>388</td>
  <td>236</td>
  <td>1.6</td>
  <td>1404</td>
  <td>395</td>
  <td>3.5</td>
 </tr>
 <tr>
  <td>22</td>
  <td>t</td>
  <td>76</td>
  <td>18</td>
  <td>4</td>
  <td>7</td>
  <td>5</td>
  <td>1.2</td>
  <td>83</td>
  <td>23</td>
  <td>3.5</td>
 </tr>
 <tr>
  <td>44</td>
  <td>t</td>
  <td>873</td>
  <td>133</td>
  <td>6.5</td>
  <td>479</td>
  <td>263</td>
  <td>1.8</td>
  <td>1352</td>
  <td>396</td>
  <td>3.4</td>
 </tr>
 <tr>
  <td>4</td>
  <td>h</td>
  <td>10565</td>
  <td>2057</td>
  <td>5.1</td>
  <td>2840</td>
  <td>2061</td>
  <td>1.4</td>
  <td>13405</td>
  <td>4118</td>
  <td>3.3</td>
 </tr>
 <tr>
  <td>32</td>
  <td>t</td>
  <td>94</td>
  <td>18</td>
  <td>4.9</td>
  <td>72</td>
  <td>33</td>
  <td>2.1</td>
  <td>166</td>
  <td>51</td>
  <td>3.2</td>
 </tr>
 <tr>
  <td>19</td>
  <td>t</td>
  <td>116</td>
  <td>16</td>
  <td>6.8</td>
  <td>116</td>
  <td>60</td>
  <td>1.9</td>
  <td>232</td>
  <td>76</td>
  <td>3</td>
 </tr>
 <tr>
  <td>11</td>
  <td>t</td>
  <td>144</td>
  <td>18</td>
  <td>7.6</td>
  <td>181</td>
  <td>91</td>
  <td>2</td>
  <td>325</td>
  <td>109</td>
  <td>3</td>
 </tr>
 <tr>
  <td>10</td>
  <td>t</td>
  <td>69</td>
  <td>12</td>
  <td>5.3</td>
  <td>48</td>
  <td>29</td>
  <td>1.6</td>
  <td>117</td>
  <td>41</td>
  <td>2.8</td>
 </tr>
 <tr>
  <td>6</td>
  <td>t</td>
  <td>69</td>
  <td>11</td>
  <td>5.8</td>
  <td>40</td>
  <td>29</td>
  <td>1.3</td>
  <td>109</td>
  <td>40</td>
  <td>2.7</td>
 </tr>
 <tr>
  <td>1</td>
  <td>h</td>
  <td>941</td>
  <td>181</td>
  <td>5.2</td>
  <td>368</td>
  <td>356</td>
  <td>1</td>
  <td>1309</td>
  <td>537</td>
  <td>2.4</td>
 </tr>
 <tr>
  <td>9</td>
  <td>t</td>
  <td>5034</td>
  <td>394</td>
  <td>12.7</td>
  <td>9584</td>
  <td>5599</td>
  <td>1.7</td>
  <td>14618</td>
  <td>5993</td>
  <td>2.4</td>
 </tr>
 <tr>
  <td>17</td>
  <td>t</td>
  <td>1335</td>
  <td>213</td>
  <td>6.2</td>
  <td>1293</td>
  <td>1119</td>
  <td>1.2</td>
  <td>2628</td>
  <td>1332</td>
  <td>2</td>
 </tr>
 <tr>
  <td>3</td>
  <td>h</td>
  <td>21</td>
  <td>6</td>
  <td>3</td>
  <td>15</td>
  <td>13</td>
  <td>1.1</td>
  <td>36</td>
  <td>19</td>
  <td>1.8</td>
 </tr>
 <tr>
  <td>34</td>
  <td>h</td>
  <td>1140</td>
  <td>132</td>
  <td>8.6</td>
  <td>4146</td>
  <td>2921</td>
  <td>1.4</td>
  <td>5286</td>
  <td>3053</td>
  <td>1.7</td>
 </tr>
 <tr>
  <td>14</td>
  <td>t</td>
  <td>714</td>
  <td>111</td>
  <td>6.4</td>
  <td>10175</td>
  <td>6589</td>
  <td>1.5</td>
  <td>10889</td>
  <td>6700</td>
  <td>1.6</td>
 </tr>
 <tr>
  <td>42</td>
  <td>t</td>
  <td>949</td>
  <td>139</td>
  <td>6.8</td>
  <td>3420</td>
  <td>2671</td>
  <td>1.3</td>
  <td>4369</td>
  <td>2810</td>
  <td>1.6</td>
 </tr>
 <tr>
  <td>37</td>
  <td>t</td>
  <td>4006</td>
  <td>489</td>
  <td>8.2</td>
  <td>15548682</td>
  <td>9892846</td>
  <td>1.6</td>
  <td>15552688</td>
  <td>9893335</td>
  <td>1.6</td>
 </tr>
 <tr>
  <td>2</td>
  <td>f</td>
  <td>164348</td>
  <td>106669</td>
  <td>1.5</td>
  <td>178498</td>
  <td>121970</td>
  <td>1.5</td>
  <td>342846</td>
  <td>228639</td>
  <td>1.5</td>
 </tr>
 <tr>
  <td>28</td>
  <td>t</td>
  <td>1305</td>
  <td>194</td>
  <td>6.7</td>
  <td>7006</td>
  <td>5797</td>
  <td>1.2</td>
  <td>8311</td>
  <td>5991</td>
  <td>1.4</td>
 </tr>
 <tr>
  <td>45</td>
  <td>h</td>
  <td>123</td>
  <td>93</td>
  <td>1.3</td>
  <td>510</td>
  <td>373</td>
  <td>1.4</td>
  <td>633</td>
  <td>466</td>
  <td>1.4</td>
 </tr>
 <tr>
  <td>43</td>
  <td>t</td>
  <td>1243</td>
  <td>130</td>
  <td>9.5</td>
  <td>13330</td>
  <td>10836</td>
  <td>1.2</td>
  <td>14573</td>
  <td>10966</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>35</td>
  <td>t</td>
  <td>329</td>
  <td>47</td>
  <td>6.9</td>
  <td>25471</td>
  <td>19582</td>
  <td>1.3</td>
  <td>25800</td>
  <td>19629</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>27</td>
  <td>t</td>
  <td>1866</td>
  <td>294</td>
  <td>6.3</td>
  <td>12196</td>
  <td>10243</td>
  <td>1.2</td>
  <td>14062</td>
  <td>10537</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>12</td>
  <td>t</td>
  <td>13789</td>
  <td>2852</td>
  <td>4.8</td>
  <td>28818</td>
  <td>29040</td>
  <td>1</td>
  <td>42607</td>
  <td>31892</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>4</td>
  <td>t</td>
  <td>511</td>
  <td>67</td>
  <td>7.5</td>
  <td>158330</td>
  <td>130742</td>
  <td>1.2</td>
  <td>158841</td>
  <td>130809</td>
  <td>1.2</td>
 </tr>
 <tr>
  <td>34</td>
  <td>t</td>
  <td>99</td>
  <td>13</td>
  <td>7.1</td>
  <td>134764</td>
  <td>112984</td>
  <td>1.2</td>
  <td>134863</td>
  <td>112997</td>
  <td>1.2</td>
 </tr>
 <tr>
  <td>2</td>
  <td>f</td>
  <td>23</td>
  <td>147</td>
  <td>0.2</td>
  <td>17980</td>
  <td>16879</td>
  <td>1.1</td>
  <td>18003</td>
  <td>17026</td>
  <td>1.1</td>
 </tr>
 <tr>
  <td>1</td>
  <td>h</td>
  <td>54</td>
  <td>10</td>
  <td>4.9</td>
  <td>1845</td>
  <td>1761</td>
  <td>1</td>
  <td>1899</td>
  <td>1771</td>
  <td>1.1</td>
 </tr>
 <tr>
  <td>33</td>
  <td>t</td>
  <td>220</td>
  <td>33</td>
  <td>6.5</td>
  <td>746</td>
  <td>980</td>
  <td>0.8</td>
  <td>966</td>
  <td>1013</td>
  <td>1</td>
 </tr>
 <tr>
  <td>36</td>
  <td>t</td>
  <td>199</td>
  <td>27</td>
  <td>7.1</td>
  <td>26330</td>
  <td>25429</td>
  <td>1</td>
  <td>26529</td>
  <td>25456</td>
  <td>1</td>
 </tr>
 <tr>
  <td>45</td>
  <td>t</td>
  <td>5</td>
  <td>8</td>
  <td>0.6</td>
  <td>6306</td>
  <td>6142</td>
  <td>1</td>
  <td>6311</td>
  <td>6150</td>
  <td>1</td>
 </tr>
 <tr>
  <td>26</td>
  <td>t</td>
  <td>2969</td>
  <td>348</td>
  <td>8.5</td>
  <td>64557</td>
  <td>70819</td>
  <td>0.9</td>
  <td>67526</td>
  <td>71167</td>
  <td>0.9</td>
 </tr>
</table>

我们有一个客户端，我们将允许它使用我们的一个应用程序。现场工作人员定期通过 VPN 连接到我们的网络。连接到 SQL Server 的 .Net 应用程序使用集成安全性。他们使用的笔记本电脑是我们域的成员。

客户也请求使用该应用程序。因此，我们为他们提供了一个网络帐户以及在我们的网络上创建 VPN 会话的能力。我在 SQL 服务器上为该帐户提供了与我们自己的员工相同的权限的登录名。

问题是，当他们尝试使用该应用程序时，会收到以下错误： 登录来自不受信任的域，不能用于 Windows 身份验证。

我猜，因为他们使用的计算机不在我们的域中，所以他们使用 VPN 登录并不重要。那么，解决这个问题的最佳方法是什么？我宁愿不为这个小型应用程序切换到 SQL 身份验证。