Автор: Владимир Белов

То что я хочу рассказать в данной статье, думаю известно многим DBA, но, анализируя вопросы приходящие в форум на www.sql.ru, становится ясно, что эти моменты вызывают некоторые затруднения при работе.
Итак…

Учетная запись для старта сервисов MS SQL Server 2000

SQL Server в своем "стандартном" наборе имеет следующие службы:

Сервис	Название	Имя для установки по умолчанию	Именованная инсталляция
Microsoft SQL Server	SQL Server	MSSQLSERVER	MSSQLSERVER$InstanceName
Microsoft SQL Server Agent	SQL Server Agent	SQLSERVERAGENT	SQLSERVERAGENT$InstanceName

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

Возможности	LocalSystem	Domen User
Вызов RPC	Нет	Да
Участие сервера в репликации	Нет	Да
Резервное копирование на сетевые ресурсы (а также любое обращение к сетевым ресурсам)	Нет	Да
Участие в распределенных запросах	Да	Да
Участие в распределенных запросах используя trusted connection	Нет	Да
Использование "возможностей" SQL Mail	Нет	Да

Так как преимущество использования доменной учетной записи очевидно, то практически всегда, когда это возможно, используйте доменную учетную запись для старта SQL Server. Однако, здесь тоже есть свои "подводные" камни. Некоторые DBA, не долго мучаясь, стартуют сервис от имени пользователя, которые входит в группу Domen Admin. Но это фактически противоречит всем канонам безопасности, т.к., в случае взлома, ни что не мешает злоумышленнику выполнить какие-нибудь особо веселые команды через xp_cmdshell. Поэтому рекомендуется предоставить следующие разрешения для учетной записи для старта сервиса MSSQLSERVER и SQLSERVERAGENT:

· Full control на директорию с исполняемыми файлами SQL Server;
· Full control на директорию с файлами баз данных;
· Full control на директорию с файлами SQL Server Logs;
· Предоставить необходимые права на сетевые ресурсы;
· Предоставить разрешение на машине "Log on as a service";
· Запретить локальный вход на машину;
· Предоставить права на Read & Write на следующие ключи реестра:

  - HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLSever

  - HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Perflib

  - HKEY_LOCAL_MACHINE\Systme\CurrentControlSet\Services\MSSQLServer

  - HKEY_LOCAL_MACHINE\Software\Microsfot\MSSQLServer\Providers

Во всяком случае, касаемо прав на ветки реестра - это рекомендации Microsoft. Обычно я предоставляю права на всю ветвь MSSQLServer.
Кстати, при изменении логина/пароля для сервисов SQL Server, Microsoft настоятельно рекомендует изменять данные свойства в Enterprise Manager, а не в оснастке Services. В этом случае гарантируется, что все права будут корректно прописаны в системе.

Предоставление прав на уровне системы для пользователя Dealine, E-commerce на директорию с файлами данных.

Предоставление прав на ветку реестра "MSSQLServer".

Выполнение распределенных запросов

Предположим, у нас есть два сервера, которые имеют разную функциональную нагрузку, например, сервер TRELON с финансовой программой и сервер NEPTUN с основной корпоративной программой (во всяком случае, так у нас в организации) и появляется необходимость, например, при работе отчетов получить данные как с одного сервера, так и с другого. Как всегда есть три пути решения данной "проблемы".
Но для начала небольшое отступление. Во-первых, я всегда рекомендую в распределенных запросах использовать MTS, т.е. чтобы транзакции контролировались MTS, что по заверениям Microsoft, гарантирует целостность транзакции. К сожалению, это не всегда так. Для этого можно отметить галочку в свойствах серверах на вкладке "Connection" Enforce distributed transaction (MST). Также надо разрешить возможность подключению других SQL Server' ов к локальному с помощью RPC - на этой же вкладке отметьте галочку "Allow other SQL Server to connect remotely to this SQL Server using RPC". Не заморачиваясь на EM, который все-таки немного неповоротлив, можно использовать QA. Для этого выполните следующие запросы:

USE master
GO
sp_configure 'remote proc trans', 1 -- аналог Enforce …
GO
reconfigure with override
GO
sp_configure 'remote access', 1 -- аналог Allow other …
GO
reconfigure with override
GO

Далее - к распределенным запросам. Насколько я понял, SQL Server все обнаруженные MS SQL сервера добавляет как Remote Server. Обычно я удаляю ненужные, а необходимые делаю как Linked Server. Разница между ними только в том, что:

- Во-первых, Remote Server - это только SQL Server, а Linked Server - это может быть и не SQL Server;
- Во-вторых, Linked Server предоставляет возможность настраивать и Windows Logins, т.е. логины на основе Windows-аутентификации.

Предположим, что на сервере TRELON есть SQL - логин DEALINE.CENTER\BelovV. Данному логину необходимо получить данные с сервера NEPTUN. Возьмем за основу то, что у нас запрос выполняется с сервера TRELON, сервер NEPTUN уже подключен как Linked Server. Если нет подключаем:

- из QA выполнив:

	exec master..sp_addlinkedserver 'NEPTUN', N'SQL Server'
	exec master..sp_serveroption 'NEPTUN', 'DATA ACCESS', true

- из EM:

Security - Linked Server - New Linked Server. Указываем, что это будет у нас SQL Server, указываем имя сервера. Далее на вкладке "Server Options" отмечаем следующие пункты:

	 Data Access
	 RPC
	 RPC Out

Описание этих параметров выходит за рамки данной статьи, поэтому читайте о данных параметрах в BOL или спросите на форуме :)

Добавление нового Linked Server

Итак, сервер добавлен - можно идти дальше. А чтобы идти дальше есть три пути:

Путь номер один

На вкладке "Security" в колонке "Local Login" указываем логин, которому нужен доступ на сервер NEPTUN. Далее на сервере NEPTUN создаем такой же логин с необходимыми правами. Почему такой же? Для удобства администрирования. :)
Преимущества такого пути в том, что Вы всегда можете увидеть какой логин, скажем так, чем занят.
Недостаток - для каждого логина придется заводить новый логин на удаленном сервере.

Путь номер два

На сервере NEPTUN создать новый логин, например, "NEPTUN" и всем пользователям, которым необходим доступ на удаленный сервер, давать доступ под этим логином. Т.е., также на вкладке "Security" в колонке "Local Login" указать необходимый логин, а в колонке "Remote User" - указать логин "NEPTUN"

Путь номер три

По моему мнению - это самый лучший путь, но, чтобы его использовать, у Вас должна быть развернута и функционировать Active Directory. Без этого никак.
Итак, для настройки необходимо:

1. В оснастке Active Directory Users and Computers - Users найти пользователя, под которым запускаются сервисы SQL Server'a и в свойствах данного пользователя на вкладке Account в Account options отметить флажок "Account is trusted for delegention".
2. Также в оснастке Active Directory Users and Computers - Computers найти название машины, на которой функционирует SQL Server и в свойствах компьютера отметить флажок "Trust computer for delegation".
3. Далее, также создаете Linked Server (если ещё не создан), добавляете нового пользователя на вкладке "Security", и отмечаете флажок "Impersonale"

После этого все должно работать. Иногда встречаются ошибки, такие как, например - пользователь устанавливает соединение с сервером TRELON, на котором установлен SP3, далее запускает распределенный запрос к серверу NEPTUN, на котором установлен SP2. В этом случае Вы получите ошибку "Login failed…". То есть необходимо обеспечить идентичность, скажем так, версий Ваших SQL серверов. И ещё одно условие - необходимо обеспечить идентичность установленных Windows Service Pack.

Свойства компьютера в оснастке "Active Directory Users and Computers"

Свойства пользователя в оснастке "Active Directory Users and Computers"

Добавление нового пользователя.