SQL Server 2000

Введение. 2

Краткая характеристика редакции. 8

SQL Server 2000. 8

Developer Edition. 9

Enterprise Evaluation Edition. 9

Возможности редакций. 10

Аппаратные требования. 10

Взаимодействие с операционными системами. 11

Взаимодействие с программным обеспечением Интернета. 12

Планирование конфигурации сервера. 13

Выбор сопоставления. 14

Выбор метода установки. 16

Автоматическая установка. 18

Создание учетных записей. 19

Выбор типа установки. 23

Установка сетевых библиотек и протоколов. 25

Установка сетевых протоколов в Windows 2000. 25

Сетевая библиотека Описание. 26

Установка и конфигурирование клиентов. 27

Запуск, остановка и приостановка служб. 29

Автоматический старт. 30

Ручной запуск SQL Server 31

Запуск SQL Server в однопользовательском режиме. 32

Запуск SQL Server с минимальными требованиями. 32

Дополнительные режимы запуска. 33

Приостановка SQL Server 34

Остановка SQL Server 34

Правила Безопасности. 35

Общие правила разграничения доступа. 36

Архитектура системы безопасности SQL Server 2000. 37

Режимы аутентификации. 37

Режим аутентификации SQL Server 38

Компоненты структуры безопасности. 39

Пользователи. 40

Роли сервера. 42

Роли баз данных. 42

Роли приложения. 44

Защита данных. 45

Шифрование данных. 45

Ограничение доступа к файлам SQL Server 46

Права доступа. 46

Права на доступ к объектам баз данных. 47

Запрещение доступа. 49

Создание и обслуживание баз данных. 50

Использование неформатированных разделов 51

Увеличение базы данных. 52

Использование Transact-SQL.. 53

Создание баз данных. 53

Управление базами данных. 57

Уменьшение размера базы
данных. 60

Управление свойствами базы данных. 64

Присоединение и отсоединение базы данных. 67

Передача прав владения 68

Изменение имени базы данных. 69

Просмотр свойств базы данных. 69

Удаление базы данных. 76

Управление пользовательскими типами данных. 76

Управление правилами. 79

Управление умолчаниями. 80

Список литературы.. 84

Введение.

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

Администрирование SQL Server 2000 в свою очередь можно разделить на две части: администрирование собственно сервера и администрирование баз данных. Таким образом, администрирование баз данных представляет собой отдельную область работы с SQL Server 2000. Оно включает разработку структуры базы данных, ее реализацию, проектирование системы безопасности, создание пользователей базы данных, предоставление им прав доступа, создание объектов и т. д. Кроме того, администратор базы данных должен периодически создавать резервные копии, выполнять проверку целостности данных и следить за размером файлов как самой базы данных, так и журнала транзакций. Указанный список можно легко продолжить, так как мы перечислили далеко не все задачи администрирования.

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

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

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

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

База данных — поименованная совокупность взаимосвязанных данных, находящихся

под управлением системы управления базами данных (СУБД). СУБД — это комплекс

программных и языковых средств, необходимых для создания баз данных,

поддержания их в актуальном состоянии и организации поиска в них необходимой

информации.

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

Централизованный характер управления данными в базе данных предполагает существование некоторого лица (группы лиц), на которое возлагаются функции администрирования данных, хранимых в базе.

Различают централизованные и распределенные базы данных. О Распределенная база данных состоит из нескольких частей, хранимых в различных ЭВМ вычислительной сети. Этот способ обработки подразумевает наличие нескольких серверов, на которых может храниться пересекающаяся или даже дублирующаяся информация. Для работы с такой базой данных используется система управления распределенными базами данных (СУРБД).

'О Централизованная база данных хранится в памяти одной вычислительной системы, то есть база данных располагается на одном компьютере. Если для этого компьютера установлена поддержка сети, то множество пользователей с клиентских компьютеров могут одновременно обращаться к информации, хранящейся в центральной базе данных. В локальных сетях чаще всего используется именно такой способ обработки данных. Системы централизованных баз данных могут существенно различаться в зависимости от их архитектуры. » Файл-сервер. БД располагается на файл-сервере (или нескольких файл-серверах), в качестве которого может использоваться наиболее мощная из ПЭВМ, объединенных в сеть. Функции файл-сервера заключаются, в основном, в хранении БД и обеспечении доступа к ним пользователей, работающих на различных компьютерах. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. Переданные данные обрабатываются СУБД, которая находится опять же на компьютерах пользователей. После того как пользователи выполнят необходимые изменения данных, они копируют файлы обратно на файл-сервер, где другие пользователи, в свою очередь, могут снова их использовать. Кроме того, каждый пользователь может создавать на локальном компьютере свои собственные базы данных, используемые им монопольно. Эта схема работает при не очень больших объемах данных. При увеличении числа компьютеров в сети или росте БД производительность резко падает. Это связано с увеличением объема данных, передаваемых по сети, так как вся обработка происходит на компьютере пользователя. Явным недостатком подобного подхода является высокая вероятность потери изменений, выполненных одними пользователями, при сохранении измененных файлов на центральный сервер. Дело в том, что пользователи могут и не подозревать, что помимо них еще кто-то изменял данные. Примерами СУБД, предназначенными непосредственно для разработки локальных пользовательских приложений БД, то есть приложений, работающих на одном локальном компьютере либо в компьютерной, сети являются: Microsoft Visual FoxPro, Microsoft Access,Paradox,fpr Windows, dBase for Windows и др.

• Клиент-сервер. Технология клиент-сервер подразумевает, что помимо хранения базы данных центральный компьютер (сервер базы данных) должен

обеспечивать выполнение основного объема обработки данных. При технологии клиент-сервер запрос на выполнение операции с данными (например, обычная выборка), выдаваемый клиентом (рабочей станцией), порождает на сервере поиск и извлечение данных. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту дж. Система, использующая технологию клиент-сервер, разделяется на две части: клиентская часть (front-end) обеспечивает графический интерфейс и находится на компьютере пользователя; серверная часть (back-end), которая находится на специально выделенных компьютерах, обеспечивает управление данными, разделение информации, администрирование и безопасность. Примерами СУБД технологии клиент-сервер являются Microsoft SQL Server, Oracle, IBM DB2, Sybase и др. Спецификой архитектуры клиент-сервер является использование специального языка структурированных запросов (Structured Query Language, SQL), обеспечивающего пользователя простым и эффективным инструментом доступа к данным.

Помимо подразделения баз данных по методам обработки можно классифицировать их по используемой модели (или структуре) данных. Модель данных — совокупность структур данных и операций по их обработке. С помощью модели данных можно наглядно представить структуру объектов и установленные между ними связи. Для терминологии моделей данных характерны понятия «элемент данных» и «правила связывания». Элемент данных описывает любой набор данных, а правила связывания определяют алгоритмы взаимосвязи элементов данных. К настоящему времени разработано множество различных моделей данных, но на практике используется три основных. Выделяют иерархическую, сетевую и реляционную модели данных. Соответственно говорят об иерархических, сетевых и реляционных СУБД.

О Иерархическая модель данных. Иерархически организованные данные встречаются в повседневной жизни очень часто. Например, структура высшего учебного заведения — это многоуровневая иерархическая структура. Иерархическая (древовидная) БД состоит из упорядоченного набора элементов. В этой модели исходные элементы порождают другие элементы, причем эти элементы в свою очередь порождают следующие элементы. Каждый порожденный элемент имеет только один порождающий элемент/

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

Основным недостатком данной модели является необходимость использования той иерархии, которая была заложена в основу БД при проектировании. Потребность в постоянной реорганизации данных (а часто невозможность этой реорганизации) привели к созданию более общей модели — сетевой.

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

Рассмотрим предметную область для базы данных, в которой хранится информация о заказах магазина. Заказчики берут напрокат фильмы, используя два носителя: видеоленту и компакт-диски. Обслуживание заказчиков выполняют продавцы. Каждый продавец обслуживает многих заказчиков. Каждый продавец может пользоваться услугами нескольких магазинов и наоборот. Существует много копий одного и того же фильма и т. д.

Поскольку сетевая БД может представлять непосредственно все виды связей, присущих данным соответствующей организации, по этим данным можно перемещаться, исследовать и запрашивать их всевозможными способами, то есть сетевая модель не связана всего лишь одной иерархией. Однако для того чтобы составить запрос к сетевой БД, необходимо достаточно глубоко вникнуть в ее структуру (иметь под рукой схему этой БД) и выработать механизм навигации по базе данных, что является существенным недостатком этой модели БД.

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

Итак, целью информационной системы является обработка данных об объектах реального мира, с учетом связей между объектами. В теории БД данные часто называют атрибутами, а объекты — сущностями. Объект, атрибут и связь — фундаментальные понятия ИС.

Объект (или сущность) — это нечто существующее и различимое, то есть объектом можно назвать то «нечто», для которого существуют название и способ отличать один подобный объект от другого. Например, каждая школа — это объект. Объектами являются также человек, класс в школе, фирма, сплав, химическое соединение и т. д. Объектами могут быть не только материальные предметы, но и более абстрактные понятия, отражающие реальный мир. Например, события, регионы, произведения искусства; книги (не как полиграфическая продукция, а как произведения), театральные постановки, кинофильмы; правовые нормы, философские теории и проч.

Атрибут (или данное) — это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое числовое, текстовое или иное значение. Информационная система оперирует наборами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы в школе. Число учеников в классе — это данное, которое принимает числовое значение (у одного класса 28, у другого — 32). Название класса — это данное, принимающее текстовое значение (у одного — 10А, у другого — 9Б и т. д.).

Атрибут некоторого набора объектов сам может быть набором объектов, имеющих собственные атрибуты. Например, атрибутом лица (как экземпляра набора объектов «Лица») является вуз, который это лицо окончило (МГУ, МИФИ и т. п.). С другой стороны, конкретный вуз — это экземпляр набора объектов «Вузы» и характеризуется множеством данных: фамилией ректора, адресом, специализацией, числом студентов и т. д. Наконец, ректор в свою очередь является экземпляром набора объектов «Лица». Таким образом, возникает возможность установления связи между экземплярами объектов из разных наборов.

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 июня 1970 г. статью A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных», что и положило начало реляционным базам данных.

Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую Основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.

Э. Кодд, будучи математиком по образованию, предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида, известных в математике как «отношения».

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

Таблица состоит из столбцов (полей) и строк (записей); имеет имя, уникаль ное внутри базы данных. Таблица отражает тип объекта реального мира (сущ ность), а каждая ее строка— конкретный объект. Так, таблица Спортивная секция содержит сведения обо всех детях, занимающихся в данной спортивной секции, а ее строки представляют собой набор значений атрибутов каждого кон кретного ребенка. Каждый столбец таблицы — это совокупность значений конк ретного атрибута объекта. Столбец Вес, например, представляет собой совокупность всех весовых категорий детей, занимающихся в секции. В столбце Пол могут содержаться только два различных значения: «муж.» и «жен.». Эти значения выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain). Так, значения в столбце выбираются из множества всех возможных весов детей.

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

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

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

так как, по всей вероятности, оно не имеет смысла. Например, из сравнения имени и даты рождения сотрудника ничего определенного не выйдет.

В большинстве систем управления реляционными базами данных понятие домена не реализовано.Каждый элемент данных в отношении может быть определен с указанием его адреса в формате A[i , j], где А — элемент данных, i — строка отношений, j — номер атрибута отношения.

Количество атрибутов в отношении определяет его порядок (или степень). Порядок отношения, приведенного в табл., равен 4.

ID сотрудника	Имя сотрудника	№ паспорта	Дата рождения
12576893	Мамаев Евгений	357934 ХИ-БА	13.08.78
56387934	Шкарина Лилия	463865 XIV-БА	07.10.72
85973002	Салихов Тимур	653473 Х1И-БА	17.12.80
24856892	Волков Иван	395789 XVII-БА	05.05.79
76578243	Мамаев Сергей	312642 XVII-БА	21.09.80

Множество значений А [ i , j ] при постоянном i и всех возможных j образуют кортеж (или попросту строку таблицы). Количество всех кортежей в отношении определяет его мощность, или кардинальное число. Мощность отношения в табл. 2.2 равна 5. Мощность отношения, в отличие от порядка отношения, может со временем меняться. Совокупность всех кортежей образует тело отношения (или собственно таблицу).

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

Каждый столбец (поле) имеет имя, которое обычно записывается в верхней части таблицы. При проектировании таблиц в рамках конкретной СУБД имеется возможность выбрать для каждого поля его тип, то есть определить набор правил по его отображению, а также определить те операции, которые можно выполнять над данными, хранящимися в этом поле. Наборы типов могут различаться у разных СУБД.

Имя поля должно быть уникальным в таблице, однако различные таблицы могут иметь поля с одинаковыми именами. Любая таблица должна иметь, по крайней мере, одно поле; поля расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от полей, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции — среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). В таблице Спортивная секция первичный ключ — это столбец Ф.И.О. Такой выбор первичного ключа имеет существенный недостаток: невозможно записать в секцию двух детей с одним и тем же значение поля Ф.И.О., что на практике встречается не так уж редко. Именно поэтому часто вводят искусственное поле, предназначенное для нумерации записей в таблице. Таким полем, например, может быть его порядковый номер в журнале для каждого ребенка, который сможет обеспечить уникальность каждой записи в таблице. Ключ должен обладать следующими свойствами. О Уникальностью. В каждый момент времени никакие два различных кортежа отношения не имеют одинакового значения для комбинации входящих в ключ атрибутов. То есть в таблице не может быть двух строк, имеющих одинаковый идентификационный номер или номер паспорта.

О Минимальностью. Ни один из входящих в ключ атрибутов не может быть исключен из ключа без нарушения уникальности. Это означает, что не стоит создавать ключ, включающий и номер паспорта, и идентификационный номер. Достаточно использовать любой из этих атрибутов, чтобы однозначно идентифицировать кортеж. Не стоит также включать в ключ неуникальный атрибут, то есть запрещается использование в качестве ключа комбинации идентификационного номера и имени служащего. При исключении имени служащего из ключа все равно можно уникально идентифицировать каждую строку.

Выполнение условия уникальности является обязательным. В то же время при необходимости может быть допущено нарушение условия минимальности.

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

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key). Рассмотрим пример. В базе данных содержатся сведения о различных касредрах университета (таблица Кафедры), а также сведения о работниках этих кафедр (таблица Сотрудники). Первичным ключом таблицы Сотрудники является поле I D, а таблицы Кафедры— поле Кафедра. Поле Кафедра таблицы Сотрудники является внешним ключом для связи с таблицей Кафедры.

При описании модели реляционной базы данных для одного и того же понятия часто употребляют различные термины, что зависит от уровня описания (теория или практика) и системы (Access, SQL Server, dBase). В табл. приведена сводная информация об используемых терминах.

Таблица Терминология баз данных

Теория БД_________Реляционные БД_______SQL Server___________

Отношение (Relation) Таблица (Table) Таблица (Table)

Кортеж (Tuple) Запись (Record) Строка (Row)

Атрибут (Attribute) Поле (Field)__ _________Столбец или колонка (Column)

Краткая характеристика редакции

SQL Server 2000

Первый вопрос, который необходимо решить, прежде чем приступить непосредственно к установке SQL Server 2000, — это выбор редакции. SQL Server 2000 поставляется в нескольких редакциях, обладающих разной функциональностью и имеющих свои отличительные особенности. Вы должны выбрать именно ту ' редакцию, которая более всего подходит для решения стоящих перед вами задач. Например, если требуется всего-навсего обеспечить переносной компьютер. с операционной системной Windows 98 высокофункциональным хранилищем данных, то вряд ли стоит приобретать SQL Server 2000 Developer Edition. Лучшим решением будет SQL Server 2000 Personal Edition.

Enterprise Edition

Используется в качестве промышленного сервера баз данных. Поддерживает все возможности, доступные в SQL Server 2000 и систем хранения данных. SQL Server 2000 Enterprise Edition поддерживается следующими операцион ными системами: О Windows NT 4.0 Server; О Microsoft Windows 2000 DataCenter; О Windows 2000 Advanced Server; О Windows 2000 Server; О Microsoft Windows NT 4.0 Server, Enterprise Edition.

Standard Edition

Используется в качестве сервера баз данных для небольших рабочих групп.

Standard Edition поддерживается следующими операционными системами: .. О Windows NT 4.0 Server;

О Microsoft Windows 2000 DataCenter

О Windows 2000 Advanced Server;

О Windows 2000 Server;

О Microsoft Windows NT 4.0 Server, Enterprise Edition.

Personal Edition

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

Personal Edition поддерживается следующими операционными системами:

О Microsoft Windows 98;

О Windows NT 4.0 Workstation;

О Windows NT 4.0 Server;

О Windows 2000 Professional;

О Microsoft Windows 2000 DataCenter;

О Windows 2000 Advanced Server;

О Windows 2000 Server;

О Microsoft Windows NT 4.0 Server, Enterprise Edition.

Developer Edition

Используется для разработки приложений с SQL Server в качестве хранилища данных. Хотя Developer Edition поддерживает все возможности Enterprise Edition, которые позволяют разработчикам писать и тестировать приложения, Developer Edition лицензируется только как система разработки и тестирования, а не как промышленный сервер.

Developer Edition поддерживается следующими операционными системами: О Microsoft Windows 98 (используя Desktop Engine); О Windows NT 4.0 Workstation; О Windows NT 4.0 Server; О Windows 2000 Professional; О Microsoft Windows 2000 DataCenter; О Windows 2000 Advanced Server; О Windows 2000 Server;

О Microsoft Windows NT® 4.0 Server, Enterprise Edition.

Desktop Engine Edition /

Используется независимыми разработчиками для встраивания хранилищ данных в разрабатываемые системы. Desktop Engine включает в себя только инструменты обработки пользовательских запросов (engine). В эту редакцию не входят:

О графические инструменты администрирования (при необходимости для администрирования этой редакции можно использовать графические инструменты любой другой редакции);

О инструменты электронной документации Books Online; О инструменты поддержки репликации сведением; О примеры кода (code samples); О библиотеки разработки.

Хотя большей частью редакция Desktop Engine обеспечивает ту же функцио нальность, что и другие редакции, но имеет некоторые ограничения. В частно сти, не реализовано распараллеливание запросов, индексирование представлений и некоторые другие функции, характерные для больших промышленных серв ров. Кроме того, если на сервере одновременно выполняется более пяти паке тов команд, то производительность их выполнения снижается. Отличительно^ чертой редакции Desktop Engine является также и то, что она не требует клиен ских лицензий доступа (Client Access Licenses, CAL). Все описанные характе ристики делают SQL Server 2000 Desktop Engine идеальным выбором при со| здании систем с встроенными хранилищами данных и при работе с даннык в автономном режиме (off-line).

Редакция Desktop Engine поставляется в виде модулей Windows Installer, ко торые могут быть включены в установочный пакет. SQL Server 2000 Desktojf Engine поддерживает все интерфейсы API, доступные в других редакциях. Эт API также могут быть использованы для администрирования сервера.

Desktop Engine поддерживается следующими операционными системами: О Microsoft Windows 98; О Windows NT 4.0 Workstation; О Windows NT 4.0 Server; О Windows 2000 Professional; О Microsoft Windows 2000 DataCenter; О Window's 2000 Advanced Server; О Windows 2000 Server; О Microsoft Windows NT 4.0 Server, Enterprise Edition.

Windows CE Edition

Используется как хранилище данных на устройствах Microsoft Windows g| Благодаря поддержке репликации допускается копирование данных с SQL I ver 2000 Enterprise и Standard Editions.

Windows CE Edition поддерживается Microsoft Windows CE.

Enterprise Evaluation Edition

Это полнофункциональная версия SQL Server Enterprise Edition. Однако пр назначена она только для знакомства с данным продуктом, так как срок работы" с ней истекает через 120 дней после установки. Распространяется редакция Enterprise Evaluation Edition свободно и доступна для загрузки из Интернета. Enterprise Evaluation Edition поддерживается следующими операционными системами: О Windows NT 4.0 Server;

О Microsoft Windows 2000 DataCenter;

О Windows 2000 Advanced Server;

О Windows 2000 Server;

О Microsoft Windows NT 4.0 Server, Enterprise Edition.

Возможности редакций

Клиентское программное обеспечение для всех редакций SQL Server 2000, за исключением SQL Server Windows CE Edition, запускается на любых версиях Microsoft Windows NT, Microsoft Windows 2000 и Microsoft Windows 95/98. Однако возможность установки серверной части SQL Server 2000, отвечающей за выполнение пользовательских запросов, зависит от используемой редакции и операционной системы. Так, серверная часть SQL Server 2000 Enterprise Edition не может быть установлена на Windows 2000 Professional, Windows NT Workstation или Windows 98. Тем не менее компакт-диск с SQL Server 2000 Enterprise Edition обеспечивает установку клиентского программного обеспечения на любой из этих операционных систем.

В табл. 7.1. обобщена информация о поддержке той или иной редакцией различных механизмов SQL Server 2000, связанных с использованием баз данных (БД).

Подготовка к установке

Предыдущие разделы были посвящены рассмотрению различных редакций SQL Server 2000. Когда выбор редакции остался в прошлом и у вас имеется компакт-диск с конкретной редакцией, можно приступать к установке SQL Server 2000. Однако прежде чем начать непосредственно установку сервера, необходимо выполнить некоторые подготовительные операции, которые помогут вам избежать неприятностей в ходе установки. В частности, прежде всего необходимо убедиться, что на вашем компьютере установлена операционная система, которая необходима для функционирования той или иной редакции SQL Server 2000. Кроме того, следует проверить, имеется ли на жестком диске достаточно свободного пространства для установки собственно сервера, а также вспомогательных и клиентских компонентов.

В этом разделе будут рассмотрены основные требования, выдвигаемые мастером установки SQL Server 2000, а также некоторые общие рекомендации по выполнению собственно установки.

Непосредственно процесс подготовки к установке SQL Server состоит из трех этапов:

О проверка соответствия аппаратным требованиям; О установка необходимого программного обеспечения; О конфигурирование учетных записей для служб MSSQLServer и SQLServer-Agent.

Прежде чем приступать к установке, обязательно пройдите все три этапа. В этом случае у вас не возникнет сложностей в процессе установки, не придется прерывать ее и возвращаться назад!

Аппаратные требования

Для установки инструментария и библиотек Microsoft SQL Server 2000 компьютер должен отвечать минимальным требованиям к аппаратному обеспечению компьютера (табл. 7.3). Цифры, приведенные в таблице, практически не отличаются от аналогичных показателей для SQL Server 7.0. Это связано с тем, что ядро SQL Server 2000 осталось в основном тем же, что и в SQL Server 7.0.

Таблица. Требования к аппаратной части

Аппаратная часть_Минимальные требования_

Компьютер Intel или совместимый с ним.

Pentium 166 MHz или выше, Pentium PRO, Pentium III или процессор,

требующийся для вашей операционной системы (с учетом редакции

SQL Server) Память (RAM) Enterprise Edition: 64 Мбайт

Standard Edition: 32 Мбайт Пространство SQL Server 2000: жесткого диска полная установка: 180 Мбайт;

типичная установка: 170 Мбайт;

минимальная установка: 65 Мбайт;

установка только утилит администрирования: 90 Мбайт;

+50 Мбайт: установка OLAP; ______________+12 Мбайт: установка English Query________________________

Для успешной работы рекомендуется к вышеперечисленным требованиям добавить размеры пользовательских баз данных, а также учесть возможность роста системных баз данных. Приведенные требования указаны в расчете на системы, работающие с небольшими объемами данных. При увеличении объема баз данных возрастают и требования к ресурсам компьютера. При этом следует учитывать и возможности редакции, которую вы используете. Напомним, что максимальные возможности предоставляет редакция SQL Server 2000 Enterprise Edition, обеспечивающая использование серверов с 32 процессорами и объемом памяти до 64 Гбайт.

Не следует приведенные в таблице требования воспринимать как требования к ресурсам ваи. компьютера. Данные цифры касаются самого пакета SQL Server 2000. Кроме того, следует уче требования операционной системы, которые могут существенно отличаться. Например, для операционной системы Windows 98 достаточно будет 8-16 Мбайт оперативной памяти, тогда как операционной системе Windows 2000 Advanced Server для работы необходимо, как минимум, 128 Мбайт оперативной памяти.

С точки зрения единичного пользователя компьютера SQL Server 2000 может показаться довольно требовательной СУБД. Однако это довольно мощный продукт, и при использовании его на промышленных многопроцессорных серверах указанные требования не считаются чрезмерными.

Взаимодействие с операционными системами

Как уже стало ясно при описании редакций SQL Server 2000, каждая из них работает под управлением лишь некоторых операционных систем семейства Windows. Поэтому выбор редакции накладывает ограничения и на операционную систему, под которой будет работать SQL Server 2000. В табл. 7.4 приведена сводная информация о том, под управлением каких операционных систем может работать та или иная редакция, а также указано, на каких операционных системах разрешается установка только клиентских компонентов и соединение с SQL Server 2000.

При установке SQL Server 2000 на компьютер, работающий под управлением операционной системы Windows NT Server 4.0 или Windows NT Workstation 4.0, требуется установка Service Pack версии 5.0 или более поздней. При установке SQL Server 2000 на Windows 2000 установка сервисных пакетов не требуется.

Таблица Использование редакций на различных операционных системах

Редакция или компонент Операционные системы

SQL Server 2000________________ _____________________________

Enterprise Edition Microsoft Windows NT Server 4.0, Microsoft Windows NT Server

Enterprise Edition 4.0, Windows 2000 Advanced Server, Windows 2000 Data Center Server

Standard Edition Microsoft Windows NT Server 4.0, Windows 2000 Server,

Microsoft Windows NT Server Enterprise Edition, Windows 2000 Advanced Server, Windows 2000 Data Center Server

Personal Edition Microsoft Windows 98, Windows NT Workstation 4.0,

Windows 2000 Professional, Microsoft Windows NT Server 4.0,

Windows 2000 Server Developer Edition Все операционные системы семейства Windows NT

и Windows 2000

Только клиентские утилиты Все операционные системы семейства Windows NT (включая возможность выбора и Windows 2000, а также Windows 98 компонентов) Установка соединения Все операционные системы семейства Windows NT

и Windows 2000, а также Windows 98 и Windows 95

Как видно, ни одна из редакций SQL Server 2000 не может работать с операционной системой Windows 95. Однако под управлением этой операционной системы могут работать клиентские приложения, устанавливающие соединение с SQL Server 2000.

Взаимодействие с программным обеспечением Интернета

Для установки всех редакций Microsoft SQL Server 2000 необходимо наличие в операционной системе Microsoft Internet Explorer 5.0. Исключением является установка в режиме Connectivity Only (только соединение), которая требует Microsoft Internet Explorer 4.01 с Service Pack 2 и обеспечивает только возможность установки соединения с SQL Server 2000.

Наличие Internet Explorer необходимо для работы программы Microsoft Management Console (MMC), с помощью которой реализован инструмент администрирования Enterprise Manager, а также для работы электронной справочной системы Books Online, реализованной в виде компилированного HTML-файла. При установке SQL Server 2000 на компьютер с Windows 2000 устанавливать отдельно броузер Internet Explorer 5.0 не придется, так как он непосредственно встроен в эту операционную систему.

В SQL Server 2000 была добавлена поддержка технологии XML. Однако доступ к данным с использованием этой технологии осуществляется средствами Microsoft Internet Information Server (US). Таким образом, если предполагается обеспечить пользователям возможность работы с данными посредством технологии XML, следует дополнительно установить Internet Information Server. В этом случае необходимо учесть, что это налагает дополнительные требования к ресурсам компьютера.

При работе с операционной системой Windows 2000 установка Internet Information Server не требуется, так как эта операционная система поставляется вместе с пятой версией этого продукта.

Взаимодействие с сетевым программным обеспечением

Все современные операционные системы семейства Windows имеют встроенную поддержку возможности работы с сетью. В большинстве случаев никакое дополнительное обеспечение не требуется. Исключением являются протоколы Banyan VINES или AppleTalk ADSP, работа с которыми обеспечивается продуктами третьих производителей.

Если планируется использование SQL Server 2000 в качестве корпоративного сервера баз данных, к которолгу предполагается обращение множества пользователей сети, то в операционной системе необходимо установить соответствующие сетевые протоколы. Мастер установки SQL Server 2000 не выполняет установку сетевых протоколов, поэтому эта часть работы должна быть выполнена пользователем. SQL Server 2000 поддерживает все основные протоколы Windows 2000: NetBEUI, IPX/SPX и TCP/IP. Кроме того, возможна работа по протоколам AppleTalk ADSP, Banyan VINES и некоторым другим редко используемым протоколам.

Установка сетевых протоколов еще не дает возможности работать с SQL Server 2000. Для обеспечения этой возможности необходимо наличие программного интерфейса, который бы позволял работать с SQL Server 2000. Таким интерфейсом являются так называемые сетевые библиотеки (network libraries). Эти библиотеки поставляются в составе SQL Server 2000 и автоматически устанавливаются в операционной системе при установке сервера. Более подробно архи-

тектура и конфигурирование сетевых библиотек будут рассмотрены далее в этой главе в разделе «Установка сетевых библиотек и протоколов».

В качестве клиентов SQL Server 2000 могут выступать не только приложения, работающие под управлением операционных систем семейства Windows, но и приложения операционных систем Apple Macintosh, OS/2, UNIX и т. д. Однако в настоящее время Microsoft не предоставляет драйверов ODBC под UNIX, хотя связь с клиентами UNIX возможна. Указанные драйверы могут быть разработаны независимыми производителями.

Взаимодействие с продуктами Microsoft

Для взаимодействия Microsoft Access 2000 с SQL Server 2000 необходимо установить Microsoft Office 2000 Service Release 1 или Access 2000 Service Release 1. Только в этом случае вы сможете обращаться к диаграммам базы данных, хранимым процедурам, данным о структуре таблиц и представлений, однако никаких внесенных пользователем изменений не сохраняется.

При работе с Microsoft Visual Studio® 6.0, вы не сможете получить доступ к диаграммам базы данных, хранимым процедурам, данным о структуре таблиц и представлений в SQL Server 2000. Хотя установка Visual Studio 6.0 Service Pack 4 и позволит выполнять изменения, все же сохранить их не удастся.

Планирование конфигурации сервера

Если в вашей организации предполагается наличие нескольких серверов баз данных, взаимодействующих между собой и обменивающихся данными, то необходимо разработать единую конфигурацию, которая будет реализована на всех серверах SQL Server вашего предприятия. Существует несколько параметров установки сервера, которые существенно влияют на функционирование SQL Server и не могут быть изменены в процессе работы. В SQL Server 7.0 к ним относились следующие: О набор символов (character set); О сопоставление Unicode (Unicode collation); О порядок сортировки (sort order).

Чтобы изменить любую из этих настроек, необходимо было перестроить системную базу данных master с помощью утилиты rebuildm.exe, которая позволяет изменить порядок сортировки, набор символов и сопоставление Unicode. Однако при выполнении подобного перестроения теряется любая информация, накопленная на сервере. В этом плане перестроение базы данных master можно сравнить с удалением и повторной установкой сервера. Если же было необходимо сохранить пользовательские базы данных и объекты, приходилось сначала создавать сценарии (script), описывающие создание всех объектов, а затем копировать данные, используя возможности служб преобразования данных (Data Transformation Services, DTS) или утилиту массового копирования (bulk copy program, bcp).

В SQL Server 2000 больше не нужно отдельно определять кодовую страницу, используемую для символьных данных, порядок сортировки символьных данных и сопоставления для данных Unicode. Вместо этого вы просто указываете требуемые название сопоставления и сортировку.

Физическое хранение символьных строк и операции их сравнения в SQL Server 2000 зависят от сопоставления. Сопоставление определяет двоичные образцы, которые представляют каждый символ, и правила, по которым символы сортируются и сравниваются. При работе с SQL Server 7.0 эти параметры задавались при установке сервера и были едины для всех объектов и данных, имеющихся в базах данных этого сервера.

В SQL Server 2000 значение сопоставления, указанное при установке сервера, рассматривается только как значение по умолчанию, которое используется при создании всех объектов. Разрешается создание разных сопоставлений в одной и той же базе данных одного и того же сервера объектов. Более того, в одной таблице могут иметься столбцы, использующие различные сопоставления.

SQL Server 2000 поддерживает два вида сопоставлений.

О Сопоставление Windows (Windows Collation). Этот вид сопоставления определяет набор правил для хранения и сортировки символьных данных, основанных на правилах, определенных для операционной системы Windows.

О Сопоставление SQL (SQL Collation). Этот вид сопоставления обеспечивает совместимость с более ранними версиями Microsoft SQL Server.

Каждое сопоставление SQL включает в себя следующую информацию.

О Порядок сортировки для данных Unicode (nchar, nvarchar и ntext). Порядок сортировки определяет последовательность, в которой сортируются символы, и то, как оцениваются символы при операциях сравнения.

О Порядок сортировки для символьных данных, не относящихся к Unicode (char, varchar-и text).

О Кодовая страница, используемая для сортировки символьных данных, не относящихся к Unicode.

Чтобы при установке произвести изменения заданных по умолчанию параметров настройки сопоставления, используйте окно Collation Settings (параметры сопоставления). Вариант Collation Designator (назначение сопоставления) обеспечивает настройку параметров сопоставления Windows, а вариант SQL Collations (сопоставление SQL) — настройку параметров сопоставления, совместимых с SQL Server 7.0, SQL Server 6.5 или более ранними версиями.

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

Выбор сопоставления

На одном из этапов установки в окне Collation Settings (параметры сопоставления) мастер установки SQL Server 2000 предлагает выбрать сопоставление (collation), которое будет использоваться по умолчанию на сервере. Этот выбор осуществляется с помощью раскрывающегося списка с вариантами допустимых сопоставлений. Например.

О Вариант Latinl_General предназначен для американизированного английского набора символов (кодовая страница 1252).

О Вариант Modern_Spanish предназначен для всех разновидностей испанског языка, в котором используется тот же набор символов, что и в английское (кодовая страница 1252).

О Вариант Arabic предназначен для всех разновидностей арабского языка довая страница 1256).

О Для России по умолчанию предлагается использовать сопоставление Windows, называющееся Cyrillic_General, тем не менее можно указать любое другое сопоставление. Также можно выбрать сопоставление SQL. В этом случае в распоряжении пользователя имеется множество различных сопоставлений, каждое из которых имеет свои отличительные характеристики. Сопоставления для России используют набор символов 1251, то есть оканчиваются на строку for use the 1251 (Cyrillic) Character Set. На уровне сервера указанные сопоставления относятся к семейству сопоставлений SQL_Latinl_General. В частности, при выборе сопоставления Windows с именем Cyrillic_General на уровне сервера будет использоваться сопоставление SQL_Latinl_General_Cpl_CI_AS. Это сопоставление устроит большинство пользователей. В частности, при сравнении символов не учитывается регистр.

Выбор порядка сортировки

Сопоставление Windows определяет только набор символов, который будет доступен пользователям. Однако собственно сопоставление не определяет правила сравнения и сортировки символьных данных. Поэтому эти параметры должны быть сконфигурированы отдельно. Для этого в окне Collation Settings (параметры сопоставления) используется набор флажков Sort Order (порядок сортировки), с помощью которых разрешается тот или иной метод сортировки. В табл. 7.5 указано назначение флажков.

Таблица. Типы сортировки

Тип сортировки______Описание________________________________

Символы сравниваются в соответствии с их порядковым номером в таблице символов. Этот вид сортировки наиболее быстрый, так как не требует дополнительных вычислений

Одни и те же символы, но записанные в разных регистрах, считаются разными

Определяет, что SQL Server будет делать различие между символами с диакритическим знаком и без него. Например, а не будет равно а____________________________

Binary Order (двоичная сортировка)

Case-sensitive (с учетом регистра)

Accent-sensitive (с учетом диакритических знаков)

Двоичная сортировка является самым быстрым методом сравнения данных и всегда учитывает регистр. Однако при использовании этой сортировки флажки Case-sensitive (с учетом регистра) и Accent-sensitive (с учетом диакритических знаков) будут недоступны.

Как уже было сказано, выбранные при установке сервера параме?ры сопоставления оказывают влияние на многие аспекты функционирования SQL Server 2000. Например, порядок сортировки играет большую роль при сравнении пароля, введенного пользователем, с паролем, хранимым в системной базе данных. Если применяется порядок сортировки, чувствительный к регистру символов, то при вводе пароля пользователь должен в точности соблюдать регистр. Если же используется нечувствительная к регистру сортировка, то пользователь может не заботиться о регистре, в котором он набирает пароль.

Когда вы передаете данные пользователей (включая пароли) между серверами, имеющими разный порядок сортировки, возможно два варианта поведения сервера, на который переносятся данные (сервера назначения).

Первый случай имеет место, когда исходный сервер был нечувствителен к регистру символов. Тогда при вводе пароля он сохраняется в верхнем регистре, и пользователь может зарегистрироваться на втором сервере, вводя пароль в верхнем регистре.

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

Выбор метода установки

SQL Server 2000 поддерживает три способа установки, предоставляя администраторам разные возможности автоматизации и упрощения процесса установки. От выбора того или иного метода зависит, какой набор шагов будет предложен мастером установки.

Система SQL Server 2000 может быть установлена с использованием одного из следующих методов установки: О Local Installation (локальная установка); О Remote Installation (удаленная установка); О Unattended Installation (автоматическая установка).

Рассмотрим более подробно использование каждого типа установки.

Локальная установка

При локальной установке все файлы SQL Server устанавливаются на тот компьютер, на котором она инициирована.

Локальный метод установки является самым простым из всех поддерживаемых. В этом случае мастер установки последовательно выдает пользователю набор окон, в которых тот должен указать параметры конфигурации. В процессе установки вам будет необходимо ввести свое имя, наименование организации и серийный номер, полученный при покупке SQL Server 2000. Эта информация также необходима, если вы обращаетесь в службу технической поддержки Microsoft. На последующих этапах необходимо ввести информацию о размещении файлов сервера и баз данных, кодовой странице, порядке сортировки, сопоставлении, сетевых протоколах и библиотеках, а также сведения об учетных записях, под которыми будет запускаться SQL Server. Для запуска мастера установки SQL Server 2000 необходимо запустить программу Setupsql.exe.

По умолчанию для установки сервера выбирается папка Program FilesMic SQL Server, а базы данных размещаются в панке Data установочной папки SQL Server 2000 (Mssql). В процессе установки программа собирает все данные о параметрах конфигурации, вводимые пользователем, и сохраняет их в файле Setup.iss. Файл Setup.iss вы можете найти в папке Install установочной папки SQL Server 2000.

Файл Setup.iss впоследствии может оказаться очень полезным для повторной локальной установки, а также для выполнения удаленной или автоматической установки.

Кроме того, в процессе установки ведется журнал, в котором отображается информация о каждой фазе установки. Журнал представляет собой обычный файл с именем Sqlstp.log, который сохраняется в корневой папке операционной системы, например в папке WinNT. Информация об ошибках в процессе установки записывается в файлы Errorlog и хранится в папке l_og установочной папки SQL Server 2000.

После того как все файлы сервера скопированы и все подготовительные операции выполнены, программа установки приступает к настройке параметров работы сервера.

Удаленная установка

Windows NT и Windows 2000 предоставляют нам поистине потрясающие возможности, позволяя не только производить удаленное администрирование компьютеров домена, но и устанавливать программное обеспечение на компьютере, находящемся в соседней комнате, не вставая из-за рабочего стола.

Удаленная установка запускается также программой Setupsql.exe на том компьютере, с которого производится удаленная установка. Однако кроме данных, необходимых при локальной установке, от вас потребуется ввести еще и дополнительную информацию — это и понятно, так как в этом случае используется еще и сеть: О Username (имя пользователя) — имя пользователя, учетная запись которого

будет использована на удаленном компьютере для выполнения установки SQL Server 2000;

О Password (пароль) — пароль пользователя;

О Domain (домен) — имя домена, к которому принадлежит учетная запись пользователя;

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

О Target Computer (целевой компьютер) — имя удаленного компьютера, на который будет производиться установка SQL Server 2000;

О Target Path (UNC) (целевой путь в формате UNC) — полное описание пути в формате UNC к папке, в которую планируется установить SQL Server'.

О Setup Source Files (установочные файлы) — полный путь в формате UNC к установочным файлам SQL Server 2000 в сети.

После того как будут введена информация для указанных выше параметров, последующая работа мастера установки весьма напоминает локальную установку. Мастер собирает информацию обо всех параметрах установки, таких как сопоставление, имена и пароли учетных записей для запуска служб SQL Server 2000, установочная папка для самого сервера и папка для хранения баз данных, список устанавливаемых компонентов и т. д. После того как вся необходимая для установки SQL Server 2000 информация введена, она, как и при выполнении локальной установки, сохраняется в файле Setup.iss. Однако собственно установки сервера при этом мастер установки не выполняет. Он лишь запускает на удаленном компьютере программу remsetup.exe, которая и будет выполнять установку SQL Server 2000. На этом работа мастера установки Installation Wizard (программы setup.sql) заканчивается.

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

На удаленном компьютере программа remsetup.exe копирует файлы, необходимые для установки, в сетевую папку Admin$, в том числе и файл Setup.iss, из которого считывает данные об установке. После этого начинается собственно установка SQL Server 2000.

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

О на локальном компьютере — права на запуск мастера установки и сохранение файла Setup.iss;

О на удаленном компьютере — права доступа с административными полномочиями.

Не обязательно, чтобы пользователь, запускающий программу установки, имел права администратора на удаленном компьютере. Мастер установки позволяет явно указать учетную запись, которая будет использована на удаленном компьютере для запуска программы Remsetup.exe. Кроме того, подойдет любая учетная запись, в том числе учетная запись пользователя, запускающего программу Setupsqi.exe на локальном компьютере. Также может быть использована одна из учетных записей, сконфигурированных для запуска служб SQL Server 2000. Единственным требованием является наличие необходимых прав доступа.

Выполнение удаленной установки возможно только в том случае, если локальный и удаленный компьютеры работают под управлением операционной системы Windows NT или Windows 2000.

Автоматическая установка

Если вам необходимо выполнить аналогичные установки SQL Server 2000 на нескольких компьютерах, вы можете реализовать автоматическую установку,которая позволяет не вводить данные вручную, а использовать специальный файл, который содержит всю информацию о конфигурации SQL Server. Кром того, автоматическая установка удобна для повторной установки SQL Server 2000 с теми же параметрами конфигурации, что и при первой установке.

Автоматическая установка может быть выполнена двумя способами: О с использованием Microsoft Systems Management Server (SMS); О с использованием файла автоматической установки Setup.iss.

Использование Microsoft Systems Management Server

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

Microsoft System Management Server — сервер управления системой — является ключевым звеном пакета Microsoft BackOffice, позволяя существенно облегчить жизнь системных администраторов. Одной из возможностей сервера SMS является его способность выполнять типовую установку программного обеспечения на большое число компьютеров сети с минимальным участием пользователя.

Вы можете использовать Microsoft System Management Server версии 1.2 или выше для автоматической установки Microsoft SQL Server 2000 на множестве компьютеров сети предприятия.

Компакт-диск с SQL Server поставляется с файлом Smssql.pdf, который автоматически создает установочный пакет SMS. После этого сервер можно устанавливать с помощью SMS на многих компьютерах. Файлы .pdf представляют собой обычные текстовые файлы, в которых содержится информация о действиях, которые должны быть выполнены Microsoft SMS. Файл Smssql.pdf содержит команды для запуска bat-файлов, поставляемых на компакт-диске с дистрибутивом SQL Server 2000. Файл smscli.bat предназначен для выполнения автоматической установки утилит администрирования SQL Server 2000 с использованием пакета SMS. Файл smssqins.bat предназначен для выполнения обычной установки утилит администрирования SQL Server 2000 с использованием пакета SMS. При необходимости пользователь может скопировать файл smssql.pdf и внести в него необходимые изменения.

Использование файла автоматической установки

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

Создание файла автоматотеской установки Setup.iss возможно одним из двух способов. Во-первых, можно использовать для этого любой текстовый редактор, например Notepad. Второй альтернативой будет запуск программы Setupsql.exe с ключом k=Rc. Этот ключ указывает программе установки сначала собрать все сведения о конфигурации, а затем начать копирование файлов. Когда сбор сведений заканчивается, появляется диалоговое окно, предупреждающее о начале копирования файлов. Если щелкнуть на кнопке Cancel (отмена), то программа установки сохранит все введенные данные в папке операционной системы в файле Setup.iss. Необходимо лишь добавить секции [SdStartCopy-О] и [SdFinish-0] вконец файла

Файл Setup.iss также создается и в случае обычной установки. При создании файла автоматической установки следует учитывать, что возможность его использования для установки SQL Server на множество компьютеров зависит от конкретной ситуации. Например, если при создании файла Setup.iss вы использовали локальную учетную запись, а на удаленном компьютере не существует пользователя с таким же именем и паролем, установка может не удаться. Конфигурация дисков на компьютерах также должна быть одинаковой.

SQL Server 2000 поставляется с пятью исполняемыми bat-файлами: О sqlcli.bat — устанавливает только средства управления SQL Server 2000, использует в своей работе файл автоматической установки sqlcli.iss;

О sqlins.bat — выполняет типичную установку, устанавливая локальную учетную запись системы для запуска служб, использует файл sqlins.iss;

О sqlcst.bat — выполняет заказную установку всех компонентов, устанавливая локальную учетную запись системы для запуска служб, запускает программу Setupsql.exe с файлом sqlcst.iss;

О sqlupg.bat — выполняет автоматическое обновление до SQL Server 2000 на операционной системе Windows NT;

О sqlrem.bat — удаляет SQL Server 2000.

Вы также можете скопировать и отредактировать любой из этих файлов по своему усмотрению. Например, разрешить использование доменной учетной записи пользователя в файле sqlins.iss для выполнения типичной установки.

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

Создание учетных записей

SQL Server 2000 под управлением операционных систем Windows NT и Windows 2000 функционирует как служба операционной системы, или, точнее, как две службы — MSSQLServer и SQLServerAgent. Система защиты Windows NT и Windows 2000 требует, чтобы любой доступ к ресурсам был подтвержден наличием соответствующих прав. Хотя все службы и являются частью одного приложения, все же перед тем как начать работу, они обязаны пройти проверку прав доступа подобно обычным пользователям. Как известно, права и разрешения назначаются на основе учетных записей. Таким образом, некоторые службы SQL Server 2000, которые обращаются к ресурсам сети, обязаны иметь собственные учетные записи, причем разные службы могут иметь разные учетные записи.

Этот раздел имеет отношение только к операционным системам семейства Windows NT и Windows 2000. В операционной системе Windows 98 не реализована возможность выполнения при-1 ложений в виде служб операционной системы. При запуске SQL Server 2000 под управлением этой j операционной системы используется учетная запись текущего пользователя. Как следствие, SQL' Server 2000 будет иметь те же права доступа, что и пользователь, запустивший это приложение. '

Различается три вида учетных записей, под которыми может стартовать SQL ;

Server.

О Local System (локальная система). Учетная запись локальной системы создается автоматически при установке операционной системы. Под этой учетной записью служба SQL Server запускается с правами операционной системы. Все действия по управлению этой учетной записью, в том числе и изменения пароля, выполняет сама операционная система. Даже администратор не может управлять ею. Данная учетная запись имеет права администратора и обычно по умолчанию ей предоставляется доступ ко всем файлам. Однако если вы решили для запуска SQL Server 2000 использовать локальную учетную запись, убедитесь в том, что она имеет полный доступ ко всем необходимым файлам и папкам SQL Server 2000, и если потребуется, то предоставьте сами этой учетной записи доступ к тем или иным ресурсам.

О Local User (локальный пользователь). Данная учетная запись создается на отдельном компьютере. Соответственно, область действия подобных учетных записей ограничивается одним этим компьютером. При запуске SQL Server 2000 под учетной записью локального пользователя, не входящего в группу локальных администраторов, следует предоставить этой учетной записи полный доступ ко всем файлам и папкам SQL Server 2000, а также разрешить ей регистрироваться локально и стартовать в качестве службы операционной системы.

О User for Domain (пользователь домена). Принципиальным отличием учетных записей пользователя домена является возможность работы в сети. Учетные записи этого типа хранятся централизованно на контроллере домена (domain controller) Windows NT или Windows 2000 и доступны с любого компьютера, входящего в домен.

Учетные записи локальной системы и локального пользователя не поддерживают сетевые операции. Следовательно, когда сервер SQL Server 2000 работает под локальной учетной записью, то он будет иметь ограниченные возможности. В частности, нельзя будет выполнять следующие действия: О вызов удаленных процедур (Remote Procedure Calls, RPC); О репликация; О резервное копирование данных на сетевой диск;

О использование разнородных источников данных, требующих сетевого соединения;

О поддержка электронной почты.

Таким образом, выбирая тип учетной записи, учитывайте те возможности, которые она предоставляет.

Во всех случаях, требующих наличия сети, необходимо использовать учетную запись пользователя в домене. Кроме того, если предполагается репликация, то рекомендуется использовать на всех серверах одну и ту же учетную запись пользователя в домене для запуска служб SQL Server 2000. Это гарантирует, что не возникнет никаких конфликтов разрешений на доступ к ресурсам. При конфигурировании репликации рекомендуется использовать одну и ту же учетную запись пользователя для издателя и подписчика, чтобы избежать проблем с разграничением доступа.

Основным компонентом SQL Server 2000 является служба MSSQLServer. Все остальные компоненты (SQLServerAgent, Microsoft Search и MSDTC) устанавливают соединение с MSSQLServer. При этом учетные записи, под которыми стартуют службы SQLServerAgent и MSDTC, должны иметь соответствующие права на самом сервере. Для этого необходимо назначить соответствующим учетным записям встроенную роль сервера (fixed server role) Sysadmin.

Служба Microsoft Search может стартовать только под локальной учетной записью системы. Для установления соединения со службой MSSQLServer она использует имя и пароль учетнбй записи, под которой стартует служба MSSQLServer.

Как уже говорилось выше, каждая служба SQL Server 2000 может стартовать под собственной учетной записью. Но если нет особых на то причин, то для того чтобы избежать проблем с правами доступа, рекомендуется запускать все службы под одной учетной записью. Также можно предоставить учетным записям служб права администратора локальной операционной системы, включив их в группу Administrators. Это даст возможность SQL Server 2000 перезапускать сервер и поможет избежать некоторых проблем с автоматическим выполнением заданий (jobs). Однако такой подход открывает потенциальную возможность взлома системы с использованием SQL Server 2000. Если вы хотите максимально обезопасить систему, то лучше потратить некоторое время на конфигурирование прав доступа, не предоставляя учетной записи административных прав.

Независимо от того, под какой учетной записью предполагается запуск служб SQL Server 2000, необходимо убедиться в том, что эта учетная запись имеет следующие права:

О доступ и изменение файлов в папке Program FilesMicrosoft SQL ServerMssql; О доступ и изменение файлов баз данных — mdf, ndf и Idf;

О чтение и запись следующих ключей реестра:

* HKEY_LOCAL_MACHINESoftwareMicrosoft MSSQLServer; » HKEY_LOCAL_MACHINESystemCurrentControl set Services MSSQLServer. . Если свойства запуска служб SQL Server 2000 сконфигурированы некорректно, то впоследствии их можно изменить с помощью утилиты Services (службы) из окна Control Panel (панель управления) или с помощью интерфейса Enterprise Manager

Как уже говорилось выше, каждая служба SQL Server 2000 может стартовать под собственной учетной записью. Но если нет особых на то причин, то для того чтобы избежать проблем с правами доступа, рекомендуется запускать все службы под одной учетной записью. Также можно предоставить учетным записям служб права администратора локальной операционной системы, включив их в группу Administrators. Это даст возможность SQL Server 2000 перезапускать сервер и поможет избежать некоторых проблем с автоматическим выполнением заданий Gobs). Однако такой подход открывает потенциальную возможность взлома системы с использованием SQL Server 2000. Если вы хотите максимально обезопасить систему, то лучше потратить некоторое время на конфигурирование прав доступа, не предоставляя учетной записи административных прав.

О доступ и изменение файлов в папке Program FilesMicrosoft SQL ServerMssql; О доступ и изменение файлов баз данных — mdf, ndf и Idf; О чтение и запись следующих ключей реестра:

« HKEY_LOCAL_MACHINESoftwareMicrosoftMSSQLServer;

» HKEY_LOCAL_MACHINESystemCurrentControlsetServicesMSSQLServer.

Если свойства запуска служб SQL Server 2000 сконфигурированы некорректно, то впоследствии их можно изменить с помощью утилиты Services (службы) из окна Control Panel (панель управления) или с помощью интерфейса Enterprise Manager.

Создание учетных записей в Windows 2000

Создание учетных записей в Windows 2000 отличается от создания учетных записей в Windows NT 4.0. Для управления учетными записями пользователей домена Windows 2000 используется оснастка (в терминологии Windows NT -утилита) Active Directory Users and Computers. Когда же выполняется конфигурирование учетных записей локальных пользователей, то используется оснастка Computer Management (рис. 7.4). В этом разделе будет рассмотрено создание учетных записей для локальных пользователей Windows 2000. Создание пользователей домена отличается лишь тем, что требуется иная утилита и ввод несколько большего количества информации о пользователе. Однако мы не будем рассматривать конфигурирование дополнительных сведений о пользователе, таких как адрес его электронной почты, профиль, возможность использования RAS и т. д.

При работе с оснасткой Computer Management информация о локальных пользователях хранится в папке System ToolsLocal Users and GroupsUsers. При выборе в левой части окна этой папки в правой части будет отображен список всех пользователей, созданных на выбранном для администрирования компьютере. Для создания нового пользователя необходимо в контекстном меню папки Users выбрать пункт New User (новый пользователь). В ответ откроется одноименное диалоговое окно (рис. 7.5), с помощью которого необходимо указать основные сведения о создаваемой учетной записи.

Если компьютер, на который предполагается установить SQL Server 2000, является контроллером домена Windows 2000, то использование локальных учетных записей пользователей на этом компьютере невозможно, поэтому соответствующие пункты оснастки Computer Management будут недоступны.

Рассмотрим назначение элементов управления, имеющихся в окне New User

(новый пользователь).

О User name (имя пользователя). Имя учетной записи, которое будет использоваться при регистрации пользователя в домене. Это имя может быть произвольным и не всегда отражать имя самого пользователя.

О Full name (полное имя). В этом поле указывается полное имя владельца учетной записи.

О Description (описание). Это поле предназначено для небольшого комментария, который помогает идентифицировать учетную запись или ее владельца. Допускается краткая запись любых других сведений.

О Password (пароль). В этом поле указывается пароль, под которым пользователю будет разрешаться вход в домен.

О Conform Password (подтверждение пароля). В этом поле необходимо повторить тот же пароль, что и в предыдущем поле. Это делается, чтобы гарантировать ввод правильного пароля и избежать ошибок.

О User must change password at next logon (пользователь должен сменить пароль при следующем входе в систему). Установив этот флажок, администратор тем самым потребует от пользователя смены пароля при следующем входе в домен.

О User cannot change password (пользователь не должен менять пароль). Если администратор установит для пользователя этот флажок, то пользователь не сможет самостоятельно сменить пароль и будет вынужден обратиться к администратору. Такая ситуация необходима, если кроме этого пользователя под тем же самым паролем работает еще кто-либо. В этом случае администратор сможет известить второго пользователя о том, что пароль был изменен.

О Password never expires (срок действия пароля не истекает). Установка этого флажка позволяет избежать частой смены пароля пользователем.

О Account disabled (блокирование учетной записи). При установке этого флажка учетная запись блокируется и не допускает регистрации в домене ни хозяина учетной записи, ни кого-либо еще. Эта возможность часто используется, если предполагается длительное отсутствие пользователя на рабочем месте. Такой подход поможет избежать несанкционированного доступа к ресурсам. Чтобы использовать учетные записи пользователей Windows 2000 для запуска служб Server 2000, как и при конфигурировании учетных записей Windows NT 4.0, им необходимо предоставить дополнительные права. В Windows 2000 управление правами осуществляется отдельно от управления учетными записями. Для управления правами в пределах локального компьютера используется оснастка Local Security Policy (рис. 7.6).

Для предоставления учетной записи необходимых прав выполните описанные ниже действия.

1. В оснастке Local Security Policy выберите папку Local Policies.

2. В папке Local Policies выберите вложенную папку User Right Assignment. В правой части окна будет выведен список прав, которые могут быть присвоены пользователям.

3. Для присвоения пользователю того или иного права дважды щелкните на названии права и в открывшемся диалоговом окне Local Security Policy Settings (параметры локальной политики безопасности) щелкните на кнопе Add (добавить), после чего выберите имя нужного пользователя.

Как и при работе с Windows NT, для того чтобы учетная запись Windows 2000 могла использоваться для запуска служб SQL Server 2000, ей необходимо присвоить следующие права:

О Act as a part of the operating system (действовать как часть операционной системы); О Log on as a service (регистрироваться в качестве службы операционной системы);

О Increase quotas (право изменять квоты процессов);

О Replace a process level token (право заменять уровень маркера процесса).

После того как все указанные права будут предоставлены учетной записи (или всем учетным записям), которую предполагается использовать для запуска служб SQL Server 2000, подготовку учетных записей можно считать оконченной.

Выбор типа установки

При установке SQL Server 2000 в редакциях Enterprise, Standard, Personal edition мастер установки предложит вам выбрать один из трех типов установки. О Обычный тип установки (Typical). Устанавливаются заданные по умолчанию компоненты. Такой тип установки рекомендуется для большинства пользователей.

О Минимальный тип установки (Minimum). Устанавливается минимальная конфигурация, необходимая для работы SQL Server. Этот тип рекомендуется для пользователей, имеющих компьютер с небольшим доступным дисковым пространством.

О Выборочный тип установки (Custom). Этот тип установке позволяет выбрать необходимые именно для вас компоненты. Производить выборочную установку рекомендуется опытным пользователям.

Если вы запускаете программу установки SQL Server для редакций, которые не поддерживаются вашей операционной системой, например, если устанавливается SQL Server Standard Edition под Microsoft Windows 98, программа не будет предлагать вам выбрать тип установки. Вместо этого сразу предлагается выбрать инструменты администрирования в диалоговом окне Select Components (выбор компонентов).

Установка сетевых библиотек и протоколов

Как уже было сказано ранее в этой главе, для обеспечения сетевого взаимодействия серверов SQL Server и их клиентов требуются так называемые сетевые библиотеки (network library), использующие определенные сетевые протоколы для передачи данных. Эти библиотеки реализованы в виде dll-файлов (Dynamic-link library, DLL), подключаемых к операционной системе. Сама по себе сетевая библиотека не обеспечивает возможности коммуникации, для этого необходимо установить соответствующий сетевой протокол. Библиотека представляет собой программный интерфейс, реализующий работу с SQL Server 2000. Сетевые библиотеки устанавливаются как на сервере, так и на клиенте.

SQL Server 2000, как: и SQL Server 7.0, может использовать большинство сетевых протоколов операционной системы. Операционные системы семейства Windows имеют встроенную поддержку сети, то есть в состав этих операционных систем входит набор стандартных протоколов и служб, с помощью которых можно выполнять базовые сетевые операции работы с файлами и принтерами. Управление сетевыми протоколами могут различаться при работе с различными операционными системами. Конфигурирование же сетевых библиотек практически не зависит от используемой операционной системы, так как эта операция осуществляется на уровне SQL Server 2000.

Установка сетевых протоколов в
Windows 2000

В операционной системе Windows 2000 установка и конфигурирование сетевых протоколов несколько иная по сравнению с Windows NT 4.0. Для управления настройками локальной сети используется окно Local Area Connection Properties (свойства локального соединения).

1. В главном меню операционной системы выберите пункт Start > Settings * Network and Dial-Up Connections (пуск > настройка > сетевые соединения).

2. В открывшемся окне (рис. 7.11) дважды щелкните на значке Local Area Connection (локальное соединение), после чего откроется окно Local Area Connection Status (состояние локального соединения), показанное на рис. 7.12.

Теперь остается только щелкнуть на кнопке Properties (свойства), что и приведет к открытию окна Local Area Connection Properties (свойства локального соединения).

В окне Local Area Connection Properties (свойства локального соединения) отображается название сетевой карты и ниже приведен список сетевых протоколов и служб, установленных для указанной сетевой карты. Для добавления или удаления

протокола используйте кнопки Install (установить) или Uninstall (удалить). Для добавления нового протокола необходимо выполнить следующие шаги.

1. Щелкните на кнопке Install (установить). После этого откроется диалоговое окно Select Network Component Type (выбор типа сетевого компонента), которое предназначено для выбора тина устанавливаемого сетевого компонента

2. Для установки нового протокола выделите пункт Protocol (протокол) и щелкните на кнопке Add (добавить). В итоге откроется диалоговое окно Select Network Protocol (выбор сетевого протокола), с помощью которого, собственно, и выбирается устанавливаемый протокол (рис. 7.14). р сетевого протокола) содержится список протоколов, поставляемых вместе с операционной системой Windows 2000 и еще не установленных в системе. Если предполагается установить протокол стороннего производителя, то необходимо явно указать папку, в которой содержатся соответствующие файлы. Для этого нужно воспользоваться кнопкой Have Disk (установить с диска).

После того как нужный протокол выбран, остается только щелкнуть на кнопке ОК. Для некоторых протоколов (например, NetBEUI) на этом их установка заканчивается. Однако при работе со сложными протоколами (например, TCP/IP) может потребоваться конфигурирование свойств устанавливаемого протокола.

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

Одновременно SQL Server 2000 может работать с несколькими сетевыми библиотеками. В табл. 7.7 приведен список и назначение сетевых библиотек, поставляемых в составе SQL Server 2000.

Сетевая библиотека Описание

AppleTalk ADSP Позволяет клиентам Apple Macintosh подключаться к серверам SQL Server 2000 по протоколу AppleTalk взамен TCP/IP Sockets. Вам не обязательно конфигурировать зоны Apple Macintosh, так как используется текущая зона. Библиотека не поддерживается на операционных системах Windows 95/98

Multiprotocol Работает через вызовы удаленных процедур RPC с использованием

большинства механизмов IPC Windows NT: TCP/IP Sockets, Named Pipes, NWLink IPX/SPX и т. д. Не нуждается в конфигурировании. Лри работе под управлением операционной системы Windows NT позволяет шифровать данные при передаче по сети, а также выполнять аутентификацию Windows NT поверх любого протокола. Не поддерживается при установке SQL Server 2000 на Windows 98

Named Pipes Позволяет SQL Server 2000 использовать именованные каналы. Может (именованные работать поверх основных протоколов Windows. Следует учитывать, что каналы) Windows 98 не поддерживает серверную часть именованных каналов — доступна только их клиентская часть. Используется в Windows NT и Windows 2000 по умолчанию. По умолчанию для SQL Server устанавливается канал .pipesqlquery. Если на одном сервере установлено несколько копий SQL Server, то для обращения к конкретной копии требуется канал .pipeMSSQL$instancenamesqlquery

NWLink IPX/SPX Позволяет подключаться к SQL Server 2000 клиентам Novell NetWare Shared Memory С помощью библиотеки Shared Memory можно имитировать систему (разделяемая клиент-сервер на локальном компьютере, и потому ее рекомендуется память) использовать на компьютерах, не имеющих поддержки сети. Данная библиотека не является в полном смысле сетевой, хотя и имеет те же интерфейсы, что и другие библиотеки

TCP/IP Sockets Работает поверх механизма IPC через сокеты протокола TCP/IP. Сокеты (сокеты TCP/IP) TCP/IP используются по умолчанию на всех операционных системах, в том числе и на Windows 98. При установке этой библиотеки необходимо указать порт, по которому будет осуществляться обмен данными. Для SQL Server 2000 портом по умолчанию является порт 1433. Возможна работа через прокси-сервер Banyan VINES С помощью этой библиотеки возможна работа клиентов, использующих протокол Banyan VINES IP. Для этих клиентов по протоколу Banyan VINES Sequenced Packet Protocol, работающему поверх протокола Banyan VINES IP, _________организуется соединение через механизмы IPC____________

В процессе установки SQL Server 2000 необходимо выбрать требуемые библиотеки. Если какая-то нужная библиотека не была установлена, то ее можно установить позже, воспользовавшись утилитой сетевого конфигурирования сервера SQL Server Network Utility (рис. 7.15). Эта утилита автоматически устанавливается вместе с SQL Server 2000.

Для запуска этой утилиты SQL Server Network Utility можно воспользоваться либо главным меню операционной системы, выбрав пункт Start > Programs > Microsoft SQL Server > Server Network Utility (пуск > программы > Microsoft SQL Server > Server Network Utility), либо запустив файл svrnetcn.exe, который находится в папке ToolsBin установочной папки SQL Server 2000. После этого откроется собственно окно утилиты, приведенное на рисунке.

Как видно, окно утилиты имеет две вкладки — General (общие) и Network Libraries (сетевые библиотеки). В свою очередь, на вкладке General (общие) имеется два списка — Disabled protocols (доступные протоколы) и Enabled protocols (установленные протоколы). В первом списке перечислены библиотеки, доступные для установки, но не используемые в работе сервера. Второй же список содержит перечень библиотек, которые используются в текущей работе SQL Server 2000. Для изменения параметров любой из них необходимо выделить имя библиотеки и щелкнуть на кнопке Properties (свойства), после чего откроется диалоговое окно свойств выбранной сетевой библиотеки. На рис. 7.16 приведено окно свойств библиотеки Multiprotocol.

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

Установка и конфигурирование клиентов

Как уже было сказано, чтобы клиент имел возможность подключаться к SQL Server 2000, на нем должен быть установлен по крайней мере один сетевой протокол и сетевая библиотека, соответствующая сетевой библиотеке сервера, В противном случае клиент не сможет установить соединение с SQL Server 2000. В составе всех операционных систем семейства Windows имеется набор общих сетевых протоколов. Однако сетевые библиотеки должны быть установлены отдельно. Для их этого можно воспользоваться мастером установки SQL Server 2000, выбрав режим установки Client Connective Only (только для соединения клиента). В этом случае на компьютер будет установлены только компоненты, необходимые для соединения клиентов с SQL Server 2000.

Если на клиенте используется несколько библиотек, то соединение с сервером может быть установлено с помощью любой из них. Однако после того как соединение установлено, работа с сервером ведется посредством только одной библиотеки, выбор которой происходит следующим образом: клиент по очереди перебирает библиотеки, перечисленные в списке Enabled Protocols (установленные протоколы) вкладки General (общие) утилиты SQL Server Network Utility, начиная с самой верхней. Если на сервере имеется аналогичная библиотека и параметры конфигурации сервера и клиента совпадают, то перебор на этом останавливается и для соединения выбирается эта библиотека. Получается, что библиотека, находящаяся вверху списка, имеет больше шансов для установки соединения. Поэтому если желательно, чтобы клиент использовал конкретную библиотеку, ее следует поместить вверху списка.

К компонентам, необходимым для соединения клиентов с SQL Server 2000, относятся сетевые библиотеки и утилита Client Network Utility (рис. 7.18), с помощью которой выполняется конфигурирование сетевых библиотек со стороны клиента. Запустить утилиту можно из главного меню операционной системы, выбрав пункт Start > Programs > Microsoft SQL Server > Client Network Utility (пуск > программы > Microsoft SQL Server > Client Network Utility) либо запустив файл cliconfg.exe из папки SYSTEM операционной системы Windows 98 или SYSTEM32 для Windows NT и Windows 2000.

Как видно из рисунка, окно утилиты Client Network Utility имеет четыре вкладки. Первая их них имеет имя General (общие) и предназначена для управления набором библиотек, используемых для установления соединения с сервером. Назначение списков Disabled protocols (доступные протоколы) и Enabled protocols (установленные протоколы) этой вкладки точно такое же, как и для вкладки General (общие) утилиты Server Network Libraries. В нижней части вкладки имеется два флажка.

О Enable protocol encryption (включить шифрование протокола) — установка эт го флажка обеспечивает шифрование данных, передаваемых по сети. Однако шифрование будет использоваться только в том случае, если оно разрешено как на клиенте, так и на сервере. Установка флажка Enable protocol encryption (включить шифрование протокола) только на клиенте без разрешения шифрования со стороны сервера не обеспечивает шифрования данных.

О Enable shared memory protocol (включить протокол разделения памяти) — установка этого флажка разрешает коллективное использование памяти. Подобный подход используется, когда сервер и клиент находятся на одном компьютере. Обмен данными через оперативную память, а не сетевые протоколы, позволяет повысить скорость обмена.

Возможна ситуация, когда клиент будет взаимодействовать с несколькими серверами, использующими одну и ту же сетевую библиотеку, но с разными параметрами. Так как для каждой библиотеки можно указать только один вариант параметров, то на клиенте нужно будет каждый раз изменять параметры конфигурации в соответствии с настройками сервера. В этом случае удобнее использовать так называемые псевдонимы серверов (server alias). Псевдоним имеет определенно имя и представляет собой набор параметров, описывающих способ подключения клиента к серверу. Имя псевдонима сервера и собственное имя сервера не обязательно должны совпадать. Более того, каждый сервер может иметь более одного псевдонима, каждый из которых может содержать различные варианты конфигурации сетевых библиотек. Конфигурирование псевдонимов осуществляется с помощью вкладки Alias (псевдонимы), показанной на рис. 7.19.

Конфигурирование нового псевдонима осуществляется с помощью окна Add Network Library Configuration (добавление конфигурации сетевой библиотеки). Это окно, показанное на рис. 7.20, можно открыть с помощью кнопки Add (добавить). В этом окне в поле Server alias (псевдоним сервера) необходимо указать имя псевдонима, через которое будет устанавливаться соединение с сервером. Клиент должен будет вводить не имя самого сервера, а соответствующий псевдоним. Для каждого псевдонима допускается использование лишь одной сетевой библиотеки, выбор которой осуществляется с помощью группы переключателей Network libraries (сетевые библиотеки). В области Connection parameters (параметры соединения) настраиваются параметры выбранной библиотеки. Конкретный набор параметров зависит от того, какая библиотека выбрана. После задания всех необходимых параметров остается только щелкнуть на кнопке ОК, после чего псевдоним будет добавлен в список вкладки Alias (псевдонимы).

Клиент может обращаться к серверу, используя технологии ODBC, OLE DB, SQL-DMO (SQL Distributed Management Objects) и DB-Library, работающие поверх сетевых библиотек. Третья вкладка утилиты Client Network Utility называется DB-Library Options (параметры DB-Library) и содержит информацию об установленной на клиенте версии DB-Library (рис. 7.21).

В группе DB-Library information (информация DB-Library) указываются основные сведения о библиотеке. В частности, выводится имя и путь к соответствующему dll-файлу, а также номер версии, дата создания и размер файла. В нижней части окна имеется два флажка, используемые для управления параметрами устанавливаемого с помощью DB-Library соединения.

"О Automatic ANSI to OEM conversion (автоматическое преобразование из OEM в ANSI) — установка этого флажка обеспечивает при передаче данных от кли-

'' ента к серверу автоматическое преобразование текстовых данных из форма-та OEM в формат ANSI, и наоборот — преобразование из ANSI в OEM при передаче от сервера к клиенту.

О Use international settings (использовать национальные установки) — при новке этого флажка библиотека DB-Library будет использовать национальные установки (формат даты, времени, валюты и т. д.) локальной системы. Если же этот флажок снят, будут использоваться значения по умолчанию, сконфигурированные в самой библиотеке.

Флажок Automatic ANSI to OEM conversion (автоматическое преобразование из OEM в ANSI) установлен по умолчанию на всех клиентах, тогда как флажок Use international settings (использовать национальные установки) установлен по умолчанию только на клиентах, работающих под управлением 32-разрядных операционных систем.

По умолчанию как клиенты Windows NT 4.0, Windows 2000, так и клиенты Windows 98 используют для подключения к серверу именованные каналы. Напомним, что Windows 98 не поддерживает серверную часть именованных каналов.

Непосредственно перед установкой SQL Server необходимо закрыть все приложения и остановить все службы, использующие ODBC, такие, например, как Internet Information Service.

Запуск, остановка и приостановка служб

Прежде чем вы сможете зарегистрироваться в SQL Server и приступить к выполнению каких-либо действий, сервер необходимо запустить. Точнее говоря, запустить службу MSSQLServer. Для этого нужно знать, каким образом можно это сделать. Только после того как будет произведен запуск SQL Server и проверены ваши права доступа, вы сможете выполнять какие-либо действия в соответствии с вашими правами, например администрирование сервера или выполнение запросов.

Напомним, что запуск службы SQLServerAgent необходим только в том случае, если требуется автоматизировать администрирование и управление SQL Server 2000.

В этой главе будут подробно рассмотрены различные варианты запуска служб SQL Server 2000, а также их остановка и приостановка.

Мы уже не раз говорили, что основной службой SQL Server 2000 является служба MSSQLServer. Все основные операции с объектами баз данных (выполнение запросов, хранимых процедур и т. д.) реализуются именно благодаря этой службе. Другие службы SQL Server 2000 являются второстепенными, и их работа строится на фундаменте, обеспечиваемом службой MSSQLServer. В принципе, службы MSSearch и MS DTC могут работать и независимо от SQL Server 2000, так как они используются в работе и других продуктов. Тем не менее служба SQLServerAgent не может работать без службы MSSQLServer. Вот почему эту службу необходимо запускать после запуска службы MSSQLServer.

Напомним функции дополнительных служб SQL Server 2000: О служба SQLServerAgent отвечает за автоматическое исполнение заданий и

извещение операторов об ошибках в работе сервера;

О служба MSSearch позволяет реализовать поиск символьной информации в полях таблиц баз данных;

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

с сервером, подобно обычным клиентам. Каждая такая служба самостоятельно

подключается к MSSQLServer, используя определенные учетные записи с соответствующими правами доступа. Итак, чтобы начать работу с SQL Server 2000, достаточно запустить службу MSSQLServer. После этого пользователи могут устанавливать соединения с сервером и выполнять любые действия.

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

Почти все вышесказанное относится к компьютерам, работающим под управлением операционных систем семейства Windows NT. Поскольку операционная система Windows 95/98 не имеет служб, вы можете запускать, останавливать и приостанавливать SQL Server только локально, то есть только на том компьютере, где запущен сервер SQL Server.

Если на компьютере с SQL Server не установлена сетевая поддержка, вы все же сможете выполнять запуск, остановку и приостановку SQL Server. Действия при этом ничем не отличаются от операций с сетью. При установке соединения с локальным сервером, который не поддерживает сеть, используются именован
ные каналы.
Именованные каналы непосредственно обращаются к SQL Server, минуя сетевые компоненты. Как в случае работы с сетью, так и без нее, по умолчанию устанавливается соединение посредством именованных каналов. Йри этом используется стандартный канал .pipesqlquery, если явно не указан какой-либо другой.

В случае если при подключении не указывается имя сервера, производится прямое подключение к локальному
серверу с использованием локальных именованных каналов. Если же указывается имя удаленного
сервера, то используются сетевые именованные каналы
либо другой механизм, например IPX/SPX.

Автоматический старт

Одним из способов запуска служб SQL Server 2000 является их запуск операционной системой. Такой способ запуска называется автоматическим, так как участия пользователя в этом случае не требуется. Запуск службы происходит в момент загрузки операционной системы. Если после этого служба была остановлена, то пользователь должен будет запускать ее вручную.

