К статье
Практический материал

Администрирование · 13 мин

Как подтянуть базу 1С: пошаговое руководство для администратора

Практическое руководство, как подтянуть базу 1С: тестирование и исправление, обновление конфигурации, очистка данных, сжатие таблиц и проверка результата без потери информации.

Фраза «подтянуть базу 1С» на практике означает комплекс работ: привести конфигурацию к актуальному релизу, устранить накопившиеся ошибки в данных, уменьшить объём базы и ускорить её работу. Симптомы, при которых пора этим заняться, обычно одни и те же: документы проводятся медленно, отчёты формируются минутами, при входе появляются сообщения об ошибках, а копия базы занимает неоправданно много места.

Главное правило любых работ с базой — сначала резервная копия, потом всё остальное. Большинство операций из этой статьи необратимы: тестирование и исправление может удалить «битые» объекты, очистка данных стирает историю, а неудачное обновление способно остановить работу всей компании на день. Поэтому каждый раздел ниже начинается с проверки условий и заканчивается способом убедиться, что результат достигнут.

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

Что значит «подтянуть базу» и когда это нужно

Под «подтягиванием» обычно понимают четыре разные задачи, и важно сразу определить, какая из них ваша. Первая — обновление конфигурации и платформы, когда база отстала от актуальных релизов и перестала принимать отчётность или обмены. Вторая — исправление ошибок данных: битые ссылки, дубли элементов, ошибки при проведении. Третья — сокращение объёма: база разрослась за годы работы и тормозит. Четвёртая — ускорение: индексы, регламентные задания, настройки СУБД.

Часто проблемы комбинированные: старая база, которая три года не обновлялась, почти всегда одновременно перегружена мусорными данными и содержит ошибки. В этом случае работы выполняют в строгом порядке: сначала копия, затем тестирование и исправление, потом обновление, затем чистка и только в конце — оптимизация скорости. Нарушение порядка (например, обновление базы с неисправленными ошибками) заметно повышает риск сбоя.

ПризнакМедленное проведение документов

Проверьте объём базы и дату последнего тестирования и исправления

ПризнакОшибки при входе или обмене

Проверьте актуальность релиза конфигурации и платформы

ПризнакКопия базы занимает десятки гигабайт

Проверьте объём регистров сведений, истории обменов и помеченных объектов

Признак«Объект не найден» в отчётах

Признак битых ссылок — нужно тестирование и исправление

Подготовка: резервная копия и проверка окружения

Перед любыми работами сделайте полную копию базы и убедитесь, что она восстанавливается. Для файловой базы достаточно выгрузки через конфигуратор («Администрирование — Выгрузить информационную базу») либо копирования файла 1Cv8.1CD при закрытых сеансах. Для клиент-серверной базы делайте выгрузку средствами СУБД (например, pg_dump для PostgreSQL или backup для MS SQL) — выгрузка в dt на больших базах идёт долго и не всегда подходит для отката.

Проверьте копию на восстановление на отдельном компьютере или в тестовой базе. Архив, который не разворачивается, — это отсутствие архива. Заодно зафиксируйте текущие версии: релиз конфигурации (раздел «О программе»), версию платформы и размер базы. Эти цифры понадобятся, чтобы сравнить состояние «до» и «после» и доказать результат работ.

Убедитесь, что во время работ в базе никто не работает: завершите сеансы пользователей, отключите регламентные задания и обмены. Практически все операции — тестирование, обновление, удаление помеченных объектов — требуют монопольного доступа. Если база клиент-серверная, заблокируйте её в консоли кластера или через параметр блокировки сеансов.

Обновление конфигурации и платформы

Если база отстала от актуального релиза на несколько версий, обновляйте последовательно через промежуточные релизы, указанные в документации поставщика. Для типовых конфигураций проще всего использовать обновление через интернет-поддержку (в разделе «Администрирование — Обновление версии программы») — механизм сам подберёт цепочку релизов. При ручном обновлении через конфигуратор («Конфигурация — Поддержка — Обновить конфигурацию») внимательно читайте файл поставки: там указано, с каких релизов допустимо обновление.

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

Обновление платформы

Платформу обновляйте до версии, рекомендованной для вашего релиза конфигурации — она указана в сопроводительной документации. Установка более новой платформы «с запасом» иногда приводит к несовместимости. После смены платформы на клиент-серверных базах проверьте версии на всех серверах кластера и тонких клиентах: смешение версий вызывает ошибки соединения.

