Не шибко большая база, отработав полтора года на в режиме серверной версии на ПостГре, сделал чпокс. Перестали средствами 1С создаваться архивы, через Постгре архив создать можно, но потом он не распаковывается. Процедуру Реиндексация на постге была выполнена, Вакуум - вылетает с ошибкой - причем закрывая службу работы самого ПостгреСкл. Тестирование исправление базы делать средствами 1С как-то стремно без архива -то. Че дальше то делать? гыыы За все видать нужно платить и за бесплатный продукт ПостГре.
Пока вижу только один путь, пока база запускается и работает побыренькому данные из нее выносить в другую базу...

Бесплатный сыр только в мышеловке. Если используете свободное ПО, то проблемы с ним это ваши проблемы.

можно файлы БД скопировать на остановленном сервере постгре

а вообще - просто так чпокс никто не делает...

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

>>> Перестали средствами 1С создаваться архивы

Выдаются при этом какие-то сообщения?

Второй вариант скопировать базу - перенести данные через ВыгрузкуЗагрузкуДанныхXML.

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

(0) Странно. Архив из ПостГре у нас распаковывался. На Линуксе? Я меня проблемы были только с обновлением. Труднее делать из-за Линукса тоже. И проблемы с СОМ-обменами. А в остальном  жить можно.

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

(8) у вас он распаковался наверное живой базы а не с поломанной структурой, Винда 2003я

(10) Интересно. Скажи, пожалуйста, серверная лицензия 1С для ПостГре нужна?

(10) Зачем на постгре под виндой сидеть-то? Слетает выгрузка в дт-файл, я так понимаю? А перед этим вы установили обновление платформы на клиенте и на сервере?

Ну и кто в этом виноват, кроме 1С-ки, обновляющей версии клиента и сервера приложений?

(11) Конечно нужна.
Лицензия на сервер цепляется к приложению, которое обзывается термином "кластер серверов 1С"
Если же кластер серверов запущен, то в нем уже можно подлючатся к разным СУБД.

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

(0) УПП, ЗУП - риб-базы - на постгрю и 1с:сервер на одном компе под CentOs - три года, полёт нормальный. Да, капризная, Да, не надёжная. Да, были, есть и будут сбои. Но: базу не терял, из архивов не приходилось подниматься.

(15) + в подчиненном узле пользователей не больше десятка. Не вижу смысла тратиться на что-то более, чем бесплатного сыра.

(11) она нужна для 1С Сервера
(12) потому как, бесплатна она!
(15) при распаковке из бекапа на другом Сервере останавливается с ошибкой
(16) пользователей около 20..30, по какой причине крякнула я не скажу, обновлений не делал! так то она работает, логов только много делает, процедуры оптимизации на ней не выполняли, возможно какой-нить кластер на диске полетелел....но больше мне кажется что за базой на постГРЕ нужен уход, в отличии от МсСкл, на них все живет просто отлично.

(17) нужно написать ошибку. Попробовать под линуксом загружать и на х64.

нету в наличии линукса х64, даже просто линукса нет...

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

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

(0) Google пользует PSQL, вроде не жалуется.

(21) ну да, вот было бы куда откатываться, попробую целиком каталог с базой закопировать или диск целиком )))

(0) Врят ли это движок СУБД попортил базу. Скорее всего дело в ручках того, кто с этой базой работал.

Так у вас версия то 32-битная или 64?

(21) Нарушение структуры - это ж немного не то, база не запустится вообще

Используй pgadmin3
Из под него нужно сделать обслуживание (при отключенном сервере 1с предприятия)
Вначале ставишь обе галочки vacuum full и analyze (выполняешь)
потом reindex (выполняешь)
время выполнения операций зависит от размера базы postgresql и версии платформы
начиная с версии 8.4 выполняется на порядок быстрее.

Еще посмотри место на диске, где базы лежат - возможно полностью забито.

Если место забито - значит проблема в логах - возможно ругательства на "/", хотя с версии 9 вредительский параметр изначально отключен.

(26) Смотря какое нарушение структуры. Довольно сачтотак бывает: база - рабочая (в смысле пользователи работают без регистрации ошибок), а файлы .db, .dt и .cf - битые, сбойные, не работоспособные.

(30) "сачтотак" --> "часто так"

(31) жёпь ебрило! попячся!

(17) >>мне кажется что за базой на постГРЕ нужен уход, в отличии от МсСкл, на них все живет просто отлично
v8: Навернулась база 1С 8.1 SQL 2008
v8: как реанимировать базу????
Просто великолепно живет... Не надо вестись на рекламные надписи на коробках, уход нужен за всем.

Вообще надо логи смотреть, обычно там проблема отображается. Помогает еще способ накатить новую версию сервера 1с. А бакап лучше проиводить обоими способами - и 1с, и postgresql.

Вон в последнем релизе исправлены ошибки платформы
Ошибки исправленные в 8.2.15.318
10100226  Постепенная утечка памяти в процессе rphost и rmngr
Проблема:
При каждой установке нового соединения клиентского приложения с процессом кластера или между процессами кластера может безвозвратно увеличиваться объем занимаемой оперативной памяти процессов rphost и rmngr.
Дата публикации:
2012-06-26

10109113  Реструктуризация регистра бухгалтерии
Проблема:
Если в предопределенный счет в плане счетов добавлено субконто и есть движения регистра бухгалтерии с этим счетом в кредите, или есть движения в регистре бухгалтерии без поддержки корреспонденции, то при реструктуризации информационной базы происходит аварийное завершение работы системы.
Дата публикации:
2012-06-26

20005536  Сеансовые данные кластера
Проблема:
В клиент-серверном варианте информационной базы возможно возникновение критичной ошибки, которая может влиять на сохранность данных и стабильность работы системы.
Дата публикации:

Вот вам еще утечками памяти по мозгам. А я то думаю - чего у меня под CentOS память все растет и растет. За такие вещи нужно строго отвечать.

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

Сравнив работы СКЛ 2000, 2005, 2008 , постгре - вывод один МС рулит в плане неприхотливости и надежности, но ДОРОГО.

(35) в 318-й уже не растет, по крайней мере несколько дней держится на одном уровне, починили, значит...

(36) v8: Ошибка базы. HELP.Could not read block 26637 of relation base/50468/3305609: inv
Может пригодится. Выполни еще vacuum verbose( в pgadmin или в psql), чтобы посмотреть на какой таблице валится СУБД, хотя если реиндексация проходит...Посмотри в логе постгрес, что за ошибки пишутся при индексации и вакууме, вакуум может ругаться на временные таблицы и забивать соообщениями лог, особенно если их(таблиц много).

(36) У самих была такая проблема - логи по 10мб за три дня сожрали все место на RAID 10 из SAS (CentOS) (если логи ругаются на этот параметр):
escape_string_warning (boolean)
В случае, если escape_string_warning уставновлен в on выводиться warning сообщение, когда в строках встречается "\" (обратный слэш)
standard_conforming_strings (boolean)
Этим параметром котролируется процесс обработки строк. В случае если этот параметр выставлен в on , строки обрабатываются в соответствии со стандартом (\ - не имеет какого-либо специального значения). По-умолчанию этот параметр выставлен в off, поскольку так уж сложилось, что пг использует обратный слеш как escape-символ для записи специальных символов. Это умолчание будет изменено в будущем, дабы улучшить соответствие стандартам.

Не так выразился, извиняюсь
escape_string_warning = off

standard_conforming_strings не трогай

(39) как все мудрено )))

(42) Судьба такой.

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