|
Бэкап постгри 1С базы | ☑ | ||
---|---|---|---|---|
0
antihacker
01.07.19
✎
12:47
|
Всем привет ! Есть база 1С на постгри. Делаю бэкап. Бэкап проходит с предупреждениями
pg_dump: [sorter] ПРЕДУПРЕЖДЕНИЕ: не удалось разрешить цикл зависимостей для следующих объектов: pg_dump: [sorter] DUMMY TYPE __document70_vt161_intkeyind (ID 1208 OID 278566) pg_dump: [sorter] DUMMY TYPE _document70_vt161_intkeyind (ID 2976 OID 278567) pg_dump: [sorter] INDEX _document70_vt161_intkeyind (ID 8410 OID 278565) pg_dump: [sorter] POST-DATA BOUNDARY (ID 9300) pg_dump: [sorter] TABLE DATA config (ID 8929 OID 258801) pg_dump: [sorter] PRE-DATA BOUNDARY (ID 9299) Что н так ? |
|||
1
Cyberhawk
01.07.19
✎
13:11
|
Кто ж знает
|
|||
2
ansh15
01.07.19
✎
16:23
|
Жаловались, не так давно https://www.linux.org.ru/forum/admin/14704848
Сам тоже такое видел. Получилось после того, как сделал vacuum full, а потом сразу выгрузил pg_dump-ом. В новую пустую базу с другим именем загрузилось без ошибок и pg_dump потом тоже ошибок не выдавал. В этой базе, заново созданной с этим же именем, и загруженными данными хоть pg_admin, хоть из *.dt, ошибка возникала. Поступил согласно совету "Если компьютер работает плохо, переустановите Windows" - удалил кластер PostgreSQL, инициализировал заново, залил базу из .dt. Больше такая ошибка не возникала. Что там было - непонятно. |
|||
3
antihacker
02.07.19
✎
08:32
|
Да что то такое есть. Если создать новую базу и поднять с бэкапа там и его же бэкапить, то ошибок нет. По ходу pg_dump убирает несогласованные вещий.
|
|||
4
Провинциальный 1сник
02.07.19
✎
08:34
|
Лучше бы 1с поддерживала fb/ib вместо постгреса..)
|
|||
5
Фрэнки
02.07.19
✎
08:45
|
(4) и чем интербэйс был бы лучше?
|
|||
6
Сияющий в темноте
02.07.19
✎
08:46
|
(4)эти товарищи-версионники,и они имеют свою специфику,причем,из-за версионности и хранения незавершенных транзакций в самих страницах таблиц эти ребята тормозят на пустом месте(буквально,удаляем все из таблицы,а потом select count,и видит как "жареный петух" клюется).
ну и замечательный событийный интерфейс для пинания клиента с сервера из коробки 1с просто не готова переварить. |
|||
7
Фрэнки
02.07.19
✎
08:47
|
Но вообще, гипотетически допускаю, что кроме уже существующих форматов баз могут в новых релизах вывести еще что-то.
Например, и вовсе свой собственный файловый режим довести до нормальной многопользовательской работы. |
|||
8
ice777
02.07.19
✎
09:27
|
(4) fb/ib еще и не рассчитаны на базы приличных размеров. По крайней мере так было.
|
|||
9
Провинциальный 1сник
02.07.19
✎
09:49
|
(8) Да нет, всё нормально они рассчитаны. У них проблема действительно в том что могут затупить на сборке мусора. Но вакуум в постгресе - примерно та же фигня.
|
|||
10
Провинциальный 1сник
02.07.19
✎
09:50
|
+(9) Зато бэкапить и восстанавливать одно удовольствие, никаких "кластеров": одна база - один файл.
|
|||
11
ansh15
21.07.19
✎
02:34
|
+(2) В общем, это не из-за vacuum. Ситуация возникает после реструктуризации таблиц в ТиИ. После нее pg_dump начинает выдавать такие предупреждения. И похоже, такое происходит в версии платформы 8.3.14. Ни в версии 8.3.15, ни в более ранних(< 8.3.14) этой ситуации не наблюдается.
|
|||
12
rphosts
21.07.19
✎
08:22
|
(2) не могло помимо создания бэкапа чего-то в базе изменяться сеансами пользователей/регламентными?
|
|||
13
rphosts
21.07.19
✎
08:29
|
(4) у нас на fb база проходной перко (одна на все филиалы)... раз в год ей устраивают обрезание ибо не тянет ни в какую...
Fb на что-то серьёзное ставить - получать кучу проблем на пустом месте |
|||
14
ansh15
21.07.19
✎
10:20
|
(12) Нет, специально эксперимент проводил, на копии. Ни пользователей, ни регламентных, все выключено. После реструктуризации останавливал сервер приложений, чтобы ничего не мешало. До нее сообщений не возникало.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |