6

我被告知 SQL Native Client应该比 OLEDB 驱动程序更快。所以我把一个实用程序放在一起，在两者之间进行负载测试——结果好坏参半。有时一种更快，有时另一种更快，无论查询是什么（简单的选择、where 子句、连接、排序依据等）。当然，服务器承担了大部分工作负载，但我感兴趣的是从数据进入 PC 到数据在应用程序中可访问的时间之间的时间。

负载测试由非常小的查询组成，这些查询返回非常大的数据集。例如，我这样做select * from SysTables了，这个表有 50,000 多条记录。收到数据后，我又对结果进行了循环加载（使用 while notQ.eof ... Q.next ...等）。我还尝试向查询中添加一些内容——例如字段order by Val在哪里。Valvarchar(100)

这是我的负载测试器的示例，最底部的数字是平均值...

在此处输入图像描述

那么实际上，两者之间有什么区别？我知道 OLE 非常灵活并且支持许多不同的数据库引擎，而 Native Client 只针对 SQL Server。但是幕后还有什么？这对 Delphi 使用这些驱动程序的方式有何影响？

这也是专门通过TADOConnection组件使用 ADO 的TADOQuery。

我不一定要寻找或寻求提高性能的方法——我只需要知道驱动程序之间的区别是什么。

4

8 回答 8

7

正如微软所说：

SQL Server Native Client 是一个独立的数据访问应用程序编程接口 (API)，用于 OLE DB 和 ODBC，它是在 SQL Server 2005 中引入的。SQL Server Native Client 将 SQL OLE DB 提供程序和 SQL ODBC 驱动程序结合到一个本机动态链接库 (DLL)。

据我了解，ADO 只是 OleDB 之上的面向对象的应用程序级数据库层。它将在所有情况下使用 OleDB。使用的提供程序发生了什么变化。如果您指定SQLNCLI10提供程序，您将使用最新版本的协议。如果您指定SQLOLEDB提供程序，您将使用通用 SQL Server 2000 + 协议。

像这样：

  ADO -> OleDB -> SQLNCLI10 provider -> MS SQL Server (MSSQL 2000, 2005 or 2008 protocol)
  ADO -> OleDB -> SQLOLEDB provider -> MS SQL Server (MSSQL 2000 protocol)

关于性能，我认为您不会有太大的不同。像往常一样，它将取决于处理的数据。

但恕我直言，建议为您的数据库使用最合适的提供程序。某些类型的数据（如var(maxchar)或Int64）被告知最好处理。并且SQLNCLI10提供者已经更新，所以我想它更加调整了。

于 2012-01-31T17:31:30.837 回答
5

我认为您应该专注于优化：

  • sql server 引擎和数据库设置
  • 您的查询
  • 您的数据架构

连接库之间的速度差异是如此之小，甚至可以忽略不计，以至于它可能会导致系统非常微小的减速，并且在非常特定的情况下

于 2012-01-31T16:18:57.467 回答
5

  1. 在您的问题中，您正在混合 OLE 和 SQL Native Client。可能你在同一时间意味着几件事：

    • OLE -> OLEDB，这是过时的通用数据访问技术；
    • OLE -> "SQL Server OLEDB Provider"，即 SQL Server 2000 OLEDB 提供程序；
    • SQL Server Native Client，即 SQL Server 2005 及更高版本的客户端软件。它包括作为 OLEDB 提供程序，作为 ODBC 驱动程序。

  2. 如果要谈论 OLEDB 提供程序和支持的 SQL Server 版本，那么：

    • “SQL Server OLEDB Provider”（SQLOLEDB）支持SQL Server 2000协议；
    • “SQL Server Native Client 9”（SQLNCLI）支持SQL Server 2000和2005协议；
    • “SQL Server Native Client 10”支持 SQL Server 2000、2005 和 2008 协议。

    你没有说你使用的是什么 SQL Server 版本。一般来说，最好是使用与您的 SQL Server 版本相对应的 SQL Server OLEDB 提供程序。否则，您可能会遇到服务器和客户端版本之间的不兼容问题。

  3. 抽象比较，我只能推测SQLNCLI和SQLOLEDB之间的区别：

    • 一是更正确地使用服务器协议；
    • 一是使用更高级的协议特性；
    • 一个执行更多的处理，处理更多的情况；
    • 一种使用更通用/优化的数据表示。

    如果没有正确的基准应用程序和环境，很难接受您的比较结果，因为它们可能取决于多种因素。

于 2012-01-31T17:20:13.913 回答
4

简短的回答：
没关系。

长答案：
与服务器执行 + 网络数据传输相比，2 个客户端库之间的性能差异相对可以忽略不计，这是您主要测量的，因此测试数据不确定。无论如何，您很有可能在两种情况下都使用相同的低级层，而在它之上的间接性只有很小的差异。

