FB 1.5.2: проблема с восстановлением базы

[Boris Kuritsin]

Недавно перешел на версию 1.5.2 с 1.5.1.
Сегодня обнаружил, что любой сделанный в новой версии бекап базы нельзя восстановить:

...
gbak: restoring privilege for user DBADMIN
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

это не зависит от наличия ключа -NO_VALIDITY

через IBExpert ситуация аналогичная.

ODS 10.1
Page size = 8k
формат бекапа - transportable
сама база в порядке и нормально проходит validate full

Посоветуйте, что делать, возвращаться на версию 1.5.1?
Заранее благодарю за ответ.

[Merlin]

Недавно перешел на версию 1.5.2 с 1.5.1.
Сегодня обнаружил, что любой сделанный в новой версии бекап базы нельзя восстановить:

...
gbak: restoring privilege for user DBADMIN
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

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

select * from rdb$user_privileges UP
where
UP.rdb$object_type<>13
and
not exists(select 1 from rdb$relations RL where RL.rdb$relation_name=UP.rdb$relation_name)
and
not exists(select 1 from rdb$procedures PR where PR.rdb$procedure_name=UP.rdb$relation_name)

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

[kdv]

исправление для

gbak: ERROR: could not find table/procedure for GRANT
gbak: Exiting before completion due to errors

есть, но в код не попало. уж не знаю, Джим в restore.e этот код писал или еще кто, но если нет объекта, для которого ресторится грант, выдается вот такая идиотская ошибка (хотя должен быть warning с игнорированием). Причем упомянутый тобой запрос может ничего и не отловить...

[Merlin]

Причем упомянутый тобой запрос может ничего и не отловить...

Имеешь в виду убитые роли? Остальное мне каатся должен всё взять - поля, таблицы, вьюхи, процедуры. С ролями тоже можно разобраться в отдельности, запрос похожий, если сам не дотумкает - подскажем. В случае ломных баз и паники меня не ломает и доку вслух почитать

[kdv]

роли не имею в виду. как раз ДЕ делал для меня спец-gbak когда ни ролей не было, ни гранты без объектов не отлавливались. но ошибка была. это еще было на IB 6.5, gbak тогда подошел от FB 1. Чего ДЕ не вструмил это в основной код - не знаю. Наверное он тогда просто эту обработку ошибки отрубил, а по человечьи сделать потом руки не дошли или забылось.

[Merlin]

роли не имею в виду. как раз ДЕ делал для меня спец-gbak когда ни ролей не было, ни гранты без объектов не отлавливались.

Могу предположить только битые индексы на системных таблицах в базе-источнике и gbak из-за этого некоторых объектов вообще не видит. Но тогда в базе-приёмнике этих объектов не будет и это видно невооружённым глазом, если это не какие-то рудименты, про которые разработчик сам давно забыл. Кстати, в этом случае запрос надо модифицировать в плане блокирования индексов через ||'' при всех полях в условиях и тогда должен увидеть.

Чего ДЕ не вструмил это в основной код - не знаю. Наверное он тогда просто эту обработку ошибки отрубил, а по человечьи сделать потом руки не дошли или забылось.

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

[kdv]

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

при ресторе-то? когда уже абсолютно точно известно, что этого объекта в файле бэкапа нет? в этом случае просто ПОЗДНО ерроры выдавать. более того, я настаиваю что этот еррор выглядит ... (мнэээ.. как бы это покультурнее..) несуразно. вот warning - выдавать обязательно, без ключиков. по нему можно определить, что в исходной базе что-то не так, и что в файле бэкапа чего то недостает.

[Merlin]

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

при ресторе-то? когда уже абсолютно точно известно, что этого объекта в файле бэкапа нет? в этом случае просто ПОЗДНО ерроры выдавать. более того, я настаиваю что этот еррор выглядит ... (мнэээ.. как бы это покультурнее..) несуразно. вот warning - выдавать обязательно, без ключиков. по нему можно определить, что в исходной базе что-то не так, и что в файле бэкапа чего то недостает.

Не согласные мы. Тогда што - по умолчанию и констрайнты на ресторе не контролировать? Уже абсолютно точно известно, что они в файле бакапа нарушены Имею Мнение Хрен Оспоришь - по умолчанию рестор должен быть предельно жёстким в отношении всех нарушений, чтобы не прозевать их. То есть, либо выдавать хорошую базу, идентичную источнику, либо сливать. А вот ключиками в ис-ключительных случаях его смягчать с целью спасения того, что спасти можно. А то, знаешь, админ спит, служба идёт, и вот - случилось страшное (С). Фигня, у нас вчерашний рестор есть, а глядь - опаньки, да тут же половины таблиц нету. То же и с констрейнтами - не прошёл через них рестор - значить, пора засучивать рукава и с базой разбираться. А вот если разбираться уже не с чем - смягчить и разбираться с тем, что получится.

[kdv]

ыыыыы. давай про конкретный случай.
бэкапим базу. gbak не ругается.
ресторим. идет ругань (ОШИБКА!) при восстановлении базы, если нет объекта, на который якобы есть грант (в бэкапе).

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

дальше. допустим, повредились индексы на сист. таблицах или действительно удалось удалить объект так, что грант на него остался. И ? я никак в толк взять не могу, чем-таким в результате файл бэкапа провинился. Ну не попали в него объекты. так оно ж не может сказать при ресторе, что вот мол, нету у тебя такой таблицы! И определить, почему ее не оказалось, тоже не в состоянии. То ли ее уже нет, то ли она была но в бэкап не попала.

Так что ключики нафиг, и в этом конкретном случае выводить warning вместо error. А админ уже имея ресторенный бэкап в кармане разберется, копать ему оригинальную базу на предмет повреждений, забить на эти "лишние гранты", али заливаться горючими слезами у незаресторенного путем бэкапа. Ок?

[kdv]

я это к чему - базы нонче большие пошли. пока админ сообразит, что ключик ignore warnings или еще какой не указал, ему базу придется ресторить повторно. А рестор и так не быстрый, сам знаешь.

то есть - в нынешнем функционале gbak при ресторе часть ошибок надо исправить на warnings, а часть - игнорировать посредством специального ключика. Конкретная ошибка сейчас и с ключиком присутствует.

[Merlin]

И ? я никак в толк взять не могу, чем-таким в результате файл бэкапа провинился. Ну не попали в него объекты. так оно ж не может сказать при ресторе, что вот мол, нету у тебя такой таблицы! И определить, почему ее не оказалось, тоже не в состоянии. То ли ее уже нет, то ли она была но в бэкап не попала.

Так что ключики нафиг, и в этом конкретном случае выводить warning вместо error. А админ уже имея ресторенный бэкап в кармане разберется, копать ему оригинальную базу на предмет повреждений, забить на эти "лишние гранты", али заливаться горючими слезами у незаресторенного путем бэкапа. Ок?

ыыыыы 2 раза. Это ТЕБЕ я должен рассказывать, как люди относятся к ворнингам. 95% админов доведут базу до состояния полного мусора даже при условии еженощного b/r и не спохватятся, если на них не заорать в момент обнаружения первой же неприятности - еррор, мать твою, не спи! И вот тогда уже обложится докой, разберётся что за еррор и примет меры. И посидит сколько нужно, держа руку на пульсе. Это я тебе как раз говорю как владелец базы, ресторящейся 7 часов. Именно посокольку она мне дорога, я настаиваю на жёсткости b/r как регулярной рутинной диагностической процедуры. Лично я категорически не готов просматривать ежедневно с утра логи жбака, мне есть чем заняться. И не верю что админ будет этим прилежно заниматься, у него делов тоже хватает. А когда в мыле у всего отдела "restore unsuccessfull", то весь отдел тоже в мыле, только в другом

ЗЫ Мы тут с тобой очень приятственно и привычно с разных позиций на эту тему беседуем, а зачинателю топика это всё похоже уже неинтересно

[Лысый]

ЗЫ Мы тут с тобой очень приятственно и привычно с разных позиций на эту тему беседуем, а зачинателю топика это всё похоже уже неинтересно

Зато другим интересно Я например, так и не решил для себя что лучше: варнинги и восстановимый бакап или ерор и иди кури доку

[Boris Kuritsin]

select * from rdb$user_privileges UP
where
UP.rdb$object_type<>13
and
not exists(select 1 from rdb$relations RL where RL.rdb$relation_name=UP.rdb$relation_name)
and
not exists(select 1 from rdb$procedures PR where PR.rdb$procedure_name=UP.rdb$relation_name)

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

Исполнил упомянутый запрос – результат пустой. Но упомянутая в треде ситуация с установкой прав и на таблицу, и на отдельные ее поля как раз возможна, и, по-моему, в этой базе присутствует.

Относительно возможного повреждения БД могу же сказать следующее: базе backup/restore делал я как раз совсем недавно, то ли непосредственно до апгреда версии сервера, то ли сразу после него – точно не помню. До этого restore точно работал, поскольку я неоднократно носил из офиса домой бекап базы и там ресторил без проблем, но это было на версии 1.5.1. Как раз поэтому я скорее как-то посмотрю на новую версию сервера криво, чем на базу.

Большое спасибо за участие в моих проблемах. Может, еще чего посоветуете?

[Boris Kuritsin]

ЗЫ Мы тут с тобой очень приятственно и привычно с разных позиций на эту тему беседуем, а зачинателю топика это всё похоже уже неинтересно

Отжего же Весьма интересно... Вот бы еще проблему решить, тогда вообще

[Boris Kuritsin]

Причем упомянутый тобой запрос может ничего и не отловить...

Имеешь в виду убитые роли? Остальное мне каатся должен всё взять - поля, таблицы, вьюхи, процедуры. С ролями тоже можно разобраться в отдельности, запрос похожий, если сам не дотумкает - подскажем. В случае ломных баз и паники меня не ломает и доку вслух почитать

Уж подскажите не время счас системные таблицы изучать - сначала надо проблему разрешить...

[dimitr]

Дискуссия развернулась довольно интересно, но зачастую конкретная проблема автора темы решается установкой (или снятием?) флажка "commit after each table" во время рестора.

[kdv]

а природа исправления этой ошибки путем commit each table... ?

[dimitr]

Это ж надо в отладчик лезть... а влом... ))

Не знаю пока причины. Но наблюдаю ежедневно на болтиковской базе и еще на какой-то. Как разберусь - доложу.

[Merlin]

Причем упомянутый тобой запрос может ничего и не отловить...

Имеешь в виду убитые роли? Остальное мне каатся должен всё взять - поля, таблицы, вьюхи, процедуры. С ролями тоже можно разобраться в отдельности, запрос похожий, если сам не дотумкает - подскажем. В случае ломных баз и паники меня не ломает и доку вслух почитать

Уж подскажите не время счас системные таблицы изучать - сначала надо проблему разрешить...

select * from rdb$user_privileges UP
where
UP.rdb$object_type=13
and
not exists(select 1 from rdb$roles RL where RL.rdb$role_name=UP.rdb$relation_name)


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

select * from rdb$user_privileges UP
where
UP.rdb$object_type=13
and
not exists(select 1 from rdb$roles RL where RL.rdb$role_name||''=UP.rdb$relation_name)

Запрос, о котором говорил в прошлый раз, в случае того же подозрения:

select * from rdb$user_privileges UP
where
UP.rdb$object_type<>13
and
not exists(select 1 from rdb$relations RL where RL.rdb$relation_name||''=UP.rdb$relation_name)
and
not exists(select 1 from rdb$procedures PR where PR.rdb$procedure_name||''=UP.rdb$relation_name)


Процедура для перестройки системных индексов (крайняя мера, к живым базам применять не рекомендуется). Выполнить 2 раза, сначала Execute Procedure Rebuild_Sys_Indices(1), затем COMMIT, затем Execute Procedure Rebuild_Sys_Indices(0), опять COMMIT :

Create Procedure Rebuild_Sys_Indices(Activity_Flag Int)
As
Declare Variable Index_Name Char(31);
Begin
For Select RDB$INDEX_NAME From RDB$INDICES
Where RDB$INDEX_NAME||'' Starting 'RDB$'
Into :Index_Name
Do
Update RDB$INDICES Set RDB$INDEX_INACTIVE=:Activity_Flag
Where RDB$INDEX_NAME||''=:Index_Name;
End

Если всё это шаманство не помогает, то, возможно, дело в повреждении таблицы RDB$SECURITY_CLASSES. Учить её чинить по переписке я не возьмусь. Кстати, owner менять хакерскими методами у объектов в базе не пытался? Такие попытки при неверной последовательности действий ведут к её повреждениям.

[Merlin]

Это ж надо в отладчик лезть... а влом... ))

Не знаю пока причины. Но наблюдаю ежедневно на болтиковской базе и еще на какой-то. Как разберусь - доложу.

А достаточно простые базы с такими глюками есть? А то с болтиковской и отладчиком - да...