Приветствую уважаемые.

Стал свидетелем любопытного и не известного мне явления.

Файловая база (почти типовая УТ) весом ~500 мб.

Через конфигуратор делается выгрузка БД.

Выгрузка делается до сих пор, т.е. более 15 часов, файл выгрузки весит чуть больше 7 ГБ. и продолжает расти.

Может кто-нить объяснить природу сего явления?

Платформу и версию протелепатировать?

ТиИ делал перед выгрузкой ?

(0)У меня такое было, chdbfl.exe спасло

(0)  chdbfl.exe и тестирование и исправление тебепомогут..

у меня как то временный файл выгрузки до 40 гигов вырос и убил диск Ц на серваке :)

(1) Платформа 8.2.13.205
УТ не помню какой релиз (один из последних).

и чем поможет знание платформы и версии?

(2) не делал, вроде как небыло необходимости. До сих пор :)

(3,4) Ребята, понятно что это не нормально, понятно что нужно делать ТиС или(и) chdbfl. Вопрос не в том что с этим делать, а в том почему или даже КАК это может быть. Убейте не понимаю как база в 500 Мб может при выгрузке выдать 10 Гб

(4) Страшные вещи говоришь, выросший временный файл убивает винт ... представилось мне :)

(5) это временный файл 10 Гб, а не файл выгрузки.

(7) очень полезный комментарий

(8) а какой вы комментарий ждете? Убейте процесс и запустите заново. Только очень замечательные люди могут ждать выгрузку 15 часов.

(9) комментарий какой-нить конструктивный по теме, а не лишь бы че ляпнуть

и не стоит считать других идиотами, где написано что я ее ждал, или что вообще я ее сам запустил. В голову не пришла светлая мысль что вопрос может быть переадресован?

"Убейте процесс и запустите заново" Совет истинного знатока.
Продолжил бы тогда " и подождите еще 15 часов".

Достали подобные комментаторы, читать бы хоть для начала научились внимательно.

Остановить и посмотреть что в файле?

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

(5) Я никогда в своей практике не заморачиваюсь вопросами "Почему?" - это зачастую бессмысленно. Куда важнее вопрос "Что сделать для решения проблемы?". Решить этот вопрос, запустить систему в работу, а потом в свободное время за свой счет заниматься выяснением причин. Или подгрузить этим телепатов с Мисты, ага.

(10) После такого я бы на Вашем месте вообще не стал ждать конструктивных предложений.

(13)а зря. Проблема решается гораздо быстрее если понимаешь причину ее возникновения. Более того, некоторые проблемы без выяснения причин их возникновения не решить вообще. Так что фраза "Я никогда в своей практике не заморачиваюсь вопросами "Почему?"" не в вашу пользу. Не стоит этим кичиться.

(14) уже давно не жду, с каждым годом конструктива на мисте все меньше, а загнутых пальцев все больше. :(

(15) "уже давно не жду, с каждым годом конструктива на мисте все меньше, а загнутых пальцев все больше. :("

-1 и скатертью дорога...

(16) затычка?

Думаю сессия зависла какая -то вот он и фигачит. У мну было подобное. База часа 4 выгружалась в место обычных 30 минут. перегрузил сервак все нормально выгрузилось

(5)[Убейте не понимаю как база в 500 Мб может при выгрузке выдать 10 Гб]
убьём и легко.
нарушена структура, например циклическая ссылка
и сожрёт не 10 Гб, а всю доступную дисковую память

был не прав, есть еще нормальные представители. Спасибо ребята, возродили надежду :)

(18) первое что сделали, перезагрузили сервак. Не помогло.

(19) поясни плиз для тупых, что есть циклическая ссылка в 1С и как она чисто технически может вызвать распухание выгрузки?

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

проблема не у тебя первого
ТиИ и очистка кэшей её лечит

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

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

Проблему уже решили при помощи тестирования.
Я с этим впервые столкнулся и просто хочу понять причину.


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

(6) ну всмысле места свободного нуль.. система повисает и висит.. ждет спасителя с shift+del

(23)[просто хочу понять причину]
и что ты для этого, кроме флюда в ветке сделал ?

(25) как что? обратился к спецам с просьбой пояснить возможную  причину, будучи уверенным что кто-то с подобным сталкивался. :)

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

(26)
ржал
от души
жги ещё

Опять носки не стоят? А ведь раньше стояли так долго...

(27) ну блин, а ведь так хорошо начинал )))

(25) два контрагента считают друг друга головными к примеру

(30) во, вот это уже похоже.

а что в этом случае происходит при выгрузке? чисто технически, на пальцах объясни плиз.

по ссылкам идет Контрагент1 - Контрагент2 - Контрагент1 - Контрагент2... и так пока память и место не кончатся

И кстати насчет выяснения причин, для этого ветка не нада было а ТиИ показало бы ошибки которые натолкнули бы тебя возможно на саму проблему которая была

(32) не совсем так... не ссылки в элементах друг га друга, а иерархия побилась...

(32) ты хочешь сказать что выгрузка данных в ДТшник происходит так же как и выгрузка в XML т.е. по правилам? О том что система не даст сделать "два контрагента считают друг друга головными" говорить не будем.

(33) нет, ТиИ выдает служебную информацию об отсутствующих объектах, о недостающих записях регистра и т.д. Ничего интересного.

(34) это как? слетела ссылка на родителя, к примеру? И как это на выгрузке отразится?

(35) образуется бесконечная рекурсия

(35) Ну да, ну да отсуствующие обьекты, циклические ссылки ... ничего ж интересного

(37) ещё пара итераций и ТС наконец создаст стенд на сиквеле с двумя справочниками, загубит ссылку и убедиться в верности версии

(38) У меня знакомый есть, проблема решена, он потратит еще уйму времени - "А почему?", в итоге ответ может и не найти а время соответственно деньги свои или работодателя потратит

(39) представь себе 1С без Гилева и Насипова,
не искать то же плохо

Мои "5 копеек" - реальная история.
Жила была база БП 1.6.
Ей сделали типовой обработкой свертку на начало года.
Осталась куча документов помеченных на удалений за предыдущие периоды (решили оставить на всякий случай).
Днем этой базе сделали "динамическое обновление", а на ночь запустили удаление помеченных объектов (тех самых за предыдущий период)...
Утром НЕ дождавшись окончания работы обработки сервер.... перегрузили кнопкой Reset корпусе.

Привело это к тому, что "ночной" бэкап забивал почти всё место на диске - оставляя буквально 15-20 Мб... и отваливался оставляя в логах надпись "нету места на диске", при этом образовывался файл размером... нормальным размером... именно по объему я его и нашел.

Сервер при этом загружался, работал, но дико тормозил - терминальный режим просто "вешался" (вот к этому месту меня и позвали - "посмотри какая у нас кухнЯ твориться")

Причина такого поведения описана в (19) - нарушена ссылочная целостность хотя тем счастливчики которые попадали в базу этого не видели, документы то уже помечены на удаление и в регистре бухгалтерии движений НЕ делали...

Такой ответ устроит?