ODBC DSN замедляет MSSQL до тайм-аутов

Question

В MS SQL Server 2008 R2 в Windows XP с пакетом обновления 3 (SP3) имеется многомиллионная база данных записей.

Мой сотрудник написал приложение .Net, которое напрямую подключается к этому db и запускает разумное количество запросов. Я не знаю .Net, но я уверен, что это приложение не подключается к БД с использованием ODBC.

С другой стороны, я написал приложение python из командной строки (CPython версии 2.7.5), которое подключается к этой базе данных и запускает простые запросы для отправки данных через Интернет в другое место. Соединение с базой данных выполняется с использованием pyodbc 3.0.7 (установщик от http://www.lfd.uci.edu/~gohlke/pythonlibs/) и DSN, который использует драйвер SQL Server Native Client 10.0. Я попытался отключить и включить пулы подключений для этого драйвера в таблице Connection Pooling вкладки windows Data Sources (ODBC) апплет. Скрипт отправляет 100 записей из db, а затем закрывает соединение и спит в течение 2 минут, а затем снова запускается.

Обе эти программы работают постоянно на той же машине, что и дБ.

Вопрос: приложение .Net прекрасно работает, когда я удаляю определенный DSN (и, конечно, скрипт python не работает). Когда я снова определяю DSN и запускаю скрипт python для запуска бок о бок .Net-приложение, проблем нет примерно на 5 часов. но затем постепенно, в то время как сценарий python в основном прекрасен, приложение .Net начинает получать тайм-ауты из db.

Что может произойти неправильно, если это произойдет?

EDIT:

питон скрипт (который подключается с помощью ODBC) работает нормально, все время. но приложение .Net отстает от обычной производительности через пару часов. Когда я закрываю скрипт python, приложение .Net по-прежнему остается позади. но когда я удаляю ODBC DSN, который я определил для скрипта python, приложение .Net возвращается к нормальной работе. Это очень странно. Как я уже сказал, я ничего не знаю о .Net, так что это может быть результатом нестандартного кода со стороны приложения .Net, возможно, открытых транзакций, блокировок, слишком большого количества подключений и т. Д. Чтобы сделать дело незнакомцем, размер базы данных до половины, удалив записи и перестроить индексы, похоже, решил проблему с .Net-приложением до сих пор.

EDIT 2:

Единственные два запроса, что питон скрипт работает, являются:

SELECT TOP 100 FROM tbl_data WHERE id > ? ORDER BY id 

и

SELECT * FROM tbl_data WHERE id = ? 

Первый запрос, как правило, работает только один раз в каждом цикле питона скрипт. Второй работает не более 100 раз. id является первичным ключом, и поэтому индексируется. Как вы видите, запросы не могут быть проще. Для первого запроса я прочитал весь набор результатов в программе, чтобы не держать курсор открытым на сервере БД. Кроме того, я отключил объединение пулов в апплете ODBC для используемого драйвера, поэтому после каждого запуска скрипта необходимо было установить соединение с БД, и все ресурсы на сервере БД должны были быть освобождены. Сценарий спит в течение 2 минут, а затем повторяет это.

Запросы, выполняемые приложением .Net, намного сложнее, в сочетании с некоторыми триггерами в базе данных. И странно, что он работает в основном отлично, сам по себе. но когда DSN определен, он начинает получать длинные ожидания в одном заявлении insert, что иногда приводит к таймауту.

Также я должен был сказать, что Windows и MSSQL не обновляются с последними исправлениями от Microsoft, поэтому, если это ошибка в драйвере ODBC или сам MSSQL, он мог бы быть уже решен для других.

РЕДАКТИРОВАТЬ 3

Таблица сгруппирована по индексу PK. таблица данных содержит около 1,5 М записей. Размер БД составляет около 160 ГБ. Сервер не имеет высокой спецификации. Intel Core i7 2600, 4 ГБ оперативной памяти, обычный 1ТБ SATA-накопитель.

Answer 1

Есть ряд вещей, которые могут повлиять на производительность. Могут существовать конфликты ресурсов, субоптимальная конфигурация SQL Server, медленные диски, отсутствующие индексы и т. Д.

Я бы начал с мониторинга системных ресурсов, когда оба процесса запущены. Вы можете использовать perfmon для мониторинга счетчиков ОС и SQL. Я хотел бы начать, глядя на

• ProcessorInformation /% процессорного времени

  LogicalDisk/Avg Disk сек/чтение

  LogicalDisk/Avg Disk с/написать

  Память/Доступно МБ

  SQLServerBufferManager/BufferCacheHitRatio

  SQLServerBufferManager/PageLifeExpectency

Вот большая статья об использовании Perfmon, http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

Следующим шагом является оптимизация запросов и SQL производительности сервера.

производительность запросы, http://technet.microsoft.com/en-us/magazine/2007.11.sqlquery.aspx SQL производительность сервера,

• Отдельных данные и файлы на разных томах журнале (рейд 10 предпочтительнее)

  -tempdb (http://technet.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx)

  -configure мин/макс.

  -конфигурировать блокирующие страницы в памяти и мгновенные файлы initiali зация

  -Проверит эту ссылку, http://www.brentozar.com/sql/sql-server-performance-tuning/

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