Порядок обновления типовой конфигурации
  1. 1
    Сделайте и проверьте резервную копию базы
  2. 2
    Завершите сеансы пользователей и отключите регламентные задания
  3. 3
    Запустите обновление через интернет-поддержку или конфигуратор
  4. 4
    Дождитесь завершения обновления конфигурации базы данных
  5. 5
    Запустите режим предприятия и дождитесь отработки отложенных обработчиков
  6. 6
    Проверьте ключевые операции: проведение документа, формирование отчёта, обмен
  7. 7
    Включите пользователей и регламентные задания

Тестирование и исправление базы

Штатный инструмент «Тестирование и исправление» (в конфигураторе: «Администрирование — Тестирование и исправление») устраняет физические и логические ошибки: битые страницы файловой базы, битые ссылки, ошибки индексов. Запускайте его только в монопольном режиме и только после резервной копии. Для файловой базы перед этим полезно выполнить проверку физической целостности утилитой chdbfl.exe из каталога платформы — она ловит повреждения, которые тестирование не видит.

Основные режимы: реиндексация таблиц, проверка логической целостности, проверка ссылочной целостности, пересчёт итогов, сжатие таблиц. На первом проходе включите проверку логической и ссылочной целостности в режиме «только тестирование, без исправления» и изучите отчёт. Если ошибок много и они касаются реальных документов, сначала разберитесь вручную: автоматическое исправление при потере ссылок может удалить объекты или очистить ссылки, что не всегда желательно.

Пересчёт итогов по регистрам запускайте, если отчёты показывают расхождения между оборотами и остатками. Реиндексацию имеет смысл выполнять периодически на больших базах — она ускоряет поиск, но на время работы блокирует базу. Для клиент-серверных баз аналогичные операции (перестроение индексов, обновление статистики) выполняются средствами СУБД и планируются в нерабочее время.

Очистка базы от лишних данных

Самый быстрый и безопасный шаг — удаление помеченных объектов («Администрирование — Обслуживание — Удаление помеченных объектов»). За годы работы в базе копятся тысячи помеченных документов и элементов справочников, которые занимают место и замедляют выборки. Удаление выполняется в монопольном режиме; если объект используется в других документах, платформа покажет список препятствий — их нужно разобрать вручную.

Дальше смотрите на типовые «пожиратели» объёма: регистры сведений с историей версирования и очередями обменов, журналы регистрации за несколько лет, протоколы обменов данными, вложения писем и файлы, хранящиеся в базе. В типовых конфигурациях есть штатные обработки очистки (например, очистка устаревших данных обменов и версий объектов). Журнал регистрации сокращается через конфигуратор: «Администрирование — Журнал регистрации — Сократить».

Свёртка базы

Если нужно радикально уменьшить объём и ускорить работу, используйте свёртку: на дату свёртки формируются документы ввода остатков, а все документы раньше этой даты удаляются. Для типовых конфигураций существуют официальные обработки свёртки. Это серьёзная операция: теряется возможность строить отчёты за прошлые периоды в этой базе, поэтому старую копию сохраняют как архив для справок. Свёртку всегда сначала выполняют на копии и проверяют сходимость остатков по всем разделам учёта.

Типичные ошибки при чистке базы
01
Удаление помеченных объектов без копии — восстановить ошибочно удалённый документ будет нечем
02
Свёртка без проверки остатков на копии — расхождения обнаруживаются, когда откат уже невозможен
03
Удаление истории обменов до выяснения причин ошибок синхронизации — теряется диагностическая информация
04
Сокращение журнала регистрации перед аудитом — пропадают следы действий пользователей

Сжатие и оптимизация для ускорения работы

После удаления данных файловая база физически не уменьшается сама — нужно сжатие таблиц. Оно выполняется в том же окне «Тестирование и исправление» (режим «Сжатие таблиц информационной базы») либо через выгрузку и загрузку базы в dt: загруженная заново база обычно заметно компактнее. На клиент-серверной базе сжатие делают средствами СУБД: shrink для MS SQL (с осторожностью, с последующим перестроением индексов), VACUUM FULL или pg_repack для PostgreSQL.

Для ускорения работы проверьте регламентные задания: пересчёт итогов, обновление индексов полнотекстового поиска, очистка устаревших данных должны выполняться по расписанию в нерабочее время. На клиент-серверных базах убедитесь, что СУБД получает достаточно памяти, а обновление статистики и перестроение индексов настроены как регулярные задания обслуживания. Часто именно устаревшая статистика — причина внезапного «торможения» запросов после роста базы.

