База 1С не ломается за секунду — она понемногу устает каждую ночь

Привет, это СБиСик, тот самый пушистый консультант, что обычно сует мордочку в самые тёмные уголки ваших баз. Сегодня хочу поговорить о вещи вроде бы скучной — регламентном обслуживании SQL Server. На самом деле это история про то, почему утром накладные открываются за пять секунд или за пять минут. Казалось бы, мелочь, но если бухгалтер стартует день с чашки кофе и полосы “Ожидание SQL-запроса”, настроение компании задаётся на сутки вперёд.

Откуда берётся “пивной” эффект: вчера налили — сегодня выдохлось

Когда ставят клиент-серверную 1С на SQL Server, у бизнеса часто срабатывает иллюзия: ну раз сервер серьёзный, значит можно расслабиться. Железо шумит, лампочки мигают, данные крутятся — чего ещё нужно? На старте действительно всё летает. Индексы свежие, статистика девственно точная, транзакционный журнал аккуратен. Но база начинает жить: документы прилетают пачками, отчёты строятся, пользователи то проводят, то исправляют, иногда даже делают отмену проведения прямо в пике дня. Каждая такая операция — маленький пузырёк воздуха в бочке пива. Сначала не видно, потом пена съедает половину кружки.

Через месяц-­другой индекс уже фрагментирован на треть, планы запросов кэшируются на давно ушедшую в небытие картину данных, а статистика смотрит на мир глазами позапрошлой недели. 1С, конечно, пытается что-то подправить сама, но её сил хватает лишь на точечные обновления. Глобально же никто метлу в угол не ставит, и вот “вы духовку топите?”, “а может интернет лагает?”, “что-то сервак опять гудит”.

Смешно, но простейший план обслуживания — пять-шесть пунктов — часто решает больше, чем апгрейд на новый процессор. Я правда не преувеличиваю: приходишь к клиенту, ставишь ночное обслуживание, приезжаешь через неделю — окна в 1С щёлкают, как в демо-роликах. Бухгалтер улыбается, айтишник делает победный жест, а я иду писать короткую заметку в наш канал в MAX, пока воспоминание свежее и не разъехалось по проектам.

Почему не сделать это сразу? Да всё по классике: “рук не хватало”, “не дошли”, “ещё квартал ждали новую конфигурацию”. К тому моменту, когда бизнес начинает прямо говорить “проводки идут вечность”, профилактика превращается в спасательную операцию. Но здесь важно: даже если база уже тормозит, по-настоящему тяжёлой она станет только тогда, когда к плохим планам запросов добавится ещё и повреждение страниц или забитый до упора лог. И вот тут без регулярных CHECKDB и бэкапа разговор уже переходит в плоскость “спасём ли мы УПРЗ сервер до зарплаты”.

Пять симптомов, по которым я чувствую: “В эту 1С давно не заглядывали”

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

Симптом второй. Проведение документа подвисает ровно там, где начинается обновление регистров. Смотрим на блокировки — целая елка из LCK_M_S, но не потому, что пользователи сели на один объект, а потому, что одна операция сканирует всё подряд и держит ресурсы дольше, чем могла бы при правильном плане.

Симптом третий. Журнал транзакций вырос на сотни гигабайт. Визуально в 1С этого не видно, но резервная копия начинает идти вечность, диски крутятся, и любой запрос, который лезет в tempdb, ощущает нехватку дисковых операций.

Симптом четвёртый. CHECKDB внезапно находит подозрительную страницу. Ошибку не видно в интерфейсе 1С, но каждая попытка обращения к повреждённому индексу превращается в “Соединение разорвано”. Регламентная проверка бы поймала это ночью, вместо того чтобы пользователи ловили день сурка днём.

Симптом пятый. Индекс фрагментирован на 60 %. SQL Server всё ещё использует его, потому что вариантов нет, но чтение превращается в марафон с преодолением препятствий. Я иногда ставлю клиенту скрипт, который просто выводит топ-10 самых дырявых индексов — лица людей в этот момент бесценны.

Почему обновление статистики — тот самый “тихий герой”

Многие ищут волшебную кнопку “ускорить 1С”. Звучит скучно, но 80 % чудес я вижу именно после обычного UPDATE STATISTICS. Данные в 1С меняются неравномерно: то слой продаж в розницу, то массовый импортер из маркетплейса, то кто-то загрузил каталог номенклатуры новой ТМЦ. Планы, построенные утром, уже вечером попадают пальцем в небо. Но статистика же обновляется автоматически, скажут мне. Формально да, практически нет. Автообновление срабатывает, когда изменилось 20 % + 500 строк. В розничной точке это отбивается быстро, а вот в регистре движений по миллиону строк за день нужно сменить аж 200 тысяч, чтобы порог упал. Пока ждём, запросы лезут в табличный скан, пишут в tempdb, и пользователи жмут F5, думая, что это ускорит процесс.

Один мой любимый кейс. Клиент жаловался: “СБиСик, у нас ЁНВД отчёт формируется 40 минут, раньше было 8”. Захожу, смотрю статистику — дата последнего обновления два месяца назад. Обновил вручную, отчёт снова 9 минут. Никому кода переписывать не пришлось, просто объяснил: ребята, делайте это раз в сутки, а ещё лучше пробегайте лёгкой реорганизацией индексов. Нюанс: реорганизация не эксклюзивная, пользователи могут работать, а перестроение уже с блокировками, так что надо ловить ночное окно.

А как же индексы: реорганизовать или перестроить?

Тут есть любимый спор админов: “если до 30 % фрагментации — REORGANIZE, выше — REBUILD”. Честно, с 1С логику иногда ломает. Бывает, таблица растёт так, что до 30 % она доходит уже к обеду, а ночью надо сделать полноценный REBUILD. Заменить всё реогранизацией — значит иметь полумеру. Ловлю себя на мысли, что проще завести правило: если фрагментация выше 10 % и при этом индекс меньше 100 мегабайт — перестраиваю; если больше — реорганизую, а в выходные делаю REBUILD онлайн, если редакция Enterprise позволяет.

Небольшое отступление. Иногда спрашивают: “А правда, что перестроение индекса сбрасывает план кэша?”. Да, но это меньшее из зол. Плохой план кэша, основанный на устаревшей карточке клиента, страшнее, чем временный эффект от его сброса. Поэтому я сначала чиню физику, а уже потом слежу за планами. На практике 1С быстро перестраивает кэш, страшных просадок не видно.

Кстати, эта тема обсуждалась недавно в Telegram-канале — там ребята делились, как выкручивались, если REBUILD ночью не успевал в окно. Одни резали таблицу по секциям, другие переносили самые тяжёлые индексы на SSD и выделяли отдельное обслуживание именно под них. Разница в производительности иногда драматическая.

Зачем проверять целостность, если “и так работает”

Обнаружить повреждение страницы, которая редко читается, можно годами. SQL Server вежливо промолчит, пока не придёт запрос именно в тот кусок данных. Поэтому CHECKDB — не роскошь, а страховка, чтобы ваше обслуживание не шлифовало уже треснувшую поверхность. Я видел, как перестроение индекса на повреждённом объекте падало с ошибкой, а админ думал, что “ну, значит, перезапустим попозже”. Спойлер: потом восстанавливали из бэкапа за прошлую ночь, теряя 18 часов свежих документов. Без панических кнопок, но понервничали.

Кстати, резервная копия. Часто слышу: “Да у нас и так резервка каждую ночь”. Окей, а восстанавливались с неё? Чек сумм проходили? Предположим, повреждение в 3 часа дня, бэкап был в 2:45, лог с 2:45 до 3:00 ещё не копировался, потому что никто не настроил лог-шиппинг каждые 15 минут. Потеря полчаса продаж в e-commerce — это реальные деньги, и тут уже ни производительность 1с, ни удобство пользователей, а чистой воды репутационные риски.

История из практики: как ночь индексов спасла закрытие месяца

Конец марта, клиентская база позиций на 25 миллионов строк в регистре остатков. До отчётности осталось два дня, бухгалтеры включили турбо-режим проведения документов. Вдруг поступает звонок: “СБиСик, зависли при закрытии месяца, уже три часа кружочек крутится”. Смотрю — один запрос сканирует фактически весь регистр. Фрагментация 68 %, статистика древняя. Предлагаю: давайте экстренно нарушим график, сделаем REBUILD этой конкретной таблицы, на 40 минут пустим бухгалтеров попить чай. Решились, сделали, попросили всех выйти, проверили CHECKDB прямо точечно на объект. Запускаем повторно закрытие — семь минут вместо трёх часов. Пришлось объяснять экономисту, что это не “чудо”, а накопленный долг, который случайно обрушился в самый болючий момент.

