Беда после обновления: ERROR: relation "_reference5091" #796966

Помогите, у меня просто беда! 1С 8.1. нетиповая.  Линукс на сервере. Вайн. Посгре. Сделала обновление (появился новый тип Документов). Реиндексирвала базу. ок. В клиенте захожу клиентов в новый документ, ошибка. Пытаюсь изменить конфигурацию - ошибка. Пытаюсь выгрузить dt - ошибка. Ошибка СУБД: ERROR: relation "_reference5091" does not exist at character 60 Гуглю, говорят что "такое бывает" на постгре, если таблица в бд записалась не так, как надо было бы согласно конфигурации. что делать, я не знаю Поиск и исправление - дают ту же ошибку Искала обработкой SSU_СтруктураХраненияТаблицБазыДанных.epf показывает мне что с этим самым ново созданным документом, и есть проблема. выковырить его оттуда, удалить из конфигурации, не могу, изменять конфигурацию не могу, база не реиндексируется . Пыталась выгрузить универсальной выгрузкой из базы все документы, в xml, и загрузить в чистую, с той же конфой, на SQL ((   выгрузить-то выгрузила, а загрузить в чистую не могу, тоже ошибки... Ошибка СУБД: ERROR: out of memory DETAIL: Failed on request of size 268435456   (завершить перезапустить)    в итоге у меня зависшая не обновляемая, порой выдающая странные ошибки база (( что делать ? есть ли какой то механизм, менеджер , что то для работы напрямую с постгре, что бы я могла эту созданную таблицу кривую оттуда выкорчевать ?

есть один способ - делать копии перед обновлением... а так... вазелин.

ERROR: out of memory - не хватает памяти. Грузите частями.

"Пыталась выгрузить универсальной выгрузкой из базы все документы, в xml, и загрузить в чистую, с той же конфой, на SQL ((   выгрузить-то выгрузила, а загрузить в чистую не могу, тоже ошибки" А если не выгружать новосозданный документ?

В файловую загрузиться с чистой конфигурацией не пробовали? Потом уже тащить базу на сервер.

+ не туда для

1)Бекап. 2) В файловую. 3) 64 битным клиентом под виндой. он такой уже есть. 4) повторить 5) Если нет 64 битного то 32 битным но файловую. 6) результат положить в новую базу в postgress.

Postgress требует аккуратности. linux way... можно все но надо чёкто знать что делаешь. Вообще если база большая то делать обновления конфы в файловой предварительно. Конфа без данных файловая. И с ней работать. Это как раз и есть большая стоимость поддержки постгресс. из

Копию базы сделала перед "неудачной" обновой. только факт сбоя, обнаружили через двое суток. когда базу не откатить. там пара сотен документов. Грузить частями ...что ?  я выгружаю за период, с даты фэйла. за неделю.  А dt - и вовсе частями не выгрузить. Ново-созданный, даже не трогаю. В базе - 20 видов документов.  я беру три вида. выгрузила. еще два. и еще пару. те, что работали всегда, и не обновлялись структурно тыщу лет. и на них косяк.  такое ощущение что между двумя разными конфами веду выгрузку.

Пытаться починить сломанную базу руками. Нужно только если не было бекапа. Поскольку это дело сложное. И нет гарантии что там еще и данные не сломались.

У меня сбойная база на постгре. разворачивать чистую, с чистой конфой, файловую ? и туда загружать все, что слилось из постгре в xml ?

1) Бекап перед обновлением? Есть? Работать с бекапом.

Постгресс без бекапа вообще нельзя обновлять. Это и есть доп затраты на обслуживание постгресс. ну починишь ты постресс. а данные 1с изменила во время обновления или нет? она же на половине прервалась.

Про постгресс и вообще про базы данных. только 64 битные в продакте. Они надежнее. Памяти добавь в настройки. Если памяти нет на компютере. Добавь свап в линукс. И все равно добавь памяти в настройке постгресс.

PS: и как всегда не указаны ни версии платформы, ни версии PostgreSQL. Намекаю на не совместимость версий.

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

Там вообще 8.1 1с Все запущено. Сейчас 1с гораздо лучше работает с постгресс чем тогда...

Лучше? Не факт. Семь лет отработал на пингвине и все ошибки какие были - сюрпризы от 1С. Как, например, сейчас могут быть виноваты протухшие кэши 1С и прощай обновлённая конфигурация. А все кругом с умным видом кивают "Да, этот PostgreSQL такой кривой..."(цы) :(

Я удаляю кеши. 1) перед обновлением. 2) перед динамическим обновлением. батником. Эти кеши зло и удалить их перед обновлением не трудно. 1) удаляешь 2) заходишь в конфигуратор. 3) обновляешь.

Знание что кеши глючат убирает много проблем. Просто удаляешь их. Жаль что нет ключа 1с не пользоваться кешами.

Постгресс не кривой. Просто 1с надежнее работает с mssql. Причина не в постгресс а в совместной работе с 1с. Но 1с не убрать из стека технологий.

Но есть же ключик удалять кэш....

