SQL Server 2000

Содержание


Лекция 1. Обзор Microsoft SQL Server

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

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

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

Системы SQL Server

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

Клиент-серверная система SQL Server

Клиент-серверная система SQL Server может иметь двухзвенную установку (two-tier setup) либо трехзвенную установку (three-tier setup). Независимо от варианта установки, программное обеспечение и базы данных SQL Server размещаются на центральном компьютере, который называется сервер базы данных (database server). Пользователи работают на отдельных компьютерах, которые называются клиенты (clients). Доступ пользователей к серверу базы данных производится при помощи приложений с их компьютеров-клиентов (в двухзвенных системах) либо при помощи приложений, выполняющихся на специально предназначенном для этой цели компьютере, который называется сервер приложений (application server) (в трехзвенных системах).

В частности, в двухзвенных системах клиенты исполняют приложения, осуществляющие доступ к серверу базы данных непосредственно через сеть. Таким образом, компьютеры-клиенты исполняют программный код, соответствующий нуждам предприятия, и код, отображающий для пользователя результаты доступа к базе данных. Такие клиенты называются толстыми (thick client), потому что они выполняют два вида работы (cм. рис. 1.1).Двухзвенная установка полезна при относительно небольшом количестве пользователей, потому что для соединения с каждым из пользователей расходуются системные ресурсы, такие как память и блокировки (locks). Чем больше будет количество соединений с пользователями, тем хуже будет производительность системы, из-за соперничества за ресурсы. В этих условиях вас может заинтересовать применение трехзвенной системы.

Двухзвенная клиент-серверная система


Рис. 1.1.  Двухзвенная клиент-серверная система

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

Достоинством трехзвенной системы является то, что можно позволить серверу приложений организовывать все клиентские соединения с сервером базы данных, вместо того, чтобы разрешить каждому клиенту самостоятельно устанавливать соединения (такая самостоятельность может привести к нерациональному использованию ресурсов сервера базы данных). Этот подход называется организация пула соединений (connection pooling), при этом предполагается, что запросы клиентов помещаются в пул (или, говоря точно, в очередь, queue), в котором они будут дожидаться ближайшего доступного соединения. Сразу же по освобождении соединения, оно может использоваться для нужд следующего запроса из очереди. Организация пулов соединений позволяет в некоторой степени регулировать объем работы, выполняемой сервером базы данных, конфигурируя количество соединений, имеющихся в пуле и, следовательно, количество соединений, доступных для выполнения задач пользователей. (Количество соединений можно конфигурировать программно.) Так можно избавиться от потребности в большом количестве пользовательских соединений, способных быстро израсходовать ресурсы и замедлить скорость работы. Организация пулов соединений может быть реализована при помощи Internet Information Server (продукта фирмы Microsoft) и программного обеспечения для организации пулов соединений, вроде COM+, являющегося службой компонент, поставляемой вместе с операционной системой Microsoft Windows 2000. Мы не станем углубляться в подробности использования этих продуктов, поскольку программирование приложений выходит за рамки нашего курса.

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

 Трехзвенная клиент-серверная система


Рис. 1.2.  Трехзвенная клиент-серверная система

Настольная система

SQL Server может использоваться также и как автономный (stand-alone) сервер базы данных, работающий на настольном или на портативном компьютере. Мы будем называть такие конфигурации настольными системами (desktop system). В них клиентские приложения исполняются на том же компьютере, на котором хранится программное обеспечение, реализующее механизм работы SQL Server и базы данных. В данной системе применяется только один компьютер, поэтому не устанавливаются никакие сетевые соединения от клиента к серверу – клиент устанавливает локальное соединение со своей локальной установкой SQL Server.

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

Новые функциональные возможности и усовершенствования, появившиеся в SQL Server 2000

SQL Server 2000 имеет столько новых функциональных возможностей, что мы сможем рассказать здесь лишь о некоторых новшествах. Благодаря им облегчается применение и администрирование SQL Server, повышается производительность работы SQL Server, так что SQL Server стала прекрасной платформой не только для мелкомасштабных приложений оперативной обработки транзакций (OLTP-приложений, on-line trАnsaction processing applications), но и для крупномасштабных OLTP-приложений, для организации информационных хранилищ (data warehousing) и приложений для электронной коммерции. В данном разделе описаны некоторые из наиболее интересных новых функциональных возможностей SQL Server 2000, рассказано о других улучшениях в SQL Server и даны ссылки на источники дополнительной информации об этом.

Улучшения сервера

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

Поддержка расширенной памяти

SQL Server 2000 Enterprise Edition может пользоваться API (интерфейсом прикладного программирования, Application Programming Interface) Windows 2000 Address Windowing Extensions (AWE) для поддержки больших адресных пространств. На серверах под управлением Windows 2000 AdvАnced Server SQL Server поддерживает память до 8 Гб, а на серверах под управлением Windows 2000 Datacenter – до 64 Гб. Поддержка AWE имеется только в этих двух операционных системах, ни Windows 2000 Professional, ни Windows 2000 Server не поддерживают AWE. Кроме того, для того, чтобы использовать AWE, применяется новый параметр конфигурации SQL Server – awe enabled.

Дополнительная информация. Для дополнительной информации смотрите "awe enabled Option" в Books Online.
Многократные экземпляры SQL Server

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

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

Распределенные расчлененные представления

Распределенные расчлененные представления (distributed partitioned views) – это замечательная новая функциональная возможность SQL Server 2000, очень ценная для систем баз данных и веб-сайтов, требующих вычислительной мощи нескольких серверов, необходимой для поддержки нагрузки интенсивных транзакций. При помощи этой функциональной возможности вы можете осуществлять горизонтальное расчленение таблиц по нескольким компьютерам, на которых работает SQL Server и создавать представления (views, термин views переводится как"представления","виды" и"виртуальные таблицы"), охватывающие все серверы-члены. Благодаря представлениям создается впечатление, как будто бы на каждом сервере имеется полная копия таблицы. Приложения могут ссылаться на представления и не обязаны знать о том, на каком из серверов-членов хранятся данные.

Дополнительная информация. Чтобы ознакомиться с дополнительными подробностями и получить общие рекомендации, смотрите "Creating a Partitioned View" в Books Online.
Кластеризация для обеспечения отказоустойчивости

В SQL Server 2000 были значительно улучшены средства администрирования кластеризацией для обеспечения отказоустойчивости (failover-clustering administration). Начальная установка отказоустойчивости выполняется теперь не в мастере Failover Cluster Wizard, а стала частью процесса начальной установки SQL Server. В SQL Server 2000, по сравнению с предыдущими версиями, кластеризация для обеспечения отказоустойчивости стала проще в инсталляции, конфигурировании и администрировании. Вот перечень некоторых из задач администрирования, которые вы сможете выполнять:

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

Поддержка XML

Язык XML (Extensible Markup LАnguage) – это стандарт Консорциума WWW (W3C, World Wide Web Consortium) для представления информации в форме структурированных документов, пригодной для транспортировки данных между разнородными системами. В SQL Server 2000 имеются новые средства для поддержки функциональности XML. В основном вы можете применять XML для доступа к SQL Server при помощи протокола HTTP через URL. Имеются следующие новые функциональные возможности поддержки XML.

О применении XML для доступа к SQL Server см. лекцию 23. В этой же лекции вы изучите некоторые вопросы программирования, имеющие отношение к Интернету.

Операции по поддержке базы данных

К усовершенствованиям SQL Server 2000 относится то, что для некоторых операций поддержки базы данных, выполняемых администраторами, повысилась скорость их исполнения и улучшилось удобство работы. К этим усовершенствованиям относятся повышение скорости дифференциального (разностного) резервного копирования (differential backup), параллельные проверки согласованности базы данных (DBCC, database consistency checks) и параллельное сканирование с проверкой согласованности базы данных (DBCC). Дифференциальные (разностные) резервные копирования теперь могут производиться за время, пропорциональное объему данных, измененных с момента последнего резервного копирования базы данных. DBCC теперь может пользоваться достоинствами многопроцессорных вычислительных систем, работая параллельно сразу на нескольких процессорах, что повышает производительность (скорость работы) DBCC. DBCC при сканировании таблиц теперь работает без блокировки разделяемых таблиц, благодаря чему обновления могут производиться одновременно с задачами DBCC.

Целостность ссылочных данных

При помощи двух новых предложений – ON UPDATE и ON DELETE – вы можете задать поведение SQL Server при изменении колонки в таблице, на которую ссылается внешний ключ (foreign key) в другой таблице. Предложения ON UPDATE и ON DELETE могут применяться в операторах CREATE TABLE и ALTER TABLE. Эти предложения имеют опции CASCADING и NO ACTION. CASCADING с ON DELETE означает, что если из указываемой (родительской) таблицы удаляется ряд, то это удаление будет "каскадным", окажет также воздействие и на таблицу внешних ключей. Аналогично, CASCADING с ON UPDATE означает, что обновление, применяемое к указываемой колонке данных в родительской таблице, будет применяться "каскадом", так что таблица внешних ключей будет обновляться таким же образом. Если с ON DELETE или с ON UPDATE применяется опция NO ACTION , то, если в родительской таблице указываемая строка удалена или указываемая колонка обновлена, SQL Server вернет сообщение об ошибке, а удаление или обновление "откатится назад".

Дополнительная информация. Описание синтаксиса и другие подробности об этих предложениях имеются в "CREATE TABLE" и "ALTER TABLE" в Books Online.
Полнотекстовый поиск

В SQL Server 2000 появились две новые возможности, улучшающие функциональность полнотекстового поиска: отслеживание изменений (chАnge tracking) и фильтрация изображений (image filtering). Отслеживание изменений сохраняет журнал всех изменений, произведенных с полнотекстовыми индексированными данными, а на основе записи этих изменений можно обновлять индекс. Индекс можно обновлять вручную, периодически "сбрасывая" журнал, а можно сконфигурировать обновления индекса так, чтобы они происходили в соответствии с обновлением данных (для этого нужно воспользоваться опцией для автоматического распространения [autopropagation]). Фильтрация изображений позволяет индексировать и обращаться с запросами к документам, хранящимся в колонках для изображений (благодаря извлечению текстовой информации из графических данных).

Дополнительная информация.Дополнительная информация о полнотекстовом поиске имеется в "Microsoft Search Service" в Books Online.
Новые типы данных

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

В SQL Server имеется много других типов данных. (См. раздел "Применение системных типов данных" в лекции 10.)

Улучшения для индексирования

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

Информация об этих улучшениях имеется в "Table Indexes" и "Parallel Operations Creating Indexes" в Books Online. (Об индексах см. лекцию 17.)

Улучшения для администрирования

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

Пересылка журнала

При помощи пересылки журнала (log shipping) вы можете непрерывно "сбрасывать" и копировать резервные копии журнала транзакций с исходного сервера на целевой сервер (или серверы), а затем автоматически загружать эти журналы на целевом сервере (или серверах). Таким образом, вы получаете "теплый резерв" (warm standby) базы данных и отдельную, предназначенную только для чтения систему для выполнения таких запросов, как деловые отчеты, чтобы убрать подобную деятельность с целевого сервера. Вы можете сконфигурировать расписание для каждого шага, в том числе сконфигурировать задержки между копированием и загрузкой резервных копий журналов.

Дополнительная информация. Для дополнительной информации об этом смотрите "Log Shipping" в Books Online.
PerformАnce Аnalyzer

В Enterprise MАnager появилось новое инструментальное средство – PerformАnce Аnalyzer (Анализатор производительности). PerformАnce Аnalyzer имеется в папке MАnagement каждого из серверов. Это средство служит для сбора данных о производительности для отдельной базы данных или для всех баз данных. Данные трассировки хранятся в таблице, и на их основе строится "куб OLAP" (OLAP – online Аnalytical processing, аналитическая обработка в реальном времени). Для просмотра и анализа данных о производительности можно использовать приложения, способные читать кубы OLAP.

Дополнительная информация.Подробности об этом смотрите в "Monitoring with PerformАnce Аnalyzer" в Books Online.
SQL Server Profiler

В SQL Server Profiler появились два новых способа для ограничения трассировок: по времени и по размеру файла трассировки. Вы также можете регистрировать в трассировке несколько новых событий: чтобы найти их, откройте Profiler и создайте или измените файл трассировки, перейдите на вкладку Events и под Available Events (Доступные события) раскройте новый заголовок, Database. Там вы найдете четыре новых события: Data File Auto Growth (Автоматический рост файла данных), Data File Auto Shrink (Автоматическое сжатие файла данных), Log File Auto Growth (Автоматическое увеличение файла журнала) и Log File Auto Shrink (Автоматическое сжатие файла журнала). Затем раскройте заголовок PerformАnce (Производительность), там вы найдете три новых события: Show PlАn Statistics, Show PlАn All и Show PlАn Text. (Об использовании Profiler см. лекцию 35.)

SQL Server Query Аnalyzer

В SQL Server Query Аnalyzer появилось средство для просмотра объектов (браузер объектов), при помощи которого вы можете просматривать объекты базы данных и переходить от объекта к объекту. Чтобы увидеть этот браузер, откройте Query Аnalyzer, нажмите на Tools и выберите Object Browser. (К новшествам относится и все меню Tools.) Браузер появится в левой части окна Query Аnalyzer. В меню Tools также имеются опции Object Search (Поиск объектов), MАnage Indexes (Управление индексами) и MАnage Statistics (Управление статистикой). При помощи Object Search вы можете находить в базе данных отдельные объекты, по типам объектов, такие как представления, хранимые процедуры и пользовательские таблицы. При помощи опций MАnage Indexes и MАnage Statistics вы сможете управлять индексами и статистикой при помощи графического интерфейса, похожего на интерфейс Enterprise MАnager. Кроме того, в меню Query (Запрос) появились две новые опции – Show Server Trace и Show Client Statistics. (Об использовании Query Аnalyzer см. лекцию 35.)

Улучшения репликации

В SQL Server 2000 появились несколько улучшений репликации. Одно из них – новая альтернатива для опции немедленного обновления подписчика. Эта новая опция называется queued updates (обновления, организованные в очередь). Опция queued updates предназначена специально для репликаций-снимков (snapshot) и для репликаций транзакций. Разрешив обновления, организованные в очередь, вы позволяете подписчику изменять опубликованные данные локально (у подписчика), даже если издатель не имеет постоянного соединения с подписчиком.

Дополнительная информация. Смотрите "Queued Updating components" в Books Online.

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

Появились и новые улучшения для репликации слиянием:

О репликации слиянием см. лекцию 28.

Другие улучшения

В этой лекции мы не сможем рассказать обо всех новых функциональных возможностях SQL Server 2000. Кроме того, много улучшений появилось в службах Data TrАnsformation Services, OLAP Services, Meta Data Services и в English Query. Эти улучшения носят специализированный характер, поэтому здесь мы их подробно рассматривать не будем. Информацию об этом вы найдете в следующих темах Books Online:

Заключение

SQL Server 2000 – это реляционная система управления базой данных (СУБД), обладающая многими функциональными возможностями, при помощи которых вы можете сконфигурировать свою систему так, чтобы она соответствовала потребностям вашего бизнеса; она годится и для малых предприятий, и для корпораций, и для предприятий электронной коммерции. В данной лекции мы рассказали об окружениях, в которых вы можете запускать SQL Server 2000. Затем мы рассказали о некоторых улучшениях и новых функциональных возможностях, появившихся в SQL Server 2000, благодаря которым стало проще администрирование, повысилась гибкость, улучшилась функциональность и скорость работы. Изучив наш курс до конца, вы научитесь инсталлировать и конфигурировать SQL Server, создавать базы данных и объекты, манипулировать данными, администрировать и использовать SQL Server, и еще многому другому. Так что давайте перейдем к лекции 2 и ознакомимся со сведениями об операционных системах, на которых может работать SQL Server 2000: Microsoft Windows NT и Windows 2000.

Лекция 2. Платформа Microsoft Windows 2000

SQL Server 2000 проектировалась для платформы Windows 2000, обеспечивая тем самым высокий уровень надежности, защищенности, повышенную степень комфорта и функциональности. Операционная система Windows 2000 выпускается в 4 редакциях, что позволяет подобрать требуемую функциональность для конкретных нужд СУБД. Проводится краткий обзор каждой версии (редакции) и их сравнительный анализ. Выделены ключевые новшества Windows 2000, такие как надежность, безопасность, удобство в применении, системное администрирование, производительность. Рассматривается служба каталогов Active Directory, ее архитектура, концепция, функциональность.

В феврале 2000 года Microsoft представила публике семейство операционных систем Microsoft Windows 2000. Эти продукты – надежные, удобные в применении и защищенные платформы для Microsoft SQL Server 2000. Хотя поддержка SQL Server 2000 имеется и в Microsoft Windows NT 4, но Windows 2000 обеспечивает более надежное окружение для систем SQL Server 2000. Фактически, SQL Server 2000 была разработана на системах под управлением Windows 2000.

Семейство Windows 2000

Windows 2000 выпускается в "редакциях" (версиях): Windows 2000 Professional, Windows 2000 Server, Windows 2000 AdvАnced Server и Windows 2000 DataСenter Server. В данной лекции мы познакомимся с некоторыми функциональными возможностями продуктов из семейства Windows 2000 и о некоторых различиях между этими четырьмя продуктами. Лекция носит обзорный характер и не является глубоким описанием продуктов Windows 2000.

Дополнительная информация.Более подробную информацию о Windows 2000 можно получить, посетив сайт Microsoft,http://www.microsoft.com/windows2000
Windows 2000 Professional

Windows 2000 Professional – это новая операционная система для корпоративных настольных и портативных компьютеров. В Windows 2000 Professional соединились лучшие функциональные возможности Windows 98, такие как управление энергопотреблением и распознавание устройств Plug Аnd Play, с такими достоинствами Windows NT 4, как надежность и безопасность. Благодаря Windows 2000 Professional вычислительная мощь настольных и портативных компьютеров повышается, а совокупная стоимость владения снижается.

Windows 2000 Server

Операционная система Windows 2000 Server построена на основе Windows NT 4. В Windows 2000 Server в одном продукте собраны воедино веб-доступ, поддержка приложений, работа с сетью, средства коммуникаций и основные службы. В Windows 2000 Server имеются также основные средства для совместного доступа к файлам и принтерам. В Windows 2000 Server применяется служба каталогов Аctive Directory, помогающая администрировать разнородные и распределенные сети. Мы рассмотрим Аctive Directory далее в данной лекции.

Windows 2000 AdvАnced Server

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

Windows 2000 DataCenter Server

Windows 2000 DataCenter Server – это специализированный продукт из семейства Windows 2000 Server. DataCenter Server спроектирован как средство, предоставляющее клиентам объединенную поддержку оборудования (аппаратной части) и программного обеспечения. Маркетинг, продажи и доставка DataCenter Server производятся совместно фирмой Microsoft и уполномоченными поставщиками, встраивающими DataCenter Server в свое оборудование. Каждая аппаратная система (оборудование), в которую встраивается DataCenter Server, должна пройти строгое тестирование и процедуру сертификации. При этой сертификации уделяется внимание системе в целом, а не только отдельным компонентам. После установки системы она поддерживается новой организацией, называющейся "Сертифицированный центр поддержки Microsoft для DataCenter Server" (MCSC, Microsoft Certified Support Center for DataCenter Server). Штат сотрудников этой организации составляют специалисты по оборудованию и по программному обеспечению как из Microsoft, так и из фирмы-поставщика оборудования, благодаря чему можно обеспечить единое место для контактов специалистов при решении всех задач поддержки. Сертифицированные центры поддержки предоставляют следующие услуги потребителям систем DataCenter Server:

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

Различия между продуктами семейства Windows 2000

Различия между продуктами семейства Windows 2000 перечисленны в табл. 2.1.

Таблица 2.1. Продукты Windows 2000
Windows 2000 ProfessionalWindows 2000 ServerWindows 2000 Advanced ServerWindows 2000 Datacenter Server
НазначениеОперационная система-клиент для настольных и портативных компьютеров в организацияхСерверная операционная система, служащая для организации работы с файлами, с принтерами, для работы во внутренних сетях и другой сетевой работыСерверная операционная система с поддержкой приложений и служб для электронной коммерцииСерверная операционная система, обеспечивающая специализированную поддержку для больших, критически важных, приложений
Количество поддерживаемых центральных процессоров24832
Поддерживаемая память4 Гб4 Гб8 Гб64 Гб
КластеризацияНетНетДвухузловой переход при отказе (two-node failover)Четырехузловой переход при отказе
Минимальные системные требования Pentium-совместимый процессор с частотой 133 МГц, оперативная память 64 Мб, место на диске 1 ГбPentium-совместимый процессор с частотой 133 МГц, оперативная память 256 Мб, место на диске 1 Гб32-узловое балансирование сетевой нагрузки (Network Load Balancing)

Pentium-совместимый процессор с частотой 133 МГц, оперативная память 256 Мб, место на диске 1 Гб

32-узловое балансирование сетевой нагрузки (Network Load Balancing)

Pentium-совместимый процессор с частотой 133 МГц, оперативная память 256 Мб, место на диске 1 Гб

Компоненты и функциональные возможности Windows 2000

А теперь, получив основное представление о семействе продуктов Windows 2000, давайте сосредоточимся на функциональных возможностях Windows 2000. Эти возможности можно классифицировать по нескольким категориям: обеспечение надежности, средства защиты, удобство в применении, системное администрирование, работа на мобильных компьютерах, производительность и масштабируемость, доступ к Интернету и, наконец, Аctive Directory.

Надежность

В Windows 2000 имеется множество средств для увеличения надежности вашей системы. Давайте рассмотрим некоторые наиболее важные средства из этой категории:

Безопасность (средства защиты)

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

Удобство в применении

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

Системное администрирование и развертывание

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

Система, учитывающая особенности мобильной работы

Windows 2000 Professional с самого начала создавалась как система, помогающая пользователям портативных компьютеров (ноутбуков) и способствующая работе на ноутбуках. Хотя на ноутбуках смогут работать и другие операционные системы из семейства Windows 2000, но в них не имеется средств управления энергопотреблением и функциональных возможностей для работы в автономном режиме (offline), имеющихся в Windows 2000 Professional. Применение Windows 2000 Professional может быть желательным, потому что в ней имеются следующие функциональные возможности:

Производительность

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

Доступ к Интернету

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

Служба каталогов Аctive Directory

Служба каталогов Аctive Directory является новой функциональной возможностью Windows 2000 Server, это – центральная компонента для управления данными и ресурсами в сетях Windows 2000. В этом разделе дан обзор технологии Аctive Directory.

Архитектура Аctive Directory

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

Аctive Directory является одновременно и административным, и пользовательским инструментальным средством. Аctive Directory обеспечивает единообразное взаимодействие пользователей с разнообразными и широко рассеянными по сети ресурсами и доступ к ним. Пользователям больше не надо заботиться об определении местоположения сетевых ресурсов и об их именах. При помощи Аctive Directory ресурсы "рекламируются" ("advertised") для пользователей, имеющих право на доступ к ним. Такая "реклама" ресурсов производится при помощи мастера Add/Remove Programs Wizard или мастера Add/Remove Printers Wizard.

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

Аctive Directory является "единой точкой" для управления всеми пользовательскими учетными записями Windows, компьютерами-клиентами, компьютерами-серверами и приложениями. Аctive Directory также помогает организовывать и интегрировать системы под управлением не Windows. При помощи Аctive Directory организации могут распространять свои системы в Интернет, причем с обеспечением защиты на высоком уровне.

Аctive Directory основывается на иерархической структуре (см. рис. 2.12). Объекты применяются для обозначения пользователей, групп пользователей, систем, устройств, приложений и других сущностей в сети. Объекты хранятся в контейнерах, которые применяются для обозначения организаций, например, "юридический отдел", или совокупностей взаимосвязанных объектов, например, принтеров.

Иерархия Аctive Directory


Рис. 2.12.  Иерархия Аctive Directory

Аctive Directory также управляет взаимоотношениями между различными объектами и контейнерами. Благодаря этому системные администраторы могут видеть всю сеть скорее как согласованные сущности, а не как ресурсы в одном месте и взаимоотношения между ресурсами – в другом месте.

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

Чтобы отвечать требованиям высокой производительности, доступности и гибкости, Аctive Directory применяет репликацию с множественными контроллерами-хозяевами (multimaster replication). Администраторы могут создать многие копии каталога Аctive Directory, называющиеся "реплики каталога" и разместить их по разным местам из сети. Когда изменение применяется к любой какой-нибудь реплике каталога где-нибудь в сети, то это изменение автоматически реплицируется (копируется) по всей сети.

Польза от применения Аctive Directory

Мы уже сказали, что Аctive Directory упрощает управление, повышает защищенность сети и улучшает функциональную совместимость сетей. Давайте более подробно рассмотрим эти улучшения.

Аctive Directory упрощает управление

Современные сети зачастую охватывают большие географические зоны. Управление этими неоднородными и обширными сетями стало требовать больших затрат времени. Кроме того, поскольку сети сейчас распространяются на значительные расстояния (в географическом смысле), то административные функции часто дублируются в нескольких местах, что приводит к избыточности и несогласованности. А вот Аctive Directory становится "единой точкой" для управления разнообразными ресурсами сети.

Аctive Directory также помогает развертывать приложения и другое программное обеспечение на компьютеры пользователей. Раньше техникам приходилось подходить к каждой рабочей станции, нуждавшейся в добавлении программного обеспечения. Этот процесс был дорогостоящим и занимал много времени. Затем были разработаны средства, позволявшие развертывать приложения с центрального сервера. Хотя эта методика и была шагом вперед, но ей не хватало интегрированности, встроенности в общий процесс управления сетью. А при помощи Аctive Directory системные администраторы могут развертывать программное обеспечение, не выходя из существующих рамок организации безопасности и практики управления, что снимает хлопоты по применению "одиночных" инструментальных средств для развертывания и управления.

При помощи Аctive Directory администраторы, когда это бывает нужным, могут делегировать некоторые административные функции пользователям или подразделениям. Благодаря такому процессу "безопасного делегирования" можно позволить таким "продвинутым пользователям" проявлять свою компьютерную квалификацию в рамках своего отдела, освобождая профессионалов-компьютерщиков для других дел.

Аctive Directory повышает защищенность

Критически важными компонентами Аctive Directory являются ее службы безопасности. В Аctive Directory собраны данные для аутентификации пользователей и данные для администрирования. Аctive Directory реализует ролевую модель безопасности: пользователи и организации получают предварительно заданные роли (roles), которые, однако, можно редактировать, аспекты безопасности (security aspects) и правила (rules). Администраторы могут пожелать включить для некоторых пользователей или ресурсов строгие правила безопасности или же ослабить защиту, когда это имеет смысл. Модель безопасности, применяемая в Аctive Directory, поддерживает такие протоколы защиты, как Kerberos, сертификаты X.509 и технологию работы со смарт-картами. Эта модель безопасности также обеспечивает согласованную единообразную защиту как для локально подключенных к сети пользователей, так и для соединившихся через удаленное коммутируемое соединение.

Аctive Directory расширяет функциональную совместимость сетей

По мере того как происходило развитие сетей, вместе с ними развивались и сетевые технологии. Чтобы максимизировать отдачу от вложений в разработку и развертывание этих технологий, они должны работать совместно. Сейчас в окружениях большинства сетей имеются собрания разнородных несогласованных каталогов для электронной почты, приложений, сетевых устройств, брандмауэров для Интернета и внутренних сетей и приложения для электронной коммерции. Аctive Directory поможет навести порядок в этом разнообразии, задавая набор стандартных интерфейсов для интегрирования приложений и набор открытых механизмов синхронизации, гарантирующих возможность активной функциональной совместимости компонент операционной системы Windows с большим количеством устройств и приложений для других операционных систем (не Windows).

Заключение

В данной лекции мы кратко рассмотрели операционные системы семейства Windows 2000. Каждая операционная система из этого семейства (Windows 2000 Professional, Windows 2000 Server, Windows 2000 AdvАnced Server и Windows 2000 DataCenter Server) имеет специализированные функциональные возможности, призванные соответствовать множеству потребностей пользователей. Благодаря Windows 2000 вы можете иметь одинаковые окружения на ноутбуках и на высокопроизводительных 32-процессорных информационных центрах корпораций. Прочитав эту лекцию, вы без труда сможете выбрать подходящую платформу Windows 2000 для своей установки SQL Server 2000. В следующей лекции мы вернемся к SQL Server 2000 и познакомим вас с некоторыми обязанностями администратора базы данных.

Лекция 3. Что делают и за что отвечают администраторы баз данных Microsoft SQL Server

Администраторы баз данных SQL Server могут иметь самые разнообразные обязанности по конфигурированию оборудования, инсталляции систем, настройки аппаратного и программного обеспечений, безопасности, работы сети. Дается характеристика инструментальных средств для мониторинга системы: System Monitor, SQL Server Enterprise Manager, SMS и других. Анализируются методы работы администраторов баз данных: работа с коллективом, помощь, отдых, настройка системы.

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

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

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

Основные и дополнительные обязанности администратора баз данных SQL Server 2000

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

Инсталляция и конфигурирование

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

Инсталляция программного обеспечения

Администраторы баз данных должны участвовать не только в инсталляциях SQL Server, но и в инсталляциях Microsoft Windows 2000 и другого программного обеспечения. Вы должны проверять, чтобы опции были установлены правильно, а ненужные компоненты не были инсталлированы и сконфигурированы. Во время инсталляции Windows 2000 можно ненароком наустанавливать множество нежелательных компонент. Такие компоненты, как Internet Information Server (IIS), сервер протокола DHCP (Dynamic Host Configuration Protocol), Message Queuing и службы для доступа к файлам и принтерам являются слишком большой нагрузкой для системы, и особенно надо учитывать, что они могут никогда не понадобиться.

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

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

Конфигурирование аппаратуры и программного обеспечения

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

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

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

Безопасность

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

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

Защита сети

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

Аудит системы

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

Как уже говорилось, вы можете организовать аудит своей системы при помощи SQL Server Profiler. Можно создать профили, регистрирующие, например, такие события, как неуспешные попытки входа в систему. Кроме того, вы можете регистрировать такие события, как операторы языка описания данных ( DDL, data definition language ) и операторы INSERT, UPDATE и DELETE. Пользуясь SQL Server Profiler, вы сможете отслеживать определенные события, а также следить за временем входов в систему, за именами пользователей и за деятельностью.

Обычная работа

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

Резервное копирование и восстановление

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

Управление пользователями

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

Прочая обычная работа

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

Уровень качества обслуживания

Нужно следить, чтобы система обеспечивала определенный уровень качества обслуживания для важных задач. Этот уровень качества обслуживания, который должна обеспечивать ваша система, может определяться соглашением об уровне обслуживания (SLA, service level agreement). Даже если нет никакого контракта, все равно администратор баз данных должен обеспечивать наилучший уровень обслуживания. Этого можно добиться, стремясь к максимально большему времени работоспособности системы и к максимальной производительности, настраивая производительность и планируя мощность.

Мониторинг и настройки производительности

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

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

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

Состав системы и планирование мощности

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

Обеспечение периодов работоспособности системы

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

Планирование периодов неработоспособности

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

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

Восстановление после аварий

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

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

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

Документирование

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

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

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

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

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

Документация о конфигурации

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

Системный журнал

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

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

Документация о структуре системы

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

Планы обычного технического обслуживания

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

Планы восстановления после аварий

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

Чтобы написать план восстановления после аварий, вы должны проанализировать технические требования для периода работы системы и риск для системы. Для малых систем, для которых не требуется почти постоянная круглосуточная работа, там, где в случае серьезных отказов допустим некоторый нерабочий период, можно обойтись обычным резервным копированием и все восстановление будет основываться лишь на комплекте магнитных лент для восстановления. Те же системы, для которых требуется более надежное обеспечение непрерывной работы, нуждаются в решениях с большей отказоустойчивостью (например, можно запустить службы MSCS – Microsoft Cluster Services ). Для систем, простой которых стоит миллионы долларов в день, вы должны реализовать более объемлющие решения. Эти решения обычно подразумевают создание резервного (failover) сайта в другом географическом регионе страны, благодаря чему работа не прекратится даже в случае природной катастрофы. Резервные сайты могут обеспечивать работоспособность даже при выходе из строя основного центра обработки данных на дни и недели. Такие типы чрезвычайных планов документироваться должны тщательно, чтобы каждый техник смог осуществить перенос работы на резервный сервер.

Проектирование и разработка

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

Создание модели данных и анализ

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

Проектирование базы данных

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

Разработка хранимых процедур

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

Разработка приложений

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

Информационная помощь другим сотрудникам

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

Прочие обязанности администратора баз данных

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

Администрирование кластера

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

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

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

Оценка закупаемого оборудования и программного обеспечения

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

Слежение за мощностью системы

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

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

Администрирование веб-сайта

В небольших фирмах администратор баз данных зачастую обязан также обеспечивать работу веб-сайта фирмы. В больших фирмах часто работает много людей, занимающихся лишь поддержкой и развитием веб-сайта. Эта работа может быть далека от ваших обязанностей администратора баз данных или тесно взаимосвязана с ними, в зависимости от того, требуется ли доступ к базе данных через веб-сайт. SQL Server идеально подходит для обеспечения доступа к данным через веб-сайт, и для распространения информации таким способом в SQL Server и Windows 2000 имеется множество инструментальных средств и API (Application Programming InterfАce интерфейсов прикладного программирования).

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

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

Работа с коллективом пользователей

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

Потребитель всегда прав

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

Умейте слушать

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

Следуйте Золотому Правилу

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

Настройка системы

Важной обязанностью администратора баз данных является настройка системы (system tuning). Мы дадим здесь пару советов, которые помогут вам более эффективно настраивать и поддерживать систему. Запомните один совет: при настройке системы меняйте за один раз лишь что-нибудь одно. Тогда вам будет просто понять, какие изменения приводят к увеличению производительности системы, а какие могут привести к ее снижению. Для удобства настройки системы будет полезным вести хорошие заметки.

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

Работа в кризисных ситуациях

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

Не паникуйте

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

Не делайте поспешных выводов

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

Пользуйтесь мерами предосторожности

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

Отдыхайте

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

Обращайтесь за помощью

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

Заключение

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

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

Лекция 4. Проектирование системы Microsoft SQL Server

Прежде чем начинать установку операционной системы и СУБД, требуется провести тщательный анализ и продумать архитектуру системы. С помощью данной лекции вы научитесь определять, какие функции будет выполнять система: OLTP, DSS или же системы пакетной обработки данных, определять требования к уровню обслуживания, мощности, обеспечения работоспособности. Обзор службы Microsoft Cluster Services позволяет более эффективное ее использование в будущем. Подробно рассматриваются архитектуры системы баз данных: однозвенная архитектура, двухзвенная и трехзвенная. Вы сможете без труда оценивать производительность и масштабируемость будущей системы.

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

В этой лекции будет дана краткая вводная информация о версиях Microsoft Windows 2000 и SQL Server, которые вы можете выбрать для инсталляции. И наконец, вы получите сведения о типах внешних, интерфейсных (front-end) приложений для доступа к SQL Server, которые ваша фирма может приобрести или создать, а также о том, как архитектура приложений может влиять на перспективы масштабирования и производительности вашей системы.

Системные требования

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

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

Системное приложение

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

Приложения могут быть весьма разнообразными по выполняемым функциям. Можно обобщенно считать, что имеются три основные функции приложений: системы оперативной обработки транзакций ( OLTP, on-line transaction processing ), системы поддержки принятия решений ( DSS, decision support system ) и системы пакетной обработки данных ( batch processing ). Эти функции имеют различные требования и могут применять совершенно разные типы приложений.

OLTP (системы оперативной обработки транзакций)

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

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

DSS (системы поддержки принятия решений)

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

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

Системы пакетной обработки данных

Системы пакетной обработки данных обрабатывают неоперативные (offline) задания обработки данных, не имеющие никаких компонент для работы с конечными пользователями. Вот типичные примеры таких систем:

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

Требования

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

Требования к уровню обслуживания

К наиболее важным факторам, влияющим на проектирование вашей системы, относятся требования к уровню обслуживания. Эти требования к уровню обслуживания обычно формулируются в соглашении об уровне обслуживания (SLA, service level agreement). Соглашения об уровне обслуживания заключаются между поставщиками обслуживания (CIO, chief information officer, руководителями, отвечающими за информационные технологии) и потребителями (пользователями). Будет ли заключено формальное соглашение об уровне обслуживания или нет, зависит от того, кто является потребителем и каким образом осуществляется обслуживание.

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

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

Производительность

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

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

Мощность

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

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

Обеспечение работоспособности

Кроме спецификаций с требованиями к производительности и к мощности, в соглашения об уровне обслуживания обычно включаются также и спецификации с требованиями к обеспечению работоспособности системы. В спецификациях на обеспечение работоспособности системы утверждается, что система должна быть доступна для пользователей в некоторые заранее определенные периоды времени. В соглашении об уровне обслуживания может быть указано, что система должна быть работоспособной в течение 99,9% времени семь дней в неделю, 52 недели в году, либо может быть сказано, что система должна быть работоспособной восемь часов в день, пять дней в неделю, это зависит от потребностей вашей фирмы. Вы отвечаете за разработку плана регулярного резервного копирования и восстановления, а также за планы восстановления после аварий (чрезвычайные планы), чтобы обеспечить работоспособность системы во время, заданное спецификацией об уровне обслуживания.

Системные компоненты и настройки

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

Версии Windows 2000

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

Windows 2000 Professional

Windows 2000 Professional является, по существу, версией Windows 2000 для настольных компьютеров. Как правило, компьютер под управлением Windows 2000 Professional сможет воспользоваться возможностями лишь клиентских компонент SQL Server 2000. Однако если вам понадобится запустить на этом компьютере SQL Server, то вы сможете инсталлировать SQL Server 2000 Personal Edition. Версия Personal Edition позволяет только локальный доступ к базе данных. Доступ с других компьютеров не разрешается.

Примечание. В Windows 2000 Professional можно инсталлировать SQL Server Personal Edition и клиентские компоненты SQL Server.
Windows 2000 Server

Windows 2000 Server спроектирована как серверная операционная система. Это значит, что инсталлировав на компьютер Windows 2000 Server, вы позволите другим компьютерам осуществлять доступ к ресурсам этого компьютера. Windows 2000 Server поддерживает SQL Server 2000 Standard Edition. Windows 2000 Server не поддерживает компьютеры с более чем четырьмя центральными процессорами и более чем с 4 Гб оперативной памяти. SQL Server 2000 также позволяет удаленным клиентам осуществлять доступ к базе данных.

Примечание. На компьютеры под управлением Windows 2000 Server можно инсталлировать только SQL Server Standard Edition, SQL Server Personal  Edition и клиентские компоненты SQL Server.
Windows 2000 Advanced Server

Windows 2000 Advanced Server также является серверной операционной системой. Как и для компьютеров под управлением Windows 2000 Server, компьютеры под управлением Windows 2000 Advanced Server позволяют другим компьютерам осуществлять доступ к их системным ресурсам, а также к SQL Server. В дополнение к возможностям Windows 2000 Server, Windows 2000 Advanced Server поддерживает до восьми центральных процессоров и до 8 Гб оперативной памяти. Если вы хотите пользоваться службами MSCS (Microsoft Cluster Services) для поддержки перехода к другому узлу кластера при отказах, то вам следует применять Windows 2000 Advanced Server. Кроме поддержки MSCS, Windows 2000 Advanced Server вместе с SQL Server 2000 поддерживает новую технологию кластеризации SQL Server – "обновляемые распределенные представления" (updatable distributed views).

Примечание.Чтобы иметь возможность применять SQL Server 2000 с восемью центральными процессорами и 8 гигабайтами памяти, вы должны запускать SQL Server Enterprise Edition. Кроме того, на компьютерах под управлением Windows 2000 Advanced Server можно инсталлировать SQL Server Standard Edition, SQL Server Personal Edition и клиентские компоненты SQL Server.
Windows 2000 Datacenter

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

Примечание.Чтобы иметь возможность применять SQL Server 2000 с 64 центральными процессорами и 64 Гб памяти, вы должны запускать SQL Server Enterprise Edition. Кроме того, на компьютерах под управлением Windows 2000 Datacenter Server можно инсталлировать SQL Server Standard Edition, SQL Server Personal Edition и клиентские компоненты SQL Server.
Версии SQL Server

Вы можете выбирать не только среди версий Windows 2000, но и среди нескольких версий (редакций, editions) SQL Server. Выбор версии SQL Server очень прост и зависит от необходимого для вас объема оперативной памяти и количества центральных процессоров. Ниже даны описания версий SQL Server.

Клиентское программное обеспечение

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

Версия Personal Edition

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

Версия Standard Edition

Standard Edition является одной из двух серверных версий ("редакций") SQL Server 2000. Standard Edition обладает такими же функциональными возможностями, как и SQL Server Enterprise Edition, но не может работать более чем с четырьмя центральными процессорами и более чем с 4 Гб оперативной памяти.

Версия Enterprise Edition

Версия Enterprise Edition поддерживает все средства и функциональные возможности всех версий Windows 2000. Для работы SQL Server 2000 Enterprise Edition требуется Windows 2000 Advanced Server или Windows 2000 Datacenter. Кроме прочего, SQL Server 2000 Enterprise Edition поддерживает двухузловую кластеризацию с переходом к другому узлу кластера при отказах и обновляемые распределенные представления (updatable distributed views).

Сравнительная таблица версий

Возможности различных версий Windows 2000 и SQL Server 2000 перечислены в табл. 4.1.

Таблица 4.1. Сравнение различных версий Windows 2000 и SQL Server 2000
SQL Server 2000 Personal Edition SQL Server 2000 Standard EditionSQL Server 2000 Enterprise Edition
Windows 2000 ProfessionalОграниченные возможностиНевозможное сочетание версийНевозможное сочетание версий
Windows 2000 ServerОграниченные возможностиВозможности сервера.

Поддержка до 4 центральных процессоров и до 2 Гб памяти

Возможности сервера.

Поддержка до 4 центральных процессоров и до 4 Гб памяти

Windows 2000 Advanced ServerОграниченные возможностиВозможности сервера.

Поддержка до 4 центральных процессоров и до 2 Гб памяти

Возможности сервера.

Кластеризация MSCS. Поддержка до 8 центральных процессоров и до 8 Гб памяти

Windows 2000 DatacenterОграниченные возможностиВозможности сервера.

Поддержка до 4 центральных процессоров и до 2 Гб памяти

Возможности сервера.

Кластеризация MSCS. Поддержка до 64 центральных процессоров и до 64 Гб памяти

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

Системные настройки

Кроме выбора версий SQL Server 2000 и Windows 2000 вы также можете воспользоваться еще некоторыми другими настройками. Эти настройки (опции) описаны ниже, они определяют применение кластеризации MSCS, репликацию SQL Server 2000 и обновляемые распределенные представления (эта новая возможность, появившаяся в SQL Server 2000 Enterprise Edition). Каждая из этих настроек имеет свои собственные возможности и требования и, следовательно, могут оказаться в вашей конфигурации полезными либо бесполезными. Мы расскажем об этом в нескольких абзацах ниже.

MSCS

Сокращение MSCS расшифровывается как Microsoft Cluster Services – "службы кластеризации Microsoft". Службы MSCS являются настройкой Windows 2000, работающей в сочетании с SQL Server. Благодаря MSCS компьютер может работать как резервный сервер (standby, failover server) для другого компьютера (сервер для перехода при отказе). Благодаря этому можно начинать процесс восстановления почти сразу же после случившегося аппаратного или даже программного отказа. Для MSCS требуется разделяемая дисковая подсистема, подключенная к обоим компьютерам кластера. Журнал транзакций SQL Server и файлы данных, а также исполняемые файлы должны размещаться на этой разделяемой дисковой подсистеме. В случае отказа, определяемого по отсутствию "сигнала пульса", резервный компьютер берет на себя функции SQL Server. Так как резервный компьютер захватывает себе IP-адрес и имя системы, то для внешнего мира он воспринимается просто как перезагрузившийся основной сервер базы данных.

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

Репликация SQL Server

Репликация SQL Server позволяет копировать данные из одной базы данных SQL Server на другие системы баз данных. Имеются разные схемы репликации –моментальная (snapshot replication), транзакционная (transactional replication) и репликация слиянием (merge replication), они будут описаны в нескольких абзацах ниже. Какая из схем репликации лучше всего подойдет вам – зависит от ваших предпочтений и от ваших потребностей. Репликация SQL Server работает по модели "опубликовать-подписаться" (publish-and-subscribe model), в которой издатель (publisher) публикует данные, а один или несколько подписчиков (subscribers) получают копии этих данных.

Моментальная репликация

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

Транзакционная репликация

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

Репликация слиянием

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

Обновляемые распределенные представления

В SQL Server появились обновляемые распределенные представления (updatable distributed views). Благодаря этой возможности системы SQL Server могут разделять (использовать совместно) логическую базу данных, что повышает масштабируемость. Логическая база данных может стать большой, и вы можете разместить ее на многих компьютерах, это позволяет повысить ее мощность. (Об обновляемых распределенных представлениях см. лекцию 18.)

Размещение базы данных

Важной частью проектирования системы SQL Server является проектирование размещения базы данных (database layout). Под этим надо понимать физическое размещение журналов транзакций, файлов данных и т.д. Эта задача – одна из самых важных при проектировании системы, потому что изменить принятые ранее решения, относящиеся к размещению, будет очень сложно. В лекциях 5 и 6 будут даны советы о физическом размещении журнала транзакций и файлов данных.

Журнал транзакций

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

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

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

Файлы данных

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

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

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

Приложение

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

Архитектура

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

Сравнение архитектур

Каждое приложение базы данных состоит из трех отдельных компонент:

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

Различия между однозвенной, двухзвенной и трехзвенной архитектурами


Рис. 4.1.  Различия между однозвенной, двухзвенной и трехзвенной архитектурами

Однозвенная архитектура

Однозвенная (one-tier, single-tier) архитектура – это система, в которой все службы базы данных, приложения и представления (пользовательский интерфейс) размещены на одной системе. Системы такого типа не производят обработку вне тех компьютеров, на которых они исполняются. Примером однозвенной архитектуры может служить база данных Microsoft Аccess с локальными службами представления.

В наше время трудно встретить действительно однозвенную архитектуру, особенно на платформе Windows 2000. Тем не менее многие небольшие однопользовательские приложения являются однозвенными. Примером этому могут служить Microsoft Money, Quicken и TurboTax. Такие приложения обычно размещаются на том же компьютере, на котором они и исполняются. Пример однозвенной архитектуры с SQL Server найти гораздо труднее. Фактически, даже если вы можете исполнять Enterprise Manager на той же системе, где размещена и база данных, но на самом деле такое приложение не является однозвенным, потому что данное приложение пользуется сетевыми компонентами SQL Server. Тот факт, что вы вот взяли и запустили его на той же системе, является несущественным.

Двухзвенная архитектура

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

Двухзвенные приложения встречаются чаще всего. Вы, наверное, уже работали со многими такими приложениями. Эти приложения обычно написаны на языках, поддерживающих API (интерфейсы прикладного программирования) для Windows, таких, как Microsoft Visual C++ или Visual Basic. При помощи двухзвенных приложений каждый пользователь может иметь одно или несколько соединений с базой данных SQL Server. Данная архитектура может стать неэффективной из-за того, что большинство этих соединений будут простаивать большую часть времени.

Трехзвенная архитектура

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

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

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

Производительность и масштабируемость

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

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

Заключение

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

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

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

Лекция 5. Конфигурирование и планирование подсистемы ввода-вывода

Подсистема ввода-вывода – одна из главных составляющих при проектировании системы. Рассматриваются принципы работы жестких дисков, показатели производительности: задержка вращения, время поиска дорожки диска, максимальное время поиска и другие. Проводится очень подробный анализ и сравнительная характеристика массивов RAID: RAID 0, RAID 1, RAID 5, RAID 10. Обзор внутренних и внешних массивов RAID. Различные таблицы, схемы, графики позволяют более наглядно и качественно представить информацию для принятия нужного решения. Первое знакомство с языком запросов T-SQL проводится именно в этой лекции!

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

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

Характеристики производительности дисков

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

Конструкция накопителя на жестких дисках

В качестве компонент для хранения данных в накопителях на жестких дисках применяются одна или нескольких пластин (disk platters). Эти пластины покрыты веществом, способным хранить данные благодаря своим магнитным свойствам. Данные хранятся на дорожках (tracks), похожих на дорожки грампластинки (или компакт-диска – для тех, кто забыл, как выглядят грампластинки). Каждая дорожка, в свою очередь, состоит из нескольких секторов. Чем дальше от центра диска, тем больше секторов будет на каждой из дорожек. Типичная пластина жесткого диска показана на рис. 5.1.

Накопители на жестких дисках часто состоят не из одной, а из многих пластин, расположенных одна над другой (рис. 5.2). Данные считываются при помощи магнитных головок. Магнитные головки используются как для чтения, так и для записи данных на диск. Так как пластин несколько, то и головок должно быть несколько. Эти головки крепятся на коромыслах (armature), двигающихся внутрь пакета пластин и обратно из него, подобно тонарму с иглой у граммофона. Все головки и коромысла жестко соединены друг с другом, поэтому все головки в каждый из моментов времени находятся в одинаковых местах каждой из пластин. Из-за такой конструкции диска становится целесообразным одновременное чтение или запись сразу всеми его головками. Таким образом, данные записываются и считываются с диска одновременно всеми головками. Поскольку набор дорожек, охватываемых головками в любой из моментов времени, похож на цилиндр, мы говорим, что данные хранятся в цилиндрах (рис. 5.2).

Пластина жесткого диска


Рис. 5.1.  Пластина жесткого диска

 Цилиндры жесткого диска


Рис. 5.2.  Цилиндры жесткого диска

Накопители на жестких дисках могут иметь только одну пластину, а могут – и более шести пластин. Плотность хранения данных на пластинах и количество пластин определяют максимальную емкость (вместимость) накопителя. Некоторые модели накопителей не отличаются почти ничем, кроме количества пластин. Распространенная модель накопителей имеет емкость 9 Гб и три пластины, а накопители модели, не отличающейся ничем, кроме емкости 18 Гб, имеют шесть пластин.

Показатели производительности накопителей на жестких дисках

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

Задержка вращения

Многие высокопроизводительные жесткие диски вращаются со скоростью 10000 об/мин. Если для доступа к запрошенным данным потребуется полный оборот диска, то этот оборот диска займет приблизительно 6 мс, т.е. 0,006 секунд. Скорость вращения 10000 об/мин соответствует 166,7 оборотам в секунду, поэтому на один оборот требуется 1/166,7 секунды, т.е. около 6 мс.

Чтобы головки накопителя могли прочитать сектор данных, этот сектор должен находиться под головками. Поскольку диск всегда вращается, головка просто должна подождать, пока сектор не подойдет в позицию под нее. Время, необходимое для поворота диска в нужную позицию, когда нужный сектор подойдет под головку, называется задержкой вращения (rotational latency). Задержка вращения может достигать 6 мс (если необходим полный оборот диска), но в среднем она составляет 3 мс.

Задержка вращения добавляется к времени отклика доступа к диску. Поэтому, когда вы выбираете дисковые накопители для своей системы, с точки зрения производительности, длительность задержки вращения чрезвычайно важна. Как вы только что видели, для дисков со скоростью вращения 10000 об/мин, задержка вращения составляет около 3 мс. Диски предыдущего поколения вращались со скоростью 7200 об/мин, у них оборот совершался за 8,3 мс, а средняя задержка вращения составляет около 4,15 мс. Это увеличение средней задержки вращения кажется небольшим, но оно на 38% больше, чем у диска со скоростью вращения 10000 об/мин. Как вы узнаете далее в данной лекции, длительность времени отклика может значительно увеличить время доступа для ввода-вывода.

Время поиска дорожки диска

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

 Задержка вращения и время поиска


Рис. 5.3.  Задержка вращения и время поиска

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

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

Время перехода головки на соседнюю дорожку (track-to-track seek time) определяет время перехода на другую дорожку при осуществлении операций последовательного ввода-вывода. У типичных 9 Гб дисков со скоростью вращения 10000 об/мин время перехода головки с дорожки на дорожку составляет около 0,8 мс. Как видите, для дисков со временем перехода головок на соседнюю дорожку 0,8 мс, задержка вращения составляет около 3 мс и является более существенным фактором, оказывающим влияние на производительность дискового накопителя. Если операции ввода-вывода применяются к дисковому накопителю достаточно быстро, то накопитель сможет прочитывать за один раз соседние дорожки или даже прочитывать или записывать дорожку целиком за один раз. Однако так бывает не всегда. В некоторых ситуациях операции ввода-вывода запрашиваются недостаточно быстро, и на каждый запрос из серии последовательных запросов приходится по обороту диска. То, что будет происходить на самом деле, зависит от конструкции и от скорости контроллера дискового накопителя.

Среднее время поиска дорожки диска (average seek time) – это усредненное время, необходимое для перехода головок между двумя произвольно выбранными (random) дорожками диска. Исходя из таблиц с техническими характеристиками типичных дисков со скоростью вращения 10000 об/мин, их время поиска составляет около 6 мс. Поскольку почти все операции ввода-вывода, генерируемые SQL Server, будут относиться к произвольным участкам диска, то ваши дисковые накопители будут выполнять множество операций произвольного ввода-вывода.

Максимальное время поиска для дисков данного типа может достигать 13 мс. Поиск дорожки имеет максимальную длительность при переходе от самой внутренней дорожки пластины к самой внешней дорожке или наоборот. Такая ситуация называется поиск по всему диску (full-disk seek). Но при обычной работе поиск нужной дорожки не будет поиском по всему диску, особенно когда диск не заполнен до конца.

Технические характеристики накопителей на жестких дисках

В данном разделе вы узнаете, насколько быстро дисковые накопители могут выполнять различные виды операций ввода-вывода. Чтобы оценить скорость выполнения операций ввода-вывода, необходимо знать некоторые сведения о дисковом накопителе. Большинство этих сведений можно найти в технических описаниях дисков, сообщаемых их производителями. В данной лекции в качестве примера будут взяты технические характеристики накопителя с емкостью 9,1 Гб и скоростью вращения 10000 об/мин. Другие технические характеристики этого типичного дискового накопителя перечислены в табл. 5.1.

Таблица 5.1. Технические характеристики дискового накопителя (пример)
Техническая характеристикаЗначениеОписание
Емкость диска9.1 ГбЕмкость неформатированного диска
Скорость вращения10000 об/минСкорость, с которой вращается диск
Скорость передачи данных40 Мб/сСкорость шины SCSI
Среднее время поиска5,2 мс (для чтения), 6 мс (для записи)Средняя продолжительность времени, необходимого для поиска нужной дорожки (при операциях произвольного ввода-вывода)
Время перехода головки на соседнюю дорожку0,6 мс (для чтения), 0,9 мс (для записи)Продолжительность времени, необходимого для перехода на соседнюю дорожку (при операциях последовательного ввода-вывода)
Время поиска по всему диску12 мс (для чтения), 13 мс (для записи)Продолжительность времени, необходимого для перехода от самого внутреннего сектора диска к самому внешнему сектору, или наоборот
Средняя задержка2,99 мсСредняя задержка вращения
Средняя длительность работы до отказа1 000 000 часовСредний срок службы дискового накопителя

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

Производительность накопителя на жестких дисках

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

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

Последовательный ввод-вывод

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

Как мы уже упоминали, типичному дисковому накопителю для выполнения перехода головок к соседней дорожке потребуется около 0,9 мс. Прибавив это время к величине задержки вращения (2,99 мс), вы можете сделать вывод, что каждая операция ввода-вывода займет приблизительно 3,89 мс. Такая длительность теоретически позволяет выполнять 264 операции последовательного ввода-вывода в секунду, т.к. одна секунда содержит 264 интервала времени по 3,89 мс. Но на производительность последовательного ввода-вывода влияют и другие факторы, такие как ограничение пропускной способности интерфейса SCSI 40 Мб/с и компоненты операционной системы: файловая система и драйвер устройства. Эта дополнительная нагрузка определяет максимальную производительность последовательного ввода-вывода, допустимую для данного дискового накопителя, составляющую около 250 операций в секунду (это число зависит от размера передаваемых данных). Как вы узнаете в лекции 6, если ваш диск передает данные со скоростью, превышающей 85% от его производительности, то будут образовываться очереди, поэтому максимальная рекомендуемая производительность ввода-вывода составит 225 операций в секунду.

Произвольный ввод-вывод

При произвольном вводе-выводе головки дискового накопителя должны считывать данные с произвольных участков диска. Из-за этих произвольных перемещений головок происходит снижение производительности. Давайте снова вернемся к нашему примеру дискового накопителя. Пусть теперь головки затрачивают не по 0,8 мс, переходя на соседние дорожки, а перемещаются произвольным образом по всему диску. Для поиска произвольной дорожки потребуется в среднем около 6 мс, что в 7,5 раза длительней перехода к соседней дорожке. Для типичной операции произвольного ввода-вывода понадобится примерно 6 мс (в среднем) на перемещение головок к дорожке с данными и еще 2,99 мс на задержку вращения, что составит в сумме 8,99 мс, т.е. теоретически максимально может производиться 111 операций ввода-вывода в секунду (т.к. в одной секунде содержится 111 интервалов времени по 8,99 мс). Далее, мы уже говорили, что если возможности ввода-вывода для диска задействуются более чем на 85%, то образуются очереди. Поэтому максимальная рекомендуемая производительность ввода-вывода составит 94 операции в секунду. А если согласиться с эмпирическим правилом для учета нагрузки на контроллер, то следует ограничить ввод-вывод для данного дискового накопителя 85 операциями ввода-вывода в секунду.

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

Количество операций ввода-вывода в секунду как функция задержки


Рис. 5.4.  Количество операций ввода-вывода в секунду как функция задержки

На самом деле, если вы достигните 100-процентного задействования возможностей диска, то очереди возникнут обязательно, а общая производительность резко снизится. Как вы прочтете в нашей книге позднее, SQL Server, как и любая другая система управления реляционными базами данных, очень сильно зависит от задержек ввода-вывода. Если для выполнения операций ввода-вывода требуется чрезмерно много времени, то производительность SQL Server сильно снизится (деградирует) и могут возникнуть такие проблемы, как блокировка (blocking) и зависание (deadlock). Когда поток ждет исполнения операции ввода-вывода, он может удерживать блокировки. До тех пор, пока операция ввода-вывода не будет исполнена, блокировка будет сохраняться, что и является причиной данных проблем.

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

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

Массивы RAID

Как вы понимаете, если просто добавлять в систему новые и новые дисковые накопители, то с нею будет очень сложно работать. Поэтому, вместо того, чтобы добавлять десятки или сотни отдельных дисковых накопителей, многие пользователи предпочитают применять массивы RAID (Redundant Array of Independent Disks, массивы независимых дисковых накопителей с избыточностью). Массивы RAID могут быть реализованы с использованием программных средств и имеющихся у вас устройств ввода-вывода, либо могут быть приобретены как аппаратные устройства RAID. В этом разделе мы познакомим вас с массивами RAID и расскажем о том, как они работают.

Как ясно из самого их названия, массивы RAID содержат в себе два или несколько дисковых накопителей, образуя тем самым массив дисковых накопителей. Операционная система воспринимает весь этот массив как один логический диск. Этот логический диск называют также дисковый том, потому что он является набором дисков, кажущихся одним диском. Для пользователей, для приложения и даже (если применяется аппаратный массив RAID) для Microsoft Windows 2000 массив RAID воспринимается как один диск. Во многих случаях, однако, этот один диск будет иметь гораздо больший объем, чем любой из дисков, имеющихся в продаже. Но благодаря массивам RAID можно создавать не только большие логические диски, но также, во многих из конфигураций RAID (уровнях RAID), обеспечивать также и отказоустойчивость логического диска. Эта отказоустойчивость позволяет диску RAID сохранять работоспособность даже при отказе одного или нескольких из отдельных дисковых накопителей, составляющих массив RAID. В следующих разделах мы покажем, как достигаются такие возможности, и расскажем о характеристиках различных уровней RAID.

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

Понятия, относящиеся к подсистеме ввода-вывода

Аппаратные контроллеры RAID обеспечивают не только основные функциональные возможности RAID, но и некоторые дополнительные средства. Среди этих дополнительных возможностей аппаратных реализаций RAID чаще всего встречается кэш контроллера. В этом разделе вы узнаете о кэше контроллера, кэшах дисковых накопителей и о разнице между внутренними и внешними массивами RAID. Кроме того, вы узнаете о новой технологии ввода-вывода – сетях хранения данных SAN (Storage Area Network). В данном разделе мы также рассмотрим некоторые разнообразные вопросы, имеющие отношение к контроллерам RAID, к дисковым накопителям и к пропускной способности устройств ввода-вывода.

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

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

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

Кэши дисковых накопителей

Большинство дисковых накопителей тоже содержит кэш с оперативной памятью. Этот кэш имеет меньший объем, чем кэш контроллера. Он может хранить одновременно немного запросов, благодаря чему дисковый накопитель может самостоятельно выполнить лифтовую сортировку (elevator sorting). Но так как этот кэш совсем маленький (обычно – только несколько килобайт), то он не может применяться для значительного упреждающего чтения или для кэширования значительных объемов данных. Многие поставщики контроллеров RAID и контроллеров SCSI не разрешают изменять состояние этого кэша, но, однако, некоторые производители массивов RAID все же разрешают пользователям включать либо выключать этот кэш.

Внутренние и внешние массивы RAID

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

Внутренние и внешние системы RAID


Рис. 5.5.  Внутренние и внешние системы RAID

Сети хранения данных (SAN)

Одной из новейших технологий, появившихся на рынке, является SAN (storage area network, сеть хранения данных). Основой SAN является большая внешняя система RAID, которой могут пользоваться совместно несколько компьютеров. Из-за этого в названии технологии появилось слово network – сеть. Благодаря SAN вы можете консолидировать (собрать воедино) все запоминающие устройства и снизить расходы, осуществляя работу с системой и поддержку системы в одном месте.

Технология SAN имеет довольно простую концепцию. Внешняя система RAID соединяет адаптер главной шины (HBA, host bus adapter) непосредственно с подсистемой RAID (см. рис. 5.6). В сети SAN происходит соединение нескольких адаптеров главной шины через коммутатор, по крайней мере, с одной внешней системой RAID. В такой конфигурации все компьютеры, входящие в сеть SAN, могут осуществлять доступ к подсистеме RAID.

 Система SAN


Рис. 5.6.  Система SAN

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

Пропускная способность контроллера и шины

Вы должны оценить не только ограничения, связанные с дисковым накопителем, но и ограничения пропускной способности шины ввода-вывода (обычно это SCSI или Fibre Channel). Так как шины работают с заданной тактовой частотой и имеют определенное количество разрядов данных (32 бита, 64 бита и т.д.), то максимальная пропускная способность ограничена некоторым фиксированным значением. Ваши потребности могут достичь до пропускных способностей контроллера, шины PCI или шины ввода-вывода контроллера или превысить их. Вы можете избежать этого, распределив контроллеры по нескольким шинам PCI вашего компьютера. Большинство компьютеров сейчас выпускается с тремя и более шинами PCI.

Подсистемы ввода-вывода высшего класса

Компании, которым необходимо обеспечивать доступность в течение 99,99% времени и более в сочетании с максимальной производительностью, часто обращаются к поставщикам вроде фирмы EMC. Такие поставщики предлагают сложные подсистемы ввода-вывода, содержащие кэши объемами в несколько Гб и множественные каналы для передачи данных от компьютеров к дисковым накопителям. Множественные каналы обеспечивают избыточность. Если какая-либо компонента системы откажет (например, откажет канал ввода-вывода, контроллер или кэш), то подсистема ввода-вывода не прекратит свое функционирование. При тщательном планировании состава таких подсистем ввода-вывода, они могут обеспечить высочайший уровень производительности и надежности.

Лифтовая сортировка

Лифтовая сортировка (elevator sorting) – это метод для обеспечения большей эффективности операций произвольного ввода-вывода. Когда диск получает произвольные запросы ввода-вывода, головки должны перемещаться произвольным образом по дорожкам диска, внутрь и наружу. Из-за этих операций произвольного ввода-вывода возникают задержки, мы уже рассказывали вам об этом. Многие из RAID-контроллеров поддерживают лифтовую сортировку, благодаря которой поиск произвольных дорожек становится более эффективным. Когда на контроллере, поддерживающем лифтовую сортировку, собрались в очереди несколько запросов ввода-вывода, то операции ввода-вывода могут быть отсортированы таким образом, чтобы избавиться от лишних перемещений головок. Движения головок, оптимизированные при помощи лифтовой сортировки, напоминают движения лифта, забирающего попутных пассажиров при перемещении между этажами в нужном направлении.

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

 Лифтовая сортировка


Рис. 5.7.  Лифтовая сортировка

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

Надежность дисков

Дисковые накопители являются одними из немногих компонент компьютера, имеющими подвижные детали. Диск вращается с большой скоростью и работает нагретым до высокой температуры. Среди деталей накопителя имеются несколько двигателей и подшипников, которые рано или поздно, но обязательно износятся. Среди технических характеристик дискового накопителя имеется средняя продолжительность наработки на отказ (MTBF, mean time between failures). Данная техническая характеристика показывает, сколько в среднем прослужит этот накопитель. Однако это число показывает лишь среднее время. При одинаковой средней продолжительности наработки на отказ срок службы у разных дисков будет неодинаковым. Типичные современные диски могут иметь среднюю продолжительности наработки на отказ равную миллиону часов, т.е. 114 годам. Это долгий срок, но некоторые диски с таким показателем MTBF прослужат гораздо дольше, а некоторые – сломаются очень быстро. Дело в том, что диски содержат подвижные детали, и поэтому они подвержены износу и могут ломаться.

Обзор типовых уровней RAID

Главной особенностью массивов RAID является то, что логический диск формируется из двух или нескольких физических дисковых накопителей и воспринимается Windows 2000 (и Performance Monitor) как один физический дисковый накопитель. Логический дисковый накопитель может содержать многие сотни Гб данных, хотя изготовлять дисковые накопители емкостью в 100 Гб не удается (пока что!).

Большинство уровней RAID, о которых мы вам расскажем, применяют расслоение данных (data striping), при помощи которого данные с двух или нескольких дисков объединяются в один большой логический RAID-диск. Это делается так: первый фрагмент данных берется с первого диска, второй кусок данных – со второго диска, и так далее. Эти фрагменты данных называются слои (stripes) или куски (chunks). Размер слоев данных задается контроллером. Некоторые контроллеры разрешают вам конфигурировать размеры слоев, а некоторые применяют слои фиксированного размера.

Название "слой" ("кусок") применяется как к фрагментам данных на каждом из отдельных дисков, так и к набору слоев (кусков) для всей совокупности дисков (рис. 5.8).

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

  Слои RAID


Рис. 5.8.  Слои RAID

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

RAID 0

RAID 0 являются самым "фундаментальным" из уровней RAID, он обеспечивает только расслоение дисков. Куски данных создаются на каждом из дисковых накопителей, а размер кусков задается контроллером. Для составления большого логического диска применяется метод кругового распределения кусков данных по отдельным дискам массива RAID 0 (рис. 5.9).

 RAID 0


Рис. 5.8.  RAID 0

Хотя RAID 0 и причисляется к массивам RAID, однако данный уровень RAID не обеспечивает избыточности (redundancy, вспомните расшифровку аббревиатуры RAID: Redundant Array of Independent Disks ). Раз избыточности нет, то и отказоустойчивость тоже отсутствует. Если в массиве RAID 0 откажет хотя бы один диск, то все данные будут потеряны. Отказ одного из дисков будет сравним с уничтожением каждого четвертого слова в книге. Если произойдет такая потеря данных, то массив RAID станет бесполезным.

Рекомендации по применению RAID 0

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

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

RAID 1 являются "фундаментальным" уровнем RAID, обеспечивающим отказоустойчивость. В алгоритме RAID 1, называющемся также "зеркальное отражение", предусмотрено изготовление дублирующей копии вашего диска с данными. Дублирующая копия содержит ту же самую информацию, что имеется и на первоначальном диске (рис. 5.10). При отказе диска в строй вступит диск-дубль, и вы не потеряете данные. Так как на каждом диске (и на первоначальном, и на зеркале) хранятся все данные, то расслоение данных отсутствует. В RAID 1 второй диск применяется для дублирования первого, поэтому общий объем логического тома RAID 1 совпадает с объемом одного дискового накопителя. RAID 1 является дорогостоящим решением: при удвоении количества применяемых дисков вы взамен не получаете никакого увеличения объема дисковой памяти, но зато он обеспечивает высокий уровень отказоустойчивости.

 RAID 1


Рис. 5.10.  RAID 1

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

Запись данных на оба диска также снижает производительность логического дискового накопителя. При подсчете количества операций ввода-вывода, производимых на всех дисках массива, нужно умножать количество записей на 2. Чтение данных производится только с одного из дисков. Скорости работы дисков могут отличаться, потому что головки одного из дисков могут оказаться в другом положении, чем головки другого диска, и из-за этого время поиска нужной дорожки может оказаться более длительным. Положение головок может быть разным из-за функции уровня RAID 1, называющейся параллельный поиск (split seek).

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

Рекомендации по применению RAID 1

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

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

RAID 5

RAID 5 являются отказоустойчивым уровнем RAID, в котором для защиты данных применяется контроль по четности. Каждый слой данных (stripe) RAID создает информацию для контроля по четности, хранимую на одном из дисков в составе слоя. В сочетании с другими дисками в составе слоя RAID, информация для контроля по четности может быть использована для воссоздания данных с любого из дисков слоя. Поэтому массивы RAID 5 устойчивы к отказу одного из дисковых накопителей, входящего в состав массива. Информация для контроля по четности распределяется поочередно по всем дискам массива RAID (рис. 5.11).

 RAID 5


Рис. 5.11.  RAID 5

Достоинством RAID 5 является то, что дисковая память, доступная при применении этого уровня RAID, составляет (n-1)*(объем одного диска) где n равно количеству дисков в массиве. Так, массив RAID 5, составленный из 10 дисков, будет иметь объем, как у 9 дисков, что делает его экономичным и в то же время отказоустойчивым решением.

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

Контроль по четности в массивах RAID 5

В массивах RAID 5 для данных каждого из слоев на каждом из дисковых накопителей создается бит контроля по четности. Бит контроля по четности является дополнительным элементом данных, благодаря которому, имея биты из набора данных, по которому он был создан, можно узнать другие биты из набора данных. Бит контроля по четности создается так: все остальные биты суммируются, а затем определяется, какое значение он должен иметь, чтобы получилось четное (или нечетное число). Бит контроля по четности, в сочетании с остальными битами, может применяться, чтобы восстановить значение потерянного бита.

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

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

В нашем примере будем считать, что контроль по четности должен обеспечить четность суммы битов, т.е. сумма всех битов должна давать результат 0 (имеется в виду сложение по модулю 2, т.е. результат сложения битов должен быть четным. – Прим. пер.). Если первый бит первого диска равен 0, первый бит второго диска равен 1, первый бит третьего диска равен 1, первый бит четвертого диска равен 1, то бит контроля по четности для этих битов должен быть равен 1, чтобы дополнить эти биты до четного числа (см. табл. 5.2).

Таблица 5.2. Пример контроля по четности для массива RAID
диск 1: бит 1диск 2: бит 1диск 3: бит 1диск 4: бит 1диск 5: бит контроля по четностиСумма битов
011114(четная)

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

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

Создание данных для контроля по четности

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

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

С этого момента, всякий раз при записи данных на дисковый накопитель, должно производиться чтение данных с диска данных и с диска контроля по четности. Новые данные должны сравниваться со старыми данными, и если какой-либо бит данных поменялся, то данные контроля по четности для этого бита тоже должны быть изменены. Эта проверка производится при помощи логической операции "исключающее ИЛИ" ( XOR, exclusive OR ).Поэтому требуется чтение данных только с диска данных и диска контроля по четности, а не со всех дисков массива. Как только описанная операция вычисления изменений данных контроля по четности будет завершена, запись должна быть произведена на оба диска, т.к. операция с данными контроля по четности затрагивает весь слой данных. Таким образом, для выполнения каждой записи в том RAID 5 производятся четыре физических операции ввода-вывода: два чтения (одно – чтение с диска данных, другое – чтение с диска контроля по четности) и две записи (сами данные и данные контроля по четности). Но в массивах RAID 5 данные контроля по четности равномерно распределены по всем дисковым накопителям, поэтому и нагрузка на накопители будет распределена равномерно.

Рекомендации по применению RAID 5

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

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

RAID 10

RAID 10 является комбинацией RAID 0 и RAID 1. В RAID 10 применяется зеркальное дублирование слоев данных дисков. Для каждого диска создается дубль, но каждый диск содержит только часть всех данных (рис. 5.12). Этот уровень RAID обеспечивает отказоустойчивость, как у RAID 1, а удобства и производительность, как у RAID 0.

RAID 10


Рис. 5.12.  RAID 10

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

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

Рекомендации по применению RAID 10

RAID 10 обеспечивает высокую производительность и высокую степень отказоустойчивости. Уровень RAID 10 следует применять, когда нужна работа с большими томами, для которых операции записи составляют более 10% от общего объема операций ввода-вывода. Можно дать следующие рекомендации по применению RAID 10:

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

Сравнение производительности уровней RAID

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

Производительность чтения

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

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

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

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

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

Подсчет количества операций ввода-вывода для дисков

Чтобы определить объем нагрузки, приходящейся на отдельные дисковые накопители системы, вам придется выполнить некоторые расчеты. Если вы пользуетесь аппаратным контроллером RAID, то количество операций ввода-вывода в секунду, показываемое монитором производительности Performance Monitor означает количество операций ввода-вывода, выполняемых массивом как единым целым. Вы не увидите сведений о дополнительных операциях ввода-вывода, генерируемых контроллером и служащих для обеспечения отказоустойчивости. Фактически, Windows 2000 не замечает их выполнения, но вы должны знать о них, чтобы правильно определить количество дисковых накопителей, необходимое для обеспечения оптимальной производительности.

RAID 0

В массивах RAID 0 темп операций ввода-вывода на один диск вычисляется как сумма всех операций чтения и записи для массива, деленная на количество дисков в массиве. Для RAID 0 нужна лишь одна простая и понятная формула:

количество операций на диск = (чтения + записи) / количество дисков

RAID 1

Для массивов RAID 1 вычисления будут несколько более сложными. Так как количество записей удваивается, то число операций ввода-вывода на один диск в секунду равно сумме количества операций чтения и удвоенного количества операций записи для массива, деленной на количество дисков в массиве (для RAID 0 – два). Нужно применять такую формулу:

количество операций на диск = (чтения + (2 * записи)) / 2

Запись в массивы RAID 1 происходит медленней, но они обеспечивают лучшую отказоустойчивость.

RAID 5

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

количество операций на диск = (чтения + (4 * записи)) / количество дисков

RAID 10

Скорость записи в массивы RAID 10 такая же, как в RAID 1, но зато RAID 10 обеспечивает высокую степень отказоустойчивости. Расчет для RAID 10 аналогичен расчету для RAID 1. Поскольку количество записей удваивается, то число операций ввода-вывода на один диск равно сумме количества операций чтения и удвоенного количества операций записи для массива, деленной на количество дисков в массиве. Формула для RAID 10 будет такой:

количество операций на диск = (чтения + (2 * записи)) / количество дисков
Сравнение различных уровней RAID

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

Таблица 5.3. Сравнение уровней RAID
Уровень RAID Производительность ОтказоустойчивостьОценка стоимости
RAID 0НаилучшаяБез отказоустойчивостиЭкономичный
RAID 1ХорошаяХорошаяДорогой
RAID 5Быстрая для чтения, медленная для записиНормальнаяСамый экономичный из уровней, обеспечивающих отказоустойчивость
RAID 10ХорошаяХорошаяДорогой

Как видите, наилучший вариант зависит от ваших потребностей. Чтобы понять различие между производительностью RAID 5 и RAID 10 при разных соотношениях чтения и записи, посмотрите табл. 5.4, в которой показаны данные для массивов RAID 5 и RAID 10, выполняющих 500 операций ввода-вывода в секунду на 10 дисковых накопителях при разных соотношениях чтения и записи.

Таблица 5.4. Сравнение RAID 5 и RAID 10
Соотношение Чтения/Записи Операции ввода-вывода RAID 5 (Чтения + (4 * Записи)) /  Кол-во дисков Операции ввода-вывода RAID 10 (Чтения + (2 * Записи)) /  Кол-во дисков
100% чтений

0% записей

(500+0)/10

50 операций ввода-вывода на диск

(500+0)/10

50 операций ввода-вывода на диск

90% чтений

10% записей

(450+200)/10

65 операций ввода-вывода на диск

(450+100)/10

55 операций ввода-вывода на диск

75% чтений

25% записей

(375+500)/10

87.5 операций ввода-вывода на диск

(375+250)/10

62.5 операций ввода-вывода на диск

50% чтений

50% записей

(250+1000)/10

125 операций ввода-вывода на диск

(250+500)/10

75 операций ввода-вывода на диск

0% чтений

100% записей

(0+2000)/10

200 операций ввода-вывода на диск

(0+1000)/10

100 операций ввода-вывода на диск

Как видите, когда соотношение чтения к записи составляет 90%:10%, нагрузка на диски для RAID 5 и RAID 10 почти не отличается. Но когда запись составляет более высокий процент в операциях ввода-вывода, нагрузка на диски массивов RAID 5 становится гораздо больше.

Задержки ввода-вывода и SQL Server

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

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

Кроме того, обработка запросов станет очень медленной. Например, если на вашей системе выполняется сканирование больших таблиц, то для выполнения таких задач часто требуется чтение сотен, тысяч и даже миллионов строк в базах данных. Для миллиона операций ввода-вывода даже небольшие изменения производительности становятся очень важными. Выполнение одного миллиона операций по 10 мс займет около 2,8 часа. А если ваша подсистема ввода-вывода оказалась перегружена и каждая операция ввода-вывода требует 40 мс, то выполнение такого же запроса займет уже более 11 часов.

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

Планирование размещения дисков SQL Server

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

Определяем требования к вводу-выводу

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

Объем дисковой памяти

Определить, сколько места на дисках потребуется для ваших данных, достаточно просто. Объем необходимого места равен сумме следующих величин:

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

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

Определившись с объемом данных, объемом индексов, объемом временной базы данных и с темпом роста, вы можете определить, сколько места на дисках вам потребуется. Затем вы должны учесть место, необходимое для обеспечения отказоустойчивости в массивах RAID. Помните, что в массивах RAID 1 и RAID 10 (с зеркальным дублированием данных) для обеспечения отказоустойчивости тратится половина физического места на дисках. В массивах RAID 5 для обеспечения отказоустойчивости тратится один дисковый накопитель, входящий в состав массива. Также помните, что объем дисков, указываемый изготовителями, обозначает емкость неотформатированного диска. Неотформатированный дисковый накопитель, маркированный, как имеющий емкость 9,1 Гб, после форматирования будет вмещать на самом деле 8,6 Гб.

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

Производительность

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

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

Планирование размещения дисков

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

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

Планирование размещения журнала транзакций

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

Планирование размещения файлов данных

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

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

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

Например, если у вас имеется два тома, один – из 20 дисковых накопителей, а другой – из 10 накопителей, то нужно создать группу файлов из двух файлов данных. (О применении файлов и групп файлов см. лекцию 9.) Первый файл данных нужно поместить на 20-дисковый том, и он должен быть в два раза больше файла данных, размещаемого на 10-дисковый томе. При загрузке данных, SQL Server будет загружать в первый файл в два раза больше данных, чем во второй файл. Благодаря этому интенсивность ввода-вывода будет примерно одинаковой для всех дисков.

Реализация конфигурации

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

--
-- Сценарий SQL для создания базы данных, состоящей из нескольких файлов 
-- d:, e: и f: - для данных,  e: и f: имеют в два раза больше дисковых накопителей, 
-- чем имеется у d:, поэтому размер базы данных, распределенной для них в 
-- два раза больше, чем для d:.  l: используется для журнала. 
--

CREATE DATABASE demo 
ON
PRIMARY ( NAME = demo1,
      FILENAME = 'd:\data\demo_dat1.mdf',
      SIZE = 100MB,
      MAXSIZE = 200,
      FILEGROWTH = 20),
( NAME = demo2,
   FILENAME = 'e:\data\demo_dat2.ndf',
   SIZE = 200MB,
   MAXSIZE = 200,
   FILEGROWTH = 20),
( NAME = demo3,
   FILENAME = 'f:\data\demo_dat3.ndf',
   SIZE = 200MB,
   MAXSIZE = 200,
   FILEGROWTH = 20)
LOG ON 
( NAME = demolog1,
   FILENAME = 'l:\data\demo_log1.ldf',
   SIZE = 100MB,
   MAXSIZE = 200,
   FILEGROWTH = 20)
GO

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

Советы и рекомендации для подсистемы ввода-вывода

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

Заключение

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

Лекция 6. Планирование мощности системы

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

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

Виды планирования мощности

Планирование мощности имеет две формы: предварительное планирование мощности (pre-capacity planning) и последующее планирование мощности (post-capacity planning). В задачи предварительного планирования мощности, известного также под названием планирование состава системы (sizing), входит прогнозирование требований к аппаратуре, при соблюдении которых система сможет исполнять необходимую работу в заданные сроки (в соответствии с соглашением об уровне обслуживания (SLA, service level agreement)). Соглашения об уровне обслуживания гарантируют заданные длительности времени отклика для тех или иных функций системы, т.е. длительность исполнения каких-либо действий или транзакций.

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

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

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

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

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

Благодаря исследованиям при последующем планировании мощности можно также получить информацию, нужную для настройки системы. Информация для настройки системы, например, о вводе-выводе обработки запросов, поступающих на массивы дисковых накопителей, получается на основе анализа исторических данных о производительности и может применяться для принятия решений об изменениях конфигурации системы, необходимых для повышения производительности. Пользуясь этой информацией, вы можете выявить "узкие места", влияющие на производительность, например, слишком большую активность на одном из массивов дисковых накопителей (по сравнению с другими массивами). Так, добавление новых пользователей вызывает увеличение объема доступа к таблицам базы данных. Количество таблиц, к которым обращаются пользователи, и частота этих обращений могут отслеживаться и регистрироваться. Эта информация будет полезна при решении вопроса, может ли перемещение этих таблиц в другое место предотвратить появление "узкого места" в дисковой подсистеме.

Исторический обзор планирования мощности

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

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

Во время этого периода аналитики создавали методики для предсказания использования ресурсов существующих систем. Внешне этот процесс казался менее интересным, но он оказался таким же сложным, так как не существовало ни методик тестирования, ни инструментальных средств для сбора нужных данных. Ученые-компьютерщики (такие как д-р Джеффри Бузен [Jeffrey Buzen] – родоначальник теории планирования мощности) еще только разрабатывали теории об использовании ресурсов компьютеров и исследовали вопрос, как можно выполнять эти вычисления.

С 1980-х годов первоначальные тестовые модели развились в тесты стандартных нагрузок, такие как тесты ST1, TP1 и Debit/Credit, но усилия в то время были направлены на выявление аппаратуры с наивысшей производительностью для рекламных целей, а не на разработку стандартных моделей нагрузки от приложений, которые можно было бы использовать при предварительном планировании и поддержке систем. Потребители еще не могли пользоваться этими тестами для сравнения аппаратуры систем, потому что они работали в различных ситуациях. В ответ на эти нужды потребителей возник консорциум представителей компьютерной промышленности, "Совет по производительности обработки транзакций" (Transactional Processing Performance Council). Этот Совет задал стандарты обработки транзакций для более чем 45 производителей оборудования и программного обеспечения. Эти тесты часто могут показать относительные возможности оборудования и программного обеспечения для баз данных; к сожалению, они не могут помочь при предварительном планировании нагрузки от работы приложений.

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

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

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

Обработка транзакций

В данном разделе мы изучим, как выполнять анализ тенденций использования сервером базы данных ресурсов процессоров, памяти и дисков. Это нужно, чтобы правильно выбирать систему для нужного приложения. Сервер базы данных выполняет только функции работы с базой данных: при своей работе этот сервер выполняет только транзакции. При исполнении оператора SELECT или UPDATE сервер базы данных интерпретирует данные операторы как последовательности операторов чтения и записи. На самом деле, любая транзакция может быть разбита на чтения и записи в базу данных. На этом атомарном уровне сервер базы данных обрабатывает операции ввода-вывода. Нужно выбрать систему, способную обращаться с транзакциями различных видов и объемов, и с порождаемыми ими операциями ввода-вывода. Основными типами транзакций являются системы оперативной обработки транзакций (OLTP, on-line transaction processing) и системы поддержки принятия решений (DSS, decision support system).

Транзакции систем оперативной обработки транзакций

Транзакции систем оперативной обработки транзакций (OLTP) являются компонентами рабочей нагрузки, исполнение которых ожидается за короткие промежутки времени, так как они взаимодействуют с базой данных в режиме реального времени или в режиме "он-лайн". Другими словами, эти транзакции будут непрерывно обновлять базу данных, основываясь на наиболее свежей доступной информации, чтобы следующий пользователь мог бы быть уверен в том, что эта информация является наиболее свежей. Например, в системе ввода заказов вся информация, относящаяся к складскому учету, хранится в таблицах, распределенных по дисковой системе, и база данных может работать в режиме "он-лайн". Доступ к информации в базе данных получает каждый пользователь. Таблицы базы данных, такие как Таблица_изделий или Таблица_складских_запасов, содержат наиболее свежую информацию о разновидностях и об имеющемся количестве продаваемых товаров. Таким образом, когда поступает заказ на некоторое количество какого-либо товара, вы можете произвести доступ к таблицам базы данных, чтобы выяснить, имеется ли этот товар и сколько его осталось на складе, чтобы не продать отсутствующий товар.

Типичный сценарий предварительного планирования мощности для подобных систем обработки транзакций для сбора специальной информации предусматривает опрос людей. Вы должны провести беседы с проектировщиком базы данных, с разработчиком приложения и с представителем управленческого персонала. Эти люди могут дать начальные и корректирующие сведения о предполагаемом объеме обрабатываемых транзакций и о времени суток, когда предполагается обработка этих транзакций (например, 25 тысяч транзакций должны быть обработаны в течение 8-часового рабочего дня), сведения о количестве одновременно работающих пользователей, о времени пиковой нагрузки (времени суток, когда нагрузка на систему максимальна). Возможно, эти опросы окажутся самой важной частью процесса предварительного планирования мощности.

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

Банкоматы

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

Транзакции систем поддержки принятия решений

Другим типом систем обработки транзакций являются системы поддержки принятия решений (DSS). Транзакции систем поддержки принятия решений возвращают большие объемы информации и требуют для своей обработки гораздо больше времени, чем транзакции OLTP. Для обработки транзакции DSS могут понадобиться часы или даже дни. В качестве примера системы поддержки принятия решений можно привести архив складских запасов, запись в который производится редко, только при его обновлениях. Такие системы обычно снабжают информацией сотрудников-управленцев, чтобы они могли принимать важные решения, например, о развитии бизнеса или о необходимом уровне складских запасов. В качестве другого примера можно привести используемую военно-воздушными силами США систему поддержки принятия решений, информирующую руководящий состав ВВС о текущем состоянии, расположении и вооружении реактивных истребителей, бомбардировщиков и людей.

Как мы уже говорили, транзакции DSS обычно не завершаются за то же время, что и транзакции OLTP. Транзакции DSS обрабатываются гораздо дольше, потому что они извлекают гораздо больший объем данных. Так как транзакции OLTP извлекают необходимые данные по уникальному ключу (например, по номеру потребителя), то они начинают и завершают запрос с информацией, относящейся только к этому ключу. У транзакций DSS запрос не начинается с уникального ключа, наоборот, он начинает работу от начала таблицы базы данных и продолжает работать, пока не просмотрит все данные в базе данных. Транзакции DSS также включают в себя соединения таблиц, связываясь для получения дополнительной информации с другими таблицами.

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

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

Практические советы

Квартальные продажи

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

Принципы планирования мощности

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

Примечание. Установившимся режимом называют ожидаемую нагрузку на центральный процессор в течение вашего рабочего дня. Если вы предполагаете, что в течение рабочего дня процессор будет использоваться на 55%, то это и есть установившийся режим. Если в этот день был час, в течение которого процессор был загружен на 90%, то этот час называется периодом пиковой нагрузки.

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

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

Использование мощности центрального процессора

Еще одна причина, по которой надо создавать и поддерживать резерв мощности компьютера, связана с теорией "загиба кривой" (knee of the curve theory). Если объяснять просто, эта теория предсказывает, что загруженность системы работой непосредственно влияет на образование очередей, а так как длина очередей непосредственно связана со временем отклика (фактически, длина очередей является частью формулы для расчета времени отклика), то загруженность системы оказывает непосредственное влияние на время отклика. Загибом кривой называется точка, начиная от которой такие показатели, как время отклика или длительность очередей, переходят от линейного роста к экспоненциальному или асимптотическому (с уходом в бесконечность при приближении нагрузки к некоторому конечному значению) росту.

Практические советы

Использование мощности и время отклика на примере супермаркета

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

Предположим ту же ситуацию, но в 5 часов вечера, время наибольшей нагрузки на супермаркет. Теперь, когда вы подойдете к кассе, перед вами будут стоять в очереди восемь человек (т.е. длина очереди равна 8). Теперь ваше время отклика будет равно сумме времен отклика каждого из восьми людей перед вами (которые могут варьировать в зависимости от количества покупок, от оплаты банковским чеком или наличными и т.д.) плюс ваше собственное время обслуживания. Использование мощности кассира в 5 часов вечера тоже гораздо больше, чем в 3 часа утра, непосредственным следствием чего и является рост очереди и, следовательно, общее время вашего ожидания (время отклика).

Сравнение линейного и экспоненциального роста

Обычно мы стремимся добиться, чтобы система работала в линейном режиме, т.е., чтобы рост очередей был бы линейным. Из рисунка 6-1 видно, что линейный рост является равномерным ростом очередей в зависимости от роста загруженности системы. Согласно одному практическому правилу, рост очередей остается линейным, пока центральный процессор используется не более чем на 75%.

Впрочем, иногда при установившемся режиме центральный процессор может быть загружен и более чем на 75%. У такой работы имеются некоторые недостатки – в частности, из-за такой высокой загруженности рост длины очередей может стать экспоненциальным. Экспоненциальный рост – это рост в геометрической прогрессии (см. рис. 6.2).

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

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


Рис. 6.1.  Линейная зависимость от загруженности центрального процессора

Экспоненциальный рост в зависимости от загруженности центрального процессора


Рис. 6.2.  Экспоненциальный рост в зависимости от загруженности центрального процессора

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

Время отклика

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

Зависимость времени отклика от загруженности центрального процессора


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

Недопущение выхода за точку загиба кривой (в нашем примере – 75% мощности процессора) является одним из наиболее важных принципов предварительного планирования мощности, и его нужно соблюдать при определении количества центральных процессоров, нужных для вашей системы. Например, допустим, при предварительном планировании мощности системы, вы оценили, что потребность в ресурсе процессора составит 180% от мощности процессора. Вы можете мучиться из-за очень плохой производительности, а можете запустить два процессора с 90% загруженностью их мощности (на 15% выше точки загиба кривой). Но еще лучше было бы запустить три процессора, загрузив их на 60% мощности, тогда их загруженность будет на 15% ниже точки загиба кривой.

Этот же принцип применяется и к другим элементам системы, например, к дискам. У графиков для дисков точка загиба расположена не так, как у графиков для процессоров, она находится где-то при 85% загруженности их мощности. Эта пороговая величина (85%) относится и к вместимости, и к производительности ввода-вывода дисковых накопителей. Например, 9 Гб диски не должны содержать более 7,65 Гб данных, хранящихся на нем одновременно. Это ограничение на объем хранимых данных может послужить как резерв для роста, но оно более важно для сокращения времени отклика, потому что время поиска для дисков, заполненных полностью, становится больше, увеличивая тем самым суммарное время отклика. В соответствии с этим же правилом, если дисковый накопитель имеет производительность обмена данными 70 операций ввода-вывода в секунду, то его не следует применять в условиях, когда темп ввода-вывода постоянно превышает 60 операций ввода-вывода в секунду (при установившемся режиме работы). Следуя этим правилам, вы сможете минимизировать суммарное время отклика и получить наибольшую производительность своей системы, так как ваши процессоры и диски используются не с полной загруженностью. Кроме того, ваша система сохранит резервы мощности, которые пригодятся при работе в периоды пиковых нагрузок.

Примечание.Помните, что для оптимальной производительности нужно загружать центральный процессор не более чем на 75%, а диски – не более чем на 85%.
Обращения к отсутствующим страницам виртуальной памяти

Для процессора и дисков надо не допускать превышения их загруженности выше точки загиба, это важный принцип предварительного планирования мощности. А что можно сказать о памяти? Для предварительного планирования памяти нужно рассмотреть обращения к отсутствующим страницам виртуальной памяти (page faulting). Обращения к отсутствующим страницам – это нормальное явление при обычном функционировании системы, оно применяется для доступа к данным на диске. Если системе потребуется что-нибудь из памяти (страница с кодом программы или с данными) и будет иметься нужная страница памяти, то произойдет логическое событие ввода-вывода, означающее, что код или данные считываются из памяти, и транзакция, которой понадобился этот программный код или данные, будет обработана.

А что произойдет, если нужного кода или страницы с данными не окажется в памяти? В этом случае придется выполнить физический ввод-вывод и прочитать нужную страницу с диска. Эта задача выполняется при помощи обращения к отсутствующей странице. Система, если в ее рабочем наборе оперативной памяти не найдется нужная страница с кодом программы или с данными, выдаст прерывание обращения к отсутствующей странице (page fault interrupt). Обработка обращения к отсутствующей странице прикажет другой части системы доставить программный код или данные с физического диска. Другими словами, если нужная вашей системе страница с кодом или данными отсутствует в памяти, то система выполнит обращение к отсутствующей странице, которое прикажет другой части системы выполнить физическую операцию ввода-вывода и доставить нужную страницу с диска. Обращение к отсутствующей странице не повлечет доставку нужной страницы с диска, если эта страница находится в списке резерва (standby list) и, следовательно, уже находится в оперативной памяти, или если она находится в пользовании у другого процесса, с которым она может совместно использоваться (разделяться).

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

В вашей системе могут возникать три типа обращений к отсутствующим страницам:

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

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

Страничный обмен. При внесении изменений в страницу данных (в результате чего она становится "недействительной" (dirty page, "черновой" страницей)), производится двухэтапный обмен страниц (page fault swap), при котором система не только доставляет новые данные с диска, но и записывает измененные данные из памяти на диск. Для выполнения этого двухэтапного обращения к отсутствующей странице потребуется две физических операции ввода-вывода, но это гарантирует сохранение всех измененных данных. Если обмен страниц будет происходить слишком часто, то он может стать единственным наиболее значительным фактором, ухудшающим длительность времени отклика. Помните, что при обмене страниц происходит передача данных целиком всей страницы, даже если на самом деле нужно передать лишь несколько байтов. Обмены страниц, вызванные обращениями к отсутствующим страницам, требуют больше времени, чем просто обращения к отсутствующим страницам, потому что для них требуется по два физических ввода-вывода. Поэтому вы в своей системе должны стараться минимизировать количество обменов из-за обращений к отсутствующим страницам.

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

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

Планирование мощности памяти

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

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

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

Примечание. Обычно для каждого из пользователей требуется выделять по 500 Кб памяти, потому что эта память необходима для теневого процесса (shadow process) пользователя. Теневой процесс – это пользовательский процесс, который имеется для каждого из пользователей системы.

Затем вам надо знать, какую операционную систему вы будете применять. В нашем случае эта операционная система – Microsoft Windows 2000, для которой нужно 20 Мб памяти. Поэтому теперь вам понадобится уже 45 Мб памяти. Вам также надо будет узнать размер программы базы данных, которая будет у вас работать, в нашем случае – Microsoft SQL Server, для которого нужно 5,5 Мб памяти. Итого теперь требуется 50,5 Мб памяти.

И последняя информация, которая вам понадобится, – размер области памяти для обработки базы данных. Эта область состоит из двух элементов: области журнала и кэша базы данных. Область журнала содержит информацию о выполняющихся действиях записи. Эта область очень важна, потому что в случае сбоя системы во время исполнения транзакции в ней сохранится информация для восстановления образа данных перед транзакцией, т.е. образа базы данных, бывшего до того, как произошел сбой. Область журнала имеет также названия "аудиторский след", "контрольный журнал" (audit trail).

Кэш базы данных представляет собой специальную область вашей системы. Через нее передаются все данные, обрабатываемые вашей системой. Чем кэш крупнее, тем больше будет процент успешных обращений к нему (попаданий в кэш). Процент успешных обращений к кэшу – это вероятность, с которой ваша система находит нужные данные в оперативной памяти; очевидно, что вы хотели бы иметь максимально большой процент попаданий в кэш. Обращения к данным, отсутствующим в кэше, похожи на обращения к отсутствующим страницам памяти тем, что нужная информация должна быть доставлена системой и помещена в память кэша. Поэтому, если область кэша окажется слишком маленькой, то будет происходить физический ввод-вывод, потому что системе придется обращаться к диску и доставлять данные, отсутствующие в кэше. Этот физический ввод-вывод, несомненно, увеличит время отклика для транзакций.

Для расчета размера кэша воспользуйтесь следующей формулой:

размер кэша  =  (размер блока кэша) х (количество блоков в кэше)

Размер блока кэша – это объем данных, передаваемых при одной операции ввода-вывода. Помните, что в SQL Server уже задан стандартный размер блока кэша, равный 8 КБ. Количество блоков в кэше – это просто выбираемый вами размер кэша (в блоках). Для систем оперативной обработки транзакций (OLTP) размер блока следует выбирать поменьше, потому что объем передаваемых данных – небольшой, а чем меньше объем передаваемых данных, тем меньше будет и время, необходимое для исполнения транзакции. В системах поддержки принятия решений (DSS) размер блока должен быть гораздо больше, потому что объем передаваемых данных будет гораздо больше, из-за чего уменьшится количество операций ввода-вывода.

Примечание. Никакая настройка размера кэша не может гарантировать успешность обращений к кэшу от 90% и выше. Есть хорошее практическое правило, согласно которому для малых систем надо иметь кэш размером около 25 Мб, для систем среднего размера – 70 Мб, а для больших систем – 215 Мб. Для систем с очень большими базами данных (около 300 Гб) для получения желаемого процента попадания в кэш понадобится кэш объемом около 3 Гб.

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

минимальная память = (системная память) + (пользовательская память) + 
  +(память процесса базы данных)

Здесь системная память – это объем памяти, необходимой для операционной системы и SQL Server, пользовательская память – это по 500 Кб памяти, выделяемых каждому из одновременно работающих пользователей, а память процесса базы данных – это память, необходимая для журнала и кэша.

Эта простая формула может применяться для расчета минимального необходимого объема памяти, нужного для нормальной работы как приложений оперативной обработки транзакций (OLTP), так и для систем поддержки принятия решений (DSS). Для систем DSS нужно выбирать более крупные размеры блоков кэша, потому что приложения DSS выполняют полное сканирование таблиц в режиме последовательного чтения. Увеличив размер блока, можно увеличить количество записей, считываемых за одну физическую операцию ввода-вывода. Для систем DSS кэш не используется, потому что все операции ввода-вывода будут физическими.

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

Примечание. Следует стремиться приблизить успешность попаданий в кэш к 100%, насколько это возможно (и этот показатель не должен быть меньше 90%).
Сбор данных об использовании памяти

После того как система, для которой производилось предварительное планирование, будет сконфигурирована и настроена, вам надо будет методично собирать данные об использовании ее памяти. Эти данные можно использовать для проверки соответствия созданной вами системы требованиям соглашения об уровне обслуживания, таким как время отклика или загруженность памяти и центрального процессора. Данные можно собрать при помощи просто Microsoft Performance Monitor (Монитора производительности) для среды Microsoft Windows NT.

Примечание. В Microsoft Windows 2000 "монитор производительности" называется не Performance Monitor, а System Monitor.

Помните, что данное исследование является анализом для планирования производительности и поэтому должно производиться достаточно долго. Измерения будут длиться часами (в большинстве случаев – 24 часа), и интервал измерений тоже должен быть установлен равным 24 часам. Для задач планирования производительности нужно заносить в базы данных о производительности по одной записи в сутки. Критерии производительности, называющиеся счетчики (counters), выбираемые вами для мониторинга, будут усредняться по интервалам измерений. Счетчики для планирования мощности памяти, находятся в объекте Memory (в "мониторе производительности" объектом называется набор счетчиков).

Примечание. Чтобы запустить Performance Monitor (Монитор производительности) нажмите сначала мышью на экранную кнопку Start. Затем выберите Programs, Administrative Tools (Common) и Performance Monitor. В окне Performance Monitor в меню Edit выберите Add To Chart (Добавить к схеме). Диалоговое окно Add To Chart может применяться для выбора объектов и счетчиков, которые нужно отслеживать. Для получения дополнительной информации нажмите на кнопку Help в окне Performance Monitor.

Среди счетчиков монитора производительности имеются следующие:

Примечание. Счетчик Available Memory можно просматривать в окне монитора производительности Performance Monitor в составе объекта Memory. Кроме того, в мониторе производительности Windows 2000 Server этот счетчик представлен трижды: Available Bytes, Available Kbytes, Available Mbytes. Также он доступен из Task Manager’а (Диспетчер задач), если открыть вкладку Performance и наблюдать за доступной памятью в течение периода пиковой нагрузки. (Чтобы получить доступ к Task Manager, нажмите правой кнопкой мышки на панель задач и выберите Task Manager в контекстном меню.)

Вам следует хотя бы включить в общий процесс сбора данных для планирования мощности, наблюдение за счетчиками Available Memory и Page Faults/sec.

Анализ данных о памяти

После сбора данных их можно отобразить в графической форме, чтобы предсказать, какими они станут в будущем. График на рисунке 6-4 показывает пример упреждающего анализа. В этом примере показаны данные о свободной памяти, собранные с 22 октября 1999 года по 14 января 2000 года. При помощи Microsoft Excel эти данные были нанесены на график и построена линия тренда. Зубчатая линия обозначает историю фактического использования памяти, а прямая линия обозначает линейный тренд использования памяти. Как видите, этот анализ предсказывает, что 18 февраля 2000 года у системы останется менее 6% свободной памяти.

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

Объем свободной памяти (линейная закономерность)


Рис. 6.4.  Объем свободной памяти (линейная закономерность)

Обращения к отсутствующим страницам (линейная закономерность)


Рис. 6.5.  Обращения к отсутствующим страницам (линейная закономерность)

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

Планирование мощности процессора

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

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

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

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

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

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

Отказоустойчивость

Сейчас большинство компьютерных фирм добиваются отказоустойчивости при помощи поддержки технологии RAID (Redundant Array of Independent Disks, "массивы независимых дисковых накопителей с избыточностью"). (О технологии RAID см. лекцию 5.) Запомните, что чаще всего применяются следующие уровни RAID:

Так как в RAID 0 не применяется дублирование данных, то для них достаточно одиночного повреждения – при отказе дискового накопителя вы потеряете данные на нем и, следовательно, во всей базе данных. Схема массива RAID 0 показана на рис. 5.9. В RAID 1 обеспечивается зеркальное дублирование диска базы данных. При отказе какого-либо дискового накопителя остается резервный накопитель, весь заполненный данными, такими же, какие были и на отказавшем дисковом накопителе. Если вы решите применять массивы RAID 1, то можно воспользоваться достоинствами параллельного поиска (split seek, см. лекцию 5), благодаря которому система может выполнять поиск данных одновременно сразу на двух дисковых накопителях, что значительно повышает скорость поиска и, следовательно, уменьшает время отклика для транзакций. Схема массива RAID 1 показана на рис. 5.10.

Выбор уровня RAID непосредственно влияет на количество операций дискового ввода-вывода, т.к. разные уровни RAID отличаются количеством записей на диски. Например, для RAID 1 по сравнению с RAID 0 требуется в два раза больше записей на диск. Если пользователь задаст транзакцию, требующую 50 чтений и 10 записей, то при использовании RAID 1 количество записей вырастет до 20.

Если конфигурация RAID 0 имеет два дисковых накопителя, то равноценная конфигурация RAID 5 должна иметь три дисковых накопителя. В конфигурациях RAID 5 применяется слой данных (stripe), содержащий информацию о данных на двух других накопителях, который может быть использован для восстановления данных с отказавшего диска. Схема массива RAID 5 показана на рис. 5.11. Эта схема защиты базы данных хороша и по показателям производительности и по цене. Каждая запись в RAID 5 удваивает количество чтений и количество записей для каждой обрабатываемой транзакции, потому что каждая транзакция должна быть записана на два диска – должен быть прочитан слой контроля по четности, изменен в соответствии с новыми данными, а затем снова записан. Эта избыточность несколько увеличивает длительность времени отклика.

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

Для RAID 0:

количество операций ввода-вывода = (количество чтений на одну транзакцию) + 
+(количество записей на одну транзакцию)

Если транзакция содержит 50 чтений и 10 записей, то общее количество операций ввода-вывода для уровня RAID 0 будет равно 60.

Для RAID 1:

количество операций ввода-вывода = 
(количество чтений на одну транзакцию) + 
(2 х [количество записей на одну транзакцию])

Если транзакция содержит 50 чтений и 10 записей, то общее количество операций ввода-вывода для уровня RAID 1 будет равно 70.

Для RAID 5:

количество операций ввода-вывода = 
3 х (количество операций ввода-вывода на одну транзакцию)

Если транзакция содержит 50 чтений и 10 записей, то общее количество чтений будет равно 150, а общее количество записей будет равно 30. Общее количество операций ввода-вывода для уровней RAID 5 будет равно 180.

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

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

загруженность центрального процессора = 
(темп ввода-вывода) х (время обслуживания) х 100

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

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

  1. Рассчитайте общее количество операций чтения, которые будут выполняться в системе, при помощи следующей формулы:
    общее количество чтений = 
    (количество чтений на одну транзакцию) х (общее количество транзакций)
  2. Определите, сколько из этих операций чтения будут физическими операциями ввода-вывода, а сколько – логическими операциями ввода-вывода, пользуясь следующими формулами:
    общее количество логических чтений = 
    (общее количество чтений) х (процент успешных обращений к кэшу)
    
    общее количество физических чтений = 
    (общее количество чтений) – 
    -(общее количество логических чтений)
  3. Преобразуйте общие количества каждой из разновидностей операций чтения в количество чтений в секунду при помощи следующих формул:
    количество логических чтений в секунду = 
     (общее количество логических чтений) / (рабочий период)
     
    количество физических чтений в секунду = 
     (общее количество физических чтений) / (рабочий период)
    Здесь рабочий период обозначает длительность времени (в секундах), в течение которого должна быть выполнена работа.
  4. Рассчитайте объем времени работы центрального процессора, истраченный на каждую из разновидностей операций чтения при помощи следующих формул:
    время для выполнения логических чтений = 
    (количество логических чтений в секунду) х 
    (длительность операции логического чтения)
    
    время для выполнения физических чтений = 
    (количество физических чтений в секунду) х 
    (длительность операции физического чтения)
    Здесь длительность операции логического чтения обозначает время, необходимое для обработки одного логического чтения, а длительность операции физического чтения – время, необходимое для обработки одного физического чтения. Эти длительности операций чтения можно узнать при помощи Performance Monitor (см. врезку "Как узнать длительность операций чтения" после данного перечня инструкций по расчету.)
    Примечание.Длительность операций чтения обычно составляет 0.002 секунды для физического чтения и 0.001 секунды для логического чтения.
  5. Рассчитайте загруженность центральных процессоров для различных видов операций чтения при помощи следующей формулы:
    загруженность = (темп чтения) х (время обслуживания) х 100
    Можно рассмотреть отдельно загруженность логическими или физическими операциями чтения, применив следующие формулы:
    загруженность операциями логического чтения = 
    (количество логических чтений в секунду) х 
    (длительность операции логического чтения) 
    
    загруженность операциями физического чтения = 
    (количество физических чтений в секунду) х 
    (длительность операции физического чтения)
    Эта информация полезна, когда надо определить, а не слишком ли много нагрузки вызвано операциями физического чтения. Если это так, то можно настроить размер кэша, чтобы сдвинуть равновесие в сторону операций логического чтения.
  6. Рассчитайте общее количество операций записи, которые будут выполняться в системе, при помощи следующей формулы:
    общее количество записей = (количество записей на одну транзакцию) х 
    (общее количество транзакций) х (множитель RAID)
    Здесь множитель RAID обозначает общее количество операций записи, выполняемых рабочей нагрузкой за период обработки.
  7. Определите, сколько операций записи в секунду будут проходить через систему, пользуясь следующей формулой:
    количество записей в секунду = (общее количество записей) / 
    (рабочий период)
    Здесь рабочий период по-прежнему обозначает длительность времени (в секундах), в течение которого должна быть выполнена работа.
  8. Рассчитайте суммарное время работы центрального процессора, истраченное на обработку операций записи, пользуясь следующей формулой:
    время центральных процессоров для выполнения записей = 
    (количество записей в секунду) х 
    (длительность обработки центральным процессором одной операции записи)
  9. Рассчитайте загруженность операциями записи, пользуясь следующей формулой:
    загруженность операциями записи = (количество записей в секунду) х 
    (длительность обработки центральным процессором одной операции записи) х 100
  10. Рассчитайте суммарную загруженность центральных процессоров для каждого из типов транзакций, пользуясь следующей формулой:
    загруженность центральных процессоров  = 
    ((загруженность операциями логического чтения) + 
    (загруженность операциями физического чтения) +
    (загруженность операциями записи)) х 100
    Этот расчет должен быть выполнен для каждого типа транзакций, допустимых в вашей системе. Например, если ваша система – банковская, то в ней должны иметься транзакции для снятия денег со счетов, для помещения денег на счета и справки о состоянии баланса. Для точного предварительного планирования мощности центральных процессоров в вашей системе вычисления о нагрузке должны быть выполнены раздельно для каждого из этих трех типов транзакций.
  11. И наконец, рассчитайте суммарную загруженность центральных процессоров, пользуясь следующей формулой:
    суммарная загруженность центральных процессоров = 
    сумма загруженностей для всех отдельных видов транзакций
    Если суммарная загруженность центральных процессоров превысит 75-процентный порог, то вам следует установить в свою систему дополнительные центральные процессоры, которые уменьшат суммарную загруженность на один процессор в соответствии со следующей формулой:
    суммарная загруженность на один процессор  = 
    (суммарная загруженность центральных процессоров) / 
    (количество центральных процессоров)
    Добавьте столько центральных процессоров, чтобы суммарная загруженность на один процессор снизилась ниже 75%. Например, если суммарная загруженность центральных процессоров окажется равной 180%, то нужно применять три центральных процессора. В результате для трехпроцессорной системы суммарная загруженность на один процессор будет равна 60%.
Примечание.Вы, наверное, удивлены, почему ни в одной из наших формул не присутствует скорость работы процессоров. На самом деле, она входит в формулы, но в неявном виде. Скорость процессоров учтена во времени обслуживания – длительности времени, необходимого для обработки транзакции.
Как узнать длительность операций чтения

Длительность операций чтения в вашей системе можно определить при помощи утилиты Performance Monitor. Включите Diskperf при помощи следующей команды, вводимой в окне MS-DOS:

diskperf -y

Затем запустите Performance Monitor и наблюдайте в объекте Physical Disk за счетчиками Avg. Disk sec/Read и Avg. Disk sec/Write. Обратите внимание, что эти счетчики дают вам среднее время для операций физического чтения. Для определения длительности логического чтения операций эти счетчики неприменимы.

Сбор данных о загруженности одного центрального процессора

После того как ваша система будет реализована, потребуется тщательно следить за загруженностью центрального процессора, так же, как и за памятью. В Performance Monitor имеется множество счетчиков, связанных с измерением загруженности отдельных центральных процессоров. Эти счетчики находятся в объекте Processor. Для задач предварительного планирования мощности наиболее полезны следующие счетчики:

Для предварительного планирования мощности могут понадобиться не все эти показатели; выбор применяемых показателей зависит от глубины проводимого вами исследования. По крайней мере, следует использовать счетчик % Processor Time.

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

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

Анализ данных о загруженности центральных процессоров

Информация, собранная при помощи счетчиков Performance Monitor, может применяться для прогнозирования увеличения нагрузки на отдельные центральные процессоры, следствием которого станет увеличение времени отклика для этого процессора. На рис. 6.6 показан график загруженности центрального процессора (значения загруженности для разных дат). Обратите внимание, что тренд загруженности центрального процессора растет и достигнет 75% порога 18 февраля 2000 года.

 Линейный прогноз загруженности центрального процессора


Рис. 6.6.  Линейный прогноз загруженности центрального процессора

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

Планирование мощности дисковой подсистемы

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

Многие люди бывают удивлены количеством дисковых накопителей, необходимых для их баз данных. Но дополнительные накопители дают дополнительные точки доступа к данным. Если вы имеете только одну точку доступа к данным, то вы создаете узкое место ("бутылочное горлышко"). Так как через это узкое место придется проходить всем транзакциям, то длительность откликов будет увеличиваться. Есть такое практическое правило – имейте как можно больше точек доступа к данным. Чем больше точек доступа к данным будет у вас, тем меньше станет вероятность возникновения узкого места из-за недостаточного количества дисковых накопителей. Кроме того, вы сможете генерировать больше операций ввода-вывода в секунду – чтобы система могла выдерживать большой поток операций ввода-вывода, необходимый для больших баз данных.

Предположим, ваша система управляет базой данных объемом 10 Гб и в ней генерируется 140 операций ввода-вывода в секунду. Из правила 85% об объеме дисковой памяти следует, что вам понадобится дисковый накопитель объемом примерно в 12 Гб, чтобы его хватило для хранения базы данных. Теперь взглянем на требования к дисковым накопителям с точки зрения производительности ввода-вывода. Если дисковые накопители имеют производительность ввода-вывода 70 операций в секунду, то с учетом правила 85% для производительности каждого из накопителей вам потребуются три накопителя. Поэтому, так как анализ производительности ввода-вывода требует применения трех накопителей (максимально), мы должны применять три дисковых накопителя, суммарный объем которых составит 12 Гб, а производительность каждого будет 70 операций ввода-вывода в секунду.

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

Примечание. При предварительном планировании дисковой подсистемы всегда соблюдайте "правило 85%" и для объема базы данных, и для производительности операций ввода-вывода генерируемых пользователями. Использование каких-либо других расчетов вызывает увеличение количества дисковых накопителей. Также помните, что 85% является максимально допустимым значением использования дисков. На практике следует загружать диски менее чем на 85%. И помните, что слишком большое количество операций ввода-вывода в секунду вызовет появление узких мест и, следовательно, увеличит длительность времени отклика.

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

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

Дисковые накопители для Windows 2000 и SQL Server

Сначала надо рассчитать количество дисковых накопителей, необходимых для хранения первой категории данных – операционной системы Windows 2000 Server и СУБД SQL Server. Обычно для этого применяют отдельный набор томов RAID 1 (дисковые накопители с зеркальным дублированием), чтобы обеспечивать наиболее быстрое восстановление после отказов. Количество дисковых накопителей может быть разным в зависимости от объема хранимой на них информации, но операционная система Windows 2000 и СУБД SQL Server обычно умещаются на одном диске. Наш простой метод расчета можно выразить следующей формулой:

диски для операционной системы и SQL  = 
(диски для Windows 2000 Server и SQL) х (множитель RAID)

В данном случае, для дисковых накопителей с зеркальным дублированием, результатом формулы будет 2 диска (Windows NT и SQL Server уместятся на одном диске, а другой будет служить дублирующим диском массива RAID 1). Конфигурация тома для операционной системы как RAID 5 или как RAID 0 не рекомендуется. Применять RAID 5 имеет смысл, только когда для собственно хранения данных требуется более одного диска, и вам следует стремиться к как можно более быстрому восстановлению операционной системы и программы СУБД.

Дисковые накопители для файлов журналов

Затем вам потребуется рассчитать количество дисковых накопителей, необходимых для поддержки системных файлов журналов. Это количество сильно зависит от общего количества операций записи за одну секунду, вызываемых вашими транзакциями. Помните, что ценность информации, содержащаяся на этих дисках, очень велика. Она представляет собой "аудиторский след" (контрольный журнал) или "образ до сбоя", который понадобится, если что-нибудь случится с базой данных. При помощи аудиторского следа вы сможете отменить транзакции, незавершенные из-за отказа диска. Расчет количества операций записи уже был выполнен при предварительном планировании мощностей процессоров. Пусть, например (эти числа взяты произвольно), транзакции вызывают 1 500 000 операций записи при использовании тома RAID 0. Если мы решим, что для дисковых накопителей, хранящих журнал, надо применять RAID 1, то получится, что за 8-часовой рабочий день должно быть выполнено 3 000 000 операций записи, или 104,16 операций записи за одну секунду. (Помните, что по сравнению с RAID 0, массивы RAID 1 удваивают количество операций записи на одну транзакцию.) Для расчета необходимого количества дисковых накопителей примените следующую формулу:,

диски для журналов  = 
(количество записей в секунду) / (производительность ввода-вывода диска)

Помните, что производительность ввода-вывода диска в данной формуле должна составлять 85% от его паспортной максимальной производительности. Также не забудьте округлить результат деления (количество записей в секунду) / (производительность ввода-вывода диска) до ближайшего целого числа в сторону увеличения. И наконец, не забудьте скорректировать величину количество записей в секунду в соответствии с увеличением количества операций записи, вызванным из-за применения того или иного уровня RAID. Если мы применим 85-процентный потолок к дисковым накопителям, имеющим максимальную производительность ввода-вывода 70 операций ввода-вывода за одну секунду, то получится, что нам надо иметь 1,7 накопителя. Округлив этот результат, мы получим, что нам надо иметь два накопителя.

Дисковые накопители для базы данных

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

Расчет для объема дисковой памяти

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

диски для базы данных  = (объем данных) / (размер диска) + (прибавка RAID)

Помните, что размер диска в данной формуле должен составлять 85% от его паспортной максимальной емкости. Также не забудьте, что для объема данных и размера диска надо применять одинаковые единицы измерения (например, килобайты или мегабайты). Прибавка RAID – это количество дополнительных дисковых накопителей, необходимых для обеспечения отказоустойчивости. Для RAID 1 это число равно количеству дисковых накопителей, необходимых для хранения самой базы данных. Для RAID 5 требуется один дополнительный накопитель. Для нашей 10-гигабайтной базы данных, использующей RAID 5, потребуется два 12 Гб накопителя.

Примечание. Для дисковых накопителей, хранящих базу данных, рекомендуется применять RAID 5.

Расчет для производительности ввода-вывода при доступе к базе данных

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

  1. Рассчитайте общее количество операций чтения, которые будут проходить через систему, применив следующую формулу:
    общее количество чтений = (количество чтений на одну транзакцию) х 
    (общее количество транзакций)
    Предположим, на одну транзакцию у нас производится 500 чтений, а всего будет 50 000 транзакций, тогда всего у нас будет 25 000 000 чтений.
  2. Определите, сколько из этих операций чтения будут физическими операциями ввода-вывода, а сколько – логическими операциями ввода-вывода, пользуясь следующими формулами:
    общее количество логических чтений = (общее количество чтений) х 
    (процент успешных обращений к кэшу)
    
    общее количество физических чтений = (общее количество чтений) - 
    (общее количество логических чтений)
    Предположим, процент успешных обращений к кэшу равен 90%, тогда общее количество логических операций чтения у нас будет равно 22 500 000, а общее количество физических операций чтения будет равно 2 500 000.
  3. Преобразуйте общее количество физических операций чтения в количество чтений в секунду при помощи следующей формулы:
    количество физических чтений в секунду = 
    (общее количество физических чтений) / (рабочий период)
    Здесь рабочий период обозначает длительность времени (в секундах), в течение которого должна быть выполнена работа. Эта величина нужна также для расчета загруженности центрального процессора. Если взять для нашего примера 8-часовой рабочий период, то мы получим 86,8 физических операций чтения в секунду.
  4. Затем рассчитайте общее количество операций записи, которые будут выполняться в системе, при помощи следующей формулы:
    общее количество записей = (количество записей на одну транзакцию) х 
    (количество транзакций) х (множитель RAID)
    Пусть мы имеем 10 операций записи на одну транзакцию и применяем массив RAID 5, тогда общее количество записей будет равно 10 х 50 000 х 3, т.е. 1 500 000 операций записи.
  5. Преобразуйте общее количество физических операций записи в количество операций записи в секунду при помощи следующей формулы:
    количество физических записей в секунду = (общее количество физических записей) / 
    (рабочий период)
    В нашем примере мы имеем 1 500 000 физических операций записи за 8-часовой рабочий период (28 800 секунд), что дает 52,1 физических операций записи в секунду.
  6. Рассчитайте общее количество физических операций ввода-вывода в секунду при помощи следующей формулы:
    количество физических операций ввода-вывода в секунду = 
    	(общее количество физических чтений в секунду) + 
    	(количество физических записей в секунду)
    В нашем примере мы имеем 86,8 физических операций чтения в секунду и 52,1 физических операций записи в секунду, что дает в сумме 138,9 физических операции ввода-вывода в секунду.
  7. Вычислите общее необходимое количество дисковых накопителей по следующей формуле:
    количество дисков для базы данных = 
    	((количество физических операций ввода-вывода в секунду) / 
    	(производительность ввода-вывода одного диска)) + (прибавка RAID)

Помните, что значение производительности ввода-вывода одного диска вы должны брать с учетом правила "85%". Прибавка RAID – это количество дополнительных дисковых накопителей, необходимых для обеспечения отказоустойчивости. Если мы имеем всего 138,9 физических операции ввода-вывода в секунду, а производительность диска составляет 70 операций ввода-вывода в секунду и применяется массив RAID 5, то всего понадобится четыре дисковых накопителя – три для поддержки суммарного ввода-вывода и еще один для обеспечения отказоустойчивости массива RAID 5.

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

Общее количество дисковых накопителей, нужных в системе

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

Практические советы.

Оставляйте себе резервы

Большинство проектировщиков пользуются пороговыми величинами (75% для загруженности центральных процессоров, 85% для использования дисков и т.д.) как максимальными значениями нагрузок. В большинстве случаев желательно применять меньшие величины. Конечно, часто решения в этих вопросах принимают не проектировщики. На решение проектных вопросов могут оказывать влияние такие внешние факторы, как бюджет расходов на покупку вычислительной техники. В качестве хорошего целевого показателя можно принять максимальную загруженность центральных процессоров, равную 65% и использование дисков на 70%. Однако вы можете применять и любые другие значения этих процентов, которые сочтете оптимальными для проектируемого вами типа систем.

Сбор данных об использовании дисков

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

При выполнении исследований последующего планирования загруженности дисков понадобится следить за следующими счетчиками утилиты Performance Monitor, которые вы найдете в объекте PhysicalDisk:

Для запуска Disk Administrator нажмите на экранную кнопку Start, затем выберите Programs, Administrative Tools (Common) и, наконец, Disk Administrator. Для получения дополнительной информации об использовании утилиты Disk Administrator, производительности, нажмите на кнопку Help в окне Disk Administrator.

Анализ данных об использовании дисков

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

Как можно видеть, в начале наблюдений у нас было 2,05 Мб свободного места из общего объема в 6,15 Мб, т.е. диск был заполнен примерно на 67%. 14 января 2000 года объем свободного места на диске уменьшился примерно до 1,5 Мб, т.е. диск заполнился примерно на 75%. Проведя при помощи Microsoft Excel линию тренда, можно спрогнозировать, что 18 февраля 2000 года на диске останется свободно только около 1,3 Мб, т.е. диск заполнился примерно на 83%. Администратор баз данных может принять решение приобрести в этот момент дополнительный диск.

Прогноз (упреждающий анализ) для свободного места на диске


Рис. 6.7.  Прогноз (упреждающий анализ) для свободного места на диске

Планирование мощности сети

Планирование мощности сети мы оставили под конец, потому что изнутри системы вы не сможете получить много информации. Из утилиты Performance Monitor нельзя получить никакие счетчики производительности работы сети, поэтому предварительное планирование сети может оказаться достаточно трудным делом. Сеть обычно является самым слабым звеном в системе, поэтому будьте реалистичны при ее оценке.

Чтобы выполнить предварительное планирование сети, вам понадобится определить, сколько пользователей будут одновременно работать в системе, сколько сообщений (messages) будет проходить за одну секунду и сколько в среднем байт будет содержаться в этих сообщениях. Опираясь на эту информацию, вы можете произвести некоторые оценки минимально необходимой пропускной способности сети. Пусть, например, в нашей системе будут передаваться такие объемы данных: будет 10 пользователей, каждый из которых будет передавать 25 сообщений в минуту. Каждое сообщение будет иметь длину 259 байтов. Можно оценить, что за одну минуту все эти 250 сообщений будут генерировать 64 750 байтов в минуту, т.е. 518 000 битов в минуту, т.е. 8633,33 бита в секунду. Для такой нагрузки подойдет небольшая сеть. Для оценки мощности сети можно применять следующую формулу:

мощность сети = (количество сообщений секунду) х  (длина сообщений) х  
(количество битов в одном байте)

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

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

Сбор данных об использовании сети

При выполнении исследований последующего планирования загруженности сети вам понадобится следить за счетчиком производительности Bytes/Sec Through Network Interface утилиты Network Monitor (Сетевой монитор). Этот счетчик обозначает процент времени, когда линия передачи данных занята.

Примечание. Инструкции по инсталляции утилиты Network Monitor вы найдете в разделе "Installing Network Monitor" справочной системы Windows 2000 Server.
Анализ данных об использовании сети

Для анализа сетевых данных надо сначала рассчитать пропускную способность линии передачи данных (мощность сети), как было показано выше, а затем посмотреть значение счетчика Bytes/Sec Through Network Interface. Зная два этих значения, можно вычислить общую загруженность сети при помощи следующей формулы:

загруженность сети = 
((количество байт, проходящих через сеть за одну секунду) / 
(мощность сети)) х 100

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

Прогноз (упреждающий анализ) для загруженности сети


Рис. 6.8.  Прогноз (упреждающий анализ) для загруженности сети

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

Как выбирать оценочные данные

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

Сбор данных о процессах

Информация о процессах может оказаться очень ценной при создании профилей рабочей нагрузки. Создание профилей рабочей нагрузки – это выяснение, какую именно работу выполняет каждый из пользователей. Performance Monitor имеет много разнообразных счетчиков для выполнения этой задачи. Эти счетчики подобны счетчикам из объекта Processor, но в данном случае они применяются для сбора данных о процессе. Они находятся в объекте Process и перечислены ниже:

Анализ данных о процессах

Анализ этой информации вовсе не так сложен, как вы могли бы подумать. Например, если бы потребовалось провести анализ работ, выполняемых процессами системы, то нам надо было бы собрать данные процессов при помощи, например, счетчика % Processor Time. Этот счетчик позволяет оценить, насколько много внимания система уделяет данной функции. На рис. 6.9 показан рост пользовательского процесса в запросе CalProc, применяемом отделом кредиторских задолженностей.

Эта информация полезна тем, что мы можем спрогнозировать результат от увеличения числа пользователей в отделе кредиторских задолженностей. Линия тренда на данном графике показывает, что процент использования возрастает и достигнет 18 февраля 2000 года 30%. Допустим, в отделе кредиторских задолженностей имеется 10 пользователей, тогда можно оценить в 3% вклад каждого из пользователей в загруженность в феврале. Мы можем сделать вывод, что если в феврале добавить еще трех пользователей, то загруженность для запроса CalProc составит приблизительно 39%.

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

Прогноз (упреждающий анализ) пользовательского процесса


Рис. 6.9.  Прогноз (упреждающий анализ) пользовательского процесса

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

Таблица 6.1. Показатели, доступные в Performance Monitor
Объект Показатели
Processor% Processor Time (статистика для отдельных центральных процессоров)
System% Total Processor Time (усредненные данные для всех центральных процессоров)

Лекция 7. Инсталляция Microsoft SQL Server

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

Теперь, когда вы закончили работы по подготовке к инсталляции, описанные в лекциях 4 и 5, и правильно выполнили предварительное планирование своей системы (в соответствии с объяснениями в лекции 6), можно приступить к инсталляции Microsoft SQL Server 2000. В данной лекции содержатся объяснения о ходе инсталляции и обзор процедуры обновления Microsoft SQL Server от старых версий. А затем, поскольку вы можете применять SQL Server в клиент-серверных окружениях, мы подробно расскажем об инсталляции клиентских утилит на компьютерах-клиентах.

Инсталляция на сервере

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

Локальная инсталляция

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

  1. Вставьте компакт-диск SQL Server в привод для компакт-дисков вашего сервера. Если у вашей операционной системы включена настройка для автоматического запуска компакт-дисков, тогда появится диалоговое окно начальной установки Microsoft SQL Server 2000 (рис. 7.1). Если настройка для автоматического запуска компакт-дисков не включена, тогда нужно вручную запустить программу Autorun.exe, находящуюся в корневой директории компакт-диска.
  2. Если у вас не установлены необходимые дополнительные пакеты операционной системы (service packs, "сервис-пэки") или требуемая версия Microsoft Internet Explorer, или если вы просто хотите посмотреть перечень программных компонент, необходимых для инсталляции, то нажмите на SQL Server 2000 Prerequisites, и тогда откроется диалоговое окно SQL Server 2000 Prerequisites (Предварительные условия для SQL Server 2000). Нажмите на обозначение нужной операционной системы, появится список необходимых программных компонент для нее. Затем нажмите на обозначение программной компоненты, которую вы хотите инсталлировать. Если все необходимое программное обеспечение у вас уже установлено, то переходите к шагу 3.

     Диалоговое окно начальной установки SQL Server


    Рис. 7.1.  Диалоговое окно начальной установки SQL Server

    Примечание.Если вам потребуется инсталлировать Microsoft Internet Explorer или дополнительные пакеты (service packs, сервис-пэки), необходимые для Microsoft Windows 2000 или Microsoft Windows NT 4, то, прежде чем вы сможете продолжить инсталляцию SQL Server, может потребоваться перезагрузка компьютера и повторный запуск Autorun.exe.
    Инсталлировав необходимые программные компоненты, вернитесь в основное диалоговое окно инсталляции SQL Server, нажав на Back (Назад).
  3. Чтобы начать инсталляцию SQL Server, нажмите на SQL Server 2000 Components (Компоненты SQL Server 2000).
  4. Появится диалоговое окно Install Components (рис. 7.2). Чтобы начать инсталляцию основных компонент SQL Server, нажмите на Install Database Server.

     Диалоговое окно Install Components


    Рис. 7.2.  Диалоговое окно Install Components

  5. Появится стартовое окно мастера SQL Server 2000 Installation Wizard. Если у вас работают какие-либо другие программы, то их нужно закрыть. Чтобы продолжить процесс инсталляции, нажмите на Next.
  6. Появится диалоговое окно Computer Name (Имя компьютера). Нажмите сначала на Local Computer, а затем на Next.
  7. Появится диалоговое окно SQL Server 2000 Installation Selection (Выбор инсталляции SQL Server 2000). Для продолжения инсталляции нажмите сначала на Create A New Instance Of SQL Server (Создать новый экземпляр SQL Server), а затем нажмите на Next.
  8. Появится диалоговое окно User Information (Информация о пользователе). Проверьте правильность вашего имени и названия вашей фирмы. Для продолжения нажмите на Next.
  9. Появится диалоговое окно Software License Agreement (Лицензионное соглашение об использовании программного обеспечения). Нажмите на Yes, чтобы согласиться с условиями лицензионного соглашения и продолжить процесс инсталляции.
  10. Появится диалоговое окно CD Key (Ключ компакт-диска). Введите 25-символьный ключ компакт-диска, напечатанный на желтой наклейке на футляре компакт-диска, а затем нажмите на Next.
  11. Появится диалоговое окно Installation Definition (Задание инсталляции). Нажмите на Server And Client Tools (Серверные и клиентские инструментальные средства), а затем нажмите на Next.
  12. Появится диалоговое окно Instance Name (Имя экземпляра). Если вы хотите, чтобы имя этого экземпляра SQL Server отличалось от принятого по умолчанию, то снимите флажок Default и введите с клавиатуры нужное имя. Для продолжения процесса инсталляции нажмите на Next.
  13. Появится диалоговое окно Setup Type (Тип установки)(рис. 7.3), в котором вы можете выбрать тип инсталляции – "типичную" (Typical), "минимальную" (Minimal) или "выборочную" (Custom). В типичную инсталляцию включены все опции (возможности), кроме средств разработки (Development Tools) и полнотекстного поиска (Full-Text Search). При помощи выборочной инсталляции вы можете добавить эти опции, а также отказаться от любых ненужных вам опций. При минимальной инсталляции устанавливаются те же опции, что и при типичной, кроме Upgrade Tools (Средства обновления), Books Online (Справочная документация в электронной форме) и Management Tools (Средства управления).

    В большинстве случаев надо выполнять типичную инсталляцию, поэтому в наших примерах предполагается, что была нажата экранная кнопка Typical. Также вы можете указать местоположение устанавливаемых файлов программ и данных SQL Server, для чего нажимайте на экранные кнопки Browse в группе экранных форм Destination Folder (Целевая папка). Для продолжения нажмите на Next.

  14. Появится диалоговое окно Services Accounts (Учетные записи служб) (рис. 7.4). Вы можете применять как учетную запись Windows NT или Windows 2000, так и администраторскую учетную запись (Administrator account). В любом случае, учетная запись должна иметь права доступа Log on as a service. Если вы не знаете, как создавать такие учетные записи, посоветуйтесь со своим системным администратором или почитайте документацию по Windows NT или Windows 2000. В соответствующие поля окна введите с клавиатуры имя и пароль созданной вами учетной записи службы SQL Server. Если вы инсталлируете SQL Server на одиночный компьютер – рабочую станцию, то нажмите мышкой на Use the Local System account (Использовать учетную запись локальной системы). Для продолжения нажмите на Next.

    Диалоговое окно Setup Type (Тип установки)


    Рис. 7.3.  Диалоговое окно Setup Type (Тип установки)

     Диалоговое окно Services Accounts (Учетные записи служб)


    Рис. 7.4.  Диалоговое окно Services Accounts (Учетные записи служб)

  15. Затем появится диалоговое окно Authentication Mode (Режим аутентификации), (рис. 7.5). Это диалоговое окно определяет уровень безопасности вашей инсталляции SQL Server. Вы можете выбрать Windows Authentication Mode (Режим аутентификации Windows) либо Mixed Mode (Смешанный режим). При выборе Windows Authentication Mode все права пользователей в отношении базы данных наследуются из настроек Windows User Security. При выборе Mixed Mode вы должны задать пароль для учетной записи sa (системного администратора SQL Server). Вы можете и не задавать этот пароль (оставить его пустым), но такой поступок серьезно ухудшит безопасность вашей инсталляции SQL Server. После того как вы выберете режим аутентификации, чтобы продолжить работу, нажмите на Next.

    Диалоговое окно Authentication Mode (Режим аутентификации)


    Рис. 7.5.  Диалоговое окно Authentication Mode (Режим аутентификации)

  16. Появится диалоговое окно Start Copying Files (Запустить копирование файлов). Для продолжения нажмите на Next.
  17. Появится диалоговое окно Licensing Mode (Лицензионный режим). Вы можете выбрать один из двух вариантов лицензии для клиентов SQL Server – на количество посадочных мест (per seat) или на количество процессоров.

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

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

  18. По завершении инсталляции появится диалоговое окно Setup Complete (Установка завершена). Для завершения процесса инсталляции нажмите на Finish.

Поздравляем! Вы инсталлировали SQL Server на свой сервер.

Дистанционная инсталляция

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

  1. Выполните пункты 1-5 из последовательности действий для локальной инсталляции.
  2. В диалоговом окне Computer Name нажмите на Remote Computer и введите с клавиатуры имя удаленного компьютера. Для продолжения нажмите на Next.
  3. Появится диалоговое окно SQL Server 2000 Installation Selection. Нажмите на Create A New Instance Of SQL Server (Создать новый экземпляр SQL Server), а затем, чтобы продолжить инсталляцию, нажмите на Next.
  4. Появится диалоговое окно User Information. Проверьте правильность вашего имени и названия вашей фирмы. Для продолжения нажмите на Next.
  5. Появится диалоговое окно Software License Agreement. Нажмите на Yes, чтобы согласиться с условиями лицензионного соглашения и продолжить процесс инсталляции.
  6. Появится диалоговое окно CD Key. Введите 25-символьный ключ компакт-диска, напечатанный на желтой наклейке на футляре компакт-диска, а затем нажмите на Next.
  7. Появится диалоговое окно Remote Setup Information (Информация о дистанционной установке) (рис. 7.6). Введите в нем с клавиатуры имя учетной записи, пароль и домен для компьютера, на который вы хотите инсталлировать SQL Server. Не забудьте, что учетная запись, которой вы пользуетесь, должна иметь полномочия инсталлировать программное обеспечение на этом компьютере. Вы также должны ввести с клавиатуры путь инсталляции в файловой системе на удаленном компьютере в текстовое поле Target Path (Целевой путь). Путь инсталляции должен быть путем в формате UNC (Universal Naming Convention), например, \\remoteserver\c$\Program Files\ Microsoft SQL Server. Для продолжения нажмите на Next.

    Диалоговое окно Remote Setup Information (Информация о дистанционной установке)


    Рис. 7.6.  Диалоговое окно Remote Setup Information (Информация о дистанционной установке)

  8. Появится диалоговое окно Installation Definition. Нажмите на Server And Client Tools, а затем нажмите на Next.
  9. Появится диалоговое окно Instance Name. Если вы хотите, чтобы имя этого экземпляра SQL Server отличалось бы от принятого по умолчанию, то снимите флажок Default и введите с клавиатуры нужное имя. Для продолжения процесса инсталляции нажмите на Next.
  10. Появится диалоговое окно Setup Type. При дистанционной инсталляции, так же, как и при локальной, вы можете выбрать типичную, минимальную или выборочную инсталляцию. В типичную инсталляцию включены все опции, кроме Development Tools и Full-Text Search. При помощи выборочной инсталляции вы можете добавить эти опции, а также отказаться от любых ненужных вам опций. При минимальной инсталляции устанавливаются те же опции, что и при типичной, кроме Upgrade Tools, Books Online и Management Tools.В большинстве случаев надо выполнять типичную инсталляцию, поэтому в наших примерах предполагается, что была нажата экранная кнопка Typical. Вы также можете указать местоположение устанавливаемых файлов программ и данных SQL Server, для чего нажимайте на экранные кнопки Browse в группе экранных форм Destination Folder. Для продолжения нажмите на Next.

    Появится диалоговое окно Services Accounts (рис. 7.4). В соответствующие текстовые поля этого окна введите с клавиатуры имя и пароль созданной вами учетной записи службы SQL Server. (Если вы не создали отдельную учетную запись, то можете воспользоваться учетной записью и паролем администратора Windows NT или Windows 2000.) Для продолжения нажмите на Next.

  11. Появится диалоговое окно Authentication Mode. Это диалоговое окно определяет уровень безопасности вашей инсталляции SQL Server. Вы можете выбрать Windows Authentication Mode либо Mixed Mode. При выборе Windows Authentication Mode все права пользователей в отношении базы данных наследуются из Windows User Security. При выборе аутентификации Mixed Mode вы должны задать пароль для учетной записи системного администратора SQL Server (в этом диалоговом окне – "sa"). Вы можете и оставить этот пароль пустым, но такой поступок серьезно ослабит безопасность вашей инсталляции SQL Server. После того как вы выберете режим аутентификации, для продолжения работы нажмите на Next.
  12. Появится диалоговое окно Licensing Mode. При дистанционной инсталляции, как и при локальной, вы можете выбрать один из двух вариантов лицензии для клиентов SQL Server – на количество клиентов для работы на серверах или на посадочных мест (на количество процессоров). Различия между этими двумя видами лицензий описаны в пункте 16 последовательности действий для выполнения локальной инсталляции.

В ходе процесса дистанционной инсталляции SQL Server создаст файл с именем Sqlstp.log. Этот файл находится в папке %Systemroot% вашей операционной системы Windows NT или Windows 2000. Обычно папка %Systemroot% – это C:\Winnt. В файле Sqlstp.log хранится информация обо всех выполненных действиях процесса инсталляции, а также об ошибках или предупреждениях, возникших при инсталляции. Если вдруг дистанционная инсталляция завершится неудачно, этот файл поможет при диагностике.

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

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

  1. Из командной строки перейдите в директорию на компакт-диске.
  2. Выполните один из пакетных (.bat) файлов для автоматической инсталляции:
    • Sqlins.bat служит для выполнения типичной инсталляции SQL Server на Windows 95/98, Windows NT или на Windows 2000. Этот пакетный файл использует файл инициализации Sqlins.iss.
    • Sqlcst.bat служит для выполнения выборочной инсталляции SQL Server на Windows 95/98, Windows NT или на Windows 2000. Этот пакетный файл использует файл инициализации Sqlcst.iss.
    • Sqlcli.bat служит для инсталляции клиентских утилит. Эти утилиты инсталлируются с использованием файла инициализации Sqlcli.iss. Клиентские утилиты инсталлируются в папку C:\Program Files\Microsoft SQL Server\80\.
    • Sqlrem.bat служит для удаления с компьютера всех компонент SQL Server. В качестве параметра вы должны указать установочную папку SQL Server.

Прежде чем запускать какой-либо из этих пакетных файлов, вы можете настраивать для конкретных компьютеров файлы .iss, соответствующие этим .bat -файлам. Например, вы можете пожелать изменить режим лицензирования со стандартного ("на сервер") на "на количество посадочных мест". Для этого потребуется изменить раздел [License] соответствующего .iss -файла с LicenseMode=PERSERVER на LicenseMode=PERSEAT.

Обновление от ранних версий

Если на ваших компьютерах уже размещены данные Microsoft SQL Server 6.5 или Microsoft SQL Server 7, то вы можете без хлопот обновить эти данные для использования с SQL Server 2000. Для обновления инсталляций Microsoft SQL Server 6.5 понадобится использовать мастер Version Upgrade Wizard. Инсталляции SQL Server 7 обновляются автоматически в процессе установки SQL Server 2000.

Обновление к SQL Server 2000 от SQL Server 7

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

 Сообщение о состоянии процесса обновления SQL Server 7


Рис. 7.7.  Сообщение о состоянии процесса обновления SQL Server 7

Обновление к SQL Server 2000 от SQL Server 6.5

Прежде чем запустить мастер SQL Server Upgrade Wizard, который обновляет данные SQL Server 6.5 к форматам SQL Server 2000, вам понадобится проверить все пункты приведенного ниже списка (применительно к вашей инсталляции SQL Server 6.5):

Чтобы обновить данные SQL Server 6.5 к форматам SQL Server 2000 (после того как вы инсталлировали SQL Server 2000), надо выполнить следующие действия:

  1. Нажмите на экранную кнопку Start, наведите курсор на Programs, затем наведите курсор на Microsoft SQL Server-Switch, а затем нажмите на SQL Server Upgrade Wizard, чтобы появился стартовый экран мастера SQL Server Upgrade Wizard (рис. 7.8). Для продолжения процесса обновления нажмите на Next.
  2. Появится экран Data and Object Transfer (Перенос данных и объектов) мастера SQL Server Upgrade Wizard (рис. 7.9). По умолчанию, мастер SQL Server Upgrade Wizard выполнит конвертацию (преобразование) всех объектов и данных базы данных SQL Server 6.5 в формат SQL Server 2000. Чтобы убедиться в успешности этой конвертации, установите флажок Validate Successful Object Data Transfer (Проверить успешность переноса объектов данных). Эта проверка может занять много времени, но лучше ее все-таки выполнить.

    Стартовый экран мастера SQL Server Upgrade Wizard


    Рис. 7.8.  Стартовый экран мастера SQL Server Upgrade Wizard

    Экран Data and Object Transfer (Перенос данных и объектов)


    Рис. 7.9.  Экран Data and Object Transfer (Перенос данных и объектов)

    Если вы беспокоитесь о целостности конвертированных данных, то установите флажок Exhaustive Data Integrity Verification (Исчерпывающая верификация целостности данных). Из-за этой опции процесс конвертации данных еще более замедлится, но зато будет обеспечен наивысший уровень целостности. Если вы уже давно не запускали SQL Server 6.x DBCC (модуль для проверки непротиворечивости базы данных), то нужно выбрать применение этой опции, чтобы избежать влияния повреждения базы данных на процесс конвертации. Если на вашем компьютере имеется ленточный накопитель, то будет иметься также опция для использования в качестве метода передачи данных не именованных каналов, а ленточного накопителя. Для продолжения нажмите на Next.

  3. Появится экран Logon мастера SQL Server Upgrade Wizard (рис. 7.10). Вы должны выбрать имя сервера из выпадающего списка и ввести с клавиатуры пароль системного администратора для конвертируемой базы данных SQL Server 6.5. Вы также должны ввести пароль системного администратора для целевой базы данных SQL Server 2000. Если вы хотите, чтобы любой из SQL Server работал с какими-либо аргументами запуска (startup arguments), то введите с клавиатуры эти аргументы в соответствующее текстовое поле Optional Startup Arguments (Необязательные аргументы запуска). Здесь можно задать флаги трассировки. Если вы не пожелаете применять аргументы запуска, то оставьте эти текстовые поля пустыми. (Для дополнительной информации обратитесь к Books Online и посмотрите в разделе "stаrtup options"). Для продолжения нажмите на Next.
  4. Экран мастера SQL Server Upgrade Wizard выдаст предупредительное сообщение о том, что мастер SQL Server Upgrade Wizard должен остановить и перезапустить ваши базы данных SQL Server 6.5 и SQL Server 2000 и что никто из пользователей не должен входить ни на какой из серверов баз данных, пока не будет завершена конвертация базы данных. Для продолжения нажмите на Yes.

    Экран Logon мастера SQL Server Upgrade Wizard


    Рис. 7.10.  Экран Logon мастера SQL Server Upgrade Wizard

    Примечание. C этого момента система будет переключаться между SQL Server 6.5 и SQL Server 2000.
  1. Появится экран Code Page Selection (Выбор кодовой страницы), при помощи которого вы сможете задать кодовую страницу сценариев (scripting code page), используемую при конвертации, определяющую набор символов. Всегда выбирайте стандартную настройку, за исключением случаев, когда вы хотите применять другой набор символов, отличающийся от того, который уже был у вас установлен. Для продолжения нажмите на Next.
  2. Мастер SQL Server Upgrade Wizard, во взаимодействии с базой данных SQL Server 6.5, определит, какие базы данных можно конвертировать в новый формат, а затем покажет список этих баз данных в экране Upgrade Databases to SQL Server 2000 (Обновлять базы данных к SQL Server 2000) (рис. 7.11).

    Те базы данных, которые будут конвертироваться в новый формат, будут показаны в списке в правом поле. Чтобы исключить базу данных из процесса конвертации в новый формат, выберите ее имя в списке в поле Include these databases и нажмите на экранную кнопку Exclude. Эта исключенная база данных появится в списке в левом поле. Не нужно исключать базы данных из процесса конвертации, единственной причиной такого решения может быть лишь случай, когда вы больше не собираетесь пользоваться этой базой данных. Для продолжения нажмите на Next.

  3. Появится экран Database Creation (Создание баз данных) (рис. 7.12). При помощи этого экрана вы можете указать, как будут создаваться базы данных. Обычно выбирают конфигурацию, предлагаемую по умолчанию. Если вы хотите указать другое местоположение файлов данных, то измените конфигурацию. Для продолжения нажмите на Next.

    Экран Upgrade Databases to SQL Server 2000 (Обновлять базы данных к SQL Server 2000)


    Рис. 7.11.  Экран Upgrade Databases to SQL Server 2000 (Обновлять базы данных к SQL Server 2000)

    Экран Database Creation (Создание баз данных)


    Рис. 7.12.  Экран Database Creation (Создание баз данных)

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

    Вторая опция для создания баз данных – это Use databases already created in SQL Server 2000 (Применять базы данных, уже созданные в SQL Server 2000). С ее помощью вы можете создать в SQL Server 2000 файлы данных и журналов еще до того, как запустите мастер обновления, и SQL Server будет применять эти базы данных для хранения конвертированных данных.

    Третья опция – использовать сценарий SQL для создания файлов баз данных. Этот сценарий должен содержать оператор CREATE DATABASE, необходимый для создания файлов баз данных и журналов, используемых при конвертации. Чтобы найти и указать нужный сценарий, нажмите на экранную кнопку Browse.

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

  4. Появится экран System Configuration (Конфигурация системы)( рис. 7.13). При помощи этого экрана вы можете задать, какие системные объекты и настройки должны передаваться в новую базу данных. Если установить флажок Server Configuration (Конфигурация сервера), то будут конвертированы все регистрационные данные для обычных и дистанционных входов в систему. Если установить флажок SQL Executive Settings (Настройки исполнения SQL), то будут конвертированы все запланированные задания (scheduled tasks). Если установить флажок Replication Settings (Настройки репликации), то будет конвертироваться и поддержка репликации. В нашем примере флажок Replication Settings отключен, потому что для наших баз данных SQL Server 6.5 репликация не применялась, поэтому и конвертировать нечего. (О репликации баз данных см. лекцию 26.)

    Экран System Configuration (Конфигурация системы)


    Рис. 7.13.  Экран System Configuration (Конфигурация системы)

    При помощи группы селективных кнопок Advanced settings (Дополнительные настройки) вы можете задать настройки ANSI Nulls (Нули ANSI) и Quoted Identifiers (Идентификаторы в кавычках). Настройка ANSI Nulls влияет на работу операций сравнения, использующих нулевые значения. Если установить эту настройку на On (Включить), то операции сравнения ( = и <> ) будут всегда возвращать результат NULL, если один из аргументов операции сравнения будет NULL. Если установить эту настройку на Off (Выключить), то операции сравнения будут возвращать TRUE, если оба аргумента будут NULL, и возвращать FALSE, если один аргумент будет NULL, а другой – не NULL.

    Настройка Quoted Identifiers задает, каким образом SQL Server 2000 будет обрабатывать символы двойных кавычек. Если установить эту настройку на On, то символы двойных кавычек будут обозначать идентификаторы, например имена колонок. Если установить эту настройку на Off, то символы двойных кавычек будут обозначать символьные строки, как и символы одинарных кавычек. Если нажать на Mixed (Смесь), то SQL Server 2000 конвертирует объекты с применением той настройки Quoted Identifiers, какая была и в SQL Server 6.5. Если вы не знаете точно, как следует установить эту настройку, то лучше нажать на Mixed. Для продолжения нажмите на Next.

    Экран Completing the SQL Server Upgrade Wizard (Завершение мастера обновления SQL Server)


    Рис. 7.14.  Экран Completing the SQL Server Upgrade Wizard (Завершение мастера обновления SQL Server)

  5. После некоторой задержки появится экран Completing the SQL Server Upgrade Wizard (Завершение мастера обновления SQL Server) (рис. 7.14). При помощи этого экрана вы можете посмотреть все выбранные вами настройки конвертации. Если вы захотите внести в них какие либо изменения, то нажмите на Back и поменяйте настройки. Если ничего менять не надо, то нажмите на Finish, чтобы продолжить процесс конвертации.
  6. Появится диалоговое окно SQL Server Upgrade Script Interpreter (Интерпретатор сценария обновления SQL Server) (рис. 7.15). В этом диалоговом окне отображается исполняющийся список обновляемых объектов, благодаря чему администратор может в какой-то степени участвовать в ходе процесса обновления.

    Диалоговое окно SQL Server Upgrade Script Interpreter (Интерпретатор сценария обновления SQL Server)


    Рис. 7.15.  Диалоговое окно SQL Server Upgrade Script Interpreter (Интерпретатор сценария обновления SQL Server)

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

После завершения процесса обновления появится диалоговое окно Upgrade Complete (Обновление завершено). Нажмите на OK, чтобы убрать его с экрана, а затем нажмите на Close, чтобы закрыть диалоговое окно интерпретатора сценария обновления SQL Server.

Поздравляем! Вы только что обновили свои базы данных SQL Server 6.5 к формату SQL Server 2000.

Инсталляция клиентских компонент

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

  1. Выполните пункты 1-9 из последовательности действий для локальной инсталляции.
  2. Когда появится диалоговое окно Installation Definition, нажмите на Client Tools Only (Только клиентские инструментальные средства), а затем, чтобы продолжить работу, нажмите на Next.
  3. В появившемся окне Select Components (Выбор компонент) нажмите на нужные опции, а затем нажмите на Next. Вы можете выбрать Management Tools, Client Connectivity, Books Online, Development Tools, Code Samples либо любое сочетание этих опций. По умолчанию выбраны опции Management Tools, Client Connectivity, Books Online и Development Tools.
  4. Когда появится диалоговое окно Start Copying Files, нажмите на Next, чтобы продолжить работу.

Заключение

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

Лекция 8. Работа со службами Microsoft SQL Server Services

Управлять службами SQL Server – дело очень тонкое и требующее специфических знаний о принципах работы компонентах службы: – SQL Server Agent, Microsoft Distributed Transaction Coordinator и Microsoft Search. Рассматриваются доступ к часто изменяющимся параметрам системы. Инструментальные средства SQL Server Service Manager, SQL Server Enterprise Manager и Windows 2000 Service Control Manager позволяют расширить возможности управления службами. Приводятся примечания, защищающие администраторов от некорректных действий.

Установив Microsoft SQL Server 2000, вы можете начать им пользоваться. Но до того, как вы сможете входить в систему и начнете строить свою базу данных, нужно научиться запускать службу SQL Server и ее компоненты – SQL Server Agent, Microsoft Distributed Transaction Coordinator и Microsoft Search. Эти компоненты, описанные в данной лекции, исполняются как отдельные службы, дополняющие службу SQL Server. В данной лекции мы также расскажем, как запускать, останавливать и управлять этими службами при помощи трех инструментальных средств – SQL Server Service Manager, SQL Server Enterprise Manager и Windows 2000 Service Control Manager.

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

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

Службы SQL Server

Служба – это программа или процесс, выполняющие специфические функции поддержки других программ. Когда вы запускаете SQL Server, в операционной системе Windows NT или Windows 2000 запускается служба SQL Server. Эта служба управляет файлами баз данных, исполняет операторы Transact-SQL (T-SQL), распределяет ресурсы среди пользовательских соединений, исполняющихся одновременно, проверяет непротиворечивость данных и выполняет еще много других задач. Если вы инсталлируете один или несколько экземпляров SQL Server, то службы для отдельных экземпляров SQL Server будут иметь имена MSSQL$ИмяЭкземпляра, где ИмяЭкземпляра – имя экземпляра, назначенное вами при инсталляции. Соответственно, службы SQL Server Agent для экземпляров SQL Server будут иметь имена SQLAGENT$ИмяЭкземпляра. Однако для всех экземпляров SQL Server будет только по одной инсталляции Microsoft Distributed Transaction Coordinator и Microsoft Search.

Программные компоненты этих трех служб вы получаете в рамках лицензии на копию SQL Server. Инсталляция SQL Server Agent производится по умолчанию при инсталляции SQL Server. Если у вас не инсталлированы Microsoft Distributed Transaction Coordinator и Microsoft Search, то вы можете снова запустить инсталляционную программу SQL Server, чтобы установить эти компоненты, которые имеют там названия DTC Client Support и Full-Text Search, соответственно. А сейчас мы расскажем, что делает каждая из этих трех служб.

SQL Server Agent осуществляет планирование и исполнение заданий, оповещений, извещений и планов обслуживания базы данных. Без этой службы работа администратора баз данных станет гораздо более трудной, а может, вообще невозможной. Благодаря SQL Server Agent можно автоматизировать рутинные процедуры по обслуживанию базы данных. Например, вы можете создать задание, которое будет автоматически выполнять резервное копирование базы данных ежесуточно в 1 час пополуночи, и другое задание, которое будет автоматически выполнять резервное копирование журнала транзакций каждые полчаса. Чтобы следить за производительностью вашей системы, можно создать оповещение о состоянии производительности, которое будет информировать вас, если загруженность центрального процессора сервера превысит 90%. Для решения подобных задач нужно запускать службу SQL Server Agent, которую можно сконфигурировать на автоматический запуск при запуске SQL Server, а можно запускать и вручную. Вам следует сконфигурировать ее на автоматич еский запуск, что будет гарантировать исполнение ваших запланированных заданий, оповещений и извещений. В лекции 30 будет рассказано, как создать план обслуживания базы данных, а в лекции 31 – как при помощи SQL Server Agent назначать задания, оповещения и извещения.

Microsoft Distributed Transaction Coordinator – это администратор транзакций (transaction manager), при помощи которого в транзакции ваших приложений можно включать данные из различных источников, в том числе данные из баз данных с удаленных компьютеров. Это значит, что при помощи одной транзакции можно обновлять данные на многих серверах, доступных через сеть. Администратор транзакций гарантирует, что все обновления станут постоянными для всех источников данных (если транзакция зафиксирована) или, в случае ошибки, что для всех источников данных будет произведен откат всех изменений. (Об администраторе транзакций Microsoft Distributed Transaction Coordinator см. лекцию 25.)

Запускайте службу Microsoft Search, когда вам нужна поддержка полнотекстного индексирования и поиска. Благодаря полнотекстному индексированию возможно выполнение более сложного поиска среди данных, содержащих текстовые строки. Например, вы можете искать слова, близкие к заданному слову, или можете искать определенную фразу.

Как мы уже говорили, имеется несколько инструментальных средств для остановки и запуска служб SQL Server: SQL Server Service Manager, SQL Server Enterprise Manager и Windows 2000 Service Control Manager. Давайте сначала рассмотрим SQL Server Service Manager, при помощи которого можно управлять службами SQL Server, SQL Server Agent, Microsoft Distributed Transaction Coordinator и Microsoft Search.

Применение SQL Server Service Manager

Для запуска или остановки служб SQL Server при помощи SQL Server Service Manager, выполните следующие действия (а ещё, как вы увидите, службу SQL Server можно и приостанавливать).

  1. Нажмите на экранную кнопку Start, наведите курсор на Programs, затем наведите курсор на Microsoft SQL Server, а затем выберите Service Manager, чтобы открылось приложение Service Manager (рис. 8.1).
  2. В выпадающих списках Server и Services будут показаны локальное имя сервера и название службы SQL Server. В ниспадающем списке Server нужно выбрать имя сервера, службами которого вы хотите управлять. (Обратите внимание, что вы можете применять Service Manager для управления серверами через сеть.) В ниспадающем списке Services выберите службу, которой вы хотите управлять: SQL Server (MSSQLSERVER), Microsoft Distributed Transaction Coordinator (Distributed Transaction Coordinator), Microsoft Search (Microsoft Search) или SQL Server Agent (SQLSERVERAGENT).

    SQL Server Service Manager


    Рис. 8.1.  SQL Server Service Manager

  3. Теперь, нажимая на соответствующие экранные кнопки, вы можете запустить или остановить выбранную службу. А если вы выбрали службу SQL Server, то вы сможете еще и приостанавливать ее (pause). Символ в кружочке, несколько левее и ниже центра диалогового окна, показывает текущее состояние выбранной службы. Если служба SQL Server находится в приостановленном состоянии, то для её возобновления нажмите на кнопку Start/Continue (Запустить/Продолжить). Приостановка (pausing) SQL Server запрещает пользователям входить в систему, и вы можете попросить пользователей завершить свои работы и выйти из системы в течение некоторого времени, пока вы не остановите SQL Server. Если остановить SQL Server без приостановки, то все процессы SQL Server будут завершены немедленно. Остановка (stopping) запрещает новые соединения и отсоединяет пользователей, которые соединены в данный момент.
  4. Когда Service Manager запущен, его окно обновляется через каждые 5 секунд. Чтобы изменить интервал обновления, нажмите на маленький значок-иконку в левом верхнем углу диалогового окна, тогда появится меню System, в котором нужно выбрать Options, в результате чего появится диалоговое окно SQL Server Service Manager Options (рис. 8.2).

    Диалоговое окно SQL Server Service Manager Options


    Рис. 8.2.  Диалоговое окно SQL Server Service Manager Options

    В поле Polling interval (Интервал опроса) можно задать другой интервал опроса для служб (в секундах). Если вы установите флажок Verify service control action (Подтверждать действия по управлению службой), то Service Manager будет проверять все ваши действия по запуску, остановке и приостановке служб, запрашивая в диалоговом окне ваше подтверждение на выполнение действия. Настройки интервала опроса и подтверждения действий задаются одинаковыми для всех четырех служб.

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

Применение Windows 2000 Service Control Manager

Службы SQL Server можно запускать и останавливать также при помощи Windows 2000 Service Control Manager, как локально, так и через сеть. Вы можете даже сконфигурировать службы SQL Server на автоматический запуск при каждом запуске вашего компьютера. Чтобы службы SQL Server запускались автоматически из Windows 2000 Service Control Manager, выполните следующие действия.

  1. Нажмите на экранную кнопку Start, наведите курсор на Programs, затем наведите курсор на Administrative Tools, а затем выберите Services, чтобы запустить Service Control Manager (рис. 8.3).

    Windows 2000 Service Control Manager


    Рис. 8.3.  Windows 2000 Service Control Manager

  2. Прокрутите список служб и найдите в нем Distributed Transaction Coordinator, Microsoft Search, MSSQLSERVER и SQLSERVERAGENT. Нажмите правой кнопкой мыши на ту службу, настройки запуска которой вы хотите конфигурировать, а затем выберите Properties в контекстном меню, в результате чего появится окно Properties (Свойства) (рис. 8.4).
  3. В ниспадающем списке Startup type (Тип запуска) выберите Automatic, Manual (Вручную) или Disabled (Выключена). Если выбрать Automatic, то служба будет запускаться автоматически всякий раз при включении компьютера. При выборе Manual потребуется запускать эту службу вручную всякий раз, когда вы хотите ее использовать. Выбор Disabled служить для предотвращения запуска службы (как автоматического, так и ручного). Для сохранения выбранной конфигурации нажмите на OK.

    Окно свойств SQL Server Agent


    Рис. 8.4.  Окно свойств SQL Server Agent

  4. В окне Properties имеются еще три вкладки. Вкладка Log On позволяет задать учетную запись, под которой данная служба будет входить в систему. Вкладка Recovery позволяет задать настройки на случай отказа выбранной службы. При помощи вкладки Dependencies (Зависимости) можно посмотреть, от каких служб зависит выбранная служба и какие службы зависят от нее (если таковые имеются). Например, служба SQL Server Agent зависит от службы SQL Server. Служба SQL Server Agent не может быть запущена, если служба SQL Server остановлена.

Применение SQL Server Enterprise Manager

Enterprise Manager – это часть Microsoft Management Console (MMC), "Консоли Управления Microsoft". MMC является основным приложением, служащим для управления всеми аспектами работы компьютера под управлением Windows 2000 Server. В Windows 2000 и в последующих версиях Windows, MMC будет иметь гораздо более важную роль при управлении приложениями Microsoft BackOffice, такими как Microsoft Exchange Server, Microsoft Proxy Server, Microsoft Site Server, Microsoft Systems Management Server и Microsoft SNA Server.

Управление SQL Server

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

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

SQL Server Enterprise Manager


Рис. 8.5.  SQL Server Enterprise Manager

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

Создание групп сервера

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

  1. Нажмите на экранную кнопку Start, наведите курсор на Programs, наведите курсор на Microsoft SQL Server 2000, а затем выберите Enterprise Manager, чтобы запустить приложение Enterprise Manager.
  2. В левой части окна Enterprise Manager будут показаны папки групп серверов (как подпапки Microsoft SQL Server), а в правой части окна будут показаны значки-иконки групп серверов. Чтобы создать группу серверов SQL Server, нажмите правой кнопкой мыши на папку Microsoft SQL Server, а затем выберите New SQL Server Group в появившемся контекстном меню.
  3. Появится диалоговое окно Server Groups, введите в него с клавиатуры имя новой группы серверов (рис. 8.6). Если вы нажмете на селективную экранную кнопку Sub-group of (Подгруппа в ...), то сможете выбрать группу, для которой новая группа серверов будет подгруппой. Если вы нажмете на Top level group (Группа высшего уровня), то ваша новая группа серверов будет группой SQL Server самого высшего уровня, того же уровня, что и группа SQL Server Group. Чтобы сохранить свою новую группу, нажмите на OK.
Регистрация сервера

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

Диалоговое окно Server Groups


Рис. 8.6.  Диалоговое окно Server Groups

  1. Нажмите правой кнопкой мыши на значок-иконку группы серверов в правой панели окна Enterprise Manager. (Если заголовок Microsoft SQL Server раскрыт, то вы можете также нажать правой кнопкой мыши на имя папки группы в левой панели окна.) В появившемся контекстном меню выберите New SQL Server Registration.
  2. Появится стартовый экран мастера Register SQL Server Wizard (Мастер регистрации SQL Server). Этот мастер поможет вам в прохождении процесса выполнения многих рутинных административных задач, решаемых с помощью Enterprise Manager. Для продолжения регистрации сервера нажмите на Next.
  3. Появится экран Select а SQL Server (Выберите SQL Server) (рис. 8.7). В списковом поле Available Servers (Доступные серверы) будут показаны инсталляции SQL Server, доступные через сеть. Выберите серверы, которые вы хотите зарегистрировать (или наберите с клавиатуры имя сервера в текстовом поле), а затем нажмите на Add, чтобы переместить имя сервера в списковое поле Added Servers (Добавленные серверы). Завершив действия по выбору, нажмите на Next.

    Экран Select а SQL Server (Выберите SQL Server)


    Рис. 8.7.  Экран Select а SQL Server (Выберите SQL Server)

  4. Появится экран Select An Authentication Mode (Выберите режим аутентификации). Выберите тип защиты, которую вы хотите применять при соединении с вашей инсталляцией SQL Server. (О защите SQL Server см. лекцию 34.) (Если вы выполнили "типичную" инсталляцию, то SQL Server уже сконфигурирован на применение режима аутентификации Windows NT.) Для продолжения нажмите на Next.
  5. Появится экран Select SQL Server Group (Выберите группу SQL Server) (рис. 8.8). Вы можете выбрать уже существующую группу, в которую добавите свой сервер, а можете создать для своего сервера группу высшего уровня. Если вы хотите добавить свой сервер в существующую группу, то нажмите на первую селективную кнопку экрана, а затем выберите имя группы в выпадающем списке. А если вы хотите создать группу, то нажмите на вторую, а затем введите с клавиатуры имя группы в текстовое поле. Для продолжения нажмите на Next.

    Экран Select SQL Server Group (Выберите группу SQL Server)


    Рис. 8.8.  Экран Select SQL Server Group (Выберите группу SQL Server)

  6. Появится экран Completing The Register SQL Server Wizard (Завершение мастера регистрации SQL Server). Серверы, показанные в списке, будут зарегистрированы. Если вы хотите внести какие-либо изменения, то нажмите на Back, а если изменения не нужны, то нажмите на Finish, и тогда запустится процесс регистрации.
  7. Появится диалоговое окно Register SQL Server Messages (Сообщения регистрации SQL Server) (рис. 8.9), являющееся подтверждением успешности вашей регистрации. Чтобы закрыть это окно, нажмите на Close.

    Диалоговое окно Register SQL Server Messages (Сообщения регистрации SQL Server)


    Рис. 8.9.  Диалоговое окно Register SQL Server Messages (Сообщения регистрации SQL Server)

Доступ к свойствам сервера

После успешной регистрации вашего сервера с помощью Enterprise Manager вы получаете доступ ко всем его свойствам, базам данных и объектам. Чтобы посмотреть свойства и объекты только что зарегистрированного сервера, сначала раскройте имя группы сервера в левой панели окна Enterprise Manager. Появится список всех серверов из этой группы. Затем раскройте имя сервера, чтобы стали видны его свойства (рис. 8.10). (В последующих лекциях будет подробно объяснено, как управлять этими свойствами и как их конфигурировать.)

 Свойства и объекты сервера


Рис. 8.10.  Свойства и объекты сервера

Изменение стандартного пароля

Все инсталляции SQL Server имеют встроенную административную учетную запись, "sa" ("sa" расшифровывается как system administrator, системный администратор). У новых инсталляций SQL Server, пользовательской учетной записи не назначается никакого пароля. Чтобы обеспечить наивысший уровень защищенности ваших инсталляций SQL Server, учетной записи sa надо назначить пароль. Для этого выполните следующие действия.

  1. Получите доступ к свойствам сервера, у которого вы хотите изменить свойства учетной записи sa (в соответствии с описанием в предыдущем разделе).
  2. Раскройте папку Security, а затем нажмите на Logins, чтобы в правой панели появились бы установленные пользовательские учетные записи SQL Server (рис. 8.11).
  3. Нажмите правой кнопкой мыши на учетную запись sa, а затем выберите Properties в появившемся контекстном меню. Откроется окно SQL Server Login Properties (Свойства входа в систему SQL Server) (рис. 8.12).В окне SQL Server Login Properties можно задать и некоторые другие настройки (см. лекцию 34).
  4. Введите с клавиатуры новый пароль в текстовое поле Password, а затем нажмите на OK. Откроется диалоговое окно Confirm Password для проверки введенного пароля на отсутствие опечаток.

    Установленные пользовательские учетные записи SQL Server


    Рис. 8.11.  Установленные пользовательские учетные записи SQL Server

     Окно SQL Server Login Properties (Свойства входа в систему SQL Server)


    Рис. 8.12.  Окно SQL Server Login Properties (Свойства входа в систему SQL Server)

  5. Повторите ввод пароля и затем нажмите на OK. Вы только что выполнили действие, критически важное для обеспечения защиты вашей инсталляции SQL Server.
    Предупреждение.Вы должны надежно запомнить выбранный пароль. Если вы его забудете, то придется переинсталлировать SQL Server*.
Управление другими службами

Enterprise Manager можно также применять для управления другими службами-компонентами SQL Server: SQL Server Agent, Microsoft Distributed Transaction Coordinator и Microsoft Search. Как мы уже говорили раньше, он является единственным инструментальным средством, при помощи которого можно управлять этими службами, так как при помощи Service Control Manager и SQL Server Service Manager службы-компоненты можно только запускать и останавливать.

SQL Server Agent

Enterprise Manager имеет удобный пользовательский интерфейс для управления службой SQL Server Agent. Для доступа к свойствам службы SQL Server Agent выполните следующие действия.

  1. Находясь внутри Enterprise Manager, раскройте обозначение сервера, доступ к которому вы осуществляете, а затем раскройте папку Management (рис. 8.13).

     Папка Management в Enterprise Manager


    Рис. 8.13.  Папка Management в Enterprise Manager

  2. Нажмите правой кнопкой мыши на SQL Server Agent в левой панели или на значок-иконку SQL Server Agent в правой панели, в результате чего появится контекстное меню. При помощи этого меню вы можете: останавливать или запускать службу SQL Server Agent; просматривать журнал ошибок; запускать мастеры, чтобы данный сервер был основным (master) либо целевым (target) для выполнения заданий; создавать задания, оповещения и операторы; просматривать окно свойств (см. лекцию 31).
  3. В этом контекстном меню выберите Properties (Свойства). Появится окно свойств SQL Server Agent, показанное на рис. 8.14.
  4. В этом окне вы можете сконфигурировать различные настройки для службы SQL Server Agent, имеющиеся на многочисленных вкладках – General (Общие), Advanced (Дополнительно), Alert System (Система оповещений), Job System (Система заданий) и Connection (Соединение). В нижней части окна имеется кнопка Help, с помощью которой можно получить подробные объяснения обо всех настройках, имеющихся на открытой вкладке.

 Окно свойств для SQL Server Agent


Рис. 8.14.  Окно свойств для SQL Server Agent

Microsoft Distributed Transaction Coordinator

Что касается службы Microsoft Distributed Transaction Coordinator, то Enterprise Manager может только запускать ее и останавливать. Для этого раскройте обозначение нужного сервера, а затем раскройте папку Support Services (Поддержка служб) (рис. 8.15).

Нажмите правой кнопкой мыши на Distributed Transaction Coordinator в левой или в правой панели. Для запуска или остановки службы выберите Start либо Stop в контекстном меню.

  Папка Support Services (Поддержка служб)


Рис. 8.15.  Папка Support Services (Поддержка служб)

Microsoft Search

Чтобы получить доступ к меню с настройками для службы Microsoft Search, раскройте папку Support Services, как было рассказано в предыдущем разделе, а затем нажмите правой кнопкой мыши на Full-Text Search (Полнотекстный поиск) в левой или в правой панели. Из этого меню вы можете запускать и останавливать службу Microsoft Search, очищать каталоги полнотекстного поиска, а также просматривать свойства службы.

Заключение

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

Лекция 9. Создание баз данных

Обзор всех тонкостей работы при создании баз данных: от теории к практическим действиям. Первичные и вторичные файлы данных, файлы журналов транзакций, группы файлов – все это необходимые знания, помогающие более эффективно организовать работу базы данных, способную к масштабируемости, устойчивости и быстрой работе. Всевозможные правила и рекомендации ограничивают администратора от неправильных действий. Обзор четырех системных баз данных (master, tempdb, model, msdb). Примеры использования Create Database Wizard, Enterprise Manager, T-SQL позволяет выбрать более эффективный для вас способ создания базы данных. Особое внимание уделено T-SQL, т.к. его использование в следующих лекциях станет намного шире.

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

Структура базы данных

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

Файлы

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

Каждая база данных должна создаваться хотя бы с одним файлом данных и с одним файлом журнала; файлы не могут быть использованы более чем в одной базе данных – т.е., базы данных не могут разделять файлы (использовать файлы совместно). В приведенном ниже перечне указаны три типа файлов, которые могут быть использованы в базах данных:

Примечание. Максимальный размер файлов базы данных SQL Server составляет 32 терабайта для файлов данных и 4 терабайта для файлов журналов.

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

Но как же данные смогут размещаться по многим файлам данных? А вот для этого и применяются группы файлов.

Группы файлов

При помощи групп файлов можно группировать файлы, это нужно для администрирования и размещения данных. (Группы файлов похожи на сегменты в Microsoft SQL Server 6.5 и в более ранних версиях.) Применение групп файлов позволяет повысить производительность базы данных, т.к. становится возможным создание базы данных, размещенной на многих дисках, на многих контроллерах и на RAID-массивах. (Про RAID-массивы см. лекцию 5.) При помощи групп файлов можно создавать таблицы и индексы, размещаемые на заданных физических дисках, контроллерах и массивах дисков. В данной лекции мы рассмотрим некоторые примеры такой работы.

Имеются три типа групп файлов со следующими основными свойствами:

Чтобы повысить производительность, вы можете управлять размещением данных, создавая таблицы и индексы в разных группах файлов. Так, вы можете пожелать поместить таблицу, доступ к которой бывает часто, в группу файлов на большом массиве дисков (например, составленным из 10 дисков), а другую таблицу, доступ к которой бывает реже, поместить в другую группу файлов, расположенную на отдельном, меньшем массиве дисков (например, из 4 дисков). Таким образом, можно размещать таблицы, доступ к которым происходит чаще, по большему количеству дисков, позволяя этим дискам осуществлять параллельный ввод-вывод. Если вы не применяете массивы RAID и у вас имеется несколько дисковых накопителей, то у вас остается возможность применения групп файлов. Например, вы можете создать по отдельному файлу для каждого дискового накопителя, разместив каждый файл в отдельную пользовательскую группу файлов. Тогда вы сможете поместить каждую таблицу или индекс в отдельный файл (и на отдельный диск), назначив группу файлов при создании этой таблицы или индекса. Пример размещения файлов показан на рис. 9.1: один первичный файл данных размещен в первичной группе файлов на диске C, по одному вторичному файлу данных размещено в каждой из пользовательских групп файлов (FG1 и FG2) на дисках E и F и один файл-журнал размещен на диске G. После этого вы можете создавать таблицы и индексы в каждой из пользовательских групп файлов – FG1 или FG2.

Применение групп файлов для управления размещением данных


Рис. 9.1.  Применение групп файлов для управления размещением данных

А может быть, вы будете применять пользовательскую группу файлов для распределения данных по нескольким дискам. На рис. 9.2 показана пользовательская группа файлов FG1, состоящая из двух вторичных файлов данных, один из которых находится на диске E, а другой – на диске F (диске G размещен файл-журнал, а на C – первичный файл). В этом примере мы снова предполагаем, что каждый файл базы данных создан на отдельном физическом дисковом накопителе, и у нас нет аппаратной реализации RAID. Таблицы и индексы, созданные в этой пользовательской группе файлов, будут размещены сразу на двух дисках, потому что SQL Server применяет стратегию пропорционального расходования ресурсов.

Применение одной группы файлов для распределения данных по нескольким дискам


Рис. 9.2.  Применение одной группы файлов для распределения данных по нескольким дискам

Если вы применяете RAID-систему, то вам может потребоваться распределить данные из большой таблицы по нескольким логическим дискам-массивам, сконфигурированным на двух или на нескольких RAID-контроллерах. Для этого вам надо будет создать пользовательскую группу файлов, с файлами, соответствующими каждому из этих контроллеров. Допустим, вы создали два вторичных файла данных, каждый – на своем массиве дисков, а каждый логический массив состоит из восьми физических дисков и сконфигурирован как RAID 5. Эти два массива обслуживаются двумя отдельными RAID-контроллерами. Чтобы создать таблицу или индекс, располагающуюся на обоих этих контроллерах (т.е. на всех 16 дисковых накопителях), создайте одну пользовательскую группу файлов, в которую поместите оба файла, а затем создайте таблицу или индекс в этой группе файлов. Пользовательская группа файлов FG1 распределена по 16 физическим дискам (двум логическим дискам – RAID-массивам) (см. рис. 9.3). Там также показаны первичный файл данных на другом контроллере (с RAID 1) и файл журнала еще на одном контроллере (с RAID 10).

SQL Server позволяет оптимизировать распределение ваших данных по дисковым накопителям, за счет автоматического пропорционального расслоения (распределения) данных по всем файлам группы файлов. "Расслоение" (striping) – это термин, применяемый для описания распределения данных по нескольким файлам базы данных. Расслоение файлов SQL Server работает независимо от расслоения дисков RAID-массивов и, как вы видели из наших примеров, может применяться как в сочетании с RAID, так и самостоятельно.

Чтобы обеспечить расслоение данных, SQL Server записывает данные в файлы в объемах, пропорциональных свободному месту, остающемуся в файлах (относительно свободному месту в других файлах). Место для таблиц и индексов распределяется в виде экстентов (extents). Экстент – это единица для измерения места на диске, один экстент состоит из 8 страниц, а одна страница состоит из 8 Кб, так что один экстент состоит из 64 Кб. Допустим, нужно распределить 5 экстентов на файл F1, в котором свободно 400 Мб, и на файл F2, в котором свободно 100 Мб; тогда 4 экстента будут распределены на файл F1 и один экстент распределен на файл F2. Оба файла заполнятся до конца примерно одновременно, благодаря чему операции ввода-вывода будут распределяться по дискам более равномерно. Пропорциональное заполнение будет применяться и для пользовательских, и для первичных групп файлов. Если задать все файлы в группе файлов имеющими одинаковый начальный размер, то данные, по мере их загрузки, будут распределяться по файлам равномерно. Этот метод, когда в группах создаются файлы одинакового начального размера, можно порекомендовать для равномерного распределения данных по дисковым накопителям и, одновременно с этим, для равномерного распределения операций ввода-вывода.

 Распределение пользовательской группы файлов по нескольким RAID-контроллерам


Рис. 9.3.  Распределение пользовательской группы файлов по нескольким RAID-контроллерам

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

Правила и рекомендации

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

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

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

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

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

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

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

Максимальный размер файла означает именно это – максимальный размер, до которого разрешается расти файлу. Эта величина тоже задается при создании файла, но может быть изменена впоследствии при помощи Enterprise Manager или команды ALTER DATABASE. Если максимальный размер файла не задан, то SQL Server будет увеличивать размер файла до тех пор, пока не заполнится все место на диске. Чтобы не истратить все место на диске (а в этом случае произойдет ошибка в работе SQL Server), задавайте максимальный размер для каждого файла. Если даже файл дорастет до максимального размера, вы сможете увеличить этот максимальный размер при помощи оператора ALTER DATABASE. Вы также можете создать еще один файл на том же (если там имеется свободное место) или на другом диске. Новый файл должен обязательно быть в той же самой группе файлов, что и первоначальный файл. Если позволить файлу расти без ограничений, как это задано по умолчанию, то вам придется создавать файл на другом диске, имеющем свободное место.

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

Системные базы данных

При инсталляции SQL Server создаются четыре системных базы данных: master (главная), tempdb (временная), model (модель) и msdb.

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

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

SQL Server предлагает три метода для создания баз данных: воспользоваться мастером Create Database Wizard, создать базу данных при помощи SQL Server Enterprise Manager или применить команду CREATE DATABASE, которую можно сохранить в файле и запускать как сценарий. Эти три метода будут описаны ниже, в следующих трех подразделах. Вы должны знать, что мастер Create Database Wizard обладает некоторыми ограничениями. Так, он помещает все созданные им файлы данных на один дисковый накопитель, в одну заданную вами папку. При использовании этого мастера вы не сможете поместить файлы данных в другое физическое местоположение (ни на другие дисковые накопители, ни в другие папки). Вы можете поместить файлы журналов на диск или в папку, отличающуюся от диска или папки для файлов данных, но, опять таки, только в одно физическое местоположение. Нельзя задать пользовательские группы файлов, и все файлы получат одинаковые настройки для роста. Из-за этих ограничений мастер Create Database Wizard является наилучшим решением, когда вам нужно создать в базе данных только один первичный файл данных и один файл для журнала транзакций. (С другой стороны, в дальнейшем вы всегда можете добавить в базу данных файлы и группы файлов, если они вам понадобятся.)

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

Применение мастера Create Database Wizard

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

  1. Запустите SQL Server Enterprise Manager и выберите сервер, на котором вы хотите создать базу данных. Чтобы выбрать сервер, сначала раскройте папку Microsoft SQL Servers (для этого нажмите на значок "+" слева от имени папки). Раскройте папку SQL Server Group, а затем нажмите на имя нужного вам сервера. В меню Tools выберите Wizards. Раскройте Database (см. рис. 9.4).

    Экран Select Wizard (Выбор мастера)


    Рис. 9.4.  Экран Select Wizard (Выбор мастера)

  2. Чтобы запустить мастер Create Database Wizard, дважды щелкните на Create Database Wizard. Откроется стартовый экран мастера (рис. 9.5).

    Стартовый экран мастера Create Database Wizard


    Рис. 9.5.  Стартовый экран мастера Create Database Wizard

  3. Нажмите на Next, и вы перейдете к экрану Name the Database and Specify its Location (Дайте имя для базы данных и укажите ее местоположение) (рис. 9.6). Введите с клавиатуры имя создаваемой базы данных и местоположение для файлов данных и файлов журналов. Местоположение должно правильно указывать на диск и папку, которые уже должны иметься в системе (локально). Если нажать на кнопку с многоточием ("..."), то вы сможете поискать и выбрать нужную папку. После того как вы зададите имя базы данных и местоположения пути к файлам данных и журналов, нажмите на Next, чтобы продолжить работу мастера.

    Экран Name the Database and Specify its Location (Дайте имя для базы данных и укажите ее местоположение)


    Рис. 9.6.  Экран Name the Database and Specify its Location (Дайте имя для базы данных и укажите ее местоположение)

    Примечание. На остальных рисунках этого раздела показано создание базы данных с именем MyDB, имеющей первичный файл данных в C:\mssql2k\MSSQL\data и один файл журнала в F:\mssql2k\MSSQL\data.
  4. Появится экран Name the Database Files (Дайте имена файлам базы данных) (рис. 9.7). В этом экране вы можете ввести с клавиатуры имена и начальные размеры для каждого из файлов вашей базы данных. Первичный файл базы данных создается автоматически и получает в качестве префикса своего имени имя базы данных. Вы можете либо согласиться с этим именем, либо ввести с клавиатуры другое имя. Первичный файл данных имеет расширение .mdf. Если вы имеете какое-либо представление о будущем размере вашей базы данных, то введите сейчас этот размер в поле для задания начального размера (Initial Size). Если вы не знаете будущий размер вашей базы данных, то оставьте размер, указанный по умолчанию; вы сможете изменить его позднее при помощи команды ALTER DATABASE. Любые файлы, которые вы создадите в дополнение к первому файлу (первичному), будут являться вторичными файлами и автоматически получат расширения .ndf. Все созданные здесь файлы будут помещены в первичную группу файлов. Пользуясь мастером Create Database Wizard, пользовательские группы файлов создавать невозможно.

    Экран Name the Database Files (Дайте имена файлам базы данных)


    Рис. 9.7.  Экран Name the Database Files (Дайте имена файлам базы данных)

    В нашем примере мы оставили заданный по умолчанию первичный файл MyDB_Data и добавили вторичный файл, MyDB_Data2. Оба этих файла будут помещены в одно и то же место, которое вы указали на шаге 3. (Если вы не хотите, чтобы все файлы данных размещались на одном диске и в одной и той же папке и группе файлов, не продолжайте работу мастера, а создайте базу данных одним из методов, описанных в следующих разделах.) Для продолжения работы мастера нажмите на Next.
  5. Появится экран Define the Database File Growth (Настройте рост файлов базы данных) (рис. 9.8). Как уже говорилось в данной лекции, SQL Server может по мере необходимости автоматически увеличивать размер вашей базы данных, что снимает с администратора часть работы по обслуживанию. Вообще говоря, рекомендуется включать опцию для автоматического роста файлов (Automatically grow the database files), потому что она совсем немного расходует ресурс производительности системы, а если ее не задать, то вам в случае необходимости придется вручную настраивать размер базы данных. Если вы нажмете на Automatically grow the database files, то можно будет задать способ, которым будет выполняться рост файла базы данных: добавками фиксированного размера (задаваемого в мегабайтах) либо как некоторая доля от текущего размера (задаваемая в процентах). Помните, что файл базы данных будет расти только в случае необходимости. Кроме того, вы должны либо ограничить возможный рост базы данных (задать максимальный размер), либо позволить ей расти без ограничений. Настройки, заданные в этом экране, применяются ко всем файлам базы данных, созданным на шаге 4. Вы не можете применять мастер Create Database Wizard для конфигурирования индивидуальных настроек роста отдельных файлов. Для продолжения работы мастера нажмите на Next.

    Экран Define the Database File Growth (Настройте рост файлов базы данных)


    Рис. 9.8.  Экран Define the Database File Growth (Настройте рост файлов базы данных)

  6. Появится экран Name the Transaction Log Files (Дайте имена файлам журнала транзакций). Этот экран выглядит так же, как и экран Name the Database Files, но он относится к файлу журнала. (Помните, что журнал транзакций хранит записи обо всех изменениях базы данных, которые понадобятся при восстановлении базы данных при отказе системы.) Первый файл журнала транзакций создается автоматически и получает в качестве префикса имени имя, заданное для базы данных. Вы можете согласиться с этим именем, а можете ввести с клавиатуры и другое. Данные журнала транзакций хранятся в файле с расширением .ldf. Если надо, вы можете добавить дополнительные файлы журналов. Если вы имеете какое-либо представление о будущем размере журнала транзакций, то введите сейчас этот размер, а если не знаете, то оставьте размер, указанный по умолчанию (вы сможете изменить его позднее при помощи команды ALTER DATABASE ). Для продолжения нажмите на Next.
  7. Появится экран Define the Transaction Log File Growth (Настройте рост файлов журнал транзакций). Этот экран выглядит так же, как и экран Define the Database File Growth, но в нем задаются настройки роста для файла журнала. Как и в шаге 5, вы можете выбрать автоматический рост файлов и, если хотите, задать настройки роста и максимальный размер файла. Для продолжения нажмите на Next.
  8. Появится экран Completing the Create Database Wizard (Завершение работы мастера Create Database Wizard) (рис. 9.9). Ознакомьтесь с настройками, заданными для вашей новой базы данных. Если все хорошо, то нажмите на Finish, чтобы завершить создание базы данных, а если нет, то нажмите на Back и внесите необходимые изменения.

    Экран Completing the Create Database Wizard (Завершение работы мастера Create Database Wizard)


    Рис. 9.9.  Экран Completing the Create Database Wizard (Завершение работы мастера Create Database Wizard)

  9. Как только ваша база данных будет создана, появится информационное окно мастера Create Database Wizard, с сообщением, что база данных была успешно создана. Нажмите на OK, чтобы закрыть это окно.
  10. Появится еще одно информационное окно с вопросом, не желаете ли вы создать план обслуживания (maintenance plan) для новой базы данных. Рекомендуется создать план обслуживания, потому что благодаря ему обеспечивается хорошая производительность вашей базы данных, регулярное резервное копирование в случае отказа системы и проверки базы данных на непротиворечивость. Но планы обслуживания мы рассмотрим только в лекции 30, поэтому пока что нажмите на No, чтобы завершить создание базы данных.
Применение Enterprise Manager

При помощи SQL Server Enterprise Manager вы можете создавать более сложные базы данных, чем те, которые можно создать с помощью мастера Create Database Wizard. Вы можете задать разные настройки роста для каждого из создаваемых файлов, а не одинаковые для всех файлов. Вы также можете создавать пользовательские группы файлов. Для создания базы данных при помощи Enterprise Manager выполните последовательность шагов, которые будут перечислены ниже. В нашем примере мы создадим базу данных с именем MyDB, имеющую первичный файл данных, три вторичных файла данных (находящихся в той же самой пользовательской группе файлов) и один файл-журнал.

  1. Откройте Enterprise Manager. В левой панели раскройте группу SQL Server, в которой находится имя сервера, на котором вы хотите создать базу данных, а затем раскройте узел самого этого сервера. Затем нажмите правой кнопкой мыши на папку Databases и выберите New Database.
  2. Откроется окно свойств базы данных (Database Properties) с открытой вкладкой General (Общие) (рис. 9.10). Введите с клавиатуры имя базы данных в поле Name.
  3. Откройте вкладку Data Files (см. рис. 9.11). Как видите, Enterprise Manager автоматически создает первичный файл данных, с именем вашей базы данных в качестве префикса и PRIMARY в качестве имени группы файлов. Вы можете изменить имя, местоположение и размер первичного файла, но вы не сможете изменить группу файла для первичного файла данных. Введите с клавиатуры имя файла (логическое имя), местоположение (физическое имя), размер и группу для каждого из создаваемых вами файлов. Для каждого файла данных, кроме первичного файла, вы можете задать имя пользовательской группы файлов, и, в соответствии с вашим желанием, эта группа файлов будет создана. В нашем примере мы создали вторичный файл данных MyDB_Data2 в группе файлов My_FG.

    Вкладка General окна свойств базы данных


    Рис. 9.10.  Вкладка General окна свойств базы данных

    Вкладка Data Files окна свойств базы данных


    Рис. 9.11.  Вкладка Data Files окна свойств базы данных

    По умолчанию, каждый файл располагается на диске в папке, в которой инсталлирован SQL Server. Вы можете изменить эту настройку, задав другой путь с клавиатуры или при помощи экранной кнопки для его поиска ("...").
  4. В области File Properties (Свойства файла) в нижней части окна вы можете задать настройки автоматического роста для отдельных файлов. Выделите имя файла, для которого вы хотите задать настройки роста. Чтобы разрешить автоматический рост этого файла, установите флажок Automatically grow file. Затем вы можете задать приращение файла, выраженное в мегабайтах или в процентах от свободного места, оставшегося в файле. Нажав на селективную кнопку Restrict file growth (Ограничить рост файла), вы также можете задать максимальный размер файла, указав предел роста, выраженный в мегабайтах, а можете и не ограничивать рост файла. Эти настройки можно задавать при создании каждого из файлов, а можете оставить настройки, применяемые по умолчанию, и задать их позднее при помощи окна Enterprise Manager Database Properties. Если вам понадобится удалить файл из списка, то выделите имя этого файла и нажмите на экранную кнопку Delete.
  5. Завершив конфигурацию всех файлов данных, откройте вкладку Transaction Log и сконфигурируйте файлы журнала транзакций. Файлы журнала конфигурируются точно так же, как и файлы данных, за исключением того, что вы не сможете задать для них группу файлов, потому что они не принадлежат ни одной из групп файлов. Задайте с клавиатуры имя файла (логическое имя), местоположение (физическое имя) и начальный размер для одного или нескольких файлов журнала. Кроме того, задайте настройки автоматического роста файлов журнала, так же как это было описано в п.4 для файлов данных.
  6. После того как вы настроите все файлы так, как вам это нужно, нажмите на OK, и SQL Server создаст базу данных. Вернитесь в Enterprise Manager и нажмите на папку Databases сервера, в который вы только что добавили новую базу данных. Вы увидите в правой панели Enterprise Manager, что SQL Server добавил значок-иконку для этой базы данных.
Применение операторов T-SQL

Возможно, вы пожелаете создавать или изменять свои базы данных при помощи операторов T-SQL, не пользуясь графическим пользовательским интерфейсом (GUI). Вы можете создавать свои собственные сценарии, которые пригодятся при создании баз данных. Допустим, вы создали базу данных, а потом обнаружили, что задали неверное местоположение какого-либо файла. Можно уничтожить эту базу данных и начать все снова. Если для создания базы данных вы применяете сценарий T-SQL, то вы сможете быстро его поправить и запустить снова, а не задавать повторно все данные в графическом пользовательском интерфейсе. Если вам надо создать такую же базу данных на другом компьютере (например, на "горячем" резервном компьютере), то вы можете запустить на нем тот же самый сценарий.

С другой стороны, Enterprise Manager можно применить для генерации сценариев T-SQL, применяемых для создания баз данных (а также сценариев для создания любых объектов баз данных), но только после того, как база данных будет создана. Сценарии, сгенерированные Enterprise Manager, будут содержать все настройки текущей базы данных, что может быть полезно, поэтому вы можете захотеть пользоваться сгенерированным сценарием. Но независимо от того, будете ли вы писать свои сценарии или пользоваться сгенерированными, это окажется полезным для понимания кода T-SQL, применяемого для создания баз данных. В данном разделе мы рассмотрим операторы T-SQL для создания баз данных. Эти команды можно набрать с клавиатуры в файл и создать сценарий. (О создании и запуске сценариев см. лекцию 13.)

Практические советы.

Простая база данных

В данном примере мы создадим базу данных с именем MyDB, содержащую: первичный файл данных (MyDB_root); один вторичный файл данных (MyDB_data1), который по умолчанию останется в первичной группе файлов и один файл журнала транзакций (Log_data1). Ниже показаны операторы SQL, которые создадут базу данных MyDB:

CREATE DATABASE MyDB 
ON 
(NAME = MyDBroot,  --Первичный файл данных 
FILENAME = 'c:\mssql2k\MSSQL\data\mydbroot.mdf', 
SIZE = 8MB, 
MAXSIZE = 9MB, 
FILEGROWTH = 100KB), 
(NAME = MyDBdata1,   --Вторичный файл данных
FILENAME = 'c:\mssql2k\MSSQL\data\mydbdata1.ndf', 
SIZE = 1000MB, 
MAXSIZE = 1500MB, 
FILEGROWTH = 100MB) 
LOG ON 
(NAME = Logdata1, --Файл журнала
FILENAME = 'e:\log_files\logdata1.ldf', 
SIZE = 1000MB, 
MAXSIZE = 1500MB, 
FILEGROWTH = 100MB)

Обратите внимание, что в приведенном выше примере первичный и вторичный файлы данных оба расположены на диске C, а файл журнала расположен на диске E. Мы уже говорили, что файлы данных и файлы журналов нужно всегда размещать на физически разных устройствах, чтобы повысить производительность ввода-вывода при доступе к дискам. Кроме того, обратите внимание, что были использованы рекомендуемые расширения имен файлов – .mdf, .ndf, и .ldf. Настройки SIZE (Размер), MAXSIZE (Максимальный размер) и FILEGROWTH (Рост файла) могут быть заданы в Кб либо в Мб (по умолчанию применяются Мб).

Дополнительная информация. Более подробное описание оператора CREATE DATABASE вы найдете в Books Online, в теме "Create Database" (Создание базы данных).
Практические советы.

Этот пример базы данных относится к системе с несколькими дисковыми накопителями или с несколькими массивами дисков в RAID-системе. Мы будем употреблять термин "диск", когда будем говорить и об отдельных дисковых накопителях, и о массивах дисковых накопителей, работающих как том RAID. Будут созданы несколько файлов, каждый на своем отдельном диске. Каждый файл помещается в одну из двух групп файлов. Наша база данных получит имя Sales и будет содержать следующие файлы:

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

CREATE DATABASE Sales 
ON PRIMARY             	     --Явное задание первичной
                                     --группы файлов (не обязательно) 
(NAME = Sales_root,       --Первичный файл данных
FILENAME = 'c:\mssql2k\MSSQL\data\salesroot.mdf', 
SIZE = 8MB, 
MAXSIZE = 10MB, 
FILEGROWTH = 1MB), 
FILEGROUP customers_group    --Группа файлов для следующих файлов 
(NAME = customerdata1,          --Вторичный файл данных
FILENAME = 'd:\mssql2k\MSSQL\data\customerdata1.ndf', 
SIZE = 800MB, 
MAXSIZE = 1000MB, 
FILEGROWTH = 100MB), 
(NAME = customerdata2,           --Вторичный файл данных
FILENAME = 'e:\mssql2k\MSSQL\data\customerdata2.ndf', 
SIZE = 800MB, 
MAXSIZE = 1000MB, 
FILEGROWTH = 100MB), 
(NAME = customerdata3,           --Вторичный файл данных
FILENAME = 'f:\mssql2k\MSSQL\data\customerdata3.ndf', 
SIZE = 800MB,
MAXSIZE = 1000MB, 
FILEGROWTH = 100MB), 
FILEGROUP products_group   	--Группа файлов для следующих файлов 
(NAME = productdata1,            	--Вторичный файл данных
FILENAME = 'g:\mssql2k\MSSQL\data\productdata1.ndf', 
SIZE = 500MB, 
MAXSIZE = 700MB, 
FILEGROWTH = 100MB), 
(NAME = productdata2,           	--Вторичный файл данных
FILENAME = 'h:\mssql2k\MSSQL\data\productdata2.ndf', 
SIZE = 500MB, 
MAXSIZE = 700MB, 
FILEGROWTH = 100MB) 
LOG ON 
(NAME = logdata1,                    	--Файл журнала
FILENAME = 'i:\log_files\logdata1.ldf', 
SIZE = 800MB, 
MAXSIZE = 1000MB, 
FILEGROWTH = 200MB)

Из комментариев к этому примеру видно, что перед заданием первичного файла можно в явном виде задать первичную группу файлов. Но явное задание не обязательно, т.к. по умолчанию считается, что происходит задание первичной группы файлов. Две другие группы файлов, customers_group и products_group, задаются непосредственно перед определениями размещаемых в них файлов. Все файлы, перечисленные после определения группы файлов, будут помещаться в эту группу файлов до тех пор, пока не появится определение новой группы файлов или не появится предложение LOG ON.

Обратите внимание на обозначения дисков для файлов. Каждый из файлов создается на своем диске, чтобы при создании таблиц и индексов в группах файлов данные могли бы равномерно распределяться по многим дискам. Например, данные из таблицы, созданной в группе файлов customers_group разместятся на нескольких дисках, на которых будут располагаться файлы customer_data1.ndf, customer_data2.ndf и customer_data3.ndf. Файл журнала тоже располагается на отдельном диске, на котором не располагаются никакие файлы данных, благодаря чему становится возможной запись файла журнала с последовательным вводом-выводом (перемещением записывающих головок дискового накопителя только на соседние дорожки).

Если вы не хотите, чтобы SQL Server производил автоматический рост файла, то задайте FILEGROWTH=0, тогда файлу будет разрешено заполнять только первоначально отведенное для него пространство. Эту настройку можно задать, когда происходит работа со статическими таблицами, т.е. с таблицами, которые не растут. В этом случае в операторе не требуется задавать MAXSIZE, максимальный размер файла будет совпадать с начальной настройкой SIZE.

Примечание. Те, кто хорошо знаком с SQL Server версии 6.5 или более ранними версиями, заметят, что перед созданием базы данных больше не применяется команда DISK INIT для создания логических устройств. Вместо логических устройств теперь используются файлы.

Просмотр баз данных

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

Применение Enterprise Manager

Для просмотра информации в базе данных при помощи Enterprise Manager, выполните следующие действия:

  1. Находясь в Enterprise Manager, нажимая на значки-плюсы, раскройте списки для группы SQL Server, имя сервера, на котором находится база данных, и папку Databases (см. рис. 9.12).

    Enterprise Manager с раскрытой папкой Databases


    увеличить изображение

    Рис. 9.12.  Enterprise Manager с раскрытой папкой Databases

  2. Нажмите на имя нужной базы данных, и тогда отобразятся находящиеся в ней объекты (см. рис. 9.13).

    Объекты из базы данных Northwind


    увеличить изображение

    Рис. 9.13.  Объекты из базы данных Northwind

Применение команд SQL

Информацию о базах данных можно просматривать, также запуская команды T-SQL, при помощи окна с приглашением командной строки или из Query Analyzer. Чтобы посмотреть информацию о базе данных при помощи команды SQL, выдаваемой из командной строки, откройте окно с приглашением командной строки и осуществите соединение с SQL Server через OSQL, при помощи, например, такой команды:

OSQL   -U<имя_пользователя>   -P<пароль>   -S<имя_сервера>

Когда вы будете набирать эту команду, подставьте в нее вместо слов в угловых скобках свои имя пользователя, пароль и имя сервера (сами угловые скобки вводить не надо).

Для применения Query Analyzer нажмите на экранную кнопку Start, укажите на Programs, укажите на Microsoft SQL Server, а затем выберите Query Analyzer.

Теперь вводите команды T-SQL либо в окне Query Analyzer, либо в командной строке OSQL. Для просмотра информации о базах данных запустите такие команды:

Use MyDB--Задает контекст используемой базы данных
GO 
Sp_helpfile--Показывает информацию для всех файлов базы данных
GO--Чтобы посмотреть информацию только для некоторого файла, укажите его имя 
Sp_helpdb MyDB--То же самое, но выдается также информация о месте на диске, 
    выделенном  для базы данных 
GO 
Sp_helpfilegroup--Показывает информацию о группах файлов данной базы данных 
GO--Чтобы посмотреть информацию только о некоторой группе файлов, --укажите ее имя
Sp_helpdb--Показывает информацию обо всех базах данных
GO
Дополнительная информация.Подробности об использовании этих команд и о том, как расшифровывать выдаваемую ими информацию, вы найдете в SQL Server Books Online.

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

Когда-нибудь вам может понадобиться удалить какую-либо базу данных. Помните, что это – "дорога в одну сторону"; удалив базу данных, вы сможете восстановить ее только из резервной копии. Поэтому безопаснее всего будет перед удалением базы данных выполнить ее резервное копирование, на случай, если эта база данных снова понадобится в будущем. Базы данных можно удалять как при помощи Enterprise Manager, так и командами T-SQL.

Применение Enterprise Manager

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

  1. Находясь в Enterprise Manager, раскройте группу SQL Server, а затем раскройте имя сервера, на котором установлена база данных.
  2. Раскройте папку Databases, чтобы стали видны имеющиеся базы данных.
  3. Нажмите правой кнопкой мыши на имя удаляемой базы данных, а затем выберите Delete в контекстном меню. Появится сообщение Delete Database об удалении базы данных (рис. 9.14). В нем спрашивается также, желаете ли вы вместе с базой данных удалить и историю ее резервных копирований и восстановлений. Если флажок Delete backup and restore history for the database будет установлен, то вся информация о резервных копированиях и восстановлениях, хранящаяся в базе данных msdb, будет удалена. Если вы желаете сохранить эту информацию, то снимите флажок Delete backup and restore history for the database. Для подтверждения своего решения удалить базу данных, нажмите на Yes.

     Окно сообщения Delete Database


    Рис. 9.14.  Окно сообщения Delete Database

Примечание. Вы не сможете удалить базу данных master (главную системную базу данных).
Применение команд SQL

Администрировать базы данных можно и при помощи команд T-SQL. Как мы уже говорили ранее, команды T-SQL можно запускать из Query Analyzer или из окна с приглашением командной строки. Чтобы удалить базу данных при помощи команды T-SQL, откройте или Query Analyzer (мы уже объясняли, как это сделать), или окно с приглашением командной строки, и осуществите соединение с SQL Server через OSQL, при помощи такой команды:

OSQL   -U<имя_пользователя>   -P<пароль>   -S<имя_сервера>

Помните, что удаление базы данных является неотменяемым действием. Для удаления баз данных применяется T-SQL-команда DROP DATABASE. Ниже показаны команды, которые удалят базу данных MyDB и все ее файлы:

USE master--Для запуска команды DROP DATABASE вы должны 
GO  --применять базу данных master 
DROP DATABASE MyDB --Единственным параметром этой команды является имя удаляемой базы данных. 
GO

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

Заключение

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

Лекция 10. Создание таблиц баз данных

Создание таблиц – следующий наиболее важный этап при проектировании базы данных. От результата работы на данном этапе в большей степени зависит быстродействие будущей системы. Обзор системных типов данных позволяет определить область их применения. Обязательно следует прочесть справочное руководство по типам данных (Books Online), поставляемое вместе с SQL Server 2000. Неправильное использование параметров при создании таблиц приводит к различным ошибкам, отображенным в лекции. Примеры использования оператора CREATE TABLE, использование системных хранимых процедур sp_addtype и sp_droptype, применение NULL-значений, использование свойства IDENTITY. Уделяется немало внимания созданию таблиц с помощью Enterprise Manager, что, в свою очередь, позволяет выбрать наиболее приемлемый для вас путь создания и управления таблицами и ограничениями.

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

В данной лекции вы познакомитесь с системными и пользовательскими типами данных, узнаете, как помещать таблицы в группы файлов, узнаете, что такое null -значения и свойство IDENTITY. Вы также научитесь создавать таблицы при помощи Enterprise Manager и команд Transact SQL (T-SQL). Мы также вкратце затронем здесь другие важные вопросы, относящиеся к созданию таблиц, такие как ограничения, значения по умолчанию и индексы, о которых будет рассказано более подробно в последующих лекциях.

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

Создание основы структуры таблиц

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

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

Основные понятия, относящиеся к таблицам

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

Создание таблицы базы данных

Таблица – это объект базы данных, который хранит данные в виде совокупности строк и колонок. Таблица определяется содержащимися в ней колонками. Данные организованы в форме, похожей на электронные таблицы Excel (см. пример таблицы Product_Info, показанный в табл. 10.1). Таблица Product_Info, используемая в наших примерах, будет создана в базе данных MyDB.

Таблица Product_Info применяется для хранения информации обо всех продуктах, продаваемых в магазине. Когда продукт становится готов к продаже, данные о нем добавляются в новую строку таблицы Product_Info. Эта таблица состоит из пяти колонок: Product_ID (Идентификатор продукта), Product_Name (Название продукта), Description (Описание), Price (Цена) и Brand_ID (Название торговой марки). В табл. 10.1 показаны в качестве примера три строки данных из таблицы Product_Info. Оператор T-SQL, применявшийся для создания этой таблицы (пустой, без данных) показан в разделе "Создание таблицы Product_Info с использованием системных типов данных" далее в этой лекции. (Об использовании оператора INSERT, применяемого для вставки данных в таблицы см. лекцию 20.)

Таблица 10.1. Таблица Product_Info
Product_IDProduct_NameDescriptionPriceBrand_ID
1Пятифутовый тентДля одного-двух человек80.0012
2Мини-печьРаботает на керосине20.0033
3РюкзакСо стальным каркасом60.0015

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

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

Применение системных типов данных

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

Типы данных могут также применяться к колонкам для представлений, параметров в хранимых процедурах и в функциях T-SQL, возвращающих одно или несколько значений данных. Встроенные типы данных, имеющиеся в SQL Server, перечислены в табл. 10.2. В SQL Server 2000 появились три новых типа данных: bigint, sql_variant и table. (Кроме нескольких исключений, явно указанных в табл. 10.2, для всех указанных объектов применяются те же самые типы данных.)

Таблица 10.2. Системные типы данных SQL Server 2000
Тип данныхОписаниеСколько места занимает
tinyintЦелочисленные данные в диапазоне от 0 до 255.1 байт
unique-identifierХранит 16-байтное двоичное значение, являющееся глобальным уникальным идентификатором (GUID)16 байт
varbinaryДвоичные данные переменной длины, состоящие из n байтов, где n может принимать значение от 1 до 8000. Применяйте тип varbinary, если предполагаете, что элементы данных, хранимые в колонке, будут сильно отличаться по своим размерамФактическая длина введенных данных плюс 4 байта
varchar[(n)]Данные переменной длины не в кодировке Unicode, длиной в n символов, где n может принимать значение от 1 до 8000Фактическая длина введенных данных
Как правильно выбрать тип данных

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

Выбор подходящего типа данных является довольно понятным процессом. Данные, которые будут вводиться в колонку, должны соответствовать типу данных, заданному для этой колонки. Поэтому вам следует выбрать такой тип данных, который лучше всего охватит диапазон значений, которые могли бы храниться в колонке для всего срока эксплуатации вашего приложения, и в то же время стремясь ограничить ненужный расход места на диске. Ненужный расход места на диске – это место на диске, выделенное для элементов данных, хранящихся в колонке, но не используемое. Например, предположим, у вас есть колонка, в которой нужно хранить одно целое число в диапазоне от 1 до 100. Очевидно, что эти значения могут храниться в типе integer, но каждое целое число типа integer занимает 4 байта. Данные с типом tinyint могут хранить значения от 0 до 255 и для них нужен только 1 байт места. В данном случае tinyint будет наилучшим выбором, потому что это экономит место на диске, необходимое для хранения данных из таблиц.

Затем вы должны определить, какой тип данных следует использовать – с фиксированной либо с переменной длиной. Если все значения данных из колонки будут иметь приблизительно одинаковые размеры, то более эффективным станет применение типа данных с фиксированной длиной, так как обработка данных, имеющих типы переменной длины, вызывает повышенную нагрузку. Вообще говоря, типы данных с переменной длиной следует применять, только если вы предполагаете значительные различия в длине данных, хранимых в данной колонке, и когда данные из колонки обновляются редко. К данным с переменной длиной относятся varchar, nvarchar, varbinary, text, ntext и image.Применение типов данных с переменной длиной может привести к значительной экономии места для хранения данных. Например, если вы зададите тип данных с фиксированной длиной, достаточной для хранения значений в колонке с наибольшей возможной длиной, то для всех значений, занимающих меньше места, истратиться столько же места, как и для этого самого объемного значения. Результатом этого станут огромный ненужный расход места на диске, потому что лишь немногие строки будут расходовать все максимально допустимое место для данных. В большинстве строк будет использовано меньше места, а все неиспользуемое место станет потерянным. А если вы зададите, что будет применяться тип данных с переменной длиной, то короткие значения будут расходовать лишь то место, которое им действительно нужно. Но опять-таки, применение типов данных с переменной длиной повышает нагрузку на процессор. Поэтому, если вам не требуется тип данных с переменной длиной, то применяйте тип данных с фиксированной длиной. Если из соображений расходования места для хранения данных нужно применять тип данных с переменной длиной, то, конечно, применяйте его.

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

Создание таблицы Product_Info с использованием системных типов данных

Прежде чем продолжить наше изложение, давайте рассмотрим T-SQL-оператор CREATE TABLE, которую можно применить для создания таблицы Product_Info, показанной в этой лекции ранее в табл. 10.1. В этом примере мы применим только системные типы данных и колонки с фиксированной длиной. Когда вы создаете таблицу при помощи оператора T-SQL, она создается в базе данных, которой вы пользуетесь в текущий момент. Если вы хотите создать таблицу в какой-либо конкретной базе данных, то надо применить оператор USE имя_базы_данных, как показано в примере кода (в нашем примере база данных имеет имя MyDB). Ключевое слово GO означает, что все предыдущие операторы должны быть теперь выполнены. (Об использовании T-SQL см. лекцию 13.)

USE MyDB 
GO 
CREATE TABLE Product_Info 
( 
Product_ID    smallint,
Product_Name    char(20), 
Description  char(30), 
Price   smallmoney, 
Brand_ID	smallint 
) 
GO

Давайте посмотрим, что произойдет при исполнении этого кода. После оператора CREATE TABLE следует спецификация таблицы с именем Product_Info. Между открывающей и закрывающей скобками заданы имена колонок и их типы данных. Длины для двух типов данных заданы равными 20 и 30, потому что большинство названий продуктов уместятся в 20 символов, а большинство описаний продуктов уместятся в 30 символов. Для Product_ID и Brand_ID применяется тип данных smallint, а не tinyint, потому что мы предполагаем, что количество разновидностей как продуктов, так и торговых марок, превысит 255 (максимальное значение для типа tinyint ), хотя и будет меньше, чем 32767 (максимальное значение для типа smallint ). Так как значения больше, чем 32767, нам не понадобятся, то при использовании типа int мы напрасно тратили бы место на диске.

Работа с пользовательскими типами данных

Пользовательские типы данных (типы данных, задаваемые пользователями, user-defined data types) или, как их еще называют, "псевдонимные", "алиасные" типы данных (alias data types)являются индивидуально настроенными системными типами данных. Индивидуальная настройка типов данных (задание типов данных) полезна, когда вы имеете несколько таблиц, в колонках которых должны храниться данные одинаковых типов, а вы хотите гарантировать точное соответствие колонок каждой из таблиц по типу, длине и возможности применения null-значений. Вы можете создать тип данных с осмысленным именем, что упростит программирование и улучшит согласованность таблиц. Затем вы сможете применять этот тип данных при создании многих других таблиц.

Например, предположим, что у нас имеется еще одна таблица, с именем Brands (торговые марки) в той же базе данных, в которой находится таблица Product_Info. Пусть в таблице Brands имеется колонка Brand_ID, соответствующая колонке Brand_ID таблицы Product_Info. Пусть в таблице Brands хранятся названия торговых марок и другая информация, относящаяся к торговым маркам. Чтобы гарантировать, что колонки Brand_ID в обеих таблицах имеют одинаковый тип данных и не допускают null -значений, вы можете создать пользовательский тип данных и присвоить его обеим колонкам. А теперь представьте, что у вас имеется несколько таблиц с колонками, которые должны иметь одинаковые атрибуты. Вы можете не помнить, применяли ли вы в одной таблице тип smallint, или же tinyint, или было ли позволено применять null -значения. Если создать тип данных с понятными именем, то вам не придется беспокоиться о правильности применяемых атрибутов, и вы получите гарантию согласованности данных для всех таблиц.

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

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

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

  1. Находясь в Enterprise Manager, нажимая на значок-плюс рядом с папкой, раскройте группу SQL Server, а затем раскройте сервер.
  2. Раскройте папку Databases, а затем раскройте базу данных. Ваше окно Enterprise Manager будет выглядеть примерно как на рис. 10.1.

    Определение типа данных при помощи Enterprise Manager


    увеличить изображение

    Рис. 10.1.  Определение типа данных при помощи Enterprise Manager

  3. Нажмите правой кнопкой мыши на User Defined Data Types (Пользовательские типы данных) и выберите New User Defined Data Type (Новый пользовательский тип данных) в контекстном меню. Появится окно свойств пользовательского типа данных.
  4. В поле Name введите имя нового типа данных. Для нашего примера мы задали имя brand_type (рис. 10.2).
  5. Затем вы должны задать системный тип данных SQL Server и длину поля вашего пользовательского типа данных. В нашем примере мы задали тип данных для колонки Brand_ID, поэтому мы выбрали тип данных smallint, имеющий стандартную длину, равную 5. (Если бы мы создали символьный тип данных, то тогда можно было бы задать его длину.)

     Окно свойств пользовательского типа данных


    Рис. 10.2.  Окно свойств пользовательского типа данных

  6. Если ваш тип данных позволяет использовать null -значения, то установите флажок Allow NULLs. (См. раздел "Применение null-значений" далее в этой лекции.)
  7. Если ваш тип данных должен использовать какие-либо предопределенные правила или значения по умолчанию, то выберите их в соответствующих полях со списками. (О правилах и значениях по умолчанию см. лекцию 16.)
  8. Чтобы сохранить ваш новый тип данных, нажмите на OK.
Удаление пользовательских типов данных при помощи Enterprise Manager

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

  1. Находясь в Enterprise Manager, выберите пользовательский тип данных, который нужно удалить (раскройте группу SQL Server, раскройте сервер, раскройте папку Databases, а затем раскройте базу данных, в которой содержится удаляемый тип данных).
  2. Нажмите на папку User Defined Data Types. В правой панели станут видны пользовательские типы данных, имеющиеся в базе данных (рис. 10.3).
  3. Нажмите правой кнопкой мыши на пользовательский тип данных, который вы хотите удалить, и выберите Delete (Удалить) в появившемся контекстном меню. Появится диалоговое окно Drop Objects (Удалить объекты) (рис. 10.4).
  4. Прежде чем удалить тип данных, нажмите на Show Dependencies (Показать зависимости), в результате чего появится диалоговое окно Dependencies (Зависимости) (рис. 10.5).

    В поле-списке в левой части диалогового окна Dependencies показаны объекты базы данных, которые зависят от вашего пользовательского типа данных, а в поле-списке в правой части диалогового окна показаны объекты, от которых зависит ваш пользовательский тип данных. Если этот тип данных используется в каких-либо таблицах или объектах (как тип данных в нашем примере), то вам не будет позволено удалить его – при попытке удаления (если вы перейдете к шагу 5) появится сообщение об ошибке (рис. 10.6).

     Папка User Defined Data Types (Пользовательские типы данных)


    увеличить изображение

    Рис. 10.3.  Папка User Defined Data Types (Пользовательские типы данных)

     Диалоговое окно Drop Objects (Удалить объекты)


    Рис. 10.4.  Диалоговое окно Drop Objects (Удалить объекты)

  5. Если у вашего типа данных не возникает проблем с тем, что он где-то используется, то закройте диалоговое окно Dependencies, а затем нажмите на экранную кнопку Drop All (Удалить все) в диалоговом окне Drop Objects, чтобы удалить этот тип данных. Не волнуйтесь, удалены будут только типы данных, показанные в диалоговом окне Drop Objects, а не все ваши пользовательские типы данных.

     Диалоговое окно Dependencies (Зависимости)


    Рис. 10.5.  Диалоговое окно Dependencies (Зависимости)

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


    Рис. 10.6.  Сообщение об ошибке, появляющееся при попытке удалить тип данных, находящийся в использовании

Создание и удаление пользовательских типов данных при помощи T-SQL

Системная хранимая процедура sp_addtype является командой T-SQL, применяемой для создания пользовательских типов данных. При помощи запуска этой команды в то время, когда вы работаете с модельной базой данных (базой данных model), можно организовать применение нового типа данных во всех вновь создаваемых пользовательских базах данных, потому что эти базы данных создаются с такими же атрибутами, как и у базы данных model. Запуск этой команды при работе с пользовательской базой данных позволит применять новый тип данных только в этой базе данных. (Помните, что для работы с конкретной базой данных вы должны запускать команду USE имя_базы_данных.) Ниже дан пример команд T-SQL, создающих пользовательский тип данных brand_type в базе данных model:

USE model 
GO 
sp_addtype brand_type, 'smallint', 'NOT NULL' 
GO

Три параметра у sp_addtype – это имя пользовательского типа данных, системный тип данных, на котором основывается новый тип данных и возможность использования null -значений в новом типе данных. Новый тип данных, brand_type, появится во всех вновь создаваемых пользовательских базах данных. Если вы создадите пользовательский тип данных в пользовательской базе данных и захотите посмотреть новый тип данных через Enterprise Manager, то выберите команду Refresh в меню Action Enterprise Manager’а.

Чтобы удалить ненужный пользовательский тип данных, запустите команду sp_droptype в базе данных, в которой этот тип данных был определен. Ниже дан пример команд T-SQL, удаляющих пользовательский тип данных brand_type из базы данных model. (Напомним, что если вы создали этот тип данных в пользовательской базе данных и хотите, чтобы в Enterprise Manager было видно, что этот тип данных был удален, то выберите в Enterprise Manager команду Refresh в меню Action.)

USE model 
GO 
sp_droptype brand_type 
GO
Создание таблиц Product_Info и Brands с применением пользовательских типов данных

Давайте вернемся к нашему примеру базы данных. Мы создадим заново таблицу Product_Info, пользуясь новым пользовательским типом brand_type, а затем создадим таблицу Brands. Эта таблица, как и таблица Product_Info, будет иметь колонку Brand_ID и мы применим для этих колонок одинаковый пользовательский тип данных brand_type. Сначала нам надо будет удалить старую таблицу Product_Info, чтобы мы смогли бы создать ее снова. Ниже показан код, который выполнит все необходимые действия:

USE MyDB 
GO
DROP TABLE Product_Info
GO 
CREATE TABLE Product_Info 
( 
Product_ID     		smallint,
Product_Name   	char(20), 
Description    		char(30), 
Price          			smallmoney, 
Brand_ID       		brand_type 
) 
GO
CREATE TABLE Brands
(
Brand_ID       		brand_type,
Brand_Name     		char(30),
Supplier_ID    		smallint
)
GO

Задав одинаковый тип данных brand_type для колонок Brand_ID в обеих таблицах, мы гарантируем одинаковость атрибутов обеих колонок. Нам не надо помнить об особенностях типа данных, на котором основывается тип данных brand_type, мы можем просто применять новый тип данных для всех колонок Brand_ID.

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

Создание таблиц в заданной группе файлов

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

Создание таблицы Product_Info в заданной группе файлов

Предположим, что в созданной нами базе данных MyDB имеется группа файлов с именем product_group, содержащая один вторичный файл данных, который размещен на другом диске (E), чем диск, на котором размещена первичная группа файлов (С). Применяя эту методику, вы можете физически отделить свои таблицы данных от системных таблиц SQL Server. Еще мы создадим на отдельном диске (F) файл журнала, чтобы отделить ввод-вывод журнала. (Про создание баз данных и применение групп файлов см.лекцию 9.) Необходимые команды могут выглядеть так:

USE master 
GO 
CREATE DATABASE MyDB 
ON PRIMARY                         		-- Явное задание первичной 
                                   		-- группы файлов (не обязательно) 
(NAME = MyDBroot,               			-- Первичный файл данных
FILENAME = 'c:\mssql2k\MSSQL\data\mydbroot.mdf', 
SIZE = 8MB, 
MAXSIZE = 10MB, 
FILEGROWTH = 1MB),
FILEGROUP product_group        		-- Группа файлов для следующего файла
(NAME = MyDBdata1,                 		-- Вторичный файл данных
FILENAME = 'e:\mssql2k\MSSQL\data\mydbdata1.ndf', 
SIZE = 1000MB, 
MAXSIZE = 1500MB, 
FILEGROWTH = 100MB) 
LOG ON 
(NAME = Logdata1,                     			-- Файл журнала
FILENAME = 'f:\log_files\logdata1.ldf', 
SIZE = 1000MB, 
MAXSIZE = 1500MB,
FILEGROWTH = 100MB)
GO

А теперь мы можем создать таблицу Product_Info в группе файлов product_group, пользуясь командой CREATE TABLE, как показано ниже.

USE MyDB 
GO 
CREATE TABLE Product_Info 
( 
Product_ID     		smallint,
Product_Name   	char(20), 
Description    		char(30), 
Price          			smallmoney, 
Brand_ID       		brand_type 
) 
on product_group 
GO

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

Применение null-значений

Null-значение (null value) – это неизвестное значение, для которого применяется обозначение NULL. Способность хранить null-значения (nullability) – это свойство, благодаря которому колонка способна либо хранить null -значения, либо отвергать их. Null -значение в колонке обычно означает, что для данной строки этой колонки нет данных, потому что значение неизвестно, либо не имеет смысла, либо не задано или будет задано в будущем. Null -значения – это не пустые значения и не значения числа 0, их настоящие значения неизвестны (unknown), поэтому никакие два null -значения не являются равными.

Колонки, способные хранить null -значения, могут оказаться полезными в случаях, когда необходимая информация пока что недоступна для вас (это может быть, например, инициал для среднего имени покупателей). Что должно храниться в этой колонке для записи о некотором покупателе, который не имеет среднего имени, и поэтому не имеет среднего инициала? Если в этой колонке разрешено применять значения NULL, то null -значение будет правильным выбором и будет иметь смысл – благодаря этому вы поймете, что информация из данной колонки не имеет смысла.

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

Дополнительная информация. Более подробную информацию вы можете получить, открыв заголовок Null Values индекса Books Online, а затем выбрав тему "Comparison Search Conditions" (Условия для поиска по сравнению). Также прочитайте раздел "Добавление свойства IDENTITY" далее в данной лекции.

Прекрасной альтернативой применению null -значений в колонке является задание значения по умолчанию (default value) для этой колонки. Если значение не было задано при вводе строки, то в колонку записывается значение по умолчанию. (Более подробно о применении значений по умолчанию написано в лекции 16.) Если вы определите эту колонку, как способную хранить null -значения, т.е. два случая, когда колонка получит значение NULL:

Создание таблицы Product_Info с применением null-значений

Давайте вернемся к нашему примеру с таблицей Product_Info и зададим для каждой колонки возможность хранить null -значения. Если вы хотите, чтобы в колонке разрешалось хранить null -значения, то после типа данных надо добавить слово NULL. Если вы не хотите, чтобы разрешалось хранить null -значения, то после типа данных надо добавить слово NOT NULL. Мы рекомендуем всегда указывать, разрешается ли хранить в колонке null -значения, за исключением лишь случаев, когда применяются пользовательские типы данных (они уже заданы NULL или с NOT NULL ). Это поможет вам выработать привычку обращать внимание на необходимость способности к хранению null -значений в тех или иных колонках.

Дополнительная информация. Чтобы узнать, какова будет применяемая по умолчанию способность хранить null -значения, когда NULL или NOT NULL не заданы, обратитесь к теме "CREATE TABLE" в Books Online и, пользуясь "прокруткой", перейдите к разделу "Nullability Rules Within a Table Definition" (Задание таблиц: правила, определяющие способность к хранению null -значений). Явное задание NULL или NOT NULL будет иметь преимущество по отношению к этим правилам.

Пускай в нашем примере с таблицей Product_Info null -значения будет разрешено применять только в колонке для описаний продуктов. Мы не указали способность к хранению null-значений для типа данных brand_type, так как его способность к хранению null -значений уже была задана (как NOT NULL ) при создании этого пользовательского типа данных. Новый оператор CREATE TABLE будет выглядеть так:

USE MyDB 
GO
DROP TABLE Product_Info
GO 
CREATE TABLE Product_Info 
( 
Product_ID         		smallint NOT NULL,
Product_Name   	char(20) NOT NULL, 
Description         		char(30) NULL, 
Price                   smallmoney NOT NULL, 
Brand_ID            		brand_type 

) 
GO

Теперь, если описание продукта (Description) не будет задано, а значения остальных четырех полей – заданы, то в таблицу будет введена новая строка со значением NULL для элемента данных, находящегося в колонке Description. Вы должны будете ввести значения для четырех остальных колонок, не допускающих ввода значений NULL (колонок Product_ID, Product_Name, Price и Brand_ID ). Если данные для какой-либо из этих колонок не ввести, то попытка ввести новую строку будет неуспешной.

Добавление свойства IDENTITY

Когда вы создаете таблицу, вы можете задать одну из колонок как идентифицирующую колонку (identity column), добавив к определению колонки свойство IDENTITY. Если колонка создается со свойством IDENTITY, то SQL Server автоматически генерирует для этой колонки значение строки, рассчитываемое по начальному значению (seed value) и значению приращения (increment value). Начальное значение (seed) является значением идентификации для первой строки, вставленной в таблицу. Приращение (increment) – это величина, на которую SQL Server увеличивает значение идентификации для последовательно вводимых строк. Каждый раз при вводе строки SQL Server присваивает текущее значение идентификации элементу данных в колонке идентификации, вводимому в новую строку. Следующая введенная строка получит значение идентификации, большее, чем текущее максимальное значение идентификации на величину приращения. Таким образом, каждая вводимая строка получит уникальное значение идентификации. Свойство идентификации полезно для создания колонок, в которых каждая строка должна иметь уникальный идентификатор, например, для колонки Product_ID. Если вы разрешите SQL Server генерировать идентифицирующие значения для вводимых строк, то это окажется проще, чем следить за правильностью ввода последовательных значений. Идентифицирующие колонки обычно применяются в ограничениях первичного ключа в таблицах, благодаря которым возможна уникальная идентификация строк. (Про ограничения первичного ключа см. лекции 16.)

Например, если вы зададите IDENTITY(0, 10), то значение идентифицирующей колонки для первой введенной строки будет равно 0, для второй строки будет равно 10, для третьей строки – 20, и т.д. Если начальное значение или приращение не задать, то для них будут применяться значения по умолчанию, равные 1 и 1. Вы можете задать как оба этих параметра, так и один из них. Идентифицирующие колонки не могут содержать значения по умолчанию и для них не разрешено применение null -значений. В каждой из таблиц может иметься только одна идентифицирующая колонка.

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

SET IDENTITY_INSERT имя_таблицы ON

При помощи этого оператора можно вставить строку и назначить нужное вам значение идентифицирующей колонки. Закончив ввод строки, нужно отменить возможность вставки в идентифицирующую колонку при помощи такого оператора:

SET IDENTITY_INSERT имя_таблицы OFF

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

Добавление свойства IDENTITY для таблицы Product_Info

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

USE MyDB 
GO 
DROP TABLE Product_Info
GO 
CREATE TABLE Product_Info 
( 
Product_ID         		smallint IDENTITY(1, 1) NOT NULL,
Product_Name   	char(20) NOT NULL, 
Description         		char(30) NULL, 
Price                   	smallmoney NOT NULL, 
Brand_ID            		brand_type 
 
) 
GO

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

Создание таблиц с помощью Enterprise Manager

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

  1. Находясь в Enterprise Manager, раскройте группу SQL Server, а затем раскройте сервер.
  2. Раскройте папку Databases, чтобы стали видны имеющиеся базы данных.
  3. Раскройте базу данных, в которой вы хотите работать (в нашем примере – MyDB).
  4. Нажмите правой кнопкой мыши на папку Tables (Таблицы) и в появившемся контекстном меню выберите New Table (Новая таблица). Появится окно New Table (рис. 10.7).

     Окно New Table (Новая таблица)


    увеличить изображение

    Рис. 10.7.  Окно New Table (Новая таблица)

    Окно New Table содержит таблицу, похожую на электронную таблицу Excel. Каждая строка таблицы в окне New Table обозначает одну колонку таблицы базы данных. Каждая колонка таблицы в окне New Table обозначает какой-либо атрибут колонки таблицы – тип данных, длину или способность хранить null -значения.
    Примечание. При именовании колонок таблиц базы данных следует придерживаться некоторых стандартов. На самом деле, не важно, какую именно систему для наименований вы выберите, но вы должны придерживаться принятых правил. Всякий раз, когда вы используете такую же колонку в другой таблице, применяйте точно совершенно одинаковые имена. Такое единообразное использование имен поможет вам не запутаться, когда вы будете выполнять запросы.
  5. Задайте каждую из колонок вашей таблицы базы данных, заполняя поочередно строки таблицы окна: введите имена таблиц в колонке Column Name, выберите тип данных в выпадающих меню в колонке Data Type и выберите длину типа данных (если это допустимо, например, можно выбрать длину для символьных типов данных). Для переключения флажков в колонке Allow Nulls (Разрешаются null -значения) пользуйтесь клавишей Shift или нажимайте там мышью. В результате будет разрешаться или запрещаться применение null -значений. Заполнение для таблицы Product_Info показано на рис. 10.8. Обратите внимание, что для колонки Brand_ID мы выбрали пользовательский тип данных brand_type. Также обратите внимание, что по умолчанию флажок Allow Nulls (Разрешаются null -значения) в этой колонке установлен, даже для нашего типа данных brand_type, который был создан без разрешения применять null -значения. Вам следует снять этот флажок, чтобы обеспечить согласованность со способностью этого типа к хранению null -значений.

      Задание колонок при помощи окна New Table (Новая таблица)


    увеличить изображение

    Рис. 10.8.  Задание колонок при помощи окна New Table (Новая таблица)

    Данные в строках таблицы базы данных будут физически храниться в порядке, в котором вы задали колонки. Если вы пожелаете вставить в окно New Table строчку с определением колонки между двух уже имеющихся определений, то нажмите правой кнопкой мыши на строчку окна, под которой вы хотите вставить новую строчку, и в появившемся контекстном меню выберите команду Insert Column (Вставить колонку). Чтобы удалить строчку, нажмите правой кнопкой мыши на эту строчку и выберите Delete Column (Удалить колонку) в контекстном меню. В нашем примере с таблицей Product_Info мы зададим колонку Product_ID как колонку первичного ключа, нажав на ее имя правой кнопкой мыши и выбрав Set Primary Key (Задать первичный ключ) в контекстном меню. Рядом с именем колонки появится изображение ключа (рис. 10.9). (Про первичные ключи и другие ограничения см. лекцию 16.)

    Обозначение для первичного ключа


    увеличить изображение

    Рис. 10.9.  Обозначение для первичного ключа

  6. В нижней части окна New Table имеется вкладка с названием Columns, при помощи которой можно менять некоторые атрибуты колонки, выбранной в верхней части окна. Например, мы выбрали колонку Brand_ID, а затем во вкладке Columns задали ее назначение и значение по умолчанию, равное 0 (рис. 10.10).

      Вкладка Columns


    увеличить изображение

    Рис. 10.10.  Вкладка Columns

  7. Вы можете создавать другие ограничения и индексы для таблицы, нажимая на имена колонок правой кнопкой мыши и выбирая в контекстном меню Indexes/Keys (Индексы/Ключи), Relationships (Взаимоотношения), Constraints (Ограничения) или Properties (Свойства), либо нажав на значок-иконку Table and Index Properties (Свойства таблиц и индексов) рядом со значком-иконкой Save (Сохранить) в панели инструментов. Независимо от выбранного способа, появится окно свойств таблиц и индексов (рис. 10.11). Имя вашей таблицы будет обозначаться как Table1 или Table2 и т.д. Наша таблица получила имя Table2. При сохранении таблицы это имя можно изменить, см. описание следующего шага. Окно Properties имеет четыре вкладки, их подробные описания будут даны далее в материале нашей книги.

     Окно свойств таблиц и индексов


    Рис. 10.11.  Окно свойств таблиц и индексов

  8. Чтобы дать имя этой новой таблице, нажмите на значок-иконку Save. Появится диалоговое окно, в котором вы можете задать имя таблицы. Введите с клавиатуры нужное имя и нажмите на OK, и тогда спроектированная вами таблица будет создана, а заданная информация сохранится. Теперь вы можете закрыть окно New Table, и имя вашей таблицы появится в правой панели Enterprise Manager.

Заключение

В этой лекции вы изучили основы создания таблиц, научились применять и задавать типы данных, размещать таблицы в группах файлов, применять null -значения и добавлять свойство IDENTITY. Желательно привести таблицы в их окончательную форму до того, как вы будете заполнять их данными. В лекции 15 показаны несколько способов для изменения таблиц при помощи T-SQL. В нескольких следующих лекциях вы узнаете об инсталляции и настройке сети и о Microsoft Cluster Server. Эти лекции помогут вам выполнить завершающие стадии настройки SQL Server.

Лекция 11. Конфигурирование Microsoft SQL Server в сети

Очень трудно представить базу данных вне работы в сети. Для обеспечения данной функциональности требуются некоторые теоретические знания о работе сетевых служб, сетевых библиотек, знания уровней коммуникации SQL Server. Разобраться в этом множестве новых технологий поможет данная лекция. Рассказывается обо всех положительных и отрицательных сторонах использования того или иного интерфейса (DB-LIB, ODBC, OLE DBI и др.) взаимодействия с SQL Server. Описываются принципы работы в SQL Server 2000 Server/Client Network Utility. Понимание концепции уровня программного обеспечения и уровня аппаратуры поможет грамотно сконфигурировать свою сеть.

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

В данной лекции вы узнаете, как конфигурировать разнообразные сетевые компоненты для SQL Server, в том числе на уровне сетевого оборудования, на уровне сетевого протокола и на уровне сетевых библиотек SQL Server. В дополнение к этому материалу вы познакомитесь с компонентами для соединения с базами данных – DB-LIB и ODBC (Open Database Connectivity, открытый интерфейс доступа к базам данных), а также со средствами пулинга соединений ODBC. И в заключение вы изучите, как нужно наблюдать за сетью, чтобы выявлять в ней "узкие места", которые могут возникнуть при работе SQL Server (т.е. как осуществлять мониторинг сети).

Обзор сетевых служб

Для коммуникации между клиентами и серверами SQL Server применяются многие уровни работы программного обеспечения и оборудования. Каждый из этих уровней служит для выполнения присущих ему задач. Давайте вкратце рассмотрим все эти уровни; более подробное их описание будет дано далее в данной лекции. Высшим уровнем является интерфейс прикладного программирования для SQL Server (API, application programming interface). В качестве уровня API применяется что-либо из следующего списка:

API функционируют на вершине уровня сетевых библиотек, в котором содержатся одна или несколько сетевых библиотек (net-libraries, net libs). Сетевые библиотеки преобразуют команды и данные SQL Server в системные запросы, которые взаимодействуют с нижележащим уровнем сетевого протокола. Сетевые библиотеки являются компонентами SQL Server, а вот уровень сетевого протокола является компонентой операционной системы. Вы можете выбрать какую-либо из следующих сетевых библиотек:

Точно так же, как уровень сетевых библиотек может содержать более одной сетевой библиотеки, уровень сетевого протокола может содержать более одного протокола, причем каждая сетевая библиотека взаимодействует с одним или с несколькими протоколами. Уровень сетевого протокола является компонентой операционной системы, "разговаривающей" на языке сетевого протокола. Вызовы и данные SQL Server помещаются внутрь сетевых вызовов, которые могут быть переданы на этом уровне через сеть. За исключением "multiprotocol", каждый сетевой протокол поддерживает одну из сетевых библиотек (имеющую имя, такое же, как имя протокола). При выборе "multiprotocol" производится поддержка средства для дистанционного вызова процедур Windows 2000 и Windows NT (RPC, remote procedure call), при этом происходит поддержка сокетов TPC/IP, протокола NWLink IPX/SPX, и именованных каналов (named pipes) одновременно.

Довольно часто в Windows NT или Windows 2000 запускают сразу по несколько сетевых протоколов. Про эти протоколы мы расскажем более подробно в разделе "Сетевые библиотеки" далее в данной лекции.

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

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

Уровни коммуникации SQL Server


Рис. 11.1.  Уровни коммуникации SQL Server

API для SQL Server

Для коммуникации с SQL Server ваши приложения должны уметь "разговаривать" на его языке. Это значит, что при коммуникации должно применяться одно из инструментальных средств, поставляемых вместе с SQL Server, например, командная строка OSQL или ISQLW (анализатор запросов SQL Server). Эти инструментальные средства могут быть полезными для простых запросов, но они не подходят для обработок, ежедневно выполняемых приложениями. Например, люди, работающие с информацией о запасах товаров на складе, со счетами кредиторов и со счетами к получению, трудятся более эффективно, когда пользуются графическим интерфейсом, а не когда набирают с клавиатуры операторы SQL. На самом деле, большинство из пользователей таких приложений вообще не знают SQL. Как правило, для создания приложений, взаимодействующих с SQL Server, разработчики применяют API (Application Programming Interface), интерфейсы прикладного программирования. Благодаря API можно вызывать разнообразные функции для работы с базами данных.

Вместе с SQL Server поставляется множество разных API, в том числе DB-LIB, ODBC и OLE DB. DB-LIB – это первоначальный, "родной" интерфейс API для SQL Server, он доступен и для Microsoft SQL Server и для продуктов Sybase. ODBC – новее и гибче и может применяться для коммуникации с любым количеством реляционных СУБД. Для работы с SQL Server программистам доступны для применения также OLE DB и еще несколько других API. В данном разделе вы найдете описания различных API.

Соединения DB-LIB

Интерфейс DB-LIB был частью SQL Server начиная с первых версий SQL Server, еще с 1988 года. DB-LIB является первоначальным, исконным API для программирования SQL Server. Хотя DB-LIB всегда был составной частью SQL Server, происходит постепенный отказ от него в пользу ODBC, так что ODBC становится основным API. Языки C и C++, а также Microsoft Visual Basic поддерживают DB-LIB. Вызовы DB-LIB производятся из кода приложений, а затем отправляются через сетевую библиотеку, через уровень сетевого протокола и затем на уровень сетевого оборудования.

Соединения ODBC

ODBC – это стандартный API-интерфейс, разработанный фирмой Microsoft для упрощения соединения компьютеров под управлением Windows с различными реляционными СУБД. Благодаря программированию при помощи API-интерфейса ODBC, вы можете применять одно и то же приложение для коммуникации с любым количеством систем. ODBC обладает многофункциональностью, но может оказаться не самым эффективным API для некоторых реляционных СУБД. Как правило, "родные" API поддерживают большую функциональность и оптимизированы для работы со своими реляционными СУБД.

ODBC применяется для поддержки дополнительных возможностей соединения через Интернет с применением "активных серверных страниц" ASP (Active Server Pages). Также там имеется поддержка ActiveX, MFC (Microsoft Foundation Classes) и XML (Extensible Markup Language). За последние несколько лет поддержка ODBC выросла очень значительно, благодаря чему ODBC стал основным API для продуктов, поддерживающих много реляционных СУБД.

API ODBC имеет одинаковую форму независимо от того, с какой реляционной СУБД вы соединяетесь, но это не относится к драйверам ODBC. Вам придется приобретать по драйверу ODBC для каждой используемой реляционной СУБД. Эти драйверы преобразуют ODBC в "родной" сетевой протокол реляционной СУБД. Для оптимальной работы новых версий реляционных СУБД обычно требуются и новые драйверы ODBC, хотя обратная совместимость, как правило, поддерживается. В DB-LIB обычно применяется специфическая сетевая библиотека, а в ODBC – многопротокольная сетевая библиотека. Эта библиотека упрощает соединение приложений ODBC с сервером и избавляет от необходимости выбирать какой-либо определенный протокол.

Пулинг соединений ODBC

Способность к пулингу (объединению ресурсов) при выполнении соединений, вызываемых изнутри приложений, появилась в ODBC версий 2.х. Как правило, каждое приложение создает по одному соединению между уровнем приложений и базой данных всякий раз, когда в это приложение входит еще один пользователь. Этот процесс может оказаться неэффективным, т.к. установление и поддержание соединений с базой данных приводит к довольно-таки большой нагрузке на компьютер.

Благодаря пулингу соединений все новые потоки из одного приложения могут пользоваться существующими соединениями ODBC и для них не потребуется создавать и поддерживать дополнительные соединения. Эта возможность может быть особенно полезна для Интернет-приложений, которые могут соединяться многократно. Приложения, для которых нужен пулинг соединений, должны регистрировать себя при своем запуске.

Когда приложение запрашивает соединение ODBC, ODBC Connection Manager (Диспетчер соединений ODBC) определяет, должно ли инициироваться новое соединение или же надо воспользоваться уже имеющимся соединением. Это решение принимается без возможности приложения влиять на него. Затем потоки приложения работают как обычно.

Когда поток завершает свою работу с соединением ODBC, приложение делает вызов для освобождения этого соединения. И снова ODBC Connection Manager берет на себя управление над соединением. А если какое-либо соединение простаивает в течение некоторого периода времени, то ODBC Connection Manager может закрыть его.

Дополнительная информация. Более подробную информацию о пулинге соединений ODBC вы найдете в Microsoft ODBC Software Development Kit (SDK).
Другие API

Имеется множество других API, при помощи которых ваши приложения могут соединяться с SQL Server. Это, например, OLE DB, ODS, SQL-DMF (SQL-Distributed Management Framework), SQL-DMO (SQL-Distributed Management Objects) и SQL-NS (SQL-Namespace). Как правило, каждый из этих протоколов поддерживает те или иные специфические функции или сегмент рынка, для которого требуется свой собственный интерфейс программирования.

Дополнительная информация. Для дополнительной информации о специализированных API обратитесь к SQL Server 2000 Books Online.

Сетевые библиотеки

Уровень сетевых библиотек SQL Server преобразует вызовы API в вызовы, специфичные для протоколов, а затем передает их ниже, на уровень сетевого протокола. На клиентских компьютерах администрирование уровня сетевого протокола производится при помощи утилиты Client Network Utility, а на сервере – при помощи утилиты Server Network Utility. Благодаря этим утилитам вы можете добавлять или удалять сетевые библиотеки как на сервере, так и на любом из компьютеров-клиентов. Чтобы взаимодействие с SQL Server было возможным, сетевые библиотеки, имеющиеся на компьютерах-клиентах, должны быть доступны и на сервере. В одной сети могут работать одновременно сразу несколько протоколов. Например, некоторые из компьютеров-клиентов могут взаимодействовать с SQL Server при помощи именованных каналов (named pipes), а другие клиенты в той же сети могут взаимодействовать с SQL Server при помощи TCP/IP.

Утилита SQL Server 2000 Server Network Utility

Как правило, на одном компьютере-сервере конфигурируют несколько протоколов. По умолчанию на сервере инсталлируются сетевые библиотеки для именованных каналов и TCP/IP. Чтобы сконфигурировать на сервере дополнительные сетевые библиотеки, выполните следующие действия:

  1. Запустите Server Network Utility, нажав на экранную кнопку Start, укажите курсором мыши на Programs, затем укажите на Microsoft SQL Server и, наконец, выберите Server Network Utility. Появится диалоговое окно SQL Server Network Utility (рис. 11.2).

     Вкладка General диалогового окна SQL Server Network Utility


    Рис. 11.2.  Вкладка General диалогового окна SQL Server Network Utility

  2. Диалоговое окно SQL Server Network Utility имеет две вкладки: General (Общие) и Network Libraries (Сетевые библиотеки). Вкладка General служит для включения и отключения сетевых протоколов. Включенные протоколы показаны в правом списке в порядке, в котором SQL Server будет пытаться применять их. При помощи вкладки General можно выполнять следующие операции:
    • включать новые протоколы, выбрав сначала один или несколько протоколов из списка отключенных протоколов, а затем нажав на кнопку Enable;
    • отключать протоколы, выбрав один или несколько протоколов из списка включенных протоколов, а затем нажав на кнопку Disable;
    • изменять свойства включенного протокола, выбрав имя протокола, а затем нажав на кнопку Properties;
    • включить шифрование протокола с помощью SSL (Secure Sockets Layer);
    • включить поддержку WinSock Proxy.
    Вкладка Network Libraries служит только для просмотра информации. Благодаря ей можно посмотреть номера версий и даты последних изменений сетевых библиотек (рис. 11.3).

    Вкладка Network Libraries диалогового окна SQL Server Network Utility


    Рис. 11.3.  Вкладка Network Libraries диалогового окна SQL Server Network Utility

Утилита SQL Server 2000 Client Network Utility

На другой стороне сетевого соединения находится компьютер-клиент, который конфигурируется довольно-таки похоже на компьютер-сервер. Чтобы сконфигурировать компьютер-клиент, выполните на нем следующие действия:

  1. Запустите Client Network Utility, нажав на экранную кнопку Start, указав на Programs, затем указав на Microsoft SQL Server, и, наконец, выбрав Client Network Utility. Появится диалоговое окно SQL Server Client Network Utility (рис. 11.4), которое выполняет некоторые функции, такие же, как у диалогового окна SQL Server Network Utility, а также еще и многие другие функции.

    В то время как диалоговое окно SQL Server Network Utility просто показывает список сетевых библиотек и параметров их соединений, при помощи окна SQL Server Client Network Utility можно указывать, какие протоколы на клиентах должны применяться по умолчанию, а также задать алиас сервера (псевдоним). Включенные протоколы показаны на вкладке General в том порядке, в котором они должны применяться. Например, на рис. 11.4 заданы следующие протоколы: сначала именованные каналы (named pipes), а затем TCP/IP. В нашем примере клиент сначала попытается соединиться с сервером через именованные каналы. Если это не получится, то клиент тогда попытается соединиться с сервером при помощи TCP/IP. Если и это не получится, то клиент выдаст сообщение об ошибке соединения.

    Вкладка General диалогового окна SQL Server Client Network Utility


    Рис. 11.4.  Вкладка General диалогового окна SQL Server Client Network Utility

    Алиас сервера (псевдоним) позволяет отказаться от списка включенных протоколов и дает возможность пользоваться только каким-либо определенным протоколом. Если соединение при помощи этого протокола не получится, то попыток применить другие протоколы не последует. Если у вас имеется несколько серверов, не применяющих общий протокол, то нужно поместить наиболее употребительный протокол на верхнюю строчку списка включенных протоколов. Это минимизирует длительность времени, которое потратилось бы на попытки повторных соединений. Включать и отключать протоколы несложно. Для включения протокола просто выберите нужный протокол в списке отключенных протоколов, а затем нажмите на кнопку Enable. Чтобы отключить протокол, выберите нужный протокол в списке включенных протоколов, а затем нажмите на кнопку Disable.

    Вы можете изменять свойства включенных протоколов, выбрав протокол в списке Enabled protocols by order, а затем нажмите на кнопку Properties. Но надо заметить, что значения, применяемые по умолчанию, оптимально подходят почти для всех сетей.

    Из вкладки General можно также включить шифрование протоколов, что защитит данные при передаче через сеть. Эта возможность доступна только для протокола multiprotocol.

  2. Чтобы задать алиас сервера, откройте вкладку Alias. В этой вкладке перечислены все существующие алиасы. Чтобы добавить новый алиас, нажмите на Add. Появится диалоговое окно Add Network Library Configuration (Добавить конфигурацию сетевой библиотеки) (рис. 11.5).
  3. В этом диалоговом окне вы можете добавить алиас, задающий нужный протокол. Этот сетевой протокол должен быть сконфигурирован на компьютере-клиенте и должен быть задан здесь, тогда клиент сможет осуществлять коммуникацию при помощи этого протокола. При попытках соединения с алиасом, клиент SQL Server будет применять сетевую библиотеку и параметры соединения, заданные вами здесь. Если приложение будет пытаться соединиться с сервером не через алиас, то будет применяться протокол, используемый по умолчанию.

     Диалоговое окно Add Network Library Configuration


    Рис. 11.5.  Диалоговое окно Add Network Library Configuration

  4. Во вкладке DB-Library Options диалогового окна SQL Server Client Network Utility (рис. 11.6) показана информация о DB-Lib и имеются флажки Automatic ANSI to OEM conversion и Use international settings. При помощи первого флажка можно включить автоматическое преобразование от кодировки символов ANSI к кодировке OEM при коммуникации с SQL Server. При помощи второго флажка можно задать, чтобы форматы дат, времени и денежных единиц применялись бы те, что заданы для текущего компьютера, а не пользоваться жестко заданными настройками этих форматов.

    Эти флажки, как правило, снимать не нужно. Установленные флажки вызывают некоторую дополнительную нагрузку на компьютер, но зато и повышают функциональность.

     Вкладка DB-Library Options диалогового окна SQL Server Client Network Utility


    Рис. 11.6.  Вкладка DB-Library Options диалогового окна SQL Server Client Network Utility

  5. В диалоговом окне SQL Server Client Network Utility имеется также вкладка Network Libraries (рис. 11.7). Как и одноименная вкладка из утилиты SQL Server Network Utility, эта вкладка просто показывает список доступных сетевых библиотек и информацию о номерах их версий.

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

      Вкладка Network Libraries диалогового окна SQL Server Client Network Utility


    Рис. 11.7.  Вкладка Network Libraries диалогового окна SQL Server Client Network Utility

Сетевые библиотеки и протоколы SQL Server

Как мы уже говорили, SQL Server поддерживает множество сетевых библиотек: именованные каналы (named pipes), TCP/IP, multiprotocol, NWLink IPX/SPX, AppleTalk, Banyan VINES, VIA (Giganet) и VIA (ServerNet II). Каждая сетевая библиотека соответствует своему сетевому протоколу или набору протоколов. В этом разделе мы дадим краткий обзор каждой из сетевых библиотек.

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

Named Pipes – именованные каналы

Протокол named pipes (именованные каналы) был разработан фирмой Microsoft несколько лет тому назад. В named pipes поддерживаются два режима: локальный и удаленный (дистанционный). Протокол local named pipes применяется в случаях, когда и клиент, и сервер находятся на одном и том же компьютере, а remote named pipes применяется, когда клиент и сервер находятся на разных компьютерах. Если соединение установлено через named pipes, сетевые утилиты SQL Server распознают, как оно осуществлено – с помощью локальных именованных каналов (local named pipes) или же с помощью удаленных (дистанционных) именованных каналов (remote named pipes).

Именованные каналы – это клиентский протокол, применяемый по умолчанию, и он является протоколом, применяемым по умолчанию в операционных системах Windows NT 4 Server и Windows 2000. В операционных системах Microsoft Windows 95 и Microsoft Windows 98 именованные каналы применяться не могут. В этих системах на стороне сервера применяются протоколы TCP/IP, multiprotocol и shared memory. Хотя протокол "именованные каналы" работает эффективно, он обычно не используется в больших сетях, потому что он не поддерживает маршрутизацию и шлюзы. Также не рекомендуется его применение на медленных сетях, т.к. по сравнению с другими протоколами, например, TCP/IP, для него требуется передача значительно большего объема информации между сервером и клиентом.

TCP/IP

Протокол TCP/IP является одним из наиболее популярных сетевых протоколов, из-за очень большого количества компьютеров, на которых он работает, из-за того, что его применение принято в качестве стандарта, и из-за его высокой скорости. Он также является сетевым протоколом, применяемым в Интернете. Сетевая библиотека TCP/IP является одной из наиболее высокопроизводительных сетевых библиотек SQL Server. Благодаря высокой скорости и богатым возможностям TCP/IP станет хорошим выбором.

Multiprotocol

Сетевая библиотека multiprotocol – это новинка, появившаяся в SQL Server 7 и сохранившаяся в SQL Server 2000. Эта сетевая библиотека на самом деле является совокупностью нескольких сетевых библиотек. Поэтому она не так эффективна, как одиночные сетевые библиотеки, но зато обеспечивает большую гибкость. Сетевая библиотека multiprotocol поддерживает протоколы TCP/IP, NWLink IPX/SPX и именованные каналы (named pipes). При использовании сетевой библиотеки multiprotocol обычно используется первый из протоколов, имеющихся на клиенте и на сервере. Так как клиент может соединяться с разными серверами при помощи разных протоколов, то multiprotocol является идеальным выбором.

NWLink IPX/SPX

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

AppleTalk

AppleTalk – это сетевой протокол, разработанный фирмой Apple Computer и применяемый в компьютерах Apple. Windows NT и Windows 2000 поддерживают AppleTalk, благодаря чему серверы и клиенты Windows NT и Windows 2000 могут гладко, "без швов", интегрироваться в окружение AppleTalk.

Banyan VINES

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

VIA (Virtual Interface Architecture)

Этот протокол поставляется в двух вариантах – Giganet и ServerNet II. Он хорошо подходит для кластеризованных серверов.

Выбор сетевой библиотеки

Выбор сетевой библиотеки должен осуществляться исходя из того, какие протоколы применяются в вашей сети. Проблемы с соединениями обычно возникают, когда сетевые библиотеки на сервере не синхронизованы с сетевыми библиотекам на клиенте. Если при соединении с сервером возникают трудности, то проверьте, как заданы сетевые библиотеки на обеих сторонах соединения. Также попробуйте соединиться с сервером при помощи другой программы, например, при помощи PING или Проводника Windows (Microsoft Windows Explorer), чтобы понять, относится ли проблема к работе SQL Server или же не работает сама сеть.

Сетевые компоненты и производительность SQL Server

Сеть состоит из двух уровней: уровня программного обеспечения, реализованного сетевыми протоколами, и уровня оборудования (аппаратуры). В рамках нашей книги к уровню оборудования будут отнесены также драйверы сетевого оборудования, необходимые для работы этого оборудования. Данные уровни независимы друг от друга и каждый из них может содержать много компонент. Например, можно запускать одновременно TCP/IP и IPX/SPX "поверх" одной и той же сетевой платы, а можно и применять одновременно много сетевых плат, работающих с одним и тем же протоколом (рис. 11.8).

  Уровни сети


Рис. 11.8.  Уровни сети

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

Уровень программного обеспечения (сетевые протоколы)

Как уже говорилось, к сетевым протоколам относятся именованные каналы (named pipes), TCP/IP, NWLink IPX/SPX, AppleTalk и Banyan VINES. Важно отметить, что все сетевые протоколы функционируют примерно одинаковым образом, по крайней мере, с точки зрения SQL Server. Если сеть не функционирует или работает не так, как вам надо, то эта проблема, скорее всего, связана с уровнем оборудования.

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

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

Уровень оборудования (аппаратный уровень)

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

Пропускная способность сети

Пропускная способность сети – это показатель объема данных, которые могут быть переданы через сеть за заданный промежуток времени. Иногда пропускная способность указывается в названии сетевого оборудования, например, 10BaseT или 100BaseT, что означает, соответственно, пропускную способность 10 и 100 Мбит/с.

Однако, измерение пропускной способности сети может привести к обманчивым результатам. Для большинства сетевых адаптеров скорость, с которой этот сетевой адаптер может передавать данные, уменьшается при уменьшении объема передаваемых данных, потому что каждая передача через сеть вызывает некоторую дополнительную нагрузку на компьютер. Например, нагрузка, вызываемая передачей 64 Kб данных приблизительно равна нагрузке, необходимой для передачи 2 Кб данных. Реляционные СУБД, в том числе и SQL Server, обычно передают небольшие объемы данных. Поэтому объем данных, который может быть обработан вашим сервером, может оказаться меньше, чем пропускная способность сетевого оборудования.

Ethernet

Хотя существует много разных стандартов сетевого оборудования, но, наверное, самым популярным из них является Ethernet. За последние несколько лет скорость Ethernet выросла и продолжает расти. Ethernet был разработан фирмами Xerox, DEC и Intel в 1976 году. В то далекое время применялся коаксиальный кабель (coaxial cable, сокращенно – "coax") и пропускная способность Ethernet составляла около 3 Mбит/с. После появления технологии 10BaseT пропускная способность выросла до 10 Mбит/с, а после появления технологии 100BaseT – до 100 Mбит/с. Вскоре ожидается появление Gigabit Ethernet, и тогда пропускная способность увеличится до 1 Гбит/с. Показатели пропускной способности Ethernet приведены ниже в таблице:

СетьПропускная способность
Coax Ethernet3 Mбит/с
10BaseT10 Mбит/с
100BaseT100 Mбит/с
Gigabit Ethernet1000 Mбит/с

Несмотря на стремительный рост производительности, Ethernet страдает от серьезной проблемы: иногда сетевые адаптеры Ethernet пытаются передавать данные одновременно. Если два или несколько сетевых адаптеров Ethernet осуществляют передачу данных полностью одновременно, то возникнет коллизия передачи данных. Каждый из адаптеров-участников коллизии должен подождать, а затем снова попытаться передать данные. Хотя вызванные этим потери времени и невелики, но эти задержки все же замедляют передачу данных. Чем больше коллизий будет происходить, тем дольше придется ждать повторных попыток передачи данных. При увеличении объема сетевого трафика вероятность коллизий возрастает. Если объем трафика приближается к пропускной способности сети, то вероятность коллизий становится довольно высокой (рис. 11.9). Коллизии снижают производительность. Поэтому важно следить за сетевым трафиком и наблюдать за коллизиями. Например, можно придерживаться практического правила, согласно которому пропускная способность сети не должна расходоваться более чем на 75%. Конечно, ваша сеть будет переживать кратковременные периоды интенсивного использования, когда трафик будет превышать это значение, но речь идет о том, что превышения 75% уровня не должны длиться долго.

 Взаимосвязь между вероятностью коллизий и загруженностью сети


Рис. 11.9.  Взаимосвязь между вероятностью коллизий и загруженностью сети

Token Ring

В сетях Token Ring (Маркерное кольцо) каждый член "кольца" (member of the ring) имеет возможность общаться с другими членами, передавая "маркер" (token). Этот маркер разрешает передавать данные только одному компьютеру в сети – тому, кто имеет его в данный момент. Применяя этот тип архитектуры, вы можете расходовать почти полностью всю пропускную способность сети, без возникновения чрезмерных задержек коммуникации.

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

СетьПропускная способность
IEEE 802.3 Token Ring1, 4 или 16 Mбит/с
IEEE 802.5100 Mбит/с
Gigabit Token Ring1000 Mбит/с

Кроме Ethernet и Token Ring существуют и многие другие стандарты сетевого оборудования, в том числе ATM и "fiber optics".

Мониторинг сети

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

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

Мониторинг производительности

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

Во-первых, может быть так, что не все серверы и клиенты базы данных в вашей физической сети применяют одинаковые протоколы. Например, компьютер, исполняющий TCP/IP на Ethernet, сможет обнаруживать (на уровне операционной системы) только трафик, который по своей природе является трафиком TCP/IP. Пакеты IPX/SPX будут отбрасываться уже на уровне драйверов. Как правило, для программного обеспечения мониторинга сетей потребуются нестандартные драйверы устройств и компоненты сетевого уровня.

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

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

Диагностика причин проблем

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

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

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

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

Способы решения проблем с сетями

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

Один из способов снижения загруженности сети заключается в увеличении пропускной способности сети. Переход от 10BaseT к 100BaseT повышает пропускную способность десятикратно. Такое решение – простое и быстрое, но может оказаться дорогостоящим. Давайте рассмотрим альтернативные способы.

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

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

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

Заключение

В этой лекции вы изучили основы работы и конфигурирования SQL Server в сетях. Вы познакомились с применяемыми в SQL Server уровнями сетей, от API до сетевых библиотек, сетевых протоколов и, наконец, до сетевого оборудования. Каждый из этих уровней является независимым, но все они взаимно подходят друг к другу в различных конфигурациях. У вас имеется очень много свободы при выборе различных API, сетевых библиотек, протоколов и даже аппаратных решений. И не забывайте периодически проверять сетевой трафик, что поможет избежать проблем с производительностью еще до того, как они возникнут. (О типичных проблемах с производительностью см.лекцию 36, а о том, как следует конфигурировать SQL Server со службой Microsoft Cluster Services, чтобы получить высоконадежную систему, см.лекцию 12.)

Лекция 12. Microsoft SQL Server и Microsoft Cluster Services

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

В последние годы системы Microsoft SQL Server 2000 превратились из систем для настольных компьютеров сначала в системы для рабочих групп, а теперь и в системы для внутренних офисов. Эти системы теперь стали крупнее и их важность для бизнеса повысилась, поэтому повысились и требования к их стабильности, к возможностям дистанционного администрирования и их отказоустойчивости. Чтобы добиться удовлетворения этих требований, фирма Microsoft затратила очень много времени и усилий на поиск ошибок в программах и на улучшение поддержки пользователей. Microsoft усовершенствовала инструментальные средства для администрирования и улучшила возможности дистанционного администрирования, были созданы такие технологии, как "Службы Кластеризации", MSCS (Microsoft Cluster Services). Кластером называется группа компьютеров, которые обеспечивают друг для друга взаимное резервное копирование на случай отказов. В этой лекции вы узнаете, как работает служба MSCS и как их конфигурировать, а также научитесь планировать действия в случае возможных отказов и узнаете, как выполнять восстановление после отказов. Служба MSCS сама по себе не может обеспечить отказоустойчивость вашей системы; чтобы ваша система могла быть восстановлена после отказов, эта технология должна применяться в сочетании с тщательным планированием.

Примечание. MSCS входит в состав Microsoft Windows 2000 Advanced Server, Windows 2000 Datacenter Server и Microsoft Windows NT 4 Enterprise Edition.

Разновидности отказов

Главной обязанностью администратора базы данных является поддержание базы данных в рабочем состоянии в течение требуемых периодов времени, которые обычно указываются в соглашении об уровне обслуживания (service level agreement). В этом соглашении об уровне обслуживания обычно указывается объем периодов работоспособности системы, а также показатели производительности и длительность времени восстановления в случаях отказов в работе. Применение MSCS может увеличить длительность периодов работоспособности системы и сократить длительность времени восстановления. Несмотря на то, что аппаратура сервера, Windows 2000, Windows NT и SQL Server обычно стабильны и надежны, отказы все равно иногда случаются. На самом деле, в сложной компьютерной системе могут случаться разнообразные типы отказов, в том числе следующие:

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

Обзор MSCS

MSCS является встроенной службой Windows 2000 Advanced Server, Windows 2000 Datacenter Server и Windows NT Enterprise Edition. MSCS применяется для формирования кластера серверов, который, как уже говорилось, является группой независимых серверов, работающих совместно как единая система. Кластер служит для обеспечения готовности (availability, этот термин может переводиться и как "доступность") клиентов к обслуживанию приложений в ситуации возникновения отказа или при запланированных отключениях. Если один из серверов кластера по какой-либо причине является недоступным, то ресурсы и приложения перемещаются на другой узел кластера.

Когда речь идет о кластеризованных системах, мы обычно применяем термин с высокой готовностью (high availability), а не отказоустойчивый (fault tolerant). Термин отказоустойчивый традиционно применяется по отношению к специализированным системам, обладающим исключительно высоким уровнем резервирования, устойчивостью к внешним воздействиям и способностью к восстановлению. Такие системы обычно применяют весьма специализированное программное обеспечение, обеспечивающее почти мгновенное восстановление при любых отдельных отказах оборудования или программного обеспечения. Отказоустойчивые системы стоят гораздо дороже, чем системы без отказоустойчивости. Кластеризованные системы, обеспечивающие высокую готовность, не столь дорогостоящи, как отказоустойчивые системы. Кластеризованные системы обычно конструируются из оборудования для стандартных серверов и программного обеспечения для работы кластера (это программное обеспечение имеет небольшой объем и входит в состав операционной системы). При увеличении потребности в обеспечении готовности можно достаточно просто включать дополнительные компьютеры в состав кластера. Хотя кластеризованные системы и не гарантируют непрерывной работы, но они обеспечивают весьма значительное повышение готовности для большинства критически важных приложений.

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

Основные понятия

MSCS сокращает длительность простоев, осуществляя переходы по отказу между отдельными компьютерами, применяя при этом взаимосвязь между серверами и дисковую систему с общим доступом (рис. 12.2). В качестве взаимосвязи между серверами может применяться любое высокоскоростное соединение, например, сеть Ethernet или другое сетевое оборудование. Эта взаимосвязь функционирует как канал коммуникации между серверами, благодаря которому возможна двусторонняя передача информации о состоянии кластера и о конфигурации. Благодаря разделяемой дисковой системе возможен равноправный доступ всех серверов кластера к базе данных и к другим файлам с данными. Такая разделяемая дисковая система может быть реализована при помощи SCSI, SCSI поверх Fibre Channel, а также при помощи какого-либо нестандартного оборудования. Разделяемые диски могут быть как одиночными дисками, так и RAID-системой. (Про RAID-системы см.лекцию 5.)

Кластер Windows 2000


Рис. 12.2.  Кластер Windows 2000

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

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

Виртуальный сервер существует как элемент сети и ему сопоставлен IP-адрес, применяемый в протоколе TCP/IP. Этот IP-адрес может передаваться от одного компьютера к другому, благодаря чему пользователи продолжают "видеть" виртуальный сервер независимо от того, на каком именно оборудовании он работает. На самом деле, этот IP-адрес переходит от одного компьютера к другому, что обеспечивает одинаковое представление виртуального сервера для наружного наблюдателя. Приложение, направленное по некоторому адресу, все равно получит доступ, соответствующий этому адресу, даже если конкретный сервер, соответствующий этому адресу, и откажет (однако этот адрес теперь будет соответствовать другому серверу). Виртуальный сервер прячет от пользователя операции перехода по отказу, поэтому пользователь может продолжать свою работу, не зная о событиях, происходящих "за кулисами".

Компоненты кластера

Для создания кластера нужны некоторые компоненты: программное обеспечение для управления кластером, взаимосвязь между серверами и разделяемая дисковая система. Чтобы образовать кластер, эти компоненты должны быть сконфигурированы согласованно с приложениями, которые будут предназначены для работы на нем. В данном разделе вы познакомитесь с этими компонентами и узнаете, как они совместно работают, образуя кластер. Затем, в разделе "Конфигурирование SQL Server для работы на кластере" (далее в данной лекции) вы научитесь конфигурировать кластеры SQL Server.

Программное обеспечение MSCS для управления кластером

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

Взаимосвязь между серверами

Взаимосвязь между серверами – это просто соединение между узлами кластера. Так как для узлов кластера необходима постоянная коммуникация между ними (через Службу времени, Менеджер узлов и т.д.), то поддержка этой связи очень важна. Взаимосвязь между серверами должна быть надежным каналом коммуникации.

Во многих случаях в качестве взаимосвязи между серверами может применяться сеть Ethernet, на которой исполняется протокол TCP/IP или NetBIOS. Этого вполне достаточно, но вы можете захотеть применять нестандартную, высокоскоростную взаимосвязь между серверами, которая будет гораздо быстрее, чем Ethernet. Эти взаимосвязи можно приобрести у многих поставщиков оборудования, некоторые из них предоставляют как решения для разделяемых дисков, так и решения для коммуникации. Полный список одобренных устройств для взаимосвязи между серверами вы найдете в списке совместимого оборудования на веб-сайте фирмы Microsoft по адресу http://www.microsoft.com/hcl/

Разделяемая дисковая система

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

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

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

Вопрос о кэшах контроллеров, благодаря которым возможно кэширование записей в память, также надо решать при кластеризации, в случаях, когда кэш расположен на самом контроллере (рис. 12.3). В этом случае каждый узел имеет свой собственный кэш, и мы говорим, что он находится перед разделением дисков ("in front of" the disk sharing), потому что два кэша пользуются одними и теми же дисковыми накопителями. Если каждый контроллер имеет кэш и кэш размещается на отказавшем компьютере, то данные из кэша могут быть потеряны. Из-за этого, когда вы в конфигурации кластера применяете внутренние кэши контроллера, они должны быть настроены как применяемые только для чтения (set as read-only). (При некоторых обстоятельствах такая настройка может уменьшить производительность некоторых систем.)

Кэши контроллера перед разделением дисков


Рис. 12.3.  Кэши контроллера перед разделением дисков

В других решениях этой проблемы с разделяемыми дисками предусматривается расслоение (чередование) RAID и кэширование внутри самой дисковой подсистемы. В этой конфигурации кэш разделяется (используется совместно) узлами и в данном случае мы говорим, что кэш находится позади разделения дисков (рис. 12.4). Теперь механизмы расслоения и кэш выглядят одинаково для всех контроллеров системы, и безопасными являются как чтение из кэша, так и запись в кэш.

Кэш контроллера позади разделения дисков


Рис. 12.4.  Кэш контроллера позади разделения дисков

Последние дисковые подсистемы SCSI и Fibre Channel допускают размещение RAID- контроллеров в корпусах дисковых систем, а не в корпусах компьютеров. Такие системы обеспечивают хорошую производительность и отказоустойчивость. Фактически, многие RAID-системы этого типа предлагают контроллеры и кэши, полностью защищенные при помощи избыточности. Многие из последних RAID-систем применяют архитектуру этого типа. Давайте более подробно рассмотрим некоторые дисковые подсистемы.

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

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

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

 Внутренний RAID-контроллер


Рис. 12.5.  Внутренний RAID-контроллер

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

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

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

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

Внешняя RAID-система. Во внешних RAID-системах аппаратура RAID находится за пределами компьютеров (см. рис. 12.6). Каждый сервер содержит адаптер главной шины (HBA, host bus adapter), задачей которого является передача в RAID-систему максимально большего количества запросов ввода-вывода с наивысшей возможной скоростью. А место фактического размещения данных определяется RAID-системой.

 Внешняя подсистема RAID


Рис. 12.6.  Внешняя подсистема RAID

Внешние RAID-системы иногда называют "RAID в шкафу" или "RAID в ящике", потому что расслоение RAID производится внутри корпуса с дисками. Такие внешние подсистемы RAID обладают многими достоинствами. Они являются не только идеальным решением для MSCS, но и вообще, универсальным лучшим решением. Ниже перечислены достоинства систем "RAID в шкафу":

 Подключения кабелей внутренних RAID-систем  в сравнении  с подключением кабелей внешних RAID-систем


Рис. 12.7.  Подключения кабелей внутренних RAID-систем в сравнении с подключением кабелей внешних RAID-систем

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

Категории приложений, работающих с кластерами

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

  MSCS и категории приложений


Рис. 12.8.  MSCS и категории приложений

Режимы MSCS

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

Активно-пассивные кластеры

В активно-пассивных кластерах для работы приложений SQL Server применяется первичный узел (primary node), а сервер – вторичный узел (secondary node) является запасным, резервным сервером (рис. 12.9).

Активно-пассивный кластер


Рис. 12.9.  Активно-пассивный кластер

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

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

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

Активно-активные кластеры

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

 Активно-активный кластер


Рис. 12.10.  Активно-активный кластер

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

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

Примеры кластеризованных систем

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

Пример 1 – система с высокой готовностью со статическим балансированием нагрузки

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

Кластер с высокой готовностью, со статическим балансированием нагрузки


Рис. 12.11.  Кластер с высокой готовностью, со статическим балансированием нагрузки

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

Пример 2 – система с "горячим резервированием" с максимальной готовностью

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

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

Система с "горячим резервированием" с максимальной готовностью


Рис. 12.12.  Система с "горячим резервированием" с максимальной готовностью

Пример 3 – кластеризация части сервера

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

Кластеризация части сервера


Рис. 12.13.  Кластеризация части сервера

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

Пример 4 – только виртуальные серверы, без переходов по отказам

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

Только виртуальные серверы, без переходов по отказам


Рис. 12.14.  Только виртуальные серверы, без переходов по отказам

Конфигурирование SQL Server для работы на кластере

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

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

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

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

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

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

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

Задание времени восстановления

При настройке SQL Server вы могли задать какое-либо ненулевое значение для параметра конфигурации recovery interval (интервал восстановления) (нулевое значение задано по умолчанию). Изменение этой настройки увеличит время между контрольными точками и повысит производительность, однако снизит и время восстановления (после перехода по отказам система должна восстанавливаться). В кластеризованной системе применяемое по умолчанию нулевое значение, означающее автоматическое конфигурирование, не должно быть изменено. (Главной причиной применения MSCS является наличие компьютера, на который может быть перенесена работа другого компьютера, и это перевешивает вопросы, относящиеся к производительности.) При такой настройке контрольные точки будут происходить примерно раз в минуту, и максимальное время восстановления составит тоже около одной минуты.

Дополнительная информация. Для дополнительной информации об этом обратитесь к предметному указателю Books Online и посмотрите там "recovery interval option".
Примечание. При выполнении контрольных точек все данные, измененные в кэше SQL Server, записываются на диск. Все измененные данные, которые не были записаны на диск в момент отказа системы, SQL Server сотрет при запуске во время повтора подтвержденных транзакций и отката неподтвержденных транзакций.
Конфигурирование SQL Server для активно-пассивных кластеров

Для создания активно-пассивной конфигурации кластера вам, возможно, понадобится изменить одну из настроек SQL Server. Если вторичный сервер идентичен первичному серверу, то ничего менять не надо. Если вторичный сервер имеет меньше ресурсов, чем первичный сервер, то нужно задать значение 0 для параметра конфигурации SQL Server min server memory. Благодаря такой настройке SQL Server распределит память исходя из системных ресурсов, имеющихся в наличии.

Дополнительная информация. Для дополнительной информации об этом обратитесь к предметному указателю Books Online и посмотрите там "min server memory option".
Конфигурирование SQL Server для активно-активных кластеров

Для создания активно-пассивной конфигурации кластера вы обязательно должны задать значение 0 для параметра конфигурации SQL Server min server memory. Благодаря такой настройке SQL Server распределит память исходя и системных ресурсов, имеющихся в наличии. Если этот параметр конфигурации задан как Manual, то SQL Server может распределить слишком много памяти после перехода по отказу. Так как в операционной системе Windows 2000 применяется виртуальная память, то может случиться так, что памяти будет распределено больше имеющегося объема физической памяти. На самом деле, такая проблема возникает довольно часто и становится причиной подкачки страниц памяти. Например, если у каждого из компьютеров распределено 75% от его системной памяти и произойдет переход по отказу, то для суммарного обслуживания SQL Server потребуется 150% от доступной памяти, из-за чего работа системы практически остановится.

Инсталляция SQL Server для работы на кластере

Процесс инсталляции SQL Server для работы на кластере аналогичен процессу инсталляции SQL Server, описанному в лекции 7. Прежде чем запустить процесс инсталляции для работы на кластере, вы должны решить, где именно будет инсталлироваться SQL Server. Вы должны будете установить файлы SQL Server на разделяемом дисковом накопителе, находящемся под управлением первичного сервера. Вы должны будете задать и путь инсталляции SQL Server, и путь инсталляции главной базы данных (master database) так, чтобы они указывали на этот разделяемый дисковый накопитель. Вы также должны задать сетевой протокол, под которым будет работать кластер. Ниже кратко перечислены действия по инсталляции SQL Server для работы на кластере.

  1. Вставьте свой компакт-диск SQL Server в привод для компакт-дисков вашего сервера. Если ваша операционная система настроена на автоматический запуск компакт-дисков, то появится главное диалоговое окно начальной установки Microsoft SQL Server 2000 (рис. 12.15). Если автоматический запуск компакт-дисков не включен, то нужно вручную запустить программу Autorun.exe, находящуюся в корневой директории компакт-диска.

    Диалоговое окно начальной установки SQL Server


    Рис. 12.15.  Диалоговое окно начальной установки SQL Server

  2. Если у вас не установлены необходимые дополнительные пакеты операционной системы (service packs) или требуемая версия Microsoft Internet Explorer, или если вы просто хотите посмотреть перечень программных компонент, необходимых для инсталляции, то нажмите на SQL Server 2000 Prerequisites, и тогда откроется диалоговое окно SQL Server 2000 Prerequisites (Предварительные условия для SQL Server 2000).

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

    Примечание. Инсталляция MSCS должна быть выполнена до запуска инсталляции SQL Server.
  3. Нажмите на SQL Server 2000 Components. Появится стартовое окно мастера SQL Server 2000 Installation Wizard. Если у вас работают какие-либо другие программы Windows, то их нужно закрыть. Для продолжения процесса инсталляции нажмите на Next.
  4. В экране Computer Name нажмите на Virtual Server и введите с клавиатуры имя виртуального сервера (рис. 12.16). Для продолжения нажмите на Next.

    Экран Computer Name


    Рис. 12.16.  Экран Computer Name

  5. Появится экран User Information (Информация о пользователе). Проверьте правильность своего имени и названия вашей фирмы. Для продолжения нажмите на Next.
  6. Появится экран Software License Agreement (Лицензионное соглашение об использовании программного обеспечения). Нажмите на Yes, чтобы согласиться с условиями лицензионного соглашения и продолжить процесс инсталляции.
  7. В экране Setup введите с клавиатуры 25-символьный ключ компакт-диска, напечатанный на желтой наклейке в инструкции, прилагаемой к компакт-диску или на футляре компакт-диска. Для продолжения нажмите на Next.
  8. Затем появится экран Failover Clustering (Кластеризация с переходом по отказу) (рис. 12.17). Введите IP-адрес для виртуального сервера, а затем нажмите на Add. MSCS предоставит адрес подсети. Для продолжения нажмите на Next.
  9. В экране Cluster Management (Управление кластером) посмотрите на определение кластера, которое предлагает SQL Server. По умолчанию в качестве предпочтительного узла задается локальный компьютер. Все остальные допустимые узлы будут показаны в окне Additional Node (Дополнительный узел). Проверьте настройки и на Next для продолжения процесса инсталляции.
  10. Когда появится экран Remote Information (Информация для дистанционного доступа), введите с клавиатуры пользовательский идентификатор администратора и пароль, которые будут действительны для всех выбранных узлов этого кластера.

     Экран Failover Clustering


    Рис. 12.17.  Экран Failover Clustering

  1. В экране Instance Name (Имя экземпляра) согласитесь со стандартным именем или задайте именованный экземпляр SQL Server. Если вы хотите задать именованный экземпляр, то снимите флажок Default (По умолчанию) и введите с клавиатуры желаемое имя экземпляра. Для продолжения нажмите на Next.
    Примечание. Экземпляры не могут получать такие имена, как DEFAULT, MSSQLSERVER и любые имена, совпадающие с зарезервированными ключевыми словами SQL Server.
  2. В экране Setup Type задайте нужный вам тип инсталляции. По умолчанию программа установки SQL Server инсталлирует SQL Server в первый доступный диск – разделяемый ресурс. Если вы хотите инсталлировать SQL Server в другое место, то нажмите на Browse под заголовком Data Files и задайте путь к другому диску – разделяемому ресурсу. Для продолжения нажмите на Next.
  3. Затем появится экран Authentication Mode (Режим аутентификации) (рис. 12.18). Настройки, заданные в этом окне, задают уровень безопасности вашей инсталляции SQL Server. Вы можете выбрать использование Windows Authentication Mode (Режим аутентификации Windows) либо Mixed Mode (Смешанный режим). При выборе Windows Authentication Mode все права пользователей в отношении базы данных наследуются из настроек Windows User Security. При выборе Mixed Mode вы можете задавать и администрировать настройки безопасности пользователей для базы данных независимо от настроек для Windows. Если вы выберете Mixed Mode, то вы должны задать пароль для учетной записи sa (системного администратора SQL Server). Вы можете оставить этот пароль пустым, но это серьезно ухудшит защищенность вашей инсталляции SQL Server.
  4. В экране Start Copying Files (Запустить копирование файлов) нажмите на Next.
  5. Появится экран Licensing Mode (Лицензионный режим). Имеется два способа для лицензирования ваших клиентов SQL Server – на сервер (Per Server) или на посадочные места (Per Seat). При использовании лицензии на сервер требуется назначать каждую Лицензию клиентского доступа (Client Access License) конкретному серверу и такая лицензия допускает только одно соединение с этим сервером. Максимальное число компьютеров-клиентов, которые могут соединяться с сервером в любой момент времени равно количеству лицензий Client Access License, выданный вами этому серверу.

      Экран Authentication Mode


    Рис. 12.18.  Экран Authentication Mode

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

    Если вы не можете решить, какой режим лицензирования выбрать, нажмите на Per Server. Лицензионное соглашение разрешает возможность однократной, необратимой замены лицензии "на сервер" на лицензию "на посадочные места".

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

  6. Когда появится экран Setup Complete (Установка завершена), выберите опцию для перезапуска вашего компьютера и нажмите на Finish.

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

Применение трехзвенных приложений

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

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

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

За рамками MSCS

Мы с вами изучили основы работы MSCS и работы SQL Server в этой архитектуре. Также мы узнали, как SQL Server может выжить на некоторых типах катастрофических отказов оборудования и программного обеспечения, как можно выполнить резервное копирование SQL Server и быстрое исполнение транзакций. Для достижения такой степени отказоустойчивости одной лишь службы MSCS будет недостаточно, понадобятся и другие меры. Две таких важных меры – это выполнение регулярных и эффективных резервных копирований и разработка плана восстановления после чрезвычайных ситуаций, про это будет подробно рассказано в лекциях 32 и 33. Резервное копирование не может быть заменено службами кластеризации и RAID-системами. Во многих случаях, если система разрушится, а резервной копии у вас не будет, никакие эти технологии не помогут. Ниже перечислены некоторые из таких ситуаций.

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

Заключение

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

Лекция 13. Введение в Transact-SQL и SQL Query Аnalyzer

Язык SQL является стандартом для всех СУБД. SQL Server 2000 использует модифицированную версию языка – Transact-SQL (T-SQL), дополненную специфическими функциями администрирования и управления проектами. Для лекции характерно большое количество примеров, позволяющих увидеть, как в действительности работает тот или иной сценарий. Приводится описание новых типов данных (которые не рассматривались в предыдущих лекциях). Особенности работы в ISQL, OSQL, Query Analyzer представлены в лучшем виде. Рекомендуется изучать материал совместно со справочной информацией (Books Online).

В этой лекции вы познакомитесь с основными понятиями языков SQL (Structured Query Language, язык структурированных запросов) и T-SQL (Transact-SQL); также будет рассказано о различиях между этими двумя языками. Будут рассмотрены составные части SQL – язык DDL (data definition language, язык определения данных) и DML (data manipulation language, язык манипулирования данными), для каждого из этих языков будут даны примеры. Также мы кратко рассмотрим новые свойства T-SQL, имеющиеся в Microsoft SQL Server 2000. Вы узнаете, как применять различные утилиты SQL Server, в том числе утилиту командной строки T-SQL и SQL Server Query Analyzer, что позволит вам создавать объекты базы данных и управлять этими объектами. Вы также научитесь создавать сценарии, содержащие операторы T-SQL.

Что такое SQL

SQL – это язык программирования и запросов к базам данных, он применяется для осуществления доступа к данным, для запросов к реляционным СУБД, для управления базами данных и их обновления. Стандарт SQL утвержден как Американским Национальным Институтом Стандартов (ANSI, American National Standards Institute), так и Международной организацией по стандартизации (ISO, International Organization for Standardization). ANSI – это организация промышленных и деловых групп, разрабатывающая стандарты для торговли и коммуникации в Соединенных Штатах. ANSI также является членом ISO и IEC (Международной электротехнической комиссии, International Electrotechnical Commission). ANSI публикует стандарты США, которые соответствуют международным стандартам. В 1992 году ISO и IEC опубликовали международный стандарт на SQL, который принято называть SQL-92. ANSI опубликовал в Соединенных Штатах соответствующий стандарт, ANSI SQL-92, который иногда называют ANSI SQL. Хотя разные реляционные СУБД применяют несколько различающиеся версии SQL, но большинство из них соответствуют стандарту SQL-92, определенному ANSI.

Язык SQL содержит операторы, относящиеся к одному из двух основных языков программирования в составе SQL: DDL и DML, о которых мы расскажем вам в последующих разделах.

DDL

Язык DDL (data definition language, язык определения данных) применяется для определения объектов баз данных (таких как базы данных, таблиц и представления) и для управления этими объектами. (Про представления (views) будет рассказано в лекции 18.) Операторы языка DDL обычно включают в себя команды CREATE, ALTER и DROP для каждого из объектов, с которым производится работа. Например, для первоначального создания таблицы, для изменения ее свойств (скажем, для создания или для удаления колонок) и для уничтожения таблицы соответственно применяются операторы CREATE TABLE, ALTER TABLE и DROP TABLE ; мы расскажем об этих операторах в нескольких следующих разделах.

Оператор CREATE TABLE

Давайте в качестве примера применим DDL для создания в базе данных MyDB таблицы с именем Customer_Data (Сведения_о_заказчиках). Эту таблицу Customer_Data обработки мы будем использовать и в других примерах, приведенных в этой лекции. Как уже говорилось, для создания таблицы применяется оператор CREATE TABLE. Наша таблица-пример будет задана как имеющая четыре колонки, при помощи следующих операторов:

Use MyDB 
CREATE TABLE Customer_Data 
(customer_id  		smallint, 
first_name    		char(20), 
last_name     		char(20), 
phone         		char(10)) 
GO

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

Оператор ALTER TABLE

Оператор ALTER TABLE применяется для изменения определения или атрибутов таблицы. В нашем примере оператор ALTER TABLE применяется для добавления в существующую таблицу Customer_Data колонки middle_initial:

ALTER TABLE Customer_Data 
ADD middle_initial char(1) 
GO

Теперь определение таблицы содержит не четыре колонки, как было первоначально, а пять колонок. (Более подробно о применении оператора ALTER TABLE см. лекцию 15.)

Оператор DROP TABLE

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

DROP TABLE Customer_Data 
GO

(Подробно об операторе DROP TABLE см.лекцию 15.)

DML

Язык DML (data manipulation language, язык манипулирования данными) применяется для манипулирования данными, содержащимися в объектах базы данных, для чего применяются такие операторы, как SELECT, INSERT, UPDATE и DELETE. При помощи этих операторов можно соответственно выбирать строки с данными, вставлять новые строки, изменять имеющиеся строки и удалять ненужные строки. Ниже даны простые примеры применения этих операторов. (Более сложные примеры см. в лекциях 14 и 20.)

Оператор INSERT

Оператор INSERT применяется для вставки строки данных в таблицу или в представление. Например, если вы хотите добавить нового заказчика (customer) в нашу таблицу-пример Customer_Data, то оператор INSERT может выглядеть так:

INSERT INTO Customer_Data 
(customer_id, first_name, last_name, phone) 
VALUES (777, 'Frankie', 'Stein', '4895873900')

Обратите внимание, что во второй строке первого оператора SQL помещен список имен колонок. Этот список определяет, в какие именно колонки будут помещены данные (данные вводятся в той последовательности, как они указаны). Так, первое значение данных будет помещено в первую колонку из списка, в customer_id; второе значение будет помещено во вторую колонку из списка, и т.д. Мы перечислили значения данных в том же порядке, в каком были заданы колонки при создании таблицы, поэтому можно вообще не указывать имена колонок и применить вот такой оператор INSERT:

INSERT INTO Customer_Data 
VALUES (777, 'Frankie', 'Stein', '4895873900')
Внимание. При использовании такой формы оператора INSERT, в случае, если вводимые значения перечислены не в том порядке, как были заданы колонки при создании таблицы, значения могут попасть не в те колонки, куда надо (если вводимые данные совместимы с типами данных колонок). Если же данные будут несовместимы с типами данных колонок, то вы получите ошибку.
Оператор SELECT

Оператор SELECT применяется для извлечения данных из таблицы или из таблиц. Извлекаемые данные определяются перечисленными колонками и предложением WHERE. Предположим, например, что нам надо извлечь значения из колонок customer_id и first_name нашей таблицы Customer_Data, и эти данные нужны лишь для строк со значением Frankie в поле first_name. Тогда нужно применить такой оператор SELECT:

SELECT customer_id, first_name FROM Customer_Data 
WHERE first_name = 'Frankie' 
Если критерию из оператора SELECT будет соответствовать лишь одна строка, 
то результат может быть таким:
customer_id      		first_name 
--------------		-------------
777                    				Frankie
Оператор UPDATE

Оператор UPDATE применяется для обновления (т.е. изменения) значений в одной или нескольких строках таблицы. Например, допустим, заказчик Frankie Stein позвонил и попросил изменить его имя в записях базы данных на Franklin. Эту задачу выполнит такой оператор UPDATE:

UPDATE Customer_Data 
SET first_name = 'Franklin'
WHERE last_name = 'Stein' and customer_id=777

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

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

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

DELETE FROM Customer_Data

или

DELETE Customer_Data

Ключевое слово FROM перед именем таблицы в операторе DELETE не обязательно, эти два оператора ничем не отличаются. Для удаления из таблицы Customer_Data строк, у которых значение колонки customer_id меньше, чем 100, применяется такой оператор:

DELETE FROM Customer_Data 
WHERE customer_id < 100

Теперь, когда вы вкратце познакомились с операторами языков DDL и DML, входящих в состав SQL, давайте рассмотрим язык T-SQL.

Что такое T-SQL

T-SQL – это усовершенствование стандартного языка программирования SQL. Первоначальный, основной SQL применяется для взаимодействия между приложениями и SQL Server. В T-SQL имеются все возможности языков DDL и DML стандартного SQL, а кроме этого имеются также расширенные функции, системные хранимые процедуры и конструкции для программирования (такие, как IF and WHILE ), обеспечивающие гораздо большую гибкость программирования. По мере выхода новых версий SQL Server возможности T-SQL растут.

Обзор новых возможностей T-SQL

В T-SQL для Microsoft SQL Server 7 появились многочисленные добавления и улучшения, в том числе новые хранимые процедуры, системные таблицы, функции, типы данных, операторы и новые возможности для старых операторов. Все было сохранено и в SQL Server 2000, и мы сейчас дадим краткий обзор этих новых возможностей (если вы не знаете о них по опыту своей работы с SQL Server 7). Однако их слишком много, чтобы мы смогли дать подробные описания, поэтому мы рассмотрим лишь несколько примеров для каждой их разновидности.

Дополнительная информация. Чтобы получить полный список новых возможностей T-SQL, обратитесь к SQL Server Books Online, к теме "New Features in Transact-SQL" (Новые возможности в Transact-SQL). Чтобы открыть эту тему, нажмите на Transact-SQL Reference во вкладке Contents, а затем нажмите на New Features in Transact-SQL.
Системные хранимые процедуры

В SQL Server имеются системные хранимые процедуры, с помощью которых можно выполнять администрирование и другие задачи, требующие обновления системных таблиц и извлечения информации из системных таблиц. Системные хранимые процедуры инсталлируются вместе с SQL Server, их имена начинаются с sp_ или с xp_. Эти процедуры хранятся в базе данных master (главной системной базе данных) (а также базе msdb. – Прим. ред.), их владелец – системный администратор, но многие из них могут запускаться из любой пользовательской базы данных, извлекая при этом информацию из системных таблиц этой базы данных. Когда вы исполняете системную хранимую процедуру, она работает с системными таблицами текущей базы данных.

Дополнительная информация. Дополнительную информацию о системных хранимых процедурах вы найдете в Books Online, в теме "Extended Stored Procedures" (Расширенные хранимые процедуры).

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

Таблица 13.1. Процедуры, появившиеся в SQL Server 7, имеющиеся и в SQL Server 2000
Системная хранимая процедураОписание
sp_cycle_errorlogЗакрывает текущий файл-журнал ошибок и переименовывает его в errorlog.1 (если необходимо, переименовывает старый errorlog.1 в errorlog.2 и так далее) и открывает новый файл-журнал ошибок >
sp_helpfileВозвращает физические имена и атрибуты файлов, сопоставленных с текущей базой данных
sp_helpfilegroupВозвращает имена и атрибуты групп файлов, сопоставленных с текущей базой данных
sp_helproleВозвращает информацию о ролях в текущей базе данных
sp_help_alertВозвращает информацию о предупреждениях, заданных для сервера
sp_start_jobПриказывает, чтобы SQL Server Agent начал выполнять задание

Некоторые из этих хранимых процедур не только немедленно выдают информацию, но могут и сохранять для дальнейшего применения важную информацию о пользовательских базах данных. Например, процедуры, возвращающие информацию о базе данных пользователя, могут оказаться полезными при исполнении в сценариях T-SQL, когда выдаваемая ими информация будет сохраняться в файле. Вы можете сохранять информацию, выдаваемую после запуска хранимых процедур sp_helpfile, sp_helpfilegroup и sp_helpdb, примененных к нужной базе данных (процедура sp_helpdb, хоть и старая, но по-прежнему пользуется популярностью). Это пригодится в случае, если придется воссоздавать базу данных и понадобится информация о первоначально созданных и сконфигурированных файлах, группах файлов и опциях базы данных. Список остальных новых системных процедур, появившихся в SQL Server 7, вы найдете в Books Online, в теме "New Features in Transact-SQL" (Новые возможности в Transact-SQL).

Системные таблицы

Системные таблицы служат для хранения информации о конфигурации SQL Server и хранения заданных для баз данных определений объектов, пользователей и полномочий доступа. Каждая пользовательская база данных имеет свои собственные системные таблицы, в которых хранится информация для этой базы данных. Системные таблицы, хранящие информацию о конфигурации на уровне сервера, хранятся только в базе данных master (главной системной базе данных). Для доступа к системным таблицам нужно применять системные хранимые процедуры, а не осуществлять доступ непосредственно. Список новых системных таблиц, появившихся первоначально в SQL Server 7, вы найдете в Books Online, в теме "New Features in Transact-SQL". Ниже перечисленные некоторые интересные системные таблицы.

Функции

При помощи встроенных функций SQL Server возможно быстрое и удобное решение некоторых задач. Некоторые новые функции появились в SQL Server 7, и они остались доступными и в SQL Server 2000. Зная об имеющихся функциях, вам будет проще программировать приложения SQL Server. Полный список новых функций вы найдете в Books Online, в теме "New Transact-SQL Functions" (Новые функции Transact-SQL). Ниже приведены описания лишь нескольких из новых функций, которые могут вам пригодиться:

Типы данных

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

А ниже перечислены три новых типа данных, появившихся в SQL Server 2000:

Операторы

В SQL Server 7 появилось много новых операторов T-SQL, а имеющиеся операторы приобрели новые возможности, и все это вошло и в SQL Server 2000. Эти операторы соответствуют некоторым из новых возможностей, появившихся в SQL Server 7. Например, оператор ALTER DATABASE получил следующие новые опции для работы с файлами и группами файлов: MODIFY FILE, ADD FILEGROUP, MODIFY FILEGROUP, REMOVE FILE и REMOVE FILEGROUP. А для групп файлов новый оператор DBCC CHECKFILEGROUP проверяет размещение и структурную целостность всех таблиц в заданной группе файлов.

В SQL Server 7 и SQL Server 2000 появилось еще два оператора DBCC – DBCC SHRINKFILE и DBCC SHRINKDATABASE. Первый из них сжимает заданный файл данных, уменьшая его размер, а второй оператор сжимает все файлы в заданной базе данных, освобождая неиспользуемое место на диске.

У SQL Server 7 и SQL Server 2000 была усовершенствована архитектура для резервного копирования и восстановления. Новый оператор BACKUP позволяет выполнять полные и частичные резервные копирования базы данных и журнала, а новый оператор RESTORE позволяет восстанавливать базы данных и журналы после этого резервного копирования. Эти операторы применяются вместо операторов DUMP и LOAD из старых версий SQL Server. Полный список новых операторов и опций, появившихся в SQL Server 7 и SQL Server 2000, вы найдете в Books Online, в теме "New Features in Transact-SQL". Более подробно о резервном копировании и о восстановлении после резервного копирования будет рассказано в лекциях 32 и 33.

Как применять T-SQL

T-SQL можно применять не только в программах ваших приложений (эта тема выходит за рамки нашей книги), вы можете также исполнять интерактивные операторы T-SQL, пользуясь какой-нибудь из трех утилит – ISQL, OSQL или Query Analyzer; кроме того, вы можете создавать и исполнять сценарии SQL.

Утилита ISQL

Утилита ISQL взаимодействует с SQL Server через API-интерфейс DB-LIB; с ее помощью можно исполнять интерактивные операторы T-SQL, хранимые процедуры и файлы сценариев. API-интерфейс DB-LIB остался на уровне функциональности SQL Server 6.5, поэтому приложение ISQL не поддерживает некоторые возможности SQL Server 2000. Например, ISQL не может извлекать данные из типа данных ntext (в кодировке Unicode).

Утилита OSQL

Утилита OSQL появилась в SQL Server 7 и осталась в SQL Server 2000 в качестве замены для ISQL. Утилиты ISQL и OSQL очень во многом сходны, но OSQL для коммуникации с SQL Server применяет API-интерфейс ODBC (Open Database Connectivity), а не DB-LIB, и OSQL поддерживает все возможности SQL Server 2000. Во всем остальном OSQL и ISQL функционируют одинаково. SQL Server 2000 поддерживает обе этих утилиты, однако, чтобы не столкнуться с проблемами, о которых мы упомянули, следует пользоваться OSQL, а не ISQL.Чтобы исполнять OSQL из окна с приглашением командной строки (из окна MS-DOS), нужно просто запустить программу OSQL.exe с соответствующими параметрами, например, так:

osql –U имя_пользователя –P пароль –S имя_сервера

Когда OSQL установит соединение с SQL Server, появится такое приглашение с номером:

1>

После этого приглашения можно вводить операторы T-SQL, например, такой оператор:

1>    		sp_helpdb master 
2>    		go

В результате его выполнения будет выдана информация о базе данных master. Ключевое слово go не является оператором T-SQL, это – команда, распознаваемая ISQL, OSQL и Query Analyzer и обозначающая завершение пакета операторов T-SQL. Вывод от исполнения таких интерактивных запросов будет выдаваться в окне с приглашением командной строки.

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

1>    		sp_helpbd 
2>    		reset 
1>    		sp_helpdb  
2>    		go

Для завершения работы с утилитой OSQL введите команду QUIT или EXIT. Команду или запрос, исполняющуюся в текущий момент времени, можно завершить, нажав Ctrl+C (выход из утилиты OSQL при этом не произойдет).

Утилита OSQL имеет и другие параметры кроме -U, -P и -S. Полное описание всех параметров и дополнительную информацию об утилите OSQL вы найдете в Books Online, в теме "osql Utility".

Query Analyzer

Query Analyzer применяется для исполнения операторов или сценариев T-SQL из графического пользовательского интерфейса и для получения результатов в форматированном виде. Query Analyzer обладает также некоторыми средствами для анализа индексов запросов. Некоторые люди предпочитают применять Query Analyzer, а не запускать операторы в окне "приглашения MS-DOS". Для работы с Query Analyzer выполните следующие действия:

  1. Запустите Query Analyzer каким-либо из следующих трех способов.
    • введите isqlw в командной строке;
    • откройте Enterprise Manager и выберите SQL Query Analyzer в меню Tools;
    • в меню кнопки Start наведите указатель мыши сначала на Programs, затем на Microsoft SQL Server, а затем выберите Query Analyzer.
    Если вы не соединены с сервером, то появится диалоговое окно Connect to SQL Server (Соединиться с SQL Server) (рис. 13.1).

    Диалоговое окно Connect to SQL Server


    Рис. 13.1.  Диалоговое окно Connect to SQL Server

  2. В ниспадающем списке SQL Server выберите сервер, с которым вы хотите соединяться. Точка, стоящая в этом поле, означает соединение с локальным сервером. Введите информацию для входа в систему и, если вы желаете, чтобы в случаях, когда SQL Server не запущен, он запускался бы автоматически, установите флажок Start SQL Server if it is stopped. Затем нажмите на экранную кнопку OK. Появится стартовое окно Query Analyzer (рис. 13.2).

    SQL Query Analyzer


    увеличить изображение

    Рис. 13.2.  SQL Query Analyzer

  3. В окне запросов введите с клавиатуры любой оператор T-SQL или вызов хранимой процедуры (рис. 13.3). Заметьте, что окно запросов на приведенном рисунке развернуто и занимает все окно Query Analyzer.

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


    увеличить изображение

    Рис. 13.3.  Вызов хранимой процедуры в окне запросов

  4. Чтобы выполнить введенный оператор, нажмите на кнопку Execute Query (Исполнить запрос), находящуюся на панели инструментов и выглядящую как зеленый треугольник, указывающий острием вправо, либо нажмите Ctrl+E*. Результаты исполнения запроса появятся в панели результатов (рис. 13.4).

    Query Analyzer показывает результаты исполнения запроса


    увеличить изображение

    Рис. 13.4.  Query Analyzer показывает результаты исполнения запроса

  5. Если нужно, чтобы Query Analyzer загрузил и исполнил созданный вами ранее T-SQL-сценарий, то нажмите на кнопку Load SQL Script в панели инструментов, выглядящую как желтая папка, или выберите команду Open в меню File, а затем найдите и укажите нужный файл со сценарием. Весь сценарий появится в верхней панели окна запросов. Для запуска сценария нажмите на кнопку Execute Query.
    Примечание. Query Analyzer имеет еще много других возможностей, в том числе некоторые новые возможности для SQL Server 2000. (Подробнее об этом см. лекцию 35.)
Сценарии T-SQL

Создав свои собственные сценарии, вы получите замечательную возможность для многократного запуска операторов и хранимых процедур T-SQL. Сценарий (script) – это просто файл, в котором содержатся операторы T-SQL, которые нужно запускать. В скрипте может быть как один оператор, так и последовательность операторов. Мы сразу дадим одну рекомендацию: создавая сценарии T-SQL, давайте именам их файлов расширение .sql, тогда вам будет легче находить эти файлы.

Ниже дан пример кода простого сценария:

use MyDB 
go 
sp_helpdb MyDB 
go 
sp_helpfilegroup 
go 
sp_spaceused Customer_Data 
go 
sp_spaceused Product_Info 
go

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

Предположим, что этот сценарий был сохранен в файле MyDB_info.sql. Тогда, чтобы запустить его из командной строки, вы можете воспользоваться опциями  -i и -o утилиты OSQL. Опция  -i вызывает запуск сценария, находящегося во входном файле ( input ), имя которого указано после опции. Опция  -o задает выходной файл ( output ), имя которого указано после опции, в него будут помещены результаты. Пусть выходной файл у нас будет иметь имя MyDB_info.out. Давайте также применим опцию -e, тогда операторы T-SQL из входного файла будут отображаться (echo) также и в выходном файле, что облегчит понимание выходного файла. Например, чтобы исполнить наш сценарий, будучи системным администратором, надо дать следующую команду в командной строке:

osql –U sa  –P  –i MyDB_info.sql  –o MyDB_info.out  –e

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

Есть и другой способ запуска сценариев, при котором вам не понадобится каждый раз набирать с клавиатуры команду osql -u ....Надо создать .cmd-файл и поместить в него эту команду. Так, можно назвать этот файл MyDB_info.cmd и поместить в него вышеприведенную команду osql -u .... Теперь вы можете не только запустить команду MYDB_INFO из командной строки, но и дважды щелкнуть мышью на имени файла MyDB_info.cmd в Проводнике Microsoft Windows.

Сценарии можно запускать и в Query Analyzer. Чтобы запустить наш сценарий MyDB_info.sql, откройте этот файл, выбрав в Query Analyzer команду Open в меню File, после этого в верхней панели появится код сценария. Нажмите на кнопку Execute Query или нажмите клавиши Ctrl+E, и операторы сценария исполнятся. Вывод от операторов сценария будет выдаваться в соответствии с порядком исполнения операторов (рис. 13.5). Обратите внимание, что на рис. 13.5 две верхние таблицы результатов выданы хранимой процедурой sp_helpdb.

Результаты исполнения сценария Query Analyzer


увеличить изображение

Рис. 13.5.  Результаты исполнения сценария Query Analyzer

Заключение

В этой лекции вы познакомились с основами языков SQL и T-SQL, увидели примеры простых операторов DDL и DML. Теперь вы умеете запускать операторы T-SQL, причем разными способами – при помощи ISQL, OSQL, Query Analyzer и из сценариев T-SQL. (Об использовании T-SQL см. в лекциях 14, 15 и 25.)

Лекция 14. Извлечение данных при помощи Transact-SQL

Язык запросов DML предназначен для манипулирования данными. Наиболее распространенным оператором является SELECT. Узнать обо всех тонкостях использования оператора SELECT позволит данный материал. Огромное количество примеров, примечаний к ним, объяснения принципов работы – все это и многое другое вы найдете в лекции. Вводится множество новых операторов, ключевых слов и, самое главное, описываются принципы работы с данными новшествами. Агрегатные функции, описываемые в лекции, помогают решать повседневные задачи, связанные с поиском среднего арифметического значения, количеством элементов, минимального и максимального элементов, суммы значений и многого другого.

Прочитав эту лекцию, вы узнаете, как извлекать данные при помощи оператора SELECT языка Transact-SQL (T-SQL). Здесь также описаны многие необязательные предложения, условия поиска и функции, которые могут применяться в операторах SELECT. Благодаря этим элементам вы сможете составлять запросы, возвращающие лишь те данные, которые вам нужны.

Оператор SELECT

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

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

Давайте начнем изучать различные опции оператора SELECT и рассмотрим иллюстрирующие их примеры. Учебные базы данных pubs и Northwind создались автоматически при инсталляции Microsoft SQL Server 2000. Чтобы ознакомиться с этими базами данных, посмотрите их таблицы, применив SQL Server Enterprise Manager.

Синтаксически оператор SELECT состоит из нескольких предложений (clauses), большинство из которых не являются обязательными. Оператор SELECT должен обязательно иметь предложения SELECT и FROM. Эти два предложения задают соответственно колонку (или колонки) и таблицу (или таблицы), из которых будут извлекаться данные. Например, простой оператор SELECT, извлекающий имена и фамилии авторов из таблицы authors базы данных pubs, может выглядеть вот так:

SELECT   		au_fname, au_lname 
FROM     		authors

Если вы пользуетесь утилитой OSQL с командной строкой (она была описана в лекции 13), то не забывайте давать команду GO, исполняющую оператор. При использовании OSQL полный код T-SQL для вышеприведенного оператора SELECT будет таким:

USE      			pubs 
SELECT   		au_fname, au_lname 
FROM     		authors 
GO
Примечание. Ключевые слова не зависят от регистра букв (т.е. от того, какими буквами они набраны – строчными или ПРОПИСНЫМИ), поэтому для улучшения читаемости кода рекомендуется выделять их регистром букв в соответствии с какой-нибудь системой. В нашей книге, например, ключевые слова выделены ПРОПИСНЫМИ буквами.

Если вы запускаете оператор SELECT в интерактивном режиме (например, при помощи OSQL или SQL Query Analyzer), то результаты отображаются в колонках, и для удобства восприятия эти колонки даны вместе с заголовками. (О T-SQL, OSQL и Query Analyzer см.лекцию 13.)

Предложение SELECT

Предложение SELECT содержит обязательный список выборки (select list) и, возможно, несколько необязательных аргументов. Список выборки – это заданный в предложении SELECT список выражений или колонок, определяющий, какие данные должны быть извлечены. В этом разделе мы расскажем как о необязательных аргументах предложения SELECT, так и о списке выборки.

Аргументы

Для управления выдаваемыми строками в предложении SELECT могут применяться следующие аргументы:

Ниже даны три примера запуска оператора SELECT с разными аргументами. В первом из них при запуске используется аргумент DISTINCT, во втором – аргумент TOP 50 PERCENT, а в третьем – аргумент TOP 5:

SELECT   		DISTINCT au_fname, au_lname 
FROM     		authors 
GO
SELECT   		TOP 50 PERCENT au_fname, au_lname 
FROM      		authors 
GO
SELECT   		TOP 5 au_fname, au_lname 
FROM      		authors 
GO

Первый запрос вернет 23 строки, каждая из которых будет уникальной. Второй запрос вернет 12 строк (приблизительно 50%, с округлением до большего числа), а третий запрос вернет 5 строк.

Список выборки

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

au_fname, au_lname

Метасимвол "*". В списках выборки можно применять звездочку (символ "*"), являющуюся метасимволом (подстановочным символом, "джокером"), обозначающим все колонки из всех таблиц и представлений, указанных в предложении FROM запроса. Например, чтобы вернуть все колонки всех строк таблицы sales из базы данных pubs, воспользуйтесь таким запросом:

SELECT   		* 
FROM     		sales 
GO

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

Выражения IDENTITYCOL и ROWGUIDCOL. Чтобы извлекать значения из идентифицирующей колонки таблицы (identity column, см. лекцию 10), вы можете применять в списках выборки просто выражение IDENTITYCOL. Ниже дан пример запроса для базы данных Northwind, у которой таблица Employees (Сотрудники) имеет идентифицирующую колонку:

USE      			Northwind 
GO 
SELECT   		IDENTITYCOL 
FROM     		Employees 
GO

Набор результатов этого запроса будет выглядеть примерно так:

EmployeeID  
-------------
3 
4 
8 
. 
. 
. 
9 
(всего 9 строк)

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

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

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

Когда в разных таблицах имеются колонки с одинаковыми именами, вы можете захотеть, чтобы в выводе в заголовках выдавались не только имена колонок, но и имена таблиц; это улучшит понимание выводимой информации. Рассмотрим теперь примеры с колонкой lname таблицы employee базы данных pubs. Можно дать такой запрос:

USE      			pubs 
GO 
SELECT   		lname 
FROM     		employee 
GO

Этот запрос выдаст такие результаты:

lname 
----------
Cruz 
Roulet 
Devon 
. 
. 
. 
O’Rourke 
Ashworth 
Latimer
(всего 43 строки)

Если вы хотите, чтобы в наборе результатов вместо имеющегося заголовка "lname" выводился бы заголовок "Фамилия сотрудника", подчеркнув тем самым, что фамилии взяты из таблицы сотрудников, то надо применить ключевое слово AS, вот так:

SELECT   		lname AS "Фамилия сотрудника"
FROM     		employee 
GO

Эта команда выдаст такой вывод:

Фамилия сотрудника 
-------------------------
Cruz 
Roulet 
Devon 
. 
. 
. 
O’Rourke 
Ashworth 
Latimer
(всего 43 строки)

Алиасы колонок можно применять в сочетании с другими типами выражений в списке выборки, а также их можно применять в предложениях ORDER BY для ссылок на колонки. Предположим, что в списке выборки имеется вызов функции. Выводу этой функции можно назначить алиас (т.е. имя), воспользовавшись ключевым словом AS после вызова функции. Если при вызове функции не пользоваться алиасом, то колонка ее вывода не будет вообще иметь никакого заголовка. Ниже дан пример оператора, назначающего заголовок "Maximum Job ID" выводу функции MAX:

SELECT   		MAX(job_id) AS "Maximum Job ID" 
FROM     		employee 
GO

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

Алиас колонки, заданный в предложении SELECT, может применяться в качестве аргумента предложения ORDER BY, он позволяет предложению ORDER BY ссылаться на колонку из предложения SELECT. Это полезно, когда в списке выборки содержится функция, вывод которой должен быть отсортирован. Ниже приведен пример команды, выдающей количество проданных книг в каждом из магазинов, причем вывод отсортирован по этому количеству. В предложении ORDER BY применяется алиас Quantity_of_Books, заданный в списке выборки:

SELECT   		SUM(qty) AS Quantity_of_Books, stor_id  
FROM     		sales 
GROUP BY 	stor_id 
ORDER BY 	Quantity_of_Books 
GO

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

Если бы в этом запросе мы не задали бы алиас для колонки SUM(qty), то мы могли бы поместить в предложение ORDER BY не алиас, а SUM(qty), как показано в приведенном ниже примере. Вывод был бы таким же, за исключением того, что колонка сумм проданных книг выводилась бы без заголовка:

SELECT   		SUM(qty), stor_id FROM sales 
GROUP BY 	stor_id 
ORDER BY 	SUM(qty)
GO

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

Предложение FROM

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

Производные таблицы

Производная таблица (derived table) – набор результатов оператора SELECT, вложенный в предложение FROM. Набор результатов вложенного оператора SELECT используется как таблица, из которой извлекаются данные внешний оператор SELECT. Ниже дан пример запроса, использующего производную таблицу, чтобы найти имена всех магазинов (stores), предоставляющих хотя бы один вид скидок (discounts):

USE      			pubs 
GO 
SELECT   		s.stor_name 
FROM     		stores AS s, (SELECT stor_id, COUNT(DISTINCT discounttype) 
                         						AS d_count 
                         						FROM   	      discounts 
                         						GROUP BY   stor_id) AS d 
WHERE    		s.stor_id = d.stor_id AND 
        			d.d_count >= 1  
GO

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

Заметьте, что в этом запросе применяются сокращения для имен таблиц (s для таблицы stores (магазины) и d для таблицы discounts (скидки)). Эти сокращения называются алиасы таблиц (см. раздел "Алиасы таблиц" далее).

Примечание. Производные таблицы нельзя применять в предложениях WHERE. В качестве условия поиска в предложениях WHERE используется оператор SELECT. Об этом будет рассказано более подробно в разделе "Предложения WHERE и условия поиска" далее в этой лекции.
Соединения таблиц

Соединение таблиц (joined table) – это набор результатов от операции соединения (join operation), выполненной над двумя или несколькими таблицами. Над таблицами можно выполнять различные типы соединений: внутренние соединения, полные внешние соединения, левые внешние соединения, правые внешние соединения, перекрестные соединения. Давайте рассмотрим их более подробно.

Внутренние соединения. Внутреннее соединение (inner join) является типом соединений, принятым по умолчанию. Внутреннее соединение задает набор результатов, в который будут включены лишь те строки таблиц, которые соответствуют условию ON, а все несоответствующие строки будут отброшены. Чтобы задать соединение, применяйте ключевое слово JOIN. Для задания условия поиска, на котором основывается соединение, применяется ключевое слово ON. Ниже приведен пример запроса, в котором соединяются таблицы stores и discounts; этот запрос показывает, в каких магазинах предоставляются скидки и типы этих скидок. (Это соединение – внутреннее, потому что по умолчанию применяется внутреннее соединение; поэтому будут возвращены лишь строки, соответствующие условию поиска ON.)

SELECT   		s.stor_id, d.discounttype 
FROM     		stores s JOIN discounts d 
ON       			s.stor_id = d.stor_id 
GO

Набор результатов будет выглядеть примерно так:

stor_id  	discounttype 
------------------------------
8042     	Customer Discount

Как видите, скидки предоставляет лишь один магазин, причем скидки лишь одного типа. Выданная строка является единственной строкой с совпадающими значениями stor_id из таблицы stores и stor_id из таблицы discounts. Возвращаются это значение stor_id и соответствующее ему значение discounttype.

Полные внешние соединения. Полное внешнее соединение (full outer join) задает набор результатов, состоящий как из строк, соответствующих условию ON, так и из строк, не соответствующих условию ON. Для строк, не соответствующих условию ON, значением колонки, несоответствующей условию, станет NULL. В нашем примере NULL будет означать, что либо магазин не предоставляет никаких скидок (если некоторое значение stor_id имеется в таблице stores, но отсутствует в таблице discounts), либо этот тип скидки не предоставляется никаким магазином. Запрос в следующем примере полностью совпадает с предыдущим, за исключением того, что в нем стоят ключевые слова FULL OUTER JOIN:

SELECT   		s.stor_id, d.discounttype 
FROM     		stores s FULL OUTER JOIN discounts d 
ON       			s.stor_id = d.stor_id 
GO

Набор результатов будет выглядеть примерно так:

stor_id  		discounttype 
---------		-----------------
NULL     		Initial Customer 
NULL     		Volume Discount 
6380     		NULL 
7066     		NULL 
7067     		NULL 
7131     		NULL 
7896     		NULL 
8042     		Customer Discount

Условию поиска будет соответствовать лишь одна строка в наборе результатов (последняя). Остальные строки имеют NULL в одной из колонок.

Левые внешние соединения. Левое внешнее соединение (left outer join) возвращает строки, в которых произошло соответствие условию поиска, плюс все строки из таблицы, заданной слева от ключевого слова JOIN. Ниже дан наш старый пример запроса, но теперь в нем используются ключевые слова LEFT OUTER JOIN:

SELECT   		s.stor_id, d.discounttype 
FROM      		stores s LEFT OUTER JOIN discounts d 
ON           			s.stor_id = d.stor_id 
GO

Набор результатов будет выглядеть примерно так:

stor_id  		discounttype 
-------		---------------------
6380     		NULL 
7066     		NULL 
7067     		NULL 
7131     		NULL 
7896     		NULL 
8042     		Customer Discount

В набор результатов попадут и те строки из таблицы stores, для которых не нашлось строк из таблицы discounts с совпадающим значением stor_id (в колонке discounttype набора результатов в этих строках будет стоять значение NULL ). В набор результатов попадет также одна строка, для которой произошло соответствие условию ON.

Правые внешние соединения. Правое внешнее соединение (right outer join) противоположно левому внешнему соединению: в него войдут строки, соответствующие условию поиска, плюс все строки из таблицы, заданной справа от ключевого слова JOIN. Ниже дан наш старый пример запроса, но теперь в нем используются ключевые слова RIGHT OUTER JOIN:

SELECT   		s.stor_id, d.discounttype 
FROM     		stores s RIGHT OUTER JOIN discounts d 
ON       			s.stor_id = d.stor_id

Набор результатов будет выглядеть примерно так:

stor_id  		discounttype 
-------		--------------------
NULL     		Initial Customer 
NULL     		Volume Discount 
8042     		Customer Discount

В набор результатов попали и те строки из таблицы discounts, которые не имеют значений stor_id, совпадающих со значениями, имеющимися в таблице stores (значением stor_id для этих строк в наборе результатов станет NULL ). В набор результатов попадет также строка, соответствующая условию ON.

Перекрестные соединения. Перекрестное соединение (cross join) – это произведение двух таблиц, в котором не задано предложение WHERE. Когда предложение WHERE задано, перекрестное соединение работает как внутреннее соединение. А без предложения WHERE будет возвращаться такой результат: каждая строка из первой таблицы сопоставляется с каждой строкой из второй таблицы, поэтому размер набора результатов будет равен числу строк первой таблицы, умноженному на число строк второй таблицы.

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

SELECT   		* 
FROM     		stores 
GO

SELECT   		* 
FROM     		sales 
GO 
 
SELECT   		* 
FROM     		stores CROSS JOIN sales 
GO
Примечание. Если вы поместите в предложение FROM две таблицы, то это даст такой же результат, как если бы задать CROSS JOIN, как в следующем примере:
SELECT   		* 
FROM     		stores, sales 
GO

Чтобы не потонуть в массе ненужной информации (если информации выдано больше, чем нужно), мы можем сузить запрос, добавив в него предложение WHERE, вот так:

SELECT   		* 
FROM     		sales CROSS JOIN stores  
WHERE    		sales.stor_id = stores.stor_id 
GO

Этот оператор возвращает только те строки, которые соответствуют условию поиска в предложении WHERE, что уменьшит набор результатов до 21 строки. Из-за предложения WHERE перекрестное соединение работает как внутреннее соединение (т.е. возвращаться будут лишь строки, соответствующие условию поиска). Запрос, показанный в последнем примере, возвращает строки из таблицы sales, соединенные со строками из таблицы stores, имеющими совпадающие значения stor_id. Строки, у которых нет совпадений, не возвращаются.

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

SELECT    		sales.*, stores.city 
FROM      		sales CROSS JOIN stores 
WHERE     		sales.stor_id = stores.stor_id 
GO

Этот запрос возвращает все колонки из таблицы sales (продажи), к которым добавлена колонка city ("город) из таблицы stores, для строк с одинаковыми значениями stor_id. Фактически, в набор результатов будет включены названия городов для магазинов, в которых проводились продажи, присоединенные к строкам из таблицы sales, имеющим значения stor_id, совпадающие со значениями stor_id из таблицы stores.

Ниже приведен еще один пример запроса, не имеющий символа "*" (из таблицы sales извлекается только колонка stor_id):

SELECT    		sales.stor_id, stores.city 
FROM      		sales CROSS JOIN stores 
WHERE     		sales.stor_id = stores.stor_id 
GO
Алиасы таблиц

Вы уже видели несколько примеров, в которых применялись алиасы имен таблиц (слово алиас означает замена имени, псевдоним). Ключевое слово AS является необязательным, т.е. "FROM имя_таблицы AS алиас" будет работать точно так же, как и "FROM имя_таблицы алиас". Давайте вернемся к запросу, приведенному в качестве примера в разделе "Правые внешние соединения", в котором применяются алиасы:

SELECT   		s.stor_id, d.discounttype 
FROM     		stores s RIGHT OUTER JOIN discounts d 
ON       			s.stor_id = d.stor_id 
GO

Каждая из двух таблиц из этого примера имеет колонку stor_id. Чтобы различать, какую именно из этих двух колонок вы применяете в запросе, нужно перед именем колонки задать имя таблицы или алиас (отделив точкой). В нашем примере для таблицы stores применяется алиас s, а для таблицы discounts применяется алиас d. Задавая колонку мы должны ставить перед ее именем "s." или " d.", указывая тем самым, в какой таблице содержится эта колонка. Тот же самый запрос с применением ключевых слов AS будет выглядеть так:

SELECT   		s.stor_id, d.discounttype 
FROM     		stores AS s RIGHT OUTER JOIN discounts AS d 
ON       			s.stor_id = d.stor_id 
GO
Предложение INTO

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

SELECT <список_выборки> INTO<новая таблица>

вы можете извлекать данные из таблицы или из нескольких таблиц и помещать строки результатов в новые таблицы. Новые таблицы создаются автоматически при исполнении оператора SELECT ... INTO и определены в соответствии с колонками из списка выборки. Каждая колонка в новой таблице будет иметь тип данных, такой же, как и у исходных колонок, и будет иметь имя, заданное в списке выборки. Пользователь должен иметь полномочие на создание таблиц ( CREATE TABLE ) в той базе данных, где будет создана новая таблица (в целевой базе данных). (О том, как задавать полномочия см. лекцию 34.)

Оператор SELECT ... INTO можно применять для помещения строк как во временные, так и в постоянные таблицы. Для локальных временных таблиц (видимых только для текущего соединения или пользователя) вы должны поместить перед именем таблицы символ "#". Для глобальных временных таблиц (видимых для всех пользователей) вы должны поместить перед именем таблицы два символа "#" (т.е. "##"). Временная таблица автоматически уничтожается после того, как все пользователи, которые с ней работают, отсоединятся от SQL Server. Чтобы помещать данные в постоянную таблицу, не нужно применять префикс целевых таблиц, но для целевой базы данных должна быть включена настройка Select Into/Bulk Copy. Чтобы включить эту настройку для базы данных pubs, вы можете выполнить такой оператор OSQL:

sp_dboption pubs, "select into/bulkcopy", true 
GO

Для включения этой настройки можно также применить SQL Server Enterprise Manager, вот так:

  1. Нажмите правой кнопкой мыши на имя базы данных pubs в любой панели Enterprise Manager и выберите Properties в контекстном меню. Появится окно свойств базы данных pubs (pubs Properties) (рис. 14.1). (Наверное, вы его помните, оно было в лекции 9, когда мы создавали базу данных и задавали настройки для роста файла.)

    Вкладка General окна свойств базы данных


    Рис. 14.1.  Вкладка General окна свойств базы данных

  2. Нажмите на вкладку Options (рис. 14.2) и выберите в ниспадающем списке Model опцию Bulk-Logged. Остальные настройки не трогайте. Нажмите OK.

     Вкладка Options окна свойств базы данных


    Рис. 14.2.  Вкладка Options окна свойств базы данных

  3. Ниже приведен пример запроса, в котором оператор SELECT ... INTO применяется для создания новой постоянной таблицы emp_info (информация о сотрудниках), в которой содержатся имена, фамилии и описания должностных обязанностей сотрудников (эта информация извлекается из базы данных pubs):
SELECT   		employee.fname, employee.lname, jobs.job_desc  
INTO     		emp_info 
FROM     		employee, jobs 
WHERE    		employee.job_id = jobs.job_id 
GO

Таблица emp_info будет иметь три колонки – fname, lname и job_desc, типы данных которых будут такими же, как и у колонок, заданных в исходных таблицах (employee и jobs). Если вы хотите, чтобы новая таблица была локальной временной таблицей, то перед ее именем надо поместить символ "#" (вот так: #emp_info), а чтобы новая таблица была глобальной временной таблицей, поместите перед ее именем "##" (вот так: ##emp_info).

Предложение WHERE и условия поиска

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

Примечание. Условия поиска применяются не только в предложениях WHERE операторов SELECT, но и в операторах UPDATE и DELETE. (Об операторах UPDATE и DELETE см. лекцию 20.)

Давайте сначала договоримся об используемой терминологии. Условие поиска (search condition) может содержать произвольное количество предикатов (predicates), соединенных логическими операциями (logical operators) AND, OR и NOT (И, ИЛИ и НЕ). Предикаты –это выражения, возвращающие значения TRUE, FALSE или UNKNOWN (ИСТИНА, ЛОЖЬ или НЕИЗВЕСТНО). Выражение (expression) может быть именем колонки, константой, скалярной функцией (т.е. функцией, возвращающей одно значение), переменной, скалярным подзапросом (т.е. запросом, возвращающим одну колонку), либо комбинацией этих элементов, соединенных операциями. В этом разделе нашей книги термин "выражение" применяется также и к предикатам.

Операции сравнения

В выражениях можно использовать операции сравнения (comparison operators), перечисленные в табл. 14.1.

Таблица 14.1. Операции сравнения
ОперацияПроверяемое условие
=Проверяется равенство двух выражений
<>Проверяется неравенство двух выражений
!=Проверяется неравенство двух выражений (то же самое, что и <> )
>Проверяется, что первое выражение больше второго
>=Проверяется, что первое выражение больше второго или равно ему
!>Проверяется, что первое выражение не больше второго
<Проверяется, что первое выражение меньше второго
<=Проверяется, что первое выражение меньше второго или равно ему
!<Проверяется, что первое выражение не меньше второго

В простом предложении WHERE может производиться сравнение двух выражений при помощи операции сравнения на равенство (=). Ниже приведен пример оператора SELECT, проверяющего значения в колонке lname для всех строк (а эти значения имеют тип данных char) и возвращающего TRUE, если это значение равно "Latimer" (в набор результатов будут включены строки, для которых возвращается значение TRUE ):

SELECT   		* 
FROM     		employee 
WHERE    		lname = "Latimer"
GO

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

Примечание. По умолчанию, SQL Server допускает применение как символов одинарных кавычек ('...'), так и символов двойных кавычек ("..."), т.е. можно применять и 'Latimer', и "Latimer". В нашей книге в примерах во избежание путаницы применяются только символы двойных кавычек. Если вы хотите использовать в качестве имени объекта зарезервированное ключевое слово и использовать в качестве литералов (текстовых констант) только одиночные кавычки, то примените опцию SET QUOTED_IDENTIFIER. Установите для этой опции значение TRUE (по умолчанию установлено значение FALSE ).

В следующем запросе применяется операция неравенства ( <> ), на этот раз по отношению к колонке job_id, имеющей тип данных integer:

SELECT   		job_desc 
FROM     		jobs 
WHERE    		job_id <> 1 
GO

Этот запрос выдает текст с описанием должностных обязанностей из строк таблицы jobs, имеющих значения job_id, не равные 1. Будет выдано 13 строк. Если в строке содержится значение NULL, то оно считается не равным ни 1, ни какому- либо другому значению, поэтому будут выведены и строки null-значениями.

Логические операции

Логические операции (logical operators) AND и OR проверяют два выражения и, в зависимости от их значений, возвращают булево значение TRUE, FALSE или UNKNOWN. Операция NOT выдает булево значение, противоположное значению выражения, следующего за ним. Значения, возвращаемые операциями AND, OR и NOT, показаны в таблицах на рис. 14.3. Таблицами для операций AND и OR надо пользоваться так: найдите результат первого выражения в левой колонке, найдите результат второго выражения в верхней строке, а затем посмотрите результат логической операции в ячейке на пересечении соответствующих строки и колонки. Таблица для операции NOT – совсем понятная. Результат может получить значение UNKNOWN, если среди операндов имеется значение NULL.

Значения, возвращаемые операциями AND, OR и NOT при различных значениях операндов


Рис. 14.3.  Значения, возвращаемые операциями AND, OR и NOT при различных значениях операндов

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

SELECT   		job_desc, min_lvl, max_lvl 
FROM     		jobs  
WHERE    		min_lvl 	>= 100 AND 
         			max_lvl 	<= 225 
GO

Как видно из таблицы (рис. 14.3), операция AND возвращает значение TRUE, когда оба условия возвращают TRUE. Этот запрос вернет четыре строки.

В следующем запросе операция OR применяется для поиска издателей из Вашингтона (федеральный округ Колумбия) и из Массачусетса. Будут возвращены строки, для которых значение TRUE явилось результатом хотя бы одного из условий.

SELECT   		p.pub_name, p.state, t.title 
FROM     		publishers p, titles t 
WHERE    		p.state = "DC" OR 
         			p.state = "MA" AND 
         			t.pub_id = p.pub_id 
GO

Этот запрос вернет 23 строки.

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

SELECT   		t.title, r.royalty 
FROM     		titles t, roysched r 
WHERE    		t.title_id = r.title_id AND NOT 
         			r.royalty  < 20 
GO

Этот запрос выдаст 18 названий книг, у которых авторские отчисления составляют 20% или более.

Другие ключевые слова

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

LIKE. Ключевое слово LIKE применяется для поиска по соответствию шаблону. Соответствие шаблону (pattern matching) проверяется для двух операндов условия поиска – сопоставляемого выражения (match expression) и шаблона (pattern), задающего условие поиска. При этом используется такой синтаксис:

<сопоставляемое_выражение> LIKE <шаблон>

Если сопоставляемое выражение соответствует шаблону, то возвращается булево значение TRUE, а если нет, то возвращается FALSE. Сопоставляемое выражение должно иметь тип данных character string, в противном случае SQL Server преобразует его в данные, имеющие тип character string, если это возможно.

Шаблоны являются строковыми выражениями (string expressions), т.е. строками, состоящими из символов (characters) и метасимволов (wildcard characters). Метасимволы – это символы, имеющие особый смысл при использовании внутри строковых выражений. Метасимволы, которые можно применять в шаблонах, перечислены в табл. 14.2.

Таблица 14.2. Метасимволы T-SQL
МетасимволОписание
%Символ процента соответствует строке из нескольких символов (в том числе, пустой строке и строке из одного символа)
_Символ подчеркивания соответствует любому одному символу
[]Метасимвол диапазона соответствует любому одному символу из заданного диапазона или набора символов. Например, [m-p] или [mnop] соответствуют любому из символов m, n, o или p
[^]Метасимвол "не в диапазоне" соответствует любому одному символу, не входящему в диапазон или набор символов. Например, [^m-p] или [^mnop] соответствуют любому из символов, кроме символов m, n, o или p

Чтобы лучше понять применение ключевого слова LIKE и метасимволов, рассмотрим несколько примеров. Если нужно найти в таблице authors все фамилии, начинающиеся с буквы S, то можно воспользоваться таким запросом с метасимволом %:

SELECT  		au_lname 
FROM     		authors 
WHERE    		au_lname LIKE "S%"
GO

Набор результатов может быть, например, таким:

au_lname 
-----------
Smith 
Straight 
Stringer

В этом запросе "S%" означает, что нужно возвращать все строки с фамилиями, первой буквой которых будет S, а за ней может следовать произвольное количества букв.

Примечание. Примеры данного раздела предполагают, что вы применяете стандартный порядок сортировки – Dictionary Order, Case-Insensitive (лексикографический, нечувствительный к регистру). Если вы зададите другой порядок сортировки, то выдаваемые результаты могут измениться, однако принцип работы операции LIKE останется прежним.

Чтобы извлечь информацию об авторе, идентификатор которого начинается с числа 724, и, зная, что все идентификаторы авторов имеют формат как у номеров социального страхования (три цифры, тире, затем две цифры, затем еще тире, и затем четыре цифры), вы можете воспользоваться метасимволом "_", вот так:

SELECT   		* 
FROM     		authors 
WHERE    		au_id LIKE "724-__-____"
GO

В набор результатов попадут две строки со следующими значениями au_id: 724-08-9931 и 724-80-9391.

А теперь давайте рассмотрим пример применения метасимвола []. Чтобы получить фамилии авторов, начинающиеся на букву от A до M, можно воспользоваться метасимволом [] в сочетании с метасимволом %, вот так:

SELECT   		au_lname 
FROM     		authors 
WHERE    		au_lname LIKE "[A-M]%"
GO

Набор результатов будет содержать 14 строк с фамилиями, начинающимися на букву от A до M (или 13 строк, если пользоваться порядком сортировки, чувствительным к регистру букв).

Если в этом запросе поменять метасимвол [] на [^], то будут выданы строки, содержащие фамилии, начинающиеся на буквы вне диапазона от A до M:

SELECT   		au_lname 
FROM     		authors 
WHERE    		au_lname LIKE "[^A-M]%"
GO

Такой запрос вернет 9 строк.

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

SELECT   		au_lname 
FROM     		authors 
WHERE    		au_lname LIKE "[A-M]%" OR 
         			au_lname LIKE "[a-m]%"
GO

Имя "del Castillo" попадет в набор результатов, и это будет отличать этот запрос от запроса, чувствительного к регистру, находящего только ПРОПИСНЫЕ буквы от A до M.

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

SELECT   		title 
FROM     		titles 
WHERE    		title NOT LIKE "The %"
GO

Этот запрос вернет 15 строк.

Пользуясь ключевым словом LIKE, вы можете дать волю своей фантазии. Однако будьте осторожны и проверяйте, что ваши запросы работают именно так, как задумано. Если не поставить NOT или символ ^ там, где это надо, то набор результатов будет противоположен ожидаемому. Если не поставить в нужном месте метасимвол %, то результат тоже будет неправильным. И не забывайте о том, что первые и завершающие пробелы тоже участвуют в сопоставлении шаблону.

ESCAPE. При помощи ключевого слова ESCAPE можно задать сопоставление шаблону, содержащему сами знаки, служащие для обозначения метасимволов (т.е., сами символы ^, %, [, ] и _). Для этого вы должны задать после ключевого слова ESCAPE так называемый escape-символ, обозначающий, что символ, следующий за ним, следует понимать "как есть". Например, чтобы найти все строки из таблицы, имеющие символ подчеркивания в колонке title, можно применить такой запрос:

SELECT   		title 
FROM     		titles 
WHERE    		title LIKE "%e_%" ESCAPE "e"
GO

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

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

<проверяемое_выражение> BETWEEN <начальное_выражение> AND <конечное_выражение>

Если проверяемое_выражение больше или равно, чем начальное_выражение, и в то же время меньше или равно, чем конечное_выражение, то результатом условия поиска является булево значение TRUE, а в противном случае результатом условия поиска является FALSE.

Ниже приведен пример запроса, в котором BETWEEN применяется для поиска названий книг с ценой от 5 до 25 долларов:

SELECT   		price, title 
FROM     		titles 
WHERE    		price BETWEEN 5.00 AND 25.00
GO

Этот запрос вернет 14 строк.

Вместе с BETWEEN тоже можно применять NOT, тогда будут искаться строки, не входящие в заданный диапазон. Например, чтобы найти названия книг с ценами вне диапазона от 20 до 30 долларов (а именно, книг дешевле 20 и дороже 30 долларов), можно было бы применить такой запрос:

SELECT   		price, title 
FROM     		titles 
WHERE    		price NOT BETWEEN 20.00 AND 30.00
GO

В конструкции с ключевым словом BETWEEN проверяемое_выражение должно иметь такой же тип данных, как и начальное_выражение и конечное_выражение.

В последнем примере колонка price (цена) имеет тип данных money, поэтому и начальное_выражение, и конечное_выражение должны быть числами, сравнимыми с типом данных money, или для них должно быть возможным неявное преобразование в этот тип данных. Вы не можете применять в качестве проверяемого выражения значение из колонки price, а для начального и конечных выражений – символьные строки (т.к. они имеют тип данных char). Если вы все-таки сделаете это, то SQL Server выдаст сообщение об ошибке.

Примечание. SQL Server при необходимости будет автоматически преобразовывать типы данных, если только возможно неявное преобразование типов данных (implicit conversion). Неявное преобразование типов данных - это автоматическое преобразование одного типа данных в другой совместимый тип данных. После такого преобразования становится возможным сравнение. Например, если колонка, имеющая тип данных smallint, сравнивается колонкой, имеющей тип данных int, то перед выполнением сравнения SQL Server неявно преобразует тип данных первой колонки к типу данных int. Если неявное преобразование типов данных не поддерживается, то вы можете применять функцию CAST или CONVERT, чтобы выполнить явное преобразование колонки. Чтобы получить схему, показывающую, какие типы данных SQL Server будет преобразовывать неявно, а для каких необходимо явное преобразование, обратитесь к предметному указателю SQL Server Books Online, для темы CAST, а затем в диалоговом окне Topics Found (Найденные темы) выберите CAST and CONVERT (T-SQL).

Мы приведем еще один пример использования ключевого слова BETWEEN, которое на этот раз применяет в качестве условия поиска текстовые строки:

SELECT   		au_lname 
FROM     		authors 
WHERE    		au_lname BETWEEN "Bennet" AND "McBadden" 
GO

Этот запрос позволяет найти фамилии авторов, которые при сортировке в алфавитном порядке попали бы между фамилиями "Bennet" и "McBadden". Поскольку границы диапазона BETWEEN считаются входящими в проверяемый диапазон, то фамилии "Bennet" и "McBadden" тоже войдут в набор результатов запроса (эти фамилии имеются в таблице).

IS NULL. Ключевое слово IS NULL используется в условиях поиска, ищущих строки, содержащие null -значение в заданной колонке. Например, чтобы найти в таблице titles названия книг, у которых нет данных в колонке notes (примечания), т.е. когда значением колонки notes является NULL, можно воспользоваться таким запросом:

SELECT   		title, notes 
FROM     		titles 
WHERE    		notes IS NULL
GO
Этот запрос выдаст такой набор результатов:
title                                  	notes 
----------------------------------------	------
The Psychology of Computer Cooking     	NULL

Как видите, null -значения в колонке notes в наборе результатов отображаются словом NULL. Это слово не является содержимым колонки, оно служит просто обозначением того, что в данной колонке находится null-значение. (Помните, в лекции 10 объяснялось, что null -значения – это неизвестные значения.)

Чтобы найти названия книг, у которых имеются данные о колонке notes (т.е., у которых значение колонки notes не является null -значением), применяйте конструкцию IS NOT NULL, вот так:

SELECT   		title, notes 
FROM     		titles 
WHERE    		notes IS NOT NULL
GO

Набор результатов будет содержать 17 строк, в каждой из которых в колонке notes будут иметься символы (один или несколько), т.е. не null -значения.

IN. Ключевое слово IN используется как условие поиска, проверяющее, не соответствует ли проверяемое выражение какому-либо из значений в подзапросе или в списке значений. Если соответствие найдено, то возвращается значение TRUE. NOT IN возвращает отрицание того, что получилось бы при применении IN, поэтому NOT IN возвратит значение TRUE, если проверяемое выражение не найдено в подзапросе или в списке значений. Используется такой синтаксис:

<проверяемое_выражение> IN (<подзапрос>)

или

<проверяемое_выражение> IN (<список_значений>)

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

В приведенном ниже примере запроса ключевое слово IN применяется в сочетании со списком значений для поиска идентификаторов должностей для трех описаний должностных обязанностей:

SELECT   		job_id 
FROM     		jobs 
WHERE    		job_desc IN ("Operations Manager",  
                      			      "Marketing Manager", 
                      			      "Designer")
GO

В этом запросе применен такой список значений: (Operations Manager, Marketing Manager, Designer). Запрос будет возвращать идентификаторы должностей из строк, содержащих в колонке job_desc какое-либо значение из списка. Благодаря ключевому слову IN ваш запрос проще и понятней для восприятия, чем запрос, который получился, если бы вы применили две операции OR, вот такой:

SELECT   		job_id 
FROM     		jobs 
WHERE    		job_desc = "Operations Manager" OR  
        	job_desc = "Marketing Manager"  OR   
         	job_desc = "Designer"
GO

В следующем запросе ключевое слово IN используется в одном операторе дважды – первый раз с подзапросом, а второй раз – со списком значений внутри подзапроса:

SELECT   		fname, lname    	-- Внешний запрос 
FROM     		employee 
WHERE    		job_id IN (	SELECT 	job_id   -- Внутренний запрос, подзапрос 
                     				FROM   	jobs 
                   					WHERE  	job_desc IN ("Operations Manager", 
                     					"Marketing Manager", 
                     					"Designer"))
GO

Сначала будет искаться подзапрос (в нашем примере – набор значений job_id ). Значения job_id получаются как результаты подзапроса и не выводятся на экран, они используются внешним запросом как выражения для его собственного условия поиска IN. Окончательный набор результатов будет содержать имена и фамилии всех сотрудников, должности которых называются Operations Manager, Marketing Manager или Designer.

Набор результатов будет таким (запрос вернет 11 строк):

fname                		lname 
------------------------
Pedro                		Afonso 
Lesley               		Brown 
Palle                		Ibsen 
Karin                		Josephs 
Maria                		Larsson 
Elizabeth     	Lincoln 
Patricia             		McKenna 
Roland               		Mendel 
Helvetius            	Nagy 
Miguel               		Paolino 
Daniel               		Tonini

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

SELECT   		pub_name 
FROM     		publishers 
WHERE    		state NOT IN (	"CA", 
                       			"TX", 
                       			"IL")
GO

Этот запрос вернет пять строк, у которых значение в колонке state (штат) не является обозначением ни одного из трех штатов, указанных в списке значений. Если вы установили настройку ANSI nulls вашей базы данных на ON, то набор результатов будет содержать только три строки. Такое малое количество выданных строк произошло потому, что две из пяти строк первоначального набора результатов в качестве значения для state будут иметь NULL, а значения NULL не извлекаются при настройке ANSI nulls заданной как ON.

Чтобы узнать, какова настройка ANSI nulls для базы данных pubs, запустите следующую системную хранимую процедуру:

sp_dboption "pubs", "ANSI nulls" 
GO

Если настройка ANSI nulls задана как OFF, то измените ее на ON при помощи следующего оператора:

sp_dboption "pubs", "ANSI nulls", TRUE 
GO

А чтобы изменить настройку с ON на OFF, примените такой же оператор, но с FALSE вместо TRUE.

Дополнительная информация. Чтобы получить более подробную информацию о действии настройки ANSI nulls, найдите в предметном указателе (индексе) SQL Server Books Online "sp_dpoption", а затем в диалоговом окне найденных тем выберите sp_db_option (T-SQL). Кроме того, найдите в предметном указателе SQL Server Books Online "ANSI nulls" и нажмите в нижней части страницы на ссылку SET ANSI_NULLS, в результате чего на экране появится тема "SET ANSI_NULLS (T-SQL)".

EXISTS. Ключевое слово EXISTS используется для проверки существования строк в выводе подзапроса, указанного после него. Используется такой синтаксис:

EXISTS (<подзапрос>)

Если имеется хоть одна строка, удовлетворяющая подзапросу, то возвращается значение TRUE.

Чтобы найти имена авторов, у которых имеются опубликованные книги, можно применить такой запрос:

SELECT   		au_fname, au_lname 
FROM      		authors  
WHERE     		EXISTS (	SELECT au_id 
                  			FROM   titleauthor 
                  			WHERE  titleauthor.au_id = authors.au_id)
GO

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

CONTAINS и FREETEXT. Ключевые слова CONTAINS и FREETEXT используются для полнотекстного поиска в колонках, имеющих символьные типы данных. Это обеспечивает большую гибкость, по сравнению с возможностями ключевого слова LIKE. Например, благодаря ключевому слову CONTAINS, можно искать слова, обладающие не точным соответствием, а некоторой похожестью на заданное слово или фразу (такое сопоставление называется "нечетким"). При помощи FREETEXT можно искать слова, соответствующие или нечетко соответствующие заданной строке поиска или ее части. Найденные слова не обязаны ни полностью совпадать со строкой поиска, ни следовать в порядке расположения слов в строке поиска. Эти два ключевых слова могут применяться различными способами, они обеспечивают разнообразные возможности полнотекстного поиска, рассмотрение которых выходит за рамки нашей книги.

Дополнительная информация. Для дополнительной информации о ключевых словах CONTAINS и FREETEXT, обратитесь к SQL Server Books Online, к темам "CONTAINS" и "FREETEXT" в предметном указателе.
Предложение GROUP BY

Предложение GROUP BY применяется после предложения WHERE и означает, что строки набора результатов должны быть сгруппированы в соответствии с данными в колонке группировки. Если в предложении SELECT используется агрегатная функция, то для каждой группы вычисляется и отображается в выводе итоговое агрегатное значение. Агрегатная функция выполняет вычисления и возвращает значение. (Про агрегатные функции см. раздел "Агрегатные функции" далее.)

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

Предложение GROUP BY особенно полезно, когда в предложении SELECT имеется агрегатная функция. Давайте рассмотрим пример оператора SELECT, применяющего предложение GROUP BY для получения сведений об общем количестве проданных книг для каждого из названий книг:

SELECT   		title_id, SUM(qty) 
FROM     		sales 
GROUP 		BY title_id
GO

Будет выдан набор результатов, содержащий 16 строк:

title_id 
----------------------
BU1032            			15 
BU1111            			25 
BU2075            			35 
BU7832            			15 
MC2222            			10 
MC3021            			40 
PC1035            			30 
PC8888            			50 
PS1372            			20 
PS2091           			108 
PS2106            			25 
PS3333            			15 
PS7777            			25 
TC3218            			40 
TC4203            			20 
TC7777            			20

Этот запрос не содержит предложения WHERE – оно не нужно. Набор результатов состоит из колонки title_id (идентификатор названия книги) и итоговой колонки, не имеющей заголовка. Для каждого отдельного названия книги будет подсчитано общее количество экземпляров этой книги, это число будет показано в итоговой колонке. Например, пусть значение BU1032 колонки title_id встретится в таблице sales (продажи) два раза, первый раз оно будет обозначать продажу 5 экземпляров книги (колонка qty будет иметь значение 5), а во второй раз будет обозначать продажу книг по другому заказу, на этот раз будет продано 10 экземпляров книги. Агрегатная функция SUM произведет суммирование этих двух продаж, отсюда и получится, что общее количество проданных экземпляров равно 15, что и будет показано в итоговой колонке. Если вы хотите, чтобы итоговая колонка имела заголовок, воспользуйтесь ключевым словом AS, вот так:

SELECT      		title_id, SUM(qty) AS "Колич прод"
FROM         		sales 
GROUP BY 	title_id
GO

Теперь набор результатов станет показывать заголовок для итоговой колонки (в наборе результатов содержится 16 строк):

itle_id  		Колич прод
----------------------------
BU1032            				15 
BU1111            				25 
BU2075            				35 
BU7832            				15 
MC2222            				10 
MC3021            				40 
PC1035            				30 
PC8888            				50 
PS1372            				20 
PS2091           				108 
PS2106            				25 
PS3333            				15 
PS7777            				25 
TC3218            				40 
TC4203            				20 
TC7777            				20

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

SELECT   		type, pub_id, AVG(price) AS "Средняя цена"
FROM     		titles 
GROUP BY 	type, pub_id
GO
В набор результатов попадут 8 строк:
type         		pub_id 	                 Средняя цена
--------------------------------------------------
business     		0736                       		2.99 
psychology   		0736                      		11.48 
UNDECIDED    		0877                       		NULL 
mod_cook     		0877                      		11.49 
psychology   		0877                      		21.59 
trad_cook    		0877                      		15.96 
business     		1389                      		17.31 
popular_comp 	    1389                      		21.48

Обратите внимание, что книги, имеющие тип psychology и business, попали в набор результатов более одного раза, потому что они сгруппированы для разных идентификаторов издательств. Значение NULL, показанное в качестве средней цены книг типа UNDECIDED (нераспределенные), отражает тот факт, что для книг этого типа в таблицу не были введены их цены, поэтому невозможно вычислить среднюю цену.

Предложение GROUP BY можно применять с необязательным ключевым словом ALL, означающим, что в набор результатов должны быть включены все группы, даже не соответствующие условию поиска. Группы, не имеющие строк, соответствующих условию поиска, будут содержать в итоговой колонке значение NULL, поэтому их будет сразу видно. Например, чтобы узнать среднюю цену для книг, имеющих авторские отчисления 12%, а также показать в наборе результатов строки для книг, имеющих авторские отчисления не 12% (у них в итоговой колонке будет значение NULL), группируя книги сначала по типам, а затем по идентификатору издательства, выполните такой запрос:

SELECT   		type, pub_id, AVG(price) AS "Средняя цена" 
FROM     		titles 
WHERE    		royalty = 12 
GROUP BY 	ALL type, pub_id
GO

В набор результатов попадут 8 строк:

type         				pub_id 	Средняя цена
-------------------------------------------------
business     		0736                       		NULL 
psychology   		0736                      		10.95 
UNDECIDED    		0877                       		NULL 
mod_cook     		0877                      		19.99 
psychology   		0877                       		NULL 
trad_cook    		0877                       		NULL 
business     		1389                       		NULL 
popular_comp 	    1389                       		NULL

Будут выведены строки для всех типов книг, но для типов книг, у которых не имеется книг с 12-процентными авторскими отчислениями, появится NULL.

Если мы уберем ключевое слово ALL, то набор результатов будет содержать информацию только для тех типов книг, у которых имеются книги с 12-процентными авторскими отчислениями. Набор результатов будет содержать 2 строки и будет таким:

type         				pub_id 	Средняя цена
---------------------------------------------------
psychology   		0736                      		10.95 
mod_cook     		0877                      		19.99

Предложение GROUP BY часто применяется в сочетании с предложением HAVING, про которое мы сейчас вам расскажем.

Предложение HAVING

Предложение HAVING применяется, чтобы задать условия поиска для групп или для агрегатной функции. Предложение HAVING чаще всего используется после предложения GROUP BY в случаях, когда условие поиска должно проверяться уже после группировки результатов. Если условие поиска можно было бы проверить до группировки, то гораздо эффективней было бы поместить его в предложение WHERE, а не пользоваться предложением HAVING (за счет этого уменьшилось бы количество строк, участвующих в группировке). Если предложение GROUP BY отсутствует, то HAVING может применяться только в отношении агрегатной функции в списке выборки. В этом случае предложение HAVING действует точно так же, как предложение WHERE. Если попытаться использовать HAVING как-нибудь по-другому, то SQL Server выдаст сообщение об ошибке.

Предложение HAVING имеет такой синтаксис:

HAVING <условие_поиска>

Здесь условие_поиска имеет такой же смысл, что и условие поиска. (См. раздел "Предложение WHERE и условие поиска" выше в данной лекции). Единственным различием между предложениями HAVING и WHERE является то, что предложение HAVING может содержать агрегатную функцию в условии поиска, а предложение WHERE – нет.

Примечание. Агрегатные функции можно применять в предложениях SELECT и HAVING, но не в предложении WHERE.

Ниже приведен пример запроса, использующего предложение HAVING для поиска книг, сгруппированных по типам и по издательствам, средняя цена на которые превышает 15 долларов:

SELECT   		type, pub_id, AVG(price) AS "Средняя цена"
FROM     		titles 
GROUP           BY type, pub_id 
HAVING   		AVG(price) > 15.00 
GO

В набор результатов попадут 4 строки:

type         		pub_id 	  Средняя цена
--------------------------------------------------
psychology   		0877           		21.59 
trad_cook    		0877                15.96 
business     		1389                17.31 
popular_comp 	    1389                21.48

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

SELECT   		type, pub_id, AVG(price) AS "Средняя цена" 
FROM     		titles 
GROUP BY 	type, pub_id 
HAVING   		AVG(price) >= 15.00 AND 
         			AVG(price) <= 20.00
GO

В набор результатов попадут 2 строки:

type         	pub_id 	  Средняя цена
--------------------------------------------------
trad_cook    	0877      15.96 
business     	1389      17.31

Такой же результат получится, если вместо AND применить предложение BETWEEN, вот так:

SELECT   	type, pub_id, AVG(price) AS "Средняя цена"
FROM     	titles 
GROUP BY 	type, pub_id 
HAVING   	AVG(price) BETWEEN 15.00 AND 20.00
GO

Чтобы применять HAVING без предложения GROUP BY, нужно иметь агрегатную функцию в списке выборки и в предложении HAVING. Например, чтобы выводить сумму цен на книги типа mod_cook (современная кулинария), только в тех случаях, когда эта сумма будет превышать 20 долларов, можно применять такой запрос:

SELECT   		SUM(price) 
FROM     		titles 
WHERE    		type = "mod_cook"
HAVING   		SUM(price) > 20
GO

Если в этом запросе поместить выражение SUM(price) > 20 в предложение WHERE, то SQL Server выдаст сообщение об ошибке, т.к. в предложениях WHERE агрегатные функции применять нельзя.

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

Предложение ORDER BY применяется, чтобы задать порядок, в котором должны сортироваться строки набора результатов. Пользуясь ключевыми словами ASC и DESC, вы можете задать как возрастающий (ascending, от меньших значений к большим), так и убывающий (descending, от больших значений к меньшим) порядок сортировки. Если порядок сортировки не указать, то по умолчанию будет применяться возрастающий порядок сортировки. В предложении ORDER BY можно задать более одной колонки. Результаты будут сортироваться по первой из заданных колонок, но если в первой колонке встретятся строки с одинаковыми значениями, то они будут сортироваться в порядке возрастания значения из второй колонки, и т.д. Как вы увидите из материала данного раздела, такая сортировка особенно полезна при использовании вместе с предложением GROUP BY. Давайте сначала рассмотрим пример, в котором предложение ORDER BY работает с одной колонкой и сортирует список авторов по фамилии , в возрастающем порядке:

SELECT   	au_lname, au_fname 
FROM     	authors 
ORDER BY 	au_lname ASC
GO

Набор результатов будет отсортирован в алфавитном порядке по фамилиям авторов. Не забудьте, что чувствительность сортировки к регистру букв, заданная вами при инсталляции SQL Server, повлияет на обработку фамилий вроде "del Castillo".

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

SELECT   	job_id, lname, fname 
FROM     	employee 
ORDER BY 	job_id, lname, fname
GO

Набор результатов (43 строки) будет выглядеть так:

job_id lname                          			fname 
-----------------------------------
     2 Cramer                         		Philip 
     3 Devon                          		Ann 
     4 Chang                          		Francisco 
     5 Henriot                        		Paul 
     5 Hernadez                       		Carlos 
     5 Labrune                        		Janine 
     5 Lebihan                        		Laurence 
     5 Muller                         		Rita 
     5 Ottlieb                        		Sven 
     5 Pontes                         		Maria 
     6 Ashworth                       		Victoria 
     6 Karttunen                      		Matti 
     6 Roel                           		Diego 
     6 Roulet                         		Annette 
     7 Brown                          		Lesley 
      7 Ibsen                          		Palle 
     7 Larsson                        		Maria 
     7 Nagy                           		Helvetius 
     . .                              .
     . .                              .
     . .                              .   
    13 Accorti                        		Paolo 
    13 O’Rourke                       		Timothy 
    13 Schmitt                        		Carine 
    14 Afonso                         		Pedro 
    14 Josephs                       		Karin 
    14 Lincoln                        		Elizabeth

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

А теперь давайте рассмотрим предложение ORDER BY, работающее совместно с предложением GROUP BY и агрегатной функцией:

SELECT   	type, pub_id, AVG(price) AS "Средняя цена" 
FROM     	titles 
GROUP BY 	type, pub_id 
ORDER BY 	Средняя цена 
GO

Набор результатов (8 строк) будет выглядеть так:

type         				pub_id 	Средняя цена
-------------------------------------------------
UNDECIDED    		0877                       		NULL 
business     		0736                       		2.99 
business     		1389                      		17.31 
mod_cook     		0877                      		11.49 
popular_comp 	    1389                      		21.48 
psychology   		0736                      		11.48 
psychology   		0877                      		21.59 
trad_cook    		0877                      		15.96

Результаты отсортированы в алфавитном порядке (возрастающем) по типу книг. Также обратите внимание, что в этом запросе в предложении GROUP BY должны присутствовать и type, и pub_id, потому что они не являются частью агрегатной функции. Если вы не зададите колонку pub_id в предложении GROUP BY, то SQL Server выдаст сообщение об ошибке (рис. 14.4).

В предложении ORDER BY нельзя применять агрегатные функции и подзапросы. Однако если вы зададите алиас агрегатной функции в предложении SELECT, то его применить можно в предложении ORDER BY, вот так:

SELECT   	type, pub_id, AVG(price) AS "Средняя цена" 
FROM     	titles 
GROUP 		BY type, pub_id 
ORDER 		BY type
GO

 Сообщение об ошибке, которое появится, если не задать pub_id в предложении GROUP BY


увеличить изображение

Рис. 14.4.  Сообщение об ошибке, которое появится, если не задать pub_id в предложении GROUP BY

Набор результатов (8 строк) будет выглядеть так:

type         				pub_id 	Средняя цена 
-------------------------------------------------
UNDECIDED    		0877                       		NULL 
business     		0736                       		2.99 
business     		1389                      		17.31 
mod_cook     		0877                      		11.49 
popular_comp 	    1389                      		21.48 
psychology   		0736                      		11.48 
psychology   		0877                      		21.59 
trad_cook    		0877                      		15.96

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

Примечание. Точные результаты применения предложения ORDER BY зависят от настроек сортировки, заданных при инсталляции SQL Server.
Операция UNION

UNION считается не предложением (clause), а операцией (operator). Она используется для объединения результатов двух или нескольких запросов в один набор результатов. Применяя UNION, вы должны соблюдать два следующих правила:

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

Кроме того, соответственные колонки должны иметь совместимые типы данных. Это значит, что соответственные колонки должны иметь либо одинаковые типы данных, либо SQL Server сможет выполнить неявное преобразование одного типа данных в другой. Ниже дан пример применения операции UNION, соединяющей наборы результатов двух операторов SELECT, выдающих колонки city и state из обеих таблиц publishers и stores:

SELECT   		city, state 
FROM     		publishers 
UNION    		SELECT 	city, state 
         			FROM   	stores
GO

Набор результатов (14 строк) будет таким:

city               state 
-------------------------
Fremont              	CA 
Los Gatos               CA 
Portland             	OR 
Remulade             	WA 
Seattle              	WA 
Tustin               	CA 
Chicago              	IL 
Dallas               	TX 
Munchen              	NULL 
Boston               	MA 
New York             	NY 
Paris                	NULL 
Berkeley             	CA 
Washington           	DC
Примечание. Результаты запросов-примеров из данного раздела могут отличаться в зависимости от применяемых вами настроек сортировки SQL Server.

Две эти колонки, city и state, в обеих таблицах имеют одинаковый тип данных (char), поэтому преобразование типа не потребуется. Заголовки колонок для набора результатов операции UNION берутся из первого оператора SELECT. Если вы хотите создать алиас для заголовка, то поместите его в первый оператор SELECT, вот так:

SELECT   		city AS "Все города", state AS "Все штаты"
FROM     		publishers 
UNION    		SELECT 	city, state 
         			FROM   	stores
GO

Набор результатов (14 строк) будет таким:

Все города           			Все штаты 
------------------------------------
Fremont              			CA 
Los Gatos            			CA 
Portland             			OR 
Remulade             			WA 
Seattle              			WA 
Tustin               			CA 
Chicago              			IL 
Dallas               			TX 
Munchen              			NULL 
Boston               			MA 
New York             			NY 
Paris                			NULL 
Berkeley             			CA
Washington           			DC

При объединении наборов результатов вовсе не обязательно указывать в обоих предложениях SELECT одни и те же колонки. Например, вы можете выбрать колонки city и state из таблицы stores и колонки city и country из таблицы publishers, вот так:

SELECT   		city, country
FROM     		publishers 
UNION    		SELECT 	city, state 
         			FROM   	stores
GO

Набор результатов (14 строк) будет таким:

city                country 
----------------------------
Fremont             CA 
Los Gatos           CA 
Portland            OR 
Remulade            WA 
Seattle             WA 
Tustin              CA 
New York            USA 
Paris               France 
Boston              USA 
Munchen             Germany 
Washington          USA 
Chicago             USA 
Berkeley            USA 
Dallas              USA

В этом наборе результатов верхние шесть строк берутся из набора результатов запроса, применяемого к таблице stores, а последние восемь строк берутся из набора результатов запроса, применяемого к таблице publishers. Колонка state имеет тип данных char, а колонка country имеет тип данных varchar. Так как два этих типа данных являются совместимыми, то SQL Server выполнит неявное преобразование таким образом, чтобы обе колонки стали иметь тип varchar. Колонки итогового набора результатов имеют заголовки city и country, так, как указано в первом операторе SELECT, но здесь было бы лучше, чтобы вторая колонка имела заголовок не country (страна), а State or Country (штат или страна).

Единственное ключевое слово, которое можно применять вместе с UNION – это необязательное ключевое слово ALL. Если вы примените его, то в набор результатов будут включены также все повторяющиеся строки (другими словами, в набор результатов будут включены полностью все строки). Если ключевое слово ALL не применяется, то по умолчанию из набора результатов будут исключены все дублирующиеся строки.

ORDER BY можно применять не в каждом операторе SELECT объединения, а только в самом последнем. Благодаря этому ограничению, итоговый набор результатов будет отсортирован только один раз сразу для всех результатов. С другой стороны, вы можете применять GROUP BY и HAVING в отдельных операторах, так как они влияют только на отдельные наборы результатов, а не на итоговый набор результатов. Ниже приведен пример, иллюстрирующий объединение результатов двух операторов SELECT, каждый из которых имеет предложение GROUP BY:

SELECT   		type, COUNT(title) AS "Number of Titles"  
FROM     		titles 
GROUP BY 	type 
UNION    		SELECT   		pub_name, COUNT(titles.title) 
         			FROM     		publishers, titles 
         			WHERE    		publishers.pub_id = titles.pub_id 
         			GROUP BY 	pub_name 
GO

Набор результатов (9 строк) будет таким:

type                     Number of Titles 
————————————————————     ———————— 
Algodata Infosystems     6 
Binnet & Hardley     7 
New Moon Books           5 
psychology               5 
mod_cook                 2 
trad_cook                3 
popular_comp             3 
UNDECIDED                1 
business                 4

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

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

Дополнительная информация. Документацию, относящуюся ко всем допустимым ключевым словам и аргументам T-SQL, вы найдете в SQL Server Books Online.

Функции T-SQL

Теперь, когда вы хорошо знакомы с основными предложениями, применяемыми в операторе SELECT (немного дополнительной информации вы еще узнаете в лекции 20), давайте рассмотрим некоторые функции T-SQL, которые можно применять в предложении SELECT. Эти функции позволяют добиться большей гибкости при создании запросов; они группируются по нескольким категориям, например, относящиеся к таким вещам, как конфигурация, курсор, дата и время, безопасность, система, системная статистика, текст и изображения, математика, набор строк, строки, агрегатные функции. Функции T-SQL выполняют вычисления, преобразования, какие-либо действия, или возвращают некоторую информацию. Имеется много функций, но в этом разделе мы рассмотрим только общеупотребительные агрегатные функции.

Дополнительная информация. Дополнительную информацию об этой и других категориях функций вы найдете, открыв в SQL Server Books Online вкладку Index (Предметный указатель) и открыв тему "functions".
Агрегатные функции

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

Таблица 14.3. Агрегатные функции
ФункцияОписание
AVGВозвращает среднее арифметическое для значений выражения; null-значения игнорируются
COUNTВозвращает количество элементов в выражении (равное количеству строк)
COUNT_BIGТо же самое, что и COUNT, но результат имеет тип данных bigint, а не int
GROUPINGВозвращает специальную дополнительную колонку; применяется, только когда предложение GROUP BY содержит операцию CUBE или ROLLUP. Для дополнительной информации откройте в SQL Server Books Online вкладку Index (Предметный указатель) и откройте тему "GROUPING keyword"
MAXВозвращает максимальное значение из значений выражения
MINВозвращает минимальное значение из значений выражения
STDEVВозвращает статистическое стандартное отклонение (statistical standard deviation) для всех величин выражения. Эта функция предполагает, что выражения, используемые в расчете, являются образцом всей совокупности данных
STDEVPВозвращает статистическое стандартное отклонение для всех величин выражения. Эта функция предполагает, что выражения, используемые в расчете, являются всей совокупностью данных
SUMВозвращает сумму всех значений выражения
VARВозвращает статистическое отклонение (statistical variance) для всех значений из выражения. Эта функция предполагает, что выражения, используемые в расчете, являются образцом всей совокупности данных
VARPВозвращает статистическое отклонение для всех значений из выражения. Эта функция предполагает, что выражения, используемые в расчете, являются всей совокупностью данных

Функция COUNT применяется специальным образом: она подсчитывает все строки таблицы. Для этого нужно после COUNT поместить символ-звездочку в скобках, вот так

SELECT   		COUNT(*) 
FROM     		publishers 
GO

Набор результатов будет таким:

----------------------
         				8

Функции AVG, COUNT, MAX, MIN и SUM могут применяться с необязательными ключевыми словами ALL или DISTINCT. Для каждой из этих функций ALL означает, что функция должна применяться ко всем значениям выражения, а DISTINCT означает, что повторяющиеся значения должны участвовать в расчете только по одному разу. По умолчанию применяется опция ALL.

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

SELECT   		MAX(price) - MIN(price) AS "Разница цен" 
FROM     		titles 
GO

Набор результатов будет таким:

Разница цен 
------------------------------
                   					19.96

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

SELECT   		stores.stor_name, SUM(sales.qty) AS "Заказано всего" 
FROM     		sales, stores 
WHERE    		sales.stor_id = stores.stor_id 
GROUP BY 	stor_name
GO

Набор результатов (6 строк) будет таким:

stor_name                                     Заказано всего 
--------------------------------------------------------
Barnum’s                                      125 
Bookbeat                                      80 
Doc-U-Mat: Quality Laundry and Books          130 
Eric the Read Books                           8 
Fricative Bookshop                            60 
News & Brews                                  90
Примечание. Помните, что в SQL Server имеется множество разновидностей функций. Если вам необходимо выполнять какие-либо специфические действия, обратитесь к SQL Server Books Online и посмотрите, какие встроенные функции уже имеются.

Другие применения оператора SELECT

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

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

SET  		@count = 0 
GO

Вы можете применять оператор SELECT для присваивания локальным переменным значений, получаемых как результат запроса. Например, чтобы присвоить локальной переменной @price значение максимальной величины из имеющихся в колонке price, примените такой оператор:

SELECT   		@price = MAX(price) 
FROM     		items 
GO

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

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

SELECT   		GETDATE()
GO

Функция GETDATE не имеет никаких параметров, но скобки нужны все равно.

Заключение

В этой лекции вы изучили оператор SELECT, отдельные предложения, которые могут быть включены в него, научились ими пользоваться, узнали про условия поиска и про функции. Вы изучили материал о логических операциях, о соединениях, об алиасах, о сопоставлении шаблонам, о результатах группировки и сортировки и о многом другом. Мы дали вам большой объем информации, но у оператора SELECT имеется еще много других возможностей. (О дополнительных возможностях см. лекцию 20; там же мы рассмотрим другие операторы манипулирования данными – INSERT, UPDATE и DELETE. А в лекции 15 мы расскажем о том, как можно вносить изменения в таблицы базы данных.)

Лекция 15. Управление таблицами с помощью T-SQL и Enterprise Manager

Невозможно предусмотреть все критерии, по которым следует создавать базы данных. Все равно рано или поздно вы столкнетесь с тем, что нужно будет производить изменения в структуре отдельной таблицы или же всей базы данных. Модифицирование можно производить с помощью T-SQL и Enterprise Manager. Использование Enterprise Manager позволяет работать в более привычном, наглядном режиме отображения данных, но предоставляет администратору и проектировщику баз данных меньше возможностей для реализации поставленных задач по сравнению с T-SQL.

В лекции 10 вы узнали, как создавать таблицу путем определения ее колонок и типов данных. Создав таблицу, вы можете модифицировать ее различными способами, даже если эта таблица уже содержит данные. В данной лекции описываются некоторые способы модифицирования таблиц, включая изменение, добавление, удаление и переименование колонок, а также удаление всей таблицы. (О создании и модифицировании ограничений ( constraints (*) ) таблицы (метод обеспечения целостности данных), а также триггерах (специальный тип хранимой процедуры, которая автоматически запускается при определенных условиях) см. лекции 16 и 22.)

Примечание. В данном случае constraint – это "связывающее" ограничение, но мы будем называть его для краткости просто ограничением. – Прим пер.

В данной лекции мы рассмотрим использование Transact-SQL (T-SQL) и Microsoft SQL Server 2000 Enterprise Manager для управления вашими таблицами. Следует помнить, что T-SQL и Enterprise Manager имеют различные уровни гибкости для модифицирования таблицы. Enterprise Manager более полезен в том смысле, что позволяет вам выполнять определенные модификации проще, чем при использовании T-SQL. Enterprise Manager выводит на экран информативные сообщения об ошибках и иногда предлагает альтернативы, если вы пытаетесь выполнить неверную модификацию. Однако T-SQL имеет одно преимущество, состоящее в том, что если вы запускаете команды с записью сценария, то получаете записанную трассировку того, как и в каком порядке выполнялись ваши модификации. В этой лекции мы рассмотрим преимущества и недостатки использования этих двух методов для модифицирования таблиц.

Прежде чем начать изучение, нам нужно создать две таблицы в базе данных MyDB – Bicycle_Sales (Продажи велосипедов) и Bicycle_Inventory (Запасы велосипедов), – которые будут использоваться для примеров этой лекции. Таблица Bicycle_Sales содержит информацию по продажам велосипедов и состоит из следующих колонок: make_id (идентификатор изделия), model_id (идентификатор модели), description (описание), year (год), sale_id (идентификатор продажи), price (цена), quantity (количество) и sale_date (дата продажи). Колонки make_id и model_id указываются вместе как ограничение foreign key (внешний ключ). Это ограничение содержит ссылку на колонки make_id и model_id в таблице Bicycle_Inventory, образуя уникальный кластеризованный индекс. Как вы увидите в лекции 16, ограничение foreign key может содержать ссылку только на колонку первичного ключа (primary key) или другую колонку с уникальным ограничением в ссылочной таблице. (Подробное описание ограничений дается в лекции 16, описание индексов – в лекции 17.)

Колонка sale_id объявлена как кластеризованный индекс по первичному ключу для таблицы Bicycle_Sales. Ниже приводится оператор CREATE TABLE для создания каждой из этих таблиц:

USE MyDB 
GO 
CREATE TABLE Bicycle_Inventory 
( 
       make_name       		char(10)     		NOT NULL, 
       make_id         		tinyint      		NOT NULL,     
       model_name      		char(12)     		NOT NULL, 
       model_id        		tinyint      		NOT NULL, 
       in_stock        		tinyint      		NOT NULL, 
       on_order        		tinyint      		NULL, 
       CONSTRAINT      	MI_clu_indx 
       UNIQUE CLUSTERED(make_id, model_id) 
) 
GO 

CREATE TABLE Bicycle_Sales 
( 
       make_id      		tinyint     		NOT NULL,--Использована в ограничении
                                            				           --foreign key
       model_id     		tinyint     		NOT NULL,--Также использована в ограничении
                                           			      --foreign key
       description  		char(30)    		NULL, 
       year         		char(4)     		NOT NULL, 
       sale_id      		int         		NOT NULL IDENTITY (1,1) PRIMARY KEY CLUSTERED,
       price        		smallmoney       	NOT NULL,
       quantity     		tinyint     		NOT NULL,
       sale_date    		datetime    		NOT NULL,
	CONSTRAINT   	sales_inventory_fk FOREIGN KEY (make_id, model_id)
	REFERENCES   	Bicycle_Inventory(make_id, model_id)
)
GO
Внимание. Таблица Bicycle_Inventory должна быть создана до таблицы Bicycle_Sales. Если попытаться сначала создать таблицу Bicycle_Sales, то будет выдано сообщение об ошибке. Таблица Bicycle_Sales ссылается на таблицу Bicycle_Inventory с помощью ограничения, и если отсутствует таблица Bicycle_Inventory, то ограничение не может быть создано, что приведет к появлению ошибки.

Теперь, создав наши примеры таблиц базы данных, внесем некоторые изменения, используя сначала T-SQL и затем – Enterprise Manager.

Модифицирование таблицы с помощью T-SQL

В этом разделе вы узнаете, как использовать операторы T-SQL для изменения, добавления, удаления и переименования колонок в существующей таблице. Для осуществления всех модификаций таблицы используется оператор T-SQL ALTER TABLE.

Изменение колонок

Создав таблицу, вы можете изменить для колонки тип данных, точность (для числовых типов) и null-атрибут, а также добавить к колонке свойство ROWGUIDCOL или удалить его из колонки, и все это с помощью оператора ALTER TABLE. Используя другие операторы T-SQL, вы можете выполнять и другие модификации колонок, такие как добавление значения по умолчанию. (Подробно об этих операторах см. лекцию 16.)

Не все колонки можно изменять. В общем случае вы не можете изменять следующие типы колонок.

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

Изменение типа данных

Чтобы можно было изменить тип данных какой-либо колонки, для исходного типа данных должно существовать неявное преобразование в новый тип данных. Таблицу допустимых преобразований можно найти под заголовком "CAST and CONVERT (T-SQL)" (Приведение и преобразование [T-SQL]) в Books Online. Для доступа к этой теме найдите "CAST" в Books Online и затем выберите в диалоговом окне Topics Found "CAST and CONVERT (T-SQL)".

Оператор изменения типа данных колонки имеет следующий синтаксис:

ALTER TABLE		<имя_таблицы>
ALTER COLUMN	<имя_колонки> 	<новый_тип_данных>

Если вы измените для таблицы Bicycle_Sales тип данных datetime колонки sale_date на тип smalldatetime, то строки данных будут занимать меньше места.

Дело в том, что datetime занимает 8 байтов, а smalldatetime – только 4. Чтобы выполнить это изменение, используйте следующий оператор:

ALTER TABLE		Bicycle_Sales
ALTER COLUMN	sale_date smalldatetime 	NOT NULL 
GO

Любые существующие данные таблицы будут неявно преобразованы в новый тип данных – smalldatetime. Null -атрибут NOT NULL не изменился.

Чтобы изменить тип данных char(30) колонки description на тип varchar(20) (имеющий меньшую длину), используйте следующий оператор:

ALTER TABLE		Bicycle_Sales
ALTER COLUMN		description varchar(20) 	NULL
GO

Отметим, что исходный тип данных char(30) допускает неявное преобразование в новый тип данных varchar(20), но varchar(20) короче. Поэтому для всех существующих строк будет без оповещения выполнено усечение значений колонки description длиной более 20 символов и преобразование в тип varchar(20).

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

Чтобы изменить null -атрибут, вы можете изменить для колонки атрибут NOT NULL на NULL, за исключением колонок с ограничением primary key. (По определению в таких колонках не допускаются null -значения.) Вы можете изменить атрибут NULL на NOT NULL, только если в строках соответствующей колонки нет null -значений. Если колонка содержит null -значения, то вы можете выполнить оператор UPDATE для замены всех null -значений на некоторое фактическое значение и затем изменить NULL на NOT NULL для этой колонки. Если null -атрибут не указан для измененной колонки, то в этой колонке допускаются null -значения по умолчанию. Рассмотрим некоторые примеры.

Для изменения null -атрибута колонки quantity с тем, чтобы допускались null -значения, выполните следующий оператор:

ALTER TABLE		Bicycle_Sales 
ALTER COLUMN	quantity tinyint 	NULL 
GO

Тип данных колонки, tinyint, остался без изменений; изменился только null -атрибут. Теперь в колонке quantity будут допускаться null -значения. Если не введено никакого значения, будет происходить автоматическая вставка значения NULL. Это изменение не влияет на значения колонки quantity в существующих строках, но оно позволяет вставлять NULL -значения для новых строк, добавляемых к таблице.

Теперь изменим описание колонки description на NOT NULL. Мы предположим, что в этой колонке уже имеются null -значения. Поэтому сначала мы должны заменить эти null -значения на какое-то фактическое значение – в данном случае – на значение None (Нет), совместимое с типом данной колонки. Чтобы выполнить проверку на значение NULL, надежнее всего не использовать оператор равенства (=), а применять ключевые слова IS NULL или IS NOT NULL. Дело в том, что NULL означает неизвестное значение, а оператор равенства, возможно, не может выполнять сравнение для null -значений (это зависит от установки параметра базы данных ANSI nulls ON [активизирован] или OFF [отключен]). Если для этого параметра задано значение OFF, то оператор равенства выражение = NULL возвратит значение TRUE, если выражение содержит null -значение. Этот оператор возвратит значение FALSE, если выражение не содержит null -значения. Если для параметра ANSI nulls задано значение ON, то оператор выражение = NULL возвратит для всех сравнений значение UNKNOWN и не будет выдано никаких результатов. SQL Server не возвращает значений NULL, как можно было бы ожидать, если параметр ANSI nulls установлен в значение ON. IS NULL и IS NOT NULL действуют одинаковым образом независимо от установки параметра ANSI_NULLS. Чтобы заменить null -значения колонки description на значение None, используйте следующий оператор UPDATE SET:

UPDATE				Bicycle_Sales SET description = "None"
WHERE				description IS NULL 
GO

Теперь изменим null -атрибут колонки description на NOT NULL:

ALTER TABLE		Bicycle_Sales
ALTER COLUMN	description char(30) 	NOT NULL 
GO

И в данном случае мы изменили только null -атрибут этой колонки, а исходный тип данных char(30) остался без изменений. Вы можете одновременно изменить тип данных и null -атрибут в одном операторе ALTER TABLE, как это показано ниже:

ALTER TABLE		Bicycle_Sales
ALTER COLUMN	description varchar(20) 	NOT NULL 
GO

Этот оператор изменяет тип данных и null -атрибут колонки description.

Добавление или удаление свойства ROWGUIDCOL Property

Чтобы добавить к колонке или удалить из колонки свойство ROWGUIDCOL, используйте следующий синтаксис:

ALTER TABLE		<имя_таблицы>
ALTER COLUMN	<имя_колонки> ADD | DROP ROWGUIDCOL

Свойство ROWGUIDCOL можно добавлять только в колонку типа uniqueidentifier. Если предположить, что в нашу таблицу Bicycle_Sales была включена колонка типа uniqueidentifier с именем unique_id, то вы могли бы добавить свойство ROWGUIDCOL с помощью следующего оператора:

ALTER TABLE		Bicycle_Sales
ALTER COLUMN	unique_id ADD ROWGUIDCOL
GO

И вы могли бы удалить это свойство с помощью следующего оператора:

ALTER TABLE		Bicycle_Sales
ALTER COLUMN	unique_id DROP ROWGUIDCOL 
GO
Добавление колонок

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

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

ALTER TABLE		<имя_таблицы>
ADD				<имя_колонки> <тип_данных> <null-атрибут>
DEFAULT			значение_по_умолчанию

Например, чтобы добавить к таблице Bicycle_Sales колонку с именем salesperson_id (идентификатор продавца), используйте следующий оператор. (В новой колонке не допускаются null -значения, и она имеет значение по умолчанию, равное 0.)

ALTER TABLE		Bicycle_Sales
ADD				salesperson_id tinyint NOT NULL 
DEFAULT			0 
GO

Поскольку колонка объявлена как NOT NULL, то во всех существующих строках таблицы в новую колонку будет занесено значение 0.

Если вместо этого колонка salesperson_id будет объявлена как NULL (см. ниже), то значение по умолчанию не будет обязательным:

ALTER TABLE		Bicycle_Sales
ADD				salesperson_id tinyint NULL 
DEFAULT			0    	--Необязательное значение по умолчанию
GO

Несмотря на то, что мы задали значение по умолчанию, в колонку salesperson_id существующих строк будет занесено значение NULL, а значение по умолчанию будет присваиваться только в новых строках.

Чтобы в существующих строках вместо значения NULL также было присвоено значение по умолчанию (0), используйте в ключевом слове DEFAULT опцию WITH VALUES, как это показано ниже:

ALTER TABLE		Bicycle_Sales
ADD				salesperson_id tinyint NULL
DEFAULT			0 WITH VALUES 
GO

Опция WITH VALUES указывает, что во всех существующих строках новой колонке будет присвоено вместо значения NULL значение по умолчанию.

Удаление колонок

Вы можете также использовать оператор ALTER TABLE для удаления колонок из таблицы. Все данные удаленной колонки будут удалены из таблицы. При использовании T-SQL для удаления колонок вы не можете удалять следующие типы колонок.

Примечание. Эти запрещения тоже действуют, но обрабатываются по-другому, если вы используете для удаления колонки Enterprise Manager. (Более подробную информацию см. в разделе "Модифицирование таблицы с помощью Enterprise Manager" ниже.)

Для удаления колонки из таблицы используйте следующий синтаксис:

ALTER TABLE 	<имя_таблицы>
DROP COLUMN 	<имя_колонки>

Следующий оператор удаляет колонку description из таблицы Bicycle_Sales:

ALTER TABLE		Bicycle_Sales
DROP COLUMN		description 
GO

Колонка description и все ее значения удаляются изо всех строк таблицы.

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

Чтобы переименовать колонку с помощью операторов T-SQL, вы должны запустить системную хранимую процедуру sp_rename, используя следующий синтаксис:

sp_rename 'таблица.исходное_имя_колонки', 'новое_имя_колонки', 'COLUMN'

Например, чтобы заменить имя колонки description на Bicycle_desc, вам нужно использовать следующий оператор:

sp_rename 'Bicycle_Sales.description', 'bicycle_desc', 'COLUMN'
GO

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

Модифицирование таблицы с помощью Enterprise Manager

Как уже говорилось, модифицирование таблицы с помощью Enterprise Manager выполняется проще и дает вам больше функциональных возможностей и гибкости, чем операторы T-SQL. Вы можете выполнять все свои модификации в окне Design Table (Проектирование таблицы) или с помощью схемы (диаграммы) базы данных. Рассмотрим сначала использование окна Design Table. Чтобы открыть окно Design Table для вашей таблицы Bicycle_Sales, выполните следующие шаги:

  1. Раскройте папку базы данных MyDB в левой панели Enterprise Manager.
  2. Щелкните на папке Tables (Таблицы), чтобы в правой панели появился список всех таблиц базы данных MyDB (рис. 15.1).

    Enterprise Manager


    увеличить изображение

    Рис. 15.1.  Enterprise Manager

  3. Щелкните правой кнопкой мыши на таблице Bicycle_Sales в правой панели. Выберите из контекстного меню пункт Design Table, чтобы появилось окно Design Table (рис. 15.2). В этом окне показана исходная, немодифицированная таблица Bicycle_Sales.

    Окно Design Table (Проектирование таблицы)


    Рис. 15.2.  Окно Design Table (Проектирование таблицы)

Изменение колонок

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

Для некоторых ситуаций, когда T-SQL не позволяет выполнить определенные модификации и возвращает сообщение об ошибке, Enterprise Manager предоставляет дополнительные возможности, позволяющие вам правильно осуществить процесс модификаций. Например, если вы попытаетесь с помощью оператора T-SQL ALTER TABLE изменить длину данных колонки, имеющей ограничение primary key или foreign key, то получите сообщение об ошибке, аналогичное следующему сообщению:

Column or parameter #0: Cannot specify a column width on data type int.
(Колонка или параметр #0: Невозможно задать ширину колонки по типу данных int.)

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

Например, чтобы изменить тип данных tinyint на тип smallint для колонки make_id (имеющей ограничение foreign key, содержащее ссылку на колонку make_id таблицы Bicycle_Inventory), просто щелкните на tinyint, щелкните на направленной вниз стрелке, чтобы появился раскрывающийся список Data Type (Тип данных) и затем выберите smallint (рис. 15.3).

Изменение типа данных колонки с помощью Enterprise Manager


Рис. 15.3.  Изменение типа данных колонки с помощью Enterprise Manager

Поскольку колонка make_id имеет ограничение foreign key, появится диалоговое окно Data Type Change Required (Требуется изменение типа данных) (рис. 15.4). Щелкните на кнопке Yes (Да), чтобы автоматически преобразовать в обеих таблицах тип колонки make_id из tinyint в smallint.

Диалоговое окно Data Type Change Required (Требуется изменение типа данных)


Рис. 15.4.  Диалоговое окно Data Type Change Required (Требуется изменение типа данных)

Как и в случае использования T-SQL, при изменении типа данных с помощью Enterprise Manager исходный тип данных должен допускать неявное преобразование в новый тип данных. Если вы попытаетесь выполнить недопустимое преобразование, Enterprise Manager возвратит сообщение об ошибке, аналогичное тому, что отображено на рис. 15.5, где показан результат недопустимого способа изменения типа данных для колонки sale_date из типа datetime в тип text. Щелкните на кнопке OK, чтобы закрыть окно с сообщением об ошибке, и измените недопустимый тип данных на тип, допускающий неявное преобразование.

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


Рис. 15.5.  Сообщение об ошибке, которое выводится после попытки изменения типа данных на тип, не допускающий неявного преобразования

Чтобы сохранить ваши изменения, щелкните на кнопке Save Disk (Сохранение на диске) панели инструментов окна Design Table. Затем в диалоговом окне Save (Сохранение) (рис. 15.6), нужно подтвердить, что указанные таблицы должны быть записаны на диск. Чтобы подтвердить, что вы хотите сохранить ваши изменения, щелкните на кнопке Yes.

Диалоговое окно Save (Сохранить)


Рис. 15.6.  Диалоговое окно Save (Сохранить)

Добавление колонок

Чтобы добавить колонку, щелкните на столбце Column Name (Имя колонки) первой пустой строки окна Design Table, введите имя новой колонки, выберите тип ее данных и присвойте ей нужные атрибуты ( Allow Nulls [Разрешить null -значения], Default Value [Значение по умолчанию], Identity и т.д.). Как показано на рис. 15.7, мы добавили колонку с именем salesperson_id с типом данных tinyint, с разрешением использования null -значений и значением по умолчанию 0. Щелкните на кнопке Save Disk, чтобы сохранить ваши изменения. SQL Server добавит к таблице эту новую колонку

Добавление новой колонки с именем salesperson_id


Рис. 15.7.  Добавление новой колонки с именем salesperson_id

Удаление колонок

Удаление колонки – это простой процесс, если вы работаете с Enterprise Manager. В окне Design Table нужно просто щелкнуть правой кнопкой мыши на имени колонки или любом из ее атрибутов (на любой ячейке строки с именем данной колонки) и выбрать из контекстного меню пункт Delete Column (Удалить колонку). Соответствующая строка будет удалена из таблицы. Не забудьте щелкнуть на кнопке Save Disk, чтобы сохранить ваши изменения.

Enterprise Manager предупредит вас, если вы попытаетесь удалить колонку, которая является частью ограничения или индекса, если колонка содержит значение по умолчанию или имеет связанное с ней правило. Вы увидите окно сообщения (рис. 15.8). После щелчка на кнопке Yes последует удаление данной колонки вместе со всеми ее связями.

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


Рис. 15.8.  Окно сообщения, которое появляется при попытке удаления колонки, имеющей связи с другими колонками и таблицами

Создание и использование схемы базы данных

Вы можете также модифицировать таблицы в Enterprise Manager с помощью схемы базы данных. Чтобы создать схему для базы данных MyDB с двумя таблицами Bicycle_Sales и Bicycle_Inventory, выполните следующие шаги:

  1. Раскройте MyDB в левой панели Enterprise Manager и затем щелкните правой кнопкой мыши на Diagrams (Схемы). Выберите из контекстного меню пункт Choose New Database Diagram (Выбор новой схемы базы данных), чтобы появилось начальное окно мастера создания схемы базы данных Create Database Diagram Wizard (рис. 15.9).
  2. Щелкните на кнопке Next (Далее), чтобы появилось окно Select Tables to be Added (Выбор таблиц для добавления) (рис. 15.10). Выделите таблицы, которые хотите включить в вашу схему, в списке Available Tables (Имеющиеся таблицы) и затем щелкните на кнопке Add. В этом примере мы добавили таблицы Bicycle_Inventory и Bicycle_Sales.
  3. Щелкните на кнопке Next, чтобы появилось окно Completing the Create Database Diagram Wizard (Завершение работы мастера создания схемы базы данных). Щелкните на кнопке Finish (Готово), если выбраны нужные таблицы, или щелкните на кнопке Back (Назад) и внесите необходимые изменения.
  4. После щелчка на кнопке Finish вы увидите схему базы данных (рис. 15.11).
  5. Сохраните вашу схему, указав описательное имя (щелкните на кнопке Save Disk и введите имя, когда появится соответствующий запрос).

 Начальное окно мастера Create Database Diagram Wizard (Создание схемы базы данных)


Рис. 15.9.  Начальное окно мастера Create Database Diagram Wizard (Создание схемы базы данных)

 Окно Select Tables to be Added (Выбор таблиц для добавления)


Рис. 15.10.  Окно Select Tables to be Added (Выбор таблиц для добавления)

Вертикальная линия, которая заканчивается изображением ключа и соединяет две таблицы в вашей схеме, представляет связь между ними, выраженную ограничением foreign key. Чтобы вывести на экран метку этой связи, щелкните правой кнопкой мыши на фоновой части окна и выберите из контекстного меню пункт Show Relationship Labels (Показать метки связей). Появится имя ограничения foreign key (рис. 15.12).

Чтобы выделить какую-либо таблицу, щелкните на ней; чтобы выделить более одной таблицы, щелкните на каждой таблице, удерживая клавишу Ctrl. Если щелкнуть правой кнопкой мыши на одной из таблиц и затем выбрать из контекстного меню какой-либо пункт, то соответствующая операция будет применена ко всем выделенным таблицам. Например, если выделить в вашей схеме баз данных обе таблицы, щелкнуть правой кнопкой мыши на одной из таблиц и затем выбрать из контекстного меню пункт Table View, затем Standard, то вид обеих таблиц будет изменен, чтобы представить на экране свойства всех колонок (рис. 15.13).

Пример схемы базы данных


увеличить изображение

Рис. 15.11.  Пример схемы базы данных

Просмотр меток связей между таблицами


увеличить изображение

Рис. 15.12.  Просмотр меток связей между таблицами

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


увеличить изображение

Рис. 15.13.  Просмотр свойств по колонкам в схеме базы данных

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

Следствия изменения таблицы

Если вы изменили таблицу, то любые необходимые изменения вносятся в существующие строки данных сразу после исполнения оператора T-SQL ALTER TABLE или после сохранения изменений, если вы используете Enterprise Manager. SQL Server налагает блокировку на данную таблицу, чтобы никакие другие пользователи не имели к ней доступа, пока выполняются изменения. Модифицирование, которое требует изменения всех строк в достаточно большой таблице, такое как добавление колонки со свойством NOT NULL и значением по умолчанию или удаление колонки, может занять некоторое время и должно выполняться с осторожностью в периоды минимального пользовательского доступа. Если вы модифицируете колонку путем изменения длины ее данных, точности или масштаба, то соответствующая таблица повторно создается в базе данных и существующие данные преобразуются в новый тип данных.

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

Удаление таблицы

Если вы удаляете таблицу, то удаляется все, что связано с этой таблицей: определения и данные таблицы, индексы, ограничения, триггеры и полномочия доступа. Представления и хранимые процедуры, содержащие ссылки на удаляемую таблицу, должны быть удалены явным образом. Таблицу нельзя удалить, если на нее есть ссылка с помощью ограничения foreign key в другой таблице; иными словами, таблицу нельзя удалить, если от нее зависит другая таблица. Прежде чем удалить данную таблицу, следует сначала удалить это ограничение или ссылающуюся таблицу. С другой стороны, таблицу, содержащую ограничение foreign key, можно удалить, если от нее не зависит никакая другая таблица. В этом разделе мы рассмотрим удаление таблицы с помощью T-SQL и Enterprise Manager.

Использование T-SQL для удаления таблицы

Оператор T-SQL, используемый для удаления таблицы, имеет следующий синтаксис:

DROP TABLE <имя_таблицы>

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

Для удаления таблицы Bicycle_Inventory, на которую имеется ссылка из таблицы Bicycle_Sales с помощью ограничения foreign key, мы должны сначала удалить это ограничение foreign key (с именем sales_inventory_fk ) и затем удалить таблицу, как это показано ниже:

ALTER TABLE      	Bicycle_Sales
DROP CONSTRAINT  	sales_inventory_fk
GO 
DROP TABLE       	Bicycle_Inventory 
GO

Если вы попытаетесь удалить таблицу до удаления ограничения foreign key, то получите сообщение об ошибке и таблица не будет удалена.

Использование Enterprise Manager для удаления таблицы

В Enterprise Manager имеется два метода удаления таблицы: использование диалогового окна Drop Objects (Удаление объектов) или использование схемы базы данных. Диалоговое окно Drop Objects наиболее подходит, если вы удаляете таблицу, от которой не зависят никакие другие таблицы. Чтобы использовать этот метод, выполните следующие шаги:

  1. В левой панели Enterprise Manager раскройте базу данных, содержащую таблицу, которую вы хотите удалить, и щелкните на папке Tables; затем в правой панели щелкните правой кнопкой мыши на имени таблицы, которую хотите удалить.
  2. Выберите из контекстного меню пункт Delete (Удалить), чтобы появилось диалоговое окно Drop Objects (рис. 15.14).

     Диалоговое окно Drop Objects (Удаление объектов)


    Рис. 15.14.  Диалоговое окно Drop Objects (Удаление объектов)

  3. Если данная таблица имеет какие-либо зависимые таблицы, щелкните на кнопке Show Dependencies (Показать зависимости), чтобы появилось диалоговое окно Dependencies (рис. 15.15). Любые таблицы, зависящие от данной таблицы, появятся в левом списке этого диалогового окна. Если имеются какие-либо зависимые таблицы, то вы не можете удалить данную таблицу, пока не будут удалены соответствующие зависимости.
  4. Если никакие другие таблицы не зависят от выбранной таблицы, то вы можете удалить эту таблицу, щелкнув на кнопке Drop All (Удалить все) в диалоговом окне Drop Objects.

Диалоговое окно Dependencies для таблицы Bicycle_Sales


Рис. 15.15.  Диалоговое окно Dependencies для таблицы Bicycle_Sales

Чтобы удалить таблицу, которая имеет зависимые таблицы, мы будем использовать второй метод: схему базы данных. В этом примере мы удалим таблицу Bicycle_Inventory, на которую имеется ссылка с помощью ограничения foreign key в таблице Bicycle_Sales. Это удаление не удалось бы выполнить, если бы мы использовали диалоговое окно Drop Objects. Но, используя схему базы данных, где показаны обе таблицы, мы можем удалить любую таблицу, а ограничение foreign key будет удалено автоматически. Для удаления таблицы Bicycle_Inventory выполните следующие шаги:

  1. Откройте схему базы данных в Enterprise Manager, раскрыв базу данных, которую хотите использовать, щелкнув на Diagrams и затем дважды щелкнув на имени подходящей схемы в правой панели. Выделите имя таблицы, которую хотите удалить (в данном случае – Bicycle_Inventory).
  2. Щелкните правой кнопкой мыши в любом месте этой таблицы и выберите из контекстного меню пункт Delete Table From Database (Удалить таблицу из базы данных). При появлении окна, где нужно подтвердить, что вы хотите удалить данную таблицу из базы данных, щелкните на кнопке Yes. Таблица и ограничение foreign key будут удалены из схемы.
  3. Если вы уверены, что хотите окончательно удалить эту таблицу, сохраните свои изменения, щелкнув на кнопке Save Disk. После этого таблица будет удалена из базы данных. Если вы отказались от своего решения удалить таблицу, просто выйдите из окна Edit Diagram (Редактирование схемы) без сохранения изменений, щелкнув на кнопке Close (Закрыть). Если вы затем повторно откроете схему базы данных, исходные таблицы будут на прежнем месте. Никакие изменения не начнут действовать, пока вы не сохраните свою работу.

Заключение

В этой лекции вы узнали, как использовать T-SQL и Enterprise Manager для модифицирования таблиц базы данных путем изменения, удаления, добавления и переименования колонок. В процессе изложения материала были показаны некоторые отличия между функциональными возможностями T-SQL и Enterprise Manager. Вы также узнали, как создается схема базы данных с помощью мастера Create Database Diagram Wizard и как происходит удаление таблицы и всех ее данных из базы данных. В таблицу можно вносить другие типы модификаций, включая изменение, добавление и удаление ограничений и умолчаний. (О модификациях см. лекцию 16.)

Лекция 16. Создание и использование умолчаний, ограничений и правил

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

Умолчания, ограничения и правила – это необязательные атрибуты, которые можно определять по колонкам и таблицам базы данных. В лекции 15 вы ознакомились с умолчаниями, когда описывалось добавление к таблице колонки со значением по умолчанию с помощью оператора ALTER TABLE. В этой лекции вы узнаете о двух методах создания и модифицирования умолчаний. Напоминаем, что умолчания (значения по умолчанию *) – это значения, которые заносятся в определенную колонку, когда не указано явно никакого значения. Ограничения (constraints)** используются как способ идентифицирования допустимых значений для колонки (чтобы отклонять недопустимые значения) а также как средство обеспечения целостности данных в таблицах базы данных и между связанными таблицами. Мы рассмотрим в этой лекции пять типов ограничений; вы также узнаете, как создавать и модифицировать умолчания и ограничения с помощью Transact-SQL (T-SQL) и Microsoft SQL Server Enterprise Manager, хотя использование Enterprise Manager часто оказывается проще.

Умолчания

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

Microsoft SQL Server 2000 позволяет вам определять значение по умолчанию для каждой колонки таблицы. Вы не можете задать умолчание для колонок, имеющих тип данных timestamp или обладающих свойством IDENTITY или ROWGUIDCOL, поскольку эти колонки должны иметь уникальные значения. Колонки этого типа несовместимы со значениями по умолчанию, поскольку применение такого значения к колонке более одного раза приводило бы к тому, что колонка уже не имела бы уникальных значений. Вы можете присваивать только одно значение по умолчанию, и оно будет автоматически использоваться каждый раз, когда это требуется. И еще одно важное замечание относительно умолчаний: значение, задаваемое по умолчанию, должно быть совместимо с типом данных соответствующей колонки.

Значение по умолчанию можно создавать и модифицировать несколькими способами. В этом разделе мы рассмотрим, как определять значение по умолчанию при создании таблицы и как модифицировать колонку, чтобы добавлять или изменять умолчание, сначала – с помощью T-SQL и затем – с помощью Enterprise Manager. Напомним, что в лекции 15 мы рассматривали добавление колонок со значением по умолчанию и влияние этого значения на существующие строки. Вы увидите здесь менее подробный пример такой вставки. Мы также рассмотрим возможности и влияние вставки значения по умолчанию в существующую колонку таблицы.

Определение и модифицирование умолчаний с помощью T-SQL

Вы можете определять значение по умолчанию для колонки посредством одного из трех операторов T-SQL: CREATE TABLE, ALTER TABLE или CREATE DEFAULT. Оператор CREATE DEFAULT, который используется в SQL Server 2000 для совместимости с предыдущими версиями, создает объект типа Default (Default-объект). Если вы используете данный метод, SQL Server сохраняет этот объект отдельно от таблицы, поэтому вы должны выполнять привязку этого объекта к колонке или колонкам с помощью системной хранимой процедуры sp_bindefault. Если вы удаляете таблицу, определение DEFAULT автоматически теряет связь с этой таблицей, но сам Default -объект остается. Но если вы используете метод CREATE TABLE или ALTER TABLE, то SQL Server сохраняет определение DEFAULT вместе с таблицей и при удалении таблицы происходит автоматическое удаление этого умолчания без необходимости выполнения дополнительных шагов. По этой причине обычно рекомендуют не использовать оператор CREATE DEFAULT. Однако использование Default -объекта может оказаться полезным, если одно значение по умолчанию будет использоваться для нескольких колонок.

Для запуска ваших операторов T-SQL вам следует использовать анализатор запросов SQL Query Analyzer, поскольку результаты будут появляться в виде графического пользовательского интерфейса (GUI), что проще для чтения, чем при запуске операторов в окне командной строки.

Оператор CREATE TABLE с атрибутом DEFAULT

Создание умолчания для колонки с помощью оператора CREATE TABLE является предпочтительным, стандартным методом. Следующий оператор создает в базе данных MyDB таблицу, содержащую умолчания для обеих колонок, – columnA (типа char) и columnB (типа int):

USE MyDB
CREATE TABLE MyTable 
( 
columnA  		char(15) 		NULL DEFAULT 'n/a', 
columnB  		int      		NULL DEFAULT 0 
) 
GO

Значение по умолчанию n/a (сокращение от not applicable – неприменимо) для колонки columnA совместимо с типом данных char этой колонки, и значение по умолчанию 0 для колонки columnB совместимо с типом данных int . Если при вставке новой строки в таблицу не указывается конкретное значение для одной или обеих колонок, то используется соответствующее значение по умолчанию. Поэтому единственным способом присваивания этим колонкам значения NULL является явная вставка NULL. Null -значения допустимы, поскольку для обеих колонок указан атрибут NULL. Если бы колонки были определены как NOT NULL, то вы не могли бы выполнять явную вставку значения NULL.

Оператор ALTER TABLE с атрибутом DEFAULT

Чтобы изменить определение DEFAULT для колонки или добавить это определение к колонке, вы можете использовать оператор ALTER TABLE. Если значение по умолчанию уже определено и вам нужно изменить его с помощью этой команды, то вы должны сначала удалить существующее умолчание, указав его имя, и затем добавить новое умолчание. (При использовании Enterprise Manager вам не придется выполнять этот шаг, и это поможет вам понять, что использование Enterprise Manager является более простым методом. Изменив таблицу с помощью Enterprise Manager, вы можете также в любой момент генерировать сценарии для повторного создания таблицы.)

Предположим, что вы не хотите изменять существующее умолчание. Если вы создали умолчание с помощью оператора CREATE TABLE или с помощью Enterprise Manager (что будет описано ниже в этой лекции), но не присвоили имя самому умолчанию, то SQL Server присвоит имя автоматически. Чтобы выяснить, какое имя было присвоено умолчанию (имя используется для удаления умолчания с помощью T-SQL), вы можете запустить хранимую процедуру sp_help, указав имя таблицы, для которой задано это умолчание, как в следующем примере:

USE MyDB
GO
sp_help MyTable
GO

Имена всех ограничений default по таблице MyTable появятся в конце выводимых результатов в столбце под заголовком constraint_name (имя_ограничения) (рис. 16.1).

Предположим, что вы хотите изменить для колонки columnA значение по умолчанию n/a на значение not applicable. Напомним, что мы должны сначала удалить существующее умолчание и затем добавить новое. Чтобы удалить умолчание, используйте следующий оператор:

ALTER TABLE MyTable
DROP CONSTRAINT DF__MyTable__columnA__1920BF5CGO

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

ALTER TABLE MyTable
ADD CONSTRAINT DF_MyTable_columnA  
DEFAULT 'not applicable' FOR columnA 
GO

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

 Результаты работы хранимой процедуры sp_help


увеличить изображение

Рис. 16.1.  Результаты работы хранимой процедуры sp_help

ALTER TABLE MyTable
ADD columnC tinyint 	NOT NULL DEFAULT 13 
GO

Теперь таблица MyTable содержит еще одну колонку, columnC, которая имеет значение по умолчанию 13. Поскольку columnC – новая колонка, определенная с атрибутом NOT NULL, этой колонке в уже существующих строках таблицы будет присвоено значение по умолчанию 13.

Если бы в новой колонке было разрешено использование значений NULL, то все существующие строки получили бы в новой колонке значение NULL. Если нужно, чтобы этой колонке было присвоено значение по умолчанию (вместо NULL), то в предложении DEFAULT нужно использовать параметр WITH VALUES, как это показано ниже:

ALTER TABLE MyTable
ADD columnC tinyint 	NULL DEFAULT 13 WITH VALUES 
GO

При использовании WITH VALUES новой колонке во всех существующих строках таблицы MyTable будет присвоено значение 13 (вместо значения NULL ).

Теперь, когда вы знаете, как создавать определение DEFAULT, которое сохраняется вместе с таблицей, рассмотрим использование оператора CREATE DEFAULT. С помощью этого метода создается Default -объект, который хранится отдельно от таблицы.

Оператор CREATE DEFAULT и процедура sp_bindefault

Вы можете также добавить умолчание к существующей колонке или изменить умолчание по колонке, создав сначала Default-объект с помощью оператора T-SQL CREATE DEFAULT. Создав Default-объект, вы можете затем связать его с колонкой или с определенным пользователем типом данных, используя системную хранимую процедуру sp_bindefault. Как уже говорилось, этот метод остался в SQL Server 2000 только для обратной совместимости; он не является предпочтительным методом, но может оказаться полезным, если вы будете использовать одно значение по умолчанию для колонок нескольких таблиц.

Рассмотрим пример использования оператора CREATE DEFAULT для создания Default-объекта с именем DF_not_applicable и значением n/a. Это умолчание будет создано в базе данных MyDB и затем будет связано с колонкой columnA таблицы MyTable (в предположении, что для этой таблицы не существует никаких умолчаний). Оператор CREATE DEFAULT имеет следующий синтаксис:

CREATE DEFAULT имя_умолчания AS выражение-константа
Процедура sp_bindefault имеет следующий синтаксис:
sp_bindefault 'имя_умолчания', таблица.колонка | определенный_пользователем_тип_данных
[, futureonly]

Параметр имя_умолчания – это имя Default-объекта. Параметр таблица.колонка указывает колонку, которой вы хотите присваивать это умолчание.

С помощью следующих операторов T-SQL создается Default-объект и происходит его привязка к колонке columnA таблицы MyTable:

USE MyDB
GO 
CREATE DEFAULT DF_not_applicable AS 'n/a' 
GO 
sp_bindefault 'DF_not_applicable', 'MyTable.columnA' 
GO

Если для колонки columnA уже задано значение по умолчанию, то SQL Server возвратит сообщение об ошибке, информирующее вас, что вы не можете выполнить привязку умолчания к колонке, для которой уже задано какое-либо умолчание. Удалите сначала это умолчание и затем выполните привязку нового умолчания к данной колонке. (Процесс использования оператора DROP DEFAULT для удаления Default-объекта описывается ниже в этом разделе.)

Вы можете также создать Default-объект и выполнить его привязку непосредственно к определенному пользователем типу данных. Любая колонка, которой присваивается этот конкретный тип данных, наследует данное умолчание автоматически. Вы можете использовать при обращении к процедуре sp_bindefault необязательный параметр futureonly, когда выполняете привязку Default-объекта к определенному пользователем типу данных. Этот параметр препятствует тому, чтобы существующие колонки, имеющие этот определенный пользователем тип данных, наследовали новое умолчание; тем самым только новые колонки с этим типом данных будут наследовать это умолчание. Если параметр futureonly не указан, то SQL Server выполнит привязку ко всем существующим и вновь создаваемым колонкам, имеющим определенный пользователем тип данных.

Например, создадим определенный пользователем тип данных с именем area_code (код_района) и Default-объект с именем DF_area_code и значением 786; тем самым будет выполнена привязка этого умолчания к определенному пользователем типу данных. (О создании определенных пользователем типов данных см. лекцию 10.) Это новый определенный пользователем тип данных, т.е. еще нет колонок с этим типом данных, поэтому параметр futureonly не требуется. Тем не менее мы включим его, чтобы показать его синтаксис, хотя это не окажет никакого влияния. Ниже показаны соответствующие операторы:

sp_addtype 'area_code', 'char(3)', 'NOT NULL'
GO 

CREATE DEFAULT DF_area_code AS 786 
GO 

sp_bindefault 'DF_area_code', 'area_code', 'futureonly' 
GO

Чтобы увидеть на экране этот тип данных и присвоенное ему значение по умолчанию, используйте системную хранимую процедуру sp_help (рис. 16.2).

Результаты Query Analyzer для процедуры sp_help


увеличить изображение

Рис. 16.2.  Результаты Query Analyzer для процедуры sp_help

Процедура sp_unbindefault

Чтобы аннулировать привязку Default-объекта к колонке или определенному пользователем типу данных, используйте процедуру sp_unbindefault, указав имя таблицы и имя колонки или имя определенного пользователем типа данных. Например, для аннулирования привязки Default-объекта DF_not_applicable к колонке columnA таблицы MyTable используйте следующий оператор:

sp_unbindefault 'MyTable.columnA'
GO

Для аннулирования привязки умолчания к определенному пользователем типу данных area_code используйте следующий оператор:

sp_unbindefault 'area_code'
GO

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

Вы можете выполнить привязку Default-объекта к более чем одной колонке с помощью отдельных операторов sp_bindefault. Кроме того, отменив привязку умолчания к колонке, вы можете снова выполнить его привязку, пока не удалили сам Default-объект. Чтобы удалить Default-объект, используйте оператор DROP DEFAULT, как это показано ниже:

DROP DEFAULT DF_area_code
GO

После удаления Default-объекта он уже недоступен. Если вам нужно использовать его снова, вы должны применить оператор CREATE DEFAULT для повторного создания этого объекта.

Определение и модифицирование умолчаний с помощью Enterprise Manager

Как вы уже видели в лекции 15, использование Enterprise Manager – это, видимо, наиболее простой способ создания, просмотра и модифицирования таблиц вашей базы данных. При создании или модифицировании таблицы или колонки с помощью Enterprise Manager система SQL Server автоматически берет на себя исполнение соответствующих команд T-SQL, выполняя эту работу за вас. (Пошаговые инструкции по созданию таблицы с помощью Enterprise Manager см. в лекции 10.) В этом разделе мы рассмотрим особенности использования Enterprise Manager для присваивания и модифицирования умолчания по колонке и создания Default-объекта. Это предпочтительный метод работы. Начнем с примеров присваивания и модифицирования умолчаний.

Присваивание и модифицирование умолчаний

Предположим, у нас имеется таблица с именем Product_Info в базе данных MyDB (рис. 16.3). (Инструкции по созданию этой таблицы с помощью Enterprise Manager см. в лекции 10.)

Чтобы определить умолчание, просто щелкните на имени колонки, которой хотите присвоить это умолчание, и введите значение по умолчанию в поле Default Value (Значение по умолчанию) вкладки Columns (Колонки) внизу окна. На рис. 16.3 колонке Description (Описание) присвоено значение по умолчанию "n/a"; это может быть значение-заполнитель, указывающее, что описание продукта еще не известно. Кроме того, значение по умолчанию заключено в круглые скобки – Enterprise Manager добавляет их автоматически, когда вы сохраняете таблицу.

Изменение значения по умолчанию происходит столь же просто. Замените исходное значение по умолчанию новым значением по умолчанию и сохраните свою работу, щелкнув на кнопке Save (Сохранить). На рис. 16.4 показано, что значение по умолчанию колонки Description изменено на "not available"; на рис. 16.5 показано умолчание "general merchandise" (обычные товары), добавленное к колонке Product_Name (Имя_продукта).

Окно Design Table (Разработка таблицы) для таблицы Product_Info


увеличить изображение

Рис. 16.3.  Окно Design Table (Разработка таблицы) для таблицы Product_Info

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

Когда вы создаете или изменяете умолчание для существующей колонки с помощью Enterprise Manager, то, как и при использовании T-SQL, это не влияет на существующие строки таблицы: новое значение по умолчанию используется только при вставке новых строк. Если вы добавляете к таблице новую колонку и присваиваете ей значение по умолчанию, то в существующих строках данных этой колонке присваивается значение по умолчанию только в том случае, если не разрешено использование значений NULL. В противном случае эта новая колонка получит в существующих строках значение NULL. Чтобы разрешить использование значений NULL для новой колонки со вставкой значения по умолчанию в эту колонку для всех существующих строк, используйте метод, описанный в разделе "Оператор ALTER TABLE с атрибутом DEFAULT" выше в этой лекции.

Окно Design Table, где показано измененное значение по умолчанию


увеличить изображение

Рис. 16.4.  Окно Design Table, где показано измененное значение по умолчанию

 Окно Design Table, где показано добавленное значение по умолчанию


увеличить изображение

Рис. 16.5.  Окно Design Table, где показано добавленное значение по умолчанию

Создание Default-объектов и управление этими объектами

Вы можете также создавать Default-объект и просматривать существующие Default-объекты с помощью Enterprise Manager. Для просмотра существующих Default-объектов откройте Enterprise Manager, раскройте сервер и базу данных, которые хотите использовать, и щелкните на папке Defaults. Все существующие Default-объекты появятся в правой панели (рис. 16.6). Отметим, что показаны умолчания DF_not_applicable и DF_area_code, которые мы создали выше в этой лекции с помощью оператора CREATE DEFAULT.

 Просмотр существующих Default-объектов


увеличить изображение

Рис. 16.6.  Просмотр существующих Default-объектов

Чтобы создать новый Default-объект и выполнить привязку этого умолчания к колонке или определенному пользователем типу данных с помощью Enterprise Manager, выполните следующие шаги.

  1. Раскройте сервер и базу данных, щелкните правой кнопкой мыши на Defaults и выберите из контекстного меню пункт New Default (Создать умолчание), чтобы появилось окно Default Properties (Свойства умолчания) (рис. 16.7). Мы присвоим Default-объекту имя DF_none и значение "none". По окончании щелкните на кнопке OK.
  2. Для привязки вашего умолчания к определенному пользователем типу данных или к колонке щелкните правой кнопкой мыши в правой панели Enterprise Manager на имени этого умолчания (в данном случае – DF_none ) и выберите из контекстного меню пункт Properties (Свойства). Снова появится окно Default Properties, но теперь будут доступны кнопки Bind UDTs (Привязка к определенным пользователем типам) и Bind Columns (Привязка к колонкам).

     Окно Default Properties (Свойства умолчания)


    Рис. 16.7.  Окно Default Properties (Свойства умолчания)

    Щелкните на кнопке Bind UDTs, чтобы появилось диалоговое окно Bind Default to User-defined Data Types (Привязка умолчания к определенным пользователем типам данных) (рис. 16.8). В этом диалоговом окне представлены все определенные пользователем типы данных. В этом списке вы можете выбрать определенный пользователем тип данных, к которому нужно выполнить привязку умолчания. На рис. 16.8 мы видим типы данных area_code и brand_type. Если вы определили другие типы данных, то они также появятся в вашем списке. По окончании щелкните на кнопке Apply (Применить) и затем – на кнопке OK, чтобы вернуться в окно Default Properties. Мы не будем выполнять привязку нашего умолчания к какому-либо определенному пользователем типу данных; мы выполним вместо этого привязку к колонке, как показано на следующем шаге.

      Диалоговое окно Bind Default to User-defined Data Types (Привязка умолчания к определенным пользователем типам данных)


    Рис. 16.8.  Диалоговое окно Bind Default to User-defined Data Types (Привязка умолчания к определенным пользователем типам данных)

  3. Для привязки умолчания к колонке щелкните на пункте Bind Columns (Привязка к колонкам), чтобы появилось диалоговое окно Bind Default to Columns (Привязка умолчания к колонкам). Теперь выберите колонку, с которой хотите связать данное умолчание. Сначала выберите имя таблицы в раскрывающемся списке Table (Таблица). Затем в списке Unbound Columns (Колонки без привязки) выберите имя колонки, с которой хотите связать умолчание. Затем щелкните на кнопке Add (Добавить). На рис. 16.9 показано это диалоговое окно после добавления колонки phone таблицы customer_data к списку Bound Columns (Колонки с привязкой).

     Диалоговое окно Bind Default to Columns (Привязка умолчания к колонкам))


    Рис. 16.9.  Диалоговое окно Bind Default to Columns (Привязка умолчания к колонкам))

  4. Щелкните на кнопке OK, чтобы вернуться в окно Default Properties, и щелкните на кнопке OK еще раз, чтобы закрыть окно Default Properties.

Чтобы отменить привязку Default-объект а к определенному пользователем типу в окне Default Properties, откройте диалоговое окно Bind Default to User-defined Data Types, как это описано выше, и просто сбросьте флажок Bind. Чтобы отменить привязку Default-объект а к колонке, откройте диалоговое окно Bind Default to Columns, выделите имя этой колонки и затем щелкните на кнопке Remove (Удалить).

Чтобы удалить Default-объект, вы должны сначала отменить привязку этого умолчания ко всем другим объектам (как только что было описано). SQL Server возвратит сообщение об ошибке, если вы попытаетесь удалить умолчание, которое привязано к одному или нескольким объектам. Для удаления Default-объект а щелкните на папке Defaults в левой панели Enterprise Manager, щелкните правой кнопкой мыши на имени этого Default-объект а, выберите из контекстного меню пункт Delete и затем щелкните на кнопке Drop All (Удалить все) в появившемся диалоговом окне Drop Objects (Удаление объектов).

Ограничения

Ограничения автоматически обеспечивают целостность данных. Ограничения задают правила, которые определяют значения данных, допустимые для какой-либо колонки. Они позволяют ограничивать значения данных, которые вводятся в колонку, чтобы в этой колонке не оказались неверные значения. Например, с помощью ограничения вы можете ограничить значения колонки целого типа диапазоном от 1 до 100. В результате любые значения вне этого диапазона нельзя будет ввести в данную колонку. (Для создания этого диапазона вы можете использовать ограничение CHECK, как будет показано ниже.) Ограничение только по одной колонке называется ограничением колонки ; оно ограничивает значения только этой колонки. Ограничение, которое влияет на несколько колонок, называется ограничением таблицы, или табличным ограничением; в этом случае комбинация значений для колонок, указанных в данном ограничении, должна отвечать требованиям этого ограничения. Имеется пять типов ограничений: NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY и CHECK.

Создание и модифицирование ограничений с помощью T-SQL

В этом разделе вы узнаете об использовании каждого типа ограничений и реализации ограничений с помощью T-SQL. В следующем разделе вы узнаете, как реализовывать ограничения с помощью Enterprise Manager.

Ограничение NOT NULL

Ограничение NOT NULL является довольно простым, и мы уже видели, как оно использовалось в примерах этой лекции и предыдущих лекций. Ограничение NOT NULL задается в описании колонки, чтобы воспрепятствовать вставке null -значений в эту колонку (в противоположность ограничению NULL, которое разрешает присваивать null -значения). При использовании T-SQL вы можете указать NOT NULL при создании таблицы или позже, когда будете модифицировать какую-либо колонку. (О модифицировании таблиц базы данных см. лекцию 10.) Вам следует использовать NOT NULL вместо NULL там, где это возможно, поскольку операции с null -значениями, такие как сравнения, сопряжены с большей дополнительной нагрузкой при обработке. Как уже говорилось выше в этой лекции, лучше использовать значение по умолчанию там, где это возможно, чем разрешать вставку null -значений.

Ограничение UNIQUE

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

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

Ограничение UNIQUE можно использовать для любой колонки, которая не является частью ограничения PRIMARY KEY (описывается в следующем разделе), которое также обеспечивает уникальность значений. Ограничение UNIQUE можно использовать для колонок, в которых разрешены null -значения, в то время как ограничения PRIMARY KEY нельзя использовать для таких колонок. Null -значения не затрагиваются ограничениями UNIQUE. На колонку с ограничением UNIQUE может ссылаться ограничение FOREIGN KEY (см. раздел "Ограничение FOREIGN KEY" далее). По одной таблице можно задавать несколько ограничений UNIQUE, пока общее число индексов для этой таблицы не превышает 249 некластеризованных и одного кластеризованного индекса.

Чтобы создать ограничение UNIQUE по таблице с помощью T-SQL, используйте оператор CREATE TABLE или ALTER TABLE. Например, следующий оператор создает таблицу customer (покупатель) с ограничением UNIQUE по колонке SSN в виде кластеризованного индекса:

CREATE TABLE customer
(
first_name   		char(20) 	NOT NULL, 
mid_init     		char(1)  	NULL, 
last_name    		char(20) 	NOT NULL, 
SSN          		char(11) 	NOT NULL UNIQUE CLUSTERED, 
cust_phone   		char(10) 	NULL 
) 
GO

В этом операторе CREATE использовано ограничение по колонке. В следующем примере снова создается таблица, но на этот раз с добавлением табличного ограничения UNIQUE с именем UQ_full_name по колонкам first_name, mid_init и last_name:

CREATE TABLE customer
( 
first_name   		char(20) 	NOT NULL, 
mid_init     		char(1)  	NULL, 
last_name    		char(20) 	NOT NULL, 
SSN          		char(11) 	NOT NULL UNIQUE CLUSTERED, 
cust_phone   		char(10) 	NULL, 
CONSTRAINT   	UQ_full_name UNIQUE NONCLUSTERED (first_name,  
    				mid_init, last_name) 
) 
GO

Табличное ограничение UNIQUE (ограничение по более чем одной колонке) обеспечивает уникальность комбинаций значений по соответствующим колонкам. В данном случае в базу данных нельзя ввести двух покупателей, имеющих одинаковое сочетание имени (first_name), фамилии (last_name) и инициала отчества (mid_init). В одной или двух колонках может встретиться одинаковая комбинация, но не во всех трех колонках. Отметим, что в данном случае табличное ограничение UNIQUE является некластеризованным индексом, поскольку у нас уже имеется уникальный кластеризованный индекс по колонке SSN.

Чтобы добавить ограничение UNIQUE к существующей таблице, используйте оператор ALTER TABLE. Если вы пытаетесь модифицировать существующую колонку или колонки, добавляя ограничение UNIQUE, все существующие строки данной таблицы должны содержать уникальные значения или null -значения в этой колонке или колонках, иначе вы получите сообщение об ошибке и ограничение UNIQUE не будет добавлено. Предположим, что мы создали таблицу customer без каких-либо ограничений. Ниже приводятся два оператора для добавления ограничений по колонке и по таблице:

ALTER TABLE customer 
ADD CONSTRAINT UQ_ssn UNIQUE CLUSTERED (SSN) 
GO

ALTER TABLE customer 
ADD CONSTRAINT UQ_full_name UNIQUE NONCLUSTERED (first_name, mid_init, last_name) 
GO

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

Чтобы изменить существующее ограничение UNIQUE по какой-либо колонке или таблице с помощью T-SQL, вы должны сначала удалить соответствующее ограничение и затем снова создать его. Как и для умолчаний, вам следует использовать для ваших ограничений описательные имена, чтобы вы могли легко находить и удалять их без необходимости выяснения имен, присвоенных им системой SQL Server. При изменении ограничения с помощью Enterprise Manager система SQL Server автоматически удаляет старое ограничение и вновь создает его, когда вы сохраняете выполненные изменения (см. раздел "Создание и модифицирование ограничений с помощью Enterprise Manager" далее).

Ограничение PRIMARY KEY

Ограничение PRIMARY KEY используется, чтобы задать первичный ключ таблицы, представляемый колонкой или набором колонок, уникальным образом идентифицирующих строку таблицы. Поскольку первичный ключ идентифицирует строку, соответствующая колонка никогда не содержит значения NULL. В этом состоит отличие ограничения PRIMARY KEY от ограничения UNIQUE, которое допускает null-значения. Если вы определяете ограничение PRIMARY KEY по набору колонок, это ограничение указывает, что комбинация значений этих колонок должна быть уникальной для каждой строки, что аналогично ограничению UNIQUE по набору колонок. И, подобно ограничению UNIQUE, ограничение PRIMARY KEY не допускает дублированных значений. Если ограничение PRIMARY KEY присваивается колонке или набору колонок, то по этой колонке или колонкам первичного ключа автоматически создается уникальный индекс. Вы можете также задать для первичного ключа кластеризованный или некластеризованный индекс; если ничего не задано, по умолчанию создается кластеризованный индекс, если таблица еще не имеет кластеризованного индекса.

Таблица может иметь только одно ограничение PRIMARY KEY. Колонка с атрибутом IDENTITY хорошо подходит для первичного ключа, как и любая другая колонка или набор колонок, являющиеся уникальными для каждой строки. Например, в примере нашей таблицы customer мы могли бы создать колонку SSN как первичный ключ вместо создания для нее ограничения UNIQUE. Ограничение PRIMARY KEY не допускало бы null -значений и обеспечивало бы уникальность значений в колонке SSN, а по этой колонке первичного ключа был бы автоматически создан кластеризованный индекс. Следующий оператор T-SQL представляет один из способов задания колонки SSN как первичного ключа, когда вы определяете таблицу. При этом способе имя ограничению PRIMARY KEY присваивает SQL Server, поэтому он не является предпочтительным методом, так как в дальнейшем вам может потребоваться удаление данного ключа по имени.

CREATE TABLE 	customer
( 
first_name   		char(20) 	NOT NULL, 
mid_init     		char(1)  	NULL, 
last_name    		char(20) 	NOT NULL, 
SSN          		char(11) 	PRIMARY KEY, 
cust_phone   		char(10) 	NULL 
) 
GO

Используя альтернативный способ, вы можете присвоить имя этому ограничению, добавив ключевое слово CONSTRAINT. Чтобы присвоить имя PK_SSN вашему ограничению PRIMARY KEY, используйте следующий оператор:

CREATE TABLE 	customer
( 
first_name   		char(20) 	NOT NULL, 
mid_init     		char(1)  	NULL, 
last_name    		char(20) 	NOT NULL, 
SSN          		char(11) 	CONSTRAINT PK_SSN PRIMARY KEY, 
cust_phone   		char(10) 	NULL 
) 
GO

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

CREATE TABLE 	customer
( 
first_name   		char(20) 	NOT NULL, 
mid_init     		char(1)  	NULL, 
last_name    		char(20) 	NOT NULL, 
SSN          		char(11), 
cust_phone   		char(10) 	NULL, 
CONSTRAINT PK_SSN PRIMARY KEY (SSN) 
) 
GO

Чтобы добавить ограничение PRIMARY KEY к таблице, не имеющей ограничения PRIMARY KEY, используйте оператор ALTER TABLE. Следующий оператор добавляет ограничение PRIMARY KEY к таблице customer:

ALTER TABLE 	customer
ADD CONSTRAINT PK_SSN PRIMARY KEY CLUSTERED (SSN) 
GO

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

Чтобы удалить ограничение PRIMARY KEY, используйте оператор ALTER TABLE с предложением DROP CONSTRAINT. Ниже мы удаляем ограничение по колонке SSN:

ALTER TABLE customer
DROP CONSTRAINT PK_SSN
GO

Отметим, что для предложения DROP CONSTRAINT требуется только имя данного ограничения. Чтобы изменить существующее ограничение PRIMARY KEY по таблице с помощью операторов T-SQL, вы должны сначала удалить существующее ограничение и затем выполнить изменение таблицы, добавив новое ограничение. Это выполняется с помощью операторов ALTER TABLE...DROP CONSTRAINT и ALTER TABLE...ADD CONSTRAINT.

Ограничение FOREIGN KEY

Ограничение FOREIGN KEY определяет внешний ключ который задает связь между двумя таблицами. Колонка или колонки внешнего ключа одной таблицы ссылаются на потенциальный ключ (одна или несколько колонок) в другой таблице. При вставке строки в таблицу с ограничением FOREIGN KEY значения, которые должны быть внесены в колонку или колонки, определенные как внешний ключ, сравниваются со значениями в потенциальном ключе ссылочной таблицы. Если ни одна из строк ссылочной таблицы не соответствует значениям во внешнем ключе, то вставка новой строки не выполняется. Но если значения внешнего ключа, которые нужно внести в таблицу, все же имеются в потенциальном ключе другой таблицы, то вставка новой строки будет выполнена. Если значение, которое должно быть занесено в таблицу с ограничением FOREIGN KEY, равно NULL, то это тоже допустимо.

Проверка ограничений FOREIGN KEY происходит также в тех случаях, когда вы хотите обновить какую-либо строку в ссылочной таблице или в таблице с внешним ключом. Вы не сможете обновить какое-либо значение потенциального ключа или внешнего ключа, если это приведет к нарушению ограничения. Существует одно исключение из этого правила, когда вы обновляете ссылочную таблицу с помощью опции ON UPDATE CASCADE оператора T-SQL CREATE TABLE. (См. раздел "Создание и модифицирование ограничений с помощью Enterprise Manager" далее.) Кроме того, ограничения FOREIGN KEY проверяются, если вы хотите удалить какую-либо строку из ссылочной таблицы. Вы не сможете удалить строку из ссылочной таблицы, если строка какой-либо таблицы с внешним ключом (таблицы, содержащей ограничение FOREIGN KEY ) содержит ссылку на значение в колонке внешнего ключа.

Иными словами, для каждой строки в таблице с внешним ключом должна существовать соответствующая строка в ссылочной таблице, и эту строку нельзя удалить, пока на нее имеется ссылка. Существует также исключение из этого правила: вы можете удалить строку из ссылочной таблицы с помощью опции ON DELETE CASCADE оператора T-SQL CREATE TABLE.(См. раздел "Создание и модифицирование ограничений с помощью Enterprise Manager" далее.)

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

Чтобы получить более ясное представление о внешних ключах, рассмотрим некоторые примеры. Сначала мы создадим таблицу с именем items (товары), которая содержит ограничение PRIMARY KEY по колонке item_id (идентификатор товара), как в следующем операторе:

CREATE TABLE 	items
( 
item_name  		char(15)     	NOT NULL, 
item_id     	smallint     	NOT NULL IDENTITY(1,1), 
price       	smallmoney   	NULL, 
item_desc   	varchar(30)  	NOT NULL DEFAULT 'none', 
CONSTRAINT  	PK_item_id   	PRIMARY KEY (item_id) 
) 
GO

Затем мы создадим таблицу с именем inventory, содержащую ограничение FOREIGN KEY с именем FK_item_id, которое ссылается на колонку item_id в таблице items, как в следующем операторе:

CREATE TABLE 	inventory
( 
store_id        	tinyint    	NOT NULL, 
item_id         	smallint   	NOT NULL,  
item_quantity   	tinyint    	NOT NULL, 
CONSTRAINT      	FK_item_id 	FOREIGN KEY (item_id)  
REFERENCES      	items(item_id) 
) 
GO

Чтобы увидеть, каким образом связаны эти таблицы, мы создадим схему (диаграмму) базы данных (рис. 16.10). (Инструкции по созданию схемы базы данных см. в лекции 15.) В данном примере items – это ссылочная таблица с потенциальным ключом item_id. Это единственно возможный потенциальный ключ, поскольку он является первичным ключом в данной таблице и эта таблица не содержит никаких ограничений UNIQUE. Напомним, что только колонки первичного ключа и колонки с ограничениями UNIQUE является допустимыми потенциальными ключами. Таблица inventory содержит ограничение FOREIGN KEY, определенное по ее колонке item_id. С помощью этого ограничения создается связь по внешнему ключу между этими двумя таблицами. Обе связанные колонки имеют тип данных smallint. Ограничение FOREIGN KEY в таблице inventory по колонке item_id гарантирует, что в колонку item_id нельзя ввести никакое значение, если этого значения нет в колонке item_id таблицы items. Иными словами, если товар отсутствует в таблице items, то он не может присутствовать в таблице inventory. Кроме того, из таблицы items нельзя удалить строку, если на нее имеется ссылка из какой-либо строки в таблице inventory. Иными словами, если какой-либо товар присутствует в таблице items и таблице inventory, этот товар нельзя удалить из таблицы items, пока он присутствует в таблице inventory. Теперь вы, вероятно, поняли, что внешние ключи используются для поддержки согласованности базы данных. Например, в данном случае вам не нужна информация о допустимости какого-либо товара в таблицах, если не существует записи об этом товаре в таблице items, предназначенной для хранения записей по каждому имеющемуся товару.

Схема базы данных, где показана связь по внешнему ключу между таблицами items и inventory


увеличить изображение

Рис. 16.10.  Схема базы данных, где показана связь по внешнему ключу между таблицами items и inventory

Чтобы модифицировать ограничение FOREIGN KEY с помощью операторов T-SQL, вы должны сначала удалить старое ограничение и затем создать новое с помощью оператора ALTER TABLE. Этот метод действует аналогично модифицированию ограничения PRIMARY KEY. Ниже приводятся операторы для удаления исходного ограничения по таблице inventory и последующего добавления нового ограничения:

ALTER TABLE inventory
DROP CONSTRAINT FK_item_id 
GO 

ALTER TABLE inventory 
ADD CONSTRAINT FK_item_id FOREIGN KEY (item_id)  
REFERENCES items(item_id) 
GO

Если вы добавляете ограничение FOREIGN KEY к существующей колонке таблицы, SQL Server проверяет существующие строки таблицы, чтобы убедиться в том, что для значений этой колонки (за исключением null -значений) имеются соответствующие значения в колонке с ограничением PRIMARY KEY или UNIQUE ссылочной таблицы. Чтобы создать ограничение FOREIGN KEY без проверки системой SQL Server совпадения с существующими значениями, вы должны использовать опцию WITH NOCHECK оператора ALTER TABLE, как это показано ниже:

ALTER TABLE inventory
WITH NOCHECK ADD CONSTRAINT FK_item_id  
FOREIGN KEY (item_id) 
REFERENCES items(item_id) 
GO

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

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

Вы можете также активизировать или отключать использование ограничения FOREIGN KEY. Если вы хотите ввести строку, которая не согласуется с существующим ограничением, то можете временно отключить это ограничение, ввести строку и затем снова активизировать ограничение. Ключевое слово NOCHECK указывает, что данное ограничение следует игнорировать (отключить), а ключевое слово CHECK указывает, что ограничение следует активизировать. Следующие операторы выполняют отключение и повторную активизацию ограничения FOREIGN KEY с помощью ключевых слов NOCHECK и CHECK:

ALTER TABLE inventory
NOCHECK CONSTRAINT FK_item_id    	--Отключает ограничение
GO

—Здесь должен быть оператор INSERT
GO

ALTER TABLE inventory          
CHECK CONSTRAINT FK_item_id      	--Повторно активизирует ограничение
GO
Внимание. Вам не следует выполнять вставку строки данных, не согласующейся с ограничением FOREIGN KEY, если это не является крайней необходимостью. Если вы все же сделаете это, то, возможно, не сможете выполнять дальнейшие обновления.
Ограничение CHECK

Ограничение CHECK используется, чтобы ограничить множество допустимых для колонки значений определенными значениями. Значения, которые используются при вставке в колонку или обновлении колонки, проверяются на истинность (значение TRUE ) указанного в ограничении булева условия поиска. Например, если бы нам нужно было ограничить диапазон возможных значений, допустимых для колонки price (цена) таблицы items, величинами от $0,01 до $500,00, то мы использовали бы следующий оператор:

CREATE TABLE items
( 
item_name   		char(15)    	NOT NULL, 
item_id     		smallint    	NOT NULL IDENTITY(1,1), 
price       		smallmoney  	NULL, 
item_desc   		varchar(30) 	NOT NULL DEFAULT 'none', 
CONSTRAINT  	PK_item_id  	PRIMARY KEY (item_id), 
CONSTRAINT  	CK_price    	CHECK (price >= .01 AND  
    						price <= 500.00) 
) 
GO

Отметим, что мы разрешили использование значений NULL в колонке price и задали ограничение CHECK по этой колонке. Поскольку SQL Server может отличить null -значение от любого другого типа значений, в колонке price, несмотря на ограничение CHECK, разрешены значения NULL. Кроме того, отметим, что мы присвоили этому ограничению имя CK_price. Как мы уже видели, присваивание имени ограничению упрощает последующее удаление и повторное создание этого ограничения по имени с помощью T-SQL. Например, чтобы изменить множество допустимых значений на диапазон от $1,00 до $1000,00, используйте следующий оператор:

ALTER TABLE items
DROP CONSTRAINT CK_price 
GO 
 
ALTER TABLE items 
ADD CONSTRAINT CK_price CHECK (price >= 1.00 AND  
    	 price <= 1000.00) 
GO

Второй оператор ALTER TABLE имел бы такой же вид, если бы вы добавляли это ограничение к существующей таблице items в первый раз. При добавлении ограничения CHECK к существующей таблице применяются те же правила, что и при добавлении ограничения FOREIGN KEY. Существующие строки будут проверяться на соответствие этому ограничению. Если не все строки дают при проверке значение TRUE, то ограничение не добавляется к таблице и SQL Server возвращает сообщение об ошибке, информирующее, что оператор ALTER TABLE создает конфликтную ситуацию из-за ограничения CHECK. Если вы все же должны добавить это ограничение, используйте опцию WITH NOCHECK, чтобы указать, что должны проверяться только последующие обновления и добавляемые строки, но не существующие строки.

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

Вот пример использования WITH NOCHECK при добавлении ограничения CK_price:

ALTER TABLE items
WITH NOCHECK ADD CONSTRAINT CK_price  
CHECK (price >= 1.00 AND price <= 1000.00) 
GO

Вы можете также активизировать и отключать ограничение CHECK (как и ограничение FOREIGN KEY ) с помощью ключевых слов CHECK и NOCHECK, используемых с командой ALTER TABLE. Вам может потребоваться этот метод, например, для вставки цены, выходящей за указанный диапазон. В следующем примере выполняется отключение и последующая повторная активизация ограничения CHECK с именем CK_price:

ALTER TABLE items
NOCHECK CONSTRAINT CK_price    	--Отключает ограничение     
GO 
 
--Здесь должен быть оператор INSERT
GO 

ALTER TABLE items
CHECK CONSTRAINT CK_price      	--Повторно активизирует ограничение
GO
Примечание. CHECK и FOREIGN KEY – это единственные типы ограничений, которые можно отключать и активизировать таким способом.
Создание и модифицирование ограничений с помощью Enterprise Manager

В этом разделе вы узнаете, как создавать, модифицировать и удалять ограничения в Enterprise Manager с помощью окна Design Table и (в случае ограничений FOREIGN KEY ) с помощью схемы базы данных. (Инструкции по созданию схемы базы данных см. в лекции 15.) Окно Design Table появляется, когда вы создаете или редактируете таблицу с помощью Enterprise Manager. Чтобы создать таблицу, раскройте в левой панели Enterprise Manager папку сервера и папку базы данных, щелкните правой кнопкой мыши на папке Tables (Таблицы) и затем выберите из контекстного меню пункт New Table (Создать таблицу). Чтобы появилось окно Design Table для какой-либо существующей таблицы, сначала щелкните на папке Tables, щелкните правой кнопкой мыши на имени этой таблицы в правой панели и затем выберите из контекстного меню пункт Design Table.

Разрешение использовать null-значения

Чтобы указать, можно или нельзя использовать null -значения в какой-либо колонке, просто установите или сбросьте соответствующий флажок в колонке Allow Nulls (Разрешить null -значения) окна Design Table. Вы можете задать этот параметр при создании таблицы или при ее модифицировании. (Правила для разрешения null -значений см. в лекции 10.) На рис. 16.11 показано окно Design Table для таблицы customer (см. раздел "Создание и модифицирование ограничений с помощью T-SQL" выше в этой лекции). Как видно из рисунка, null -значения допускаются в колонках mid_init и cust_phone, но в остальных трех колонках не допускаются.

Окно Design Table для таблицы customer с установленными флажками в столбце Allow Nulls.


увеличить изображение

Рис. 16.11.  Окно Design Table для таблицы customer с установленными флажками в столбце Allow Nulls.

Ограничение UNIQUE

Чтобы создать или модифицировать ограничение UNIQUE с помощью Enterprise Manager, выполните следующие шаги:

  1. В панели инструментов окна Design Table щелкните на кнопке Table аnd Index Properties (Свойства таблицы и индексов) (кнопка справа от кнопки Save) и затем щелкните на вкладке Indexes/Keys (Индексы/Ключи) в появившемся окне Properties (Свойства). На рис. 16.12 показана вкладка Indexes/Keys окна Properties для таблицы customer. В этой вкладке будут представлены любые ограничения UNIQUE, поскольку они реализуются в виде уникальных индексов.

    Данная таблица создана с помощью следующего оператора, содержащего ограничение UNIQUE в виде кластеризованного индекса по колонке SSN. (SQL Server автоматически присвоил этому индексу имя UQ_customer_398D8EEE; именно поэтому удобнее присваивать ваши собственные имена ограничениям и индексам.)

    CREATE TABLE customer
    (
    first_name   		char(20) 	NOT NULL, 
    mid_init     		char(1)  	NULL, 
    last_name    		char(20) 	NOT NULL, 
    SSN          		char(11) 	NOT NULL UNIQUE CLUSTERED, 
    cust_phone   		char(10) 	NULL 
    ) 
    GO

    Вкладка Indexes/Keys окна Properties для таблицы customer


    Рис. 16.12.  Вкладка Indexes/Keys окна Properties для таблицы customer

  2. Создание нового ограничения UNIQUE начните со щелчка на кнопке New (Создать) вкладки Indexes/Keys окна Properties. Выберите имена колонок, которые хотите включить в ограничение, введите имя этого нового ограничения и затем установите флажок Create UNIQUE (Создать ограничение UNIQUE ). Установите флажок Create As CLUSTERED (Создать как кластеризованный индекс), если вы хотите, чтобы это был кластеризованный индекс по данной таблице, и задайте, если хотите, коэффициент заполнения (поле Fill factor). Если вы не хотите, чтобы SQL Server автоматически пересчитывал статистику по этому индексу через определенные периоды, установите также флажок Don’t automatically recompute statistics.
  3. Вы можете использовать окно Properties для модифицирования ограничения UNIQUE ; например, вы можете изменять имя ограничения, указывать колонки, к которым присоединяется это ограничение, задавать ограничение как кластеризованный индекс и выбирать коэффициент заполнения для индекса. (О коэффициенте заполнения см. лекцию 17.) Внесите в это ограничение нужные вам изменения. По окончании щелкните на кнопке Close (Закрыть) и затем щелкните на кнопке Save в окне Design Table для сохранения ваших изменений.>
Ограничение PRIMARY KEY

Вы можете задать ограничение PRIMARY KEY по одной колонке или по нескольким колонкам. Эта колонка или колонки должны уникальным образом идентифицировать каждую строку таблицы. Чтобы задать ограничение PRIMARY KEY, выполните следующие шаги:

  1. В окне Design Table выберите колонку, щелкнув на одной из ячеек в ее строке. (Вы можете выбрать несколько колонок, удерживая клавишу Ctrl и щелкая на серых ячейках слева от имен колонок.)
  2. Щелкните правой кнопкой мыши на одной из выбранных колонок и выберите из контекстного меню пункт Set Primary Key (Задать первичный ключ). Слева от колонок, которые вы задали для первичного ключа, появится изображение небольшого ключа. На рис. 16.13 показано окно Design Table для таблицы customer после указания колонки SSN как первичного ключа. Кроме того, из колонки SSN было удалено ограничение UNIQUE путем удаления уникального индекса, поскольку нет необходимости одновременно иметь ограничение UNIQUE и ограничение PRIMARY KEY по одной колонке.

     Задание ограничения PRIMARY KEY в окне Design Table


    увеличить изображение

    Рис. 16.13.  Задание ограничения PRIMARY KEY в окне Design Table

  3. Если вам нужно переместить ограничение PRIMARY KEY в другую колонку, просто задайте эту новую колонку как первичный ключ. От вас не требуется удалить сначала явным образом исходный первичный ключ – SQL Server удалит и снова создаст для вас индекс PRIMARY KEY. Вы можете также модифицировать индекс PRIMARY KEY в окне Properties. И снова напомним, что ваши изменения начнут действовать после того, как вы сохраните вашу работу, щелкнув на кнопке Save в панели инструментов.
    Примечание. Если вы изменили ограничение PRIMARY KEY по таблице, уже содержащей данные, то повторное создание индекса может занять некоторое время. Если ваша таблица содержит много данных и вы задали существенное изменение по данному индексу, такое как изменение колонок индекса или кластеризованности, то вам следует по возможности выполнять этот вид изменений в периоды незначительного использования базы данных.
Ограничение FOREIGN KEY

Чтобы создать или модифицировать ограничение FOREIGN KEY с помощью Enterprise Manager, вы можете использовать окно Design Table или создать схему базы данных с таблицами, которые будут включены в связь по внешнему ключу. Лучше всего создавать связи по внешнему ключу во время создания таблиц (или хотя бы до того, как начнется вставка данных в таблицы). Причину этого вы узнаете из следующего примера. Сначала мы рассмотрим, как использовать окно Design Table для создания ограничения FOREIGN KEY. Мы создадим связь по внешнему ключу между двумя таблицами, описанными выше в этой лекции, – items и inventory. Мы повторно создадим таблицу items с ограничением PRIMARY KEY (которое использовали раньше), но без свойства IDENTITY по колонке item_id, так как будем работать с примером, где происходит обновление этой колонки, а вы не сможете обновлять колонку со свойством IDENTITY без выполнения некоторой дополнительной работы. Кроме того, мы повторно создадим таблицу inventory без ограничения FOREIGN KEY, чтобы его можно было добавить позже. Ниже приводятся операторы CREATE TABLE, используемые для обеих таблиц:

CREATE TABLE items
( 
item_name   		char(15)     	NOT NULL, 
item_id     		smallint     	NOT NULL, 
price       		smallmoney   	NULL, 
item_desc   		varchar(30)  	NOT NULL DEFAULT 'none', 
CONSTRAINT  	PK_item_id   	PRIMARY KEY (item_id) 
) 
GO

CREATE TABLE 	inventory 
( 
store_id        		tinyint    	NOT NULL, 
item_id         		smallint   	NOT NULL,  
item_quantity   		tinyint    	NOT NULL 
) 
GO

Чтобы добавить ограничение FOREIGN KEY по таблице inventory, выполните следующие шаги:

  1. Щелкните правой кнопкой мыши на имени таблицы inventory в правой панели Enterprise Manager и выберите пункт Design Table. Щелкните правой кнопкой мыши на свободном месте этого окна и выберите из контекстного меню пункт Relationships (Связи). Появится окно Properties с открытой вкладкой Relationships (рис. 16.14).
  2. Щелкните на кнопке New. Появится данные по умолчанию (рис. 16.15).
  3. Мы выбираем для таблицы первичного ключа таблицу items (вместо customer) и колонку item_id для связи по внешнему ключу между таблицами items и inventory. Для этого просто щелкните на одной из пустых строк под именами таблиц, и в спускающемся меню появится список выбора допустимых колонок. После того как выбраны соответствующие таблицы для связи, имя в поле Relationship Name (Имя связи) изменится (рис. 16.16).

    Вкладка Relationships (Связи) окна Properties (Свойства)  для таблицы inventory


    Рис. 16.14.  Вкладка Relationships (Связи) окна Properties (Свойства) для таблицы inventory

     Вкладка Relationships (Связи) с данными по умолчанию  после щелчка на кнопке New (Создать)


    Рис. 16.15.  Вкладка Relationships (Связи) с данными по умолчанию после щелчка на кнопке New (Создать)

    Вкладка Relationships, где показана связь по внешнему ключу между таблицами items и inventory


    Рис. 16.16.  Вкладка Relationships, где показана связь по внешнему ключу между таблицами items и inventory

  4. Внизу этого окна имеется несколько флажков (рис. 16.17). Установите флажок Check existing data on creation (Проверять существующие данные при создании), если вы хотите, чтобы SQL Server проверял существующие данные на связь по внешнему ключу. Если данные не согласуются, то ограничение не будет создано. Сбросьте этот флажок только в тех случаях, когда у вас еще нет данных или вы знаете, что существующие данные уже согласованы с этим ограничением, или вы не хотите по какой-либо причине, чтобы существующие данные были согласованы с ограничением. Но это может вызвать проблемы, если вы попытаетесь в дальнейшем обновить или удалить одну из существующих строк.
  5. Следующий флажок – это Enable relationship for replication (Активизировать связь для репликации). Не устанавливайте его, если вы не используете репликацию. Но даже если вы используете репликацию, вам все же не нужно устанавливать этот флажок, поскольку данные будут проверяться на согласованность с данным ограничением уже в исходных таблицах, поэтому их не обязательно проверять при репликации. Если вы все же активизировали связь для репликации и если расписания репликации этих двух таблиц не синхронизированы в достаточной степени, то вы получите ошибки во время репликации, указывающие, что какая-либо строка не может быть реплицирована, поскольку в ней нарушено ограничение по внешнему ключу.
  6. Следующий флажок – это Enable relationship for INSERT and UPDATE (Активизировать связь для операций INSERT и UPDATE). Установка этого флажка означает, что ограничение FOREIGN KEY будет проверяться при вставках и обновлениях, а также при удалениях. Если это является вашим намерением, установите данный флажок. Станут доступны два находящихся ниже флажка. Это флажки Cascade Update Related Fields (Каскадировать связанные с обновлением поля) и Cascade Delete Related Records (Каскадировать связанные с удалением записи). (Записью называется строка данных.)

    Вкладка Relationships, где показаны установленные флажки


    Рис. 16.17.  Вкладка Relationships, где показаны установленные флажки

  7. Установка флажка Cascade Update Related Fields означает, что если вы обновляете ссылочную колонку ссылочной таблицы (например, обновляете значение колонки item_id в таблице items ), то это обновление будет каскадироваться в таблицу с внешним ключом. (В данном случае – то же самое значение колонки item_id будет обновлено, если оно имеется в таблице inventory.) Будет обновлено только значение данной колонки; остальная информация строки в таблице с внешним ключом останется без изменений. Установка этого флажка позволяет также выполнять обновление ссылочной колонки. Если вы не установите этот флажок, то система не позволит вам выполнить обновление ссылочной колонки, если она существует в таблице с внешним ключом. Вы получите от SQL Server сообщение об ошибке, аналогичное следующему: "UPDATE statement conflicted with COLUMN REFERENCE constraint "FK_inventory_items". The conflict occurred in database "MyDB", table "inventory", column "item_id". The statement has been terminated."

    (Конфликт оператора UPDATE с ограничением COLUMN REFERENCE "FK_inventory_items". Конфликт возник в базе данных "MyDB", таблица "inventory", колонка "item_id". Работа оператора прекращена.)

  8. Установка флажка Cascade Delete Related Records означает, что удаление из ссылочной таблицы будет каскадироваться в таблицу с внешним ключом. Например, если удаляется строка в таблице items, а строка в таблице inventory имеет в колонке item_id то же значение, что и удаленная строка, то эта строка также будет удалена из таблицы inventory. Это позволяет поддерживать согласованность вашей информации. Если вы не установите этот флажок, то система не позволит вам удалить строку из ссылочной таблицы, если на нее имеется ссылка в строке таблицы с внешним ключом. Вы получите сообщение об ошибке от SQL Server, аналогичное следующему: "DELETE statement conflicted with COLUMN REFERENCE constraint "FK_inventory_items". The conflict occurred in database "MyDB", table "inventory", column "item_id". The statement has been terminated."

    (Конфликт оператора DELETE с ограничением COLUMN REFERENCE "FK_inventory_items". Конфликт возник в базе данных "MyDB", таблица "inventory", колонка "item_id". Работа оператора прекращена.)

  9. После установки флажков щелкните на кнопке Close и затем щелкните на кнопке Save в окне Design Table для сохранения ваших изменений. Появится другое окно, информирующее, что перечисленные таблицы будут сохранены в вашей базе данных; в список входят две таблицы, связанные по внешнему ключу. Для завершения щелкните на кнопке Yes. Затем вы можете закрыть окно Design Table, щелкнув на кнопке Close в верхнем правом углу этого окна (но не окна Enterprise Manager, иначе вы закроете Enterprise Manager).

Существует другой метод, который можно использовать для создания или модифицирования ограничения FOREIGN KEY: использование схемы базы данных. Чтобы изучить создание и модифицирование ограничения FOREIGN KEY с помощью схемы базы данных, мы сформируем схему, используя те же две таблицы, что и в предыдущем примере: items и inventory. Сначала мы рассмотрим схему базы данных с этими таблицами без связи по внешнему ключу и затем добавим внешний ключ. Начальная схема базы данных показана на рис. 16.18).

 Схема базы данных для таблиц items и inventory


Рис. 16.18.  Схема базы данных для таблиц items и inventory

Колонка item_id в таблице items – это колонка с первичным ключом (рис. 16.18). Это единственный "кандидат" для ссылки по внешнему ключу, так как для таблицы items не задано никаких ограничений UNIQUE. Чтобы создать связь по внешнему ключу между колонкой item_id таблицы inventory и колонкой item_id таблицы items, выполните следующие шаги.

  1. Щелкните на крайней левой ячейке (серый квадрат) строки для колонки item_id таблицы items и, удерживая кнопку мыши, перетащите курсор мыши на таблицу inventory. (Вы увидите пунктирную линию, сопровождающую курсор.) Отпустите кнопку мыши, когда окажетесь на строке для колонки item_id таблицы inventory. Появится диалоговое окно Create Relationship (Создать связь), показанное на рис. 16.19. Оно устроено аналогично окну Properties (окна Design Table), которое было показано выше. Колонка item_id появится в столбце каждой таблицы этого диалогового окна, указывая, что связь по внешнему ключу будет задана между двумя колонками item_id.

    В Диалоговое окно Create Relationship (Создать связь), где показана предложенная связь по внешнему ключу


    Рис. 16.19.  В Диалоговое окно Create Relationship (Создать связь), где показана предложенная связь по внешнему ключу

  2. Если нужно, вы можете изменить имя этой связи. Установите или сбросьте флажки внизу этого диалогового окна, чтобы выбрать нужные вам опции. Эти флажки были описаны выше в этой лекции.
  3. По окончании щелкните на кнопке OK, чтобы создать в схеме связь между таблицами (рис. 16.20). (Она еще не сохранена.) Линия с изображением ключа направлена от таблицы с внешним ключом к ссылочной таблице.

      Схема базы данных, где показана связь по внешнему ключу


    Рис. 16.20.  Схема базы данных, где показана связь по внешнему ключу

  4. Щелкните на кнопке Save, чтобы сохранить ваши изменения. У вас будет запрошено имя схемы базы данных, и затем нужно будет подтвердить внесение изменений в соответствующие таблицы. Для завершения щелкните на кнопке Yes.

Чтобы модифицировать ограничение FOREIGN KEY, вы можете использовать аналогичным образом оба метода, описанных в данном разделе. В окне Design Table снова откройте вкладку Relationships, внесите изменения и сохраните свою работу. В схеме базы данных щелкните правой кнопкой мыши на линии связи по внешнему ключу и выберите пункт Properties для внесения изменений в соответствующее ограничение или выберите пункт Delete Relationship From Database (Удалить связь из базы данных), чтобы полностью удалить это ограничение. Если нужно, вы можете затем создать новое ограничение.

Ограничение CHECK

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

  1. Щелкните правой кнопкой мыши на окне Design Table и выберите из контекстного меню пункт Properties, чтобы появилось окно Properties. Щелкните на вкладке Check Constraints (Ограничения Check) (рис. 16.21) и щелкните на кнопке New для таблицы items.

     Вкладка Check Constraints (Ограничения Check) окна Properties


    Рис. 16.21.  Вкладка Check Constraints (Ограничения Check) окна Properties

  2. Далее введите выражение, которое хотите использовать для проверки данных, которые будут вводиться или обновляться. В нашем примере мы добавим ограничение CHECK по колонке price таблицы items, чтобы можно было помещать значения только от $1,00 до $1000,00 (рис. 16.22).
  3. Обратите внимание на три флажка внизу этого окна. Установка флажка Check existing data on creation означает, что существующие данные таблицы будут проверяться на соответствие ограничению CHECK и если они не согласуются, то ограничение не будет создано. Установка флажка Enforce constraint for replication (Проверять ограничение для репликации) означает, что данное ограничение будет проверяться при репликации данных. Данные проверяются перед тем, как они попадут в исходную таблицу, т.е. установка этого флажка означает, что во время репликации будет выполняться повторная (т.е. ненужная) проверка данных. Установка флажка Enforce constraint for INSERTs and UPDATEs (ограничение для INSERT и UPDATE ) просто означает, что ограничение CHECK будет активизировано. Если не установить этот флажок, то данное ограничение будет создано, но оно не будет активизировано, т.е. не будет оказывать никакого влияния.

      Добавление ограничения CHECK по колонке price таблицы items


    Рис. 16.22.  Добавление ограничения CHECK по колонке price таблицы items

  4. Щелкните на кнопке Close и затем щелкните на кнопке Save, чтобы сохранить новое ограничение. Чтобы модифицировать ограничение CHECK, используйте вкладку Check Constraint для изменения имени (Constraint name), выражения (Constraint expression) и флажков. На рис. 16.23 ограничение CHECK по колонке price изменено, с диапазона от $1,00 до $1000,00 на диапазон от $1,00 до $99,00.

Отметим, флажок Check existing data on creation теперь сброшен, поскольку ограничение уже было создано. Если вы хотите проверить существующие данные на соответствие модифицированному диапазону, установите этот флажок. Если эта проверка не проходит для существующих данных, то вы получите сообщение об ошибке и ограничение не будет модифицировано.

Вы можете также использовать вкладку Check Constraints для удаления ограничения CHECK, выбрав в списке Selected Constraint (Выбранное ограничение) имя ограничения, которое хотите удалить, и щелкнув на кнопке Delete.

  Модифицирование ограничения CHECK


Рис. 16.23.  Модифицирование ограничения CHECK

Объекты типа Rule

Альтернативой использованию ограничения CHECK является создание объекта типа Rule (Rule-объекта) для ограничения значений, которые можно поместить или изменить в колонке. Rule-объект аналогичен Default-объекту в том, что он создается отдельно от таблицы и не удаляется при удалении таблицы. Вы должны также выполнить привязку Rule-объекта к колонке или к определенному пользователем типу – в данном случае – с помощью системной хранимой процедуры sp_bindrule. И, подобно Default-объекту, Rule-объекты включены в SQL Server 2000 для обратной совместимости с предыдущими версиями. Использование ограничения CHECK является предпочтительным методом ограничения значений колонок, но Rule-объекты полезно использовать, когда одно правило нужно использовать для нескольких колонок или определенных пользователем типов.

Создание Rule-объекта с помощью T-SQL

В качестве примера мы создадим Rule-объект, который выполняет ту же функцию, что и ограничение CHECK, которое мы создали выше. Наше правило использует имя переменной @price для ссылки на колонку price таблицы items. Имя переменной должно начинаться с символа "@", а имя можете выбрать произвольно. Сначала мы создадим данное правило и затем выполним его привязку к колонке, как это показано ниже:

USE MyDB
GO 
CREATE RULE price_rule AS 
(@price >= .01 AND @price <= 500.00) 
GO 
sp_bindrule 'price_rule', 'items.price', 'futureonly' 
GO

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

sp_unbindrule 'items.price'
GO 
DROP RULE price_rule 
GO

Для процедур sp_bindrule и sp_unbindrule указываются те же параметры, что и для процедур sp_bindefault и sp_unbindefault (см. раздел "Оператор CREATE DEFAULT и процедура sp_bindefault" выше в этой лекции). Каждая колонка или определенный пользователем тип может иметь только одно правило, хотя вы можете одновременно присвоить одной колонке или определенному пользователем типу правило и одно или несколько ограничений CHECK. Если вы сделаете это, SQL Server будет применять правило и все ограничения к данным таблицы при их вставке или обновлении.

Создание Rule-объекта с помощью Enterprise Manager

Чтобы использовать Enterprise Manager для создания и привязки Rule-объекта, выполните следующие шаги.

  1. Раскройте имя сервера и имя базы данных в Enterprise Manager. Щелкните правой кнопкой мыши на Rules (Правила) и затем выберите из контекстного меню пункт New Rule (Создать правило), чтобы появилось окно Rule Properties (Свойства правила). В данном примере мы зададим имя правила price_rule и добавим текст (рис. 16.24). Щелкните на кнопке OK, чтобы создать данный Rule-объект.

      Окно Rule Properties (Свойства правила) для создания правила


    Рис. 16.24.  Окно Rule Properties (Свойства правила) для создания правила

  2. Для привязки правила щелкните на Rules в левой панели Enterprise Manager, щелкните правой кнопкой мыши на новом правиле и затем выберите из контекстного меню пункт Properties, чтобы появилось окно Rule Properties. Как и в случае привязки Default-объектов, щелкните на кнопке Bind UDTs для привязки данного правила к определенному пользователем типу или щелкните на Bind Columns для привязки данного правила к колонке или к колонкам. В данном примере мы щелкнем на кнопке Bind Columns и выберем колонку price таблицы items для привязки к ней правила (рис. 16.25).

      Привязка правила к колонке


    Рис. 16.25.  Привязка правила к колонке

  3. Щелкните на кнопке OK, чтобы применить ваше правило, и затем снова щелкните на кнопке OK, чтобы закрыть окно Rule Properties

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

Заключение

В этой лекции вы узнали об умолчаниях и пяти типах ограничений, которые можно задать по колонке или таблице; вы также узнали, как создавать и модифицировать умолчания и ограничения с помощью T-SQL и Enterprise Manager. Кроме того, узнали, как создавать и модифицировать умолчания и правила с помощью Default-объектов и Rule-объектов. Умолчания позволяют задавать для колонки значение по умолчанию, когда не задано конкретное значение. Ограничения можно использовать различными способами для обеспечения целостности данных в вашей базе данных. Умолчания и ограничения является полезными средствами, если они продуманно применяются к вашим таблицам базы данных. В лекции 17 мы рассмотрим использование индексов в SQL Server, включая кластеризованные и некластеризованные индексы. Использование индексов может в огромной степени увеличить эффективность доступа к данным.

Лекция 17. Создание и использование индексов

Чем больше становится ваша база данных, тем, вероятнее всего, возрастает количество и сложность запросов. Для повышения эффективности производительности запросов путем снижения количества операций ввода-вывода используются индексы. Некоторые аспекты из теории программирования необходимо знать для лучшего усвоения материала. Рассматриваются простые и составные индексы, их отличие и применение. Проводится обзор мастеров: Create Index Wizard и Full-Text Indexing Wizard. И, конечно же, использованию T-SQL уделено немало разделов.

Индексы – одно из самых мощных средств, доступных разработчику базы данных. Индекс – это вспомогательная структура, позволяющая вам повышать производительность запросов за счет снижения количества операций ввода-вывода, необходимых для поиска запрошенных данных; т.е. индекс позволяет системе Microsoft SQL Server 2000 находить данные, используя меньшее число операций ввода-вывода, чем при поиске данных путем доступа только к таблице базы данных. Если для поиска строки данных вы используете индекс таблицы базы данных, SQL Server может быстро определить, где хранятся эти данные и сразу считать эти данные. Таким образом, индексы таблиц базы данных во многом похожи на индексы (алфавитные указатели) в книгах: в обоих случаях обеспечивается быстрый доступ к большим объемам информации.

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

Что такое индекс?

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

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

Индекс базы данных организован в виде структуры B-дерева. Каждая страница индекса называется индексной страницей, или узлом индекса. Структура индекса начинается на верхнем уровне с корневого узла. Корневой узел соответствует началу индекса: это первые данные, к которым осуществляется доступ при поиске данных. Корневой узел содержит ряд строк индекса. Эти строки содержат значение ключа и указатель на определенную индексную страницу (которая называется узлом-ветвью) (рис. 17.1). Эта конфигурация необходима, поскольку в случае таблицы данных среднего масштаба индекс состоит из тысяч или миллионов индексных страниц. Начав поиск с корневого узла и перемещаясь по узлам индекса, SQL Server может постепенно "приближаться" к нужным вам данным.

Если использовать в качестве аналога книгу, то индекс действует следующим образом: предположим, что началом индекса (алфавитного указателя) является страница, где указаны номера страниц для статей индекса на букву "a", "b", "c" и т.д. Затем предположим, что эти страницы содержат номера страниц для статей в диапазонах aa-ab, Ас-ad, ae-af и т.д., а соответствующие страницы – номера страниц для записей в диапазонах aaa-aab, aАс-aad, aae-aaf и т.д. При подобной организации вы можете быстро найти то, что вам нужно, с использованием относительно небольшого количества операций поиска. Такая структура аналогична индексу таблицы базы данных, когда первой страницей является корневой узел.

Корневой узел и узлы-ветви


Рис. 17.1.  Корневой узел и узлы-ветви

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

 Дерево поиска с узлами-ветвями и узлами-листьями


Рис. 17.2.  Дерево поиска с узлами-ветвями и узлами-листьями

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

  Уровни индекса


Рис. 17.3.  Уровни индекса

В некластеризованном индексе узел-лист содержит значение ключа, а также идентификатор строки (Row ID), указывающий нужную строку в таблице, или ключ кластеризованного индекса, если имеется также кластеризованный индекс по этой таблице. А в кластеризованном индексе в узле-листе находятся сами данные. (О кластеризованных и некластеризованных индексах см. раздел "Типы индексов" далее.) Количество строк в узле-листе зависит от размера индексных записей, а в случае кластеризованного индекса – от размера данных.

Примечание. Row ID – это указатель, который автоматически формируется системой SQL Server из идентификатора файла (File ID), номера страницы и номера строки данных. Используя Row ID, вы можете считывать данные с помощью всего лишь одной дополнительной операции ввода-вывода. Поскольку вы знаете, какую страницу нужно считывать, а SQL Server "знает", где эта страница находится, то она считывается в память с помощью единственного запроса ввода-вывода. Именно простота этого процесса определяет эффективность использования индексов для считывания данных и обеспечивает столь значительное повышение производительности.

Имейте в виду, что, поскольку индекс создается в отсортированном порядке, любые изменения в данных могут приводить к дополнительной нагрузке на систему. Например, если вставка приводит к созданию новой строки индекса, которую нужно поместить в узел-лист, который уже заполнен до конца, то SQL Server должен создать место для новой строки индекса. Он выполняет эту задачу, перемещая приблизительно половину строк узла-листа на другую страницу. Это перемещение данных называется расщеплением страницы. Расщепление страницы на одном уровне дерева может приводить к каскадным расщеплениям на более высоких уровнях. Расщепления страниц можно избежать путем соответствующей настройки коэффициента заполнения. (См. раздел "Использование коэффициента заполнения для предупреждения расщеплений страниц" далее.)

Понятия индексирования

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

Индексные ключи

Индексным ключом называется колонка или колонки, которые используются для формирования индекса. Индексный ключ – это значение, позволяющее быстро находить строку, содержащую нужные вам данные (подобно статье индекса [алфавитного указателя] в книге, указывающей определенную тему в тексте). Для доступа к данным строки через индекс вы должны включить значение или значения индексного ключа в предложение WHERE нужного оператора SQL. Способ выполнения этого процесса зависит от того, какой это индекс – простой или составной.

Простые индексы

Простой индекс определяется только по одной колонке таблицы (рис. 17.4). Чтобы индекс использовался оператором SQL, ссылка на эту колонку должна быть включена в предложение WHERE данного оператора.

  Простой индекс


Рис. 17.4.  Простой индекс

В зависимости от типа сохраняемых данных, количества уникальных элементов в колонке и типа используемых операторов SQL простой индекс может оказаться весьма эффективен. В других случаях необходим составной индекс. Например, если вы строите индекс для адресной книги с тысячами имен и адресов, то колонка state (штат) не слишком подходит для простого индекса, поскольку для каждого штата будет много записей. Однако, добавив к индексу колонки street (улица) и city (город), вы делаете его составным индексом, после чего почти каждая запись становится уникальной. Это может оказаться полезным, если у вас используются запросы поиска строк в соответствии с адресом.

Составные индексы

Составной индекс – это индекс, определенный более чем по одной колонке (рис. 17.5). Доступ к составному индексу может осуществляться с помощью одного или нескольких индексных ключей. В рамках SQL Server 2000 индекс может содержать до 16 колонок, и колонки ключей могут иметь длину до 900 байтов.

  Составной индекс


Рис. 17.5.  Составной индекс

Для запросов, включающих составной индекс, вам не требуется помещать все индексные ключи в предложение WHERE оператора SQL, но имеет смысл использовать более одного ключа. Например, если индекс создается по колонкам a, b и c какой-либо таблицы, то доступ к этому индексу можно осуществлять с помощью оператора SELECT, содержащего выражение ( a АND b АND c ), или ( a АND b ), или a. Конечно, использование более ограничивающего предложения WHERE, содержащего, например, выражение a АND b АND c, обеспечит более высокую производительность. Скорее всего, из базы данных будет считано меньшее количество строк, поскольку строки будет указаны более точно. Если использовать a АND b или просто a, то будет инициировано сканирование индекса.

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

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

Таблица местоположения заказчиков

Предположим, что у нас имеется таблица, содержащая информацию о местоположении заказчиков вашего предприятия. По колонкам state (штат), country (графство) и city (город) создается структура B-дерева в следующем порядке: state, country, city. Если в запросе в предложении WHERE указано значение Texas (Техас) колонки state, то будет использован индекс. Но поскольку значения колонок country и city не заданы в запросе, то индекс возвратит набор строк, исходя из всех записей индекса, содержащих значение Texas в колонке state. Для считывания диапазона индексных страниц используется сканирование индекса и последующее сканирование страниц данных, исходя из значений колонки state. Страницы индекса считываются последовательно таким же образом, как при сканировании таблицы для доступа к страницам данных.

Примечание. Индекс может быть использован только в том случае, если хотя бы один из индексных ключей указан в предложении WHERE запроса SQL. Если в предложении WHERE запроса для предыдущего примера указано значение только колонки name (имя) или колонки phone number (номер телефона), то индекс использоваться не будет.

В большинстве случаев сканирование индекса будет достаточно эффективным; но если происходит доступ к более чем 20 процентам строк таблицы, то более эффективным является сканирование таблицы, при котором из таблицы считываются все строки. Эффективность запросов, использующих индекс, зависит от того, как вы используете индекс (см. раздел "Использование индексов" далее), а также от степени уникальности индекса (см. следующий раздел).

Уникальность индекса

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

Уникальный индекс

Уникальный индекс содержит только одну строку данных для каждого индексного ключа; иными словами, значения индексного ключа не могут присутствовать в индексе более одного раза. Использование уникальных индексов гарантирует, что для поиска запрошенных данных требуется всего одна дополнительная операция ввода-вывода. SQL Server обеспечивает уникальность индекса по колонкам или комбинации колонок, образующих ключ индекса. SQL Server не допускает занесения дублированных значений ключа в базу данных. Если вы попытаетесь сделать это, появится сообщение об ошибке. SQL Server создает уникальные индексы, если задали по таблице ограничение PRIMARY KEY или ограничение UNIQUE. (Об ограничениях PRIMARY KEY и UNIQUE см. лекцию 16).

Индекс можно сделать уникальным, только если уникальны сами данные. Если данные какой-либо колонки не обладают свойством уникальности, то вы можете все же создать уникальный индекс, используя составной индекс. Например, колонка last name (фамилия), возможно, не будет уникальной, но комбинация данных этой колонки с колонками first name (имя) и middle name (отчество) может образовать уникальный индекс по данной таблице.

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

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

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

Типы индексов

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

Кластеризованные индексы

Как уже говорилось, кластеризованный индекс – это индекс в виде B-дерева, где хранятся реальные строки данных таблицы в отсортированном порядке в узлах-листьях (рис. 17.6). Эта система дает несколько преимуществ и имеет несколько недостатков.

 Кластеризованный индекс


Рис. 17.6.  Кластеризованный индекс

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

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

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

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

Некластеризованные индексы

В отличие от кластеризованного индекса некластеризованный индекс не содержит реальных данных таблицы в своих узлах-листьях. Узлы-листья могут содержать один из двух типов информации о местоположении строк данных. Во-первых, если по таблице не создан кластеризованный индекс, то некластеризованные индексы по этой таблице хранят в своих узлах-листьях идентификаторы строк (Row ID) (рис. 17.7). Каждый идентификатор строки указывает реальную строку данных в таблице. Идентификатор строки – это значение, включающее в себя номер файла данных, номер страницы и местоположение строки на этой странице. Это значение обеспечивает быстрый доступ к реальным данным, указывая точное местоположение этих данных.

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