Форум: "Базы";
Текущий архив: 2006.03.26;
Скачать: [xml.tar.bz2];
ВнизОшибка при восстановлении БД Firebird Найти похожие ветки
← →
LineSoft © (2006-01-26 18:16) [0]Пожалуйста, поделитесь опытом в решении подобного рода проблем:
gbak: restoring privilege for user SYSDBA
gbak: ERROR: action cancelled by trigger (0) to preserve data integrity
gbak: ERROR: could not find table/procedure for GRANT
gbak: Exiting before completion due to errors
Что можно сделать? База живая.
← →
DSKalugin © (2006-01-26 18:32) [1]я так понимаю, триггер удалили, а права на него остались?
перед бэкапом сделай проверку базы на повреждения.
gfix -v -full database.gdb
подробности тут
http://www.ibase.ru/devinfo/db_repair.htm
← →
linesoft © (2006-01-26 18:37) [2]>триггер удалили, а права на него остались?
да
>перед бэкапом сделай проверку базы на повреждения.
>gfix -v -full database.gdb
это делали, не помогло
← →
linesoft © (2006-01-26 19:25) [3]Вообще говоря, удаляли таблицу.
И гбак о том же говорит.
Ни разу не видел отдельных грантов на триггеры
← →
linesoft © (2006-01-26 19:46) [4]DSKalugin © (26.01.06 18:32) [1], спасибо за ссылку, почитал про глюки gbak.
Но причина сбоя была, видимо, в другом. Хотя не факт, проверим после того, как народ уйдет. Учебную базу вроде запустили
← →
DSKalugin © (2006-01-26 20:23) [5]Если помнишь имя триггера попробуй снять права вручную
revoke all on триггер FROM юзер или таьлица к которой он принадлежал
← →
linesoft © (2006-01-27 10:36) [6]Gbak сыпал разные ошибки, кроме этой еще на арифметические операции жаловался. Подсказали на др. форуме, чтобы проверили таблицы с COMPUTED BY. Нашлась одна ненужная, после исправления дело сдвинулось.
А по запросам, которые рекомендовали на rdb$user_privileges, ничего не нашли.
← →
DSKalugin © (2006-01-28 15:44) [7]>gfix -v -full database.gdb
это делали, не помогло
А оно и не поможет :-)) Это проверка, а не лечение
надо сделать
gfix -mend -full -ignore database.gdb пометить сбойные участки
gbak -g -ig сделать бэкап без сборки мусора и без сбойных участков
gbak -c создать базу из бэкапа
← →
linesoft © (2006-01-30 19:45) [8]Дмитрий, спасибо большое, будем иметь в виду.
Пока и так нормально отрабатывает по расписанию. Лучше не трогать :)
← →
jack128 © (2006-01-30 23:24) [9]linesoft © (30.01.06 19:45) [8]
Пока и так нормально отрабатывает по расписанию. Лучше не трогать
хе, что значит работает? То что база работает - еще ничего не означает, когда нить её всё равно из бекапа нужно будет востанавливать, вот тогда ты и огребешь ;)
← →
linesoft © (2006-01-31 10:11) [10]jack128 © (30.01.06 23:24) [9]
>что значит работает?
значит ежедневно отрабатывает backup-restore по расписанию без сбоев.
← →
Sergey13 © (2006-01-31 10:15) [11]2 [10] linesoft © (31.01.06 10:11)
Я надеюсь restore по расписанию не в рабочую базу?
← →
linesoft © (2006-01-31 14:24) [12]нет
← →
DSKalugin © (2006-01-31 14:34) [13]
> ежедневно отрабатывает backup-restore по расписанию без
> сбоев
В этом нет никакого смысла при правильной организации работы с транзакциями. Сборка мусора наступает автоматически после 20000 транзакций.
Я, например, по расписанию ежедневно делаю только бэкап со сборкой мусора. Рестор - риск. Это лучше делать под контролем, а не по расписанию
← →
Sergey13 © (2006-01-31 14:45) [14]2[13] DSKalugin © (31.01.06 14:34)
> Рестор - риск.
В рабочую БД - это не риск, а отложенное самоубийство. В другую БД - единственный способ убедиться в успешности бэкапа.
ИМХО.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2006.03.26;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.037 c