8.1 :(

А ключа Эне создавать" нет.

Есть нет веры в кеши, то в ключ по работе с кешами тоже нет веры. Удалил батником это гарантия.

Будь бы я на месте ТС - я бы повторил обновление на копии базы. Не важно, что данные там устарели, - важно добиться "нормального" обновления конфигурации. Потом шаманить, танцы с бубном: выгрузить"нормальную" конфигурацию из копии и загрузить в рабочую; удалить напрямую в PostgreSQL сбойную таблицу и скопировать её же из копии...

Да надо работать на бекапе. Получить рабочий результат на бекапе. а потом сравнивать с тем что есть.

Пара сотен документов. - забить руками. Это дешевлек и надежнее чем ковырять базу. Прям отдать операторам и они перевобьют. за 2 дня. Зато понятно что все будет работать.

ощущение что между двумя разными конфами веду выгрузку. - это вполне реально если апдайт не прошел корректно. и постгресс частично откатил изменения. в НЕИЗВЕСТНОЙ части. Из бекап работать все там сделать чтобы все было ок. и операторам дать задание перевбить 2 дня.

Юзвер накануне, лёгким движением левой клешни, нажимал кнопку "Выполнить" на панели "Расчет себестоимости" предыдущих месяцев и теперь волнуется за Ваш совет кого-то "забить руками"... :)) См.

При таком раскладе руками точно не собрать базу в скл. Тем более перевводить.

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

Добрый ты. Уверенности что все ок только не будет. Программа перестала ругаться. то не значит что все ок. )

+ можно сделать так развернуть бд без добавленных метаданных из архива. объединить с конфой с новыми метаданными. создать  таблицы (и индексы)  новых метаданных в испорченной бд +  заменить запись dbnames в таблице params и таблицу dbschema  .

.dt , самый последний из сделанных, не разворачивается локально: Превышен максимально допустимый размер внутреннего файла 'E:44/1Cv8.1CD' Я почитала, Почему* ... и скисла. Уважаемые ! руками повторить все доки, что они внесли, уже нельзя. с каждым днем (включая Вчера), там проводок и независимых регистров до черта сделали. что бы актуализировать, надо выдернуть xml .. или починить сбойную. А насчет "создайте таблицу _reference5091 в бд руками. " может попробовать ? а как ? чем ? как залезть и куда ? И "развернуть бд без добавленных метаданных из архива" ... чем ?  у меня есть .dt  ...

советую обратиться за платной помощью. т.к. очень долго вам рассказывать. учитывая ваши  " а как ? чем ? как залезть и куда ?" на этом форуме поиск платной помощи приравнивается к публикации вакансий, и публикация платная либо согласована с ВР (  пункт 6).

"не разворачивается локально..." - не надо "локально", у Вас есть PostgreSQL - создавайте клиент-серверный вариант базы данных. Я бы порекомендовал Вам сделать копию напрямую средствами PostgreSQL. Понимаю, Вы не знаете ответа на "Как и чем?" - но погуглить то Вы можете?

