Инструмент диагностики · 10 SM · демо-отчёт
Чек-ап СУБД под 1С: 40+ проверок с вердиктом по каждой
Инструмент отвечает на вопрос, который обычно решают на глаз: правильно ли база 1С стоит на SQL Server. Он снимает настройки платформы и сервера СУБД и по каждому пункту выдаёт не сырую цифру, а вердикт - норма, внимание или чинить, и почему. Ниже показываем, как выглядит его отчёт на боевом сервере.
Полная обработка (40+ проверок, генерация скриптов, разбор вывода) публикуется в каталоге Инфостарта - 10 SM. Эта страница показывает, как выглядит её отчёт; сам инструмент со всеми проверками забираете там.
Статей про настройку MS SQL под 1С полно: MAXDOP в единицу, порог параллелизма поднять, tempdb разбить на файлы. Проблема в другом: чтобы проверить это у себя, нужен доступ к SSMS и понимание, какие цифры считать нормальными. У рядового 1С-ника нет ни того, ни другого, а у того, у кого есть, обычно нет времени обходить сорок пунктов руками.
Мы собрали обработку, которая делает ровно то, чего статья сделать не может: снимает показатели и интерпретирует их вместо читателя. Часть проверок она снимает сама из 1С (доступ к серверу СУБД для этого не нужен), часть - через готовый скрипт, который администратор один раз выполняет в SSMS и вставляет результат обратно. Обработка к серверу баз данных не подключается и ничего в нём не меняет: только читает системные представления.
Что проверяет
Параллелизм: MAXDOP и порог стоимости
Два параметра, из-за которых кассы встают на ровном месте. Значения по умолчанию (MAXDOP 0, порог 5) для OLTP-нагрузки 1С почти всегда неверны и дают CXPACKET-ожидания. Обработка сверяет их с рекомендованными и объясняет, что поменять.
Журнал транзакций и модель восстановления
Full без бэкапа лога - классическая причина, по которой лог разрастается до размеров тома. Проверка показывает модель, размер и процент заполнения лога и что именно держит его усечение.
tempdb, статистика, RCSI, авто-сжатие
Число файлов tempdb, актуальность статистики, версионирование строк (RCSI), включённое авто-сжатие и авто-закрытие - настройки, которые по отдельности незаметны, а вместе тормозят всю базу.
Со стороны 1С - без доступа к СУБД
Режим блокировок и совместимости, полнотекстовый индекс, регламентные и упавшие фоновые задания, таймауты и взаимоблокировки из журнала регистрации, актуальность итогов регистров. Это обработка снимает сама, скрипт для этого не нужен.
Как выглядит отчёт: прогон на боевом сервере
Реальный прогон 05.08.2026 на боевом SQL Server розничной сети, данные обезличены. На сервере около 580 сеансов, прогон шёл по двум базам 1С: боевой и малонагруженной. Настройки сервера у них общие, а в строках, где значения баз расходятся, база названа. Строки взяты из полной диагностики настроек и из отдельных скриптов библиотеки, значения и вердикты в них те, что выдала обработка.
| Показатель | Значение | Как надо | Вердикт | Что это значит |
|---|---|---|---|---|
| Устаревшая статистика | 21 статистика старше 90 дней, самой старой 97 дней | 0 старше 30 дней | чинить | Считаются таблицы от 100 тысяч строк. Автообновление статистики при этом включено, а планы по этим таблицам оптимизатор всё равно строит по картине трёхмесячной давности. Лечится регулярным UPDATE STATISTICS по горячим таблицам |
| Запросы со сканами | 598 запросов читают больше миллиона страниц за вызов | 0 | чинить | Сканы почти всегда лечатся индексом или переписанным отбором. Рядом в том же скрипте топ по процессору: самый дорогой запрос сервера набрал 781 386 секунд за 104 760 выполнений, по 7,5 секунды на вызов |
| Журнал малонагруженной базы | 11 464 МБ при 15 624 МБ данных, 73 % | до 25 % от данных | чинить | Процент считается от размера данных. Обработка называет две обычные причины: полную модель без копий журнала или разовую тяжёлую операцию, после которой файл не ужали. Копии журнала у этой базы идут, и журнал ничем не удерживается (NOTHING), так что остаётся вторая |
| Уровень совместимости боевой базы | 100 при SQL Server 2022 | уровень версии сервера | внимание | Уровень 100 соответствует SQL Server 2008, новая модель оценки кардинальности для базы не включается. Поднимать его стоит только с проверкой планов тяжёлых запросов |
| Максимум памяти SQL Server | 250 000 МБ из 261 789 МБ, 95 % | 70-90 % на выделенном сервере | внимание | Операционной системе почти не остаётся запаса, под нагрузкой может начаться выгрузка на диск |
| MAXDOP | 4 при 64 ядрах | 1-8 | норма | На ожидания параллелизма (CXCONSUMER, CXSYNC_PORT, CXPACKET) при этом приходится 81 % ожиданий сервера без учёта фоновых. Настройка уже в рабочем диапазоне, и крутить её обработка не советует: искать надо тяжёлые запросы в топе по процессору |
| Порог стоимости параллелизма | 100 | 50-150 | норма | Параллельный план оптимизатор рассматривает только для запросов с оценкой стоимости выше 100 |
| Журнал боевой базы | 140 288 МБ, 4 % от данных, занят на 2 % | до 25 % от данных | норма | Модель FULL, в log_reuse_wait_desc значение LOG_BACKUP: журнал ждёт очередной копии. При заполнении 2 % это обычное состояние полной модели |
| Файлы данных tempdb | 8 | 4-8 | норма | Когда логических процессоров больше восьми, Microsoft советует начинать с восьми файлов и добавлять по четыре, только если конкуренция за выделение страниц не уходит |
| Авто-сжатие базы (Auto Shrink) | выключено у обеих баз | выключено | норма | |
| READ_COMMITTED_SNAPSHOT боевой базы | выключен | осознанный выбор | инфо | Версионного чтения нет, читатели и писатели ждут друг друга на одних данных. Включение обычно снимает подвисания отчётов в часы пик, но нагружает tempdb, поэтому решают вместе с администратором СУБД |
Разбор результата
Самая поучительная строка тут про MAXDOP. На параллелизм уходит 81 % ожиданий сервера, и любой чек-лист на этом месте советует крутить MAXDOP. Но он уже равен 4, порог стоит на 100, обработка ставит обоим норму и отправляет к тяжёлым запросам: со сканами их нашлось 598. Вторая показательная пара строк про журнал. У малонагруженной базы 73 % посчитаны от размера данных, копии журнала у неё идут, так что модель восстановления менять незачем. У боевой базы журнал ждёт очередной копии (LOG_BACKUP) и занят на 2 %, это тоже норма.
Как работает
- 01
Открываете в своей базе
Файл → Открыть → .epf. Часть проверок обработка снимает сразу, доступ к серверу СУБД для них не нужен.
- 02
Копируете скрипт в SSMS
Для показателей со стороны СУБД обработка печатает готовый диагностический скрипт. Он только читает системные представления, ничего не меняет.
- 03
Вставляете результат обратно
Вывод скрипта возвращаете в поле обработки. Она разбирает его и сопоставляет с нормами для 1С.
- 04
Читаете вердикты
Готовый отчёт: по каждому пункту плашка норма / внимание / чинить и что именно поменять. Без ручного перебора сорока параметров.
Не получается самим? Напишите, разберёмся
Находим настоящую причину, почему 1С тормозит и как ускорить её работу - по технологическому журналу и планам запросов, а не наугад. Ускоряем проведение документов, отчёты и обмены в разы. Удалённо по всему Казахстану и СНГ.
- Стоимость
- 150 000 - 450 000 ₸ТЗ и оптимизация под ключ, без налогов; доработки сверх плана - единым счётом по факту диагностики
- типичный результат по "тяжёлым" операциям
- часы → минуты
Разборы по теме
База 1С не открывается после обновления конфигурации: порядок действий, когда копии нет
Конфигуратор пишет "При обновлении данных, после последней реструктуризации, произошла критическая ошибка", пользователи в базу не попадают, копии до обновления нет. Разбираем по шагам: что сохранить первым, как по журналу регистрации найти этап, на котором упало, какие действия только добавляют ошибок, когда бросать починку старой базы и как через ibcmd выгрузить .dt из базы, которая не открывается, собрать новую и тихо подменить её в кластере. В конце - задания резервного копирования, после которых такая авария превращается в откат на минуту до обновления.
Регламентное обслуживание SQL Server под 1С: статистика, индексы и три побочки, о которых забывают
Запросы, которые вчера летали, сегодня выполняются минутами - при том, что данных прибавилось немного, а железо то же. Обычно это не "1С кривая", а отсутствие регламентного обслуживания: оптимизатор СУБД строит планы по устаревшей статистике. Разбираем, что и как часто обслуживать, почему статистика важнее фрагментации, чем опасно ночное перестроение всех индексов и что "Тестирование и исправление" 1С не чинит в принципе.
1С висела, серверы перезагрузили: какие следы аварии остались и сколько они живут
После перезагрузки SQL Server и кластера 1С большая часть улик пропадает сразу, остальная через дни. Разбираем по источникам, что где хранится и когда стирается, что успеть сохранить за две минуты до рестарта, как по журналу регистрации доказать, что беда общая для всех баз, как читать события vCenter голым SOAP и что поставить заранее, чтобы следующую аварию было по чему разбирать. Иллюстрация - зависание касс в рознице, где через три недели назвать виновника было уже нечем.
CHECKDB нашёл ошибки в базе 1С: порядок действий до REPAIR и после
CHECKDB советует repair_allow_data_loss и на битый индекс, и на потерянные документы. Разбираем по шагам, что делать в первый час: что сохранить до исправления, как по таблице и номеру индекса понять, что задето в 1С, как перестроить битый индекс без потерь и как получить список пропавших документов, пока REPAIR не удалил их молча. Проверено на копии УТ для Казахстана с испорченными страницами.
Рядом по теме
Чёрный ящик SQL Server под 1С
Чек-ап говорит, что настроено не так, ящик - кто занимал tempdb и держал блокировку в минуту аварии, даже если сервер потом перезагрузили.
Аудит паролей СУБД
Соседняя проверка того же сервера: достаётся ли пароль пользователя SQL из файла кластера 1CV8Clst.lst и не слабый ли он.
Повреждение базы 1С на MS SQL
Если CHECKDB уже нашёл ошибки: какой документ, регистр или индекс задет и что поднимать из бэкапа.
Чек-ап итогов и остатков 1С
Если остатки не бьются с движениями: регистр, позиция и месяц поломки итогов и пересчёт только нужного периода.
Частые вопросы
Обработка подключается к SQL Server?
Нет, к серверу баз данных она не ходит вообще: ни строки подключения, ни COM. Часть проверок снимается прямо из 1С без доступа к СУБД, для остального обработка печатает диагностический скрипт, его выполняет администратор, а результат вставляется обратно и разбирается.
Скрипт падает с ошибкой про конфликт сортировок (collation)?
У ранней версии из статьи это ловилось на UNION, когда сортировка инстанса и базы разные. В обработке блоки сведения строк идут через COLLATE DATABASE_DEFAULT, поэтому конфликта сортировок нет. Свой инстанс можно сверить через SERVERPROPERTY('Collation') и DATABASEPROPERTYEX(DB_NAME(), 'Collation').
Насколько показательны цифры ожиданий и сканов?
Они копятся с последнего перезапуска сервера, поэтому обработка выводит аптайм рядом с ними. Если сервер поднимали меньше суток назад, картину ожиданий она сама помечает как ещё непоказательную - замер стоит повторить через несколько рабочих дней.
Что нужно, чтобы получить полный отчёт?
Со стороны 1С - административные права (чтение журнала регистрации и структуры хранения), без них недоступные проверки честно помечаются как нет данных. Для скриптов на MS SQL нужны VIEW SERVER STATE и VIEW ANY DEFINITION. У файловой базы работает только часть со стороны 1С, про СУБД обработка сообщает сама.
Скрипты не сломаются на старом SQL Server?
Заявленный минимум - SQL Server 2008. Показатели из поздних редакций запрашиваются динамическим SQL под TRY/CATCH: отсутствующая колонка иначе роняет весь пакет на этапе компиляции, а так пропускается только она.
На какой платформе и конфигурации работает?
Платформа 8.3.14 и новее, управляемое приложение, любая конфигурация - к прикладным объектам обработка не обращается. Есть вариант и для обычных форм (толстый клиент).
Бесплатный экспресс-аудит вашей 1С
За 1-2 дня посмотрим вашу базу, найдём, где теряется производительность, и скажем, что с этим делать. Без обязательств.
Обсудим задачу
Быстрее всего в WhatsApp: напишите пару строк о задаче, ответим в течение рабочего дня.