В экземпляре SQL Server 2014 с достаточным количеством оперативной памяти и быстрыми дисками более 160 пользователей имеют доступ к базе данных. По какой-то причине без моего ведома выполнение команды DROP USER [username]
в этой базе данных занимает до 5 секунд на пользователя.
Преобразование пользователей в логины и восстановление их разрешений происходит очень быстро.
В контексте обновления баз данных DEV с производства я должен отбросить и воссоздать всех пользователей баз данных. Так что да, удаление пользователей базы данных и их воссоздание необходимо.
Как мне ускорить DROP USER
команду?
Помните, я должен запустить его более 160 раз для экземпляра, о котором я пишу.
Это SQL, который я использую:
DECLARE drop_user_cur CURSOR FOR
SELECT name FROM #drop_users
OPEN drop_user_cur
FETCH NEXT FROM drop_user_cur INTO @user
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'use [' + @db_name + '] DROP USER [' + @user + ']'
BEGIN TRY
print @sql
EXECUTE(@sql)
END TRY
BEGIN CATCH
print 'ERREUR : ' + @sql
END CATCH
FETCH NEXT FROM drop_user_cur INTO @user
END
CLOSE drop_user_cur
DEALLOCATE drop_user_cur
Проблема не в курсоре; это факт, DROP USER
который занимает до 5 секунд.
Используя sp_whoisactive
, wait_type есть NULL
.
Не обращать внимание на продолжительность, DROP
и CREATE USER
были бежать в WHILE
петлю из -за чего он больше минуты говорят.
Профилировщик показывает более 125 000 операций чтения для выполнения DROP USER
.
Компонент Service Broker не включен.
источник
Ответы:
Решением этой проблемы было включение сервисного брокера в базу данных.
После включения сервис-брокера для базы данных, отбрасывание пользователей происходило практически мгновенно.
Кин спросил, был ли сервисный брокер включен в предыдущем комментарии, который отправил мне поиск в правильном направлении.
источник
это не ответ на вопрос, а аргумент, чтобы полностью отклонить его.
Если я правильно понимаю ваш комментарий:
Ваша цель - скопировать производственные данные в систему разработки и заставить их работать с тем же разрешением, что и у производственной системы, используя те же имена пользователей .
Самый быстрый путь - клонировать sql-логины из производственной системы в систему dev, используя процедуру, описанную ms в этой статье kb .
с помощью процедуры, определенной ms, вы можете восстановить базы данных на своем dev-сервере, и разрешение будет работать без изменений.
Я успешно использовал вышеупомянутую процедуру для копирования рабочей среды sql 2005 в среду test и dev sql 2012.
После клонирования пользователей простое восстановление базы данных привело меня к паре полностью работающих новых систем с актуальными данными.
Огромный плюс этого решения заключается в том, что для обновления данных разработчика вы просто восстанавливаете производственную базу данных и все; вам придется настроить ссылки, синонимы и тому подобное, но разрешения не будут нарушены.
Вот код из этой статьи, просто для справки, но, пожалуйста, обратитесь к статье, в которой есть замечания и подробности о совместимости с древними версиями sql, сведениями о шифровании паролей и другой информацией, которая может избавить вас от головной боли при передаче имен входа на серверы:
источник
Курсор, подобный этому, должен работать
источник