Имеется очень сильно переписанная база на основе Розницы. До сих пор работала на версии платформы 8.3.13.1644
Лежит на postgresql-10.5-24.1C_x64, кластер 1С и postgre SQL с базой находятся на одном физическом сервере.
Размер окол 45Гб.

Решили обновить платформу 1С.
Сисадмин на тестовой машине установил postgresql_13.4_6.1C_x64, сервер 1С и платформу 8.3.20.1674.

Из старой версии dt выгружается и при необходимости прекрасно загружается обратно, а вот в новую версию отказывается загружаться. Процесс загрузки начинается, загружает примерно 5 Гб (по данным pgadmin) и выходит с ошибкой.

После включения логирования получаем ошибку
48:26.312001-0,EXCP,3,process=rphost,p:processName=NEW,OSThread=1088,t:clientID=17,t:applicationName=Designer,t:computerName=BUH,t:connectID=21,SessionID=1,AppID=Designer,Exception=SeanceContextException,Descr=Попытка получения неинициализированного значения

Методом проб и ошибок было выяснено: новая платформа успешно загружает базу УТ10, имеющую больший размер, чем целевая.
Если загрузить базу с помощью платформы 8.3.13.1644 и затем обновить платформу то база работает, однако выгрузка в DT проходит, а обратно не загружается.
Если установить 1с 8.3.18.1661, то тоже база нормально загружается и работает, на более свежих платформах загрузка не проходит.


Подскажите, как убедить последние версии платформы 1С загружать нашу базу.

Зачем вам 20 платформа? Почему бы не оставить 13, ну или хотя бы 18?

У меня ЗУП работает например сейчас на 19 платформе, а все остальные самописки на 13 до сих пор, и с 13 их переводить не собираюсь

установи ту платформу, через которую выгружали. Загрузи на сервер и установи новую платформу.

(3) наверное по этому: "Если загрузить базу с помощью платформы 8.3.13.1644 и затем обновить платформу то база работает, однако выгрузка в DT проходит, а обратно не загружается. "

Не понятно зачем для УТ10 последняя платформа.

(5) у него вообще Розница )))

(6) Розница 1.0 ?

(0) зачем вы дт мучаете, неужели нет возможности по средствам скуля выгрузить и загрузить базу?

Иногда полезно грузить в пустую базу , а не в прежнюю. Т.е. создал пустую базу на SQL и грузи.

Ошибки могут быть при выгрузке в dt. 1С рекомендует восстанавливать архивы средствами СУБД, если это не переход с файловой на клиент-серверную

(10) явно скуль используется раз "Сисадмин на тестовой машине установил postgresql_13.4_6.1C_x64, сервер"

(0) Вы меняете и версию платформы и версию СУБД
Странно что у вас там не взорвалось  ничего

(1) Планируем подключить обмен по ЭДО, а для этого взять обработку Diadok в перспективе они скорее всего все равно потребуют более свежую платформу.
(6) Розницей это было очень давно. Сейчас там больше своего написано.
(8) Сисадмин утверждает что у postgresql c этим проблемы. К тому же, а если придется на SQL переходить, то как это без dt сделать?
(9) пробовали. создавали и пустую базу, в нее загружали только конфигурацию и затем уже целевой dt результат такой же.
(10) Ошибки наверное могут быть, но почему тогда в старые версии грузится?
(12) Пробовали не менять версию СУБД - ошибка та же на том же месте(загружался такой же объем базы).

(13) Тестировали бд ?

(14)Да, конфигуратором. После все равно не загружается в новую платформы.

а чекдбфл ?

В СЕРВЕРНОМ варианте?

(12) действительно, повезло еще...

!18) Я же писал в (13) что была попытка поменять только платформу, но это ни к чему не привело.

(13) вы же сами пишите, что у вас клиент-серверный вариант работы с базой "Лежит на postgresql-10.5-24.1C_x64," попробуйте сделать бекап на стороне скуля, постгря без проблем с этим справится и грузите уже этот бекап, а не вашу дтшку. "Сисадмин утверждает что у postgresql c этим проблемы" - может это у сисадмина проблемы? Какая ошибка?

забудьте уже о дтшках на базах с более 10 юзверами и размерами за 40гигов. Всегда есть риск не развернуть базу, либо развернуть с ошибками, поэтому и не рекомендуют использовать ДТ для бекапов

(20) т.е. вы считаете нормальным тот факт что 1С разучилась загружать собственные дт?
в(1) я писал: Если установить 1с 8.3.18.1661, то тоже база нормально загружается и работает, на более свежих платформах загрузка не проходит.

(19) из чего следует вывод - 20-я платформа тестовая подделка, посмотрите, сколько криков на тему...перешли на 20-ю - все умерло...

(22) вы проблему хотите решить, или по возмущаться, почему ваш ДТ 1ска не кушает?)

(22) я вам больше скажу, если одна из таблиц превысит 4гига, то в любой платформе ваша дтшка чудным образом не развернется и скажет "Превышен максимально допустимый размер внутреннего файла"

