Инструмент диагностики · 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
Читаете вердикты
Готовый отчёт: по каждому пункту плашка норма / внимание / чинить и что именно поменять. Без ручного перебора сорока параметров.
Özünüz həll edə bilmirsiniz? Yazın, birlikdə baxaq
1C-in yavaşlamasının əsl səbəbini tapır və onun işini necə sürətləndirməyi müəyyən edirik - təxminlə yox, texnoloji jurnal və sorğu planları ilə. Sənədlərin keçirilməsini, hesabatları və mübadilələri dəfələrlə sürətləndiririk. Qazaxıstan və MDB üzrə uzaqdan.
- Qiyməti
- 150 000 ₸-dənlayihə üçün; vergilərsiz; pulsuz auditdən sonra sabitlənir
- "ağır" əməliyyatlar üzrə tipik nəticə
- saatlar → dəqiqələr
Mövzu üzrə təhlillər
Регламентное обслуживание SQL Server под 1С: статистика, индексы и три побочки, о которых забывают
Запросы, которые вчера летали, сегодня выполняются минутами - при том, что данных прибавилось немного, а железо то же. Обычно это не "1С кривая", а отсутствие регламентного обслуживания: оптимизатор СУБД строит планы по устаревшей статистике. Разбираем, что и как часто обслуживать, почему статистика важнее фрагментации, чем опасно ночное перестроение всех индексов и что "Тестирование и исправление" 1С не чинит в принципе.
Уникальный индекс в PostgreSQL пропускает дубли с NULL: найти, посчитать, починить
Методика для служебных таблиц рядом с базой 1С: один запрос к каталогу PostgreSQL находит все уникальные ключи с необязательными колонками, второй считает, какая доля строк идёт мимо защиты. Дальше ремонт по версиям: NULLS NOT DISTINCT с 15-й, частичные индексы до неё, и проверка повтором в транзакции с откатом. Все запросы прогнаны на PostgreSQL 17.
Перенос базы 1С с PostgreSQL на MS SQL: смещение дат, индексы и приёмка
Справочник к переезду базы 1С с PostgreSQL на MS SQL Server через ibcmd infobase replicate: какое смещение дат ставить и как узнать текущее, какие ключи индексов шире 900 байт создадутся молча и при чём тут версия SQL Server, чем принимать перенос вместо подсчёта строк. С регламентом по этапам и замерами на трёх базах.
Дедлок 1205 при проведении, а движения не пересекаются: что делать
Проведение падает с 1205, наборы записей по разным регистраторам не пересекаются ни одним ключом, диагностика по таблице движений возвращает пустоту. Это отдельный класс отказов, он живёт на таблице итогов, и лечится не тем, чем лечатся два соседних класса. Определитель по графу, три запроса проверки на своей базе, разбор пяти вариантов лечения с ценой каждого и список того, что в этом случае не поможет.
Tez-tez verilən suallar
Обработка подключается к 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 и новее, управляемое приложение, любая конфигурация - к прикладным объектам обработка не обращается. Есть вариант и для обычных форм (толстый клиент).
1C sisteminiz üçün pulsuz ekspress-audit
1-2 gün ərzində bazanıza baxıb, məhsuldarlığın harada itdiyini tapacağıq və nə etmək lazım olduğunu deyəcəyik. Öhdəliksiz.
Tapşırığı müzakirə edək
Ən sürətlisi WhatsApp: tapşırıq barədə bir-iki sətir yazın, iş günü ərzində cavab verəcəyik.