Здравствуйте. Есть таблица. В нее скидываются данные с периодичностью в 1 секунду. Запрос выглядит так:

Код

INSERT INTO L110KVD_B2 (TIMEPOINT,VD000,VD001,VD002,VD003,VD004,VD005,VD006, VD007,VD010,VD011,VD012,VD013,VD014,VD015,VD016,VD017,VD020,VD021,VD022, VD023,VD024,VD025,VD026,VD027,VD030,VD031,VD032,VD033,VD034,VD035,VD036, VD037,VD040,VD041,VD042,VD043,VD044,VD045,VD046,VD047,VD050,VD051,VD052, VD053,VD054,VD055,VD056,VD057,VD060,VD061,VD062,VD063,VD064,VD065,VD066, VD067,VD070,VD071,VD072,VD073,VD074,VD075,VD076,VD077,VD100,VD101,VD102, VD103,VD104,VD105,VD106,VD107,VD110,VD111,VD112,VD113,VD114,VD115,VD116, VD117,VD120,VD121,VD122,VD123,VD124,VD125,VD126,VD127,VD130,VD131,VD132, VD133,VD134,VD135,VD136,VD137,VD140,VD141,VD142,VD143,VD144,VD145,VD146, VD147,VD150,VD151,VD152,VD153,VD154,VD155,VD156,VD157,VD160,VD161,VD162, VD163,VD164,VD165,VD166,VD167,VD170,VD171,VD172,VD173,VD174,VD175,VD176, VD177,VD200,VD201,VD202,VD203,VD204,VD205,VD206,VD207,VD210,VD211,VD212, VD213,VD214,VD215,VD216,VD217,VD220,VD221,VD222,VD223,VD224,VD225,VD226, VD227,VD230,VD231,VD232,VD233,VD234,VD235,VD236,VD237,VD240,VD241,VD242, VD243,VD244,VD245,VD246,VD247,VD250,VD251,VD252,VD253,VD254,VD255,VD256, VD257,VD260,VD261,VD262,VD263,VD264,VD265,VD266,VD267,VD270,VD271,VD272, VD273,VD274,VD275,VD276,VD277) VALUES (CONVERT(DATETIME,'2004-12-06 12:08:06',102),0,0,1,0,1,0,0,0,1,0,1,0,0,0,0, 0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,1,1,1,1,0,0,0,1,0,0,0,1,1,0,1,0, 1,0,0,1,1,1,0,0,1,1,1,0,1,0,1,1,0,0,0,1,0,0,0,0,1,0,1,0,1,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0, 0,0,1,0,1,0,1,0,0,0,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)

длинный запрос такой

По полю TIMEPOINT сделан кластеризованный индекс (это поле участвует в выборках по условию Where). На таблице висит два триггера (оба по инсерту) и все что делают - обновляют в другой таблице одну строчку (таблица из этой строчки и состоит). Вся база весит ~6,5Гб. Сервер: 2,4 Гг, 2Гб RAM, скайзи-винты.
Вроде ничего не забыл... Теперь вопрос. Часть insert-ов не проходит. Вместо положенной 1-й секнды, данные записываются по разному, то через 1-у как надо, то через 2 сек. то через 3 сек. Для моей задачи это критично. Кроме того, что база копится, из нее делают выборки. Все однотипные: select .... from table where timepoint>... and timepoint<... В чем может быть проблема?

Это сообщение отредактировал(а) Vit - 6.12.2004, 07:21

1) Кластерный индекс с какой сортировкой? Всегда ли Insert производится в конец таблицы? Если нет то здесь и проблема... Вообще-то при таких частых Insert ставить кластерный индекс это не самая лучшая идея, а возможно и вообще индексы не стоит ставить... Тут надо больше знать. Но как вариант я бы начал с того что кластерный индекс выбросил на фиг (при таких частых изменениях в таблице он скорее помеха чем помощь), оставил обычный, кстати уничтож и пересоздай индексы, иногда помогает.

2) Ключ по каким полям стоит?

3) Вообще SQL очень хреново работает с таким большим количеством полей, может таблицу нормализовать? Или как вариант - какой тип имеют поля VDxxx? По ним есть запросы (имею ввиду order, group, where, having)? Если нет, то сделай из них одну строку - работать будет на порядок быстрее, при взятии данных - конвертнёшь в boolean - наверное это самый хороший вариант оптимизации. Ещё можно таблицу разбить на несколько... Если в таблице очень много записей, то каждый день делать новую таблицу типа L110KVD_12dec2004. Если не очень много то разбить вертикально на 2-3 таблицы с половинным количеством полей - вставка в 2 таблицы будет идти быстрее.

4) Такая большая кверя долго компиллируется. Засунь её в SP и вызывай SP с параметрами.

5) Выключи временно триггеры посмотри как будет себя вести, если триггеры виновыты, выброси их на хрен, используй Select max(TIMEPOINT) ....

5) Открой SQL Query Analyser - загрузи этот запрос, включи план выполнения запроса и посмотри что жрёт ресурсы (время и загрузку процессора), поиграйся с хинтами

6) В твоих селектах добавь хинты чтоб убрать блокировку (возможно только это уже решит проблемы):

Код

Select * From L110KVD with (nolock) Where ...

7) Индексы какие на этой таблице?

Showcontig

Покажет тебе сегментированность индексов...
Загрузи в аналайзер свои селекты - посмотри они вообще индексы используют? При таких частых изменениях наверное не успевает статистика использования индексов обновляться, постаь ежедневное обновление статистики.

8) Временно отключи селекты посмотри как на производительность это повлияет

9) Возможно на insert попробовать поставить хинт rowlock (правда на insert я его никогда не делал, обычно на Update, но чем чёрт не шутит)

10) Инсерты откуда идут? Из программы или какая-то Job стоит в SQL агенте? Если Job - то бороться бесполезно, она работает с минимальным приорететом, для такой частоты не подходит, надо програмно реализовывать.

11) 102 - не помню, это ты куда время конвертируешь? Может не надо его конвертировать никуда? Может поставишь ключём аутоинкремент, а время индексированным полем и без всякой конвертации? Должно быть быстрее. Если время - это текущее время, то используй GetDate

спасибо, Vit. Так много насоветовал. Буду пробовать. А пока, то что сразу могу сказать: Инсерты идут от приложения, оно может выдавать и чаще. Селекты не постоянные. В 90% случаев их нет вообще, так как данные необходимы при "разборе полетов". Если я уберу индексы - то даже при таком размере базы получу офигенные тормоза при выборках этих значений (выборка, скажем, за сутки). Переиндексировать пробовал - не помогло. Ключ, как ты и сказал, стоит по полю-ID записи (автоинкремент). По поводу SP еще не попробовал, занимаюсь. Индекс отсортирован по возрастанию. Попутно, как убедиться, что вставка делается в конец таблицы? Экспериментально - вроде в конец.

Цитата(unreg @ 6.12.2004, 00:33)

Попутно, как убедиться, что вставка делается в конец таблицы? Экспериментально - вроде в конец.

Нет, имеется ввиду не это... У тебя кластерный индекс по TIMEPOINT, вопрос такой:

Всегда ли TIMEPOINT вставляемой записи больше тех что уже есть в таблице? Если всегда, т.е. ты всегда вставляешь большее значение TIMEPOINT чем любое значение TIMEPOINT которое уже есь в таблице то всё нормально - можешь пользовать кластерный индекс, если нет, то надо его заменить на обычный.

Лучше совсем отказаться от индексов.
А для разбора полетов, сливать данные за нужный период в отдельную таблицу и в ней уже анализировать ситуацию.

Цитата(boevik @ 6.12.2004, 08:30)

Лучше совсем отказаться от индексов. А для разбора полетов, сливать данные за нужный период в отдельную таблицу и в ней уже анализировать ситуацию.

Угу... а то и всю целиком...

TIMEPOINT всегда разный. И всегда больше предыдущего. Таблица содержит данные с контроллера и TIMEPOINT - текущее время для считанных данных. Одно мое приложение (драйвер) опрашивает контроллер, другое архивирует данные в БД, ну и есть два вида клиентов (мониторинг и анализатор). Мониторинг с базой не работает, а обращается напрямую к драйверу. А вот анализатор - конечно берет ретроспективу из базы. При этом, должна быть возможность выбирать данные за любой промежуток времени. Сначала индексов не было и даже при меньшем объеме базы половина селектов выпадала по таймауту, с индексами работает очень шустро и таймауты вылезают только если в сети затыки. Это я к тому, что не понял последних высказываний по поводу индексов Когда идет разбор, с базой соединяются до 10-15 пользователей и выборки делают не кислые, кто за 12 часов, кто за сутки, а кто-то может и несколько разных интервалов посмотреть + не по одному полю.
Ну мы нашли, что тормозит наш инсерт. В своих тригеррах мы просто злоупотребили update-ом. У нас есть табличка содержащая одну строку которая постоянно обновляется (для каждой задачи свое поле). Этим мы хотели решить задачу общего мониторинга БД. И до поры все работало на ура. В общем получилось так, что количество задач росло и мы просто задушили эту таблицу апдейтами. Пришлось немного переделать.
Всем спасибо за участие.

Проблема решилась или нужна дальнейшая помощь?

Нет, спасибо. Новый вопрос пока не назрел.