Соединение JDBC с очень занятым SQL 2000: selectMethod=cursor vs selectMethod=direct?

в процессе попытки помочь команде разработчиков приложений с проблемами производительности на сервере SQL 2000 (из группы приложений Java на отдельных серверах приложений) я запустил трассировку SQL и обнаружил, что все вызовы базы данных полны операторов Курсора сервера API (sp_cursorprepexec, sp_cursorfetch, sp_cursorclose).

похоже, они задают некоторые свойства строки подключения, которые заставляют использовать серверные курсоры, получая только 128 строк данных за раз: (От http://msdn.microsoft.com/en-us/library/Aa172588)

когда атрибуты курсора API или свойства значение чем их значения по умолчанию, OLE DB поставщик для SQL Server и SQL Сервер ODBC драйвер использовать API сервер курсоры вместо результата по умолчанию наборы. Каждый вызов функции API выборки строк создает обращение к серверу для получения строки с сервера API указатель.

обновление: строка подключения, о которой идет речь, является параметром строки подключения JDBC,selectMethod=cursor (который включает серверные курсоры, которые мы обсуждали выше) против альтернативной selectMethod=direct. Они использовали selectMethod=cursor как их стандартная строка подключения из всех приложений.

С моей точки зрения DBA, это просто раздражает (он загромождает трассировку бесполезным мусором), и (я бы предположил) приводит ко многим дополнительным раундам приложения к SQL server поездки, снижение общей производительности.

они, по-видимому, тестировали изменение (только одно из 60 различных подключений приложений) на selectMethod=direct но испытал некоторые проблемы (из которых у меня нет подробностей) и обеспокоен нарушением приложения.

Итак, мои вопросы:

  • можно использовать selectMethod=cursor снижение производительности приложения, как я пытался спорить? (за счет увеличения количества рейсов, необходимых на SQL Server, который уже имеет очень высокий запросы / сек)
  • Is selectMethod= прозрачная настройка приложения для соединения JDBC? Может ли это сломать их приложение, если мы его изменим?
  • в более общем плане, когда вы должны использовать cursor vs direct?

и cross-posted to SF.

редактировать: получены фактические технические данные, которые гарантируют значительное редактирование заголовка, вопроса и тегов.

редактировать: добавлено баунти. Также добавить щедрость к вопросу SF (этот вопрос сосредоточен на поведении приложения, вопрос SF сосредоточен на производительности SQL.) Спасибо!!

11
cursor jdbc selectmethod sql-server-2000

2 ответов

коротко

  1. selectMethod=cursor
    • теоретически требует дополнительные ресурсы на стороне сервера чем selectMethod=direct
    • загружается только самое большее пакета в размере записывает в память клиента сразу, приводящ к в более предсказуемом следе ноги памяти клиента
  2. selectMethod=direct
    • теоретически требуется меньше ресурсов на стороне сервера, чем selectMethod=cursor
    • читать весь результат установите в память клиента (если драйвер изначально не поддерживает асинхронное извлечение результирующего набора), прежде чем клиентское приложение сможет перебирать его; это может снизить производительность двумя способами:
      1. снижение производительности с большими результирующими наборами, если клиентское приложение написано таким образом, чтобы остановить обработку после прохождения только части результирующего набора (с direct он уже оплатил стоимость извлечения данных, которые он по существу выбросит; с cursor отходы ограничены максимум пакета в размере - 1 строк. первые условия расторжения должны, вероятно, быть перекодированы в SQL в любом случае, например,SELECT TOP или оконные функции)
      2. снижение производительности с большими результирующими наборами из-за потенциальной сборки мусора и/или проблем с памятью, связанных с увеличением объема памяти

в целом,

  • можете с помощью selectMethod=cursor снижение производительности приложения? -- любой метод может снизить производительность по разным причинам. Мимо определенного размера resultset,cursor еще может быть предпочтительнее. См. ниже, когда использовать тот или иной
  • и selectMethod= прозрачная настройка приложения для соединения JDBC? -- он прозрачен, но он все равно может сломать их приложение, если использование памяти растет достаточно значительно, чтобы зацепить их клиентскую систему (и, соответственно, ваш сервер) или сбой клиент вообще
  • в более общем плане, когда вы должны использовать cursor vs direct? -- лично я использую cursor при работе с потенциально большими или иными неограниченными результирующими наборами. Накладные расходы туда и обратно амортизируются при достаточно большом размере пакета, и объем памяти моего клиента предсказуем. Я использую direct когда размер результирующего набора, который я ожидаю, как известно, уступает размеру любой партии, которую я использую с cursor, или связанный каким-то образом, или когда память-это не проблема.
11

используя selectMethod=cursor запрещает SQL Server использовать Параллельная Обработка Запросов, который может иметь большое влияние на производительность, например, когда:

  • у вас много ядер процессора (а у кого нет?)
  • вы оптимизировали свою базу данных, разделив таблицы
  • вы выполняете множество агрегированных запросов (sum(), count(), etc.)

И, Наконец, Microsoft государства следующее:

(selectMethod=direct) обеспечивает наивысшую производительность, когда приложение обрабатывает все строки.

вы должны обязательно попробовать и посмотреть, если установка selectMethod=direct имеет значение для вас.

0