На одном из этапов установки пользователь может разрешить автоматический запуск служб SQL Server 2000. Если этого не было сделано, впоследствии автоматический запуск можно разрешить одним из следующих методов. О SQL Server Enterprise Manager.
Чтобы установить автоматический старт служб SQL Server 2000 средствами Enterprise Manager, необходимо выбрать сервер и открыть окно его свойств, выбрав в контекстном меню пункт Properties (свойства). В ответ откроется окно SQL Server Properties (свойства SQL Server), показанное на рис. 10.1. В нижней части вкладки General (общие) имеется на-

бор флажков, с помощью которых можно разрешить автоматический запуск для служб MSSQLServer, SQLServerAgent и MSDTC.

О Средства утилиты
Services.
Третий способ заставить SQL Server запускаться автоматически сводится к использованию встроенных в операционную систему средств управления службами. Таким средством является утилита Services (службы) в окне Control Panel (панель управления) операционной системы. В окне утилиты отображается список всех служб, имеющихся в операционной системе. Для каждой службы отображается ее текущее состояние и параметры запуска (рис. 10.2). Запуск службы идентифицируется меткой Started (запущена) в поле Status (состояние). В поле Startup Type (тип запуска) возможны три варианта метки: Automatic (автоматический), Manual (ручной) и Disabled (отключена), которые соответственно означают автоматический запуск, ручной запуск и отключение службы. Для автоматического запуска служб SQL Server 2000 дважды щелкните на имени нужной службы. В ответ откроется окно свойств службы (рис. 10.3). Выбор метода запуска службы конфигурируется с помощью раскрывающегося списка Startup Type (тип запуска), в котором необходимо выбрать пункт Automatic (автоматический).

О Средства утилиты
SQL Server Service Manager.
Утилита SQL Server Service Manager позволяет запускать, останавливать и приостанавливать службы SQL Server 2000 (рис. 10.4). Кроме того, с ее помощью можно установить режим автоматического запуска для служб MSSQLServer, SQLServerAgent и MSDTC. Для этого необхо димо запустить Service Manager, выбрать нужный сервер, указать службу и уста-; новить флажок Auto-start service when OS starts (автоматически старт при запуске операционной системы). Повторите .эту операцию на всех серверах сети для каж дой службы, которую необходимо запускать в автоматическом режиме.

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

Ручной запуск
SQL Server

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

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

О Запуск SQL Server 2000 из окна Control Panel (панель управления) сводится к использованию утилиты Services (службы). Аналогично процедуре установки автозапуска для этого необходимо выбрать нужную службу, открыть окно свойств службы (см. рис. 10.3) и щелкнуть в нем на кнопке Start (пуск). Если в поле Startup Type (тип запуска) указан режим Disabled (отключена), то сразу запустить службу не удастся. Предварительно необходимо изменить режим ее запуска на Manual (ручной) или Automatic (автоматический) и только после этого выполнять запуск службы.

Поскольку SQLServerAgent является зависимой службой, сначала необходимо запускать службу MSSQLServer и лишь затем SQLServerAgent.

О Второй способ ручного запуска SQL Server предполагает использование SQL Server Enterprise Manager. Для этого щелкните правой кнопкой мыши на имени нужного сервера. В открывшемся контекстном меню можно выбрать команды, разрешенные для сервера в данный момент (рис. 10.5). Таким способом можно запускать (команда Start), останавливать (команда Stop) и приостанавливать (команда Pause) как локальные, так и удаленные серверы. Заметим, однако, что этот метод позволяет запускать только службу MSSQLServer. Значок службы SQLServerAgent расположен в папке Management сервера. Вызвав его контекстное меню, вы можете управлять работой этой службы. Дополнительные службы, такие как MSDTC и SQLMail, располагаются в папке Support Services. Управление их работой осуществляется аналогично.

О Наиболее простой способ ручного запуска заключается в использовании административной утилиты SQL Server Service Manager (см. рис. 10.4), специально предназначенной для запуска, остановки и приостановки служб SQL Server. В окне утилиты вам предлагается выбрать сервер и службу, с которыми вы будете работать. Значки отображают действия, доступные в настоящий момент для выбранной службы.

О Следующий способ запуска SQL Server предполагает использование утилиты командной строки net start. В качестве параметра необходимо указать имя службы, которую необходимо запустить, например: net start mssqlserver net start sqlserver-agent

Для запуска служб именованной копии необходимо добавить ее имя и знак доллара перед ним. Например, для запуска службы MSSQLServer копии TRELON используется следующая команда: net start MSSQLSTRELON

Для запуска службы SQLAgent требуется следующая команда: net start SQLAgentSTRELON

Выполнение команды net start без имени службы приведет к выводу списка запущенных в операционной системе служб.

О Для запуска SQL Server можно также использовать команду sqlservr. В этом случае SQL Server 2000 запускается не как служба, а как отдельное приложение.
Это означает, что все средства администрирования (Service Manager, Enterprise Manager, Services в панели управления) будут показывать, что сервер остановлен.
Использование команды net stop mssql server для остановки SQL Server в этом случае выдаст сообщение об ошибке, так как система считает, что сервер не запущен. Все системные сообщения будут появляться в консольном окне, в котором выполнена команда sqlservr. Сервер будет запускаться под учетной записью пользователя, работающего в системе в данный момент, и если этот пользователь решит завершить сеанс работы в операционной системе, ему придется сначала завершить работу SQL Server.

Запуск
SQL Server в однопользовательском режиме

При некоторых обстоятельствах бывает необходимо запустить SQL Server в однопользовательском режиме —
например, чтобы выполнить конфигурирование важных характеристик сервера или восстановить поврежденную системную базу данных.

В однопользовательском режиме служба MSSQLServer поддерживает только одно соединение. Так как дополнительные службы SQL Server 2000, подобно обычным пользователям, устанавливают клиентские соединения, то необходимо убедиться, что эти службы, например SQLServerAgent или SQLMail, не запущены. В противном случае вы сами не сможете получить доступ к серверу,

поскольку единственное возможное соединение будет уже задействовано. Убедитесь, что клиентские приложения, обращающиеся к SQL Server (такие как Internet Information Server), также остановлены.

При однопользовательском режиме «грязные» страницы (dirty pages) немедленно
записываются на диск. Это означает, что данные, которые были изменены после считывания, сразу окажутся на диске, а не в кэш-памяти, как это бывает при обычной работе.

Другой особенностью работы в однопользовательском режиме является то, что разрешен прямой доступ к системным таблицам, по умолчанию запрещенный при обычной работе. Прямой доступ к системным таблицам позволяет модифицировать системные данные (структуру таблиц, пользователей, настройки репликации и т.д.) непосредственно командами INSERT, DELETE и UPDATE. В обычных условиях подобная модификация производится с использованием хранимых процедур и административных утилит.

Прямой доступ к системной информации требует очень высокой квалификации и специальных знаний. Большинству пользователей и системных администраторов будет достаточно средств, предоставляемых интерфейсом SQL Server.

Для запуска SQL Server 2000 в однопользовательском режиме введите следующую команду.

sqlservr.exe -т

Запуск
SQL Server с минимальными требованиями

В некоторых случаях, например после применения неправильных параметров конфигурации, SQL Server при следующем запуске не сможет стартовать, в результате чего вы не сможете отменить сделанные изменения. В этом случае необходимо запустить SQL Server с минимальными требованиями.
Это своего рода аварийный запуск
SQL Server. В таком режиме количество открытых баз данных, таблиц, открытых объектов, размер кэша процедур и т. д. минимально. Запрещается выполнение хранимых процедур, автоматически запускаемых при каждом старте SQL Server. Автоматически устанавливается однопользовательский режим и прямой доступ к системным таблицам. Удаленный доступ запрещается, то есть предоставляется возможность работать с сервером только локально.

Для запуска SQL Server 2000 как службы с минимальными требованиями
введите следующую команду: sqlservr.exe -f

Если необходимо незамедлительно запустить SQL Server 2000 с минимальными требованиями как приложение,
выполните следующую команду: sqlservr.exe -f -с

Перед запуском SQL Server с минимальными требованиями убедитесь, что сервер остановлен и никакие дополнительные службы или приложения, которые могут блокировать единственное соединение, не запущены.

Дополнительные режимы запуска

После установки SQL Server программа установки заносит в реестр набор базовых параметров запуска для SQL Server. Если вы не хотите использовать параметры по умолчанию, то для запуска SQL Server в нестандартной конфигурации можете воспользоваться ключами, перечисленными в табл.

Таблица.
Дополнительные ключи sqlservr.exe

Ключ

Описание

-d < master_file_path >

-е< error_log_path >

-I < masterjog_path >

Используйте этот ключ для запуска SQL Server с другой системной базой данных master. Укажите полный путь к этой базе данных, обычно это

Program filesMicrosoft SQL ServerMSSQLDataMaster.mdf Если этот ключ не указан, используются значения из реестра

Позволяет использовать дополнительный журнал ошибок. Укажите полный путь к файлу журнала, обычно это Program filesMicrosoft SQL ServerMSSQLLogErrorlog

Используйте этот ключ для подключения указанного журнала транзакций для системной базы данных master. Укажите полный путь к файлу журнала, обычно это Program filesMicrosoft SQL ServerMS5QLDataMastlog
.
Idf

Ключ реестра, создаваемый программой установки и содержащий параметры запуска SQL Server 2000 по умолчанию, находится в реестре .

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

Вы можете создать свою собственную конфигурацию, сохранив все необходимые параметры запуска сервера в реестре. Создайте копию стандартных ключей (SQLArgO, SQLArgl или SQLArg2), изменив имя, например, на SingleUser. Затем отредактируйте строку данных для указания нужных параметров.

Чтобы запустить SQL Server с новым ключом реестра, введите следующую команду: Sqlservr.exe -sSingleUser

Здесь SingleUser — имя конфигурации.

Приостановка
SQL Server

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

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

При желании вы можете после приостановки возобновить работу сервера в нормальном режиме.

Чтобы приостановить работу SQL Server, необходимо воспользоваться теми же средствами, что и для запуска, но вместо команды Start (пуск) выбирать команду Pause (пауза). Если необходимо остановить сервер из командной строки, то нужно ввести следующую команду:

net pause mssqlserver

Для продолжения работы приостановленного SQL Server введите команду

net continue mssql server

Соответственно для именованных копий эти команды будут выглядеть следующим образом:

net pause mssqlSinstancename net continue mssql$instancename

Вы не можете приостановить работу сервера, если он запущен командой sqlservr.exe, так как в этом случае сервер работает как самостоятельное приложение, а не как служба операционной системы.

Остановка
SQL Server

Вы можете остановить сервер SQL Server 2000, если он запущен как служба, как локально (на том же сервере, на котором он запущен), так и удаленно (с клиентского компьютера или другого сервера SQL Server), используя один из следующих методов.

О SQL Server Enterprise Manager останавливает локальный или удаленный сервер SQL Server либо службу SQLServerAgent.

О SQL Server Service Manager останавливает локальный или удаленный сервер SQL Server либо службу SQLServerAgent из одного окна (в одном окне можно управлять работой всех служб).

О Команда SHUTDOWN языка Transact-SQL применяется для остановки SQL Server из клиентского приложения при выполнении запросов, например из утилиты osql или Query Analyzer. Используйте команду SHUTDOWN с параметром WITH NOWAIT для незамедлительной остановки сервера.

О Команда net stop mssql server (net stop mssql Sinstancename - для именованных копий) останавливает локальный или удаленный SQL Server, если вы работаете в Windows NT.

О Утилита Services (службы) окна Control Panel (панель управления) останавливает локальный сервер SQL Server.

О Комбинация клавиш CTRL+C останавливает сервер SQL Server, если он запущен из командной строки командой sqlservr.exe.

При завершении работы все данные из кэша сохраняются на диск, кроме случая, когда остановка сервера производится с помощью комбинации клавиш CTRL+C. В этом случае сохранения данных не происходит, в результате время последующего запуска сервера увеличивается, так как необходимо выполнить фиксацию законченных и откат незавершенных транзакций.

SQL Server 2000 ожидает завершения всех активных команд Transact-SQL и хранимых процедур, и только после их завершения происходит остановка сервера. Однако если вы останавливаете сервер командой SHUTDOWN WITH NOWAIT, остановка происходит незамедлительно вне зависимости от того, все ли активные операции завершены.

Перед остановкой SQL Server 2000 всегда осуществляйте приостановку соответствующих служб и рассылку предупреждающего сообщения. Это позволит пользователям корректно завершить свою работу и в то же время предотвратит новые соединения.

Правила Безопасности

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

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

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

В современных условиях, когда информация имеет огромное значение, принятие мер для предотвращения несанкционированного доступа, предупреждения потери или повреждения информации становятся неотъемлемой частью работы любой компании. По данным статистики, в США 80 % компаний, потерявших информацию, прекращали свою деятельность в течение года. Среди оставшихся 20 % около половины просуществовало не более 4 лет.

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

Система управления базами данных Microsoft SQL Server 2000 имеет разнообразные средства обеспечения защиты данных. Эта глава посвящена детальному знакомству с системой безопасности SQL Server 2000.

Общие правила разграничения доступа

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

После проектирования логической структуры базы данных, связей между таблицами, ограничений целостности и других структур необходимо определить круг пользователей, которые будут иметь доступ к базе данных. Чтобы разрешить этим пользователям обращаться к серверу, создайте для них учетные записи в SQL Server либо предоставьте им доступ посредством учетных записей в домене, если вы используете систему безопасности Windows NT. Разрешение доступа к серверу
не дает автоматически доступа к базе данных и ее объектам.

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

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

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

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

При создании паролей следуйте стандартным рекомендациям. Желательно, чтобы пароль включал в себя не только символы, но и цифры. Следите, чтобы пользователи не применяли в качестве пароля год рождения, номер паспорта, машины или другие часто используемые данные. Установите ограниченный срок действия пароля, по истечении которого система потребует у пользователя сменить пароль. Для достижения максимальной степени безопасности используйте аутентификацию пользователей средствами Windows NT, поскольку операционные системы этого семейства предоставляют множество очень полезных средств защиты.

Архитектура системы безопасности
SQL Server 2000

Система безопасности SQL Server 2000 базируется на пользователях
и учетных записях.
Пользователи проходят следующие два этапа проверки системой безопасности. На первом этапе пользователь идентифицируется по имени учетной записи и паролю, то есть проходит аутентификацию. Если данные введены правильно, пользователь подключается к SQL Server. Подключение к SQL Server, или регистрация,
не дает автоматического доступа к базам данных. Для каждой базы данных сервера регистрационное имя
(или учетная запись — login) должно отображаться в имя пользователя базы данных
(user). На втором этапе, на основе прав, выданных пользователю как пользователю базы данных (user), его регистрационное имя (login) получает доступ к соответствующей базе данных. В разных базах данных login
одного и того же пользователя может иметь одинаковые или разные имена user
с разными правами доступа.

Для доступа приложений
к базам данных им также понадобятся права. Чаще всего приложениям выдаются те же права, которые предоставлены пользователям, запускающим эти приложения. Однако для работы некоторых приложений необходимо иметь фиксированный набор прав доступа, не зависящих от прав доступа пользователя. SQL Server 2000 позволяет предоставить такие с применением специальных ролей приложения.

Итак, на уровне сервера система безопасности оперирует следующими понятиями:

О аутентификация (authentication);

О учетная запись (login);

О встроенные роли сервера (fixed server roles).

На уровне базы данных используются следующие понятия: О пользователь базы данных (database user); О фиксированная роль базы данных (fixed database role); О пользовательская роль базы данных (users database role); О роль приложения (application role).

Режимы аутентификации

SQL Server 2000 может использовать два режима аутентификации пользователей: О режим аутентификации средствами Windows NT/2000 (Windows NT Authentication);

О смешанный режим аутентификации (Windows NT Authentication and SQL

Server Authentication).

Смешанный режим позволяет пользователям регистрироваться как средствами Windows NT, так и средствами SQL Server. Кроме того, этот режим предлагает некоторые удобства по сравнению с первым. В частности, при аутентификации только средствами домена Windows NT, если пользователь не имеет учетной записи в домене Windows NT, то он не сможет получить доступа к серверу баз данных. Смешанный режим аутентификации позволяет избежать этой проблемы.

При выборе режима аутентификации следует исходить как из требований обеспечения наибольшей безопасности, так и из соображений простоты администрирования. Если ваша организация небольшая и должности администратора сети и администратора баз данных совмещает один человек, то удобнее использовать аутентификацию Windows NT. Если же в организации сотни пользователей и функции системного администратора и администратора баз данных выполняют различные люди, то может оказаться, что аутентификация средствами SQL Server удобнее. В противном случае человеку, занимающемуся администрированием сервера баз данных, придется постоянно обращаться к системному администратору для создания нового пользователя, смены пароля или для перевода пользователя из одной группы в другую. К тому же системный администратор будет иметь возможность назначать права доступа по своему усмотрению, а это совсем ни к чему.

С другой стороны, каждый пользователь организации, скорее всего, имеет в домене учетную запись, администрированием которой занимается системный администратор. Благодаря аутентификации Windows NT администратор баз данных может использовать уже готовые учетные записи, а не отвлекаться на создание новых.

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

Режим аутентификации
SQL Server

Для установки соединения с сервером SQL Server 2000, находящемся в домене, с которым не установлены доверительные отношения, можно использовать аутентификацию SQL Server. Аутентификация SQL Server также используется, когда вообще нет возможности зарегистрироваться в домене. Например, при подключении к SQL Server 2000 по Интернету.

При работе с аутентификацией SQL Server доступ также предоставляется на основе учетных записей. Но в этом случае используются учетные записи SQL Server, а не Windows NT.

Для аутентификации средствами SQL Server Server член стандартной роли сервера sysadmin или securityadmin должен создать и сконфигурировать для пользователя учетную запись, в которую входит имя учетной записи, уникальный идентификатор SQL Server и пароль. Вся эта информация будет храниться в системной базе master. Создаваемая учетная запись не имеет отношения к учетным записям Windows NT.

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

Аутентификация SQL Server может применяться в следующих случаях: О для пользователей Novell NetWare, Unix и т. д.;

О при подключении к SQL Server 2000 через Интернет, когда регистрация в домене не выполняется;

О под управлением операционной системы Windows 98.

Учтите, что в этом случае администратор SQL Server 2000 сам должен периодически предупреждать пользователей о необходимости сменить пароль, чтобы обезопасить систему от несанкционированного доступа, поскольку в отличие от Windows NT, в SQL Server отсутствуют подобные средства системы безопасности.

В большинстве случаев учетная запись в SQL Server создается с целью предоставления доступа. Но бывают ситуации, когда необходимо запретить
доступ пользователю или группе. Например, при наличии сложной системь! безопасности Windows NT доступ обычно предоставляется группе
пользователей. Однако если в группе имеется человек, которому нельзя
разрешать доступ к SQL Server, его необходимо убрать из этой группы. Но такой подход неудовлетворителен, если группа предназначена не только для объединения пользователей, имеющих доступ к SQL Server, но имеет еще и какие-то дополнительные функции. SQL Server разрешает создать учетную запись с целью запрещения
доступа. Это гарантирует, что пользователь никаким образом не сможет установить соединение с сервером. Создав группу Windows NT и запретив
ей доступ к SQL Server, вы можете включать в нее пользователей, которым необходимо отказать в доступе.

После установки SQL Server создаются две стандартные учетные записи: BUILTINXAdministrators и sa.

О BUILT INNAdministrators — это учетная запись Windows NT, обеспечивающая автоматический доступ всем членам группы Administrators к SQL Server. Учетная запись BUILTINNAdministrators по умолчанию является членом встроенной роли сервера sysadmin. Таким образом, системные администраторы получают полный доступ ко всем базам данных. В ситуации, когда функции системного администратора и администратора баз данных выполняют разные люди, скорее всего, следует исключить эту учетную запись из роли sysadmin, а возможно, и вообще удалить.

О s a — это специальная учетная запись SQL Server для администратора. По умолчанию она присвоена встроенной системной роли сервера sysadmin и не может быть изменена. Эта учетная запись сохранена в этой версии SQL Server для сохранения совместимости с приложениями, написанными для предыдущих версий. Хотя s а и имеет административные права, ее не рекомендуется использовать в SQL Server 2000. Вместо этого следует создать новых пользователей и включить их в административную группу sysadmin. Учетную запись s а оставьте на крайний случай, когда учетные записи администраторов окажутся недоступными либо вы забудете пароль.

В процессе установки SQL Server 2000 мастер установки предлагает ввести пароль для учетной записи sa, но он также может быть оставлен и пустым. В этом случае следует обязательно установить новый пароль сразу же после установки. В предыдущих версиях не было возможности устанавливать пароль учетной записи sa во время установки сервера, и этот пароль всегда был пустым.

Компоненты структуры безопасности

Фундаментом системы безопасности SQL Server 2000 являются учетные записи
(login), пользователи
(user), роли
(role) и группы
(group). t

Пользователь, подключающийся к SQL Server, должен идентифицировать себя, используя учетную запись.
После того как клиент успешно прошел аутентификацию, он получает доступ к SQL Server. Для получения доступа к любой базе дан
ных учетная запись пользователя
(login) отображается в пользователя данной базы
данных
(user). Объект «пользователь базы данных» применяется для предоставления доступа ко всем объектам базы данных: таблицам, представлениям, хранимым процедурам и т. д. В пользователя базы данных может отображаться:

О учетная запись Windows NT;

О группа Windows NT;

О учетная запись SQL Server.

Подобное отображение учетной записи необходимо для каждой базы данных, доступ к которой хочет получить пользователь. Отображения сохраняются в системной таблице sysusers, которая имеется в любой базе данных. Такой подход обеспечивает высокую степень безопасности, предохраняя от предоставления пользователям, получившим доступ к SQL Server, автоматического доступа ко всем базам данных и их объектам. Пользователи баз данных,
в свою очередь, могут объединяться в группы
и роли
для упрощения управлением системой безопасности.

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

Если в сети имеется небольшое количество пользователей, то достаточно легко предоставить доступ каждому пользователю персонально. Однако в больших сетях с сотнями пользователей подобный подход займет много времени. Гораздо более удобным и эффективным является подход, когда доступ к SQL Server 2000 предоставляется целым группам пользователей. Как раз такой подход возможен при аутентификации средствами Windows NT/2000, когда на уровне домена создается несколько групп, каждая из которых пред

назначена для решения специфических задач. На уровне SQL Server 2000 такой группе разрешается доступ к серверу, предоставляются необходимые права доступа к базам данных и их объектам. Достаточно включить учетную запись Windows NT в одну из групп, и пользователь получит все права доступа, предоставленные этой группе. Более того, одна и та же учетная запись может быть включена во множество групп Windows NT, что даст этой учетной записи возможность пользоваться правами доступа, предоставленными всем этим группам. Администратор SQL Server 2000 должен сам решить, как удобнее предоставлять доступ к серверу: персонально каждой учетной записи или группе в целом.

Пользователи

После того как пользователь прошел аутентификацию и получил идентификатор учетной записи
(login ID), он считается зарегистрированным и ему предоставляется доступ к серверу. Для каждой базы данных, к объектам которой пользователю необходимо получить доступ, учетная запись пользователя
(login) ассоциируется с пользователем
(user) конкретной базы данных. Пользователи
выступают в качестве специальных объектов
SQL Server, при помощи которых определяются все разрешения доступа и владения объектами в базе данных.

Имя пользователя
может использоваться для предоставления доступа как конкретному человеку, так и целой группе людей (в зависимости от типа учетной записи).

При создании базы данных определяются два стандартных пользователя: d b о и guest.

Если учетная запись (login) не связывается явно с пользователем (user), последнему предоставляется неявный
доступ с использованием гостевого имени guest. То есть все учетные записи, получившие доступ к SQL Server 2000, автоматически отображаются в пользователей guest во всех базах данных. Если вы удалите из базы данных пользователя guest, то учетные записи, не имеющие явного отображения учетной записи в имя пользователя, не смогут получить доступа к базе данных. Тем не менее, guest не имеет автоматического доступа к объектам. Владелец объекта должен сам решать, разрешать пользователю guest этот доступ или нет. Обычно пользователю guest предоставляется минимальный доступ в режиме «только чтение».

Для обеспечения максимальной безопасности можно удалить пользователя guest из любой базы данных, кроме системных баз данных master и Tempdb. В первой из них guest используется для выполнения системных хранимых процедур обычными пользователями, тогда как во второй позволяет создавать любым пользователям временные объекты.

Владелец
базы данных (DataBase Owner, DBO) — специальный пользователь, обладающий максимальными правами в базе данных. Любой член роли sysadmin автоматически отображается в пользователя dbo. Если пользователь, являющийся членом роли sys admin, создает какой-нибудь объект, то владельцем этого объекта назначается не данный пользователь, a dbo. Например, если Liliya, член административной группы, создает таблицу ТаЫ еА, то полное имя таблицы будет не Lil iya .ТаЫеА, a dbo.ТаЫ еА. В то же время, если Liliya, не будучи участником роли сервера sysadmin, состоит в роли владельца базы данных db_owner, то имя таблицы будет Li I i уа. ТаЫ еА.

Пользователя dbo нельзя удалить.

