Timeout expired

← →
Петров Денис © (2003-05-12 09:48) [0]

Доброе время суток.

Есть следующая интересная проблема. Порядок объема таблиц базы данных - миллионы записей (база содержит данные сетевого траффика, объем ежедневного пополнения около 80 000 записей). База данных на MS SQL 2000 SP3. Соединение реализовано через ADO, система - Win2k SP3.

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

Поясню: например, отчет с 1 апреля по 12 мая построить реально, а с 1 по 12 мая - вылетит по таймауту (так как данных за этот период немного).

Текст запроса, ессно, не меняется (кроме дат).

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

Кроме того, в программе используется несколько запросов. ВСЕ ведут себя одинаково, хотя структура отличается, и значительно. Замечу, что другие SQL-сервера вообще не потянули этот объем базы - Interbase 6.5 умирал еще в процессе добавления данных в таблицы базы, Sybase ASA 6.0.3 - в принципе не мог выполнить ни одного запроса уже на объеме в 100 000 записей.

Для примера приведу текст одного из запросов:

SELECT Users.UName,
TempTraffic.UserTraffic

FROM

(SELECT Requests.RUser,
(SUM(Traffic.TSize) / 1048576) AS UserTraffic

FROM Requests JOIN Traffic

ON Requests.RDate = Traffic.TDate AND
Requests.RUser = Traffic.TUser AND
Requests.RID = Traffic.TID

WHERE Requests.RDate BETWEEN :BeginDate AND :EndDate

GROUP BY Requests.RUser) AS TempTraffic JOIN Users

ON Users.ID = TempTraffic.RUser

ORDER
BY TempTraffic.UserTraffic DESC

Если у кого есть мысли по поводу решения проблемы, подскажите, пожалуйста.

← →
sniknik © (2003-05-12 10:31) [1]

а курсор какой серверный/локальный?

была такая проблема (с умиранием запроса в середине) но правда не MSSQL а с Access + Midas + ClientDataSet, но признаки похожи (работает работает, стор тормоза) и именно на больших обьемах маленькие на ура все. было от неправильной настройки в частности курсор локальный, поставил серверный + Last (нужно было именно перекачать данные на клиента) и все "пошло".
короче поиграйся курсорами. может и у тебя "пойдет" (если от этого).

← →
Anatoly Podgoretsky © (2003-05-12 10:41) [2]

У него наоборот, он утвержает, что на больших выборках нормально, а на маленьких капут.
Но курсор надо выбрать подходящий.

← →
Bachin (2003-05-12 11:42) [3]

была аналогичная проблема. вылечилась до банальности просто - в запрос добавил конструкцию fast first row и все ;)

← →
Петров Денис © (2003-05-12 12:45) [4]

Bachin >> Поподробнее можно?

← →
Петров Денис © (2003-05-12 13:18) [5]

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

← →
Kapusto © (2003-05-12 13:28) [6]

- План выполнения запросов смотрел?
- Какие индексы используются при выборках? или там чистый table-scan?
- Статистика по таблицам давно обновлялась?

← →
Петров Денис © (2003-05-12 13:47) [7]

Kapusto > да причем здесь план выполнения запросов или индексы? Однозначно могу утверждать, что индексы используются те же, что и при выборке на больших объемах данных.

Кроме этого, подчеркиваю, в Query Analyzer ВСЕ РАБОТАЕТ!

← →
ND (2003-05-12 14:03) [8]

У меня то же была проблема со связанными серверами - SQL server
не хотел из обновлять в явном виде через форму, а через Query Analyzer все работало в тех же самых свзанных серверах - так и не понял в чем дело.

Может Query Analyzer использует какой-то спец. доступ к данным.

Петров Денис © (12.05.03 13:47)
> Кроме этого, подчеркиваю, в Query Analyzer ВСЕ РАБОТАЕТ!

тогда (раньше Q.A. не упоминался) зависит на 98,7% от настроек ADO компонентов.

Ни фига себе не упоминался... А как же "Те же запросы, но выполняемые в консоли MSSQL, прекрасно работают"?

А по поводу настроек ADO компонентов - собственно, я и спрашиваю, что и где следует настроить, что бы все начало нормально работать.

"Query Analyzer" это не "консоль MSSQL", консоль это чтото типа дос окна (в этом режиме прога) а Q.A. нормальная оконная прога. понять что ты именно его имел ввиду, мне было не дано.

по поводу настроек я уже говорил и что сделал сказал у меня работает но дело в том что у тебя это не тоже что у меня, и признаки похожи но отличия есть см. Anatoly Podgoretsky © (12.05.03 10:41) существенные :о)), и компонентов побольше так что мои настройки тебе скорее всего ничего не дадут.

но если хочеш (то что я считаю главным)
ADOConnection.CursorLocation:= clUseServer;
ADOConnection.IsolationLevel:= ilReadUncommitted;

ADODataSet.CursorLocation:= clUseServer;
ADODataSet.CursorType:= ctOpenForwardOnly;
вот это мне помогло.

Ну если в QA работает, то он использует следующие настройки: SQL_CONCUR_READ_ONLY, SQL_CURSOR_FORWARD_ONLY, SQL_CUR_USE_DRIVER.
И имей ввиду. В контексте одного соединения с такими настройками может быть активен только один (!) курсор. "Зависание" запроса при такой конфигурации может просходить, если ты пытаешься "одновременно" выполнять два запроса. Я такое "ловил" при попытке выполнить две хранимки в контексте одного соединения (по моему, точно уже не помню).
Хотя это нетепичный случай ;)
Обычно в такой ситуации возникает ошибка "Connection is busy with results for another hstmt". Но это ошибка ODBC. Как ведет себя ADO в такой ситуации - ХЗ.
Пробуй, если что, пиши.

Timeout expired Найти похожие ветки