Галактика в вопросах и ответах

Одним из пунктов инструкции по переносу БД на новый сервер является следующий

12) Удалить в Microsoft SQL Server Management Studio все динамические хранимые процедуры восстановленной базы данных (Stored Procedures) с префиксами:
DT, EQ, FT, GE, GR, LE, LS, LT, ML, NT, PS, RE
Скрипт для удаления хранимых процедур может быть получен путем выполнения в восстановленной базе данных запроса:
select 'drop procedure '+name from sysobjects where xtype = 'P' and name like '__0___________________________'

Зачем это нужно делать?
Обязательно ли это делать? Может быть есть какие-то допущения, при которых делать необязательно (например, если база данных на новом сервере будет называться также как и на старом или еще что-нибудь подобное...)?
Сколько времени может занять?
Чем чревато, если этого не сделать?

Этот пункт нужно периодически делать и без переноса базы. Галактика создает кучу мелких процедур и со временем это может привести к падению быстродействия.
Впрочем при переносе я делаю обычно по упрощенной схеме - уже вроде писал на форуме как, но это не штатный механизм .

edward_K писал(а):Этот пункт нужно периодически делать и без переноса базы. Галактика создает кучу мелких процедур и со временем это может привести к падению быстродействия.
Впрочем при переносе я делаю обычно по упрощенной схеме - уже вроде писал на форуме как, но это не штатный механизм .

Не подскажете, где описана упрощенная схема?

И все таки, если формально, чистка этих процедур "необходима" или "рекомендована"?

Friendlyman писал(а):И все таки, если формально, чистка этих процедур "необходима" или "рекомендована"?

поскольку переход не частая процедура, лучше сделать её - если рабочий сервер меняется .. а если так побаловаться .. то "рекомеднована"

У нас довольно часто разворачивается БД для тестов и было бы тоже интересно посмотреть на упрощенную схему...

1. Делаем копию базы и восстанавливаем в новую. Удобно написать скрипт для копии/восстановления - при этом вы можете переопределить место хранения данных при восстановлении, особенно удобно, когда файлы базы должны располагаться в других местах или нужно восстанавливать с другим именем.
2.В новой базе в security\login (или «безопасность\имена входа») убиваем пользователя админа, под которым потом будем пробовать входить в систему.
3.Просто в security(то есть уже не базы, а сервера) меняем роли на базу как в рабочей базе. При необходимости меняем пароль в General.
4. Если перенос делается первый раз или нужны новые пользователи, то в рабочей базе сохранить права (сапорт – права доступа) и восстановить с полученного файла права в тестовой базе. Можно также включить SQLDriver.ForceRights =On в support.cfg и перейти к следующему этапу.
А еще проще выполнить в сапорте
select x$users.* to dbf c:\1\x$users;
import x$users from dbf c:\1\x$users nfsr; // ключи важны!
5. На всякий случай пересчитываем права пользователей на базу данных по полной программе.
Повторюсь - это моя личная схема, и вы ей можете пользоваться на свой страх и риск, а этапы 2,3 требуют понимания раздачи прав в SQL(но две картинки сравнить не сложно).
Этапы 2,3,5 делаются выборочно при повторном восстановлении поверх существующей копии базы. Иногда возникают проблемы с паролями - связано это с тем, что пароли пользователей хранятся помимо базы в security сервера и главный вопрос как их туда корректно запихать(они должны совпасть с паролями в базе). Ну еще и вопрос как освободить старую копию базы - но это уже совсем другая тема.

Можно также включить SQLDriver.ForceRights =On в support.cfg и перейти к следующему этапу.
Кажется этого параметра уже нет ?

А еще проще выполнить в сапорте
В старой базе
select x$users.* to dbf c:\1\x$users;
В новой базе
import x$users from dbf c:\1\x$users nfsr; // ключи важны

В документации по переносу БД есть такой чудный пункт.

11) Данный пункт выполняется при перемещении на SQL Server 2005 базы данных, созданной с выключенным флагом Пользователи 2005 (см. п. Установка базы данных, Рис. 11). Для баз данных, созданных с включенной опцией Пользователи 2005 (на SQL Server 2008 существуют только такие БД) этот пункт нужно пропустить и перейти к п.12 данной методики.

Удалить всех пользователей из таблицы sysusers восстановленной БД (за исключением пользователя <NEWUSER>). Для этого необходимо выполнить в Microsoft SQL Server Management Studio следующий запрос:

select 'exec sp_dropalias '''+substring(name,2,128)+'''' from sysusers where name like '\%'
Результатом данного запроса является скрипт, состоящий из запросов вида:

exec sp_dropalias '<User_Name>'
где <User_Name> - имя пользователя. Выполните все сформированные запросы, кроме запроса для пользователя <NEWUSER>.

После выполнения этого скрипта в таблице sysusers должны остаться dbo, guest, public, information_schema, предустановленные роли db_<роль> и новый пользователь.

Может подскажете:
1) как можно понять, какой режим работы с пользователями сейчас в БД?
2) где хранится информация о том, как нужно создавать пользователей, как пользователей 2005 или по-старинке?

даже если выполните этот пункт если оно того не треба, то ничего страшного не произойдет - поднимется БД все равно нормалек.

Дело не в том, что повредит или нет.
Просто, если есть желание в перемещенной БД создать пользователей уже в формате "Пользователей 2005", то не понятно, как это сделать. Хочется понимать, где эта опция хранится, ну и как ей управлять.

Была замечена еще одна особенность (простите, если буду не совсем точен в выражениях):
после воссоздания пользователей на перемещенной БД обычные пользователи воссоздались через механизм ролей, а администраторы Галактики были созданы в БД Галактики через alias-ы, т.е. админов не видно на закладке Permissions, открытой к БД Галактики в Management Studio. Также, если выполнить запрос select name from sysusers where name like '\%' , то выводятся только админы.

Alias-ы вроде считаются старой технологией. Ну да ладно, если бы не одно неприятное следствие: на новом сервере хотели переместить один файл БД в новое место, для этого сделали Datach и Attach БД Галактики. При этом из sysusers пропали все alias-ы. Получалась ситуация, когда обычные пользователи, заведенные через роли, имеют доступ к БД, а администраторы не имеют.
Собственно удалось частично полечить такую ситуацию выключением Protect-а запросом в Management Studio и повторным включением Protect-а в Cаппорте. Таким образом можно восстановить алиас для текущего пользователя Support-а. Для остальных админов при этой процедуре Alias не восстанавливается.

Friendlyman писал(а):....Хочется понимать, где эта опция хранится, ну и как ей управлять.

1. Сэкономить время и поинтересоваться у ТП
2. Разобрать запросы инсталятора при создании БД с этим флагом и без него ....это если время есть ...)))

Friendlyman писал(а):на новом сервере хотели переместить один файл БД в новое место

проще было запланировать это заранее и переназначить при восстановлении БД.
Я обычно советую заводить 2 раида - на одном располагаете журнал и лог, на втором системный, данные, индексы.
За нехваткой винтов часто получается, что 1 вместе с системой на раид-0, 2 на раид 5 или 10 (заодно и размер побольше).

У меня было, что админы после восстановления не могут войти в базу. Добавлял к Идентификатору пользователя 1, сохранял, затем единичку удалял, т.е. имя становилось прежним. И все, можно входить в базу

maikl писал(а):У меня было, что админы после восстановления не могут войти в базу. Добавлял к имени 1, сохранял, затем единичку удалял, т.е. имя становилось прежним. И все, можно входить в базу

А где и какими средствами добавляли к имени единицу?