JDBC-соединение с очень загруженным SQL 2000:selectMethod=курсор или selectMethod=direct?

Question

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

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

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

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

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

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

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

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

Также перенаправлено в Сан-Франциско.

РЕДАКТИРОВАТЬ:Получены актуальные технические подробности, требующие существенного редактирования заголовка, вопроса и тегов.

РЕДАКТИРОВАТЬ:Добавлена ​​награда.Также добавлена ​​награда за вопрос SF (этот вопрос посвящен поведению приложения, вопрос SF ориентирован на производительность SQL). Спасибо!!

Answer 1

Кратко,

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

В итоге,

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

Answer 2

С использованием selectMethod=cursor запрещает SQL Server использовать Параллельная обработка запросов, что может оказать большое влияние на производительность, например, если:

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

Наконец, Майкрософт состояния следующее:

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

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