fhqhelp
Алекс К

Ну а где же про ssd и новомодное "отказ от дефрагментации на основе avg_fragmentation_in_percent"?
Вот это вот все: https://blogs.msmvps.com/gladchenko/nodefrag/ ? .. схожие мысли были вроде и у https://www.brentozar.com/blog/ - мол не увлекайтесь древним avg_fragmentation_in_percent >10-30%.

Сам сижу на массивах смешанных - там ssd, сям шпиндели, а вот тут - смесь первого и второго и хитрый контроллер еще и сам распихивает кому куда.
Сделал несколько выводов
- на шпиндельном массиве можно пользоваться старой схемой, но задрать пороги с 10-30 до скажем 30-80 - без особо заметной деградации
- на ssd фрагментация внешняя не шибко влияет на index seek
- зато влияет на скан (но как часто бывает тот скан?)
- и влияет на буферпул! иные индексы раздувает так безбожно, что ниприведдихосспидя их вытащит в память - задержки pageiolatch, падение page life expectancy .. а если они постоянно в памяти?
- и влияет на объем бд, и бывает сильно - а место не резиновое, и бекапы медленные
- и реиндексация на ssd все равно нужна, но лучше понятное дело смотреть на avg_page_space_used_in_percent - и пороги делать разные для "оно постоянно в памяти" и "оно редко в памяти"
- можно, как ни странно, довольно точно отличить где ssd, а где нет - через sys.dm_io_virtual_file_stats (в случае смешанных массивов конечно ой)


А так да.. напарывался на "от вашей реиндексации место в логе кончилось", и сделал аналогичные предохранители
И "alwaysOn загнулось от реиндексации" тож бывает.
И еще блокировки на ней бывают, и WAIT_AT_LOW_PRIORITY не всегда устраивает..

Материал относится к базам данных на связке «1С - MS SQL Server».
Один из способов отлова блокировок в бд 1С .
Переход к управляемым блокировкам через режим "Автоматический и управляемый".

(19) >>.. заканчивается ничем ..
Это вроде-бы уже не так.
От однозначного "нет, это нарушение закона" риторика на партнерском форуме вроде смещается в сторону "не рекомендуется, на ваш страх и риск, и забудьте в этом случае про техподдержку".
Хотелось бы, конечно, более быстрого развития событий.

(4)
Да не суть важно..
Конкретный запрос можно починить кучей способов - вопрос-то в другом..
Вопрос - как их выявлять, и желательно заблаговременно, до катастроф

(5)

Цитата
SET STATISTICS XML ON

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

Да, наверное нужно было исходный код.
Отбор по дате есть.
Тут методологическое скорее.. отчет запускается с пустыми по-умолчанию датами, и работает ветка "ВЫБОР КОГДА &Дата2 = ДАТАВРЕМЯ(1, 1, 1) ТОГДА &Дата1 <= Обращение.Дата" .. т.е. "И '1753-01-01 00:00:00' <= Обращение.Дата"
Отбор есть - толку нет.
На предложение "а давайте воткнем по-умолчанию последний год" последует "а у нас задания и по пять лет висят".

Код

ВЫБРАТЬ     ... ИЗ     БизнесПроцесс.Обращение КАК Обращение         ЛЕВОЕ СОЕДИНЕНИЕ БизнесПроцесс.Задание КАК Задание         ПО Обращение.Ссылка = Задание.Обращение И (Задание.ОсновноеЗадание = ЗНАЧЕНИЕ(БизнесПроцесс.Задание.ПустаяССылка)) ГДЕ     НЕ Обращение.ПометкаУдаления     И Обращение.Инициатор = &Инициатор     И НЕ Обращение.Состояние В (&СписокСост)     И ВЫБОР КОГДА &Дата2 = ДАТАВРЕМЯ(1, 1, 1) ТОГДА  &Дата1 <= Обращение.Дата ИНАЧЕ Обращение.Дата МЕЖДУ &Дата1 И &Дата2 КОНЕЦ ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ     ... ИЗ     БизнесПроцесс.Задание КАК Задание         ЛЕВОЕ СОЕДИНЕНИЕ БизнесПроцесс.Обращение КАК Обращение         ПО Задание.Обращение = Обращение.Ссылка ГДЕ     Задание.Инициатор = &Инициатор     И НЕ Задание.Состояние В (&СписокСост)     И ВЫБОР КОГДА &Дата2 = ДАТАВРЕМЯ(1, 1, 1) ТОГДА &Дата1 <= Обращение.Дата ИНАЧЕ Обращение.Дата МЕЖДУ &Дата1 И &Дата2 КОНЕЦ

Рассматривается один из типов массовых проблем в рабочих базах на связке «1С - MS SQL Server».

(9) Да, но есть засада - оптимизатор не всегда сумеет верно оценить количество строк, которые отдаст подзапрос
( ВЫБРАТЬ РАЗЛИЧНЫЕ ..ИЗ Документ.ПеремТов.Товары КАК Товары ГДЕ Товары.Ссылка = &Ссылка )
По разным причинам (например неактуальные статистики по ПеремТов или неудачное значение &Ссылка).
А если выделить этот подзапрос во времянку - такой ошибки быть уже не может.. Количество строк во времянке число абсолютно конкретное, и оно известно оптимизатору ДО создания плана (запроса к остаткам).
Поэтому и предпочитаю времянки.. хуже, да стабильней..
Впрочем, будет ли на этом sql ошибаться в каждом конкретном случае, и насколько часто - еще тот вопрос.. тут практика критерий истины.. тут "эксперимент - сбор статистики - анализ - правки"

(8) спасибо, да, это опечатка

ок, попробую .png..

(6) Архитектура - зачастую данность, которую не изменить (сложно, долго, дорого). Но, даже с не шибко хорошей архитектурой можно таки ужиться. Даже не так - приходится уживаться, и есть способы уживаться.
>> ..Очевидно, что все 500 млн записей хранить..
Не очевидно, нет.
Было бы ненужно - резали бы нещадно, без придыханий (ну или переливали бы куда).
Хотели было сворачивать.. но что-то не задался проект.