По теме из базы знаний
- Восстановление из архива базы PostgreSQL
- Резервное копирование и восстановление базы 1С средствами PostgreSQL
- Передача баз PostgreSQL на удалённый сервер резервных копий, удобное восстановление. Почасовой и ежесуточный вариант. В общем, ещё один скрипт
- Восстановление базы из DT, если она не хочет восстанавливаться
- Резервное копирование и восстановление 1С баз на PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) AngelVIII, Навскидку:
1.Здесь описывается Ваша ситуация:
2.Вот еще:
3. В Postgre Есть аналог Attach database MS SQL.
Вообщем скорее Да, чем нет... единственное, полагаю, желательно, чтобы конфигурация Postgre была аналогичная. (Возможно это и не обязательно)
1.Здесь описывается Ваша ситуация:
2.Вот еще:
3. В Postgre Есть аналог Attach database MS SQL.
Вообщем скорее Да, чем нет... единственное, полагаю, желательно, чтобы конфигурация Postgre была аналогичная. (Возможно это и не обязательно)
была похожая ситуация с mssql, также рухнул *.ldf, что и составляло всю сложность, восстанавливал с трудом. С журналом и образом восстановить можно парой кликов. Да и там pgadmin есть, можно без написания скриптов обойтись.
(7) Aleksey58, вот что меня удивило, так это бесполезность созданных бекапов. Делаю каждый день копии,а толку от них было 0, ибо ругался, что копии не от той базы, когда пытался накатить на пустую. Получается, что надо еще и mdf+ldf образы держать где-нибудь про запас.
(8) Melius, ну ты меня размешил, представь такую ситуацию, захотелось электрикам в шиток залезть пробросить отдельную линию, и рубят все электричество, а железо у тебя нехати и система на серваке летит, или винты убитые, и что ты после этого будешь делать? если у тебя вчерашней копии нету, останется только "сматывать удочки" :D, да и бекап не сам вручную делаешь и зачем это забивать голову. У некоторых БД на дню делается копия по несколько раз.
(9) Aleksey58, какая-то бессвязная речь.
(10) pablo_escobar, конечно. Я там вертел как мог. Все это произошло ночью, перемещал базу на новые винты, ldf благополучно затерся. Что я там только не пытался сделать. Не хотели бекапы восстанавливаться и все. То одна ошибка, то другая, все, база не встает, утром будет полный П. Спасло только это, но к тому времени волосы у меня уже на половину поседели:
(10) pablo_escobar, конечно. Я там вертел как мог. Все это произошло ночью, перемещал базу на новые винты, ldf благополучно затерся. Что я там только не пытался сделать. Не хотели бекапы восстанавливаться и все. То одна ошибка, то другая, все, база не встает, утром будет полный П. Спасло только это, но к тому времени волосы у меня уже на половину поседели:
use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
alt er database <db_name> set emergency, single_user
GO
DBCC CHECKDB (<db_name>, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO
alt er database <db_name> set online, multi_user
go
Показать
(12) Melius, Это не могло помешать, я бекап MSSQL2005 со старого сервера, на новом сервере MSSQL2012 разворачивал без проблем. Может бекап был порченный? У меня такое было раз, при копировании на другой сервак бекапа и обратно портились бекапы, но только одной базы(самая большая где-то 20 гигов), но потом нормально все стало, списали на 2012 винду(до нее была 2008 все было нормально), она тогда еще только вышла. Причем копировался этот файл не всегда с первого раза. Хотя тогда MSSQL говорил что-то, что бекап поврежден.
многие говорят, что имея просто папку с OID базы никак её не прикрутить, но вот если есть вся папка data, тогда можно.
попал в ситуацию - из корректных данных осталась только папка "base"
удалось руками создать в Postgres базу с таким же OID
подсунул папку данных
выгрузить архив не дает
ошибки:
pg_dump: error: query failed: ERROR: relation "public._yearoffset" does not exist
pg_dump: error: query was: LOCK TABLE public._yearoffset IN ACCESS SHARE MODE
из консоли 1С-Сервера достучаться до базы тоже не удается:
"Ошибка создания информационной базы.
Ошибка операции администрирования"
Ошибка при выполнении операции с информационной базой
нарушено условие уникальности данных.
Попытка вставки неуникального значения в уникальный индекс:
23505: ERROR duplicate key value violates unique constraint "pg_proc_proname_args_nsp_index"
DETAIL: Key (proname, proargtypes, pronamespace)=(datediff2, 1043, 1114 1114, 2200) already exists.
может не все потеряно с моей базой?
можете помочь?
попал в ситуацию - из корректных данных осталась только папка "base"
удалось руками создать в Postgres базу с таким же OID
подсунул папку данных
выгрузить архив не дает
ошибки:
pg_dump: error: query failed: ERROR: relation "public._yearoffset" does not exist
pg_dump: error: query was: LOCK TABLE public._yearoffset IN ACCESS SHARE MODE
из консоли 1С-Сервера достучаться до базы тоже не удается:
"Ошибка создания информационной базы.
Ошибка операции администрирования"
Ошибка при выполнении операции с информационной базой
нарушено условие уникальности данных.
Попытка вставки неуникального значения в уникальный индекс:
23505: ERROR duplicate key value violates unique constraint "pg_proc_proname_args_nsp_index"
DETAIL: Key (proname, proargtypes, pronamespace)=(datediff2, 1043, 1114 1114, 2200) already exists.
может не все потеряно с моей базой?
можете помочь?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот