Загадочный owner...
Модератор: kdv
Загадочный owner...
Предисловие: Отресторил БД от имени другого пользователя -> другой пользователь - владелец БД.
System Info: FB CS 1.5.2
Вопрос(ы):
1. Владелец БД <> владелец существовавших ранее в ней объектов. Почему?
2. Как "относительно безболезненно" сменить владельца существующих объектов БД стандартными средствами?
System Info: FB CS 1.5.2
Вопрос(ы):
1. Владелец БД <> владелец существовавших ранее в ней объектов. Почему?
2. Как "относительно безболезненно" сменить владельца существующих объектов БД стандартными средствами?
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Загадочный owner...
1. Не знаю. Может разработчики ответят или ещё кто-нибудь более сведущий.
2. Стандартные средства - это какие? Можно выгрузить базу в скрипт и соответственно создать новую базу от имени "правильного" владельца. Но я просто делал update RDB$RELATIONS set RDB$OWNER_NAME = "Новый владелец"
После чего опять backup/restore от имени нового владельца.
2. Стандартные средства - это какие? Можно выгрузить базу в скрипт и соответственно создать новую базу от имени "правильного" владельца. Но я просто делал update RDB$RELATIONS set RDB$OWNER_NAME = "Новый владелец"
После чего опять backup/restore от имени нового владельца.
А почему не воспользоваться недокументированными возможностями и не поправить процедурой RDB$USER_PRIVILLEGE и связанные с ней другие системные таблицы?Dimitry Sibiryakov писал(а):Простой путь: пересоздать БД из скриптаю
Вряд ли такие поклоны и кувырки в ноги к чему-то приведут...Dimitry Sibiryakov писал(а):Сложный путь: погуглить на предмет Owner Migration и падать в ноги автору чтобы осчастливил утилькой.
Re: Загадочный owner...
Хотя подобные идеи и бродили у меня в голове, все равно, благодарю за сопричастность.Slavik писал(а):1. Не знаю. Может разработчики ответят или ещё кто-нибудь более сведущий.
2. Стандартные средства - это какие? Можно выгрузить базу в скрипт и соответственно создать новую базу от имени "правильного" владельца. Но я просто делал update RDB$RELATIONS set RDB$OWNER_NAME = "Новый владелец"
После чего опять backup/restore от имени нового владельца.
Я пока не теряю надежды, что все-таки существует лучшее и более элегантное решение.
Общий вопрос ко всем, кто интересуется топиком:
Какой смысл в в самостоятельном понятии "владелец БД", если таковым может быть любой пользователь, восстановивший базу? Не могу взять в толк, какой от него "особенный прок", который нельзя было бы получить другим способом?
ЗЫ. Прошу прощение за дотошность, но очень уж хочеться основательно разобраться во всех этих кренделях небесных!
Какой смысл в в самостоятельном понятии "владелец БД", если таковым может быть любой пользователь, восстановивший базу? Не могу взять в толк, какой от него "особенный прок", который нельзя было бы получить другим способом?
ЗЫ. Прошу прощение за дотошность, но очень уж хочеться основательно разобраться во всех этих кренделях небесных!
Последний раз редактировалось Naidenov 06 ноя 2007, 16:43, всего редактировалось 1 раз.
Отправить базу в шатдаун, подключиться к ней после этого, снять бэкап с работающей базы может только владелец (сисдба не в счёт)Naidenov писал(а):Какой смысл в в самостоятельном понятии "владелец БД", если таковым может быть любой пользователь, восстановивший базу? Не могу взять в толк, какой от него "особенный толк", который нельзя было бы получить другим способом?
Об этом обо всем я читал Непонятна была практическая необходимость "введения" самостоятельного понятия "владелец БД". Проще говоря, на кой ляд лудить мозк какими-то "особенными" пользователями вроде владелец БД, если на практике толку от него, как от козла молока, а все его "супер функции" могут быть преспокойно выполнены кем-то другим (кроме сисдба)!kdv писал(а):владелец БД это аналог sysdba, и не обязательно автор метаданных. Понятно? Например, VASYA может создать таблицу или процедуру, и он будет ее автором, но он не будет владельцем БД. А владелец БД не станет после рестора автором этой процедуры.
Прочитав вот это:
Все становиться ясно и понятно!WildSery писал(а):Отправить базу в шатдаун, подключиться к ней после этого, снять бэкап с работающей базы может только владелец (сисдба не в счёт)
И все таки остается без ответа мой 2-ой вопрос.
Неужели не существует лучшего и более элегантного решения, кроме как вылить все в скрипт -> залить обратно под другим пользователем(владельцем) (а база то аж 8,2 Гб ), клянчить со слезами на глазах у какого-то дяди супер утилиту или править системные объекты руками???
Неужели не существует лучшего и более элегантного решения, кроме как вылить все в скрипт -> залить обратно под другим пользователем(владельцем) (а база то аж 8,2 Гб ), клянчить со слезами на глазах у какого-то дяди супер утилиту или править системные объекты руками???
Есть.Naidenov писал(а):И все таки остается без ответа мой 2-ой вопрос.
Неужели не существует лучшего и более элегантного решения, кроме как вылить все в скрипт -> залить обратно под другим пользователем(владельцем) (а база то аж 8,2 Гб ), клянчить со слезами на глазах у какого-то дяди супер утилиту или править системные объекты руками???
1. Разобраться в структуре системных таблиц.
2. Понять, что ещё и в каком порядке (это важно) нужно сделать, кроме изменения owner в rdb$relations, чтоб получилось корректно. Или поиском, поиском... Кстати, когда-то и здесь тоже всё расписывал. Но разобраться - надёжней.
3. Если это в силу некоторых причин религиозного характера приходится делать регулярно (вместо того, чтобы сразу создавать и базу и объекты в ней от нужного пользователя), сделать свою утиль и никому не кланяться.
На всё про всё с экспериментами и парой заломанных тестовых базёнок уйдёт полдня максимум. Но проще, конечно, неделю торчать на форуме, может кто разжует. А может и ляпнет не подумавши.
Мне когда-то потребовалось у нескольких объектов владельцев поменять - я за полчаса набросал прогу, генерирующую скрипт для смены владельца методом пересоздания (с учётом зависимостей). Разбираться было лень
Вот только таблицы этим методом долго пересоздаются - через временные таблицы данные льются...
ЗЫ: А "автор" этих объектов получил по шее. Чтоб под SYSDBA больше не создавал ничего.
Вот только таблицы этим методом долго пересоздаются - через временные таблицы данные льются...
ЗЫ: А "автор" этих объектов получил по шее. Чтоб под SYSDBA больше не создавал ничего.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05