(22) если в выгруженном дт есть ошибки (рассогласованность схемы базы? например, ошибки в полях и структуре табличек, которые ТиИ никогда не правит) то dt никогда не загрузится ни в какой релиз.

и это ..со времён выгрузки в dat файлик в 7.7

Если ваш Одмин не умеет делать скулевый бэкап.. гоните его сцанными тряпками

(26) Как  проверить наличие ошибки рассогласованность схемы базы?
К тому же 8.3.18.1661 прекрасно грузит.

(29) Эту базу или что  грузит ?

такой запрос че возвращает ?
SELECT * FROM ConfigSave ?

База в каком режиме совместимости ?

(31) там бекап не могут на скуле сделать, а вы прямой запрос просите сделать)

Грузит именно эту базу именно из этого же дт
(31) не пробовали. Это надо на старом сервере сделать конечно?

(33) А вы умеете? Расскажите как, я сисадмину передам.

(0) "Я вам один умный вещь скажу но только вы не обижайтесь"(с)
Вам никто не гарантировал обратную совместимость выгрузки/загрузки DT в платформах. На моей памяти уже не раз и не два такое бывало.

Я вам отвечу глупостью, но в одну платформу грузится (без гарантий), а в другую - нет. Возникает крамольная мысль, улучшения и исправления ошибок в платформе уже начинают мешать работать.

(25) " я вам больше скажу, если одна из таблиц превысит 4гига, то в любой платформе ваша дтшка чудным образом не развернется и скажет "Превышен максимально допустимый размер внутреннего файла"

Знаю такую проблему для файловой базы, про серверный вариант не слышал. В нашей базе кстати таких нет.

(35) если вы про бекапы, то вот:
https://its.1c.ru/db/metod8dev/content/1809/hdoc
https://serveradmin.ru/bekap-i-vosstanovlenie-bazyi-1s-v-bd-postgresql/
https://infostart.ru/1c/articles/1187165/

(34) И в какой именно вашу выгрузку не загружает ?

и вы 18 накатывали куда, на старый сервер или на новый ?

(37) Зря иронизируем. Однажды мне помогло банальное ТиИ (реструктуризация). База,  загруженная из DT, становилась битой после непродолжительной работы с ней. Крамольная мысль: вероятно какие-то служебные данные из DT предыдущей платформы загружались без их реструктуризации.

(29) ну так и оставайся на этой платформе.

почитайте внимательно вот эти рекомендации https://its.1c.ru/db/metod8dev/content/2922/hdoc

+(42) (офф) я даже помню случай, когда DT файловой версии не грузился в клиент-серверную версию той-же платформы (хотя, как по мне, так обратное считал более вероятным).

(42) дело говорит
Нужно текущую обновить платформу, потом сделать реструктуризацию через ТИ, а потом уже попробовать выгрузку загрузку DT

ИМХО, автор хернёй страдает.
1С всегда и везде писала, что dt не является архивом и что бекапы клиент-серверных баз должны делаться средствами СУБД.
Единственное, где без dt не обойтись - миграция с файлового варианта на клиент-сервер и обратно или с одной СУБД на другую.
Налицо придумывание самому себе проблем и мужественные попытки их преодоления.
Обновлять одновременно и версию платформы и версию СУБД - заведомый поиск приключений на свою задницу. Причем с заранее неизвестным источником причин этих приключений - толи СУБД глючит, то ли платформа. А может там админ криворукий и тестовый сервер криво настроил и там тупо места на диске не хватает (например).

(46) спасибо за дельный совет. Попробуем.

(47)Уважаемый, я видимо где-то написал на непонятном для вас языке, но

1. Не было обновления, была установка на новом сервере и уже туда попытка "миграции". - неудачно
2. Была произведена попытка миграции на новую платформу 1С с использованием старой версии постгриса. - неудачно
3. А если когда нибудь все таки потребуется мигрировать "с одной СУБД на другую", а я уже знаю: dt не грузится?
4. Место на диске бралось с кратным запасом по отношению к размеру базы. Причем еще раз отмечу, на той же машине не могут загрузить базу только последние версии платформы.

Вы пишете "1С всегда и везде писала, что dt не является архивом". Спасибо   Kassern он как раз вовремя дал ссылку  https://its.1c.ru/db/metod8dev/content/2922/hdoc
где написано: "Иногда этот режим используют, также, для создания резервной копии информационной базы" ну вот мой случай как раз "иногда".
Все перечисленные в статье недостатки этого метода компанию устраивают.

(49) Поставить на новом серваке ту-же версию постриги и ту же версию 1с-ины не предлагать ?
А потом уже заниматься поднятием версии платформы

Да и..45 гиг.. версионирование поди, гигов 30 место отъело ? :)

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

(52) ну и обновляй, в начале на старом постриге обнови платфору ( не делая никаких выгрузок)
Потом подыми версию скуля

Усё

