Здравствуйте уважаемые форумчане!
Возникла следующая проблема. Выполнял восстановление базы методами postgresql все прошло успешно, база работает, но возникла проблема.
Имеется отчет, после восстановления формируется невероятно долго (Несколько часов) до восстановления было все отлично. Про оптимизацию прошу не писать т.к. при восстановлении этого дампа в другую базу отчет выполняется как было до восстановления (несколько секунд). Вопрос в том, что можно сделать (на уровне 1с или постгреса) с базой. Делал реиндекс из 1с, сейчас выполняется реиндекс средствами постгрес + вакуум. Восстановить по новой не предлагать т.к. дамп 5 дневной давности, и в базу были внесены множество записей и изменений (проблема с отчетом вылезла накануне). Тестирование и исправление запускал, но к сожалению ночи не хватило, чтобы оно выполнилось на 100%. Прошу палками и помидорами не кидать, понимаю, что нужно в первую очередь выполнить тестирование и исправление. Но возможно кто нибудь сталкивался с подобным, и подскажет в какую сторону копать. П.С. База 100% самописка

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

реиндекс не завершился, чего ты от базы хочешь?

из всего громкого названия ТИИ нужен только реиндекс и больше ничего.

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

(0) Переиндексация в PostgreSQL, ТИИ в 1С (переиндексация, пересчет итогов, реструктуризация)

(0) ANALYZE;

"ТИИ запускал, но к сожалению ночи не хватило, чтобы оно выполнилось на 100%"
Я не фанат РИБ... а может быть уже и стал им :) но для меня не проблема поднять РИБ альтернативным вариантом из двух узлов - центральный (ЦУ) и подчиненный ПУ); выгнать пользователей работать в ПУ и никуда не спеша - восстановить базу ЦУ.
Сколько надо ТС на ТИИ? Сутки/двое? Нет проблем - РИБ регистрирует все изменения в ПУ и в любой момент готов перегрузить их в ЦУ сеансом обмена. Когда база ЦУ будет восстановлена, а базы узлов синхронизированы - юзвера перегоняются из ПУ в ЦУ и РИБ можно удалить.
Хотя я бы этого не стал делать (раз уж РИБ поднят) - РИБ удобен ещё тем, что снимает некоторые проблемы архивирования, проведения длительных операций, получение монопольного доступа и т.д.

Всем спасибо большое за ответы! Про РИБ - уже валяются два сервака с настроенной РИБ - ждут своего часа с переносом лицензии. Еще раз всем спасибо!

К сожалению реиндекс не помог, отчёт работает по обекту задачи. в таблице записей 600-700к как можно не писать обработку а перенести задачи из одного дампа в другой? Или какие есть ещё варианты?

перенос таблиц tasks напрямую из базы где отчёт формируется норм не принёс результатов((( как быть?

Ничего понять не могу, для одного объекта отчёт формируется нормально, для других нет. Мистика...

Попробуй сделать замеры в отладке. Возможно, увидишь неоптимальный фрагмент

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

(11) ну для разных периодов пробуйте. найдите конкретную секунду, на которой отчет глючит.