事实上，如果你的测试没有显示出明显的差异，它只是证明缓慢与客户端库的选择无关，应该在其他地方搜索优化。

对于您目前的测试，您应该在运行测试的同时使用 SQL Profiler 测量服务器上的查询执行时间，您会发现它们也有很大的不同。从测试最终结果中减去这些数字将为您提供捆绑客户端时间 + 网络传输的时间。

网络性能变化很大，对您的测试的影响比您想象的要大。尝试在运行测试的同时让某人流式传输视频，你会看到......（在我以前的公司有过这种情况；在这种情况下调整 SQL 不是答案）

于 2012-01-31T19:36:46.703 回答
3

虽然它当然可以在数据库端，但我认为在整个系统中还有很多东西需要查看——至少是您的测试系统。一般来说，如果您要求数据库执行的工作与整体工作相比非常小，则很难进行计时。所以总的来说，数据库任务是一项大工作还是仅仅是检索一个数据项？您使用的是存储过程还是简单查询？您的测试是否在运行测试之前准备了任何存储过程？每次连续运行任何测试时，您是否获得一致的时间？

于 2012-01-31T16:56:16.947 回答
1
  • 查询执行时间告诉您数据库引擎（以及任何模式/查询优化）运行良好。在这里，您使用什么并不重要。ODBC/OLEDB/Native 只是将查询传递到数据库并在那里执行
  • 从第一条记录读取到最后一条记录所花费的时间告诉您数据访问层和您的网络性能如何。在这里，您可以计算数据在客户端上的返回和“缓存”情况。根据数据，网络设置可能很重要。例如，如果您的表使用“大”记录，则更大的 MTU 可能需要更少的数据包（和更少的往返）来将它们发送到客户端。

无论如何，在寻找解决方案之前，您必须确定问题所在。分析您的应用程序，包括客户端和服务器端（SQL Server 有很好的工具），并找出究竟是什么让它变慢了。只有这样，您才能寻找正确的解决方案。也许数据访问层不是问题。今天，20,000 条记录只是一个小数据集，而不是一个大数据集。

于 2012-01-31T19:19:45.507 回答
1

您不能将本机客户端与 ADO 一起使用，就像.

ADO 不理解XMLSQL Server 数据类型。字段类型：

field: ADOField;

field := recordset.Fields.Items["SomeXmlColumn"];

尝试访问field.Value会引发EOleException：

  • 来源：微软光标引擎
  • 错误代码： 0x80040E21 (E_ITF_0E21)
  • 消息：多步操作生成错误。检查每个状态值

本机客户端驱动程序（例如SQLNCLI, SQLNCLI10）向 ADOSQLNCLI11呈现Xml数据类型为

field.Type_ = 141

虽然旧版SQLOLEDB驱动程序向XmlADO 提供一种数据类型为adLongVarWChar，但它是一个 unicode 字符串：

field.Type_ = 203 //adLongVarWChar

其中VARIANT包含的field.Value是 a WideString（技术上称为 a BSTR）：

TVarData(field.Value).vtype = 8 //VT_BSTR

微软指出的解决方案：

将 ADO 与 SQL Server Native Client 一起使用

现有的 ADO 应用程序可以使用 SQLOLEDB 提供程序访问和更新 XML、UDT 以及大值文本和二进制字段值。新的更大的varchar(max)、nvarchar(max)和varbinary(max)数据类型分别作为 ADO 类型adLongVarChar、adLongVarWChar和adLongVarBinary返回。XML 列作为adLongVarChar返回，UDT 列作为adVarBinary返回。但是，如果您使用 SQL Server Native Client OLE DB 提供程序 (SQLNCLI11) 而不是 SQLOLEDB，则需要确保设置DataTypeCompatibility关键字设置为“80”，以便新数据类型正确映射到 ADO 数据类型。

他们还指出：

如果您不需要使用 SQL Server 2005 中引入的任何新功能，则无需使用 SQL Server Native Client OLE DB 提供程序；您可以继续使用当前的数据访问提供程序，通常是 SQLOLEDB。

于 2013-10-02T13:55:28.737 回答
1

此外，除了缺乏对 XML 数据类型的支持之外，Delphi ADO 无法识别 SQL Server 中定义的列，TIME (DBTYPE_DBTIME2=145)或者DATETIMEOFFSET (DBTYPE_DBTIMESTAMPOFFSET=146);尝试在应用程序中使用这些字段会导致多个错误，如“无效变量值”或某些控件（如 TDBGrid）将完全放弃该领域。

似乎缺乏支持DBTYPE_DBTIME2=145是一个错误/QC问题，因为已经有ftTime支持（我也不清楚为什么SQL Server不返回DBTYPE_DBTIMEDelphi支持的），XML和Offset类型没有明确的TFieldType映射.

对 OLE DB 日期/时间改进的数据类型支持

于 2016-03-30T17:38:55.183 回答