Помогите, у меня просто беда!
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 ((  
выгрузить-то выгрузила, а загрузить в чистую не могу, тоже ошибки"
А если не выгружать новосозданный документ?

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

(4)+ не туда для (0)

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

(0)
Postgress требует аккуратности.
linux way...
можно все но надо чёкто знать что делаешь.

Вообще если база большая то делать обновления конфы в файловой предварительно.
Конфа без данных файловая.
И с ней работать.

Это как раз и есть большая стоимость поддержки постгресс.
из
Выбираем между SQL, Postgre, sql azure. Посоветуйте.

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

Грузить частями ...что ?  я выгружаю за период, с даты фэйла. за неделю.  А dt - и вовсе частями не выгрузить.

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

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

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

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

(10) Постгресс без бекапа вообще нельзя обновлять.
Это и есть доп затраты на обслуживание постгресс.

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

она же на половине прервалась.

(0) Про постгресс и вообще про базы данных.
только 64 битные в продакте.
Они надежнее.

Памяти добавь в настройки.
Если памяти нет на компютере.
Добавь свап в линукс.
И все равно добавь памяти в настройке постгресс.

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

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

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

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

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

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

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

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

(21) 8.1 :(

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

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

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

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

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

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

Из бекап работать
все там сделать чтобы все было ок.
и операторам дать задание перевбить 2 дня.

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

См.(15)

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

создайте таблицу _reference5091 в бд руками.

далее + поле id прочие служебные

далее заходите в документ программа ругнется на следующее поле. добавьте его и так далее.

(31) Добрый ты.

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

+(31)

можно сделать так развернуть бд без добавленных метаданных из архива. объединить с конфой с новыми метаданными.

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

Я пробовала (((

.dt , самый последний из сделанных,
не разворачивается локально:
Превышен максимально допустимый размер внутреннего файла 'E:\44/1Cv8.1CD'

Я почитала, Почему* ... и скисла.

Уважаемые ! руками повторить все доки, что они внесли, уже нельзя. с каждым днем (включая Вчера), там проводок и независимых регистров до черта сделали.
что бы актуализировать, надо выдернуть xml .. или починить сбойную.

А насчет "создайте таблицу _reference5091 в бд руками. "
может попробовать ? а как ? чем ? как залезть и куда ?

И "развернуть бд без добавленных метаданных из архива" ...
чем ?  у меня есть .dt  ...

(34) советую обратиться за платной помощью.

т.к. очень долго вам рассказывать. учитывая ваши  " а как ? чем ? как залезть и куда ?"

на этом форуме поиск платной помощи приравнивается к публикации вакансий, и публикация платная либо согласована с ВР (http://www.forum.mista.ru/rules.php  пункт 6).

(34) "не разворачивается локально..." - не надо "локально", у Вас есть 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 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими.

(40)  на отдельном сервере развернули SQL. развернули там последний нормальный dt.
Со сбойной базы в Постгре сохраняю конфигурацию.
Ею замещаю конфигурацию на развернутом SQL. где последний dt.
Обновляю все документы реиндексирую.

пытаюсь загрузить в ТУДА все что выгружено из сбойной Постгре.
Справочники - загружаются. Документы - нет.

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

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

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

подробно:
{ВнешняяОбработка.ВыгрузкаЗагрузкаДанныхXML(147)}: Ошибка при вызове метода контекста (ПрочитатьXML): Ошибка преобразования данных XML: [file://E:/out1/11.05.2017- док1.xml][337308,16]
            ЗаписанноеЗначение = ПрочитатьXML(ЧтениеXML);
по причине:
Ошибка преобразования данных XML: [file://E:/out1/11.05.2017- док1.xml][337308,16]

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

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

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

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

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

Открывала этот файл в редакторе. А что искать то там ?
файл-выгрузка обычный.

в общем, я в диком стрессе ...

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

(49) во во.чел дело говорит

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

(48) Та же ошибка, это какая?
"Ошибка преобразования данных XML: [file://E:/out1/11.05.2017- док1.xml][337308,16]"
Означает, что проблема в 16 символе 337308 строки.

НайтиНедопустимыеСимволыXML() по этому файлу что показывает?

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

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

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

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

А то что Вы делаете это творчество.
За такое творчество на работе надо штрафовать.

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

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

(57)
Это проблема.

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

Начальник сделает что надо.

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

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

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

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

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

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

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

Написал обработку, которая анализировала журнал регистрации и использовала его в качестве фильтра при выгрузке и загрузке данных...

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

Не буду спорить. Каждому своё. Оно по всякому бывает.

Предложи я, например, отделу логистики вновь набить документы за два дня работы - меня тут же выкинут за ворота :) Хорошо если не из окна :))
Глупо думать что они там сидят без работы и ждут меня, когда я её им предложу :))

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

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

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