Программное выполнение запросов

[SLIM]

SQL Server
Нет возможности испытать, но скажите мне если не трудно, если сделать консоль выполнения запросов самому, используя непосредственно для выполнения ADO например, будет ли отличаться скорость выполнения и как ее повысить до максимального уровня, сравнимо например с Query Analizer-ом

[HandKot]

скорость выполнения запросов не должно зависеть от клиентской утилиты, т.к они авыполняются на сервере

возможно, что если и будет отставание, то только в момент передачи результата запроса клиенту и его отображения

[SLIM]

Я понимаю что скорость выполнения не изменится.
Узкое место - передача (запрос) к серверу. Вот меня и интересует, какие камни могут возникнуть
А отвечать так никто и не торопится...жаль конечно

[iGrok]

А отвечать так никто и не торопится...жаль конечно

Просто не очень понятно, в чём вопрос.

[SLIM]

Просто не очень понятно, в чём вопрос.

Ладно, опишу задачу...
в стандартный пакет MS SQL 2000 входит утилита выполнения запросов Query Analyzer. Требуется выполнять запросы в самописной утилите не медленее чем QA.

Что-то мне подсказывает, что сама СУБД не юзает ADO, а я ее собираюсь использовать. Поэтому и интересуюсь, что юзает MS SQL и намного ли медленнее ADO например.

Да и вообще, как клиент обращается к серверу

[arvitaly]

Скорее всего QA использует API ODBC функции http://msdn.microsoft.com/en-us/library/ms714562(VS.85).aspx

[iGrok]

Требуется выполнять запросы в самописной утилите не медленее чем QA.

Гм. А сейчас они выполняются медленнее?

ИМХО, тебе заняться нечем. Или ты просто не там решил искать узкое место...

Я юзал ADO и OLEDB. Каких-либо значимых тормозов не наблюдал.

Нет, если у тебя запросы по 4-5 тысяч символов, и ответ на 500 мегабайт, тогда да. Но в этом случае тебя уже ничто не спасёт, как ни работай с БД, а узким местом банально окажется скорость передачи данных по сети.

Скорее всего QA использует API ODBC функции http://msdn.microsoft.com/en-us/library/ms714562(VS.85).aspx

Я, конечно, точно не знаю, но что-то у меня возникают сомнения, что QA из пакета SQL Server 2000 будет юзать такой уровень абстракции, а не общаться напрямую с сервером. Хотя я могу и заблуждаться..

[karlex]

Есть такой протокол: Tabular Data Stream, если один ресурс не врет, то именно он является тем самым протоколом по которому идет общение с MS SQL Server.

Т.е. используя его, я так понимаю, можно обойтись без ADO и пр. технологий, только вот кто будет этим маяться.

[SLIM]

Гм. А сейчас они выполняются медленнее?

ИМХО, тебе заняться нечем. Или ты просто не там решил искать узкое место...

Я юзал ADO и OLEDB. Каких-либо значимых тормозов не наблюдал.

Нет, если у тебя запросы по 4-5 тысяч символов, и ответ на 500 мегабайт, тогда да. Но в этом случае тебя уже ничто не спасёт, как ни работай с БД, а узким местом банально окажется скорость передачи данных по сети.

arvitaly писал(а):Скорее всего QA использует API ODBC функции http://msdn.microsoft.com/en-us/library/ms714562(VS.85).aspx


Я, конечно, точно не знаю, но что-то у меня возникают сомнения, что QA из пакета SQL Server 2000 будет юзать такой уровень абстракции, а не общаться напрямую с сервером. Хотя я могу и заблуждаться..

Сейчас у меня нет возможности испытат свою утилиту. В двух словах - БД очень большая, запросы конечно не по 5 тыс символов, а вот возврат вполне может быть метров по 150. Поэтому и боюсь что обращение через общедоступные средства будут с тормозами. Но все равно, нормальный запрос к той самой БД выполняется порядка 15 минут, иногда меньше. Однажды я вообще выполнял запрос 6 часов, но это отдельная история.
Так вот и хочется хотя бы такое же время.

[alibek]

Что-то мне подсказывает, что сама СУБД не юзает ADO, а я ее собираюсь использовать. Поэтому и интересуюсь, что юзает MS SQL и намного ли медленнее ADO например.

Да какая разница, что используют для доступа клиентские приложения.
Неужели ты думаешь, что запросы выполняются на них или на прослойках?

[alibek]

а вот возврат вполне может быть метров по 150. Поэтому и боюсь что обращение через общедоступные средства будут с тормозами.

Значит используй серверные рекордсеты, фетчи данные по необходимости и оптимизируй сами запросы.
При чем тут метод доступа к СУБД?

[SLIM]

Да какая разница, что используют для доступа клиентские приложения.
Неужели ты думаешь, что запросы выполняются на них или на прослойках?

Нет, я так не считаю.

Значит используй серверные рекордсеты, фетчи данные по необходимости и оптимизируй сами запросы.
При чем тут метод доступа к СУБД?

Ну вот как бы я и спрашиваю, прим они (методы) тут или не причем, а если и причем, то что делать

Но если разницы нет, то могу сказать только спасибо тебе alibek!

[arvitaly]

Ну вот как бы я и спрашиваю, прим они (методы) тут или не причем, а если и причем, то что делать

На клиентских приложениях тормоза не из-за методов доступа к СУБД, а в отображении передаваемой информации, а также, например, маленькой скорости сети.

И еще ты ведь наверное и сам можешь сравнить и увидеть где теряется скорость. В QA скорее всего пишется время выполнения запроса

[HandKot]

QA скорее всего пишется время выполнения запроса

в QA пишется полное время: и время выполнения и время перекачки результата клиенту

для выполнения запросов используются не только QA, но и osaql.exe, sqlcmd.exe, с некоторым приближением и bcp.exe

[arvitaly]

osaql.exe

osql.exe??

[SLIM]

Мне данные отображать не нужно вовсе.
Все запросы будут через insert-ы

[arvitaly]

150-метровый insert??? Ты же писал у тебя возвращают что-то запросы?

[SLIM]

150-метровый insert??? Ты же писал у тебя возвращают что-то запросы?

150 метров это не так уж часто, но бывает.
Но то что запросы возвращают что-то я не писал.
И все запросы insert-ся.

[arvitaly]

Сейчас у меня нет возможности испытат свою утилиту. В двух словах - БД очень большая, запросы конечно не по 5 тыс символов, а вот возврат вполне может быть метров по 150.

Я что-то не так понимаю?

[SLIM]

Возврат - я имею ввиду суммарный вес данных по итогам запроса. Просто неудачно выразился