Delphi с SQL Server: oledb и драйверы собственных клиентов

мне сказали, что собственный клиент SQL-это должно чтобы быть быстрее, чем драйверы OLEDB. Поэтому я собрал утилиту для выполнения нагрузочного теста между ними - и получаю смешанные результаты. Иногда один быстрее, иногда другой, независимо от того, какой запрос может быть (простой выбор, предложение where, присоединение, порядок и т. д.). Конечно, сервер выполняет большую часть рабочей нагрузки, но меня интересует время, которое требуется между данными, поступающими на ПК, и временем данные доступны в приложении.

нагрузочные тесты состоят из очень маленьких запросов, которые возвращают очень большие наборы данных. Например, я делаю select * from SysTables и эта таблица имеет 50,000 + записей. После получения данных я делаю еще одну загрузку цикла через результаты (используя while not Q.eof ... Q.next ... etc.). Я также попытался добавить некоторые вещи в запрос-например,order by Val здесь Val - это

6
ado delphi oledb sql-server sqlncli

8 ответов

As заявлено Microsoft:

собственный клиент SQL Server-это автономный интерфейс прикладного программирования (API) доступа к данным, используемый как для OLE DB, так и для ODBC, который был представлен в SQL Server 2005. Собственный клиент SQL Server объединяет поставщик OLE DB SQL и драйвер ODBC SQL в одну собственную библиотеку динамической компоновки (DLL).

из моего понимания, ADO - это просто объектно-ориентированный уровень БД уровня приложения над OleDB. Оно будет используйте OleDB во всех случаях. Какие изменения использует поставщик. Если вы укажете SQLNCLI10 provider, вы будете использовать последнюю версию протокола. Если вы укажете 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 поставщик был обновлен, поэтому я думаю, что он более настроен.

