Распределенная информационная база (РИБ) широко применяется в инфраструктуре 1С:Предприятия несмотря на наличие иных, более современных методов доступа. Одно из главных преимуществ РИБ - полная автономность подчиненной базы, а обмен информации с центральной базой происходит при помощи синхронизации. Но есть и минусы, как любая другая информационная база 1С РИБ имеет свойство расти и работать все медленнее и медленнее, особенно на слабых ПК. Поэтому рекомендуется регулярно проводить процедуру свертки, но данный процесс содержит столько подводных камней, что многие шарахаются от нее, как черт от ладана.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Как всегда, начнем с постановки проблемы. В нашем случае будет рассматриваться РИБ по магазину 1С:Розница, как наиболее типичный случай, но механизм синхронизации в современных конфигурациях 1С стандартизован и все сказанное ниже с небольшими поправками можно применить к любой конфигурации.
Классическая конфигурация предполагает, что у нас есть центральная информационная база, чаще всего в клиент-серверном варианте, в которой консолидируется все информация торговой сети. С ней же работают менеджеры в центральном офисе. Для каждого из магазинов создается отдельная РИБ по магазину, которая работает в файловом варианте и располагается на POS-терминале магазина, в роли которого выступает достаточно маломощный компьютер, так популярные моноблоки АТОЛ содержат обычно Intel Celeron J1900.
Это хорошая, зарекомендовавшая себя платформа, но большие объемы данных - это не ее конек. Поэтому по мере работы и роста базы замедление работы становится все более ощутимо и заметно невооруженным глазом. Кассиры начинаются жаловаться на производительность и нужно что-то делать. Для уменьшения размера базы и количества документов в ней у 1С предусмотрен штатный механизм - свертка.
У многих сейчас задергается глаз и появится непреодолимое желание кого-нибудь стукнуть. Их эмоции вполне можно понять, потому что штатный механизм свертки имеет такое количество подводных камней, что, попробовав один раз можно получить негативного опыта на долгое время вперед. Почему? Давайте посмотрим.
Что предлагает нам 1С? С их стороны все просто, заходим в настройки синхронизации узла и меняем дату свертки, система сформирует документ ввода начальных остатков на эту дату, а более ранние документы будут впоследствии удалены из подчиненной информационной базы. На первый взгляд все выглядит неплохо: поменял дату и выполнил синхронизацию.
Предупреждаем - никогда так не делайте! Потому что это верный способ остановить торговую точку на неопределенный период времени без возможности быстро исправить ситуацию. Ну и получить массу сопутствующих проблем в ближайшем будущем.
Почему? Да потому что после свертки 1С зарегистрирует к обмену все документы за сворачиваемый период, в нашем случае их оказалось около 4,5 млн за 1,5 года. Одна только выгрузка такого объема займет более нескольких часов и вам очень повезет, если вы по техническим причинам выгрузить данные все-таки не сможете.
Иначе эта выгрузка попадет на POS-терминал, который начнет старательно ее обрабатывать и удалять из базы старые документы, растянуться этот процесс может очень и очень надолго: часы, десятки часов, сутки. База при этом будет работать, но плохо: с сильными тормозами и регулярными конфликтами блокировок. А дальше становится очень весело.
То, что касса висит, тормозит и в магазине очередь как в мавзолей - это самое малое зло, проблемы кроются глубже. Покупатель оплачивает картой, платеж проходит, но в далее система виснет и вовремя не получает от терминала статус оплаты. Покупатель уже ушел, а чек пробить невозможно, система не увидела оплату и требует ее повторно. Либо увидела оплату, но не смогла пробить чек, посчитала ситуацию аварийной и требует сделать сторно. А покупателя нет, давно ушел. Прибавим сюда крепкое спиртное, которое отдельно списывается через ЕГАИС, маркированную продукцию и т.д. и т.п.
Мы не хотим сгущать краски, но, когда вы поймете масштаб проблемы - на торговой точке воцарится хаос. Мало того, что ничего не работает, так и нарушено все, что можно нарушить и впоследствии всплывет куча проблем с алкоголем и маркированным товаром. И никакие бекапы вас здесь не спасут.
Поэтому, один раз получив такой опыт многие шарахаются не только от сверки, но и от розницы и 1С вообще. И самое смешное, хотя смех тут сквозь слезы, что действовал специалист строго по инструкции к программе, но кого это будет волновать, если предприятие несет вполне ощутимые и измеряемые рублями убытки?
В общем и целом, проблему можно сформулировать так: современные объемы данных и мощности торгового оборудования не позволяют выполнить штатный механизм свертки за приемлемое для бизнеса время. Поэтому мы будем сворачивать базу другим методом, позволяющим не только значительно сократить время свертки и ее влияние на работу торговой точки, но и выполнить ее даже в том случае, если технологического окна все равно будет не хватать.
Подготовка ИБ к свертке
Сразу напомним одну вещь, которую технические специалисты часто забывают: перед нами учетная система и основным признаком успешности операции будет сохранение правильных значений учетных данных. Проще говоря, после выполнения операции остатки поплыть не должны! Поэтому, прежде чем приступать к любым операциям с базой снимите отчеты по текущим остаткам товаров и денежных средств (для Розницы) и обязательно сохраните их.
Почему обязательно сохранить? Это поможет вам, если во время выполнения всех операций по свертке в базу будут внесены изменения задним числом, сохраненный отчет поможет понять, что остатки поплыли не по причине свертки и искать проблему нужно в другом месте. Чаще всего ничего страшного в этом нет и все изменения придут в свернутую базу с ближайшим обменом.
Теперь перейдем к сугубо техническим вещам, для успешного завершения процесса свертки по нашему методу требуется чтобы был правильно заполнен справочник Идентификаторы объектов метаданных, в противном случае в самом конце процесса вы получите на свернутом узле вот такую ошибку:
А это означает, что вся многочасовая работа пошла насмарку и нужно начинать заново. Поэтому заранее подстелем соломки. Откроем регистр сведений Версии подсистем и изменим версию подсистемы Розница, на какую - не важно, главное изменить. Сохраним сведения и перезапустим программу.
При перезапуске заново отработают все обработчики, запускаемые при обновлении, что гарантирует правильное заполнение необходимых справочников.
Свертка ИБ
Следующим шагом убеждаемся, что все данные из подчиненного узла переданы в центральный и отсутствуют зарегистрированные объекты для обмена. После чего выключаем синхронизацию с центральной базой и принимаем все меры для того, чтобы в базу никто не внес никаких изменений. Лучше всего переименовать папку с базой, это даст гарантию того, что к базе не смогут подключиться не только пользователи, но и скрипты или внешние приложения.
Возвращаемся в центральную базу, принимаем все сообщения от подчиненного узла и также выключаем автоматическую синхронизацию с этим узлом. Затем заходим в настройки синхронизации по магазину и сворачиваем базу на нужную дату штатным способом. В зависимости от периода свертки процесс может занять определенное время.
Подождите, скажет внимательный читатель, вы же только что говорили, что так делать не надо? Действительно, штатный механизм свертки использовать не надо, да мы и не будем, но полностью отказываться от штатных механизмов не стоит. В процессе выполнения свертки будет сформирован документ начальных остатков на дату свертки и выполнена регистрация объектов для обмена. Первый нам пригодится, а вот с регистрацией поступим по-своему.
Откроем обработку Регистрация изменений для обмена и отменим регистрацию всех объектов для подчиненного узла, заодно обратим внимание на то, какое количество их зарегистрировала штатная свертка.
И, пока мы здесь, обнулим счетчики полученных и отправленных сообщений.
Теперь вернемся в настройки синхронизации узла и выполним создание нового начального образа. Именно в этом и заключается основной смысл предлагаемого метода. Начальный образ формируется на дату свертки и происходит это гораздо быстрее, чем свертка подчиненной базы. Но приготовьтесь к тому, что образ будет формироваться продолжительное время, возможно несколько часов.
Чтобы ускорить процесс можно пойти на небольшую хитрость. Каждый, кто работает с 1С знает, что на одном и том же оборудовании файловая базе будет работать быстрее. Поэтому выгружаем ИБ в файловый вариант и формируем начальный образ в нем. Можно даже перенести копию базы на более мощный ПК и выполнить операцию там.
Важно! Убедитесь, что база загружена в режиме копии и все внешние обмены данными отключены, либо отключите их на всякий случай вручную!
Результатом создания нового начального образа будет папка с информационной базой подчиненного узла, которой нам потребуется заменить старую на магазине.
Настройка новой свернутой ИБ в магазине
При первом запуске свернутой ИБ вам потребуется заново настроить параметры синхронизации, этот процесс знаком каждому, кто разворачивал распределенные информационные базы. Однако на этапе Настройки правил отправки и получения данных вы можете получить сообщение о том, что в данной транзакции уже происходили ошибки.
Ничего страшного, сразу переходите к документам ввода начальных остатков, где вы увидите что поле Узел созданного при свертке документа содержит надпись - Объект не найден. При помощи любой обработки для изменения реквизитов установите в поле Узел документа текущий узел РИБ. Мы, например, используем следующую обработку:
Универсальные подбор и обработка объектов (управляемое и обычное приложение), 256 КБ
После чего проведите документ ввода начальных остатков и завершите настройку синхронизации.
Теперь сформируем отчеты по складским остаткам и денежным средствам в кассах с той же самой датой и временем, с которыми мы формировали отчеты перед началом свертки и убедимся, что все цифры совпадают, это означает что свертка проведена успешно.
Убедившись в правильности свертки не забудьте выполнить первоначальную настройку новой подчиненной базы: подключите торговое оборудование, выполните настройки РМК, добавьте пользователей.
Закончив с настройками, выполните синхронизацию, сначала в подчинённой базе, затем в центральном узле и убедившись, что все нормально снова включите автоматическую синхронизацию.
Как быть, если технологического окна не хватает?
В процессе свертки и выгрузки нового начального образа может получиться так, что технологического окна все-таки не хватает для успешного завершения операции. Ничего страшного, базу свернуть все равно можно. Выполните все описанные выше действия вплоть до начала выгрузки нового начального образа.
Теперь мы должны исключить любую возможность синхронизации между центральным и подчиненным узлами. Отключите с обоих сторон автоматическую синхронизацию и на всякий случай в настройках измените параметры подключения на обмен через локальную папку. Теперь мы можем продолжать работать с подчиненной базой, все созданные вновь и измененные документы будут регистрироваться для обмена, но сам обмен происходить не будет. Точно также в центральном узле будут продолжать накапливаться данные для выгрузки в базу магазина. После чего спокойно выгружаем начальный образ, предупредив всех, что обмена с узлом временно не будет.
Выгрузив новую подчиненную базу, запустите ее и, сравнив остатки, убедитесь, что свертка выполнена правильно. Теперь нам нужно перенести из старой базы в новую все те данные, которые там успели наработать. Убедитесь, что кассовая смена в старой базе закрыта и откройте Регистрацию изменений для обмена и посмотрите какие именно документы и справочники зарегистрированы к обмену и за какой промежуток времени.
Не стоит лениться, просмотрите все документы, может оказаться так, что некоторые из них были изменены задним числом. Изменения в регистрах нас не интересуют, так как все движения формируются документами и будут созданы автоматически после проведения их в новой базе. Теперь берем штатную обработку Выгрузка и загрузка данных XML и выгружаем указанные в регистрации изменений документы и справочники за указанный период.
Не бойтесь зацепить лишнего, дублей в новой базе не появится, а уже существующие документы будут перезаписаны только в случае различия в содержимом, это как раз тот случай, когда существующий документ изменили задним числом. Затем этой же обработкой загрузите изменения в новую базу.
Выгрузка и загрузка данных XML, 53 КБ
Теперь сформируем отчеты по остаткам в старой и новой периферийных базах и сравним их. Остатки должны совпадать. Если это не так, то еще раз проанализируйте измененные документы и выполните выгрузку-загрузку еще раз, при этом можете расширить временные рамки выгрузки.
После того, как вы выровняли остатки выполните обмен сначала в новой периферийной базе, затем в центральной и включите автоматический обмен. Теперь уберите старую базу и выполните первоначальную настройку новой.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Последние комментарии