Я погуглила, но сама в постгре таблицы руками сделать не смогу. не тот уровень знаний. нужна помощь .... (( сегодня база начала выдавать ошибку: Ошибка SDBL: тип поля Fld5061 таблицы Document116 несовместим с типом литерала (pos=2466) при записи в документ при чем - на трех рабочих местах выдает, на других - нет. проверяла всячески.

1. поднять дополнительную базу из копии перед обновлением. 2. из текущей рабочей базы где работали нескольо дней сделать выгрузку за период от бэкапа - до сейчас. если это все колоттят руками - объем будит с гулькин хрен. 3. затнуть выгрузку в п.1 4. исследовать...

п.3 - не закидывается ! я выгружаю из Текущей, рабочей базы (на постгре) в xml справочники, отдельно документы, отдельно регистры. Ок. выгрузилось. но когда я в развернутой Целой копии (сделанной до сбоя) пытаюсь ВГРУЗИТЬ эти xml, выдает ошибку

"не разворачивается локально: Превышен максимально допустимый размер внутреннего файла 'E:44/1Cv8.1CD' " Что мешает локально поставить православный MS SQL сервер 1С, загрузить туда последний .dt, корректно обновить и пытаться загружать xml, раз выгрузка проходит без ошибок. "Ошибка СУБД: ERROR: out of memory DETAIL: Failed on request of size 268435456   (завершить перезапустить)    в итоге у меня зависшая не обновляемая, порой выдающая странные ошибки база (( " Исходные данные: Платформа: 1С:Предприятие 8.1 (8.1.15.14) Кофигурация: БП 1.6.24.7 (Конфигурация типовая, на поддержке). Ситуация может воспроизвестись на любой конфигурации. Сервер СУБД: Postgres 8.3.8 (сборка 1с) ОС: Debian Lenny 5.0 (Linux 2.6.26-2-686-bigmem i686 GNU/Linux) Физ: на сервере 8Гб памяти, параметры остального оборудования думаю не критичны. Воспроизводимость 100% При закрытии месяца вылетает с ошибкой: Ошибка СУБД. ERROR: Out of memory. DETAIL: Failed on request size 8388608 Решение: enable_mergejoin=off (в .conf файле или через SET в консоли/PgAdmin) Подробно: Проблема в оптимизаторе, который выбирает неудачный план(merge join), требующий большого объема памяти и большого времени для выполнения запроса. Комментарий с postgresql.org (нужное подчеркнул) «If the default plan chosen by the optimizer for a particular query is not optimal, a temporary solution can be found by using one of these con?guration parameters to force the optimizer to choose a different plan. Turning one of these settings off permanently is seldom a good idea, however. « Что такое mergejoin? Алгоритм соединения слиянием сортированных списков (merge join, sort merge join, sort-merge join) — разновидность алгоритма соединения. Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими.

на отдельном сервере развернули SQL. развернули там последний нормальный dt. Со сбойной базы в Постгре сохраняю конфигурацию. Ею замещаю конфигурацию на развернутом SQL. где последний dt. Обновляю все документы реиндексирую. пытаюсь загрузить в ТУДА все что выгружено из сбойной Постгре. Справочники - загружаются. Документы - нет.

ни один вид документов не загружается? ошибка какая при загрузке?

все не проверяла. проблема с основными доками, которые нужно спасти из проблемной базы.   их то, как раз, то обновление критичное, не касалось никак. выгружаю универсальной обработкой. крутится: мол загружено 2500 обьектов потом: ошибка преобразования данных xml: ссылка на файл 337308,16 подробно:

"крутится: мол загружено 2500 обьектов потом: ошибка преобразования данных xml: ссылка на файл 337308,16 " Что мешает включить отладку на сервере, поставить "останавливаться по ошибке" и посмотреть отладчиком на чем именно падает?

попробуй в браузерее открыть этот док1.xml. или в xml-редакторе.

и не выгружай 2500 объектов, выгрузи один документ для начала.

К сожаление, если база большая, то в файловую она может и недогрузиться - "не все данные были загружены". Поэтому приходится иногда идти на риск.

Включила отладку. Выбрала на выгрузку один документ (выгрузилось связанных 86 обьектов)) Точка останова. Ошибка. такая же. Открывала этот файл в редакторе. А что искать то там ? в общем, я в диком стрессе ...

во владике полно партнеров 1с . делегируйте им проблему. мыслите капиталистически.

во во.чел дело говорит

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

Та же ошибка, это какая? Означает, что проблема в 16 символе 337308 строки. НайтиНедопустимыеСимволыXML по этому файлу что показывает?

посмотри что в строке 337308

"сегодня база начала выдавать ошибку... при чем - на трех рабочих местах выдает, на других - нет." - удали кэши 1С на проблемных рабочих местах. "но когда я в развернутой Целой копии (сделанной до сбоя) пытаюсь загрузить эти xml..." - копия была сделана до обновления или после? Надеюсь у базы-источника и базы-приемника идентичные конфигурации. Иначе, перед загрузкой файлов xml, нужно обновить конфигурацию до версии базы-источника.

ПРАВИЛЬНОЕ РЕШЕНИЕ было в 28. Все остальное это танцы с бубном на удачу. Критерий правильности: 1) точно известно что это поможет и все будет ок. 2) точно известен объем работы. А то что Вы делаете это творчество. За такое творчество на работе надо штрафовать.

(офф) "Выбрала на выгрузку один документ (выгрузилось связанных 86 обьектов)..." - связываться с универсальной выгрузкой XML, чтобы перегрузить объекты из рабочей базы в её копию? :( Мне проще развернуть РИБ из рабочей базы и её копии. А потом, через сообщения обмена, формируя произвольные пачки данных, перегрузить всё что потребуется.

это пользователи ленивые, они ее и тормошат, давай-давай. а так-то если там допустим 20 пользователей, 200 документов. каждому по 10 документов всего.

Это проблема. Подходишь к непосредственному начальнику и спрашиваешь: Вы хотите чтобы проблема был решена быстро и надежно? Предлагаешь: Начальник сделает что надо.

200  документов это 1 рабочий день оператора. это 1 тысяча рублей зп. ну может 2. Если это слишком много то база данных не нужна.

Скинь мне на почту файлы конфигурации CF базы-источника, базы-приёмника и сам этот файл XML. Если доверяешь, естественно, эту секретную информацию мне :) Ничего не гарантирую, но посмотрю.

Зачем потворствуешь ошибкам? Бесплатно?

, не зацикливайся на :)) Правильное предложение была сказано в - "советую обратиться за платной помощью." - и оно не по поводу платной набивки данных вручную как Вы подумали :))

Эта платная помошь стоит дороже и будет оказываться дольше чем вбить руками документы. При этом риски что база будет с глюками останутся. (С неправильными данными если задним числом что-то меняли в эти 2 дня) .. теперь 3 или 4 )

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

Как это не дороже. 1 час работы программиста стоит как 1 день работы оператора. Причем оператор вот он ему уже заплачено. А программисту надо выбивать зп за _свой_ косяк. Это само по себе конфликт.

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

[завязал оффтопить, ушёл]

Утилита администрирования Postgre есть?