7

  1. в вашем вопросе вы mxing OLE и SQL собственный клиент. наверное вы имеете в виду несколько вещей, в то же время:

    • OLE - > OLEDB, устаревшая технология общего доступа к данным;
    • OLE - > "поставщик OLEDB SQL Server", который является поставщиком OLEDB SQL Server 2000;
    • собственный клиент SQL Server, который является SQL Server 2005 и выше клиентского программного обеспечения. И он включает в себя как поставщик OLEDB, как ODBC водитель.

  2. Если говорить о поставщиках OLEDB и поддерживаемых версиях SQL Server, то:

    • "поставщик OLEDB SQL Server" (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 вы с помощью. В общем случае лучше всего использовать поставщик OLEDB SQL Server, соответствующий вашей версии SQL Server. В противном случае может возникнуть несовместимость между версиями сервера и клиента.

  3. абстрактно сравнивая, я могу только предполагать о различиях между SQLNCLI и SQLOLEDB:

    • один более правильно использует серверный протокол;
    • один использует более продвинутые функции протокола;
    • один выполняет больше обработки, чем для ГЭС обрабатывать больше ситуаций;
    • используется более общее / оптимизированное представление данных.

    без правильного эталоном и окружающей среды, трудно принять результаты сравнения, потому что они могут зависеть от нескольких факторов.

5

Я думаю, вы должны сосредоточиться на оптимизации:

  • SQL server engine и настройки базы данных
  • запросы
  • схема данных

разница в скорости между библиотеками соединений настолько мала, даже незначительна, что это может вызвать очень небольшое замедление систем и в очень конкретных сценариях

5

короткий ответ:
Это не имеет значения.

ответ:
Разница в производительности между 2 клиентскими библиотеками относительно незначительна по сравнению с выполнением сервера + передачей сетевых данных, что вы в основном измеряете, следовательно, неубедительные тестовые данные. Есть хороший шанс, что вы используете один и тот же низкоуровневый слой в обоих случаях с незначительной разницей в косвенности поверх него.

Как a на самом деле, если ваши тесты не показывают видимой разницы, это просто доказывает, что медлительность не связана с выбором lib клиента и оптимизацию следует искать в другом месте.

для вашего настоящего теста вы должны использовать SQL Profiler для измерения времени выполнения запросов на сервере в то же время, когда вы запускаете свой тест, вы увидите, что они также сильно различаются. Вычитание этих чисел из конечных результатов теста даст вам время для времени клиента пакета + Передача по сети.

производительность сети довольно изменчива и оказывает большее влияние на ваш тест, чем вы думаете. Попробуйте иметь кого-то потокового видео в то же время вы запустите тест, и вы увидите... (У меня было это с моей бывшей компанией; настройка SQL не была ответом в этом случае)

4

хотя это, безусловно, может быть в конце базы данных, я думаю, что есть много, чтобы посмотреть в общей системе - по крайней мере, ваша тестовая система. В общем, трудно сделать время, если работа, которую вы просите сделать базу данных, очень мала по сравнению с общей работой. Итак, в общем, задача базы данных-большая работа или просто поиск одного элемента данных? Вы используете хранимые процедуры или простые запросы? Ваш тест готовит какие-либо хранимые процедуры перед запуском теста? Ты понимаешь? последовательное время каждый раз, когда вы запускаете какой-либо тест в sucession?

3
  • время выполнения запроса показывает, насколько хорошо работает компонент database engine (и любая оптимизация схемы/запроса). Вот то, что вы используете не имеет значения. ODBC/OLEDB / Native все, что просто передает запрос в базу данных, и он выполняется там
  • время, необходимое для чтения от первой записи до последней, говорит вам, насколько хорошо уровень доступа к данным и сети perfom. Здесь вы определяете, насколько хорошо данные возвращаются и" кэшируются " на вашем клиенте. Зависящий на данных могут быть важны параметры сети. Например, если в ваших таблицах используются" большие " записи, для отправки большего MTU может потребоваться меньше пакетов (и меньше циклов).

в любом случае,до ищем решение вы должны определить проблему. Профилируйте свое приложение, как на стороне клиента, так и на стороне сервера (SQL Server имеет хорошие инструменты для этого), и найдите, что именно делает его медленнее. Тогда и только тогда вы сможете искать правильное решение. Возможно, проблема не в уровне доступа к данным. Сегодня 20 000 записей-это небольшой набор данных, а не большой.

1

вы не можете использовать уроженца клиенты с ADO, как.

ADO не понимает XML тип данных SQL Server. Тип поля:

field: ADOField;

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

попытка доступа field.Value выдает EOleException:

  • источник: Microsoft Cursor Engine
  • код ошибки: 0x80040E21 (E_ITF_0E21)
  • сообщение: во время выполнения многошаговой операции генерируемые ошибки. Проверьте каждое значение состояния

на уроженца драйверы клиента (например,SQLNCLI, SQLNCLI10, SQLNCLI11) представлен Xml тип данных для ADO as 

field.Type_ = 141

в то время как наследие SQLOLEDB драйвер представляет собой Xml тип данных для ADO as adLongVarWChar, Юникод строку:

field.Type_ = 203 //adLongVarWChar

и VARIANT содержится в field.Value это WideString (технически известный как BSTR):

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

решение, как отметил Microsoft:

использование ADO с собственным клиентом SQL Server

существующие приложения ADO могут получать доступ и обновлять значения XML, UDT и больших значений текста и двоичных полей с помощью поставщика SQLOLEDB. Новый большой varchar (max), nvarchar (max) и varbinary (max) типы данных возвращаются как типы ADO adLongVarChar, adLongVarWChar и adLongVarBinary соответственно. XML-столбцы возвращаются как adLongVarChar, и столбцы UDT возвращаются как adVarBinary. Однако если вместо sqloledb используется поставщик OLE DB для собственного клиента SQL Server (SQLNCLI11), необходимо обязательно установить DataTypeCompatibility ключевое слово "80", чтобы новые типы данных правильно отображались в данные ADO типы.

они также отмечают:

если нет необходимости использовать какие-либо новые функции, введенные в SQL Server 2005, нет необходимости использовать поставщик OLE DB для собственного клиента SQL Server; можно продолжить использование текущего поставщика доступа к данным, который обычно является sqloledb.

1

кроме того, помимо отсутствия поддержки типа данных XML, Delphi ADO не распознает столбцы, определенные в SQL Server как TIME (DBTYPE_DBTIME2=145) или DATETIMEOFFSET (DBTYPE_DBTIMESTAMPOFFSET=146); попытка использовать эти поля в вашем приложении приведет к нескольким ошибкам, таким как "недопустимое значение варианта", или некоторые элементы управления (например, TDBGrid) просто полностью удалят поле.

похоже на отсутствие поддержки DBTYPE_DBTIME2=145 это ошибка / QC-проблема, так как уже есть поддержка ftTime (мне также не ясно, почему SQL Server не возвращается DBTYPE_DBTIME который Delphi поддерживает), типы XML и Offset не имеют четкого отображения TFieldType.

поддержка типов данных для улучшения даты/времени OLE DB

0