Пытаюсь развернуть DT рабочей базы на тестовой машине.
DT весит 9 Гб, а сама база примерно 110 Гб. База клиент-серверная, сервер на debian, стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64. Клиентская терминальная машина на Windows, на ней стоит 8.3.13.1513 х64.
Запускаю загрузку базы из DT, проходит 5 минут, база начинает весить 2,3 Гб и всё, выходит ошибка "В информационную базу загружены не все данные 1с. Ошибка формата потока"
Пробовал загрузить 4 разных DT-файла. Все вылетают с такой ошибкой.
В чем может быть проблема? Почистить кэш не предлагать))

http://catalog.mista.ru/upload/iblock/a39/ошибка_потока.png
Антивирус или спец. программы защиты трафика.

(1) забыл сказать, что маленькие по размеру базы разворачиваются без проблем

а точно версия у того что в ДТ = 1С 8.3.13.1513 ?

Вы что, в файловую базу пытаетесь 110 гигов загрузить?

(4) " стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64"

(3) точно. DT был сделан с базы под платформой 1513 и разворачивается тоже на 1513, только на другом компе

(0) Файл подкачки смотри на сервере

(0) 8.3.13.1513 глючный релиз

(0) ТиИ в источнике выгрузки  сделан ?
4-ре файла выгружены 4 раза из одной и той же базы ?

(7) NAME TYPE    SIZE USED PRIO
    none virtual   6G   0B    0

Как понять сколько нужно?

(8) ещё пока качаю новую платформу

(9) ТиИ не делал в источнике, надо чтобы все вышли часов на 8, а это проблематично.
Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается

аминь

Если в базе есть ошибки, то она не загрузится из dt'ника
Все кто делает резервные копии - dt'никами сильно рискуют остаться без базы.

А почему делаешь через DT, а не через средства SQL?

(0) а кто бекапы 100гиговой базы в дт решил делать?

(15) а как средствами SQL получить 1CD?

ок, попробую через pgadmin сделаю копию

(18) то есть все-таки файловая)

(17) нууу, может они не умеют делать бэкапы средствами постги

(18) какое нафиг 1CD!

(20) т.е. у ТС каша в голове

(23) тяпница,бывает)

(13) Поддерживаю.
Бекапы делают трусы (С)

(23) да вы че, там чел какой то про 1CD спросил, это не я. Я пока копию через pgadmin делаю))

(26) о, точно

+ (26)но бэкап и ресторе нужно делать скриптами а не оболочками

(21) ну бывает скинут bak от MSSQL 2017 и как его грузить в PostgreSQL или MSSQL 2014?

(12)[Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается]
это тебе кажется

а что только я один не понимаю, зачем ему эту всю хрень нужно затащить на клиентскую машину, если ее можно и нужно развернуть как лишнюю базу на том же сервере и в нем тестить все себе интересное на сервере?

(26)[ Я пока копию через pgadmin делаю]
т.е. смысл поста был в троллинге форума =)

(31) Тестить? На боевом сервере? В приличных местах за это а-та-та сделают.

(32) ну да. совсем зеленые о существовании пгадмина самостоятельно не догадываются.

(33) а им не похрен где тестить? чего такого страшного в запуске теста на отдельной базе, ну пускай даже на том же сервере?

(35) ну не.. вдруг че не так пойдет. Плюс лишняя нагрузка на сервер

(35) в ресурсах
в отключенном отладчике

Вот соседняя ветка, уверяла Переход с Микрософта на Линукс что с postgres проблем нет, особенно с бекапами.

(37) да, про отладчик я не подумал.

(36) я бы, пока суть да дело, а если есть готовые ДТ, то проверил бы из них загрузку в соседнюю базу на том же сервере, чтоб лобовым способом проверить, что проблемы в ДТ нету.

(11) Новый PostgreSQL тоже не забудь скачать. Сейчас это 10.9-5.1С.

