Соединение JDBC с очень занятым SQL 2000: selectMethod = курсор против selectMethod = прямой?

Question

В процессе попытки помочь группе разработчиков приложений с проблемами производительности на сервере 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 и драйвер ODBC для SQL Server используют серверные курсоры API вместо наборов результатов по умолчанию. Каждый вызов функции API, выбирающей строки, генерируетобратное обращение к серверу для извлечения строк из курсора сервера API.

ОБНОВЛЕНИЕ : рассматриваемая строка соединения является параметром строки соединения JDBC, selectMethod=cursor (который включаетсерверные курсоры, о которых мы говорили выше) против альтернативы * 1013. * Они используют selectMethod=cursor в качестве стандартной строки подключения для всех приложений.

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

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

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

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

Также перекрестно опубликовано в SF .

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

РЕДАКТИРОВАТЬ : Добавлена ​​награда.Также добавлено вознаграждение в вопрос 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() и т. Д.)

Наконец, Microsoft заявляет следующее:

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

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