- •Методические указания к лабораторным работам
- •Лабораторная работа №2
- •Утилита Enterprise Manager
- •Останов средствами Transact-sql
- •Управление учетной записью службы с помощью утилиты Enterprise Manager
- •Режимы запуска sql Server 2000
- •Конфигурирование служб sql Server 2000 Конфигурирование службы mssqlServer
- •Вкладка General
- •Вкладка Memory
- •Вкладка Processor
- •Вкладка Security
- •Вкладка Connections
- •Вкладка Server Settings
- •Лабораторная работа №3
- •Создание пользователя
- •Специальные пользователи
- •Хранение информации о пользователях
- •Фиксированные роли базы данных
- •Пользовательские роли базы данных
- •Права доступа
- •Права доступа к данным
- •Права на выполнение хранимых процедур и функций
- •Права на выполнение команд Transact-sql
- •Управление правами доступа
- •Запрещение доступа
- •Лабораторная работа №4
- •Полная копия
- •Разностная копия
- •Копия журнала транзакций
- •Резервное копирование файлов и групп файлов
- •Планирование стратегии резервного копирования
- •Резервное копирование системных баз данных
- •Восстановление системных баз данных
- •Присоединение баз данных
- •Ограничения при выполнении архивирования
- •Архивирование средствами Enterprise Manager
- •Архивирование с помощью мастера
- •Восстановление архива средствами Enterprise Manager
Специальные пользователи
В любой базе данных автоматически создаются два пользователя:
dbo (database owner). Это специальный пользователь базы данных, являющийся ее владельцем. Владелец базы данных имеет абсолютные права по управлению ею. Пользователя dbo нельзя удалить. По умолчанию в пользователя dbo отображается учетная запись sa, которой тем самым предоставляются максимальные права в базе данных. Кроме того, все члены роли базы дачных dbowner также считаются владельцами базы данных. Пользователь dbo включен в роль db_owner и не может быть удален из нее
guest. Если учетной записи явно не предоставлен доступ к базе данных, то она автоматически отображается сервером в пользователя guest. С помощью этого пользователя можно предоставлять разрешения на доступ к объектам базы данных, необходимые любому пользователю. Разрешив доступ пользователю guest, вы, тем самым, даете аналогичные права доступа всем учетным записям, сконфигурированным на SQL Server 2000. Для повышения безопасности хранящейся информации рекомендуется удалять пользователя guest, избазы данных.
Хранение информации о пользователях
Информация о пользователях, созданных в базе данных, хранится в системной таблице sysusers, которая содержит множество столбцов, определяющих различные свойства пользователя. В табл. 9.2. приведен список столбцов таблицы с указанием типа данных и назначения.
Таблица 3.1. Список столбцов таблицы sysuser
|
Имя столбца |
Тип данных |
Краткое описание |
|
uid |
smallint |
Указывается идентификатор пользователя (роли), уникальный в пределах базы данных. Пользователю dbo при создании БД присваивается идентификатор 1, а пользователю guest - идентификатор 2. Идентификаторы фиксированных ролей начинаются с номера 16З84, а пользовательских - с 16 400 |
|
status |
smallint |
Битовое поле, определяющее статус пользователя (роли). Не документировано. Предназначено для внутреннего применения |
|
name |
sysname |
Имя, присвоенное пользователю (роли) при создании. Можно легко изменять имена пользователей, исправляя значение в этом столбце |
|
sid |
varbinary (85) |
Идентификатор безопасности учетной записи, связанной с рассматриваемым пользователем. Для учетных записей SQL Server идентификатор обязательно должен иметься в столбце sid системной таблицы syslogins системной БД Master. Для учетных записей Windows NT идентификатор соответствует доменному идентификатору безопасности и не обязательно присутствует в таблице syslogins (для пользователей, получающих доступ к серверу через членство в группе Windows NT) |
|
roles |
varbinary (2049) |
Двоичное поле, определяющее членство пользователя в ролях сервера. Если пользователь является членом той или иной роли, то соответствующий бит устанавливается в 1. Таким образом, максимальное количество ролей SQL Server 2000 ограничено количеством 16384 |
|
createdate |
datetime |
Дата создания пользователя (роли) |
|
updatedate |
datetime |
Дата последнего изменения свойств пользователя (роли) |
|
altuid |
smallint |
Альтернативный идентификатор пользователя. Не документировано. Предназначено для внутреннего использования |
|
password |
varbinary (256) |
В этом столбце хранится пароль для ролей приложения. Для пользователей, фиксированных и пользовательских ролей базы данных в этом столбце содержится значение null |
|
gid |
smallint |
Идентификатор группы, членом которой является пользователь. Если значение в этом столбце равно значению в столбце sid, то текущая строка описывает пользовательскую роль БД |
|
environ |
varchar (255) |
В настоящее время данный столбец не используется и содержит значение NULL |
|
hasdbaccess |
int |
Если содержит 1, то пользователь имеет доступ к базе данных |
|
islogin |
int |
Если содержит 1. то текущая строка соответствует учетной записи (SQL Serves, пользователя или группы Windows NT) |
|
isntname |
int |
Если содержит 1. то пользователь является отображением учетной записи пользователя или группы Windows NT |
|
isntgroup |
int |
Если содержит 1, то пользователь является отображением учетной записи группы Windows NT |
|
isntuser |
int |
Если содержит 1, то пользователь является отображением учетной записи пользователя Windows NT |
|
issqluser |
int |
Если содержит 1, то пользователь является отображением учетной записи пользователя SOL Server |
|
isaliased |
int |
Если содержит 1, то пользователь является псевдонимом другого пользователя. Актуально для учетных записей SQL Server 6.x |
|
issqlrole |
int |
Если содержит 1, то текущая строка соответствует пользовательской или фиксированной роли базы данных |
|
isapprole |
int |
Если содержит 1. то текущая строка соответствует роли приложения |
Как видно, структура таблицы sysusers довольно сложна. Тем не менее, выполнение некоторых задач требует прямого доступа к этой таблице и невозможно иными способами. Например, если вы присоединяете (attach) базу данных с другого сервера, то соответствия между учетными записями и пользователями базы данных будут наверняка нарушены. То есть, хотя в базе данных и будут существовать пользователи, они не могут быть связаны с реальными учетными записями. Это произойдет даже в том случае, когда на сервере имеются учетные записи с теми же именами, что и на исходном сервере.