Доброго времени.
Встала задача мигрировать ДО из 2.1 в 3 КОРП (и то и то).
Собственно все по мануалу делаю.  Конфигурации типовые +- .  Все изменения 2.1 перенесены в 3 -ку.

Но в процессе Миграции столкнулись с рядом проблем.

1.  Базы серверные . 2.1 достаточно большая. Ведется с бородатых времен.  Миграция в определенный момент зависает и ничего не происходит.  При попытке отменить миграцию начинается непрерывная запись в 2 РС . ОтметкиВремениОчередь1 2 3 ..  База начинает расти очень быстро . и пока не закончится место на диске пухнет.. . Немного допилил код чтобы  отменить миграцию. Но РС все равно жирные остались..  Как то можно это победить?

2. При отмене миграции есть необходимость очищать регистры которые были заполнены при предыдущих попытках? или они должны очищаться при отмене сами?

3. Есть ли возможность ограничения периода выгрузки данных? или только костылями?  Грубо говоря не нужны данные по некоторым  объектам до начала текущего года.  Удалять перед  началом миграции не вариант, т.к.  для истории они должны остаться. Но не должны переноситься в  ДО 3.

Кто сталкивался с Миграцией  , сталкивался ли с подобными проблемами?

(0)
по п.1 - каковы объемы баз (2.1/3 после миграции, когда место заканчивается)
по п.3 - скорее всего, проще подготовить базу копию, с уже обрезанными данными и из нее миргрировать.

(1) старая база порядка 180 гб. по новой уточнить надо.
В файловом варианте база 40 Гб

(2) п.1 - копейки. У вас там консьюмерский SSD на 250 Гб что ли? Такие вопросы, которые Вы задаете - возникают, когда у вас там исторических данных на террабайт-полтора. Какой объем дисковой подсистемы, где миграция идет? Очевидно же, что Вам надо как-то актуализировать его. Плюс уточните, атачи где хранятся - в томах на диске, или в базе?

(0) А вы отчаянные. 3.0 же в тестовом режиме :)

+ https://dl03.1c.ru/content/DocMngCorp/3_0_10_20/news.htm

Новое в версии 3.0.10.20
Исправлены ошибки:
       При миграции с 2.1 на 3.0 некорректно мигрировали условия маршрутизации со способом задания условия "Комбинация из других условий".


Вы там на какую версию хотели мигрировать и с какой? :)

Ух ты с версии 3.0.5.76 похоже вышли из теста :)

https://dl03.1c.ru/content/DocMngCorp/3_0_5_76/news.htm

Но, по мне как сыроват еще, столько ошибок при миграции :)

(6) на 10.20  с 2.1.32.6

(3) В томах хранится все. Т.е. это штатная история как я понимаю?

(1) Возможность отрезания периода документов существует? в очереди объектов у документов Внутр , входящ, исходящ стоит признак периодичнасти. И реквизит ДатаСоздания как ограничитель периода. Но нигде не нашел где штатно это настраивается

Ну и соответственно если прервать , то статус "выгружен" не пропадает в очереди.  Или это косяк как раз прерывания миграции

(9) Это штатная история, да. Видимо, у вас проблем нет - просто нужно больше места. Забери базу домой, и запусти на выходных миграцию на домашнем компе, отведи под это дело Тб. По поводу обрезки - не подскажу, есть ли такая штатная функция, но если и нет, полагаю написать то не сложно это. Отобраться по периоду, и пометить на удаление все. Скорее всего, сто пудов, если штатного такого нет, кто то уже напилил и где-то выложил.

(12) Спасибо) боду пробовать.

Доброго времени.

Новая беда с миграцией.. Точнее она старая, но не решенная.

смысл в том, что на данный момент миграция идет. Вся история выгрузилась.  Но при загрузке в ДО 3 попадает не все.  Это как документы так и задачи / процессы. Они не переносятся.  Хотя файлы есть.  Они читаются и удаляются.  Я перед началом миграции доработал выгрузку так, чтобы помимо основного каталога фалы копировались в каталог "ИсторияВыгрузки". И если повторно эти файлы закинуть в  папку откуда забирает ДО3 то они прогружаются корректно.

Что касается документов, то в списке всех документов отображаются данные из РС ДанныеДокументов. т.е. в РС может не быть документа а в Документах он есть. . .  + в РС попадают строчки с пустыми ссылками.  Или с сылкой на документ, но все остальное пустое.. При повторной прогрузке все встает на свои места.

Сравнивал 2 файла в Kdiff  разницы в структуре нет вообще. тОлько в данных.

а не проще начать новую жизнь в новой базе с новой версией?
какое то время поживут люди с 2 базами - старой и новой
пока в старой процессы закончатся
а все новое только в новой вводить
потом в старую обращаться только за историческими данными, через полгодика вообще ее закрыть, допилив в новой отчет который сам выдернет то что надо из старой базы если потребуется.
или есть какая-то жесткая необходимость сохранить единую базу?

(16) ТС на новый год ответит. Он 3 месяца базу домой нес....

(17) я ничего никуда не нес.  Вся история переносилась.  Сейчас вопрос по изменениям.

(16) Нужна  единая база. Работать в 2-х базах придется все-равно пока не закрыты старые процессы.

единая база это хорошо до тех пор пока она мелкая..
но со временем вопрос свертки/обрезки старых данных/периодов всегда поднимается.
и в этом смысле переход на новую версию мог быть хорошим поводом обрезать старое, я только с этой точки зрения )

(19)   при переносе выгружали только последние 2 года истории.  Т.е.  Это как бы своеобразная свертка + перенос.

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