Администрирование информационных баз системы 1С:Предприятие часто сталкивается с ситуациями, когда требуется изменить архитектуру хранения данных. Одной из таких задач является конвертация распределенной информационной базы (РИБ) в обычную центральную базу. Это необходимо при отказе от схемы работы с узлами, консолидации данных или при переносе базы на новый сервер без сохранения структуры распределения.
Процесс снятия флага распределенности является необратимым и требует тщательной подготовки. Ошибки на этапе выполнения могут привести к потере части данных или полной неработоспособности конфигурации. Система 1С:Предприятие хранит служебную информацию о распределении в специальных таблицах, которые необходимо корректно обработать перед изменением статуса базы.
В данной инструкции мы рассмотрим поэтапный алгоритм действий, который позволит безопасно удалить признак распределенной базы. Мы затронем вопросы настройки прав доступа, работы с таблицей регистрации изменений и особенности отключения механизма RLS. Следование этим шагам минимизирует риски возникновения критических ошибок в будущем.
Подготовка резервной копии и проверка целостности
Перед началом любых манипуляций с архитектурой базы данных критически важно создать полную резервную копию. Это правило является аксиомой для любого системного администратора 1С. Если в процессе снятия признака распределенности произойдет сбой транзакции или повреждение метаданных, наличие свежего бэкапа позволит восстановить работоспособность системы без потери бизнес-данных.
Рекомендуется использовать штатные средства платформы или инструменты сервера SQL для создания дампа. После создания копии необходимо выполнить проверку целостности информационной базы. Это действие позволит выявить возможные логические ошибки, которые могли накопиться в период работы в режиме распределенной базы.
⚠️ Внимание: Никогда не начинайте процедуру конвертации РИБ в обычную базу без предварительного тестирования на копии. Прямое изменение флагов на продуктивной базе в рабочее время может заблокировать доступ всем пользователям на неопределенный срок.
Убедитесь, что все пользователи завершили сеансы работы с базой. Наличие активных подключений может привести к блокировке таблиц и невозможности выполнения административных операций. Также стоит проверить журнал регистрации на наличие ошибок синхронизации, которые могли остаться с предыдущих сеансов обмена данными между узлами.
☑️ Готовность к конвертации РИБ
Анализ текущей схемы распределения данных
Прежде чем приступать к техническим действиям, необходимо понять текущую топологию вашей распределенной базы. В режиме предприятия или в конфигураторе можно просмотреть список подключенных узлов. Это поможет оценить объем данных, которые потенциально могут быть утеряны или требуют предварительной выгрузки в центральный узел.
Особое внимание следует уделить настройкам предопределенных элементов данных. В распределенной базе часто используются механизмы разделения данных по организациям или складам. При снятии признака распределенности эти ограничения должны быть корректно сняты, чтобы данные стали доступны в полном объеме для всех пользователей центральной базы.
Проверьте настройки правил обмена данными. Если между узлами настроена сложная логика фильтрации или преобразования данных, эти правила станут неактуальными после конвертации. Однако их наличие в метаданных может конфликтовать с новым режимом работы, поэтому их анализ необходим для планирования чистки конфигурации.
| Параметр анализа | Значение для РИБ | Требуемое действие |
|---|---|---|
| Режим работы | Распределенная ИБ | Конвертация в обычную |
| Доступ к данным | Ограничен (RLS) | Полный доступ |
| Таблица изменений | Активна и заполняется | Очистка и отключение |
| Пользователи | Локальные права узлов | Унификация прав |
Важно задокументировать текущее состояние перед изменениями. Сделайте скриншоты списка узлов и настроек синхронизации. Это пригодится в случае, если потребуется откатить изменения или понять, какие именно каналы обмена данными были активны до момента конвертации.
Используйте отчет"Анализ информационной базы" в режиме администратора для получения сводной статистики по узлам распределенной базы перед началом работ.
Отключение механизмов синхронизации и RLS
Ключевым этапом является отключение механизмов, обеспечивающих работу распределенной базы. В первую очередь это касается системы разграничения прав доступа на уровне записей (RLS). В распределенной базе данные часто фильтруются автоматически в зависимости от того, к какому узлу принадлежит пользователь.
Для снятия ограничений необходимо войти в систему под пользователем с полными правами администратора. Перейдите в раздел администрирования и найдите настройки распределенной информационной базы. Здесь потребуется явно указать системе, что база более не является распределенной. Интерфейс может отличаться в зависимости от версии платформы 1С:Предприятие 8.3.
Если автоматическое отключение через интерфейс недоступно или выдает ошибки, может потребоваться ручное вмешательство через консоль команд или прямое выполнение запросов к базе данных (только для опытных специалистов). Основная задача — убрать флаг, который заставляет систему проверять таблицу регистрации изменений при каждой операции записи.
⚠️ Внимание: Интерфейс настроек может меняться в разных релизах платформы 1С. Если вы не находите нужных переключателей, сверьтесь с документацией к вашей конкретной версии конфигурации или обратитесь к официальным источникам информации.
После отключения механизмов синхронизации система перестанет отслеживать изменения для передачи на другие узлы. Это значительно снизит нагрузку на сервер баз данных, так как исчезнет необходимость вести журнал изменений для каждого объекта. Однако старые записи в журнале никуда не денутся автоматически.
Что такое RLS в контексте РИБ?
RLS (Row Level Security) в распределенных базах 1С используется для автоматического отсечения данных, не относящихся к текущему узлу. При снятии признака распределенности эти ограничения должны быть удалены, иначе пользователи не увидят полную картину данных.
Очистка таблицы регистрации изменений
Таблица регистрации изменений — это технический объект, который хранит историю всех модификаций данных для последующей синхронизации. После того как вы сняли признак распределенной базы, эта таблица становится бесполезным балластом, занимающим место и замедляющим работу системы.
Очистку следует производить крайне осторожно. Стандартный механизм очистки доступен через обработку обслуживания распределенной информационной базы. Запустите эту обработку в монопольном режиме. Выберите опцию очистки журнала регистрации изменений.
Обработка.ОчисткаРегистрацииИзменений.Создать.ВыполнитьОчистку;В некоторых случаях, если таблица слишком велика или повреждена, стандартная обработка может завершиться ошибкой. Тогда может потребоваться прямое удаление записей из таблицы _InfoRgРегистрацияИзменений (имя может отличаться в разных конфигурациях). Делайте это только если уверены в своих действиях и имеете свежую резервную копию.
После очистки проверьте размер базы данных. Обычно он существенно уменьшается. Также рекомендуется выполнить реиндексацию таблиц базы данных на стороне СУБД (MS SQL, PostgreSQL), чтобы оптимизировать физическое хранение данных после удаления большого объема записей.
Очистка таблицы регистрации изменений обязательна, так как оставшиеся в ней данные могут вызывать ошибки при попытке системы обратиться к несуществующим узлам синхронизации.
Настройка прав доступа после конвертации
После снятия признака распределенности структура прав доступа может потребовать пересмотра. В режиме РИБ права часто наследуются или ограничиваются настройками узла. В обычной базе необходимо явно прописать права для всех пользователей, чтобы они имели доступ ко всему массиву данных.
Проверьте роли пользователей. Убедитесь, что ни одна из ролей не содержит ограничений, специфичных для распределенной работы. Особое внимание уделите правам на чтение и запись регистров сведений и документов, которые ранее могли быть разделены между филиалами.
- 🔐 Проверьте профиль группы доступа"Администраторы" — он должен иметь полные права без ограничений RLS.
- 👥 Перепроверьте права обычных пользователей — убедитесь, что они видят документы всех организаций, а не только"своей".
- 🔄 Удалите или деактивируйте роли, созданные специально для обмена данными между узлами.
Если в базе использовались специфические настройки видимости данных, связанные с географическим распределением, их необходимо убрать. Пользователи теперь работают в едином информационном пространстве, и искусственные барьеры должны быть демонтированы.
Тестирование работоспособности системы
Финальным этапом является комплексное тестирование. Не спешите открывать доступ всем пользователям сразу. Проведите серию проверочных операций ключевыми сотрудниками. Проверьте проведение документов, формирование отчетов и выполнение регламентных операций.
Обратите внимание на скорость работы системы. Отсутствие необходимости вести журнал изменений для синхронизации должно положительно сказаться на производительности операций записи. Если вы заметили тормоза, проверьте логи сервера 1С и СУБД на наличие ошибок блокировок.
Попробуйте создать новый документ и провести его. Убедитесь, что он корректно отражается во всех отчетах, включая те, которые ранее могли фильтроваться по узлам. Проверьте работу механизмов нумерации документов, так как в распределенных базах они часто имеют префиксы узлов, которые теперь могут быть не нужны.
⚠️ Внимание: В первые дни работы после конвертации внимательно следите за журналом регистрации. Возможны скрытые ошибки в коде конфигурации, которые ссылаются на объекты распределенной базы, которые теперь отсутствуют.
Если в процессе тестирования выявляются проблемы с доступом к данным, проверьте настройки RLS еще раз. Иногда старые настройки сохраняются в метаданных и продолжают действовать, даже если флаг распределенности снят. В таком случае может потребоваться перепроведение документов или перерасчет итогов регистров.
Запустите тестовый сценарий"Закрытие месяца" или аналогичную тяжелую операцию на тестовом пользователе, чтобы убедиться в стабильности работы регистров накопления в новом режиме.
Часто задаваемые вопросы
Можно ли снять признак распределенной базы, не удаляя данные?
Да, данные сохраняются. Процедура снятия признака меняет только режим работы системы и отключает механизмы синхронизации. Однако данные, которые ранее были отфильтрованы или не выгружены с удаленных узлов, могут быть недоступны, если они физически отсутствовали в центральной базе до конвертации.
Что произойдет, если я просто удалю узлы из списка распределенной базы?
Простое удаление узлов из интерфейса не снимает системный флаг распределенности. База продолжит работать в режиме РИБ, пытаясь вести журнал изменений, но не будет знать, куда их отправлять. Это приведет к разрастанию таблицы регистрации и возможным ошибкам. Необходимо именно выполнить процедуру конвертации.
Нужно ли переустанавливать платформу 1С после снятия признака?
Нет, переустановка платформы не требуется. Все изменения происходят на уровне конкретной информационной базы и ее конфигурации. Клиентские места и сервер также не требуют переустановки, достаточно перезапустить сервисы 1С:Предприятия для применения изменений.
Как быть с префиксами номеров документов?
После снятия признака распределенности префиксы узлов обычно становятся неактуальными. Рекомендуется настроить нумерацию документов заново в свойствах конфигурации или метаданных, убрав обязательное требование префикса, чтобы нумерация стала сквозной и единой для всей базы.
Можно ли вернуть базу в режим распределенной после снятия флага?
Технически это возможно через создание новой распределенной базы и выгрузку/загрузку данных, но простым переключением галочки вернуть статус нельзя. Процедура является односторонней для текущей сессии работы с базой без использования специальных инструментов миграции.