И вот здесь я часто вспоминаю одну фразу: “SQL не чинят в момент паники — его обслуживают заранее”. Системе всё равно, ночью или днём вы потревожите индексы, но пользователю — совсем не всё равно.

Почему мощный сервер не освобождает от обслуживания

Иногда ставят серьёзную железку, 128 ГБ RAM, NVMe, и думают, что магия случилась. Первая неделя — да, ощущение ракеты. Но потом таблицы растут, планы стареют, логи пухнут. И даже самый быстрый SSD не спасёт, если запрос лезет в полный скан таблицы на 500 миллионов строк. В какой-то момент диск упрётся в физический лимит IOPS, память не удержит всё, и привет, “тормоза в интерфейсе”. Апгрейд железа без обслуживания напоминает попытку лечить грипп шоколадом: вкусно, но бесполезно.

Знаете, что еще забавно? Когда делаешь анализ ожиданий в SQL Server и видишь, что сервер простаивает на PAGEIOLATCH_SH, а CPU при этом вялый. То есть, он бы и рад, но ждёт диск, потому что скан огромен. В 1С это отображается как медленное открытие списка документов. И вот первое, что спрашиваю: “Когда последний раз обновляли статистику?” Ответ часто: “А это нужно?”

Регламентное окно: как найти то самое время, когда никто не пострадает

Условно ночное окно у разных компаний бывает и в 18:00, и в 3:00 — смотря где часовой пояс и как работает склад. Главное, чтобы в этот момент не летели обмены, не загружались данные из внешних систем и не работали интеграции. Есть лайфхак: замерить пиковые блокировки и выбрать отрезок, где их минимум. Я иногда штуку делаю: записываю на графике количество живых соединений в течение недели, формирую “тепловую карту” и показываю руководству. Цифры работают лучше, чем слова: говорят “о, здесь всего 12 пользоватлей, давайте и правда переносить обслуживание сюда”.

Ну а если совсем туго с окном — существует онлайн-перестроение индексов. Но тут надо держать в голове редакцию SQL Server. В Standard до 2019 года онлайн-режим недоступен, с 2019-го — только часть возможностей. Enterprise умеет старше, быстрее, но опять-таки не даром стоит. Я обычно предлагаю компромисс: критичные мелкие индексы — онлайн, крупные — реорганизация в будни, rebuild в выходные.

Когда обслуживание превращается в дисциплину, а не в героизм

Самая дорогая ошибка — не сбой, а привычка не замечать замедление. Пользователи месяцами привыкают к тому, что отчёт идёт 20 минут. А потом кто-нибудь зовёт меня, и выясняется, что можно было держать те же пять. Ценность регулярного плана обслуживания в предсказуемости: ты знаешь, сколько будет жить индекс, когда план устареет, сколько места займёт лог. А значит, нет сюрпризов в день закрытия квартала.

Честно сказать, мне самому надоело спасать базы в пожарном режиме. Намного приятнее заходить к клиенту раз в месяц, смотреть отчёт о регламентных работах, отмечать “всё зелёное” и вместе пить чай. Но, эй, мы же ещё не поговорили о том, как правильно настраивать резервные копии и проверять их жизнеспособность…

Резервные копии: меньше героизма, больше рутины

Продолжая тему профилактики, нельзя оставить в стороне бэкапы. В 1С на SQL Server их часто делают “как получится”: поставили полный backup в 23:00, и бог с ним. А потом выясняется, что склад формирует документы до полуночи, лог пухнет, и резервная копия неспешно идёт до трёх утра. Утром сервис интеграции падает, потому что база ещё занята копированием. Первый вывод: время бэкапа должно опираться не на часы, а на реальные пики активности.

Второй вывод прагматичен: backup без проверки — это только иллюзия защиты. Раз в неделю разворачивать копию в отдельный stand-alone экземпляр и прогонять CHECKDB стоит примерно столько же, сколько одна чашка кофе администратора. Но эта “чашка” однажды сэкономит сутки простоя. Реальный кейс: клиент хранил копии на сетевом диске, носитель умер, а они даже не знали, что последние четыре бэкапа битые — ни одной проверки не было.

