Могу ли я принудительно настроить определенные параметры пользователя в SQL Server?

Question

У меня есть группа пользователей, делающих специальные запросы в базу данных под управлением SQL Server. Иногда кто-то запускает запрос, который блокирует систему на длительный период времени, когда он получает 10-миллиметровые строки.

Можно ли установить некоторые параметры при подключении определенного входа? e.g.:

• уровень изоляции транзакции
• Максимальное количество строк
• время ожидания запроса

Если это невозможно в SQL Server 2000, возможно ли это в другой версии? Насколько я могу судить, регулятор ресурсов не дает вам такого управления (он просто позволяет вам управлять памятью и процессором).

Я понимаю, что пользователь может многое из этого сделать самостоятельно, но было бы здорово, если бы я мог управлять им с сервера для каждого пользователя.

Очевидно, я бы хотел отвести пользователей от прямого доступа к таблице / представлению, но в данный момент это не вариант.

Answer 1

В SQL Server 2005 и 2008 вы можете добавить триггер входа в базу данных, который может изменять параметры соединений в зависимости от того, к кому они подключены. Однако вы должны быть очень осторожными с ними, поскольку ошибка или ошибка в триггере могут привести к тому, что все будут заблокированы.

В SQL Server 2000 ничего подобного нет.

---

Я просто хотел добавить, что, если подход Джоэла работает для вас, тогда я настоятельно рекомендую этот метод, а не мой, потому что триггер входа - это одна большая и опасная граната, которую можно бросить в эту проблему.

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

Answer 2

Вы можете, конечно, ограничить результаты запроса. Я делаю это для StackQL , используя хранимую процедуру, которая выглядит примерно так:

CREATE PROCEDURE [dbo].[WebQuery] 
    @QueryText nvarchar(1000)
AS
BEGIN

    INSERT INTO QueryLogs(QueryText) 
        VALUES(@QueryText)

    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
    SET QUERY_GOVERNOR_COST_LIMIT 15000 
    SET ROWCOUNT 500 

    Begin Try
        exec (@QueryText) 
    End Try
    Begin Catch
        SELECT ERROR_NUMBER() AS ErrorNumber, 
            ERROR_MESSAGE() AS ErrorMessage,
            ERROR_PROCEDURE() AS ErrorProcedure,
            ERROR_SEVERITY() AS ErrorSeverity,
            ERROR_LINE() AS ErrorLine,
            ERROR_STATE() AS ErrorState
    End Catch

END

Важной частью здесь является серия из трех SET операторов после журнала. Это ограничение основано как на количестве строк в результатах, так и на ожидаемых затратах на запрос. Значения количества строк и регулятора запросов могут быть переменными, поэтому не составит труда изменить их, чтобы изменить ограничение также на основе текущего пользователя.

Тем не менее, вы также должны заметить, что пользователям, которые «в курсе», довольно легко выйти из этого, если они захотят. В моем случае я рассматриваю возможность время от времени преодолевать ограничения. Но именно поэтому я веду журналирование: код, который преодолевает ограничения, торчит в журналах, и поэтому я могу легко поймать и запретить любому, кто делает это слишком часто, без моего разрешения.

Наконец, любой пользователь, который вызывает это, должен быть только в роли denydatawriters, роли datareaders, а затем иметь явные разрешения на выполнение только этой хранимой процедуры. Тогда они на самом деле не могут ничего сделать , кроме как выбирать на существующих таблицах.

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