Поделитесь опытом переноса данных из бэкапа в рабочую базу
Произошел сбой. Заметили не сразу. Пользователи успели за 2 дня создать новые документы, элементы справочников и т.д.
Остановили сервер, сделали копию текущей базы, развернули бэкап сделанный двумя днями ранее. Запустили бэкап как рабочую базу. Пользователи снова сделали кучу документов. Недосчитались несколько тысяч объектов из старой базы. Остановили рабочий сервер по причине того, что документы стали нумероваться заново и при переносе данных их нумерация начала совпадать. Переносили объекты обработкой "Загрузка и Выгрузка данных через XML".
Наступили на грабли. Работает крайне медленно. Нет возможности выгрузить отдельные записи регистров (например РегистрСведений.СтатусыПроверкиДокументов). В некоторых случаях создаются копии объектов. Версии объектов не переносятся,а также много много подводных камней. Косяки разгребаем уже неделю. Не обошлось без написания спец.обработок, запросов и т.п. В данном случае речь идет о ERP.
Как бы вы переносили?
Остановили сервер, сделали копию текущей базы, развернули бэкап сделанный двумя днями ранее. Запустили бэкап как рабочую базу. Пользователи снова сделали кучу документов. Недосчитались несколько тысяч объектов из старой базы. Остановили рабочий сервер по причине того, что документы стали нумероваться заново и при переносе данных их нумерация начала совпадать. Переносили объекты обработкой "Загрузка и Выгрузка данных через XML".
Наступили на грабли. Работает крайне медленно. Нет возможности выгрузить отдельные записи регистров (например РегистрСведений.СтатусыПроверкиДокументов). В некоторых случаях создаются копии объектов. Версии объектов не переносятся,а также много много подводных камней. Косяки разгребаем уже неделю. Не обошлось без написания спец.обработок, запросов и т.п. В данном случае речь идет о ERP.
Как бы вы переносили?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) на перенос всего ночи не хватило бы, по последним подсчетам мной было перенесено около 5000 документов (некоторые из них созданы автоматически, некоторые изменены, что-то создано задним числом, что-то будущим и т.п.).
(3) И это тоже. Кто-то решил подождать пока перенесут, кто-то решил не дожидаться. А кто-то решил подождать, но уже начал создавать новые документы, но они начали принимать номера тех документов, которые еще не были перенесены, но на которые уже есть подписанные печатные формы и т.д. за этим номером. Значение нумератора ведь тоже откатилось на пару дней раньше.
(3) И это тоже. Кто-то решил подождать пока перенесут, кто-то решил не дожидаться. А кто-то решил подождать, но уже начал создавать новые документы, но они начали принимать номера тех документов, которые еще не были перенесены, но на которые уже есть подписанные печатные формы и т.д. за этим номером. Значение нумератора ведь тоже откатилось на пару дней раньше.
(1) Сложно давать ценные советы, как поступить после того, как сделан ряд ошибок. Озвученные проблемы легко просчитываются заранее.
В идеале надо было не пускать пользователей, пока не будут восстановлены данные. Лучше поработать сутки без перерыва, чем потом месяц выгребать последствия.
Первым делом - обязательно выгрузить и проанализировать ЖР для фиксации всех измененных за два дня объектов, для оценки глубины проблемы, составления плана и очередности устранения последствий. Ну и чтобы ничего не упустить.
Врукопашную перенести изменения справочников через универсальную обработку - вряд ли таких изменений было очень много.
Набросать собственные правила конвертации для ключевых документов, в которых справочники только ищутся по ссылкам. На одинаковых конфах это несложно, а работать будет быстро.
Если возможно - впилить в сбойную базу план обмена, обработкой зарегистрировать по нему изменения ключевых документов по выгруженному логу и выгрузить по сделанным ранее собственным правилам.
Основная идея - кровь из носу успеть закрыть самые большие дыры до запуска в базу пользователей и потом оперативно дозакрыть остальное.
В идеале надо было не пускать пользователей, пока не будут восстановлены данные. Лучше поработать сутки без перерыва, чем потом месяц выгребать последствия.
Первым делом - обязательно выгрузить и проанализировать ЖР для фиксации всех измененных за два дня объектов, для оценки глубины проблемы, составления плана и очередности устранения последствий. Ну и чтобы ничего не упустить.
Врукопашную перенести изменения справочников через универсальную обработку - вряд ли таких изменений было очень много.
Набросать собственные правила конвертации для ключевых документов, в которых справочники только ищутся по ссылкам. На одинаковых конфах это несложно, а работать будет быстро.
Если возможно - впилить в сбойную базу план обмена, обработкой зарегистрировать по нему изменения ключевых документов по выгруженному логу и выгрузить по сделанным ранее собственным правилам.
Основная идея - кровь из носу успеть закрыть самые большие дыры до запуска в базу пользователей и потом оперативно дозакрыть остальное.
(16)
Не согласен. Все просчитать невозможно, если нет опыта ранее.
(16)
Утопия. ЖР у нас больше 70Гб в новом формате. Пытаться там отбирать что-то это еще ожиданий да несколько часов.
(16)
Так и переносил, по одному элементу выбирал и выгружал. Но как я уже сказал, связанные с этими справочниками записи регистров и другие элементы справочников - не перенеслись.
(16)
Когда мы думали, что самые большие дыры были закрыты тогда и запустили пользователей, а потом выяснилось, что те же статусы проверки документов не перенеслись и народ начал эти документы активно редактировать. В общем ворох проблем.
легко просчитываются заранее
Не согласен. Все просчитать невозможно, если нет опыта ранее.
(16)
Первым делом - обязательно выгрузить и проанализировать ЖР для фиксации всех измененных за два дня объектов
Утопия. ЖР у нас больше 70Гб в новом формате. Пытаться там отбирать что-то это еще ожиданий да несколько часов.
(16)
Врукопашную перенести изменения справочников через универсальную обработку - вряд ли таких изменений было очень много.
Так и переносил, по одному элементу выбирал и выгружал. Но как я уже сказал, связанные с этими справочниками записи регистров и другие элементы справочников - не перенеслись.
(16)
Основная идея - кровь из носу успеть закрыть самые большие дыры до запуска в базу пользователей и потом оперативно дозакрыть остальное.
Когда мы думали, что самые большие дыры были закрыты тогда и запустили пользователей, а потом выяснилось, что те же статусы проверки документов не перенеслись и народ начал эти документы активно редактировать. В общем ворох проблем.
(17) Проблема с нумераторами лежит на поверхности и не требует никакого опыта. Достаточно потрудиться задать себе вопрос "что будет, если пользователи начнут создавать документы, когда старые еще не перенесены".
То, что ЖР у вас бесполезен и только место жрет - еще одна ваша проблема, добавляющая синергии конечному эффекту.
Со связанными записями независимых регистров сведений - согласен. Чтобы заранее понять, что "из коробки" они не перенесутся - нужен опыт и понимание принципов работы КД.
То, что ЖР у вас бесполезен и только место жрет - еще одна ваша проблема, добавляющая синергии конечному эффекту.
Со связанными записями независимых регистров сведений - согласен. Чтобы заранее понять, что "из коробки" они не перенесутся - нужен опыт и понимание принципов работы КД.
(5) есть ссылка на обработку? Договоры и некоторые элементы справочника, которые не были привязаны к документам никуда не поехали, паровоза не получилось. Пришлось сравнивать через левое соединение UUIDы ссылок одной базы с другой через COMConnector перебором коллекции Метаданных. Если говорить о договорах, то вместе с ними никуда не поехали также и прикрепленные файлы, даже когда переносил вручную справочник прикрепленных файлов договоров, то вместе с ними тоже никуда не поехали признаки прикрепленных файлов. Пришлось выбрать запросом все такие карточки и обработкой пересохранять, чтобы они сделали движение в этот регистр.
(6)
Хорошо, когда такая обработка есть на момент такой ситуации. А когда все на нервах и все простаивает, то писать такую обработку тяжко, но мне пришлось её писать.
(6)
Можно написать обработку
Хорошо, когда такая обработка есть на момент такой ситуации. А когда все на нервах и все простаивает, то писать такую обработку тяжко, но мне пришлось её писать.
(13) С помощью неё и переносили, но увы она достаточно ограничена. Даже натолкнулся на превышение максимального размера выделения оперативной памяти для процесса. Пытался выгрузить 1 позицию номенклатуры - отдельно от документов и т.д., съела 8Гб ОЗУ и висела 7 часов, не дождался убил сессию.
Когда случился такой сбой, остановили работу, пока не были перенесены все документы. После этого запустили пользователей, и после этого обработкой перенесли справочники (только недостающие элементы). Измененных было немного, их выявили по журналу и исправили вручную. Предприятие не работало полдня.
С регистрами там такого вопроса не было. Можно написать обработку, которая:
а) переносит набор записей регистра по заданному набору измерений
б) переносит измененные наборы записей
С регистрами там такого вопроса не было. Можно написать обработку, которая:
а) переносит набор записей регистра по заданному набору измерений
б) переносит измененные наборы записей
Чтобы понять что было изменено пользователями, можно было создать настройку обмена с максимально полным составом, потом обработкой переносить только измененные.
Одна номенклатура не может переноситься много часов. вероятно были включены флаги переносить при необходимости для всех остальных данных.
Одна номенклатура не может переноситься много часов. вероятно были включены флаги переносить при необходимости для всех остальных данных.
Хотя сдается мне, что целевая выборка изменений ключевых справочников и документов за два дня в SQLite даже 70gb - не может занимать несколько часов. На этот формат 1С и перешла именно для ускорения работы фильтров. Хотя абсолютно зря, как по мне. Лучше бы дали возможность гибко настраивать события, фиксируемые в ЖР, чтобы всякий шлак туда не писался, вместо борьбы со следствиями и возней с SQLite. Я глубоко убежден, что первичные логи обязаны писаться исключительно в текстовые файлы, с возможностью ротации и т.п. Агрегацию можно было бы прикрутить поверх, если надо. Поэтому у меня ЖР ведется в старом формате с разделением по дням и все, кроме ошибок, я пишу туда руками через подписки.
Журналу Регистрации я предпочел написать обработку, которая запускается на восстановленной из бэкапа базе, которая подцепляется через COMConnector к базе откуда нужно перенести объекты, в цикле перебирая Метаданные я создаю динамические запросы к таблицам, выгружаю UUIDы ссылок во временную таблицу, затем левым соединением отсекаю все, что совпадает и остаются только ссылки на объекты, которых нет в восстановленной базе. Происходит все это достаточно быстро. Но эти объекты нужно еще и выгрузить правильно, а универсальные обработки на то и универсальные, а не специализированные для конкретных конфигураций, что и не могут знать какие и где есть неявные связи.
В таких ситуациях пригодилось бы накопительное версионирование базы на подобии git'а, чтобы можно было выгрузить версии из одной базы в другую и произвести сравнение и объединение.
Пытался разобраться с Конвертацией Данных 3 (которая не для 8.3.10), в конфигурации куча ошибок и нет возможности как в КД2 в автоматическом режиме сопоставить все объекты идентичных баз, только ручное добавление каждого отдельного объекта...
В таких ситуациях пригодилось бы накопительное версионирование базы на подобии git'а, чтобы можно было выгрузить версии из одной базы в другую и произвести сравнение и объединение.
Пытался разобраться с Конвертацией Данных 3 (которая не для 8.3.10), в конфигурации куча ошибок и нет возможности как в КД2 в автоматическом режиме сопоставить все объекты идентичных баз, только ручное добавление каждого отдельного объекта...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот