Восстановление обмена в РИБ. Запущенный случай

03.04.17

Интеграция - Перенос данных 1C

Удачная попытка восстановить обмен в РИБ при большом количестве объектов обмена и ошибках при обмене.

Хочу поделиться опытом, касающимся распределенных баз. Ко мне обратился заказчик с просьбой восстановить обмен в распределенной базе, который перестал работать некоторое время назад. Беглый взгляд на монитор обмена привел меня в недоумение - откуда столько объектов для выгрузки (см. Рис. 1).

Помявшись, местный спец признался, что обмен из центральной базы в периферийную сломался два месяца назад, хотя в обратном направлении работает без проблем. На вопрос, почему тянули два месяца, внятного ответа я не получил. Размер файла обмена тем временем вырос до 3,7 Гб (несжатый).
Ладно. Симптомы отсутствия обмена - сообщение об ошибке (см. Рис. 2). 

Причина, очевидно, "кривые" движения каких-либо документов.
Патрон (1С), в этом случае, советует перепроводить все документы, попавшие в выгрузку (см. Рис. 3).

Совет хороший, но был отметен сразу, как неосуществимый - слишком их много. Как локализовать источник ошибок?
Учитывая размер центральной базы (15 Гб) первым предположением было превышение суммарного размера одной или нескольких таблиц, величины в 4ГБ. Это не подтвердилось.
Тестирование и исправление ничего не дало. Выгрузка и повторная загрузка центральной и периферийной баз в dt не выявила каких-либо ошибок. Все проходило штатно. Обработка, которая ищет неуникальные комбинации (Регистратор, НомерСтроки) в движениях регистров не выявила ошибок. Код процедур проверки регистров приведен на Рис. 4.

Процедура КнопкаВыполнитьНажатие(Кнопка)
    Ошибки.Очистить();
    МетаданныеРегистрыНакопления = Метаданные.РегистрыНакопления;
    КоличествоРегистров = МетаданныеРегистрыНакопления.Количество();
    Для Сч = 1 По КоличествоРегистров Цикл
        МетаданныеРегистр = МетаданныеРегистрыНакопления[Сч - 1];
        ИмяРегистра = МетаданныеРегистр.Имя;
        Если ИмяРегистра = "ПартииНоменклатуры" Тогда
            //Продолжить;
        КонецЕсли;
        Сообщить(ИмяРегистра + " ???");
        ТекстЗапроса = СформироватьТекстЗапросаПоРегистру(ИмяРегистра);
        Запрос = Новый Запрос;
        Запрос.Текст = ТекстЗапроса;
        Результат = Запрос.Выполнить();
        Если Результат.Пустой() Тогда
            Сообщить(ИмяРегистра + " Okay");
            Продолжить;
        КонецЕсли;
        Сообщить(ИмяРегистра + " + ");
        Выборка = Результат.Выбрать();
        Пока Выборка.Следующий() Цикл
            НоваяСтрока = Ошибки.Добавить();
            НоваяСтрока.Регистратор = Выборка.Регистратор;
            НоваяСтрока.Период = Выборка.Регистратор.Дата;
            НоваяСтрока.ИмяРегистра = ИмяРегистра;
        КонецЦикла;
    КонецЦикла;
КонецПроцедуры

Функция СформироватьТекстЗапросаПоРегистру(ИмяРегистра)
    ТекстЗапроса =
    "ВЫБРАТЬ РАЗЛИЧНЫЕ
    |   Данные.Регистратор КАК Регистратор
    |ИЗ
    |   (ВЫБРАТЬ
    |       РегистрНакопления.Регистратор КАК Регистратор,
    |       РегистрНакопления.НомерСтроки КАК НомерСтроки,
    |       СУММА(1) КАК КоличествоДублей
    |   ИЗ
    |       РегистрНакопления." + ИмяРегистра + " КАК РегистрНакопления
    |
    |   СГРУППИРОВАТЬ ПО
    |       РегистрНакопления.Регистратор,
    |       РегистрНакопления.НомерСтроки
    |
    |   ИМЕЮЩИЕ
    |       СУММА(1) > 1) КАК Данные";
    Возврат ТекстЗапроса;
КонецФункции

Кусочек кода, относящийся к регистру "Партии номенклатуры" появился, поскольку в файловом варианте попытка проверки приводила к аварийному закрытию сеанса с сообщением об ошибке "Недостаточно памяти" (32 Гб оперативной памяти - маловато, само собой).

Отключение итогов (кстати, аналогично, по совету патрона) тоже не помогло. Обе базы выглядели совершенно нормально. Ошибка возникала только при операции ПрочитатьИзменения() при загрузке файла. Возможно, это проблема платформы, как я сейчас думаю. Признаться, я зашел в тупик - предложение создать заново начальный образ периферийной базы я оставил в качестве последнего шанса не потерять лицо, да и не факт, что выгрузка прошла бы гладко.
Решение пришло внезапно. Кто сказал, что индексы должны быть уникальны? Далее, я создал базу SQL, загрузил туда периферийную базу, и начал попытки загрузить туда файл обмена. Как только загрузка вываливалась на ошибку (см. Рис. 5),

я снимал флажки уникальности с индексов таблиц регистров (Рис. 6).

Всего таких регистров нашлось шесть. Когда файл загрузился, я снова применил обработку поиска неуникальных комбинаций (Регистр, НомерСтроки), и получил таблицу "кривых" документов (см. Рис. 7).

После этого я сделал их непроведенными в центральной базе, выгрузил файл обмена, затем загрузил его в исходную периферийную. Все прошло нормально. Бинго!

PS. После этого я перепровел документы из таблицы и они ушли в периферийную без проблем.

Распределенная база данных 1С 8.2 1С 8.3 SQL сервер

См. также

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

27660 руб.

12.06.2017    143515    823    297    

428

SALE! 10%

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

55778 50200 руб.

04.08.2015    168522    345    280    

382

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.88.x) и УТ 11.5 (11.5.20.x), также подходят для релиза 11.5 (11.5.19.x).

35000 31500 руб.

23.07.2020    53682    236    73    

193

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

53111 47800 руб.

03.12.2020    37371    100    68    

95

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.237.x) и БП 3.0 (3.0.166.x). Правила подходят для версии ПРОФ и КОРП.

35000 31500 руб.

15.12.2021    24919    175    51    

133

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена | Можно выполнить переход с УПП на БП 3 или запускать выгрузку данных за выбранный период времени | Переносятся документы, начальные остатки и вся справочная информация | Есть фильтр по организации и множество других параметров выгрузки | Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов | Перенос данных возможен в "1С: Бухгалтерия 3.0" версии ПРОФ, КОРП или базовую | Переход с "1С: УПП1.3" / "1С:КА 1.1" на "1С:БП3.0" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!

48278 43450 руб.

25.02.2015    172100    308    259    

385

Перенос данных 1C Программист Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет НДФЛ ФОМС, ЕФС Платные (руб)

Обработки для быстрого перехода с конфигураций «КАМИН:Расчет заработной платы 3.0», «КАМИН:Зарплата для бизнеса 4.0» и «КАМИН:Зарплата 5.0» на конфигурацию «Зарплата и управление персоналом» версии 3.1.

12000 руб.

25.09.2016    81696    325    253    

277

Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 8 учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.

120000 руб.

19.08.2020    25783    25    1    

27
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. webester 26 03.04.17 09:21 Сейчас в теме
Детектив с хэппиэндом :) интересно, что скажет начальник транспортного цеха местные гуру SQL
2. peterxx 23 03.04.17 09:44 Сейчас в теме
(1) А какого рода комментариев вы от них ожидаете?
3. Stim213 416 05.04.17 08:27 Сейчас в теме
Можно было бы распровести документы в узле, загрузить файл обмена и провести непроведенные
4. WellMaster 104 05.04.17 10:27 Сейчас в теме
Все правильно сделал. Сам через это проходил.
Аналогичная проблема была, когда пытались загрузить dt-шник в базу SQL. Ругалась на служебную таблицу, которую пришлось грохнуть, загрузив dt-шник сперва в Postgre, т.к. последний менее придирчив к уникальности индексов.
5. peterxx 23 05.04.17 17:56 Сейчас в теме
Простите, не понял, что нужно было распровести в узле? На картинке показано количество документов, которых не было в подчиненном узле. И они не могли туда попасть из-за ошибки чтения файла обмена.
6. aspirator23 340 08.04.17 15:40 Сейчас в теме
Решение интересное. Пара вопросов. Если дубли были в базе источнике или в базе приемнике, то мы их должны были увидеть. Если дубли возникали при загрузке из-за неуникальности записей, то вариант предложенный в 3 должен был бы помочь - при перепроведении мы бы остановились бы на неуникальности. Или нет?
7. peterxx 23 09.04.17 09:26 Сейчас в теме
(6) Наверное, я в статье выразился недостаточно ясно, Обе базы, и центральная, и периферийная ошибок не содержали. Они прошли все тесты, которые мне пришли в голову:
а. Тестирование и исправление;
б. Выгрузку в dt и, последующую загрузку;
в. Выгрузку и последующую загрузку в SQL;
с. Поиск запросом в регистрах накопления неуникальных пар Регистратор,Номер строки.

Ошибка возникала в момент загрузки файла обмена, не раньше и не позже. Загружаемых документов, вместе с их движениями, в периферийной базе не было.
Поэтому мне совсем непонятна отсылка на совет (3). Что я должен был распровести и провести обратно в подчиненном узле? Все документы за несколько лет работы? А в главном - пять тысяч с гаком? Представляете время, которое бы это заняло? И не факт, что это удалось бы. Проще тогда заново создать начальный образ. Меня остановило только то, что не было уверенности, что созданная база будет валидна с точки зрения обмена РИБ, ведь работают те же механизмы.

После того, как я нашел эти документы, они перепровелись без проблем. И пропутешествовали в периферийную тоже без проблем. Т.е. кривизна в движениях регистров была таки, но такая, которая не "ловится" средствами 1С и появляется стохастически. Вот почему я грешу на платформу. .
8. nvv1970 17.04.17 00:54 Сейчас в теме
Автор ничего не упомянул о версии платформы и MSSQL. А это, на мой взгляд, очень важно.
Вообще РИБ меняются данными с минимумом программного кода (или вообще без), все действия в чтении и записи 1с выполняет сама. И то, что появилась такая ошибка, наводит на мысль об ошибке в платформе. Было бы интересно, если бы автор выложил трассировку ошибки и более глубоко разобрал причины. Но в любом случае идея хорошая.
А еще можно было бы вообще отключить проблемный индекс ) А потом его перестроить.
Очень странно, что ошибка вообще возникла, да еще на этом индексе. Вангую, что обычная запись набора записей без проблем выполнилась бы. Гранулярность обмена для РН - регистратор... Откуда бы взяться ошибке?
9. peterxx 23 17.04.17 07:42 Сейчас в теме
(8) Честно говоря, я не подумал, что версии платформы и MSSQL могут иметь значение. Ну раз это важно, версия платформы, в которой была создана база SQL - 8.2.19.106. Версия MSSQL - 2005.090.5000.00. Если этого недостаточно, то прилагается скриншот с полными данными по MSSQL. При тестировании в файловом режиме ошибка возникала на платформах 8.2.19.130, 8.3.8.2137, 8.3.9.2033. Так что мой вывод - ошибка не зависит от релиза платформы. Если это ошибка платформы, то она тянется, наверное, еще со времен 8.1. Мне думается, что сама 1С считает механизм РИБ устаревшим, поэтому ничего в нем не меняет.

По поводу минимума программного кода, вы абсолютно правы. В сущности все сводится к методам ЗаписатьИзменения и ПрочитатьИзменения. С отладчиком не сунешься, увы.

По поводу трассировки: что вы имеете в виду?
Прикрепленные файлы:
10. TODD22 20 17.04.17 08:06 Сейчас в теме
(9)
Мне думается, что сама 1С считает механизм РИБ устаревшим, поэтому ничего в нем не меняет.

Других механизмов то же не предлагает....
В БСП исправляют ошибки связанные с обменами в РИБе.

А так ошибок уже каких только не встречал в РИБах. Из последнего на лету без остановки рег заданий заменили правила регистрации. РИБ так лаганул что в узлы попали документы из других узлов. А некоторые документы замножились. И вместо одно документа получили 10 одинаковых документов с одним и тем же номером в узле и ЦБ.
Были проблемы с движениями. Были проблемы с обменами когда падало из за какого то глючного объекта.
11. peterxx 23 17.04.17 09:46 Сейчас в теме
(10) Мне кажется, что тренд - Конвертация данных, вот уже второе поколение пошло...
12. TODD22 20 17.04.17 09:48 Сейчас в теме
Ну а куда от РИБа уйдёшь?
Конечно может есть способы... Интересно было бы посмотреть. Пока что всё что видел было по сути тем же РИБом в доп костылями.
13. peterxx 23 17.04.17 10:12 Сейчас в теме
(12) Трудно спорить. На мой взгляд, единственное преимущество конвертации - возможность поковыряться отладчиком в случае чего.
14. sashapere 159 20.09.20 00:39 Сейчас в теме
Классная Идея с отключением уникальности!
Оставьте свое сообщение