Один и тот же запрос в разное время работает по-разному #611880

База 90Гб, MS SQL Server 2005, 140 одновременных пользователей. Ежедневно на сервере проводится апдейт статистики, еженедельно - перестройка индексов. Никак не могу вкурить: один и тот же простой запрос, который вчера работал - сегодня виснет намертво (приходится сбрасывать сеанс). Раньше причину удавалось найти - не отрабатывал апдейт статистики. Сейчас по логам SQL Server план обслуживания отработал корректно. Причем на копии базы, которая делается ежедневно, запрос отрабатывает успешно. Есть тут телепаты? Помогите! Сам запрос вот: Первый подзапрос отрабатывает в рабочей базе 1,5-2 секунды. Второй подзапрос "повисает", хотя отдельный запрос к регистру "Контактная информация" отрабатывает за конечное время.

рестарт серверу 1с еще делай

у меня обычная сличительная клала сервер

Предвещая вопросы к оптимизации запроса, уточню: - ДатаОкончания - ресурс регистра ШапкаДСП; - Статус - ресурс регистра СтатусДСП; - Регистр сведений "КонтактнаяИнформация" непериодический, не подчиненный регистратору.

В воскресенье только перегружал. Как часто рекомендуется это делать?

А в тех. журнале что пишет последние строки ? на чем виснет ? Да и платформа то какая ?

я хз, когда начинали работать под постгри - каждую ночь, сейчас - по необходимости, когда полная ж.па наблюдается )

база 1С 60 Гб 1) делаем рестарт сервера 1С кажду ночь 2) тупняк с зависанием бух. отчетов 3 раза решали путем восстановлени БД из dt

, а прямой запрос такую выборку нормально делает?

Вот вот, знакомая ситуация :) Полные ж0пы мы тоже периодически наблюдаем. Тех.журнал еще не смотрел. Щас настрою. Платформа 8.1.14.72. (да, такая старая, потому что мы распределенное звено в большой филиальной сети).

Не знаю, щас попробую.

а почему нельзя это условие перенести в условие соединения?

да и собственно второе условие туда же... )

А ПОДОБНО зачем такое? Одного типа телефон и условия NOT NULL не хватит? И может у клиента телефонов куча? Перепишите запрос. Условия поменяйте.

получи срезу последних отдельными запросами, а потому уже эти временные таблицы соединяй

а за такое ПОДОБНО надо руки рубить...

скока выдает запрос? ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.КонтактнаяИнформация КАК КонтактнаяИнформация

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

ахёпт, оно ить и внатурально внутреннее. Может в левое переквалифицировать?.. хотя - бред

так там что левое, что не левое. се равно во внутреннее если что.

если сделать , то это реально поможет

поможет второму запросу в пакете?

а как узнали, что именно эта часть запроса подвисает?

Особого эффекта нет, также виснет намертво. Условие на представление необходимо, чтобы вычленить из общей массы телефонов телефоны с 10-ю цифрами для дальнейшего анализа regexp'ом (сотовые телефоны). Ну а какие еще варианты? 313503 записи

а если номер будет а1б2в3г4д5е6ж7з8и9к0ы тоже считываем?

Щас попробую.

Капитан Очевидность утверждает, что если условие переписать так: ВЫРАЗИТЬ(КонтактнаяИнформация.Представление КАК СТРОКА) ПОДОБНО "%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%" то это может (хотя и не обязательно) облегчить жизнь серверу. Ты всё равно больше 20 символов ни где не используешь, зачем их вообще обрабатывать? там дальше нереально хитрожопый механизм на регэкспах их этого говнища телефоны добывает. Так что ответ на твой вопрос - да, это тоже считываем.

а если убрать это условие И КонтактнаяИнформация.Представление ПОДОБНО "%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%[0-9]%" столько же будет выполняться?

Да. Потом прогоняем через regexp с паттерном на сотовые телефоны. Такой номер не пройдет. Выполнил поэтапно в консоли запросов.

и сколько записей фильтруется?

а смысл этого отбора, если там КонтактнаяИнформация.Тип = ЗНАЧЕНИЕ(Перечисление.ТипыКонтактнойИнформации.Телефон) ?

Бинго, пиляйт! Убрал условие "КонтактнаяИнформация.Представление ПОДОБНО" и запрос отработал за 2,5 секунды!

и чо ты терь с этим бинго делать будешь?

Условие "ВЫРАЗИТЬ(КонтактнаяИнформация.Представление КАК СТРОКА) ПОДОБНО" тоже отрабатывает довольно шустро! Осталось понять, то ли я тут дурак, то ли SQL Server меня таковым считает.

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

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

+ или даже телефон писать в Представление, а дополниельный ресурс должен быть булевским типа ПровереноЭлектроникой, чтобы Скайнет собирал только те записи, где проверено электроникой = истина

Опять ограничением являются мозги разработчика

Спасибо всем за помощь!) Да, идея правильная, согласен. У меня даже задачка такая в мантисе висит с пометкой "Сделать когда-нибудь" :) Тогда придется пожертвовать тонной записей с неправильными телефонами. Или преобразовать все такие телефоны в правильные. Во общем, взлетит только после тщательной обработки всех записей контактной информации regexp'ом :) Но все-таки хочу разобраться, почему оптимизатор запроса не справился с таким условием.

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

Ну как бы % говорит о любом количестве знаков, так что сначала была проверка с первого символа, потом со второго, потом с третьего и так далее и 10 раз подряд. Даже я устал писать этот пост.

Понятно, спасибо! :)

что за нелюбовь к внутреннему соединению?

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

а тебе чем оно не нравится?)

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

+ )))