Если после всех мер база всё равно работает медленно, проблема обычно не в данных, а в инфраструктуре: слабый дисковый массив, файловая база на сетевом диске при большом числе пользователей, недостаток оперативной памяти на сервере. Файловый режим комфортно работает при небольшом числе одновременных пользователей; при росте нагрузки правильное решение — переход на клиент-серверную архитектуру, а не дальнейшая «чистка».

Маршрут решения

Как выбрать действие

База тормозит, но объём небольшой и ошибок нетПроверьте индексы, статистику СУБД и оборудование — чистка данных не поможет
База выросла за счёт старых периодов, отчёты по ним не нужныВыполните свёртку на копии, проверьте остатки, затем примените к рабочей базе
Ошибки «объект не найден» в документахЗапустите тестирование и исправление с проверкой ссылочной целостности
Конфигурация отстала на несколько релизовОбновляйте последовательно через промежуточные релизы, не прыгая через версии

Проверка результата после всех работ

Финальная проверка должна отвечать на три вопроса: данные не потеряны, ошибки устранены, скорость выросла. Сверьте контрольные показатели до и после: остатки по основным счетам или складам на текущую дату, количество документов за последний закрытый период, результат ключевого отчёта (например, ОСВ или отчёт по продажам). Цифры до и после должны совпадать — за исключением осознанно удалённых данных при свёртке.

Замерьте время типовых операций до начала работ и после: проведение крупного документа, формирование основного отчёта, вход в базу. Без замеров «до» оценить эффект невозможно. Наконец, повторно запустите тестирование в режиме «только проверка» — отчёт должен быть чистым. После этого сделайте финальную резервную копию уже «подтянутой» базы и настройте регулярное расписание обслуживания, чтобы не возвращаться к авральной чистке.

Контрольные точки

Как проверить результат

Остатки по счетам и складам до и после
Норма

Показатели совпадают с контрольными значениями

Тревожный признак

Расхождения без объяснимой причины (свёртка)

Повторное тестирование в режиме проверки
Норма

Отчёт не содержит ошибок

Тревожный признак

Остались битые ссылки или ошибки логической целостности

Время проведения документа и формирования отчёта
Норма

Заметно быстрее, чем до работ

Тревожный признак

Скорость не изменилась — проблема в инфраструктуре

Работа пользователей в штатном режиме
Норма

Нет жалоб на ошибки и зависания в течение нескольких дней

Тревожный признак

Появились новые ошибки — анализируйте журнал регистрации

Частые вопросы

Можно ли подтянуть базу 1С без конфигуратора?

Частично да: обновление типовой конфигурации через интернет-поддержку, удаление помеченных объектов и штатные обработки очистки выполняются из режима предприятия. Но тестирование и исправление, сжатие таблиц файловой базы и сокращение журнала регистрации доступны только через конфигуратор, поэтому для полноценного обслуживания он нужен.

Как часто нужно обслуживать базу?

Разумный минимум: удаление помеченных объектов и контроль объёма — раз в месяц, реиндексация и проверка целостности — раз в квартал или при признаках замедления, обновление конфигурации — по мере выхода критичных релизов (отчётность, обмены). Для клиент-серверных баз обслуживание СУБД (индексы, статистика) настраивается как еженедельные регламентные задания.

Что делать, если обновление зависло на отложенных обработчиках?

Не прерывайте процесс сразу: на больших базах отдельные обработчики могут работать часами. Проверьте журнал регистрации и прогресс в разделе «Результаты обновления программы». Если процесс явно остановился из-за ошибки, зафиксируйте текст ошибки, восстановите базу из копии и разбирайте причину на тестовой базе — повторный запуск на «полуобновлённой» базе рискован.

Тестирование и исправление удалило часть документов. Как вернуть?

Автоматически — никак, операция необратима. Восстановите базу из резервной копии, сделанной перед запуском, и повторите проверку в режиме «только тестирование», чтобы увидеть список проблемных объектов и обработать их вручную. Именно поэтому исправление без предварительной копии запускать нельзя.

Почему база не уменьшилась после удаления старых документов?

Удалённые данные освобождают место внутри файла базы, но сам файл не сжимается автоматически. Для файловой базы выполните сжатие таблиц в «Тестировании и исправлении» или перезалейте базу через выгрузку-загрузку dt. Для клиент-серверной — используйте средства сжатия вашей СУБД.

Когда вместо чистки нужно переходить на клиент-серверный вариант?

Когда база обслужена, объём и ошибки в норме, но работа всё равно медленная из-за числа одновременных пользователей и нагрузки. Файловый режим имеет естественный предел по конкурентному доступу; если он достигнут, дальнейшая оптимизация данных эффекта не даст — нужен переход на СУБД и настройка сервера.

Итог

Что важно запомнить

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