Имя: Пароль:
1C
1С v8
Упала база на postgresql
0 Ivan093
 
10.11.14
17:21
Доброго времени суток! Хотя у кого доброе, у кого не очень.
У клиента упала база. Получилось так, что кривой админ настроил бэкапы на тот же диск с базами, бекапы забили весь диск. Я стал накатывать изменения, место кончилось, 1с вылетела. Теперь в конфигуратор не заходит, ошибка:
Попытка получения не инициализированного параметра сеанса.

В обычном режиме тоже не заходит, ошибка:
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call/cb747d24-6d8a-4d97-8a13-305ee6f39f75/d5963243-262e-4398-b4d7-fb16d06484f6:
по причине:
Ошибка SDBL:
Таблица CommonSettings не имеет нового поколения и не может быть модифицирована

Что пробовал: копировать таблицы config, configsave из тестовой базы, там разница в конфе в пару реквизитом. Не помогло :(
Бекапы 3-х недельной давности, т.к. места не хватало под бэкапы давно, а база растет не быстро.
Что еще можно попробовать для восстановления базы?
1 Wirtuozzz
 
10.11.14
17:23
Пулю в колено сисадмина. Предлагаю взбодрить его хорошенько.
2 пипец
 
10.11.14
17:25
перед танцами с бубном сделать бэкап
вторым пунктом почистить кеш
3 bolero
 
10.11.14
17:27
для начала запустить базу pgsql с LC_MESSAGES=en_US.UTF-8, т.к. сообщение про новое поколение не вяжется со здравым смыслом

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


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

затем в postgresql.conf выставить параметр log_statement в ddl или all и пытаться найти, какой именно запрос обваливается среди мегабайтов лога
4 elCust
 
10.11.14
17:27
1) ...кривой админ настроил бэкапы на тот же диск с базами...
2) ... Я стал накатывать изменения...

Чего то не хватает меж этими действиями.
5 chudishe
 
10.11.14
17:29
(0) А очистить место на сервере пробовал?
6 Ivan093
 
10.11.14
17:44
место почистил первым делом, вторым кэш, третим сделал бекап битой базы
7 Ivan093
 
10.11.14
17:46
кто виноват предлагаю не обсуждать. надо попробовать восстановить базу, админу будет урок, да и мне ))
все осложняется, что человек кто ставил скуль недоступен, а я с постгре не работал. В мс скуле попробовал бы что-то сделать.
Да и здесь пробую, но пока безрезультатно
8 bolero
 
10.11.14
17:49
(3) похоже, это не pgsql выдает такое сообщение, а сама 1С
9 Ivan093
 
10.11.14
17:52
думал ругается на таблицу _commonsettings , очистил ее (бэкап есть), не помогло
10 bolero
 
10.11.14
17:55
(9) кмк поломалась структура в конфигурации посреди обновления, т.е. еще до уровня базы
11 Ivan093
 
10.11.14
18:12
(10) да мне тоже так показалось. Но почему тогда не помогает копирование конфигурации из тестовой?
12 bolero
 
10.11.14
18:54
возможно, в журнал обновления (т.е., данные) уже записана история изменений, что таблица должна быть новой а в конфигурацию не успело

/me в таких вопросах не силен

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

админу действительно колено прострелить за такую организацию бэкапов
13 Ivan093
 
14.11.14
07:03
Базу удалось восстановить. Поигрался с таблицами конфы, удалил таблицы dbchanges? dbchangesog и еще какую-то.
14 ifso
 
14.11.14
07:33
ну и про судьбу админа расскажи )
15 Мимохожий Однако
 
14.11.14
07:38
Надеюсь, теперь бэкапы делаются на другой диск.
(14)ИМХО. Его не было. Был "малчик", который убежал давно после установки.
16 ifso
 
14.11.14
07:44
(15)
> который убежал
у батареи смотрели?)
17 Ivan093
 
14.11.14
16:42
Админ внештатный, как собственно и я. Что там с ним сделали, не знаю, может у батареи сидит :) Когда им базу восстановил, они, наверное, всем офисом плясали :) Рассказал что бекапить нужно на другой диск или комп. Будут исправлять бекапирование.
18 N1kMZ
 
14.11.14
16:47
(17) Лучше научиться делать бекап перед "накатыванием изменений"