(35) Можно случайно перепутать тестовую базу и боевую. Можно неосторожним движением уронить процесс сервера 1С:Предприятия или SQL-сервера.

(39) (37) А что за отладчикофобия? Проверял специально, влияние параметра включенной отладки на сервере на производительность влияет на уровне погрешности. Конечно, когда процесс трассируется с подключенным отладчиком, это другое дело. Но повторяю, сам по себе признак разрешения отладки не мешает работе.

(0) Сколько места на системном диске?

1С то ломанная?
Либо она считает себя таковой. :)))))

согласен с (44). Что на системном диске свободного места меньше чем 110 гиг

(0) У тебя битый DT. Точнее битые данные в исходной базе.
1С, формируя dt-шник, выгружает в него конфу, в трех экземплярах, потом льет сырые данные. Никаких проверьк не производится. DT-ник выгрузится всегда.
Обратная ситуация при загрузке, 1с проверяет корректность загружаемых данных; и, если они битые (кривой уникид, число не влезает в разрядность, циклические ссылки и т.п.) то получаешь ошибку формата потока.
Проще всего данные поправить в исходной базе. И перевыгрузить dt-шник.

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

(43) >> А что за отладчикофобия?

Это тема отдельно холивара. И даже если считать, что включение отладки не влияет на производительность (ну или пренебречь этим влиянием), остаётся проблема, когда разработчик начинает отлаживать процесс в боевых базах на продуктивном rphost-е. А этим грешат 99.9% разработчиков, где включена отладка на продуктиве.

(48) DT - не является резервной копией для клиент-серверных баз. Это аксиома. А зачем было доказывать аксиому?...

(50) ну как бы у него аксиома получилась двоякая - ДТ вручную Конфигуратором работает, а хз откуда взятые скрипты создавали ДТ битый.
з.ы. И зачем нужно было годами делать как бы архивы, которые никто никогда не тестил на загружаемость ?

(49) точно! Если включил отладчик на продуктиве, то значит рано или поздно, так или иначе, но пользоваться им начнешь :-)

(48) Это хорошо конечно, а почему средствами SQL не сделать сразу?

(52) Продуктив продуктиву рознь. В 90% случаев это допустимо. Более того, часто даже необходимо подключиться отладкой к пользовательскому сеансу, чтобы выяснить что там у него не так.

(0) Свободное место в %temp% на сервере 1с

Я однажды sql profiler на рабочей базе включил и забыл закрыть. Полдня не могли понять, почему всё медленнее вдвое стало :)

(53) Для этого надо отдельную тему создавать. Из SQL база никак не хотела разворачиваться. Я выгружал бэкап рабочей базы через pgadmin, создавал новую базу в pgadmin на тестовом сервере, восстанавливал данные из бэкапа в эту новую базу, и через какое-то время pgadmin писал ошибку, что не удалось загрузить данные и большой список ошибок. Пробовал через pgadmin сделать копию 100% рабочей базы на том же тестовом сервере и восстановить её в другую базу на этом же сервере - те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип). Долго разбирался с кодировками и прочей хренью на линуксе, но всё было ок, русские локали работали и пустая база создавалась с русской кодировкой. Решил обновить postgresql с 9.6 на 10, но хрен там... У версии debian, которая установлена на серваке какие-то проблемы с новым 10-ым postgresql из-за библиотеки libssl.so
Короче понял, что без админов в линукс лучше не лезть, откатил всё обратно, попробовал вручную сделать бэкап рабочей базы и развернуть его. Чудом всё получилось. Дальше буду с админами разбираться что не так с бэкапами postgresql

(5) нахуа тогда dt-шник?

(57) Что-то мне помнится, что для восстановления бэкапа постгреса надо сначала базу создать из 1с, а потом уже восстанавливать бэкап поверх существующей базы. Что-то там с определяемыми типами, которые создаются в контексте базы, и эти определения не сохраняются в бэкапе.

(57)[ те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип)]
дык это 100500 раз описано, да есть фичи