для мегагуру-нытиков про "дт ето не архивация".
1. по ссылке из (44): "1С:Предприятие поддерживает возможность загрузки/выгрузки информационной базы в файл. Этот механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных." по слогам. "поддерживает". но не рекомендует для постоянного использования в качестве штатного бэкапа ("обладает рядом недостатков. Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо.")
2. у человека - НЕ штатный бэкап, а именно перенос из релиза в релиз с изменением версии формата хранения. для которого используемый им метод и применим, и "поддерживается".
поддержка постгри кроссплатформенного переноса базы - это плюшка "параллельная", не пересекающаяся с описанной задачей. она есть - Ок, но как она если при этом еще и движок 1с меняется (который в том числе также может коснуться структуры на низком уровне)?..
ну т.е. - штатный механизм, для которого и обещана поддержка, и область применения соответствует - не работает как обещано, значит надо прежде всего думать почему так и как исправить именно это. а уж далее способы продвинутого серверного администрирования - это уже "далее", а не растопырив пальцы и презрительно выпячивая нижнюю губу на штатные методы.

(55) одно дело, когда человек проблему решил и пытается разобраться, что способствовало ее появлению, другое дело, когда человек сидит со старой платформой и никуда свою дт воткнуть не может с кучей ошибок, а на подсказки решения проблемы разворачивания бекапа через инструмены скуля получили ответ - мол сложно для админа...Никто тут губу с пальцами не растопыривает, тут человек не с файловой на скуль переходит и не с постгри на ms sql, а всего лишь пытается развренуть на другом серваке свою базу, но почему-то сразу пытается на новую платформу.

(52) Можете и дальше обижаться словно девочка. Дело Ваше.
Просто никто никогда так не делает.

А то что вы там получаете какую-то невозможность - ваши личные фантазии. Уже миллион раз обсуждалось, что dt - это не архив. В клиент-серверном варианте есть прямые рекомендации вендора - делать выгрузку средствами СУБД.

А утверждения вашего сисадмина про то что "...у postgresql c этим проблемы" звучат мало убедительно.
Разделите задачи обновления платформы и обновления СУБД и проблемы не будет.

Есть четкие описания порядка обновления платформы от 1С. Ни в одном из них нет упоминания о выгрузке/загрузке через dt.
Есть четкие описания обновления версии СУБД от Postgre. И (неожиданно) в них тоже нет никаких упоминаний о каких-то загрузках сторонними приложениями (1С) из файлов непонятного происхождения (с точки зрения СУБД).

До сих пор ни одного явного доказательства, что проблема именно в 1С, а не на стороне СУБД, ОС или на стеке , так и не прозвучало.
Если ваш dt успешно можно загрузить на той же версии платформы и той же версии СУБД, откуда он был выгружен, то абсолютно никаких оснований обвинять в чем-то 1С я не вижу. Можете и дальше печалиться, сокрушаться, расстраиваться или что вы там ещё делаете вместо того чтобы нормально работать.

(57)Достаточно заменить постгре на мс скл и Ваши рассуждения теряют смысл совсем.

(58) а что не так с мс скл?

(0)Вам надо локализовать ошибку с точностью до записи таблицы.
но сначала с точностью до таблицы.
для этого можно настроить тж и выяснить инyтрукции выполненные до ошибки.( экстенсивный долгий путь)
либо сгенерировать "маленькую" бд с 1к записей в каждой не служебной таблице  и загрузить её(тк бд маленькая - загрузка быстрая).
если ошибка повториться , то (бысто) её проанализировать с помощью тж. ошибка скорее всего в служебных таблицах.
иначе
сгенерировать огромное кол-во выгрузок (dt) с несколькими таблицами . чтобы выяснить на какой таблице происходит ошибка.

Месяц назад обновлял платформу с 14-й на 20-ю, снес полностью каталог кластера 1С. ЖР можно сохранить, если нужны.
Выгруженные в dt из 14-й базы прекрасно загрузились в 20-ю, даже совсем старая бухгалтерия бюдж. уч., которой 12 лет и с 8.2 совместимость. Проработало все это время без нареканий.
PostgreSQL тоже менялся, с 11-й редакции на 13-ю. Ничего не екнуло.

>>очень сильно переписанная база
Такого, конечно, у нас нет.

(58) Не вижу связи. Или вы тоже балуетесь обновлением MS SQL через dt с одновременной сменой версии платформы? Ну вот честно.
Если вдруг возникает задача смены СУБД, то мало кто станет рисковать и совмещать это с обновлением платформы.
Либо платформу обновят сначала и выполнят полное ТИИ с реструктуризациями и пересчетам итогов, а только потом будут выгружать в dt и загружать на новой СУБД.
Либо наоборот - сначала перенос на новую СУБД и потом обновление платформы.
Зачем нужно скакание на граблях - для меня лично загадка. Трата ресурсов на расследование "проблемы" в условиях, когда нормально работает выгрузка/загрузка на старой версии платформы с последующим её обновлением, тоже вызывает вопросы. Разве что чисто академический интерес для получения ответа, не имеющего почти никакой практической ценности. Для общего развития так сказать.