Для связывания учетной записи (login) с определенным именем пользователя (user) можно воспользоваться следующей хранимой процедурой:

sp_adduser [@loginame =] 'login' [,[@name_in_db =] 'user'] [.[@grpname =] 'role']

Ниже дается пояснение используемых в ней параметров:

О login— имя учетной записи,
которую необходимо связать с именем пользователя базы данных;

О user — имя пользователя базы данных,
с которым ассоциируется данная учетная запись (в базе данных заранее не должно существовать пользователя с указанным именем);

О role — этот параметр определяет роль,
в которую данный пользователь будет включен (подробнее о ролях будет рассказано позже). Хранимая процедура sp_grantdbaccess позволяет отобразить учетную запись Windows NT в имя пользователя:

sp_grantdbaccess [@loginame =] 'login' [,[@name_in_db =] 'user']

Параметры означают следующее:

О login— имя учетной записи
пользователя или группы пользователей Windows NT, которым необходимо предоставить доступ к базе данных. Имя должно снабжаться ссылкой на домен, в котором учетная запись определена. Указанной учетной записи не обязательно должен быть предоставлен персональный доступ к SQL Server. Вполне возможно, что соединение с сервером устанавливается вследствие членства в группе Windows NT, которая имеет доступ к серверу;

О user — имя пользователя базы данных, с
которым ассоциируется данная учетная запись.

Пользователь, который создает объект в базе данных, например таблицу, хранимую процедуру или представление, становится владельцем
объекта. Владелец объекта (database object owner) имеет все права доступа к созданному им объекту. Чтобы пользователь мог создать объект, владелец базы данных (dbo) должен предоставить пользователю соответствующие права.
Полное имя создаваемого объекта включает в себя имя создавшего его пользователя. Если пользователь хочет обратиться к таблице, используя только ее имя и не указывая владельца, SQL Server применяет следующий алгоритм поиска.

1. Ищется таблица, созданная пользователем,
выполняющим запрос.

2. Если таблица не найдена, то ищется таблица, созданная владельцем
базы данных (dbo).

Допустим, пользователь Liss пытается обратиться к таблице Lil iya .TableA, просто используя имя Tab! еА. Поскольку таблица, созданная Li I iya, не соответствует ни первому, ни второму критерию поиска, то таблица ТаЫеА найдена не будет и пользователь получит сообщение об ошибке. Для получения доступа к таблице необходимо ввести имя, включающее владельца объекта, то есть Liliya.TableA.

Владелец объекта не имеет никакого специального пароля или особых прав доступа. Он неявно
имеет полный доступ, но должен явно
предоставить доступ другим пользователям.

SQL Server позволяет передавать права владения от одного пользователя другому. Чтобы удалить владельца объекта из базы данных, сначала необходимо удалить все объекты, которые он создал, или передать права на их владение другому пользователю. Для этого можно использовать хранимую процедуру sp_changeobjectowner, имеющую следующий синтаксис:

