Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[13.59.36.203] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
Итак, нечто совершенно удивительное
Есть MS SQL Server 2008, в нем база данных A с таблицей B. Существует некий запрос вида INSERT INTO #Z(***) SELECT *** FROM B Причем запрос нахродится в батче такого вида: CREATE TABLE #Z(***) INSERT INTO #Z(***) SELECT *** FROM B DROP TABLE #Z К сожалению структуру таблиц привести не могу, но в общем - в них дофига столбцов, и 50 Кзаписией порядка Actual execution plan показывает 96% времени запроса на INSERT'е Силь даже не в этом. Имеем два компьютера - ноутбук с пентиумом dual core и windows vista x86, и сервер с двумя четырехядерными оптеронами и windows 2008, но уже 64-разрядной. На сервере запрос выполняется ~40000 мс. Та же самая база данных, просто забекапленая на сервере и расстореная на ноутбуке, и тот же самый, в точности запрос на ней на ноутбуке выполняется 3000 мс. Сервер во время выпонления запроса ничем не занят, процессор даже во время его выполнения почти на нуле. СУБД MS SQL установлен на сервере в двух экземплярах - 32битном и 64битном, в обоих экземплярах скорость вполнения одна и та же. Вопрос - куда тут копать? |
Сообщ.
#2
,
|
|
|
Возникает подозрение, что всё дело - в собственно настройках сервера. Ведь должно же у него быть логичное внутреннее обоснование не сильно упираться в расходовании ресурсов на одну операцию?
Кстати... а если так, чисто модельно, вместо временной таблицы использовать табличную переменную - результат такой же? |
Сообщ.
#3
,
|
|
|
Ага, время при табличной переменной абсолютно то же.
Настройки у обоих SQL-серверов стандартные(то есть не менялись с момента устанвоки), причем 32-х разрядный инстанс вообще "девственный". |
Сообщ.
#4
,
|
|
|
А есть запросы аналогичного порядка, которые заставляют сервер шуршать что есть мочи? или он всё так вот, с ленцой, делает?
|
Сообщ.
#5
,
|
|
|
Все остальное вроде делает быстро
Делал тест утилитой тестирования сокрости жесткого диска - показатели номарльные. По крайней мере лучше чем на ноуте:) Добавлено То есть да, это единственный проблемный запрос. Прочие инсерты\селекты в нормальные таблицы работают быстрее на сервере |
Сообщ.
#6
,
|
|
|
a select into пробовал?
кажется tempdb тормозит. каков размер данных? может при расширении тормозит? мне не нравится Что # и @ таблицы однинаково работают. профаилер смотрел? |
Сообщ.
#7
,
|
|
|
Цитата Kobra @ a select into пробовал? Да, результат тот же, к тому же это вроде как те же яйца Цитата Kobra @ кажется tempdb тормозит. каков размер данных? может при расширении тормозит? Не очень понимаю. Ну один раз он расширился. Но потом таблица удалилась, и ему уже не надо расширяться. Объем... А хз. 50000 записей, каждая ну по килобайту максимум... Цитата Kobra @ мне не нравится Что # и @ таблицы однинаково работают. Угу, такое чувство что он винт юзает всегда, хотя памяти на сервере явно не мало. Цитата Это execution plan, или чтото другое?профаилер смотрел? Забыл упомянуть, на обоих машинах SQL сервер имеет версию express |
Сообщ.
#8
,
|
|
|
Цитата ANDLL @ ооооо, с этого надо было начинать . експрес может ползоватся только огранисенними ресурсами. так чтоЗабыл упомянуть, на обоих машинах SQL сервер имеет версию express Цитата ANDLL @ не чем не луще твоего ноута, кроме как наверняка, более шустрими винтами. сервер с двумя четырехядерными оптеронами ограничения експреса: максималное ОЗУ 1г. 1 проц (если точно помнью 1 едро для многоядерних). потому и нагрузки на сервере нет. Цитата Kobra @ забуть, для експреса его нет. профаилер смотрел? |
Сообщ.
#9
,
|
|
|
Цитата Kobra @ ооооо, с этого надо было начинать . експрес может ползоватся только огранисенними ресурсами. так что Так что что? Оба с sqlexpress, а производительность разная Цитата Kobra @ не чем не луще твоего ноута, кроме как наверняка, более шустрими винтами. ... |
Сообщ.
#10
,
|
|
|
Цитата ANDLL @ еслиб не експрес, в профаилере можно было бы посмотреть что да как. а с експресом приходится только гадать. правда из статистики (Query->include client ststistics) можно кое что узнать.Так что что? Оба с sqlexpress, а производительность разная кстати, может винт занят другими процесами? например антивиром? |
Сообщ.
#11
,
|
|
|
Нет, все отрубалось, активность винта сначала на нуле, и возрастает во время выпонления запроса
|
Сообщ.
#12
,
|
|
|
Цитата ANDLL @ идеии кончилис активность винта сначала на нуле, и возрастает во время выпонления запроса |
Сообщ.
#13
,
|
|
|
Такое чувство что сервер детектит версию ОС, и на клиентской оси работает иначе чем на серверной. В частности такое чувтсво что temp table на клиентской оси работает в памяти, а на серверной на винте
|
Сообщ.
#14
,
|
|
|
не исклучено.
а статистика что показывает? |
Сообщ.
#15
,
|
|
|
Сколько инсертов было сделано и за какое время.
Инсертов одинаковое количество, вообще все кроме времени одинаковое Добавлено Хотя кстати сейчас начал чуть быстрее делать. Уже 9000 мс а не 40000, хотя все же в три раза медленнее чем клиентская версия. Добавлено Гмм. Может там и правда со временем чтото оптимизируется при одинаковых запросах? Вот ведь прикол будет |
Сообщ.
#16
,
|
|
|
У нас была похожая ситуация, когда крутой сервер выполнял кучку insert-ов медленнее убогой офисной машины. Как выяснилось, был крайне криво настроен RAID или что-то в этом духе, и производительность винта на запись была крайне низкой.
Запусти какой-нибудь бенчмарк на сервере и на буке для сравнения, с чем чёрт не шутит. Добавлено Простите, проглядел сообщения, что винт уже тестировался. Идей тогда нет |
Сообщ.
#17
,
|
|
|
вот это и интересна. на каких операциях какой сколько времени тратит. где узкое место.
а если вдруг такое ускорение: значит оптимизатор начал правилно работать. но почему так поздно? илиже ранше винт был занят. но то что в експресе ограничения както работают, сам производител громко заявляет . Добавлено wdk в одном прав. одни раиды ускоряют чтение и замедляют запис, другие наоборот. |