Добрый день. Никто не сталкивался с такой ошибкой? Платформа 8.3.9.2033. Пытаюсь обновить бухгалтерию 2.0 и в самом начале конфигуратор валится по данной ошибке. ТИИ тоже не отрабатывает ,на этапе проверки логической целостности выдаёт ту же ошибку - "недостаточно памяти для получения результата запроса к базе данных".

переходи на 64-битный клиент. он позволяет хавнокодить даже тебе

бп типовая. Я так подозреваю, там какая-то табличка побилась и разрослась безмерно. Хз только как узнать.

ловить запрос.править.или искать в опубликованных ошибках

(0)
1. Сколько оперативки?
2. Выгрузить базу можешь?

(4)+ Если штатная выгрузка не проходит то вариант только лечения базы переносом всех данных по каждому объекту метаданных - где то или запорется или нормально перенесется.
Если некий справочник/документ/регистр не выгружается то придется повозиться.

(4) выгрузить могу
оперативки 16к, но сервер 1с 32 битный. Хотя постгрес х64

Обновления лучше делать на x64

при этом, обновление прям в самом начале стопорится.

Ааа тут сервер 32. Тогда все понятно

Ну иди отладчиком и смотри где валится.

(3) какой там запрос при обновлении?

(11)Там он не один.Короче если есть деньги бери 64.Нет то отдай кто может разобраться.

попробую файловую поднять сейчас, мб в постгресе ошибка

(13) нет нигде ошибок. есть слишком много данных

(6) И что, что 32-битный. Это только ограничивает выделенную память для сеанса четырьмя Гб. У меня УПП на 190 человек и куча мелких баз на 64-битном, всего отожрано 3Гб.

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

Типовой релиз своей конфы сравнивал с аналогичным типовым?

выгрузка размером 570 мб где ж там много данных-то

(15) сравнить в самой базе не получается из-за этой же ошибки

(16) Попробуй выгрузить из sql и загрузить в файловую. Затем на файловой на x64 платформе обновить.

(17) значит в каком то запросе происходит ненужное умножение таблиц

я сейчас в файловую гружу

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

да нет никакого запроса

(21) Думаю, вопрос не к автору, а к авторам обновления

Самый прикол был когда не было никаких ошибок в данных/базе.
Но обновление конфы по РИБ (Розница 2) в перифериях не проходило ибо слишком большой XML получался, эти туда засунули кучу-кучу дров внутря конфы так что она в cf занимала >480мб.
Пришлось срочно менять винду на x64 там с трудом но 1С x86  оперативки хватало.

+(21) или с регистратором такое может происходить

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

(0) Тебе бы профайлером послушать базу...

(27) а на постгрес есть профайлер?

(28) там все есть https://www.postgresql.org/docs/current/static/pgstatstatements.html

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

попробуй релиз 1с поменять

Перезапустил сервер чтоб вступили в силу изменения по размеру файла подкачки. База бп2.0 самоубилась и оказалась пустая. Восстановил из вчерашнего бэкапа, пока вроде ошибок нет никаких. Что-то, мне кажется, я где-то накосячил с настройками постгре ещё. 16 гигов оперативки даже без файла подкачки - будет минимум 8 на приложения. 32-х-битный сервер на поток больше 3гб всё равно не выделяет => памяти должно хватать. Посмотрим что после включения подкачки будет. Но вообще, я замечал, что когда запускаешь какой-нибудь огромный отчёт, иногда заканчивается память и больше не отдаётся до перезагрузки агента сервера с постгрешкой.