sp_changeobjectowner [ @objname = ] 'object' , [ (Pnewowner = ] 'owner'

Здесь с помощью первого параметра указывается имя объекта, а с помощью второго — имя пользователя, который станет новым владельцем указанного объекта.

Роли сервера

Роль —
это мощный инструмент, добавленный в SQL Server 7.0, чтобы заменить группы,
которые использовались в предыдущих версиях. Роль позволяет объединять пользователей, выполняющих одинаковые функции, для упрощения администрирования системы безопасности SQL Server.

В SQL Server реализовано два вида стандартных ролей: на уровне сервера
и на уровне баз данных.
При установке SQL Server 2000 создается 9 фиксированных ролей сервера и 9 фиксированных ролей базы данных. Эти роли вы не сможете удалить, кроме того, нельзя модифицировать права их доступа. Вы не сможете предоставить пользователю права, которые имеют фиксированные роли сервера, другим способом, кроме как включением его в нужную роль.

В предыдущих версиях SQL Server для администрирования сервера можно было использовать только учетную запись sa или ее аналог. Иначе говоря, вы могли дать либо все
права, либо никаких.
Теперь в SQL Server эта проблема решена путем добавления ролей сервера (server role), которые позволяют предоставить операторам сервера только те права, которые администратор посчитает возможным предоставить. Роли сервера не имеют отношения к администрированию баз данных. Можно включить любую учетную запись SQL Server (login) или учетную запись Windows NT в любую роль сервера.

Стандартные роли сервера (fixed server role) и их права приведены в табл.

Таблица.
Фиксированные роли сервера

Встроенная Назначение

роль сервера

______________________________________________

Sysadmin Может выполнять любые действия в SQL Server Serveradmin Выполняет конфигурирование и выключение сервера

Setupadmin Управляет связанными серверами и процедурами, автоматически запускающимися при старте SQL Server

Securityadmin Управляет учетными записями и правами на создание базы данных, также может читать журнал ошибок

Processadmin Управляет процессами, запущенными в SQL Server

Dbcreator Может создавать и модифицировать базы данных

Diskadmin Управляет файлами SQL Server

Bulkadmin Эта роль не существовала в SQL Server 7.0. Члены роли Bulkadmin могут

(Bulk Insert вставлять данные с использованием средств массивного копирования,

administrators)
не имея непосредственного доступа к таблицам
____________________

Роли баз данных

Роли базы данных
(database role) позволяют объединять пользователей в одну административную единицу и работать с ней как с обычным пользователем. Можно назначить права доступа к объектам базы данных для конкретной роли, при этом вы автоматически наделяете всех членов этой роли одинаковыми правами. Вместо того чтобы предоставлять доступ каждому конкретному пользователю, а впоследствии постоянно следить за изменениями, можно просто включить пользователя в нужную роль. Если сотрудник переходит в другой отдел, нужно просто удалить его из одной роли и добавить в другую. Создайте необходимое количество ролей, которые охватывали бы все многообразие действий с базой данных. Позже, при изменении функций членов одной из ролей, достаточно изменить права доступа для этой роли,
а не устанавливать новые права для каждого пользователя.

В роль базы данных можно включать: О пользователей SQL Server; О роли SQL Server

О пользователей Windows NT; '

О группы Windows NT, которым предварительно предоставлен доступ к нужной базе данных.

Средства Enterprise Manager позволяют добавлять в роль базы данных только пользователей базы данных (user). Используйте хранимую процедуру sp_addrolemember, чтобы задействовать все возможности SQL Server 2000:

sp_addrolemember [@ro1ename =] 'role', [@membername =] 'security_account'

Здесь параметры означают следующее: О role— название роли SQL Server в текущей базе данных;

О security_account — имя того объекта системы безопасности, который необходимо включить в роль. В качестве такого объекта могут выступать как учетные записи SQL Server, так и пользователи и группы Windows NT, которым предоставлен доступ к серверу баз данных.

При создании базы данных для нее определяются стандартные роли базы
данных,
которые, так же как и стандартные роли сервера, не могут быть изменены или удалены. Стандартные роли баз данных (fixed database role) и их права приведены в табл.

Таблица.
Фиксированные роли баз данных

Встроенная роль Назначение

баз данных

_______________________________________________

db__owner Имеет все права в базе данных db_accessadmin Может добавлять или удалять пользователей

db_securityadmin Управляет всеми разрешениями, объектами, ролями и

членами ролей

db_ddladmin Может выполнять любые команды DDL, кроме GRANT, DENY

и REVOKE

db_backupoperator Может выполнять команды DBCC, CHECKPOINT и BACKUP db_datareader Может просматривать любые данные в любой таблице БД db_datawriter Может модифицировать любые данные в любой таблице БД db_denydatareader Запрещается просматривать данные в любой таблице dbjjenydatawriter
_________Запрещается модифицировать данные в любой таблице
_____

Кроме указанных выше ролей существует еще одна — public. Эта роль имеет специальное назначение, поскольку ее членами являются все пользователи, имеющие доступ к базе данных. Нельзя явно
установить членов этой роли, потому что все пользователи и так автоматически являются ее членами. Используйте эту роль для предоставления минимального доступа пользователям, для которых права доступа к объектам не определены явно. Если в базе данных разрешен пользователь guest, то установленный для publ i с доступ будут иметь все пользователи, получившие доступ к SQL Server. Роль public имеется во всех базах данных, включая системные базы данных master, tempdb, msdb, model, И не может быть удалена.

Группы Windows NT могут быть использованы аналогично ролям SQL Server. Можно создать одну учетную запись (login) для группы Windows NT и включать соответствующих пользователей вместо роли в группу Windows NT. Выбор метода администрирования зависит от вас.

Роли приложения

Система безопасности SQL Server реализована на самом низком уровне — уровне базы данных. Это наилучший, наиболее действенный метод контроля деятельности пользователей независимо от приложений, используемых ими для подключения к SQL Server. Тем не менее встречаются ситуации, когда необходим постоянный набор прав для доступа к базе данных из приложения. Особенно это касается работы с большими базами данных, имеющими множество сложных взаимосвязанных таблиц с тысячами или миллионами записей. Чаще всего для работы с такими базами данных создаются специальные приложения.

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

SQL Server решает перечисленные проблемы путем использования роли при
ложения,
создаваемой на уровне базы данных. Отличия между стандартными ролями и ролью приложения фундаментальны. Роль приложения не имеет чле
нов.
Пользователи SQL Server или Windows NT не могут быть добавлены в эту роль. Роль активизируется, когда приложение устанавливает соединение. Пользователь, работающий в это время с приложением, не является членом роли — только его приложение использует установленное соединение.

Перед использованием роли приложения необходимо сначала создать ее. При создании роли укажите ее имя и пароль для доступа. Создание роли средствами Transact-SQL выполняется с помощью следующей системной хранимой процедуры:

sp_addappro1e [ @rolename = ] 'role' . [ (^password = ] 'password'

Первый параметр определяет имя, которое будет иметь создаваемая роль приложения, второй — пароль, который будет использоваться для активизации роли.

Создание роли приложения средствами Enterprise Manager выполняется с помощью окна Database Role Properties — New Role (свойства ролей баз данных — новая роль), которое также используется для создания обычных пользовательских ролей. Чтобы создаваемая роль являлась ролью приложения, достаточно установить переключатель Application role (роль приложения) и ввести пароль. Работа с указанным окном будет рассмотрена в одном из следующих разделов этой главы.

Приложение может быть спроектировано так, чтобы пользователь, работающий с ним, должен был вводить пароль для активизации роли приложения. Однако чаще всего пароль вводится самим приложением незаметно для пользователя. Дополнительно, для обеспечения максимальной безопасности, пароль может быть зашифрован перед своей отправкой к SQL Server по сети.

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

sp_setapprole [(ЭгоТепате =] 'role', [^password =] (Encrypt N 'password'} | 'password' [.[^encrypt =] 'encrypt_style']

Рассмотрим параметры подробнее: О role— имя роли приложения, которое определено в базе данных;

О password— пароль, который приложение должно передать серверу для активизации роли приложения;

О encrypt_styl e — применяемая схема шифрования паролей. Данный параметр может иметь два значения: попе (шифрование не применяется) и odbc (шифрование с применением функции ODBC encrypt).

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

Поскольку роль приложения имеет права только в той базе данных, в которой она создана, а все разрешения для учетных записей, групп и ролей, к которым принадлежит пользователь, теряются, то доступ к другим базам данных возможен только под гостевым именем guest. Следовательно, если имя guest в базе данных не существует, то соединение не сможет получить доступ к данным. Если же имя guest не удалено из базы данных, соединение сможет получить доступ к объектам базы только в том случае, если разрешения явно
выданы для пользователя guest. Перед установлением соединения с использованием роли приложения пользователю сначала нужно получить доступ к SQL Server. Для этого допустимы оба режима аутентификации пользователей.

Если приложение спроектировано для выполнения различных задач с использованием разных прав доступа, необходимо создать отдельную роль для каждой выполняемой задачи. Приложение должно само позаботиться о переключении ролей.

Защита данных

Как бы хорошо ни была спланирована система безопасности SQL Server 2000, остается возможность копирования файлов с данными и просмотра их на другом компьютере. Кроме того, с использованием специальных устройств данные могут быть перехвачены при передаче их по сети. Необходимо продумать средства физи
ческой
защиты данных. Учтите, что данные в файлах базы данных хранятся в открытой форме, то есть их можно просмотреть в текстовом редакторе. Конечно, они не будут структурированы, но все же часть информации можно будет прочитать.

Шифрование данных

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

• любые данные, передаваемые между сервером и клиентом по сети;

• пароли учетных записей SQL Server или ролей приложения;

• код, использованный для создания объектов базы данных (хранимых процедур,

представлений, триггеров и т. д.).

Пароли учетных записей и ролей приложения всегда
сохраняются в системных таблицах SQL Server в зашифрованной форме. Это предохраняет их от просмотра любым пользователем, включая администратора. Кроме того, пароль роли приложения может быть зашифрован перед отправкой его на сервер.

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

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

Если вы хотите шифровать данные при передаче их по сети, необходимо использовать сетевую библиотеку Multiprotocol Net-Library.

Ограничение доступа к файлам
SQL Server

В своей работе SQL Server создает и использует множество файлов — базы данных, журналы ошибок, резервные копии, файлы для экспорта и импорта данных и многое другое. Службы SQL Server на уровне операционной системы выполняются в виде процессов. Для нормальной работы SQL Server необходимо, чтобы эти процессы имели полный доступ ко всем указанным выше файлам на уровне файловой системы. Для этого на уровне операционной системы требуется предоставить соответствующие права учетным записям, которые используются для запуска SQL Server. Лучше всего управлять правами доступа непосредственно на

уровне файлов и папок. Для этого сервер должен работать под управлением операционной системы Windows NT и иметь файловую систему NTFS.

Если сервер стартует как служба, необходимо предоставить полные права доступа учетным записям, используемым для запуска служб. Если же старт SQL Server выполняется из командной строки или на компьютере под управлением Windows 98, то сервер будет иметь права доступа учетной записи пользователя, выполнившего запуск. Если для запуска сервера используется учетная запись локальной системы, то доступ должен предоставляться пользователю SYSTEM.

С целью ограничения возможностей неавторизированного доступа для файлов SQL Server необходимо установить запрет на чтение, удаление, модификацию и исполнение всем пользователям, кроме непосредственно SQL Server.

Права доступа

Когда пользователи подключаются к SQL Server, действия, которые они могут выполнять, определяются правами (разрешениями), выданными их учетной записи, группе или роли, в которой они состоят.

Права в SQL Server можно разделить на три категории: О права на доступ к объектам баз данных; О права на выполнения команд Transact-SQL; О неявные права (разрешения).

После создания пользователь не имеет никаких прав доступа, кроме тех, которые разрешены для специальной роли базы данных public. Права, предоставленные этой роли, доступны для всех
пользователей в базе данных.

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

Важно быть осторожным с предоставлением разрешений на доступ к данным. Необходимо внимательно контролировать права доступа, выдаваемые пользователю как непосредственно, так и через членство в группах Windows NT и ролях SQL Server. Особенно это касается больших систем безопасности с тысячами пользователей и десятками групп. Вы должны быть уверены, что существующая система безопасности дает возможность пользователю выполнять любые необходимые действия, но ограничивает доступ к информации, которая не требуется ему для выполнения своих обязанностей.

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

Аналогичные рекомендации касаются разрешений на выполнение команд Transact-SQL. Можно спроектировать базу данных таким образом, что выполнять конкретные действия — создание таблиц, представлений, правил, резервных копий и т. д. — будут строго определенные пользователи.

Права на доступ к объектам баз данных

Работа с данными и выполнение хранимых процедур требуют наличия класса доступа, называемого правами на доступ к объектам баз данных.
Под объектами подразумеваются таблицы, столбцы таблиц, представления, хранимые процедуры. Права на доступ к объектам баз данных контролируют возможность выполнения пользователями, например, команд SELECT, INSERT, UPDATE и DELETE для таблиц и представлений. Таким образом, если пользователю необходимо добавить новые данные в таблицу, ему следует предоставить право INSERT (вставка записей в таблицу). Предоставление же пользователю права EXECUTE разрешает ему выполнение каких-либо хранимых процедур.

Для различных объектов применяются разные наборы прав доступа к ним: О SELECT, INSERT, UPDATE, DELETE, REFERENCES- эти права могут быть применены для таблицы или представления;

О SELECT и UPDATE — эти права могут быть применены к конкретному столбцу
таблицы
или представления;

О EXECUTE— это право применяется только к хранимым процедурам
и функ
циям.
Ниже приводится более подробное описание каждого из этих прав.

О INSERT. Это право позволяет вставлять в таблицу или представление новые строки. Как следствие, право INSERT может быть выдано только на уровне таблицы или представления и не может быть выдано на уровне столбца.

О UPDATE. Это право выдается либо на уровне таблицы, что позволяет изменять все данные в таблице, либо на уровне отдельного столбца, что разрешает изменять данные только в пределах конкретного столбца.

О DELETE. Это право позволяет удалять строки из таблицы или представления. Как и право INSERT, право DELETE может быть выдано только на уровне таблицы или представления и не может быть выдано на уровне столбца.

О SELECT. Разрешает выборку данных. Может выдаваться как на уровне таблицы, так и на уровне отдельного столбца.

О REFERENCES. Возможность ссылаться на указанный объект. Применительно к таблицам разрешает пользователю создавать внешние ключи, ссылающиеся на первичный ключ или уникальный столбец этой таблицы. Применительно к представлениям право REFERENCES позволяет связывать представление со схемами таблиц, на основе которых строится представление. Это позволяет отслеживать изменения структуры исходных таблиц, которые могут повлиять на работу представления. Право REFERENCES не существовало в предыдущих версиях SQL Server.

Как следует из вышеизложенного, доступ можно предоставлять как на уровне всей таблицы или представления, так и на уровне отдельного столбца. Обычно не практикуется управление правами доступа на уровне конкретного столбца. Если в таблице имеется один или более столбцов, доступ пользователей к которым необходимо ограничить, то в базе данных часто создается представление
(view), включающее только те столбцы исходной таблицы, доступ к которым разрешен.

Предоставить или отклонить доступ пользователю базы данных ко всем объектам базы данных можно при помощи встроенных ролей базы данных. Например, для разрешения чтения данных из всех таблиц и представлений базы данных достаточно включить пользователя в фиксированную роль db_datareader, а не изменять права доступа пользователя к каждой таблице и представлению в отдельности.

Используйте команду GRANT для управления разрешениями пользователя на доступ к объектам базы данных:

GRANT

(ALL [PRIVILEGES] | permiss1on[....n]}

{

[(column[,...n])] ON {table | view}

| ON {table | view}[(column[,...n])]

| ON {stored_procedure | extended_procedure}

}

TO security_account[,...n] [WITH GRANT OPTION] [AS {group | role}]

Назначение параметров команды GRANT следующее:

О ALL — пользователю предоставляются все
доступные разрешения. Этот параметр могут использовать только участники роли sysadmln;

О permission — список доступных разрешений, которые предоставляются пользователю (SELECT, INSERT, UPDATE, DELETE, EXECUTE). Вы можете одновременно предоставлять несколько разрешений, в этом случае их нужно разделять запятыми;

О security_account — имя того объекта системы безопасности, который необходимо включить в роль. В качестве таких объектов могут выступать как учетные записи SQL Server, так и пользователи и группы пользователей Windows NT, которым предоставлен доступ к серверу баз данных;

О table, view, column, stored_procedure, extended_procedure — в качестве данных параметров выступают имена объектов в текущей базе данных, для которых необходимо предоставить доступ;

О WITH GRANT OPTION— использование данного параметра позволяет пользователю, которому вы предоставляете права, назначать права на доступ к объекту другим пользователям;

О AS {group | role) — этот необязательный параметр позволяет указать участие пользователя в роли, которая имеет возможность предоставлять права другим пользователям.

В качестве примера команды рассмотрим следующую ситуацию. Вам необходимо предоставить права на использование команд INSERT и SELECT группе Engineer в таблице Materials. При этом нужно, чтобы в дальнейшем пользователи этой группы могли сами предоставлять аналогичные права. Для этого следует выполнить следующую команду:

GRANT SELECT. INSERT

ON Materials

TO Engineer

WITH GRANT OPTION

Впоследствии пользователь Valentin, являющийся членом группы Engineer, может предоставить аналогичные права другому пользователю L i s s:

GRANT SELECT, INSERT ON Materials ' TO Liss AS Engineer

В данном случае необходимо подтвердить, на каком основании Valentine предоставляет права, поэтому применяется параметр AS.

Будьте осторожны при использовании параметра WITH GRANT OPTION, поскольку при этом вы теряете контроль над предоставлением прав на доступ другим пользователям. Лучше всего ограничить круг людей, обладающих возможностью управлять назначением прав.

Единственное право доступа, которое может быть предоставлено для хранимой процедуры, — это право на ее выполнение (EXECUTE). Естественно, кроме этого владелец хранимой процедуры может просматривать и изменять ее код.

Для функции можно выдать право на ее выполнение, а, кроме того, можно выдать право REFERENCES, что обеспечит возможность связывания функции с объектами, на которые ссылается функция. Такое связывание позволяет запретить внесение изменений в структуру объектов, которые могли бы привести к нарушению работы функции.

Чтобы предоставить право на выполнение хранимой процедуры, можно использовать Enterprise Manager. Для этого выберите в левой панели Enterprise Manager нужную базу данных и откройте в ней папку Stored Procedures. В правой части Enterprise Manager будет отображен список хранимых процедур, уже созданных в базе данных. Управление правами доступа можно осуществлять в окне Object Properties (свойства объектов), показанном на рис. 12.20. Вызвать это окно можно либо с помощью кнопки Permissions (права) в окне свойств хранимой процедуры, либо выбрав в контекстном меню хранимой процедуры пункт АН Tasks >
Manage Permissions (все задачи >
управление правами).

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

Управление правами доступа к функциям осуществляется аналогично.

Другой способ управления правами доступа заключается в предоставлении прав конкретному пользователю с помощью окна прав доступа пользователя. Для этого в окне Enterprise Manager выберите необходимую базу данных, а затем папку Users. Щелкните левой кнопкой мыши на выбранном пользователе. В появившемся окне щелкните на кнопке Permissions (права) и укажите необходимые права.

Запрещение доступа

Система безопасности SQL Server имеет иерархическую структуру. Это позволяет ролям базы данных включать в себя учетные записи и группы Windows NT, пользователей и роли SQL Server. Пользователь же, в свою очередь, может участвовать в нескольких ролях. Следствием иерархической структуры системы безопасности является то, что пользователь может одновременно иметь разные права доступа для разных ролей. Если одна из ролей, в которых состоит пользователь, имеет разрешение на доступ к данным, то пользователь автоматически имеет аналогичные права. Тем не менее может потребоваться запретить
возможность доступа к данным. Когда вы запрещаете пользователю доступ к данным или командам Transact-SQL (deny access), тем самым аннулируются все
разрешения на доступ, полученные пользователем на любом
уровне иерархии. При этом гарантируется, что доступ останется запрещенным независимо от разрешений, предоставленных на более высоком уровне.

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

Используйте команду DENY для запрещения пользователю доступа к объектам базы данных:

DENY

(ALL [PRIVILEGES] | permission[,...n]}

{

[(columnC....n])] ON {table | view} | ON {table | vi ew} [-(columnC, . . . n])] I ON {stored_procedure | extended_procedure}

TO security_account[....n] [CASCADE]

Для запрещения выполнения команд Transact-SQL применяется другая команда:

DENY {ALL | statement^... .n]} ТО security_account[....n]

Параметры данной команды аналогичны параметрам команды GRANT. Параметр CASCADE позволяет отзывать права не только у данного пользователя, но также и у всех тех пользователей, кому он предоставил данные права. Поясним смысл вышесказанного на примере. Пусть вы предоставили пользователю Sheridan определенные права:

GRANT CREATE TABLE

ТО Sheridan

WITH GRANT OPTION

Допустим, Sheridan предоставляет аналогичные права некоторым пользователям. Если впоследствии вам потребуется отозвать разрешения у Sheridan, вы выполните команду:

DENY CREATE TABLE ТО Sheridan CASCADE

При этом будут отозваны и все разрешения, которые Sheridan предоставил другим пользователям.

Создание и обслуживание баз данных

Любая база данных SQL Server 2000 состоит из набора таблиц, содержащих данные, и дополнительных объектов, создаваемых для обработки данных. К таким объектам относятся, например, представления, триггеры и хранимые процедуры. Данные сохраняются в таблицах в соответствии с их логическим определением, например, данные об имеющихся на складе товарах хранятся в одной таблице, а список персонала — в другой.

SQL Server позволяет одновременно поддерживать множество баз данных, которые могут иметь связи с другими базами данных либо существовать независимо.

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

Настоятельно рекомендую не создавать в системной базе данных master никаких пользовательских объектов, хотя это и возможно. База данных master содержит системные таблицы, которые хранят данные о параметрах функционирования SQL Server. Поэтому повреждение данных в этой базе может привести к непредсказуемым последствиям.

SQL Server 2000 предлагает несколько путей создания баз данных. О Использование
Enterprise Manager.
Для создания базы данных с помощью

Enterprise Manager в контекстном меню папки Databases на нужном сервере.

выберите пункт New Database (новая база данных). ;

О Использование мастера
Create Database Wizard.
На панели инструментов Enterprise Manager щелкните на кнопке Run a Wizard (запустить мастера) и выберите нужного мастера.

О Использование
Transact-SQL.
Этот метод предполагает выполнение команды

CREATE DATABASE.

Кроме перечисленных методов имеется еще несколько способов создания баз данных, например средствами SQL-DMO. Работа с этими механизмами является темой отдельной книги и здесь рассматриваться не будет.

Один сервер может поддерживать, максимум, 32 767 баз данных.

Для создания базы данных необходимо указать ее название, владельца (им будет пользователь, создающий базу данных), размер, определить файлы и группы файлов, из которых будет состоять создаваемая база данных.

Перед созданием базы данных необходимо уяснить следующие моменты:

О по умолчанию базы данных разрешено создавать членам фиксированных ролей сервера sysadmin и dbcreator, хотя разрешение на создание баз данных можно предоставлять и другим пользователям;

О пользователь, создающий базу данных, автоматически становится ее владельцем;

О имя (название) базы данных должно соответствовать правилам именования объектов. Для хранения базы данных используется три типа файлов.

О Primary
—
первичный файл. Каждая база данных обязательно имеет такой файл, причем только один. В этом файле хранится системная информация о базе данных и ее объектах. Здесь же размещаются системные таблицы. Кроме того, в первичном файле могут храниться и пользовательские данные. По умолчанию этот файл имеет расширение .mdf.

О Secondary
— вторичный файл. Здесь содержатся пользовательские данные, не поместившиеся в первичном файле. Если база данных небольшая и нет надобности создавать вторичные файлы, то всю информацию можно хранить в первичном файле. Однако если база данных имеет большие размеры, можно иметь несколько вторичных файлов, причем для удобства работы с данными эти файлы можно хранить на разных дисках. По умолчанию вторичные файлы имеют расширение .ndf.

О Transaction Log
—
файл журнала транзакций. Минимальный размер такого файла —512 Кбайт. База данных должна иметь, по крайней мере, один файл журнала транзакций. В этом файле будет храниться информация о транзакциях, выполняемых в базе данных. По умолчанию файлам журнала транзакций присваивается расширение .Idf. Отметим, что файл журнала транзакций не может быть помещен на сжатый диск или удаленный сетевой диск (общедоступный сетевой каталог).

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

Использование неформатированных разделов

SQL Server 2000 позволяет использовать для создания файлов базы данных так называемые неформатированные (или «сырые» — raw) разделы. Неформатированный раздел — это раздел диска, который был создан с помощью утилиты fdisk (MS DOS, Windows 95/98) или Disk Administrator (Windows NT, Windows 2000), но не был отформатирован. На таком разделе не существует файловой системы (FAT или NTFS), поэтому там невозможно хранение файлов операционной системы. Тем не менее, если при создании базы данных в качестве физического имени файла в конструкции <fi!espec> указать неформатированный раздел, то SQL Server 2000 создаст в этом разделе блок данных (назовем его файлом), который займет все свободное пространство. Так как при создании файла будет занято все доступное пространство, то увеличение размера файла в данном случае невозможно. Следовательно, указание параметров MAXSIZE и FILEGROW не обязательно. Также не обязательно указание первоначального размера файла. В качестве физического имени файла необходимо указать только букву раздела, например F:. Задание неформатированного раздела другим способом (а такие имеются — например формат, используемый в файле boot.ini) не допускается. То есть, чтобы иметь возможность разместить файл базы данных на неформатированном разделе, нужно присвоить этому разделу конкретную букву, сконфигурировав его, таким образом, в качестве логического диска.

Отметчу, что на неформатированном разделе можно разместить лишь один файл базы данных.

Даже после того как SQL Server создаст в этом разделе файл, операционная система будет воспринимать раздел как неформатированный или как раздел с неизвестной файловой системой. Обычные операции работы с файлами, выполняемые операционной системой, будут недоступны. То есть нельзя будет выполнять копирование, удаление, изменение или перемещение созданного файла. Кроме того, операции резервного копирования с помощью утилиты Windows NT Backup также будут недоступны. Однако допускается создание резервных копий базы данных и журнала транзакций средствами SQL Server 2000.

При использовании неформатированных разделов недоступны инструменты проверки целостности диска. Более того, невозможна «горячая» замена поврежденных кластеров, которая выполняется для файловой системы NTFS на дисках SCSI.

Путем использования неформатированных разделов можно обеспечить высокий уровень безопасности информации в базе данных. При размещении файлов базы данных на обычных дисках с файловой системой всегда имеется возможность скопировать эти файлы и подключить к другому серверу SQL Server 2000. Решить эту проблему в той или иной степени может помочь файловая система NTFS. Если же вы используете файловую систему FAT, то в случае останова SQL Server 2000 файлы баз данных могут быть скопированы безо всяких затруднений.

Я отдельно отметил, что для копирования файлов баз данных необходимо остановить SQL Server 2000, а точнее, службу MSSQLServer. В противном случае файлы баз данных блокируются и к ним не удастся получить доступ.

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

Увеличение базы данных

По мере того как пользователи вносят информацию в базу данных, количество свободного пространства в ней уменьшается. Когда все свободное пространство исчерпано, сервер выдает сообщение об ошибке с номером 1105.

В предыдущих версиях SQL Server необходимо было вручную добавлять новое свободное пространство в базу данных, сначала создавая новые устройства или расширяя существующие, а затем увеличивая саму базу данных или журнал транзакций. Начиная с SQL Server 7.0, реализована возможность автоматическо
го
увеличения размеров базы данных (auto grow). Эта возможность реализуется на уровне файлов базы данных, для которых можно разрешить автоматическое увеличение размера при полном заполнении базы данных. Если возможности автоматического роста исчерпаны (например, кончилось свободное место на диске или размер файла достиг максимальной величины) или поддержка автоматического увеличения файлов вообще не была задействована, то администратор должен вручную увеличить размер базы данных (expanding database). Для этого он либо увеличивает размер существующих файлов, либо создает новые файлы. Это касается как файлов самой базы данных, так и файлов журнала транзакций.

Особенное внимание администратор должен уделить системной базе данных tempdb, в которой создаются все временные объекты. По умолчанию максималь-,ный размер файлов базы данных не ограничен. Тем не менее, если места на диске мало, то через какое-то время возможности увеличения базы данных tempdb будут исчерпаны. Сервер не сможет создавать временные объекты и, следовательно, пользователи не смогут успешно работать с любой базой данных, расположенной на этом сервере. Администратор должен своевременно отслеживать наличие необходимого свободного пространства и при необходимости добавлять к базе данных файлы, расположенные на дисках с достаточным количеством свободного пространства.

Использование
Transact-SQL

В этой главе подробно рассматриваются различные аспекты создания баз данных и управления ими в SQL Server 2000. Как уже было сказано, для работыс базами данных в SQL Server 2000 могут быть использованы различные средства — мастер Create Database Wizard, утилита Enterprise Manager и команды Transact-SQL. В этом разделе мы познакомимся с созданием и изменением баз данных, а также с управлением базами данных средствами Transact-SQL. Этот метод является наиболее сложным из всех перечисленных, но обладает максимальными возможностями. В сущности, два других метода предоставляют всего-навсего графических интерфейс для выполнения соответствующих системных хранимых процедур.

Для эффективного управления базами данных SQL Server 2000 вовсе не обязательно виртуозно владеть системными хранимыми процедурами. В большинстве случаев вполне достаточно средств, предлагаемых Enterprise Manager. Тем не менее истинный профессионал должен уметь добиться нужного результата и в том случае, когда в его распоряжении имеются лишь простые средства выполнения запросов, а использование красивых графических оболочек вроде Enterprise Manager по тем или иным причинам оказывается невозможным.

Создание баз данных

Первое, с чем сталкивается администратор при реализации базы данных, это ее создание. Казалось бы, что может быть проще, чем указать имя базы данных, и на этом дело бы закончилось. Однако база данных SQL Server 2000 является довольно сложной структурой. Более того, процесс создания базы данных может представлять собой не только собственно создание новой базы, но и присоединение готовых файлов данных. В Enterprise Manager не всегда пользователи получают все возможные средства создания баз данных, предлагаемые SQL Server 2000. Доступ к этим средствам обеспечивают только команды Transact-SQL.

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

Итак, начнем рассмотрение работы с базами данных с ее создания. В Transact-SQL создание базы данных выполняется с помощью команды CREATE DATABASE, имеющей следующий синтаксис:

CREATE DATABASE databasejiame

[ ON [ PRIMARY ]

[ < filespec > [ ....n ] ]

[ , < filegroup > [ ,...n ] ]

]

[ LOG ON { < filespec > [ ,...n ] } ]

[ COLLATE collationjiame ]

[ FOR LOAD | FOR ATTACH ]

Рассмотрим подробно назначение каждого из аргументов. О database_name. С помощью этого аргумента указывается имя, которое будет присвоено создаваемой базе данных. При выборе имени следует следовать общим правилам именования объектов. Если имя базы данных содержит пробелы или другие недопустимые символы, оно должно быть заключено в ограничители (двойные кавычки или квадратные скобки). Имя базы данных должно быть уникальным в пределах сервера и не может превышать 128 символов. Если имя журнала транзакций явно не указано, то сервер укорачивает имя базы данных таким образом, чтобы оно не превышало 123 символов. Это делается из-за того, что сервер по умолчанию использует для имени журнала транзакций имя базы данных и добавляет к нему в конце символы _Log.

О О N. Это ключевое слово означает, что далее следует определение файлов базы данных.

О PRIMARY. Это ключевое слово означает, что далее следует описание первичного файла базы данных. Напомним, что в этом файле хранятся все системные данные и таблицы. Только один файл в базе данных может быть определен как первичный. Если первичный файл не определен явно, то в этом качестве будет использоваться первый файл, указанный в конструкции <f i I espeo. Группа файлов, в которую включен первичный файл, называется первичной груп
пой файлов
(primary file group). Первичная группа назначается группой файлов
по умолчанию
(default file group), и в нее будут включены все файлы, для которых явно не указана пользовательская группа файлов
(user file group).

О LOG ON. Это ключевое слово означает, что файлы журнала транзакций будут определены явно. После LOG ON должно следовать определение файлов журнала транзакций. Если это ключевое слово не используется, то есть пользователь не задает явно файлы журнала транзакций, то сервер автоматически создает единственный файл размером 25% от общей суммы размеров файлов данных. Имя файла генерируется на основе имени базы данных, но в конце к нему добавляются символы _Log.

О FOR LOAD. Этот аргумент оставлен в большей степени для обеспечения обратной совместимости с предыдущими версиями SQL Server (до SQL Server 7.0). Он предписывает серверу создать базу данных в режиме использования только владельцем (dbo use only). Это делается, если необходимо выполнить восстановление базы данных из резервной копии. Дело в том, что в ранних версиях SQL Server восстановление базы данных было возможно только в уже существующую базу данных, установленную в режим FOR LOAD. Начиная с SQL Server 7.0, при необходимости база данных может быть создана автоматически в ходе выполнения команды RESTORE. Более того, допускается восстановление резервной копии поверх существующей базы данных.

О FOR ATTACH. Этот аргумент используется, когда необходимо выполнить присое
динение
(attach) базы данных. В этом случае на диске уже должны существовать файлы с данными. Таким образом, создание базы данных происходит только на логическом уровне — в системную таблицу sysdatabases базы данных master вносятся соответствующие записи, но создание собственно файлов не выполняется. Для подключения базы данных бывает достаточно указать только размещение первичного файла базы данных. Информация о местоположении всех других файлов базы данных (вторичных и журнала транзакций) хранится в первичном файле базы данных. Однако если местоположение файлов базы данных с момента ее отсоединения изменилось, то необходимо будет указать полный путь к каждому файлу базы данных.

Присоединение базы данных можно также выполнить и с помощью системной хранимой процедуры sp_attach_db, которая напрямую работает с системной таблицей sysdatabases и таблицами самой базы данных, внося в нее необходимые изменения.

Если присоединение участвующей в репликации базы данных выполняется не на «родном» сервере, то необходимо удалить поддержку репликации. Для этого используется хранимая процедура sp_removedbreplication [@dbname =] "dbname".

О collation_name. С помощью этого аргумента указывается сопоставление по умолчанию для всех объектов, создаваемых в базе данных. Это же сопоставление будет использоваться и для системных таблиц. Разрешается указывать как сопоставления Windows, так и сопоставления SQL Server. Если сопоставление не указывается, то для базы данных будет использоваться сопоставление, определенное на уровне сервера, то есть то сопоставление, которое было выбрано при установке SQL Server 2000.

Как видно из синтаксиса команды CREATE TABLE и уже рассмотренных аргументов этой команды, при создании базы данных можно определить набор файлов, из которых будет состоять создаваемая база данных. Уже было сказано, что файл определяется с помощью конструкции <fi1espec>, синтаксис которой приведен ниже. Эта конструкция имеет одинаковый формат для всех типов файлов (первичного, вторичного и журнала транзакций). Чтобы соответствующий файл был первичным, перед его определением необходимо указать ключевое слово PRIMARY. Журнал транзакций определяется с помощью ключевого слова LOG ON. Если ни одно из этих ключевых слов не указывается (указывается только слово ON), то соответствующий файл будет вторичным. Дополнительно файлы данных могут быть включены в группы. Это будет рассмотрено несколько позже в этом же разделе.

< filespec >

( [ NAME = Iogica1_file_name , ]

FILENAME = "os_file_name"

[ , SIZE = size ]

[ . MAXSIZE = { max_size | UNLIMITED } ]

[ . FILEGROWTH = growthj increment ] ) [ . ...n ]

Рассмотрим назначение используемых аргументов.

О NAME = logical_file_name. Логическое имя файла, под которым он будет опознаваться при выполнении различных команд Transact-SQL. Логическое имя файла должно быть уникальным в пределах базы данных. Имя файла журнала транзакций не должно совпадать с именем файла самой базы данных. Использование ключевого слова NAME не требуется, если выполняется присоединение базы данных, однако таким образом можно указать новое логическое имя для физического файла.

О FILENAME = "os_f 11 e_name". Если с помощью предыдущего аргумента указывалось логическое имя файла, то рассматриваемый аргумент предназначен для указания полного пути и названия соответствующего физического файла, который будет создан на жестком диске. Это имя будет иметь файл на уровне операционной системы. Если вы воспользуетесь какой-либо программой просмотра диска, то после успешного выполнения команды CREATE DATABASE сможете увидеть файл с указанным именем. Напомним, что SQL Server 2000 не позволяет создавать файлы базы данных на сжатых томах и сетевых дисках.

По умолчанию для файлов баз данных используются расширения .mdf, .ndf и .Idf соответственно для первичного, вторичных файлов и файлов журнала транзакций. В принципе, вы можете указать любое другое расширение, но вряд ли найдется серьезная причина делать это. Чтобы не создавать путаницы, советуем оставлять значения по умолчанию, то есть при описании файла не указывать расширение.

О SIZE = size. С помощью этого аргумента указывается первоначальный размер, который будет иметь соответствующий файл. Размер может быть указан либо в мегабайтах, либо в килобайтах. Для явного задания величины можно использовать приставки М b и К Ь. По умолчанию считается, что размер задается в мегабайтах. Минимальный размер файла составляет 512 Кбайт. Если размер файла не указывается явно, то по умолчанию будет создан файл размером > 1 Мбайт. Отметим, что в качестве размера файла разрешается задавать только целочисленные значения. Таким образом, если необходимо задать дробное количество мегабайт, следует указать соответствующее значение в килобайтах.

О FILEGROWTH = growth_iincrement. При описании физической архитектуры базы данных в главе 4 было сказано, что начиная с SQL Server 7.0 поддерживается автоматическое увеличение
(auto grow) размера базы данных, что реализуется путем последовательного автоматического увеличения размеров файлов, входящих в состав базы данных. SQL Server 2000 позволяет контролировать величину прироста каждого из файлов базы данных отдельно от других, задавая шаг прироста не на уровне базы данных, а на уровне отдельного файла. С помощью рассматриваемого аргумента задается величина прироста файла базы данных. Шаг прироста может быть указан как в абсолютном выражении в виде конкретного количества мегабайт (М Ь) или килобайт (Kb), так и в относительном в виде определенного процента (%)
от первоначального размера файла. По умолчанию предполагается, что указывается значение в мегабайтах. Если аргумент FILEGROWTH опущен, то файл будет увеличиваться на 10 % от первоначального объема. Минимальный размер, на который может быть увеличен файл, составляет 64 Кбайт. Отметим, что в сумме первоначальный размер файла и выбранный шаг прироста не должны превышать указанный максимальный размер файла.

О MAXSIZE = { max_size | UNLIMITED }. Автоматическое увеличение файлов связано с определенными проблемами. В частности, если диск с файлом базы данных используется для хранения временных файлов различных приложений, то увеличение файла базы данных до большого размера может привести к нарушению работоспособности приложений. Для избежания этой и других подобных проблем SQL Server 2000 позволяет ограничивать рост файлов конкретным размером. Для этого и требуется рассматриваемый аргумент. Максимальный размер может быть указан в мегабайтах (Mb— используется по умолчанию) или килобайтах (Kb). Отметим, что ограничение роста отдельного файла не ограничивает возможность увеличения роста всей базы данных, так как размер базы данных может увеличиваться за счет пророста других файлов. Если ограничивать максимальный размер файла не нужно, то

необходимо указать значение UNLIMITED или вообще опустить аргумент MAXSIZE, так как по умолчанию размер файла не ограничивается, и он будет расти, пока не заполнит все доступное пространство на диске. Мы рассмотрели синтаксис конструкции <filespec>, которая используется для описания файлов базы данных. Как уже было сказано, файлы данных (mdf и ndf) могут объединяться в так называемые группы файлов. Подобное объединение выполняется с целью упрощения управления файлами. Например, при создании резервных копий можно выполнять архивирование не всей базы дан- • ных целиком, а лишь определенной группы файлов. Основным же назначением групп файлов является размещение в них данных определенных таблиц или их отдельных столбцов, а также хранение индексов. При создании таблицы вы можете явно указать, в какой группе файлов должны храниться данные того или иного столбца. Как следствие, подобным образом можно предписать хранить данные столбцов на разных логических или физических дисках.

Файлы, не включенные явно ни в какую группу, будут включены в группу файлов по умолчанию, которой первоначально является первичная группа файлов. Однако если имеется необходимость в дополнительных группах файлов с теми или иными файлами, необходимо воспользоваться конструкцией <filegroup>, имеющей следующий синтаксис:

<fiIegroup> : : =

FILEGROUP filegroupjiame <filespec> [,..'.n]

Аргумент fi1egroup_name определяет имя группы файлов, под которым она будет распознаваться при выполнении команд Transact-SQL. После имени группы файлов следует определение включаемых в нее файлов. Как видно из синтаксиса, в одну группу файлов может быть включено множество файлов.

Мы рассмотрели создание обычной базы данных, работа с которой производится на локальном сервере. Иногда бывает необходимо перенести базу данных на новый сервер или разослать копии базы данных (например, каталог или годовой отчет компании). SQL Server 2000 имеет инструменты для выполнения таких задач. Перенос выполняется путем отсоединения и последующего присоединения базы данных. Далее в этой главе будет подробно описан механизм этих операций, а также будут рассмотрены хранимые процедуры для выполнения отсоединения и присоединения базы данных.

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

Для создания переносимой базы данных используется хранимая процедура sp_create_removable. Чтобы после создания базы данных проверить, соответствует ли она требованиям переносимой базы данных, можно использовать хранимую процедуру sp_certify_removable.

Управление базами данных

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

Большинство действий по изменению конфигурации базы данных выполняется с помощью команды ALTER DATABASE:

ALTER DATABASE database

{ ADD FILE < filespec > [ ,...n ] [TO FILEGROUP filegroupjiame ]

| ADD LOG FILE < filespec > [ ....n ]

j REMOVE FILE logicaljfilejiame [ WITH DELETE ]

| ADD FILEGROUP filegroupjiame

j REMOVE FILEGROUP filegroupjiame

j MODIFY FILE < filespec >

j MODIFY NAME = new_dbname

j MODIFY FILEGROUP filegroupjiame NAME=new_filegroup_name

| MODIFY FILEGROUP filegroupjiame filegroupjproperty }

j SET < optionspec > [ .. .'.n ] [ WITH < termination > ]

j COLLATE < collationjiame >

}

Как видно из синтаксиса, за один вызов команды может быть изменено не

более одного параметра конфигурации базы данных. Если необходимо выполнить несколько изменений, придется разбить процесс на несколько отдельных

шагов. Рассмотрим более подробно назначение каждого из аргументов.

О database. Имя базы данных, которую необходимо модифицировать. Естественно, указанная база данных должна существовать на сервере.

Чтобы иметь возможность изменить базу данных, необходимо, чтобы с ней не работал ни один пользователь. Если же в базе данных имеется хоть одна активная транзакция, то попытка выполнения команды ALTER DATABASE завершится ошибкой. В этом случае нужно дождаться, пока будут завершены все транзакции, либо воспользоваться аргументом WITH TERMINATION, который будет рассмотрен далее.

О ADD FILE <fi1espec> [, . . .n]. Этот аргумент используется, когда в базу данных необходимо добавить новые файлы данных. Как видно из синтаксиса, одновременно можно добавить множество файлов. Как и при работе с командой CREATE DATABASE, файлы описываются с помощью конструкции <filespec>, синтаксис и использование которой были рассмотрены в предыдущем разделе при рассмотрении создания базы данных.

• ТО FILEGROUP f 11 egroup_name. Используется в сочетании с предыдущим аргументом для добавления файлов в определенную группу файлов. Если аргумент ТО FILEGROUP не указывается, то файлы будут добавлены в группу файлов по умолчанию.

О ADD LOG FILE <f11espec> [, . . .n]. Если с помощью двух предыдущих аргументов можно добавлять в базу данных файлы данных, то аргумент ADD LOG FILE используется для добавления в базу данных одного или более файлов журнала транзакций.

О REMOVE FILE 1 ogica1_fi 1 e_name. В противоположность предыдущим, с помощью рассматриваемого аргумента осуществляется удаление из базы данных одного из файлов. Отметим, что за одну команду ALTER DATABASE можно удалить всего один файл. Аргумент REMOVE FILE используется как для удаления файлов данных, так и для удаления файлов журнала транзакций. Однако прежде чем станет возможным удаление файла, он должен быть освобожден от данных. В противном случае сервер не разрешит его удаление.

Освободить файл от данных можно с помощью команды DBCC SHRINKFILE (file_name, EMPTYFILE). Аргумент EMPTYFILE предписывает распределить все данные из файла между другими файлами группы. Добавление новых данных в файл не разрешается.

О ADD FILEGROUP f i legroup_name. Используется для создания в базе данных группы файлов с указанным именем. Как видно из синтаксиса, при создании группы не указывается, какие файлы должны в нее войти. Перенос существующих файлов в новую группу выполняется отдельно. В базе данных может быть создано до 256 групп файлов. Напомним, что группы файлов создаются только для файлов данных. Файлы журнала транзакций не могут быть организованы в группы.

О REMOVE FILEGROUP filegroup_name. Используется для удаления из базы данных указанной группы файлов. При этом также будут удалены все файлы, включенные в эту группу. Однако перед выполнением этой операции необходимо предварительно удалить из файлов все данные.

О MODIFY FILE <fi lespec>. Используется для изменения параметров файла базы данных, таких как логическое имя (NAME), первоначальный размер (SIZE), максимальный размер (MAXSIZE) и шаг приращения (FILEGROWTH). За один вызов команды ALTER DATABASE может быть изменен только один параметр одного из файлов. Хотя для описания файла и используется конструкция <fi!espec>, ее синтаксис несколько иной, чем при создании базы данных. Отличительной особенностью является наличие аргумента NEWNAME, с помощью которого можно изменить логической имя файла. В остальном же синтаксис и использование конструкции аналогичны рассмотренным ранее.

<filespec> ::=

( NAME = logical_file_narne

[ . NEWNAME = new_log1cal_name ]

[ , FILENAME = "os_file_name" ]

[ . SIZE = size ]

[ . MAXSIZE = { max_s1ze | UNLIMITED } ]

[ . FILEGROWTH = growthjncrement ] )

О MODIFY NAME = new_dbname. Как нетрудно догадаться, этот аргумент позволяет изменять имя базы данных. Для этого достаточно всего-навсего указать новое имя с помощью параметра new_dbname.

О MODIFY FILEGROUP fi1egroup_name NAME = new_fi1egroup_name. Помимо изменения имени базы данных также можно переименовать и отдельную группу файлов. Это и делается с помощью рассматриваемого аргумента. Все, что нужно для изменения имени группы, — указать текущее имя с помощью параметра f i I egroup_name и новое имя— с помощью параметра new_fiIegroup_name.

О MODIFY FILEGROUP fi1egroup_name filegroup_property. Этот аргумент позволяет управлять свойствами группы файлов. Имя группы файлов, свой- • ства которой предполагается изменить, задается параметром f i I egroup_name, тогда как параметр f i I egroup_property предназначен для указания свойства, которое должно быть назначено для группы файлов. Поддерживаются следующие значения параметра f ilegroup_property.

* READONLY. При указании этого значения группа файлов переводится в режим «только для чтения». В этом режиме запрещается выполнение любых модификаций данных в файлах, принадлежащих соответствующей группе. Переключение группы файлов в режим «только для чтения» могут выполнять только пользователи, имеющие монопольный доступ к базе данных. Нельзя устанавливать в режим «только для чтения» первичную группу файлов, так как в этом случае системные таблицы будут заблокированы и выполнение любых изменений в базе данных (в том числе и отмена для группы файлов режима «только для чтения») станет невозможным.

* READWRITE. Действие этого значения обратно предыдущему. Используется для разрешения изменений в группе файлов, установленной в режим «только для чтения». Работа с этим значением, как и с предыдущим, разрешена только пользователям, имеющим монопольный доступ к базе данных.

* DEFAULT. Используется для маркировки указанной группы файлов как группы файлов по умолчанию (default filegroup). В эту группу файлов будут включаться все файлы данных, которые явно не включены ни в какую другую группу файлов. Более того, все объекты (индексы, таблицы и их столбцы), для которых явно не указано, в какой группе файлов они должны располагаться, будут размещены в группе файлов по умолчанию. Группа файлов, которая до этого была группой файлов по умолчанию, становится обычной группой.

О WITH <termination>. Вполне возможна ситуация, когда попытка изменения базы данных происходит при выполнении какой-либо транзакции. Как уже говорилось, эти две операции несовместимы и одна из них должна быть отложена до окончания другой. То есть администратор должен либо подождать завершения всех активных транзакций, либо принудительно прервать их выполнение. В первом случае администратор может довольно долго ждать завершения всех транзакций. Более того, ничто не помешает пользователям начинать новые транзакции. В предыдущих версиях, в том числе и в SQL Server 7.0, это было единственным решением. К счастью, в SQL Server 2000 появилась возможность принудительного прерывания всех пользовательских транзакций. Именно для этого и используется аргумент WITH <ternnnation>, который определяет метод прерывания транзакций. Синтаксис конструкции <termination> следующий:

< termination > ::= ROLLBACK AFTER integer [ SECONDS ] | ROLLBACK IMMEDIATE | NO WAIT

» ROLLBACK AFTER num_second [SECONDS] — в этом случае сервер будет ожидать указанное количество секунд, прежде чем прервет все активные и обслуживание баз данных транзакции. Предварительно можно отправить пользователям сообщение по сети, что через столько-то секунд все транзакции будут принудительно откачены. За это время пользователи должны либо зафиксировать, либо откатить свои транзакции. * ROLLBACK IMMEDIATE — в этом случае откат пользовательских транзакций

выполняется немедленно без каких-либо пауз.

» NO WAIT— как и в предыдущем случае, откат происходит сразу же. О COLLATE < conation_name >. С помощью этого аргумента указывается сопоставление по умолчанию для всех объектов, создаваемых в базе данных. Изменение сопоставления по умолчанию не влияет на сопоставления, используемыми уже созданными объектами базы данных. Разрешается указываться как сопоставления Windows, так и сопоставления SQL Server. Определяет сопоставление для базы данных.
По умолчанию задается сопоставление SQL Server.

О SET <optionspec> [ , . . . n ]. С помощью аргумента SET пользователь может управлять различными свойствами базы данных. Свойства указываются с помощью конструкции <optionspec>, которая имеет довольно объемную структуру. Более подробно управление свойствами базы данных будет рассмотрено далее в этой главе в разделе «Управление свойствами базы данных».

В предыдущих версиях SQL Server, включая и SQL Server 7.0, не поддерживалась

возможность изменения свойств базы данных с помощью команды ALTER DATABASE.

Уменьшение размера базы
данных

В одном из предыдущих разделов этой главы было рассказано о возможности SQL Server 2000 автоматически увеличивать размер баз данных. Однако нередко требуется выполнить и обратный процесс — уменьшение размера базы данных. Действительно, если из базы данных удаляется значительная часть данных или после нескольких дней напряженной работы пользователи существенно снижают нагрузку на сервер и в журнале транзакций образуется много свободного пространства, часто возникает необходимость вернуть неиспользуемое дисковое пространство в операционную систему. Как и увеличение базы данных, процесс уменьшения размера базы данных, называемый также сжатием базы данных (shrinking database), представляет собой
уменьшение размера отдельных файлов, из которых состоит база данных.

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

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

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

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

Для разрешения или запрещения автоматического уменьшения базы данных используется хранимая процедура sp_dboption:

sp_dboption "database_name", "autoshrink". ("true" | "false")

С помощью первого аргумента указывается имя базы данных, свойства которой предполагается изменять. Второй аргумент должен оставаться таким, как он приведен выше. Указывая значение "true" или " f al se", можно соответственно разрешать и запрещать автоматическое уменьшение файлов базы данных.

Автоматическое уменьшение размера базы данных можно разрешить и с помощью команды ALTER DATABASE, воспользовавшись аргументом SET. Более подробно управление свойствами базы данных будет рассмотрено в следующем разделе.

Помимо автоматического можно также выполнять ручное уменьшение размера базы данных. Это делается с помощью команды контроля согласованности
(или целостности) базы данных
(database consistency check, DBCC):

DBCC SHRINKDATABASE

( databasejname [ , target_percent ]

[ , { NOTRUNCATE | TRUNCATEONLY } ]

)

Рассмотрим назначение аргументов.

О database_name. Имя базы данных, которую необходимо сжать.

О target_percent. Количество процентов свободного пространства, которое желательно оставить в базе данных после выполнения ее сжатия. Говоря точнее, с помощью рассматриваемого аргумента указывается процент от общего объема файлов базы данных, который должен быть незаполненным. Например, если в файле размером 10 Мбайт имеется 4 Мбайта свободного пространства, то для уменьшения количества неиспользуемого пространства до 2 Мбайт необходимо указать значение аргумента target_percent равным 25. Сначала сервер вычисляет объем свободного и занятого пространства (соответственно 4 и 6 Мбайт). Чтобы получить искомые 25 процентов, соотношение свободного и занятого пространства должно быть 3 к 1. Путем нехитрых вычислений сервер приходит к выводу, что нужный результат будет получен при размере файла, равном 8 Мбайт. После этого сервер переносит все данные из последних 2 Мбайт файла в первые 8 Мбайт, помещая их в любое незанятое место на странице. После того как все данные будут перенесены, выполняется уменьшение размера файла. Заметим, что в аргументе target_percent нельзя указывать размер, превышающий текущий процент свободного пространства. В противном случае уменьшение размера файла выполнено не будет. Таким образом, выполняя команду DBCC SHRINKDATABASE

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

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

О TRUNCATEONLY. При задании этого аргумента сервер удаляет все свободное пространство в файле за последним используемым экстентом. Значение аргумента target_percent при этом игнорируется. Не предпринимается никакой попытки перемещения данных для более эффективного их распределения в файле. Если в файле размером 2 Мбайт выделено всего два экстента в начале и в середине файла, то при использовании команды DBCC SHRINKDATABASE будет освобождена только половина файла, начиная от второго экстента и до конца файла. Размер файла будет составлять около 1 Мбайт, хотя в принципе он мог быть уменьшен до 128 Кбайт.

Права на сжатие базы данных с помощью команды DBCC SHRINKDATABASE выданы только членам фиксированной роли сервера sysadmin и фиксированной роли базы данных dbowner. Эти права не могут быть переданы пользователю никаким другим способом, кроме как включением его в одну из этих ролей. Чтобы уменьшить количество свободного пространства в базе данных pubs до 15% с
резервированием освобожденного пространства для дальнейшего использования, необходимо выполнить следующую команду: DBCC SHRINKDATABASE (pubs. 15. NOTRUNCATE)

He имеет значения, в контексте какой базы данных выполняется команда DBCC SHRINKDATABASE, так как при ее вызове явно указывается имя нужной базы данных.

После выполнения команды сервер выдаст примерно следующее сообщение:

Dbld Fileld CurrentSize MinSize UsedPages EstimatedPages

5 2 96 63 96 56

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system

administrator.

Рассмотрим назначение столбцов в полученном результате. О Dbld — идентификационный номер базы данных. Этот номер-будет одинаков

для всех отображаемых строк.

О Fileld— идентификационный номер файла базы данных, размер которого был уменьшен в процессе сжатия базы данных. Если некоторые файлы не были сжаты, то информация о них не выводится.

О CurrentSize— количество страниц, которое имеется в файле, причем учитываются как заполненные, так и свободные страницы.

О MinimumSize— минимальное количество страниц, до которого может быть уменьшен файл. Это значение может ограничиваться начальным размером файла, установленным при его создании. В ином случае оно равно значению в столбце EstimatedPages.

О UsedPages— количество страниц, содержащих данные.

О EstimatedPages— количество страниц, до которого может быть сжат файл. Однако не всегда файл может быть сжат до указанного размера, так как нельзя установить размер файла меньше первоначального.

Список баз данных и соответствующих идентификационных номеров хранится в таблице sysdatabases системной базы данных master. Для получения идентификационного номера базы данных можно использовать команду DB_ID ("databasename"). Если же необходимо определить имя базы данных по идентификационному номеру, то можно воспользоваться командой DB_NAME(database_id).

Команда DBCC SHRINKDATABASE работает с целой базой данных. Если же необходимо уменьшить размер конкретного файла базы данных, то для этого следует использовать команду DBCC SHRINKFILE, имеющую следующий синтаксис:

DBCC SHRINKFILE

( { filejname | fllejd }

{ [ . target_size ]

j [ . { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]

Выполнение этой команды, в отличие от команды DBCC SHRINKDATABASE, должно производиться в контексте той базы данных, файл которой предполагается уменьшить. Напомним, что для переключения баз данных используется команда USE. Рассмотрим назначение аргументов команды DBCC SHRINKFILE. О f i 1 e_name | f i 1 e_i d. Имя файла, который необходимо сжать, или его иден-

тификационный номер. Для получения идентификационного номера файла

базы данных можно использовать команду FILE_ID: FILE ID ("filename")

ПРИМЕЧАНИЕ

Список файлов базы данных, их идентификационных номеров, логических и физических имен хранится в таблице sysfiles каждой базы данных.

О target_size. Желательный размер (целое число в мегабайтах), который должен иметь файл после выполнения сжатия. Если размер не указывается, то файл сжимается до минимально возможного размера. При выполнении команды DBCC SHRINKFILE сервер при необходимости выполняет перемещение данных из части файла, которая должны быть удалена, в ту часть, которая будет оставлена. Если размер target_size меньше, чем минимально возможный размер файла, то сжатие файла будет выполняться только до минимально возможного размера. Например, если файл размером 20 Мбайт содержит 14 Мбайт данных, а пользователь пытается сжать его до 10 Мбайт, то файл будет сжат только до 14 Мбайт. Если размер файла после сжатия становится

меньше первоначального размера, то новый размер становится минимальным размером файла.

О EMPTYFILE. При использовании этого аргумента сервер выполняет перенос данных из файла в другие файлы, включенные в ту же группу, что и сжимаемый файл. Сервер не будет добавлять новые данные в файл, сжатый с аргументом EMPTYFILE. Такой файл может быть уничтожен с помощью команды ALTER DATABASE REMOVE FILE.

О NOTRUNCATE. Использование этого аргумента предписывает серверу не возвращать освободившееся место операционной системе. Таким образом, размер файла на самом деле не уменьшается. Данные в файле располагаются более компактно и смещаются к началу файла. Если аргумент NOTRUNCATE не указан, то освободившееся пространство возвращается операционной системе, то есть размер файла уменьшается.

О TRUNCATEONLY. При указании этого аргумента сервер выполняет урезание части файла, начиная от последней используемой страницы до конца файла. Значение аргумента target_size в этом случае игнорируется. Никакого перемещения данных для более компактного их расположения не предпринимается. Для сжатия файла данных базы данных pubs до 1 Мбайт введите следующую команду:

USE Pubs

DBCC SHRINKFILE (pubs, 1)

В результате сервер выдаст таблицу, подобную той, которая выдается при

выполнении команды DBCC SHRINKDATABASE. Состав и назначение столбцов в

обоих случаях аналогичны:

Dbld Fileld CurrentSize MinimumSize UsedPages EstimatedPages

5 1 296 80 288 288

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system

administrator.

Удостоверимся, что файлом с идентификационным номером 1 является файл pubs:

SELECT FILE_ID("pubs") SELECT FILE_NAME(1)

В итоге будет получен следующий результат:

(1 row(s) affected)

pubs

(1 row(s) affected)

Права на выполнение команды DBCC SHRINKFILE выдаются таким же образом, как и для команды DBCC SHRINKDATABASE.

Для журнала транзакций или его файлов сжатие происходит не сразу, а при последующем выполнении операции усечения (truncate) или резервного копирования.

Управление свойствами базы данных

Помимо перечисленных выше физических
параметров (описывающих в основном имена, размеры, положение и другие характеристики файлов) база данных имеет еще и логические
параметры. К этим параметрам относятся выполнение автоматического усечения журнала транзакций, автоматическое создание и обновление статистики, возможность выполнения вложенных триггеров и другие. Управление этими параметрами конфигурации базы данных сводится к их разрешению или запрещению и осуществляется с помощью системной хранимой процедуры sp_dboption. Назначение основной части параметров было рассмотрено в главе 11. Синтаксис хранимой процедуры sp_dboption следующий:

sp_dboption [[@dbname =] "database"] [. [@optname =] "optionjiame"] [. [@optva"lue =] "value"]

Аргумент "database" содержит имя базы данных, в которой необходимо выполнить изменение конфигурации. Аргумент "value" определяет значение параметра. Возможны два варианта: значение ON или TRUE (параметра задан) и значение OFF или FALSE (параметра не задан). Аргумент "option_name" определяет имя параметра, который необходимо изменить. Возможные значения этого аргумента приведены в табл. с кратким указанием назначения каждого параметра.

Таблица.
Параметры конфигурации базы данных

Параметр

Назначение'

a uto create statistics auto update statistics autoclose autoshrink ANSI null default ANSI nulls ANSI warning concat null yields null

cursor close on commit

dbo use only

default to local cursor

merge publish

offline

published

quoted identifier

read only recursive triggers select into/bulk copy

Автоматическое создание статистики

Автоматическое обновление статистики

Автоматическое закрытие базы данных

Автоматическое сжатие базы данных

Разрешение значения NULL по умолчанию для столбца

Управление сравнением величин NULL

Появление сообщений об ошибке

Значение ON означает, что результатом объединения величин NULL будет значение NULL

Закрытие курсора при завершении транзакции

Использование базы данных только владельцем

Создание по умолчанию локального курсора

База данных может публиковаться для репликации сведением

Отключение базы данных

Разрешение публикации базы данных

Разрешение использования двойных кавучек для указания идентификаторов

Использование базы данных только для чтения Разрешение выполнения вложенных триггеров

Разрешение выполнения команд копирования, не регистрируемых

в журнале транзакций
___________________________

продолжение А

данных

Таблица
(продолжение)

Параметр Назначение

subscribed Разрешение подписки на публикацию single user Использование базы данных в
режиме поддержки одного пользователя

torn page detection Обнаружение поврежденных страниц

trunc. log on chkpt
____Усечение журнала транзакций при выполнении контрольной точки

Например, для переключения базы данных pubs в однопользовательский режим нужно выполнить следующую команду: ЕХЕС sp_dboption "pubs", "single user", "true"

Часть установленных администратором параметров конфигурации базы данных может быть изменена пользователем с помощью команды SET на уровне соединения, транзакции, хранимой процедуры, пакета команд и т. д. Эти изменения действуют только в пределах соединения (транзакции, хранимой процедуры и т. д.) и будут потеряны сразу же после отсоединения пользователя. При последующем соединении снова будут использоваться параметры, установленные администратором.

Использование системной хранимой процедуры sp_dboption для управления свойствами базы данных было единственным вариантом в предыдущих версиях. Даже при работе с SQL Server 7.0 администратор имел в своем распоряжении только эту процедуру. В SQL Server 2000 изменение параметров базы данных также может выполняться с помощью команды ALTER DATABASE с аргументом SET <optionspec>. Как нетрудно догадаться, свойства базы данных, которые предполагается изменить, указываются с помощью конструкции <optionspec>, имеющей следующий синтаксис:

<opt1onspec>::=

< state_option >

[ < cursor_option >

| < auto_option >

| < sql_option >

| < recovery_option >

< state_option > .- .- =

{ SINGLEJJSER | RESTRICTED_USER | MULTIUSER }

| { OFFLINE | ONLINE }

| { READJ3NLY | READ_WRITE }

< termination >

ROLLBACK AFTER integer [ SECONDS ]

| ROLLBACK IMMEDIATE

| NO WAIT

< cursor_option > : : =

CURSOR_CLOSE_ON_COMMIT { ON | OFF }

| (CURSOR_DEFAULT { LOCAL | GLOBAL }

< auto_option >

{ AUTO_CLOSE ON | OFF }

| { AUTO_CREATE_STATISTICS ON | OFF }

| { AUTO_SHRINK ON | OFF }

| { AUTO_UPDATE_STATISTICS ON | OFF }

< sql_option > ::=

ANSI_NULL_DEFAULT { ON | OFF }

| ANSI_NULLS { ON | OFF }

j ANSI_PADDING { ON | OFF }

j ANSIJIARNINGS { ON | OFF }

| ARITHABORT { ON | OFF }

| CONCAT_NULL_YIELDS_NULL { ON | OFF }

| NUMERIC_ROUNDABORT { ON | OFF }

| QUOTEDJDENTIFIER { ON J OFF }

| RECURSIVEJRIGGERS { ON | OFF }

< recovery_option > ::=

RECOVERY { FULL | BULK_LOGGED | SIMPLE }

| TORN_PAGE_DETECTION { ON | OFF }

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

Присоединение и отсоединение базы данных

SQL Server 2000 позволяет отсоединять
(detach) базы данных от сервера. Пользователи не могут обращаться к отсоединенным базам данных. Описание отсоединенной базы данных, включая описание файлов журнала транзакций и самой базы данных, удаляется из системных таблиц SQL Server и, таким образом, сервер перестает ее воспринимать. Позже эту базу данных можно присоединить
(attach) на этом же или другом сервере.

Отсоединение и присоединение в основном используются для переноса баз данных с одного диска или сервера на другой. Если требуется скопировать базу данных на один или несколько удаленных серверов, можно выполнить резервное копирование базы данных и разослать копии. Другой способ — выполнить отсоединение базы данных и разослать пользователям все ее файлы. У себя на сервере пользователи смогут выполнить присоединение базы данных и сразу же начать работать с ней. Процедура отсоединения и присоединения занимает гораздо меньше времени, чем создание и восстановление резервной копии. Кроме того, отсоединенную базу данных можно записать на компакт-диски и разослать пользователям. Пользователи смогут работать с базой данных непосредственно с компакт-диска в режиме «только для чтения». Такой подход особенно эффективен при рассылке каталогов, которые не должны изменяться.

Если планируется скопировать базу данных на компакт-диск, предварительно необходимо установить все ее группы файлов в режим «только для чтения». Для этого используется команда ALTER DATABASE MODIFY FILEGROUP filegroup_name READONLY.

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

Для отсоединения базы данных используется следующая хранимая процедура:

sp_detach_db [@dbname =] "dbname" [, [@skipchecks =] "skipchecks"]

Аргумент "dbname" указывает имя базы данных, которую необходимо отсоединить. Аргумент "skipchecks" управляет обновлением статистики при отсоедине-

нии. Если значение этого аргумента равно TRUE, то обновление статистики пропускается, если же указывается FALSE, то обновление статистики будет выполнено. Для отсоединения базы данных pubs нужно использовать следующую команду:

ЕХЕС sp_detach_db "pubs"

После отсоединения базы данных вы получаете в свое распоряжение набор обычных файлов, с которыми можно выполнять обычные операции, в том числе и архивирование с использованием утилиты NT Backup.

Для присоединения отсоединенной базы данных используется системная хранимая процедура sp_attach_db:

sp_attach_db [@dbname =] "dbname", [(Pfilenamel =] "filenameji" [,...16]

Аргумент "filename_n" должен содержать полный путь к первичному файлу присоединяемой базы данных. Описание остальных файлов базы данных хранится в первичном файле. Если положение этих файлов было изменено, то необходимо явно указать их положение при вызове хранимой процедуры — через запятую в аргументе "f i lename_n".

Количество файлов, которое можно присоединить с помощью хранимой процедуры sp_attach_db, ограничивается 16. Если необходимо выполнить подключение базы данных с большим количеством файлов, используется команда CREATE DATABASE FOR ATTACH.

Для присоединения базы данных pubs нужно выполнить следующую команду: sp_detach_db"pubs".

"d:mssqldatapubs.mdf" .

"d:mssqldatapubs_log.Idf"

Если база данных состоит из одного файла данных и одного файла журнала транзакций, то ее можно присоединить, указав только первичный файл. База данных должна быть отсоединена от сервера с помощью хранимой процедуры sp_detach_db. Для присоединения такой базы данных используется следующая хранимая процедура:

sp_attach_sing1e_file_db [@dbname =] "dbname".

[@physname =] "physicaljiame"

Сервер автоматически создаст для базы данных файл журнала транзакций и выполнит удаление из базы данных поддержку репликации, если она была установлена.

Для присоединения базы данных pubs с использованием только первичного файла необходима следующая команда: sp_attach_single_file_db "pubs", "d:mssqldatapubs.mdf"

Передача прав владения

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

Для передачи прав владения базой данных от одного пользователя другому используется следующая хранимая процедура:

sp_changedbowner [(Ploginame =] "login"

[,[@map =] remap_al1as_f1ag]

Рассмотрим назначение каждого из аргументов хранимой процедуры. О [Ologiname =] "login". Имя учетной записи пользователя, которого требуется сделать владельцем базы данных. Эта учетная запись не должна иметь доступа к базе данных ни через псевдоним, ни через отображение в пользователя базы данных. В противном случае перед выполнением хранимой процедуры необходимо сначала удалить все отображения учетной записи в пользователя базы данных.

О [map =] remap_al i as_fl ag. Этот аргумент может принимать значение TRUE или FALSE. Значение TRUE означает, что учетная запись старого владельца базы данных будет отображаться в учетную запись нового владельца. Если задано FALSE, учетная запись старого владельца уничтожается. Если этот аргумент опускается, то есть принимает значение NULL, то все существующие dbo будут отражены в учетную запись нового владельца базы данных. Хранимая процедура sp_changedbowner должна выполняться в контексте базы данных, владельца которой необходимо изменить. Например, для изменения владельца базы данных KHSU необходимо выполнить следующую команду:

USE khsu

EXEC sp_changedbowner "MATRIXXAdmlnistrator"

Изменение имени базы данных

При рассмотрении команды ALTER DATABASE мы уже говорили, что она позволяет изменить имя базы данных. Однако для изменения имени базы данных также можно использовать следующую хранимую процедуру:

sp_renamedb [@old_name =] "old_name". [@new_name =] "new_name"

Аргумент "old_name" должен содержать старое имя базы данных. Новое же имя указывается с помощью аргумента "new_name".

Права на выполнение этой хранимой процедуры имеют только члены фиксированной роли сервера sysadmin.

Просмотр свойств базы данных

Часто бывает необходимо получить исчерпывающую информацию о структуре и параметрах базы данных. В этом разделе будут рассмотрены средства Transact-SQL, с помощью которых можно получить различную информацию о базе данных. Для просмотра значения параметров конфигурации базы данных, установленных с помощью хранимой процедуры sp_dboption или средствами Enterprise Manager, можно использовать системную хранимую процедуру sp_dboption с указанием только имени базы данных. Например, для получения информации о параметрах базы данных pubs можно выполнить следующую команду: EXEC sp_dbopt1on "pubs"

Будет возвращен примерно следующий результат:

The following options are set:

published

trunc. log on chkpt. torn page detection auto create statistics auto update statistics

Как видно, возвращается список только тех параметров, которые были установлены. Для получения значения конкретного параметра необходимо указать не только имя базы данных, но и имя интересующего параметра конфигурации:

ЕХЕС spjboption "pubs", "ANSI null default"

В результате выполнения этой команды будет получен примерно следующий результат:

OptionName CurrentSetting

ANSI null default off

Если выполнить хранимую процедуру sp_dboption вообще без аргументов, то она выдаст список всех доступных параметров конфигурации:

Settable database options:

ANSI null default

ANSI nulls

ANSI padding

ANSI warnings

arithabort

auto create statistics

auto update statistics

autoclose

autoshrink

concat null yields null

cursor close on commit

dbo use only

default to local cursor

merge publish

numeric roundabort

offline

published

quoted identifier

read only

recursive triggers

select into/bulkcopy

single user

subscribed

torn page detection

trunc. log on chkpt.

Помимо хранимой процедуры sp_dboption для получения значения тех же и некоторых дополнительных параметров конфигурации можно использовать следующую команду: DATABASEPROPERTY("database_name". "property")

Аргумент database_name должен содержать имя базы данных, свойства которой необходимо просмотреть. Возможные значения аргумента property и их назначение перечислены в табл. 14.2.

Таблица
Аргументы команды DATABASEPROPERTY

Аргумент

IsAnsiNullDefault

IsAnsiNullEnabled

IsAnsiWarningEnabled

IsAutoClose

IsAutoShrink

IsAutoUpdateStatistics

IsBulkCopy

IsCloseCursorOnCommit-Enabled

IsDboOnly

IsDetached

IsEnergencyMode

IsFulltextEnabled

IsInLoad

IsInRecovery

IsInStandby

IsLocalCursorsDefault

IsNotRecovered IsNullConcat

IsOffline IsQuotedldentifiersEnabled

leReadOnly

IsRecursiveTriggersEnabled

IsShutDown

Назначение

Аналог аргумента "ANSI null default" процедуры sp_dboption

Аналог аргумента "ANSI nulls" процедуры sp_dboption

Аналог аргумента "ANSI warning" процедуры sp_dboption

Аналог аргумента "autoclose" процедуры sp_dboption

Аналог аргумента "autoshrink" процедуры sp_dboption

Аналог аргумента "auto update statistic" процедуры sp_dboption

Аналог аргумента "select into/bulk copy" процедуры sp_dboption

Аналог аргумента "cursor close on commit" процедуры spjdboption

Аналог аргумента "dbo use only" процедуры sp_dboption

База данных отделялась командой sp_detach

Разрешение работы с «подозрительной» базой

Поддержка полнотекстового поиска

База данных была загружена из резервной копии

Выполняется восстановление базы данных

База данных работает в режиме «только для чтения»

Аналог аргумента "default to local cursor" процедуры sp_dboption

Восстановление базы данных завершилось с ошибкой

Аналог аргумента "concat null yields null" процедуры sp_dboption

Аналог аргумента "offline" процедуры sp_dboption

Аналог аргумента "quoted identifier" процедуры sp_dboption

Аналог аргумента "read only" процедуры sp_dboption

Аналог аргумента "recursive triggers" процедуры sp_dboption

В базе при запуске сервера возникают ошибки__

продолжение &

Таблица
(продолжение)

Аргумент Назначение

IsSingleUser Аналог аргумента "single user" процедуры

sp_dboption

IsSuspect Имеются сомнения в целостности базы данных IsTruncLog Аналог аргумента "trunc. log on chkpt." процедуры

sp_dboption

Version Внутренний номер версии сервера SQL Server, ________________________ на котором была создана база

данных
_________

Результатом выполнения команды DATABASEPROPERTY будет либо значение О, соответствующее значению FALSE или OFF хранимой процедуры sp_dbopt1 on, либо значение 1, соответствующее значению TRUE или ON. Исключением из правила является значение, возвращаемое для параметра Version. Для этого параметра возвращается значение типа int, которое может принимать любое положительное значение. Если значение параметра не определено, то команда вернет значение NULL.

Приведем пример использования команды DATABASEPROPERTY для получения информации о режиме слияния двух значений NULL, установленном для базы данных pubs: SELECT DATABASEPROPERTY ("pubs", " IsNullConcat")

Сервер вернет примерно следующий результат:

(1 row(s) affected)

Для получения некоторой общей информации о базе данных можно использовать следующую хранимую процедуру: spjielpdb [[@dbname=] "name"]

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

Для получения информации о файлах базы данных из хранимой процедуры spjielpdb происходит вызов хранимой процедуры sp_helpfile, которая и выдает информацию о параметрах файла. Поэтому формат результата выполнения этих хранимых процедур одинаков. Более подробно формат данных будет рассмотрен ниже.

Для получения информации о базе данных pubs можно использовать следующую команду:

ЕХЕС spjielpdb "pubs"

Объем информации, возвращаемый этой командой, достаточно велик, поэтому возможности привести эту информацию в книге нет. Однако вы можете выполнить указанную команду в Query Analyzer и посмотреть, что же будет выдано в ответ.

Для получения информации о конкретном файле базы данных можно использовать следующую хранимую процедуру: sp_helpfile [[^filename = ] "name"]

Эта процедура выдает информацию о файле в следующих столбцах: О Name — логическое имя файла в базе данных;

О Filename— физическое имя файла в операционной системе, которое включает полный путь к файлу;

О Filegroup— имя группы файлов, к которой принадлежит файл;

О Si ze — текущий размер файла;

О Maxsize— максимальный размер файла, установленный при его создании;

О Growth — шаг прироста размера файла;

О Usage— тип использования файла; возможно одно из двух значений: data only (файл используется для хранения данных) или log on!у (файл используется для хранения журнала транзакций).

Для получения информации о группе файлов можно использовать следующую хранимую процедуру: sp_helpfilegroup [[Ofilegroupname =] "name"]

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

Для получения информации о группе файлов PRIMARY базы данных pubs можно использовать следующую команду: ЕХЕС sp_helpf11egroup "primary"

Будет получен примерно следующий результат: groupname groupid fllecount

PRIMARY 1 1

f11e_in_group fileid filename size maxsize growth

pubs 1 pubs.mdf 2688 KB Unlimited Ш

В столбце Filename будет указан полный путь к файлу.

Для просмотра информации об использовании пространства внутри базы данных можно применить следующую, системную хранимую процедуру:

sp_spaceused [[@objname =] "objname"] [, [@updateusage =] "updateusage"]

Аргумент "objname" содержит имя таблицы базы данных, о которой необходимо получить информацию. Аргумент "updateusage" управляет выполнением команды DBCC UPDATEUSAGE и может принимать значения TRUE или FALSE.

Если процедура sp_spaceused запускается без аргументов, то будет выведена информация об использовании пространства в текущей базе данных. В результате выполнения sp_spaceused в контексте базы данных pubs будет получен примерно следующий результат:

database_name

pubs

reserved data

database_s1ze 3.63 MB

Index size

unallocated space 1.10 MB unused

2584 KB 1120 KB 1288 KB 176 KB

Как видно, результат состоит из двух наборов. В столбце database_name указано имя базы данных, о которой выводится информация, в столбце database_s1 ze — первоначальный размер базы данных, а в столбце unal I ocated space— пространство, которое было освобождено при сжатии.

В столбце reserved отображается сумма зарезервированного для базы данных пространства (database_size - "unallocated space" = data + index_size + unused). В столбце data указан объем памяти, занимаемый данными, а в столбце index_size— объем памяти, занимаемый индексами. Размер свободного пространства в базе данных выводится в столбце unused.

Чтобы получить информацию об использовании пространства в таблице titleauthor, можно использовать следующую команду: ЕХЕС sp_spaceused " titleauthor"

В результате процедура выдаст примерно следующее: name rows reserved data index_size unused

titleauthor 25 48 KB 8 KB 40 KB 0 KB

В столбце name указано имя таблицы, о которой выводится информация, а в столбце rows — число строк данных, которое введено в таблице. Объем памяти, выделенный в базе данных для таблицы, указывается в столбце reserved (data + index_s1ze + unused). В столбце data указан объем памяти, занимаемой данными, хранящимися в таблице, а в столбце i ndex_si ze — объем памяти, отведенный для индекса. Объем свободного пространства указывается в столбце unused

Для получения информации о журнале транзакций Transact-SQL предлагает команду DBCC SQLPERF, выдающую информацию об использовании журналов транзакций в каждой из баз данных, созданных на сервере.

Для получения информации об использовании журналов транзакций нужно выполнить следующую команду: DBCC SQLPERF (LOGSPACE)

В результате будет выдана следующая информация: DatabaseName LogSize(MB) Log Space Used ( %
) Status

Samp! e_3	1.9921875	33.039215
Sample_2	1.9921875	34.264706
Sample 1	1.9921875	33.553921
Distribution	0.9921875	56.98819
Abba	0.9921875	38.877953
Northwi nd	0.9921875	46.948818
Pubs	0.9921875	55.610237
Msdb	2.4921875	35.442791
Tempdb	0.4921875	85.079521
Model	0.7421875	45.328949
Master	1.2421875	34.709118

(12 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Вся информация о файлах и группах файлов базы данных хранится в системных таблицах. Хранимые процедуры обращаются к этим таблицам и возвращают пользователю результат в удобном виде. Хотя в некоторых случаях бывает проще напрямую считать данные из системных таблиц, чем выполнять хранимые процедуры, Microsoft настоятельно советует не прибегать к прямому обращению к системным таблицам, так как их структура может быть изменена в следующих версиях, и поэтому программы, успешно работающие с одной из версий SQL Server, могут работать неправильно или вообще не работать со следующими версиями этой СУБД. При использовании хранимых процедур Microsoft гарантирует, что совместимость будет сохранена.

Все же для полноты картины приведем структуру системных таблиц, в которых хранится описание физической структуры базы данных.

Список файлов базы данных хранится в системной таблице sysfiles. Каждая строка этой таблицы соответствует одному файлу базы данных. Таблица sysfiles является виртуальной и не может быть изменена непосредственно с помощью команд DELETE, UPDATE или INSERT. Тем не менее, пользователи могут считывать данные из этой таблицы, используя команду SELECT. Структура таблицы sysf i I es приведена в табл. 14.3.

Таблица.
Структура системной таблицы sysfiles

Имя столбца	Тип данных	Назначение
Field	Smallint	Идентификационный номер (ID) файла в базе данных
GroupID	Smallint	ID группы файлов, к которой принадлежит файл
Size	Int	Текущее количество страниц в файле
Maxsize	Int	Максимальный размер файла. Значение -1 означает,
		что размер файла не ограничен
Growth	Int	Шаг приращения
Status	Int	Текущий статус файла
Perf	Int	Зарезервировано
Name	Nchar(128)	Логическое имя файла
Filename	Nchar(260)	Физическое имя файла

Таблица sysf lies описывает подробную структуру файлов. Более компактное описание файлов хранится в таблице sysfilesl, которая содержит столбцы status, field, name и filename, назначение которых аналогично. Для просмотра информации о файлах базы данных с помощью таблицы sysfilesl можно выполнить следующую команду: SELECT * FROM sysfilesl

В итоге будет возвращен следующий результат: status fileid name filename

3 1 pubs ...datapubs.mdf

49218 2 pubsjog ...datapubs_log.ldf

(2 row(s) affected)

Описание групп файлов, созданных в базе данных, хранится в системной таблице sysfilegroups. Каждая строка этой таблицы соответствует одной группе. Структура этой таблицы приведена в табл.

Таблица.
Структура таблицы sysfilegroups

Имя столбца	Тип данных	Назначение
GroupID Allocpolicy Status Groupname	Smallint Smallint Ins Sysname	Идентификационный номер группы файлов Зарезервировано Текущий статус группы: 0x8— READONLY, 0x10 — Имя группы файлов	DEFAULT

Например, для получения информации о группах файлов, определенных в базе данных pubs, можно использовать следующий запрос:

SELECT * FROM sysfilegroups

Будет возвращен примерно следующий результат:

groupld allocpolicy status groupname

1 0 16 PRIMARY (1 row(s) affected)

Удаление базы данных

Для удаления базы данных используется следующая команда: DROP DATABASE databasejiame [,...n]

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

Например, для удаления баз данных Pubs и Northwind нужно выполнить следующую команду: DROP DATABASE Pubs. Northwind

Управление пользовательскими типами данных

В главе 5 в разделе «Типы данных» были рассмотрены встроенные в SQL Server 2000 типы данных. Эти типы данных всегда имеются в распоряжении пользователей и могут быть использованы для столбцов таблиц, представлений, переменных и т. д. Однако помимо встроенных типов данных пользователи могут на их основе создавать свои собственные типы данных — так называемые пользовательские типы данных.

Пользовательские типы данных
(user-defined data type) — это типы данных, создаваемые пользователями. Они создаются на основе системных типов данных. Пользовательские типы данных часто используются, когда в нескольких таблицах необходимо хранить однотипные значения, причем гарантировать, что столбцы в таблице будут иметь одинаковый размер, тип данных и чувствительность к данным NULL. Например, с помощью пользовательского типа данных можно хранить номера и серии паспорта.

Для создания пользовательского типа данных используется системная хранимая процедура sp_addtype:

sp_addtype [ @typename = ] type. [ @phystype = ] system_data_type [ . [ @nulltype = ] "null_type" ] [ , [ @owner = ] "owner name" ]

Если необходимо сделать пользовательский тип данных доступным во всех создаваемых базах данных, добавьте этот тип в базу данных model.

Здесь используются следующие аргументы.

О type — имя создаваемого типа данных. При выборе имени создаваемого типа данных необходимо следовать установленным правилам именования объектов. Имя должно быть уникальным в пределах владельца, то есть не совпадать с именами других объектов. Разные пользователи могут употреблять одинаковые имена для создаваемых объектов.

О system_data_type — системный тип данных, на основе которого создается пользовательский тип данных. Можно выбрать один из следующих типов данных:

"binary(n)" Image smalldatetime

Bit Int smallint

"char(n)" "nchar(n)" ' text

Datetime Ntext tinyint

Decimal Numeric uniqueidentifier

"decimal[(p[,s])]" "numeric[(p[,s])]" "varbinary(n)"

Float "nvarchar(n)" "varchar(n)"

"float(n)" Real

Кавычки необходимы, когда помимо самого типа данных требуется указание дополнительных параметров. Аргумент п идентифицирует длину системного типа данных в пользовательском типе данных, аргумент р — максимальное суммарное (до и после десятичной точки) количество цифр для числовых типов данных в пользовательском типе данных, аргумент s — максимальное количество десятичных цифр после запятой в пользовательском типе данных.

Нельзя создать пользовательский тип данных на основе системного типа timestamp.

О "null _type". Значение этого аргумента определяет, будет ли пользовательский тип данных хранить значения NULL Аргумент null_type имеет тип varchar(S) и может принимать одно из трех следующих значений: NULL (разрешается хранение NULL), NOT NULL (хранение NULL запрещается) или NONULL (используется значение по умолчанию). Если аргумент null_type не указывается, то при создании пользовательского типа используется значение по умолчанию, установленное для базы данных с помощью системной хранимой процедуры sp_dboption. Текущее значение, установленное в базе данных, можно получить с помощью функции GETANSINULL

Значение аргумента null_type требуется для пользовательского типа данных только как значение по умолчанию при создании столбца таблицы. Если при создании столбца явно определено свойство NULL или NOT NULL, то значение аргумента null_type игнорируется.

О "owner_name". Определяет владельца или создателя нового типа данных. По умолчанию владельцем нового типа данных считается текущий пользователь. Параметр owner_name имеет тип данных sysname.

Например, при создании пользовательских типов данных для описания номеров факса и телефона можно использовать следующий код: ЕХЕС sp_addtype telephone, "varchar(24)", "NOT NULL" EXEC sp_addtype fax, "varchar(24)", "NULL"

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

SELECT name FROM systypes

Будет возвращен следующий результат:

name

image

text

uniqueidentifier

tinyint

smallint

int

smalldatetime

real

money

datetime

float

sql_variant

ntext

bit

decimal

numeric

small money

bigint

varbinary

varchar

binary

char

timestamp

nvarchar

nchar

sysname

tid

empid

(29 row(s) affected)

Как видно, в одной таблице перечислены и встроенные, и пользовательские типы данных (i d, ti d и emi d).

Управление правилами

Правила
(rules) являются одним из средств обеспечения целостности данных, хранящихся в базе. Правила оставлены для обеспечения обратной совместимости с предыдущими версиями SQL Server. В новой версии они заменены ограничениями целостности CHECK, которые являются более мощным средством и определяются при создании таблицы. Правила же создаются как отдельные объекты, которые впоследствии связываются с конкретными полями таблиц. В этом разделе будут рассмотрены правила как самостоятельные объекты базы данных.

Для столбца таблицы можно определить только одно правило, но несколько ограничений целостности CHECK. Если для одного столбца определены ограничения целостности и правило, то будут учитываться как ограничения целостности, так и правило.

Создание правила не может выполняться в одном пакете с другими командами Transact-SQL.

Для создания правила используется следующая команда Transact-SQL: CREATE RULE rule AS condition_expression

Рассмотрим аргументы команды. О rule— имя правила. При выборе имени необходимо придерживаться общих

правил именования объектов. При необходимости можно указать имя владельца.

О condition_expression — логическое выражение, определяющее условие, накладываемое на значения. В качестве условия можно использовать любые логические команды, арифметические операторы, встроенные функции и предикаты (например IN, BETWEEN, LIKE). В выражении condition_expression нельзя ссылаться на столбцы таблиц или на любые другие объекты базы данных. Встроенные функции также не должны ссылаться на объекты базы данных. В выражении допустима одна локальная переменная, начинающаяся с символа @. В качестве имени переменной можно использовать произвольную строку. При выполнении правила переменная будет содержать значение, которое пользователь пытается ввести в столбец с помощью команды INSERT или UPDATE. Переменная может использоваться в любых логических операциях. Приведем пример создания правила: CREATE RULE rule_one AS @val>=100 AND (ava1<170 CREATE RULE rule_two AS

(Plist IN ("MATRIX". "ACC", "SIS", "KIT")

Правило может быть создано только в текущей базе данных. Само по себе правило не выполняет контроля данных. Созданное правило необходимо связать со столбцом таблицы или пользовательским типом данных. Правило не может быть связано с системным типом данных и столбцами, имеющими типы данных timestamp, text и image. При связывании правила со столбцом таблицы или пользовательским типом данных следует убедиться, что тип данных в правиле и в объекте привязки совпадают. Сервер не отслеживает соответствия типов данных при связывании. Ошибка выдается только тогда, когда пользователь изменяет значение и сервер начинает выполнение правила. Строго говоря, сервер вообще не выполняет проверки соответствия типов, он лишь констатирует ошибку при сравнении величин, имеющих несовместимый тип.

Для связывания правила со столбцом таблицы или пользовательским типом данных используется хранимая процедура sp_bindru1e со следующим синтаксисом:

sp_b1ndrule [@ru1ename =] "rule". [@objname =] "objectjname" [. [@futureonly =] "futureonlyjflag"]

Назначение параметров процедуры sp_bindrule соответствует назначению аналогичных параметров хранимой процедуры sp_bindef ault, описанной в предыдущем разделе.

Для «отвязывания» правила используется хранимая процедура sp_unbindrule: sp_unb1ndrule [@objname =] "object_name" [. [@futureonly =] "futureonly_flag"]

Для получения сведений о правиле (имени владельца и даты создания) используйте хранимую процедуру sp_hel p с указанием в качестве аргумента имени правила: sp_he1p "rule_name"

Для получения текста кода Transact-SQL, определяющего правило, используйте хранимую процедуру sp_helptext: sp_helptext "rule_name "

Для изменения имени правила используйте хранимую процедуру sp_rename: sp_rename @objname='rule_one' @newname='rule_two'

Управление умолчаниями

Умолчание
(default) — это значение, которое будет присвоено столбцу таблицы при вставке строки, если в команде вставки явно не указано значение для этого столбца.

Как и правила, умолчания оставлены в SQL Server 2000 для обеспечения обратной совместимости с предыдущими версиями продукта (до версии SQL Server 7.0). Версия SQL Server 2000 позволяет задавать умолчания для столбцов таблицы или пользовательского типа данных при их создании, используя ключевое слово DEFAULT. Применение умолчаний и правил как отдельных объектов базы данных было вызвано невозможностью изменения таблиц до версии SQL Server 7.0. Было гораздо проще создать новое правило или умолчание, чем удалять таблицу и создавать ее заново. Так как версии SQL Server 7.0 и 2000 разрешают свободно изменять структуру таблиц, то надобность в правилах и умолчаниях как отдельных объектах отпала сама собой. Поэтому, если вы еще только создаете собственную базу данных, нет необходимости использовать устаревшие конструкции, подобные правилам и умолчаниям. К тому же нет абсолютно никакой гарантии, что Microsoft будет поддерживать эти объекты в следующих реализациях SQL Server, так что при использовании правил и умолчаний перед вами рано или поздно встанет вопрос об изменении структуры базы данных.

Сейчас мы рассматриваем умолчания, которые существуют в базе данных как самостоятельные объекты. Умолчания предоставляют удобный способ быстро назначать одинаковые значения по умолчанию множеству столбцов таблиц базы данных. Тем не менее задавать значения по умолчанию для столбцов рекомендуется, используя синтаксис команд CREATE TABLE и ALTER TABLE.

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

Для создания умолчания используется следующая команда: CREATE DEFAULT default AS constant_expression

Здесь default— имя умолчания, a constant_express1on — его значение.

При выборе имени умолчания следует придерживаться установленных правил именования объектов. Кроме того, имя умолчания должно быть уникально для каждого владельца. Указание имени владельца умолчания при его создании не обязательно.

В качестве значения constant_expression можно использовать не только константы, но и любые математические выражения и встроенные функции. Строки символов и даты должны заключаться в одиночные кавычки. Перед бинарными данными должен указываться префикс Ох, а перед денежным типом — символ $. Если размер значения по умолчанию превышает размер, заданный для данных в столбце, выполняется усечение значения по умолчанию до требуемого размера.

Приведем пример создания текстового умолчания: CREATE DEFAULT default one AS "RIAC Industries"

Создание умолчания не может выполняться в одном пакете с другими командами Transact-SQL.

Умолчание может быть создано только в текущей базе данных. После того как умолчание создано, его можно связать со столбцом таблицы или пользовательским типом данных. Для связывания умолчания с объектом базы данных используется хранимая процедура sp_bindefault, имеющая следующий синтаксис:

sp_bindefault [@defname =] "default",

[(Pobjname =] "objectjiame"

[. [@future]only =] "futureonly_flag"]

Здесь используются следующие аргументы.

О "default" — имя умолчания. Это имя, указанное при создании умолчания в команде CREATE DEFAULT.

О "object_name" — имя объекта, к которому привязывается умолчание. Для связывания умолчания со столбцом таблицы имя объекта указывается в форме col umn. tab! e. Если же используется другая форма имени, то считается, что умолчание связывается с пользовательским типом данных. Умолчание не может быть связано со столбцом типа timestamp, столбцом с установленным ограничением целостности IDENTITY или со столбцом, связанным с другим умолчанием. В последнем случае необходимо отвязать
от столбца старое умолчание, а уже затем привязывать новое. Если умолчание связывается со столбцом, имеющим пользовательский тип данных, и с этим типом данных связано другое умолчание, то умолчание, определенное для столбца, имеет приоритет над умолчанием, установленным для пользовательского типа данных. Если в имени объекта присутствуют недопустимые символы, то в аргументе ob ject_name необходимо использовать разделители [ и ] для указания имени объекта.

О "futureonly_flag" — этот аргумент требуется только при связывании умолчания с пользовательским типом данных и не нужен при связывании со столб-

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

ЕХЕС sp_b1ndefault "default_one",

"[employes 013].[company name]"

Пример связывания умолчания с пользовательским типом данных:

ЕХЕС sp_bindefault "default_one".

"emp_data". "futureonly"

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

Когда умолчание связывается со столбцом таблицы, информация о связывании сохраняется в системной таблице базы данных syscolumns. При связывании умолчания с пользовательским типом данных информация сохраняется в таблице systypes.

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

При вставке новой строки без указания значений для столбцов этим столбцам присваивается либо значение по умолчанию (если таковое определено), либо значение NULL (если для столбца разрешено хранение значений NULL). Если для столбца не определено значение по умолчанию и запрещено хранение значений NULL, то при вставке пустой строки сервер выдаст сообщение об ошибке. Если для столбца разрешено хранение значений NULL и установлено значение по умолчанию, то при вставке пустой строки значение по умолчанию будет иметь приоритет над значением NULL.

Для удаления умолчания из базы данных используется следующая команда: DROP DEFAULT {default} [,...n]

Здесь аргумент default определяет имя умолчания, которое необходимо удалить. Используя одну команду DROP DEFAULT, можно удалить несколько умолчаний. Для этого необходимо перечислить их через запятую.

Нельзя удалить умолчание, связанное со столбцом таблицы или пользовательским типом данных. Перед удалением необходимо отвязать умолчание от всех объектов, а уже затем выполнять команду DROP DEFAULT. Для отвязывания умолчания используется хранимая процедура sp_unbindefault со следующим синтаксисом:

sp_unbindefault [@objname =] "object_name"

[, [@futureonlу =] "futureonly_flag"]

Здесь используются следующие аргументы.

О "object_name" — имя столбца таблицы или пользовательского типа данных, от которых необходимо отвязать умолчание. Когда умолчание отвязывается от пользовательского типа данных, оно автоматически отвязывается ото всех столбцов, имеющих этот тип данных, если только умолчание не было связано с этими столбцами явно и в команде не указан аргумент "futureonly".

О " f utureonl y_f 1 ag" — указывается только для пользовательских типов данных. Если этот аргумент имеет значение "futureonly", то умолчание не отвязывается от столбцов, имеющих пользовательский тип данных. Если этот аргумент отсутствует, сервер автоматически отвяжет умолчание от всех столбцов. Для получения сведений о представлении (имени владельца и даты создания) используйте хранимую процедуру sp_help с указанием в качестве аргумента имени умолчания: spjielp "default_one"

Для получения текста кода Transact-SQL, определяющего умолчание, используйте хранимую процедуру sp_helptext: sp_helptext "default_one"

Для изменения имени умолчания используйте хранимую процедуру sp_rename: sp_rename @objname='defaul t_one' @newname='default_two'

Список литературы

Мамаев Е., Шкарина Л. «Microsoft SQl Server 2000 для профессионалов».-СПб:Питер, 2001
Хоторн Роб «Разработка баз данных, Micrososoft SQL Server 2000».-Вильямс, 2001
Шарон Б., Мэйбл Грэг «Sql Server 2000, Энциклопедия программиста».-ДиаСофт, 2001

Слов:	33869
Символов:	275952
Размер:	538.97 Кб.

Название реферата: SQL Server 2000