Коллеги, всем доброго времени суток!

В общем есть система, есть база, запросы не легкие. База весит 25 Гб. Данных много. До перехода на САБЖ платформу, все работало стабильно и корректно. Одна группа запросов отрабатывала в районе 3х минут, вторая в районе тоже 3-4 минут. Не зависимо от того сколько блокировок и сполько пользователей. За 3 месяца проблемы ни разу не возникло (примерно столько времени назад были написаны запросы).

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

Ладно - оптимизировали.. Все равно запросы на реальной базе (действующей) работали медленно. Очень медленно. До 10-30 минут.

Сотворили ночью реструктуризацию и переиндексацию базы. Запросы залетали. Стали работать как и положено не более 3х минут. Все радовались.

Но затем обнаружили что база выросла до 50Гб после исправлений и реиндексаций.

Шринканули базу.
Теперь один запрос работает как и ранее не более 4х минут. С учетом нагрузок. А вот второй - вешает сеанс. Куда его дальше оптимизировать пока не вижу. Но допустим пути найдутся.
НО!
1. Беспокоит то что это в принципе то может работать быстро! Но в чем дело?
2. Комания где я раньше работал, там вообще серверы не серверы а обычные самосборы на Core i7 и диски SSD для СУБД. Запросы там в разы более жестокие чем здесь сейчас. Обращений через точку море. Временных таблиц море. Данных ещё больше. И вот общался с ex.коллегой он говорит что у них напротив на 8.2.18.109 система на 10% шустрее стала работать. Но один нюанс. Они использую SQL 2012. У нас здесь 2005й.

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

нюанс наверное один, не оптимальный план запроса.
обновление статистики и очистка кэша.
"Не выполняются хоть тресни" это скорее всего nested loops.

(1) nested loops - возможно.
Я конечно ещё раз прочешу запрос.
Жаль сейчас нет возможности на старой платформе глянуть через SQL Profiler запросы, и сравнить их с теме что сейчас получаются на уровне SQL.

По сути пришлось избавиться почти от всех обращений через точку.

Тоесть, до этого были "точки".

Автор жжет.

Оптимизаторы хреновы.

"Сотворили ночью реструктуризацию и переиндексацию базы"
то есть никаких регламентных процедур на скуле не проводится. Круто, че...

т.е. текстов запросов не будет

8.2.18.109 забагованный, откат на 8.2.18.102 убрал все глюки.

(6) Это Клуб Анонимных Быдлокодеров.
Тут нужно просто поделиться, выговориться и полегчает.

(3) Да-да. Были точки стали запятые.
А если серьезно, опять же в Ex конторе ввиду специфики, поля могут иметь вид чуть ли не
"Объект.ВложенныйОбъект.Поле.Ссылка.Поле.Поле.Ссылка.Поле".
И у них все летает по прежнему.
У меня же такого беспредела не было. Но все эти штуки пришлось переписать на дополнительные временные таблицы. Что бы стало работать быстрее или хотя бы приемлимо.
(6) Ммм, пока нет. Ссори. Просто мне было интересно было ли нечто подобное у кого-то или нет. А запросы в любом случае длинные и не интересные. И уже сейчас динамически меняют свою структуру каждую секунду.

Не думаю, что платформа стала по-другому транслировать запросы в SQL.
Если во время выполнения запроса нагружен именно SQL , а не rphost, значит - проблема в SQL.
" база выросла до 50Гб после исправлений и реиндексаций." - так и должно быть.

Усилил ещё одно слабое место в запросе. Уменьшил количество строк в одной из временных таблиц. Которые не повлияют на общую логику. Закрутился запрос по шустрее.

Но все таки подозреваю что план запросов как минмум с 2005м сервером изменился. Потому что изменилась только платформа. И именно с этого момента проблемы начались. Да запрос может был и не ахти корректным. Каюсь. Но раньше то он работал оптимально. Следовательно сервер приложений его сам как-то оптимизировал. Теперь перестал. И узкое место стало выявленным.

(0) До этого-то какая платформа была?
Если кроме обновления платформы ничего не делали - что мешает откатится обратно?
Перестройку индексов, обнвление статистики с какой переодичностью на SQL делаете и делаете ли вообще?

+1   откати платформу - проверь, делов то

(12) Вот не могу достоверно вспомнить. Но вроде около 17.68. В этом районе цифры версии. Но не 102я точно.

Откатить мешает:
1. Конфа на 50% не стандартная. Каждый день вносится множество изменений. Но это фиг бы с ним - хранилище в помощь.
2. Слишком легально все. Кругом золотые правила лицензирования. Лишний сервак развернуть не дадут. Старый откатывать даже на тестовом не дадут из-за того что придется приостановить доработки пока все будет настраиваться. А тут ещё и куча интеграций со всякими едиными базами. По терроризму и страхованию. И на разных платформах там помню приходилось перенастраивать связь с этими системами внешними (вне офиса). А ставить сервер приложений на локальные компы разработчиков - тоже нарушение лицензии)
3. Пользователей более 100. Если случится отказ из-за наших экспериментов - по голове не погладят)

Как вариант принести ноут и на ноуте развернуть. Но у меня на ноуте тоже SQL Express. А там лимит размера БД до 8 Гб на  2005м и вроде 16Гб на 2008м. 12й не знаю сколько можно.

В общем может на досуге попытаюсь дома развернуть ради эксперимента и сравнить планы запросов.

(14) можно на одном физическом сервере несколько разных версий сервера 1с иметь совершенно легально

(15) Хорошо. Попробую пролабировать) Но проще будет самому на своем железе проверить.