Журнал транзакций: тихий пожиратель диска

Когда спрашиваю, какой объём занимает ваша база 1С, зачастую называют размер MDF, забывая про LDF. А ведь именно транзакционный журнал вмещает все изменения между бэкапами. Если его не стискать регулярными log backup, особенно в режиме FULL, он раздувается до сотен гигабайт, замедляя всё подряд: восстановление, mirror, даже простое SHRINK трудно выполнить без простоя.

На одной площадке журнал дорос до 480 ГБ при самой базе 110 ГБ. Проводить полный backup ночью уже не успевали, место на SAN закончилось, база встала readonly. Локазала практика: добавить лог-backup каждые 15 минут, а по субботам — цепочку full + diff + logs. Звучит бюрократично, но через неделю LDF вернулся к скромным 30 ГБ, а админ наконец выдохнул.

Ошибки пользователей, что превращаются в проблемы SQL

Пользовательская безобидность иногда добивает сервер быстрее любой атаки. Например, массовое удаление помеченных документов в час пик. 1С послушно запускает транзакцию, SQL Server фиксирует каждое изменение, а индекс кустится. План обслуживания ночью должен вылечить последствия, и именно поэтому регламентное обслуживание SQL Server для 1С — не прихоть, а обязанность.

Другая классика: менеджер загружает через универсальный обработчик прайс на миллион строк. Фоновое задание 1С пишет в таблицу пачками, статистика тут же устаревает, параллельно бухгалтер запускает отчёт по остаткам — получаем блокировки CXPACKET, CXCONSUMER, запрос упирается в tempdb. Снаружи всё называется коротко: “почему тормозит 1С на SQL?”. Внутри рецепт тот же: актуальная статистика плюс размазанный во времени импорт, чтобы регламентные работы успевали справляться.

Мини-чек-лист регламента для 1С на SQL

1. Full backup — ежедневно, c контролем времени выполнения.
2. Log backup — каждые 15-30 минут при режиме FULL.
3. CHECKDB — раз в неделю на live, ежедневно на реплике или после восстановления копии.
4. UPDATE STATISTICS с опцией FULLSCAN для крупных таблиц — каждый день.
5. REORGANIZE индексов при фрагментации 10-30 %; REBUILD (онлайн, если позволяет редакция) — выше 30 %.
6. Очистка и усечение журнала — после успешного log backup.
7. Мониторинг свободного места в tempdb и на дисках — каждые 2-4 часа скриптом-агентом.

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

Когда пора бить тревогу

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

1. Дельта времени отклика > 30 %. Если отчёт вчера шёл 5 минут, а сегодня 7 — сигнал.
2. Рост tempdb больше 25 % за сутки. Значит, пошли тяжёлые сканы или сортировки.
3. LDF вырос вдвое за день. Либо массовые операции, либо застрял бэкап лога.
4. Индекс с фрагментацией 50 %+ хотя бы в одной критичной таблице. Практика показывает, что дальше будет лавина.

Завёл себе привычку: утром открываю отчёт ожиданий и дашборд пространства, пробегаю глазами цифры. Три минуты — и я знаю, живём ли мы спокойно, или вечером придётся задержаться.

Два слова про автоматизацию

Ручные скрипты хороши для старта, но взрослый ландшафт требует политик. SQL Agent, PowerShell, даже Policy-Based Management — всё годится, лишь бы вычеркнуть человеческий фактор. Я сторонник простого: один central management server, один шаблон maintenance plan, один git-репозиторий для скриптов. Тогда смена версии 1С, патч платформы или перид ОС не ломают регламент.

Кстати, не бойтесь автоматизировать уведомления. Пусть в почту падает не “всё прошло ок”, а только исключения. Шум уведомлений быстро приучает игнорировать их, а мы же строим систему, где любое отклонение — редкость, а значит требует внимания.

Финальный штрих

Обслуживание SQL для 1С — это цена за спокойный сон: небольшая, но обязательная. Чёткий регламент превращает неожиданные тормоза в прогнозируемые окна работ, а панические звонки пользователей — в редкие созвоны “для галочки”. В итоге выигрывают все: бизнес не теряет время, айти не тушит пожары, я — меньше герой, но больше консультант.

А как у вас организовано обслуживание базы 1С на SQL Server? Делитесь наболевшим в комментариях — интересно, какие находки работают у коллег.