Брейман А.Д. Управление большими базами данных, 2009г

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

––––––––––––––––––––– ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ “МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ” –––––––––––––––––––––

Кафедра “Персональные компьютеры и сети”

А.Д. Брейман

УПРАВЛЕНИЕ БОЛЬШИМИ БАЗАМИ ДАННЫХ

Учебное пособие

Москва 2009

2

УДК 004.658:007.51 ББК 32.973.26-018.2

Рекомендовано к изданию в качестве учебного пособия

редакционно-издательским советом МГУПИ

Рецензенты: профессор, д.т.н. Баканов В.М. профессор, к.т.н. Рощин А.В.

Брейман А.Д. Управление большими базами данных: учебное

пособие. М.:МГУПИ, 2009. — 140с.

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

Для специальности 230101 «Вычислительные машины, комплексы, системы и сети» настоящее пособие может быть использовано при изучении курсов «Управление большими базами данных» и «Базы данных».

Брейман А.Д., 2009 МГУПИ

3

Содержание 1 Введение в управление большими базами данных ......................................... 6

1.1 Основные обязанности администратора баз данных ............................... 6 1.2 РСУБД Microsoft SQL Server ................................................................... 10 1.3 Контрольные вопросы.............................................................................. 11

2 Управление файлами БД................................................................................. 12 2.1 Файлы данных и файлы журналов транзакций....................................... 12 2.2 Автоматический рост файлов .................................................................. 13 2.3 Системные базы данных .......................................................................... 14 2.4 Создание баз данных................................................................................ 14 2.5 Просмотр информации о базах данных................................................... 15 2.6 Удаление баз данных................................................................................ 15 2.7 Контрольные вопросы.............................................................................. 15

3 Индексация данных......................................................................................... 16 3.1 Архитектура индексов.............................................................................. 16 3.2 Индексные ключи..................................................................................... 18 3.3 Уникальность индекса.............................................................................. 19 3.4 Типы индексов.......................................................................................... 20 3.5 Контрольные вопросы.............................................................................. 22

4 Управление индексами ................................................................................... 23 4.1 Создание индексов ................................................................................... 23 4.2 Перестроение индексов............................................................................ 24 4.3 Обновление статистики по индексам ...................................................... 25 4.4 Использование индексов.......................................................................... 27 4.5 Формирование эффективных индексов................................................... 27 4.6 Контрольные вопросы.............................................................................. 29

5 Управление представлениями ........................................................................ 30 5.1 Понятие о представлениях....................................................................... 30 5.2 Типы представлений ................................................................................ 30 5.3 Создание представлений.......................................................................... 31 5.4 Использование представлений ................................................................ 35 5.5 Изменение и удаление представлений .................................................... 35 5.6 Индексированные представления............................................................ 36 5.7 Контрольные вопросы.............................................................................. 36

6 Управление хранимыми процедурами........................................................... 38 6.1 Хранимые процедуры............................................................................... 38 6.2 Создание хранимых процедур ................................................................. 38 6.3 Передача параметров в хранимую процедуру ........................................ 39 6.4 Локальные переменные в хранимой процедуре ..................................... 41 6.5 Использование SELECT для возвращаемых значений........................... 43 6.6 Изменение и удаление хранимых процедур ........................................... 44 6.7 Контрольные вопросы.............................................................................. 44

7 Управление триггерами .................................................................................. 45 7.1 Принципы функционирования триггерров ............................................. 45 7.2 Создание триггеров .................................................................................. 46

4

7.3 Использование таблиц deleted и inserted ................................................. 46 7.4 Пример создания триггера ....................................................................... 47 7.5 Создание триггера типа DELETE ............................................................ 48 7.6 Создание триггера типа INSERT ............................................................. 49 7.7 Создание триггера типа UPDATE ........................................................... 50 7.8 Использование триггеров AFTER ........................................................... 52 7.9 Использование вложенных триггеров..................................................... 52 7.10 Управление триггерами.......................................................................... 53 7.11 Контрольные вопросы............................................................................ 54

8 Управление транзакциями .............................................................................. 55 8.1 Транзакции и восстановление данных после сбоев................................ 55 8.2 Уровни изолированности ......................................................................... 56 8.3 Режимы транзакций.................................................................................. 58 8.4 Откаты транзакций ................................................................................... 59 8.5 Точки сохранения..................................................................................... 59 8.6 Контрольные вопросы.............................................................................. 60

9 Блокировка транзакций................................................................................... 61 9.1 Блокировка транзакций ............................................................................ 61 9.2 Уровни блокировок .................................................................................. 61 9.3 Режимы блокировки ................................................................................. 62 9.4 Блокирование и взаимоблокировки......................................................... 62 9.5 Подсказки блокировки ............................................................................. 63 9.6 Контрольные вопросы.............................................................................. 64

10 Оптимизация запросов.................................................................................. 65 10.1 Принципы работы оптимизатора........................................................... 65 10.2 Оптимизация плана выполнения запроса ............................................. 66 10.3 Подсказки оптимизатору запросов........................................................ 66 10.4 Оптимизация с использованием SQL Server 2000 Index Tuning Wizard и SQL Server 2005 Database Tuning Advisor.................................................. 68 10.5 Контрольные вопросы............................................................................ 73

11 Управление защитой данных........................................................................ 74 11.1 Основы управления доступом ............................................................... 74 11.2 Режимы аутентификации ....................................................................... 74 11.3 Учетные записи и пользователи ............................................................ 76 11.4 Администрирование полномочий доступа к базам данных................. 78 11.5 Администрирование ролей баз данных................................................. 80 11.6 Распространенные ошибки при защите сервера БД ............................. 81 11.7 Внедрение SQL кода (SQL Injection)..................................................... 82 11.8 Защита SQL Server в Интернет .............................................................. 84 11.9 Контрольные вопросы............................................................................ 85

12 Резервное копирование и восстановление данных...................................... 86 12.1 Основные понятия резервного копирования ........................................ 86 12.2 Журнальное протоколирование в SQL Server....................................... 89 12.3 Контрольные точки ................................................................................ 93 12.4 Методы резервного копирования .......................................................... 94

5

12.5 Выполнение резервного копирования................................................... 95 12.6 Планирование резервного копирования................................................ 99 12.7 Основы восстановления данных.......................................................... 100 12.8 Оператор RESTORE ............................................................................. 101 12.9 Доставка журнала (Log Shipping) ........................................................ 104 12.10 Контрольные вопросы........................................................................ 105

13 Административные задачи и их автоматизация ........................................ 106 13.1 Административные задачи................................................................... 106 13.2 Управление заданием ........................................................................... 107 13.3 Оповещения .......................................................................................... 108 13.4 Операторы............................................................................................. 110 13.5 Журнал ошибок службы SQLServerAgent .......................................... 111 13.6 Контрольные вопросы.......................................................................... 111

14 Мониторинг и управление производительностью сервера БД................. 112 14.1 Использование SQL Query Аnalyzer для мониторинга ...................... 112 14.2 Использование SQL Profiler для мониторинга.................................... 114 14.3 Принципы управления производительностью СУБД ........................ 114 14.4 Способы определения узких мест ....................................................... 115 14.5 Трассировка приложения ..................................................................... 117 14.6 Контрольные вопросы.......................................................................... 120

15 Экспорт и импорт данных........................................................................... 121 15.1 Протоколирование операций массовой загрузки данных .................. 121 15.2 Оператор BULK INSERT ..................................................................... 121 15.3 Data Transformation Services (DTS)...................................................... 123 15.4 Создание DTS-пакетов с помощью DTS Designer .............................. 124 15.5 Контрольные вопросы.......................................................................... 127

16 Распределенные транзакции ....................................................................... 128 16.1 Введение ............................................................................................... 128 16.2 Пример использования MS DTC ......................................................... 129 16.3 Свойства MS DTC ................................................................................ 130 16.4 Программирование MS DTC................................................................ 130 16.5 Контрольные вопросы.......................................................................... 131

17 Основы репликации .................................................................................... 132 17.1 Понятие репликации ............................................................................ 132 17.2 Типы репликации ................................................................................. 133 17.3 Данные репликации.............................................................................. 134 17.4 Репликация моментальных снимков ................................................... 137 17.5 Настройка и мониторинг репликации снимков .................................. 138 17.6 Контрольные вопросы.......................................................................... 139

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

6

1 Введение в управление большими базами данных

1.1 Основные обязанности администратора баз данных

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

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

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

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

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

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

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

System Monitor. Применяется для мониторинга использования ресурсов SQL Server и Windows 2000. System Monitor является средством Windows 2000, доступным из меню Start.

SQL Server Enterprise MАnager. Предоставляет как информацию об использовании ресурсов, так и некоторую ограниченную информацию о производительности.

Программы мониторинга систем управления реляционными базами данных от сторонних производителей. Эти средства имеют

7

возможности для мониторинга систем управления реляционными базами данных (RDBMS, relational database mАnagement system) и для выдачи оповещений.

Сетевые мониторы. Применяются при необходимости слежения за сетью. Это – SMS (Systems MАnagement Server) от фирмы Microsoft и утилиты от сторонних производителей.

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

Средства для мониторинга использования места на диске. Это – Проводник(Microsoft Windows Explorer) и средства для мониторинга от сторонних производителей. Некоторые средства могут следить и за Windows 2000, и за SQL Server.

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

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

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

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

8

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

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

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

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

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

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

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

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

Конфигурация базы данных. Эта информация должна содержать компоновку и схему базы данных (database layout Аnd schema), имена и местоположения всех файлов данных, сведения о том, к каким группам относятся те или иные файлы, и сведения о том, как были созданы группы файлов. Эта информация позволит вам выяснить, какие именно группы файлов были потеряны при отказе массива дисков.

9

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

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

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

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

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

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

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

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

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

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

10

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

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

1.2 РСУБД Microsoft SQL Server

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

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

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

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

Основные средства управления SQL Server 2000 — Enterprise Manager и Query Analyser, SQL Server 2005 и 2008 — SQL Server Management Studio.

11

После успешной регистрации вашего сервера в Enterprise Manager/SQL Server Management Studio вы получаете доступ ко всем его свойствам, базам данных и объектам.

Все инсталляции SQL Server имеют встроенную административную учетную запись, "sa" ("sa" расшифровывается как system administrator, системный администратор). При инсталляции SQL Server 2008 с возможностью проверки подлинности SQL Server, для этой учетной записи потребуется задать надежный пароль. При инсталляций SQL Server 2000 и 2005, административной учетной записи создается с пустым паролем, и сразу после установки нужно назначить учетной записи sa надежный пароль

1.3 Контрольные вопросы

1. Для чего нужно документировать конфигурацию аппаратного обеспечения?

2. Как можно проверить работоспособность плана восстановления? 3. Что такое аудит системы? 4. Какие риски несет пустой пароль администратора?

12

2 Управление файлами БД

2.1 Файлы данных и файлы журналов транзакций

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

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

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

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

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

Максимальный размер файлов базы данных SQL Server составляет 32 терабайта для файлов данных и 4 терабайта для файлов журналов.

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

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

13

помощи которых вы сможете распределить данные по нескольким дискам или массивам дисков, что обеспечит параллельный ввод-вывод.

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

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

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

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

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

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

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

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

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

14

2.3 Системные базы данных

При инсталляции SQL Server создаются четыре системных базы данных: master, tempdb, model и msdb.

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

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

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

msdb. Содержит таблицы, которые SQL Server Agent применяет для планирования заданий и оповещений. Эта база данных также хранит данные репликации.

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

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

SQL Server предлагает три метода для создания баз данных: воспользоваться мастером Create Database Wizard, создать базу данных при помощи Enterprise Manager / SQL Server Management Studio или выполнить команду CREATE DATABASE:

CREATE DATABASE имя_базы [ ON [PRIMARY] ([ NAME = логическое_имя_файла, ] FILENAME = 'имя_файла_ОС' [, SIZE = размер] [, MAXSIZE = { максимальный_размер | UNLIMITED } ] [, FILEGROWTH = приращение] ) | {FILEGROUP имя_группы_файлов FILEDEFINITIONS} [,...n] ] [LOG ON {[ NAME = логическое_имя_файла, ] [FILENAME = 'имя_файла_ОС' [, SIZE = размер]

15

[, MAXSIZE = { максимальный_размер | UNLIMITED } ] [, FILEGROWTH = приращение] } [,...n] [FOR LOAD | FOR ATTACH] [COLLATE collation_name]

2.5 Просмотр информации о базах данных

Информацию о базах данных можно просматривать, запуская команды T-SQL, при помощи окна с приглашением командной строки или из Query Analyzer / SQL Server Management Studio. Для просмотра информации о базах данных запустите такие команды:

Use MyDB--Задает контекст используемой базы данных GO Sp_helpfile --Показывает информацию для всех файлов базы данных GO --Чтобы посмотреть информацию только для некоторого файла, укажите его имя Sp_helpdb MyDB --То же самое, но выдается также информация о месте на диске, выделенном для базы данных GO Sp_helpdb --Показывает информацию обо всех базах данных GO

2.6 Удаление баз данных

Базы данных можно удалять как при помощи Enterprise Manager / SQL Server Management Studio, так и командой T-SQL DROP DATABASE. Помните, что удаление базы данных является неотменяемым действием. Ниже показаны команды, которые удалят базу данных MyDB и все ее файлы:

USE master--Для запуска команды DROP DATABASE вы должны GO --применять базу данных master DROP DATABASE MyDB --Единственным параметром этой команды является имя удаляемой базы данных. GO

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

пользователей. 2.7 Контрольные вопросы

1. Сколько файлов минимально занимает база данных? 2. Для чего нужна системная база данных model? 3. Как можно проверить, сколько места занимает база данных на

диске? 4. Что произойдет, если данных окажется больше, чем размер файла

данных?

16

3 Индексация данных

3.1 Архитектура индексов

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

Большинство индексов организованы в виде структуры B-дерева. Каждая страница индекса называется индексной страницей, или узлом индекса. Структура индекса начинается на верхнем уровне с корневого узла. Корневой узел соответствует началу индекса: это первые данные, к которым осуществляется доступ при поиске данных. Корневой узел содержит ряд строк индекса. Каждая строка состоит из значения ключа и указателя на индексную страницу (которая называется узлом-ветвью) (см. рисунок 4.1).

Рисунок 4.1 — Корневой узел B-дерева и узлы-ветви Как и корневой узел, каждый узел-ветвь содержит ряд индексных строк

в структуре индексной страницы. Каждая индексная строка указывает на другой узел-ветвь или на узел-лист (см. рисунок 4.2). Узел-лист является последним уровнем индекса. Каждый узел-ветвь содержит также связанный список узлов-ветвей того же уровня.

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

17

Рисунок 4.2 — Дерево поиска с узлами-ветвями и узлами-листьями

Рисунок 4.3 — Уровни индекса

В некластеризованном индексе узел-лист содержит значение ключа, а

также идентификатор строки (Row ID), указывающий нужную строку в таблице, или ключ кластеризованного индекса, если имеется также кластеризованный индекс по этой таблице. А в кластеризованном индексе в узле-листе находятся сами данные. Количество строк в узле-листе зависит от размера индексных записей, а в случае кластеризованного индекса – от размера данных.

Row ID – это указатель, который автоматически формируется СУБД из идентификатора файла, номера страницы и номера строки данных.

18

Используя Row ID, можно считывать данные с помощью всего лишь одной дополнительной операции ввода-вывода.

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

3.2 Индексные ключи

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

Рисунок 4.4 — Простой индекс

В зависимости от типа сохраняемых данных, количества уникальных

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

19

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

Составной индекс – это индекс, определенный более чем по одной колонке (см. рисунок 4.5). Доступ к составному индексу может осуществляться с помощью одного или нескольких индексных ключей. В рамках SQL Server 2000 индекс может содержать до 16 колонок, и колонки ключей могут иметь длину до 900 байтов.

Рисунок 4.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.

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

3.3 Уникальность индекса

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

20

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

Уникальный индекс содержит только одну строку данных для каждого индексного ключа; иными словами, значения индексного ключа не могут присутствовать в индексе более одного раза. Использование уникальных индексов гарантирует, что для поиска запрошенных данных требуется всего одна дополнительная операция ввода-вывода. SQL Server обеспечивает уникальность индекса по колонкам или комбинации колонок, образующих ключ индекса. SQL Server не допускает занесения дублированных значений ключа в базу данных. Если вы попытаетесь сделать это, появится сообщение об ошибке. SQL Server создает уникальные индексы, если задали по таблице ограничение PRIMARY KEY или ограничение UNIQUE.

Индекс можно сделать уникальным, только если уникальны сами данные. Если данные какой-либо колонки не обладают свойством уникальности, то вы можете все же создать уникальный индекс, используя составной индекс. Например, колонка last name (фамилия), возможно, не будет уникальной, но комбинация данных этой колонки с колонками first name (имя) и middle name (отчество) может образовать уникальный индекс по данной таблице. Если вы попытаетесь вставить в таблицу строку, которая дает дублированное значение индексного ключа в уникальном индексе, то вставка не будет выполнена.

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

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

3.4 Типы индексов

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

21

Рисунок 4.6 — Кластеризованный индекс

Еще одним преимуществом кластеризованных индексов является то,

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

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

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

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

22

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

Каждая таблица может иметь только один кластеризованный индекс. Вы можете создать до 249 некластеризованных индексов на одну таблицу.

Рисунок 4.7 — Некластеризованный индекс по таблице, имеющей

кластеризованный индекс

Рисунок 4.8 — Некластеризованный индекс по таблице без

кластеризованного индекса


1. В чем состоят преимущества и недостатки использования индексов? 2. Как хранятся данные таблицы при наличии кластеризованного

индекса? 3. Что хранится в листе дерева некластеризованного индекса? 4. Как происходит сканирование индекса?

23

4 Управление индексами

4.1 Создание индексов

Кластеризованные и некластеризованные индексы создаются с помощью мастеров в Enterprise Manager / SQL Server Management Studio или с помощью команды T-SQL CREATE INDEX: CREATE [UNIQUE] [CLUSTERED | NONCLUSTERED] INDEX имя_индекса ON имя_таблицы ( имя_колонки [, имя_колонки, имя_колонки, ... ] ) [ WITH параметры ] [ ON имя_группы_файлов ]

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

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

Таблица 5.1 — Необязательные параметры CREATE INDEX Параметр Описание PAD_INDEX В сочетании с параметром FILL_FАСTOR указывает, что свободное

место должно быть оставлено не только в узлах-листьях, но и в узлах-ветвях

FILL_FАСTOR = число

Указывает, в какой степени будет заполнен каждый узел-лист; значение в процентах задается в диапазоне от 0 до 100

IGNORE_DUP_KEY

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

DROP_EXISTING

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

STATISTICS_NORECOMPUTE

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

При обновлениях и вставках в таблице, имеющей индексы, страницы

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

24

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

Рисунок 5.1 — Расщепление страницы индекса

Одним из способов снижения степени расщепления и фрагментации

страниц является настройка коэффициента заполнения узлов индекса. Коэффициент заполнения указывает процент заполнения узла при создании индекса, что позволяет оставить место для дополнительных строк индекса. Вы можете задать коэффициент заполнения для индекса с помощью параметра FILL_FАСTOR оператора T-SQL CREATE INDEX. Этот параметр оказывает влияние только в момент создания индекс и может принимать значения в диапазоне от 0 до 100, указывая процент заполнения страницы индекса. Значение 0 соответствует особому случаю: узлы-листья заполняются полностью, но в узлах-ветвях и корневом узле остается свободное место. Это значение задается по умолчанию при инсталляции и обычно дает хорошие результаты.

4.2 Перестроение индексов

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

25

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

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

Имеется два метода перестроения индекса без его удаления и повторного создания: оператор CREATE INDEX...DROP_EXISTING и использование DBCC DBREINDEX. Оба этих средства выполняют перестроение индекса за один шаг, и SQL Server знает, что нужно реорганизовать существующий индекс. Использование этих методов позволяет избежать удаления и повторного создания некластеризованных индексов, когда вы перестраиваете кластеризованный индекс. Эти одношаговые методы также используют отсортированный порядок данных, находящихся в индексе; повторная сортировка этих данных уже не требуется.

CREATE INDEX...DROP_EXISTING используется для единовременного перестроения только одного индекса по таблице. DBCC DBREINDEX используется с именем базы данных и именем таблицы для перестроения всех индексов по этой таблице без необходимости запуска отдельных команд для каждого индекса.

4.3 Обновление статистики по индексам

Если нет возможности перестроить индекс целиком, можно обновить только статистику с помощью оператора UPDATE STATISTICS. Он имеет следующий синтаксис:

26

UPDATE STATISTICS имя_таблицы [ имя_индекса | (имя_статистики[, имя_статистики, ...] ] [ WITH [ FULLSCАN | SAMPLE число {PERCENT | ROWS} ] [ ALL | COLUMNS | INDEX ] [ NORECOMPUTE] ]

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

Единственный обязательный параметр – это имя_таблицы. Необязательные параметры перечислены в таблице 5.2.

Таблица 5.2 — Параметры оператора UPDATE STATISTICS Параметр Описание имя_индекса Указывает индекс, по которому нужно пересчитать

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

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

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

SAMPLE число PERCENT | ROWS

Указывает количество или процент строк, по которым создается статистика. По умолчанию количество строк выборки определяет SQL Server. Этот параметр нельзя использовать в сочетании с параметром FULLSCАN

ALL | COLUMN | INDEX Указывает вид собираемой статистики: вся статистика, статистика по колонкам или только статистика по индексам

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

Если в вашей системе выполняется большое число вставок, обновлений

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

27

4.4 Использование индексов

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

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

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

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

таблицы). Подсказки указываются после ключевого слова WITH. Пример

подсказки, требующей использовать индекс Region:

SELECT * FROM Customers WITH (INDEX(Region)) WHERE region = 'OR' АND city = 'Portland'

Пример подсказки, требующей использовать один из индексов —

Region, City или CompanyName:

SELECT * FROM customers WITH (INDEX(Region, City, CompanyName)) WHERE region = 'OR' АND city = 'PortlАnd'

4.5 Формирование эффективных индексов

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

28

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

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

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

Индексы наиболее подходят для задач следующего типа: Запросы, которые указывают "узкие" критерии поиска. Такие

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

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

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

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

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

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

29

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

Не индексируйте небольшие таблицы. Иногда бывает намного эффективнее выполнять сканирование таблицы, если это небольшая таблица (например, несколько сотен строк).

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

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


1. Что происходит с индексами, когда в таблицу вставляется строка? 2. Как коэффициент заполнения FILL_FACTOR влияет на то, как часто

происходит расщепление страниц индекса? 3. Чем отличается перестроение индекса от его удаления и создания

заново? 4. Какой индекс целесообразно использовать, если запрос должен

выдать все строки таблицы?

30

5 Управление представлениями

5.1 Понятие о представлениях

Представление (англ. view) — это виртуальная таблица, определяемая запросом, т.е. таблица, которая содержит результат выполнения указанного оператора SELECT. С представлением можно работать, как с обычной таблицей. К представлению можно применять операции SELECT, INSERT, UPDATE и DELETE. На самом деле представление хранится просто как заранее определенный оператор SELECT. При доступе к представлению оптимизатор запросов объединяет текущий выполняемый оператор SQL с запросом, определяющим данное представление.

5.2 Типы представлений

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

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

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

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

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

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

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

SQL Server налагает несколько ограничений на создание и использование представлений. Это следующие ограничения:

31

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

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

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

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

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

Ограничение оператора SELECT. Используемый для представления оператор SELECT не может содержать оператора ORDER BY, COMPUTE или COMPUTE BY или ключевого слова INTO.

5.3 Создание представлений

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

ряда способов. Создание представлений с помощью T-SQL – достаточно простой процесс: вы запускаете оператор CREATE VIEW для создания представления с помощью ISQL, OSQL или Query Аnalyzer. Оператор CREATE VIEW имеет следующий синтаксис:

CREATE VIEW имя_представления [(колонка, колонка ...)] [WITH ENCRYPTION] AS ваш оператор SELECT [WITH CHECK OPTION]

Ключевое слово WITH ENCRYPTION указывает, что определение

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

32

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

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

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

Рисунок 5.1 — Таблица Employee с данными

В этом примере вместо ограничения колонок мы ограничим строки,

задав их в предложении WHERE, как это показано ниже:

CREATE VIEW emp_vw2 AS SELECT * FROM Employee WHERE Dept = 1

Результирующее представление будет содержать только строки со

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

33

Рисунок 5.2 — Представление emp_vw2

Представления позволяют упростить работу с результатом соединения таблиц. Например, у нас имеются две таблицы – Manager и Employee2 (см. рисунок 5.3). Следующий оператор создает представление, которое выполняет их соединение:

CREATE VIEW org_chart AS SELECT Employee.ename, Manager.mname FROM Employee, MАnager WHERE Employee.mАnager_id = mАnager.id GROUP BY Manager.mname, Employee.ename

В данном примере указанные две таблицы связаны значением

manager_id (идентификатор руководителя). Результирующие данные, содержащиеся в представлении org_chart, сгруппированы по имени руководителя (manager_name) (см. рисунок 5.3). Отметим, что если руководитель указан в таблице Manager, но в таблице Employee2 нет ни одного служащего (employee) для этого руководителя, то в представлении нет ни одной записи для этого руководителя. В представлении также нет ни

34

одной записи для служащего, содержащегося в таблице Employee2, но не имеющего соответствующего руководителя в таблице Manager.

Рисунок 5.3 — Представление org_chart

Агрегированные представления могут оказаться полезными во таких

случаях, как расчет средних значений и сумм. Функции агрегирования AVG, COUNT, MAX, MIN и SUM вычисляют одно значение для всей таблицы или ее части и возвращают его. В этом примере представление задает виртуальную таблицу, где показаны суммы выплат жалования по каждому отделу (см. рисунок 5.4):

CREATE VIEW sal_vw AS SELECT dept, SUM(Salary) FROM Employee GROUP BY dept

35

Рисунок 5.4 — Представление sal_vw

5.4 Использование представлений

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

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

5.5 Изменение и удаление представлений

Удаление и изменение представлений выполняется с помощью оператора ALTER VIEW, который имеет следующий синтаксис:

ALTER VIEW имя_представления [(колонка, колонка, ...)] [WITH ENCRYPTION] AS ваш оператор SELECT [WITH CHECK OPTION]

Единственным отличием между операторами ALTER VIEW и CREATE

VIEW является то, что оператор CREATE VIEW не будет выполняться, если представление уже существует, а оператор ALTER VIEW не будет выполняться, если указанное представление не существует.

36

Для удаления представления используйте оператор DROP VIEW, имеющий следующий синтаксис:

DROP VIEW имя_представления

5.6 Индексированные представления

SQL Server 2000 и выше позволяет создать индекс по представлению с помощью оператора CREATE INDEX. Например, следующий оператор T-SQL создает кластеризованный индекс по представлению с именем partview:

CREATE UNIQUE CLUSTERED INDEX partview_cluidx ON partview (part_num ASC) WITH FILLFАСTOR=95 ON partfilegroup

Индекс по представлению повышает производительность при доступе к

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

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

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


1. Можно ли создать представление, содержащее подмножество как строк, так и колонок базовой таблицы?

37

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

3. Можно ли через представление ввести данные, нарушающие какое-либо правило целостности?

4. Что нужно сделать, чтобы после вставки новых строк в базовую таблицу индексированное представление содержало актуальные данные?

38

6 Управление хранимыми процедурами

6.1 Хранимые процедуры

Хранимая процедура – это набор операторов T-SQL, который хранится и выполняется на сервере. Перед выполнением текст хранимой процедуры компилируется и сохраняется в кэш-области памяти для процедур при первом выполнении хранимой процедуры, Хранимые процедуры T-SQL могут принимать входные параметры и возвращать результаты в виде таблиц, выходных параметров и сообщения о состоянии.

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

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

Имеется три типа хранимых процедур: системные хранимые процедуры, расширенные хранимые процедуры и простые определяемые пользователем хранимые процедуры. Системные хранимые процедуры предоставляет SQL Server, и они имеют префикс sp_. Они используются для управления SQL Server и вывода на экран информации о базах данных и пользователях. Расширенные хранимые процедуры (префикс xp_) представляют собой динамически подключаемыми библиотеки (DLL).

6.2 Создание хранимых процедур

Оператор CREATE PROCEDURE имеет следующий синтаксис:

CREATE PROC[EDURE] имя_процедуры [ {@имя_параметра тип_данных} ] [= по_умолчанию][OUTPUT] [,...,n] AS оператор(ы)_t-sql

Создадим простую хранимую процедуру, которая будет выбирать и

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

39

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

USE Northwind GO IF EXISTS (SELECT name FROM sysobjects WHERE name = "LateShipments" AND type = "P") DROP PROCEDURE LateShipments GO CREATE PROCEDURE LateShipments AS SELECT RequiredDate, ShippedDate, Shippers.CompanyName FROM Orders, Shippers WHERE ShippedDate > RequiredDate AND Orders.ShipVia = Shippers.ShipperID GO

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

Для запуска хранимой процедуры достаточно вызвать ее по имени. Если оператор, вызывающий данную процедуру, входит в пакет операторов и не является первым оператором этого пакета, то вы должны использовать перед именем процедуры ключевое слово EXECUTE (сокращается до "EXEC"):

SELECT getdate() EXECUTE LateShipments GO

6.3 Передача параметров в хранимую процедуру

Теперь добавим к нашей хранимой процедуре входной параметр, чтобы мы могли передавать данные в эту процедуру. Чтобы задать входные параметры в хранимой процедуре, укажите список этих параметров с символом @ перед именем каждого параметра, т.е. @имя_параметра. Вы можете задать в хранимой процедуре до 1024 параметров. В нашем примере мы создадим параметр с именем @shipperName. При запуске хранимой процедуры мы будем передавать имя компании-грузоотправителя (shipperName).

CREATE PROCEDURE LateShipments @shipperName char(40) AS SELECT RequiredDate, ShippedDate, Shippers.CompanyName FROM Orders, Shippers WHERE ShippedDate > RequiredDate AND Orders.ShipVia = Shippers.ShipperID AND Shippers.CompanyName = @shipperName GO

40

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

CREATE PROCEDURE LateShipments @shipperName char(40) = "United Package" AS SELECT RequiredDate, ShippedDate, Shippers.CompanyName FROM Orders, Shippers WHERE ShippedDate > RequiredDate AND Orders.ShipVia = Shippers.ShipperID AND Shippers.CompanyName = @shipperName GO

Теперь при запуске процедуры LateShipments без указания значения

входного параметра @shipperName, для него будет использоваться значение «United Package». Но если вы укажете входной параметр, то будет использоваться указанное значение.

Для возврата значения параметра хранимой процедуры в вызывающую программу используйте ключевое слово OUTPUT после имени этого параметра. Чтобы сохранить значение в переменной, которую можно использовать в вызывающей программе, используйте при вызове хранимой процедуры ключевое слово OUTPUT. Чтобы увидеть, как это происходит, мы создадим новую хранимую процедуру, которая выбирает цену единицы указанного продукта. Входной параметр @prod_id – это идентификатор продукта, а выходной параметр @unit_price – это возвращаемое значение цены единицы продукта. В вызывающей программе будет объявлена локальная переменная с именем @price, которая будет использоваться для сохранения возвращаемого значения. Ниже приводится оператор, используемый для создания хранимой процедуры GetUnitPrice:

CREATE PROCEDURE GetUnitPrice @prod_id int, @unit_price money OUTPUT AS SELECT @unit_price = UnitPrice FROM Products WHERE ProductID = @prod_id GO

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

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

41

DECLARE @price money EXECUTE GetUnitPrice 77, @unit_price = @price OUTPUT PRINT CONVERT(varchar(6), @price) GO

При обращении к хранимой процедуре вы можете также задать входное

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

6.4 Локальные переменные в хранимой процедуре

Для создания локальных переменных используется ключевое слово DECLARE. При создании локальной переменной вы должны задать для нее имя и тип данных, а также поставить перед именем переменной символ @. По умолчанию переменная инициализируется значением NULL. Область действия локальной переменной в хранимой процедуре начинается с точки объявления этой переменной и заканчивается выходом из данной процедуры.

Рассмотрим пример хранимой процедуры, содержащей локальные переменные. Эта процедура вставляет пять строк в таблицу с помощью циклической конструкции WHILE. Сначала мы создадим таблицу с именем mytable для этого примера и затем создадим хранимую процедуру InsertRows. В этой процедуре мы будем использовать локальные переменные @loop_counter и @start_val, которые объявим вместе и разделим запятой. В следующей T-SQL-программе создается таблица и хранимая процедура:

CREATE TABLE mytable( column1 int, column2 char(10) ) GO CREATE PROCEDURE InsertRows @start_value int AS DECLARE @loop_counter int, @start_val int SET @start_val = @start_value – 1 SET @loop_counter = 0 WHILE (@loop_counter < 5) BEGIN INSERT INTO mytable VALUES (@start_val + 1, "new row") PRINT (@start_val) SET @start_val = @start_val + 1 SET @loop_counter = @loop_counter + 1 END GO

42

А теперь выполним эту хранимую процедуру с начальным значением 1. Вы увидите пять значений, выведенных для @start_val: 0, 1, 2, 3 и 4. Выберите все строки из таблицы mytable с помощью оператора SELECT и получите следующие выходные результаты:

column1 column2 ----------------------- 1 new row 2 new row 3 new row 4 new row 5 new row

После завершения хранимой процедуры переменные @loop_counter и

@start_val уже недоступны. Те же правила, связанные с областью действия переменной, применимы к выполнению пакетного набора операторов. Как только появляется ключевое слово GO (являющееся признаком конца пакета), локальные переменные, объявленные внутри пакета, становятся недоступны. Область действия локальной переменной находится только в пределах пакета. Рассмотрим вызов хранимой процедуры в одном из приведенных выше примеров:

DECLARE @price money EXECUTE GetUnitPrice 77, @unit_price = @price OUTPUT PRINT CONVERT(varchar(6), @price) GO PRINT CONVERT(varchar(6), @price) GO

В первом операторе PRINT выводится значение локальной переменной

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

13.00 Msg 137, Level 15, State 2, Server JAMIERE3, Line 2 Must declare the variable '@price'. (Должна быть объявлена переменная '@price')

Отметим, что первый оператор PRINT выполнен успешно. (Он вывел

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

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

43

6.5 Использование SELECT для возвращаемых значений

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

CREATE PROCEDURE PrintUnitPrice @prod_id int AS SELECT ProductID, UnitPrice FROM Products WHERE ProductID = @prod_id GO

Вызовите эту процедуру со значением входного параметра 66.

Результаты будут выведены в следующей форме:

ProductID UnitPrice ------------------------------------------ 66 17.00 (1 row(s) affected)

Для возврата значений переменных с помощью оператора SELECT,

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

CREATE PROCEDURE CheckUnitPrice @prod_id INT AS DECLARE @var1 int IF (SELECT UnitPrice FROM Products WHERE ProductID = @prod_id) > 100 SET @var1 = 1 ELSE SET @var1 = 99 SELECT "Variable 1" = @var1 GO

Вызовите эту процедуру со значением входного параметра 66.

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

Variable 1 -------------- 99 (1 row(s) affected)

44

Если бы в этом примере мы не задали заголовок колонки (просто указали бы SELECT @var1), то получили бы результат без заголовка, как это показано ниже:

-------------- 99 (1 row(s) affected)

6.6 Изменение и удаление хранимых процедур

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

Синтаксис оператора ALTER PROCEDURE аналогичен синтаксису оператора CREATE PROCEDURE:

ALTER PROC[EDURE] имя_процедуры [ {@имя_параметра тип_данных} ] [= по_умолчанию] [OUTPUT] [,...,n] AS оператор(ы)_t-sql

В операторе ALTER PROCEDURE вы должны переписать всю

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

Оператор DROP PROCEDURE удаляет хранимую процедуру без возможности восстановления.

Хранимая процедура sp_helptext выводит исходный текст хранимой процедуры. Единственный ее параметр – имя хранимой процедуры.


1. Чем отличается вызов хранимой процедуры от передачи SQL-запроса?

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

3. Как вернуть таблицу из хранимой процедуры? 4. Что нужно сделать, чтобы изменить один оператор в тексте большой

хранимой процедуры?

45

7 Управление триггерами

7.1 Принципы функционирования триггерров

Триггер – это специальный тип хранимой процедуры, которая запускается автоматически системой SQL Server при изменении данных в указанной таблице или представлении. Триггер должен иметь уникальное имя. Триггеры, как другие хранимые процедуры, могут содержать простые или сложные операторы T-SQL. В отличие от других типов хранимых процедур триггеры запускаются автоматически при указанных модификациях данных; их нельзя запустить вручную по имени. Триггер прикрепляется к одной таблице, но он может осуществлять доступ и к другим таблицам и объектам других баз данных. Существует три события, на которые может реагировать триггер: UPDATE, INSERT, DELETE. Триггер UPDATE выполняется, когда происходит изменение строк в таблице, триггер INSERT выполняется, когда происходит вставка данных в таблицу, а триггер DELETE выполняется, когда из таблицы удаляются строки. Триггер может реагировать на несколько событий, например, на INSERT и на UPDATE.

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

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

Триггер выполняется только один раз для одного оператора, даже если этот оператор влияет на несколько строк данных.

Обычно триггер не возвращает результаты, но такая возможность существует, и ее нужно учитывать. Если в теле триггера будет выполнен оператор SELECT, то его результат будет передан вызывающей программе. Для скрытия служебных сообщений о количестве измененных строк, нужно использовать оператор SET NOCOUNT ON.

Триггер может выполняться в одном из двух режимов: INSTEAD OF и AFTER. Триггер INSTEAD OF выполняется вместо соответствующей операции вставки, обновления или удаления. Можно задать только один триггер INSTEAD OF для каждого события в данной таблице. Триггеры INSTEAD OF нельзя подключать к модифицируемым представлениям, созданным с опцией WITH CHECK.

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

46

Триггеры, как и ограничения, можно использовать для поддержки целостности данных и деловых правил, но триггер не следует использовать как замену ограничения, когда достаточно использовать только ограничение. Например, вам не нужно создавать триггер, который проверяет наличие значения в колонке первичного ключа одной таблицы, чтобы определить, можно ли вставить это значение в соответствующую колонку другой таблицы; в этой ситуации прекрасно подойдет ограничение FOREIGN KEY. Однако вам может потребоваться триггер для каскадирования изменений, вносимых в связанные таблицы базы данных. Например, вы можете создать триггер DELETE по колонке title_id в таблице titles базы данных pubs, который удалит строки в таблицах sales, roysched и titleauthor, если удаляется соответствующая строка в таблице titles.

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

7.2 Создание триггеров

Для создания триггера служит оператор CREATE TRIGGER:

CREATE TRIGGER имя_триггера ON {таблица | представление} [WITH ENCRYPTION] {FOR | AFTER | INSTEAD OF} {[DELETE] [,] [INSERT] [,] [UPDATE]} [WITH APPEND] [NOT FOR REPLICATION] AS оператор_sql [...n]

При срабатывании триггера будут выполнены операторы SQL,

указанные после ключевого слова AS. Вы можете поместить сюда несколько операторов, включая программные конструкции, такие как IF и WHILE. В определении триггера не допускаются следующие операторы: ALTER DATABASE, CREATE DATABASE, DISK INIT, DISK RESIZE, DROP DATABASE, LOAD DATABASE, LOAD LOG, RECONFIGURE, RESTORE DATABASE, RESTORE LOG.

7.3 Использование таблиц deleted и inserted

Триггер имеет доступ к двум временным таблицам с именами deleted и inserted. Эти две таблицы имеют ту же структуру, что и таблица, к которой прикреплен данный триггер. Таблица deleted содержит копии строк, на которые повлиял оператор DELETE или UPDATE. Строки, удаляемые из таблицы операцией, которая привела к срабатыванию триггера, помещаются

47

в таблицу deleted. Таблица inserted содержит копии строк, добавленных к таблице при выполнении оператора INSERT или UPDATE. Эти строки добавляются одновременно в таблицу данных, к которой прикреплен триггер, и в таблицу inserted. Поскольку оператор UPDATE обрабатывается как DELETE, после которого следует INSERT, то при использовании оператора UPDATE старые значения строк копируются в таблицу deleted, а новые значения строк – в таблицу триггера и в таблицу inserted.

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

Значения таблиц inserted и deleted доступны только из триггера. После завершения работы триггера эти таблицы больше не доступны.

7.4 Пример создания триггера

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

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, ) GO IF EXISTS (SELECT name FROM sysobjects WHERE name = "Print_Update" AND type = "TR") DROP TRIGGER Print_Update GO CREATE TRIGGER Print_Update ON Bicycle_Inventory FOR UPDATE AS PRINT "The Bicycle_Inventory table was updated" GO

Чтобы проверить триггер, выполним вставку строки в эту таблицу и

затем модифицируем ее:

48

INSERT INTO Bicycle_Inventory VALUES ("Trek",1,"5500",5,1,0) GO UPDATE Bicycle_Inventory SET make_id = 2 WHERE model_name = "5500" GO

Будет возвращено сообщение "The Bicycle_Inventory table was updated",

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

7.5 Создание триггера типа DELETE

Перейдем к более сложному примеру – триггер типа DELETE, который каскадно выполняет изменения в связанных таблицы. Мы создадим триггер, который будет удалять строки из таблиц sales, roysched и titleauthor базы данных pubs, когда соответствующая строка удаляется из таблицы titles. Чтобы этот триггер смог работать, нужно удалить ограничения FOREIGN KEY на таблицы titleauthor, roysched и sales, которые связаны с колонкой title_id таблицы titles. Если попытаться удалить строку из таблицы titles, не удалив ограничений FOREIGN KEY, то вы получите сообщение об ошибке от SQL Server и удаление не произойдет.

Ниже показана программа T-SQL для этого триггера:

CREATE TRIGGER Delete_Title ON titles FOR DELETE AS DELETE sales FROM sales, deleted WHERE sales.title_id = deleted.title_id PRINT "Deleted from sales" DELETE roysched FROM roysched, deleted WHERE roysched.title_id = deleted.title_id PRINT "Deleted from roysched" DELETE titleauthor FROM titleauthor, deleted WHERE titleauthor.title_id = deleted.title_id PRINT "Deleted from titleauthor" GO

Чтобы проверить этот триггер, используйте оператор DELETE

следующим образом:

DELETE titles WHERE title_id = "PC1035" Если выполнить этот оператор DELETE, то сработает триггер, и вы

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

49

заданные в трех операторах PRINT из этого триггера, и сообщения о количестве затронутых строк в трех других таблицах; эти выходные сообщения показаны ниже:

(1 row(s) affected) Deleted from sales (5 row(s) affected) Deleted from roysched (1 row(s) affected) Deleted from titleauthor (1 row(s) affected)

Еще один вариант использования таблицы deleted – это сохранение

всех строк, удаленных из таблицы, в архиве. Например, можно сохранить строки, удаляемые из таблицы roysched, в таблице roysched_backup:

CREATE TABLE roysched_backup ( title_id tid NOT NULL, lorange int NULL, hirange int NULL, royalty int NULL ) GO CREATE TRIGGER tr_roysched_backup ON roysched FOR DELETE AS INSERT INTO roysched_backup SELECT * FROM deleted GO

7.6 Создание триггера типа INSERT

В этом примере мы создадим триггер, который активизируется при выполнении оператора INSERT в таблице sales. Этот триггер при вставке строки в таблицу sales будет добавлять значение sales.qty к колонке titles.ytd_sales. Этот триггер обращается к таблице inserted, чтобы получить значение qty, которое было помещено в таблицу sales:

CREATE TRIGGER Update_ytd_sales ON sales FOR INSERT AS UPDATE titles SET ytd_sales = ytd_sales + qty FROM inserted WHERE titles.title_id = inserted.title_id GO

50

7.7 Создание триггера типа UPDATE

Теперь создадим UPDATE-триггер, который будет просматривать колонку price (цена) при модификации таблицы titles, чтобы убедиться, что цена книги не возросла более чем на 10 процентов. В противном случае будет использован оператор ROLLBACK, который выполнит откат данного триггера и оператора, вызвавшего триггер. Если триггер активизирован из транзакции, то произойдет откат всей транзакции. Таблицы deleted и inserted используются в данном примере для проверки изменения цены.

CREATE TRIGGER Update_Price_Check ON titles FOR UPDATE AS DECLARE @orig_price money, @new_price money SELECT @orig_price = price from deleted PRINT "Исходная цена=", CONVERT(varchar(6),@orig_price) SELECT @new_price = price from inserted PRINT "Новая цена =", CONVERT(varchar(6),@new_price) IF (@new_price > (@orig_price * 1.10)) BEGIN PRINT "Откат транзакции" ROLLBACK END ELSE PRINT "С ценой все хорошо" GO

Чтобы проверить этот триггер, выполните сначала следующие

операторы, чтобы проверить текущую цену книги:

SELECT price FROM titles WHERE title_id = "BU1111" Цена составляет $11.95. Теперь попробуем увеличить цену на 15

процентов с помощью следующих операторов:

UPDATE titles SET price = price * 1.15 WHERE title_id = "BU1111" Вы увидите следующие результаты:

Исходная цена 11.95 Новая цена 13.74 Откат транзакции

Произошла активизация триггера, который вывел исходную цену и

новую цену и выполнил откат (поскольку цена возросла более чем на 10 процентов).

51

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

SELECT price FROM titles WHERE title_id = "BU1111"

Цена осталась равной $11.95, а это означает, что был выполнен откат

модификации. Теперь увеличим цену на 9 процентов и убедимся, что цена изменена.

Для этой модификации используется следующий T-SQL-набор:

UPDATE titles SET price = price * 1.09 WHERE title_id = "BU1111" GO SELECT price FROM titles WHERE title_id = "BU1111" GO

Цена стала равной $13.03, и поскольку изменение составило меньше 10

процентов, то триггер не инициировал откат. Создавая триггер UPDATE, вы можете задать, чтобы этот триггер

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

CREATE TRIGGER Update_Price_Check ON titles FOR UPDATE AS IF UPDATE (price) BEGIN DECLARE @orig_price money, @new_price money SELECT @orig_price = price FROM deleted

PRINT "Исходная цена=", CONVERT(varchar(6),@orig_price) SELECT @new_price = price from inserted PRINT "Новая цена =", CONVERT(varchar(6),@new_price)

IF (@new_price > (@orig_price * 1.10)) BEGIN PRINT "Откат транзакции" ROLLBACK END ELSE PRINT "С ценой все хорошо" END GO

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

titles, за исключением колонки price, триггер пропустит операторы между ключевыми словами BEGIN и END в операторе IF, т.е. фактически будет пропущен весь триггер.

52

Чтобы проверить этот триггер, выполните следующие операторы T-SQL, модифицирующие сумму продаж за год (значение в колонке ytd_sales) для книги со значением BU1111 в колонке title_id.

UPDATE titles SET ytd_sales = 123 WHERE title_id = "BU1111"

Отметим, что в выходные результаты не будут включены никакие

сообщения, указанные в операторах PRINT данного триггера. Сам триггер активизируется, так как мы модифицировали таблицу titles. Но поскольку была модифицирована колонка ytd_sales, а не колонка price, то результатом условия IF было значение FALSE. Поэтому остальные операторы данного триггера не выполнялись.

7.8 Использование триггеров AFTER

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

sp_settriggerorder [@triggername =] 'имя_триггера', [@order=] {'first' | 'last' | 'none'}

7.9 Использование вложенных триггеров

Вложенные триггеры – это триггеры, которые срабатывают из-за модификаций данных другими триггерами. SQL Server 2000 допускает до 32 уровней вложенности триггеров. Рассмотрим пример использования вложенных триггеров. В этом примере мы создадим вложенные триггеры, которые будут выполнять каскадные удаления при удалении заголовка книги из таблицы titles. Мы создали отдельный триггер, который выполняет эту операцию. Второй и третий триггеры будут вложенными триггерами. Первый триггер будет активизировать второй триггер, который будет активизировать третий триггер. Вот эта программа:

CREATE TRIGGER TR_on_titles ON titles FOR DELETE AS DELETE sales FROM sales, deleted WHERE sales.title_id = deleted.title_id PRINT "Deleted from sales" GO

53

CREATE TRIGGER TR_on_sales ON sales FOR DELETE AS DELETE roysched FROM roysched, deleted WHERE roysched.title_id = deleted.title_id PRINT "Deleted from roysched" GO CREATE TRIGGER TR_on_roysched ON roysched FOR DELETE AS DELETE titleauthor FROM titleauthor, deleted WHERE titleauthor.title_id = deleted.title_id PRINT "Deleted from titleauthor" GO

Для работоспособности этих триггеров нужно удалить ограничения

FOREIGN KEY на соответствующие таблицы. Чтобы проверить, работают ли все эти триггеры, запустите следующий оператор DELETE:

DELETE FROM titles WHERE title_id = "PS7777"

Вы увидите следующий набор результатов:

(2 row(s) affected) (1 row(s) affected) Deleted from titleauthor (2 row(s) affected) Deleted from roysched (1 row(s) affected) Deleted from sales (1 row(s) affected)

При сбое на любом уровне набора вложенных триггеров происходит

отмена всей транзакции и откат модификаций всех данных до начала данной транзакции.

7.10 Управление триггерами

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

54

sp_helptrigger, после которой укажите имя этой таблицы. Колонки результата isupdate, isdelete, isinsert, isafter и isinsteadof содержат значение 1, если триггер активизируется событием модификации данных, которое указано именем колонки, или 0 в противном случае.

Чтобы изменить определение триггера, можно удалить и заново создать соответствующий триггер или использовать оператор ALTER TRIGGER. Для удаления триггера из таблицы используйте оператор DROP TRIGGER. Если вы удаляете таблицу, то при этом автоматически удаляются все триггеры по данной таблице.

Можно использовать опцию DISABLE TRIGGER оператора ALTER TABLE чтобы запретить срабатывание триггера, не удаляя его:

ALTER TABLE Bicycle_Inventory DISABLE TRIGGER Print_Update

После этого изменения в таблице Bicycle_Inventory триггер

Print_Update не будет срабатывать, пока его не разблокируют с помощью опции ENABLE TRIGGER оператора ALTER TABLE:

ALTER TABLE Bicycle_Inventory ENABLE TRIGGER Print_Update


1. Чем отличается триггер от обычной хранимой процедуры от передачи SQL-запроса?

2. Что хранится в таблице inserted во время выполнения триггера FOR UPDATE?

3. Что произойдет,если триггер внесет изменения в данные другой таблице, к которой тоже прикреплен триггер?

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

55

8 Управление транзакциями

8.1 Транзакции и восстановление данных после сбоев

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

Транзакции должна отвечать четырем требованиям. Эти требования называют ACID-свойствами (сокращение от atomicity (атомарность), consistency (согласованность), isolation (изолированность) и durability (устойчивость)).

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

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

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

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

56

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

8.2 Уровни изолированности

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

Read uncommitted (Чтение незафиксированных данных). Самый низкий уровень изолированности. Транзакция будет видеть даже те данные, которые были изменены другой незавершившейся транзакцией.

Read committed (Чтение фиксированных данных). Принятый по умолчанию уровень для SQL Server. На этом уровне разрешается чтение только фиксированных данных. (Фиксированные данные – это данные, которые стали постоянной частью базы данных.)

Repeatable read (Повторяемость чтения). Уровень, при котором чтение одной и той же строки или строк в транзакции дает одинаковый результат. (Пока транзакция не завершена, никакие другие транзакции не могут модифицировать эти данные.)

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

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

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

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

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

57

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

В таблице 9.1 приводится список типов проблем, которые допускаются на каждом уровне изолированности. Как можно видеть из таблицы, уровень read uncommitted является наименее ограничивающим уровнем изолированности, а serializable – наиболее ограничивающим. По мере роста уровня изолированности SQL Server налагает все более ограничивающую блокировку на все более длительные периоды времени. Уровень изолированности влияет на режим блокировки, применяемый к читаемым данным.

Таблица 9.1 — Свойства уровней изолированности

Возможные проблемы

Уровень изолированности

Чтение нефиксированных

данных

Неповторяемое чтение Фантомное чтение

Read uncommitted Да Да Да Read committed Нет Да Да Repeatable read Нет Нет Да Serializable Нет Нет Нет

Уровень изолированности можно задать для конкретного запроса с

помощью подсказки блокировки, а можно задать для всех запросов в течение сеанса соединения с SQL Server. Для задания уровня изолированности для всей сессии используется оператор SET TRANSACTION ISOLATION LEVEL:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE GO

Чтобы определить, какой уровень изолированности SQL Server

применяется в данный момент, можно использовать команду DBCC USEROPTIONS.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE GO DBCC USEROPTIONS GO Set Option Value --------------------------------------------- … isolation level serializable

58

8.3 Режимы транзакций

Транзакция может начинаться в одном из трех режимов: автофиксация (autocommit), явный режим (explicit) или неявный режим (implicit). По умолчанию для SQL Server принят режим автофиксации.

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

Явный режим используется чаще всего для программных приложений, а также для хранимых процедур, триггеров и сценариев. Для запуска транзакции используется оператор BEGIN TRANSACTION. Чтобы указать конец транзакции, используется COMMIT TRANSACTION или ROLLBACK TRANSACTION. В операторе BEGIN TRANSACTION вы можете дополнительно указать имя транзакции и затем ссылаться на эту транзакцию по имени в операторе COMMIT TRANSACTION или ROLLBACK TRANSACTION. Ниже показан синтаксис этих трех операторов:

BEGIN TRAN[SACTION] [имя_транзакции | @переменная_с_именем_транзакции] COMMIT [TRAN[SACTION] [имя_транзакции | @переменная_с_именем_транзакции]] ROLLBACK [TRAN[SACTION] [имя_транзакции | @переменная_с_именем_транзакции | имя_точки_сохранения | @переменная_с_именем_точки_сохранения]]

В неявном режиме транзакция автоматически начинается при

использовании определенных операторов T-SQL и продолжается, пока не появится оператор явного окончания COMMIT или ROLLBACK. Если оператор окончания не указан, то при отсоединении пользователя происходит откат данной транзакции. Следующие операторы T-SQL являются началом новой транзакции в неявном режиме: ALTER TABLE, CREATE, DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE, UPDATE.

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

59

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

SET IMPLICIT_TRANSACTIONS {ON | OFF}

Значение ON активизирует неявный режим, и OFF отключает его.

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

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

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

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

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

8.5 Точки сохранения

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

60

освобождает блокированные ресурсы. Они будут освобождены после фиксирования транзакции или после отката всей транзакции.

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

SAVE TRAN[SACTION] {имя_точки_сохранения | @переменная_с_именем_точки_сохранения}

Поместите точку сохранения в том месте транзакции, до которого вы

хотите выполнять откат. Чтобы выполнить откат до точки сохранения, используйте ROLLBACK TRAN вместе с именем точки сохранения:

ROLLBACK TRAN имя_точки_сохранения

Вы можете использовать другие операторы T-SQL, чтобы продолжить

транзакцию. Не забудьте включить оператор COMMIT или другой оператор ROLLBACK после первого оператора ROLLBACK, чтобы завершить всю транзакцию.


1. Возможно ли неповторяемое чтение при уровне изолированности SERIALIZABLE?

2. Приведите пример фантома. 3. Какой командой задается неявный режим транзакций? 4. Что нужно сделать, чтобы отменить не всю транзакцию, а только

несколько последних ее операций?

61

9 Блокировка транзакций

9.1 Блокировка транзакций

В SQL Server используется объект, который называется блокировкой (lock); он препятствует тому, чтобы несколько пользователей одновременно вносили изменения в базу данных и чтобы один пользователь считывал данные, которые изменяет в этот момент другой пользователь. Блокировка помогает обеспечивать логическую целостность транзакций и данных. Если пользователь захватывает блокировку по какому-либо ресурсу, то эта блокировка указывает, что только данный пользователь имеет право на использование данного ресурса. К ресурсам, которые можно блокировать, относятся строка данных, страница данных, экстент (8 страниц), таблица и вся база данных.

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

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

9.2 Уровни блокировок

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

Таблица 10.1 — Блокируемые ресурсы Ресурс Тип блокировки Описание Идентификатор строки

Уровень строки Блокирует отдельную строку в таблице

Ключ Уровень строки Блокирует отдельную строку в индексе Страница Уровень

страницы Блокирует отдельную страницу размером 8 Кб в таблице или индексе

Экстент Уровень экстента Блокирует экстент – группу из 8 последовательных страниц данных или страниц индекса

Таблица Уровень таблицы Блокирует всю таблицу База данных Уровень БД Блокирует всю базу данных

SQL Server автоматически выбирает тип блокировки, подходящий для

данной задачи, минимизируя при этом затраты на блокировку. SQL Server

62

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

9.3 Режимы блокировки

Режим блокировки указывает, каким образом одновременно транзакции могут осуществлять доступ к какому-либо ресурсу. Имеется три основных режима: разделяемая блокировка (shared), блокировка изменений (update), монопольная блокировка (exclusive).

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

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

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

9.4 Блокирование и взаимоблокировки

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

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

63

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

Рисунок 9.1 — Взаимоблокировка

9.5 Подсказки блокировки

Подсказки блокировки – это ключевые слова T-SQL, которые можно использовать с операторами SELECT, INSERT, UPDATE и DELETE, чтобы указать SQL Server предпочтительный тип блокировки. Использование подсказок блокировки не влияет на уровень изолированности для других транзакций. В следующем списке приведены подсказки блокировки на уровне таблиц.

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

NOLOCK. Применяется только к оператору SELECT. Не получает разделяемых блокировок и не поддерживает монопольных блокировок; читает данные, которые монопольно захвачены другой транзакцией, в том числе незафиксированные данные (dirty read).

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

READCOMMITTED. Выполняется чтение данных с обычным блокированием уровня изолированности read committed.

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

READUNCOMMITTED. Эквивалентно NOLOCK.

64

REPEATABLEREAD. Выполняется чтение данных с обычным блокированием уровня изолированности repeatable read.

ROWLOCK. Используются блокировки на уровне строк вместо блокировки на уровне страниц или на уровне таблиц.

SERIALIZABLE. Выполняется чтение данных с обычным блокированием уровня изолированности serializable. Эквивалентно HOLDLOCK.

TABLOCK. Используется блокировка на уровне таблиц вместо блокировки на уровне страниц или на уровне строк. Блокировка сохраняется только во время выполнения данного оператора.

TABLOCKX. Используется монопольная блокировка по таблице. Эта подсказка препятствует доступу других транзакций к этой таблице.

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

Совместимые подсказки, такие как TABLOCK и REPEATABLEREAD, можно объединять. Чтобы задать подсказку, ее нужно заключить в круглые скобки после имени таблицы, например:

SELECT COUNT(ord_num) FROM sales (TABLOCKX) WHERE ord_date > "Sep 13 1994"


1. Можно ли избежать взаимоблокировок? 2. Приведите пример взаимоблокировки. 3. Как указать, что запрос не должен получать блокировки и может

читать незафиксированные данные?

65

10 Оптимизация запросов

10.1 Принципы работы оптимизатора

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

1. Лексический и синтаксический анализ, 2. Синтаксическая оптимизация, 3. Выбор оптимального плана, 4. Формирование выполняемого представления плана, 5. Выполнение плана. На первой фазе вырабатывается внутреннее представление запроса,

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

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

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

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

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

66

10.2 Оптимизация плана выполнения запроса

Наиболее вероятны улучшения от внесения изменений в план исполнения операторов JOIN, GROUP BY, ORDER BY и UNION. Вы можете легко модифицировать эти операции, пробуя различные подсказки и просматривая результаты. Изменяя подсказку и просматривая результаты в окне Query Analyzer / SQL Server Management Studio, вы, возможно, найдете более эффективный вариант выполнения оператора.

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

Использование наиболее подходящего индекса для операции является необходимым условием достижения наиболее высокой производительности. Наиболее подходящий индекс для определенной операции – это индекс, позволяющий наиболее быстро находить данные с использованием наименьшего числа операций ввода-вывода. Индексы очень важны для SQL Server, но они могут приводить к снижению производительности при неверном использовании. Следите за количеством индексов на одну таблицу – особенно при большом количестве операций для операторов INSERT, UPDATE и DELETE. Излишнее количество индексов приводит к снижению производительности для операций этого типа, поскольку модифицирование индексов сопряжено с дополнительной нагрузкой на систему. Используйте покрывающие индексы: вместо доступа к соответствующей таблице вам, возможно, удастся считывать необходимые данные из самого индекса. Снижайте количество возвращаемых строк. Определите, насколько необходимы те или иные данные, возвращаемые в результате запросов. Модифицируйте запросы T-SQL, чтобы в них выполнялся доступ только к необходимым данным. Не считывайте строки, которые будут затем отброшены. Снижение количества строк, считываемых из базы данных, может быть достигнуто в результате повышения селективности запроса.

10.3 Подсказки оптимизатору запросов

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

Подсказки для операций соединения (join hints) используются, чтобы указывать оптимизатору запросов способ выполненения соединения. В SQL Server вы можете выполнять соединение вложенными циклами (LOOP), хеш-соединение (HASH) и соединение слиянием (MERGE). При типе соединения LOOP для каждой строки внешней таблицы проверяется каждая строка

67

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

SELECT OrderID, CustomerID, Employees.EmployeeID, FirstName, LastName, OrderDate FROM Orders, Employees WHERE Orders.EmployeeID = Employees.EmployeeID OPTION (HASH JOIN)

Подсказки для запросов используются для указания того, как следует

выполнять определенные операции запроса. Подсказки GROUP BY указывают, как следует выполнять операции

GROUP BY или COMPUTE. HASH GROUP. Указывает, что для выполнения операции GROUP

BY будет использоваться хеш-функция ORDER GROUP. Указывает, что для выполнения операции GROUP

BY будет использоваться операция сортировки. Пример использования подсказки HASH GROUP:

SELECT CustomerID, SUM(OrderDetails.UnitPrice) FROM Orders, OrderDetails GROUP BY CustomerID OPTION (HASH GROUP)

Подсказки UNION используются для указания того, как следует

выполнять операции UNION. MERGE UNION. Для выполнения операции UNION используется

операция MERGE. HASH UNION. Для выполнения операции UNION используется

хеш-функция. CONCAT UNION. Для выполнения операции UNION используется

функция конкатенации. Пример использования подсказки CONCAT UNION:

SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM orders WHERE CustomerID = 'TOMSP' UNION SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM orders WHERE EmployeeID = '4' OPTION (CONCAT UNION)

68

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

FORCE ORDER. Указывает, что доступ к таблицам должен выполняться в том же порядке, как они представлены в запросе. По умолчанию SQL Server может изменять порядок следования таблиц.

ROBUST PLAN. Указывает, что оптимизатор запросов должен быть готов к максимально возможному размеру строк. Вот пример использования этой подсказки:

SELECT OrderID, CustomerID, Employees.EmployeeID, FirstName, LastName, OrderDate FROM Orders, Employees WHERE Orders.EmployeeID = Employees.EmployeeID OPTION (ROBUST PLAN)

Подсказки для таблиц используются, чтобы управлять способом

доступа к таблицам. Здесь описаны две подсказки для таблиц. FAST n. Заменяет FASTFIRSTROWS, сохраненную для обратной

совместимости. Эта подсказка указывает SQL Server, что нужно оптимизировать выборку n первых строк данных.

INDEX = имя_индекса. Указывает оптимизатору запросов, что нужно использовать указанный индекс, когда имеется такая возможность. В одном из первых примеров этой лекции показано, как использовать подсказку INDEX. Мы повторяем здесь этот пример:

SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM orders WITH (INDEX = EmployeeID) WHERE EmployeeID = 5 OPTION (FAST 10)

Квалификатор WITH не является обязательным. Подсказка INDEX = EmployeeID указывает, что должен использоваться

индекс EmployeeID. Если указана подсказка FAST 10, то SQL Server будет оптимизировать выборку первых 10 строк (если возможно) и затем будет возвращать остальные строки.

10.4 Оптимизация с использованием SQL Server 2000 Index Tuning

Wizard и SQL Server 2005 Database Tuning Advisor

Помимо ручной настройки запросов и индексов, SQL Server 2000 и 2005 предоставляют автоматизированные средства настройки индексов. Запрос, который мы проанализируем с помощью SQL Server 2000 Index Tuning Wizard:

SELECT DISTINCT t.date AS c0, c.prefijoext AS c1,

69

c.numeroext AS c2, c.checkbook AS c3 FROM Transac t (nolock)

JOIN cmpasociados c (nolock) ON t.nrotrans = c.nrotrans JOIN tiposcmp you (nolock) ON c.codcmp = you.codcmp JOIN checkbooks so (nolock)

ON c.checkbook = so.checkbook AND t.codemp = so.codemp WHERE T.Nrotranselim is null AND ( CASE WHEN T.Codcmp IN ( ' CA', ' CC', ' CB', ' CE' ,' LR',

' LO', ' LP', ' CZ' ,' VA', ' VB', ' VC', ' YOU' ,' VZ' )

THEN T.Nrotransaut WHEN T.Codcmp IN (' IÉ', ' EÉ', ' RD')

THEN T.Nrotransctrl ELSE T.Nrotrans END ) IS NOT NULL AND

(t.CodEmp IS NULL OR t.codemp = 1) AND c.checkbook = 25 AND t.codsuc = 1 ORDER BY C2 DESC

Этот запрос, скопированный в Query Analyzer, имел план исполнения,

показанный на рисунке 10.1. Статистика выполнения запроса показала следующие значения:

170259 row(s) affected) Table ' TRANSAC'. Scan count 1, logical reads 31004, physical reads 1065, read-ahead reads 29512. Table ' CMPASOCIADOS'. Scan count 1, logical reads 8482, physical reads 0, read-ahead reads 4393. Table ' TIPOSCMP'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 2. Table ' TALONARIOS'. Scan count 1, logical reads 2, physical reads 2, read-ahead reads 0.

После запуска ITW, были получены следующие рекомендации по индексам: CREATE NONCLUSTERED INDEX [ IXC2000_TRANSAC27 ] ON [ dbo ].[ TRANSAC ] ( [ NROTRANS ] ASC , [ DATE ] ASC ,[ CODCMP ] ASC , [ NROTRANSELIM ] ASC ,[ CODSUC ] ASC ,[ NROTRANSAUT ] ASC , [ CODEMP ] ASC ,[ NROTRANSCTRL ] ASC ) CREATE NONCLUSTERED INDEX [ IXC2000_CMPASOCIADOS28 ] ON [ dbo ].[ CMPASOCIADOS ] ( [ NROTRANS ] ASC ,[ CODCMP ] ASC ,[ CHECKBOOK ] ASC , [ PREFIJOEXT ] ASC ,[ NUMEROEXT ] ASC )

Ожидаемое улучшение при использовании этих индексов составляло

52 %. После применения индексов, получился план исполнения, показанный на рисунке 10.2.

70

Рисунок 10.1 — Исходный план выполнения запроса на SQL Server 2000

Рисунок 10.2 — План выполнения запроса после выполнения рекомендаций ITW

Cтатистика данных после создания индексов выглядела так:

(170259 row(s) affected) Table ' CMPASOCIADOS'. Scan count 1, logical reads 2162, physical reads 0, read-ahead reads 0. Table ' TRANSAC'. Scan count 1, logical reads 1889, physical reads 0, read-ahead reads 24. Table ' TIPOSCMP'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0. Table ' TALONARIOS'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0.

71

Как можно видеть, улучшения очевидны. Число логических чтений в таблице TRANSAC было сокращено с 31004 до 1889.

Повторяем анализ, используя SQL Server 2005 Database Tuning Advisor. Сначала удалим созданные ранее индексы, а затем проанализируем те же самые запрос и данные, используя DTA. В этом случае, план исполнения выглядел так (см. рисунок 10.3):

Рисунок 10.3 — Исходный план выполнения запроса на SQL Server 2005

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

следующей:

Table ' TRANSAC'. Scan count 1, logical reads 31004, physical reads 0, read-ahead reads 31008. Table ' CMPASOCIADOS'. Scan count 1, logical reads 8482, physical reads 19, read-ahead reads 4482. Table ' TIPOSCMP'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 2. Table ' TALONARIOS'. Scan count 1, logical reads 2, physical reads 2, read-ahead reads 0. (170259 row(s) affected)

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

оптимизации, минимальны, что и ожидалось. После этого DTA предложил создать следующие ниже индексы, ожидая улучшения на 78 %.

CREATE NONCLUSTERED INDEX [ IXC2005_TRANSAC_6_98099390__K10_K30_K81_K1_K2_K105_K3_K55 ] ON [ dbo ].[ TRANSAC ] ( [ NROTRANSELIM ] ASC ,[ CODSUC ] ASC ,[ CODEMP ] ASC , [ NROTRANS ] ASC ,[ DATE ] ASC ,[ NROTRANSCTRL ] ASC , [ CODCMP ] ASC ,[ NROTRANSAUT ] ASC ) CREATE NONCLUSTERED INDEX [IXC2005_CMPASOCIADOS_6_437576597__K3_K1_K2_K8_K7 ] ON [ dbo ].[ CMPASOCIADOS ] (

72

[ CHECKBOOK ] ASC ,[ NROTRANS ] ASC ,[ CODCMP ] ASC , [ NUMEROEXT ] ASC ,[ PREFIJOEXT ] ASC )

Уже здесь мы наблюдаем некоторые различия. С одной стороны,

процент улучшения у ITW был 52 %, а у DTA - 78 %. С другой стороны, стоит обратить внимание на то, что предложенные индексы имеют различия.

Используем таблицу TRANSAC, и рассмотрим первые три поля. ITW предлагает следующий порядок полей в индексе: NroTrans, Date и Codcmp. В то же время, DTA предлагает другой порядок: NroTranselim, CodSuc и CodEmp.

То же самое и с таблицей CMPASOCIADOS. У ITW три первых поля: NroTrans, Codcmp и Checkbook, тогда как DTA предлагает: Checkbook, NroTrans и CodCmp.

После создания предложенных индексов получаем следующий план исполнения (см. рисунок 10.4):

Рисунок 10.4 — План выполнения запроса после выполнения рекомендаций DTA

Статистика, полученная после выполнения запроса с новыми

индексами, следующая:

Table ' CMPASOCIADOS'. Scan count 1, logical reads 619, physical reads 0, read-ahead reads 0. Table ' TRANSAC'. Scan count 1, logical reads 1757, physical reads 0, read-ahead reads 16. Table ' TIPOSCMP'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0. Table ' TALONARIOS'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0. (170259 row(s) affected)

73

Здесь, мы видим очень схожие цифры ITW и DTA для таблицы TRANSAC, но большие различия статистики для таблицы CMPASOCIADOS.

В то время, как оптимизация с помощью ITW дала 2162 логических чтений, после оптимизации DTA их осталось только 619.

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

После перезапуска сервера и выполнения в Query Analyzer запрос, была получена следующую статистика:

(170259 row(s) affected) Table ' CMPASOCIADOS'. Scan count 1, logical reads 619, physical reads 0, read-ahead reads 0. Table ' TRANSAC'. Scan count 1, logical reads 1757, physical reads 0, read-ahead reads 0. Table ' TIPOSCMP'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 2. Table ' TALONARIOS'. Scan count 1, logical reads 2, physical reads 2, read-ahead reads 0.

Как можно видеть, статистика фактически та же самая, поэтому можно

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


1. Как происходит выбор оптимального плана выполнения запроса? 2. Как можно подобрать наилучший индекс для выполнения запроса. 3. Какая подсказка позволяет потребовать использования конкретного

индекса? 4. По каким критериям можно оценить изменение эффективности

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

74

11 Управление защитой данных

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

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

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

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

Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу. Чаще всего аутентификация осуществляется с помощью ввода имени пользователя и пароля.

Для доступа к SQL Server можно использовать два режима аутентификации: режим аутентификации Windows (Windows Authentication) и режим смешанной аутентификации (Mixed Mode Authentication). В первом случае аутентификация пользователя осуществляется операционной системой Windows. Затем SQL Server использует аутентификацию этой операционной системы, чтобы определить, какие пользовательские полномочия можно применять в каждом случае. В смешанном режиме аутентификацию пользователя осуществляют как Windows, так и SQL Server.

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

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

75

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

Аутентификация с помощью SQL Server предназначена главным образом для клиентских приложений, функционирующих на платформах, отличных от Windows. Этот способ считается менее безопасным, но в SQL Server 2005 он поддерживает шифрование всех сообщений, которыми обмениваются клиент и сервер, в том числе с помощью сертификатов, сгенерированных сервером. Шифрование также повышает надежность этого способа аутентификации. Для учетной записи SQL Server можно указать такой параметр, как необходимость сменить пароль при первом соединении с сервером. Если SQL Server 2005 работает под управлением Windows Server 2003, можно воспользоваться такими параметрами учетной записи, как проверка срока действия пароля и локальная парольная политика Windows.

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

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

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

Для упрощения управления правами доступа в большинстве серверных СУБД применяется механизм ролей — наборов прав доступа к объектам

76

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

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

11.3 Учетные записи и пользователи

Независимо от используемого режима аутентификации (аутентификация Windows или режим смешанной аутентификации) учетная запись, которую вы используете для подсоединения к SQL Server, называется login-записью SQL Server. Кроме этой учетной записи, каждая база данных имеет набор пользовательских учетных псевдозаписей, присвоенных этой базе данных. Эти учетные псевдозаписи являются псевдонимами для учетных login-записей SQL Server. Например, в базе данных у вас может быть пользователь с именем manager, связанный с login-записью guest, а база данных pubs может иметь пользователя с именем manager, связанного с login-записью sa. По умолчанию учетная login-запись SQL Server не имеет связанного с ней идентификатора пользователя (user ID); тем самым она не содержит никаких полномочий доступа.

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

77

sp_addlogin [ @loginame = ] 'имя_login-записи' [ , [ @passwd = ] 'пароль' ] [ , [ @defdb = ] 'база данных' ] [ , [ @deflanguage = ] 'язык' ] [ , [ @sid = ] 'sid' ] [ , [ @encryptopt = ] 'параметр_шифрования' ]

Используются следующие необязательные параметры. пароль. Указывает пароль login-записи для SQL Server. Значение по

умолчанию – NULL. база данных. Указывает базу данных по умолчанию для login-

записи. Значение по умолчанию – master. язык. Указывает язык по умолчанию для login-записи. Значение по

умолчанию – текущий язык для SQL Server. sid. Указывает идентификатор безопасности (SID), который является

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

параметр_шифрования. Указывает, будет ли шифроваться пароль в системных таблицах. Значение по умолчанию – NULL, означающее, что пароль будет шифроваться. Значение skip_encryption (пропустить шифрование) означает, что пароль не будет шифроваться. Если указать значение skip_encryption_old, то пароль, зашифрованный в более ранней версии SQL Server, не будет шифроваться еще раз. Вам следует изменять значение по умолчанию, только если вы хотите избежать шифрования пароля в системных таблицах.

Ниже приводится пример добавления login-записи:

sp_addlogin 'SharonR', 'mypassword', 'Northwind', 'us_english' Эта команда создает пользователя с именем SharonR и паролем

"mypassword." По умолчанию будет использоваться база данных Northwind, и язык по умолчанию – U.S. English.

Хранимая процедура sp_grantlogin имеет следующий синтаксис:

sp_grantlogin 'имя_login-записи'

78

Чтобы создать пользователя SQL Server, у вас уже должна быть создана login-запись SQL Server, поскольку имя пользователя должно быть связано с login-записью.Для создания пользователя базы данныхслужит хранимая процедура sp_adduser:

sp_adduser [ @loginame = ] 'имя_login-записи' [ , [ @name_in_db = ] 'пользователь' ] [ , [ @grpname = ] 'группа' ]

Имя_login-записи – это имя учетной login-записи SQL Server, которое

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

11.4 Администрирование полномочий доступа к базам данных

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

Полномочия на уровне сервера присваиваются DBA и позволяют им выполнять задачи администрирования. Эти полномочия определяются по фиксированным ролям сервера. Пользовательским login-записям могут быть присвоены фиксированные роли на сервере, но эти роли нельзя модифицировать. К полномочиям на сервере относятся полномочия SHUTDOWN, CREATE DATABASE, BACKUP DATABASE и CHECKPOINT. Полномочия на сервере используются только для авторизации DBA, чтобы они могли выполнять административные задачи; их не нужно модифицировать или предоставлять отдельным пользователям.

Полномочия на уровне объектов базы данных – это класс полномочий, которые предоставляются для доступа к объектам базы данных. Полномочия доступа к объектам необходимы для доступа к таблице или представлению с помощью таких операторов, как SELECT, INSERT, UPDATE и DELETE. Полномочия доступа к объектам также требуются для использования оператора EXECUTE, который применяется для запуска хранимых процедур.

Для присваивания пользователю полномочий доступа к объектам служит оператор GRANT:

GRANT { ALL | полномочия } [ колонка ON {таблица | представление} ] | [ ON таблица(колонка) ] | [ ON представление(колонка) ] | [ ON { хранимая_процедура | расширенная_процедура } ] TO учетная_запись_безопасности [ WITH GRANT OPTION ] [ AS { группа | роль } ]

79

Параметр учетная_запись_безопасности может быть представлен

одним из следующих типов учетных записей: Пользователь SQL Server. Роль SQL Server. Пользователь Windows. Группа Windows. Использование ключевого слова GRANT OPTION позволяет

пользователю или пользователям, указанным в данном операторе, предоставлять указанный тип полномочий другим пользователям. Это может оказаться полезным, если вы предоставляете полномочия другим DBA. Однако GRANT OPTION следует использовать с осторожностью.

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

Для отзыва полномочий пользователя используется оператор REVOKE:

REVOKE [ GRANT OPTION FOR ] { ALL [ PRIVILEGES ] | полномочия } [ колонка ON {таблица | представление} ] | [ ON таблица(колонка) ] | [ ON представление(колонка) ] | [ ON { хранимая_процедура | расширенная_процедура } ] { TO | FROM } учетная_запись_безопасности [ CASCADE ] [ AS { группа | роль } ]

Ключевое слово GRANT OPTION FOR позволяет отзывать

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

Кроме полномочий доступа к объектам баз данных, вы можете также предоставлять полномочия на использование операторов. Полномочия доступа к объектам позволяют пользователям выполнять доступ к существующим объектам базы данных, в то время как полномочия на использование операторов позволяют им создавать объекты баз данных, включая базы данных и таблицы. Для предоставления полномочий на использование операторов применяется тот же оператор GRANT. Пользователю могут быть предоставлены полномочия на использование операторов CREATE DATABASE, CREATE DEFAULT, CREATE PROCEDURE, CREATE RULE, CREATE TABLE, CREATE VIEW, DROP TABLE, DROP VIEW, BACKUP DATABASE и BACKUP LOG,.

80

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

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

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

Для выполнения задач создания и модифицирования ролей баз данных используются те же средства, что и для выполнения большинства задач, относящихся к администрированию баз данных: Enterprise Manager или операторы T-SQL. Вы можете создавать роли с помощью хранимой процедуры sp_addrole. Эта хранимая процедура имеет следующий синтаксис:

sp_addrole [ @rolename = ] ''роль' [ , [ @ownername = ] 'владелец' ]

Если не указать базу данных, то роль будет создана в базе данных,

принятой у вас по умолчанию. Эта хранимая процедура только создает роль. Чтобы добавить полномочия к этой роли, используйте описанный выше оператор GRANT. Для удаления полномочий из роли используйте оператор REVOKE, также описанный выше в этой лекции.

Чтобы добавить пользователей к этой роли, используйте хранимую процедуру sp_addrolemember. Хранимая процедура sp_addrolemember имеет следующий синтаксис:

sp_addrolemember 'роль', 'учетная_запись_безопасности'

Во время инсталляции SQL Server создается ряд заранее определенных

ролей, которые применяются на уровне сервера. Эти фиксированные роли на сервере используются для предоставления полномочий DBA; они могут

81

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

bulkadmin. Позволяет выполнять массовые вставки. dbcreator. Позволяет создавать и изменять базы данных. diskadmin. Позволяет управлять файлами на дисках. processadmin. Позволяет управлять процессами SQL Server. securityadmin. Позволяет управлять login-записями и создавать

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

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

процедурами запуска. sysadmin.Позволяет выполнять любые операции на сервере. Присваивая пользовательские учетные записи фиксированным ролям

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

11.6 Распространенные ошибки при защите сервера БД

Ошибки при организации системы безопасности можно разделить на три категории:

Ошибки администрирования Ошибки программирования Ошибки реализации SQL Server Примером ошибок первой категории являются: открытый в Интернет

порт 1434, пустой пароль учетной записи sa. Для борьбы с подобного рода ошибками следует установить четкую политику безопасности в организации, согласно которой будет происходить администрирование ИС, включая администрирование СУБД. Необходимо отметить, что одним лишь корректным администрированием сервера баз данных невозможно обеспечить целостность и безопасность информации. Проблему следует рассматривать комплексно.

Примером ошибок второй категории может служить конструирование SQL запросов в приложении "на лету" на основе непроверенного пользовательского ввода и отправка таких запросов серверу СУБД. Для борьбы с такими ошибками можно использовать четкие стандарты кодирования и периодические обзоры программных решений.

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

82

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

11.7 Внедрение SQL кода (SQL Injection)

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

... Set rs = cn.Execute("SELECT password FROM dbo.Users WHERE email = '" &_ Request.Form("email") & "'") ... objMail.To = Request.Form("email") objMail.Send(rs("password")) ...

Нетрудно видеть, что через поле формы email можно изменить логику

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

[email protected]' OR email=';[email protected]

Запрос будет выглядеть так:

SELECT password FROM dbo.Users WHERE email = '[email protected]' OR email=';[email protected]'

что приведет к тому, что будет выбран пароль Пользователя с адресом [email protected], но отправлен он будет, скорее всего, по адресу [email protected], т.к. многие почтовые компоненты считают символ ; разделителем адресов. Этот сценарий будет работать в случае, если запросы строятся динамически и без проверки пользовательского ввода. Если же приложение работает под учетной записью, обладающей большими привилегиями в SQL Server, то последствия могут быть еще печальнее, вплоть до получения контроля над машиной, где работает SQL Server:

'; EXEC master.dbo.xp_cmdshell 'net user john pass /add && net localgroup Administrators john /add

Пользуясь подобными ошибками, злоумышленник может раскрыть

схему таблиц, механизм подробно описан в документе "Web Application Disassembly with ODBC Error Messages", автор David Litchfield. Кроме того, в ряде случаев такие ошибки сводят на нет все усилия по защите сети через брандмауэр, т.к. атака может идти поверх HTTP, а для обмена данными, проникновения во внутреннюю сеть может использоваться SQL Server

83

злоумышленника, выступающий в качестве присоединенного сервера. Об этом можно прочесть в документе "Manipulating Microsoft SQL Server Using SQL Injection", автор Cesar Cerrudo. Например, может быть использован такой запрос для получения списка баз на другом SQL сервере:

SELECT * FROM OPENROWSET('SQLOLEDB', 'Server=INTERNAL_SQL_SERVER;UID=sa;PWD=password;', 'select * from sysdatabases')

При этом могут использоваться также и удаленные и присоединенные

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

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

записями (sysadmin, db_owner и т.п.) SQL Server. Не запускать SQL Server под привилегированными учетными записями операционной системы (LocalSystem, Administrators group member и т.п.).

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

CREATE PROCEDURE dbo.GetUsers @Field varchar(100) AS SET NOCOUNT ON EXEC ('SELECT UserID, Username, FirstName, LastName FROM dbo.Users ORDER BY ' + @Field) RETURN

Вызов ("опасный"):

EXECUTE dbo.GetUsers '1; EXEC master.dbo.xp_cmdshell [net user john /add && net localgroup Administrators john /add]'

Использовать параметризованные запросы Использовать регулярные выражения для проверки

пользовательского ввода до того, как он будет отправлен в СУБД. В случае несоответствия ввода и шаблона выдавать сообщение об ошибке клиенту, оставлять запись об ошибке (ни в коем случае не показывать клиенту ошибки SQL Server'а!) в журнале приложения и прекращать выполнение запроса.

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

strEmail = Replace(Request.Form("Email"), "'", "''")

84

11.8 Защита SQL Server в Интернет

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

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

Закройте прочие порты, используемые для работы с SQL Server. В частности, необходимо закрыть порт 1434, используемый службой SQL Server Resolution Service, закрыть порт 445, служащий в Windows 2000 для работы по протоколу SMB.

Используйте шифрование потоков данных в сети: встроенное в SQL Server (SSL) либо встроенное в операционную систему (IPSec), либо стороннее, например, SHH туннель.

Не запускайте на машине с SQL Server никаких приложений кроме самого SQL Server. Особенно это касается Web серверов, FTP серверов и т.п.

Не используйте машину с SQL Server в качестве контроллера домена.

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

опасных (xp_cmdshell, sp_OA*, xp_reg* и т.п.) процедуры либо выдайте запрет на их исполнение рядовым пользователям.

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

Устанавливать только необходимые компоненты. Например, если Вам не потребуется репликация, то не устанавливайте соответствующий компонент SQL Server.

Ведите аудит всех попыток соединения. Ведите аудит событий безопасности в операционной системе. Если есть возможность установить специализированную систему защиты и уведомления о нападениях (Intrusion Detection System) - установите ее.

Корректно раздайте права на доступ к системным каталогам и файлам.

Используйте файловую систему NTFS. Следите за "заплатками" и пакетами обновления и устанавливайте

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

85

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

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

Никогда не используйте одни и те же пароли на разных машинах. Выбирайте "сильные" пароли.

Удалите неиспользуемые сетевые протоколы из Server Network Utility.

Установите отсылку уведомлений (Alerts) о событиях типа Access Denied ответственному персоналу.

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


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

2. Какой режим аутентификации SQL Server предпочтительнее при доступе через Интернет?

3. Для чего служат роли? 4. В чем разница между полномочиями доступа к объектам баз данных

и полномочиями на использование операторов SQL?

86

12 Резервное копирование и восстановление данных

12.1 Основные понятия резервного копирования

Операции резервного копирования (backup) и восстановления (restore) связаны друг с другом и предполагают сохранение информации базы данных для использования в будущем. При восстановлении данных из резервной копии они копируются назад в базу данных. Не путайте восстановление базы данных из резервной копии (restore) с восстановлением после сбоя (recovery): это две различные операции. Восстановление после сбоя — это способность СУБД восстановить целостность данных после сбоя системы, повторно выполнить зафиксированные транзакции и удалить следы отмененных транзакций.

СУБД обычно не выполняет запись на диск после каждого изменения, вносимого в базу данных. Именно поэтому база данных после отказа системы может оказать испорченной: некоторые изменения, внесенные в базу данных, могли быть не записаны на диск, а изменения, записанные на диск, могли быть не зафиксированы. Для поддержки целостности базы данных SQL Server протоколирует все изменения в журнале транзакций. При запуске SQL Server после отказа системы журнал транзакций используется для повторного выполнения транзакций, которые были зафиксированы, но не записаны на диск, и отмены результатов транзакций, которые не были зафиксированы на момент аварии системы.

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

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

Транзакции, которые внесли изменения в данные базы данных и были фиксированы, но не были записаны на диск. Во время воспроизведения SQL Server читает страницы данных с диска, снова вносит изменения и затем перезаписывает эти страницы на диск.

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

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

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

87

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

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

Транзакция, откат которой выполняет SQL Server, идентична транзакции, которая заканчивается командой ROLLBACK. Эта транзакция аннулируется, и все соответствующие данные восстанавливаются к их исходному состоянию.

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

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

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

Отказ ЦП (CPU), памяти или шины (магистрали) данных. Эти отказы обычно приводят к аварийному отказу системы. После замены неисправного компонента и перезапуска системы SQL Server автоматически выполняет воспроизведение базы данных. Собственно база данных не затрагивается таким отказом, поэтому ее восстановление (с резервной копии) не требуется; SQL Server просто должен воспроизвести потерянные транзакции

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

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

88

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

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

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

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

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

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

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

89

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

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

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

12.2 Журнальное протоколирование в SQL Server

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

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

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

90

выполняется в фоновом режиме и не виден пользователю. Поскольку модифицированные страницы хранятся в кэше, то может пройти существенный период времени, прежде чем эти страницы (их еще называют ожидающими, черновыми страницами – dirty pages) будут записаны соответствующим потоком (подпроцессом) SQL Server. Этот поток называют потоком откладываемой записи ("ленивым" потокомЭтот поток использует LRU-список записи страниц, где первой в очереди записи на диск находится наиболее давно обрабатывавшаяся страница и последней является только что обрабатывавшаяся страница. Страница, которая постоянно модифицируется (и, тем самым, все вр емя перемещается в конец этого списка), вообще может быть не записана этим потоком на диск. Подобные вещи могут увеличивать время воспроизведения, поскольку для применения изменений к таким данным потребуется прочитать много журнальных записей. Например, в большой системе с объемом RAM-памяти более 1 Гб и большим числом изменений в базе данных воспроизведение может занять несколько часов. – lazywriter thread).

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

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

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

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

91

Журнал транзакций имеет следующие характеристики. Обработка журнала транзакций отличается от обработки обычного

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

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

Для журнала транзакций теперь можно использовать несколько файлов. Эти файлы также можно сконфигурировать для автоматического роста. Для файлов журнала транзакций не используется расслоение данных (striping); они используются друг за другом. (Расслоение данных описывается в лекции 5.)

Журнал транзакций можно перемещать на другие системы для его воспроизведения на резервной системе. Это средство называется доставкой журнала транзакций (log shipping) и подробно описывается в следующей лекции.

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

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

SELECT INTO BULK COPY и программа массового копирования (BCP) CREATE INDEX Определенные текстовые операции

92

Чтобы активизировать непротоколируемые массовые операции с определенной базой данных, вы должны задать для работы этой базы данных режим воспроизведения BULK_LOGGED. Кроме этого режима, можно также задавать режимы воспроизведения FULL и SIMPLE. Эти режимы задаются с помощью команды ALTER DATABASE.

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

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

Оператор SELECT INTO используется для создания новой таблицы в базе данных. Поскольку оператор SELECT INTO нельзя использовать для выборки данных в существующий объект, его можно использовать только для создания данных, но не для обновления данных. Этот процесс создания можно легко повторить; поэтому операции SELECT INTO вполне подходят для выполнения как непротоколируемые операции.

Чтобы операции BULK COPY и BCP можно было выполнять как непротоколируемые операции, они должны отвечать следующим требованиям.

Для параметра базы данных select into/bulkcopy должно быть задано значение TRUE.

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

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

Чтобы задать блокировку на уровне таблиц, должна быть указана подсказка TABLOCK.

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

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

93

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

К текстовым операциям, которые можно выполнять как непротоколируемые операции, относятся WRITETEXT и UPDATETEXT. Чтобы активизировать выполнение этих операций без протоколирования, вам нужно просто использовать описанный выше режим BULK_LOGGED.

12.3 Контрольные точки

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

Контрольные точки создаются в результате запуска оператора CHECKPOINT, при отключении SQL Server с помощью оператора SHUTDOWN или с помощью Service Control Manager, а также при автоматическом запуске операции контрольной точки из SQL Server.

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

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

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

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

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

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

94

данных в случае отказа системы. Значение 0 указывает, что интервал будет определять SQL Server (обычно он меньше 1 минуты). Для систем с большим объемом памяти, где выполняется очень много операций вставки и обновления, это принятое по умолчанию значение может приводить к созданию излишнего числа контрольных точек. В этом случае вы можете задать для этого параметра более высокое значение. Если ваши пользователи готовы ждать достаточно долго в случае отказа системы (например, 30 минут), производительность транзакций вашей системы будет выше. Значение этого параметра зависит от допустимости простоев в вашей компании и возможной частоты отказов системы.

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

12.4 Методы резервного копирования

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

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

Разностное резервное копирование позволяет вам выполнять резервное копирование только той информации, которая изменилась с момента

95

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

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

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

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

12.5 Выполнение резервного копирования

Вы можете выполнять резервное копирование с помощью Enterprise Manager, команд T-SQL или мастера создания резервной копии базы данных Create Database Backup Wizard. Сами операции резервного копирования можно направлять на физическое устройство или логическое устройство. Физическое устройство – это компонент оборудования, такой как ленточное или дисковое устройство. Операционная система присваивает физическим устройствам имена, и для доступа к этим устройствам вы должны использовать эти имена. Поскольку эти заранее назначенные имена бывает трудно запомнить, вам может потребоваться создание для физического устройства алиаса (определенного пользователем альтернативного имени). Такой алиас называют логическим устройством. Это логическое устройство

96

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

Для создания устройства резервного копирования с помощью T-SQL используйте хранимую процедуру sp_addumpdevice. Она имеет следующий синтаксис:

sp_addumpdevice тип_устройства, логическое_имя, физическое_имя

Значением параметра тип_устройства может быть disk для дискового

устройства, tape для ленточного устройства или pipe для подсоединения программного обеспечения сторонних форм к системе резервного копирования. Параметр логическое_имя – это имя, которое вы присваиваете данному устройству; это имя используется для ссылки на устройство в операторах BACKUP и RESTORE. Параметр физическое_имя – это имя, присвоенное системой устройству или файлу.

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

BACKUP DATABASE. Используется для резервного копирования всей базы данных либо файла или группы файлов.

BACKUP LOG. Используется для резервного копирования журнала транзакций.

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

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

BACKUP DATABASE имя_базы_данных TO устройство_резервного_копирования [ WITH необязательные параметры ]

Для этого оператора обязательными параметрами являются только имя

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

следующий синтаксис:

BACKUP DATABASE имя_базы_данных

97

имя_файла или имя_группы_файлов [,...n] TO устройство_резервного_копирования [ WITH необязательные параметры ]


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

Оператор для резервного копирования журнала транзакций имеет следующий синтаксис:

BACKUP LOG имя_базы_данных { [ WITH \ NO_LOG | TRUNCATE_ONLY )]} | { TO устройство_резервного_копирования } [ WITH необязательные параметры ]


базы данных и параметр WITH NO_LOG или WITH TRUNCATE_ONLY либо имя устройства резервного копирования. Вы можете затем добавлять любые нужные вам параметры. Параметры NO_LOG и TRUNCATE ONLY является синонимами; оба указывают усечение журнала без создания его резервной копии. Если вы используете любой из этих параметров в вашем операторе BACKUP LOG, то в случае отказа системы вы не сможете воспроизвести базу данных к состоянию, в котором она находилась в момент отказа, поскольку не будут сохранены записи журнала. Применение этих параметров не рекомендуется; используйте их на свое собственное усмотрение.

Во всех трех указанных командах резервного копирования имя_базы_данных представляет базу данных, для которой будет создана резервная копия. Устройство_резервного_копирования – это имя логического устройства резервного копирования или имя физического устройства. Если указано физическое устройство, то имени устройства должен предшествовать текст DISK =, TAPE = или PIPE = (в зависимости от типа устройства). Вы можете задать одно устройство или набор разделенных запятыми устройств.

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

Таблица 12.1 — Необязательные параметры оператора BACKUP Параметр Описание BLOCKSIZE Этот параметр указывает размер физического блока в байтах DESCRIPTION Этот параметр указывает текстовое описание набора

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

DIFFERENTIAL Этот параметр указывает разностное резервное копирование. Его можно использовать только при наличии полной резервной копии базы данных

EXPIREDATE = дата Параметр EXPIREDATE указывает дату, когда истекает срок

98

RETAINDAYS = дни действия данного набора резервного копирования (и когда его можно перезаписывать).

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

PASSWORD = пароль Параметр PASSWORD позволяет вам задавать пароль для резервной копии, что повышает безопасность самой резервной копии

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

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

MEDIADESCRIPTION = текст

Это текстовое поле задает описание набора носителей

MEDIANAME= имя_носителя

Указывает имя носителя

MEDIAPASSWORD = пароль

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

NAME= имя_набора_ резервной_копии

Этот параметр позволяет вам задавать имя набора резервной копии

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

NO_TRUNCATE Этот параметр запрещает усечение журнала транзакций после создания резервной копии. Используется только для резервного копирования журнала транзакций

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

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

STATS [ = процент ] Этот параметр указывает вывод сообщения после выполнения определенного процента резервного копирования. Его полезно использовать, если вы любите следить за ходом выполнения операций

Проследите за тем, что вы задали, – добавление резервной копии к

существующим данным носителя или перезапись данных носителя, как это

99

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

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

12.6 Планирование резервного копирования

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

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

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

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

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

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

100

Следующие рекомендации по выполнению резервного копирования, возможно, окажутся полезны.

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

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

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

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

Создавайте резервные копии системных таблиц. Не забывайте периодически выполнять резервное копирование системных баз данных, таких как master и msdb.

12.7 Основы восстановления данных

Тип выполненного резервного копирования влияет на характер операции восстановления. Восстановление из полной резервной копии – это довольно простой процесс: вы просто восстанавливаете БД из файлов. Если вы планируете восстановление из дифференциальных или инкрементальных резервных копий после восстановления из полной резервной копии, то не забывайте создавать резервную копию текущего журнала транзакций, и задавать параметр NORECOVERY, когда выполняете восстановление (параметр RECOVERY указывает SQL Server, что после окончания операции восстановления нужно попытаться воспроизвести базу данных с помощью оперативного журнала транзакций).

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

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

101

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

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

1. Выполните резервное копирование текущего активного журнала транзакций, используя параметр NO_TRUNCATE.

2. Восстановите последнюю полную резервную копию. 3. Восстановите все инкрементальные резервные копии для возврата

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

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

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

Если ваша база данных работает в режиме воспроизведения BULK_LOGGED, то вы должны повторно выполнить операции массовой загрузки (SELECT...INTO, BULK COPY, CREATE INDEX, а также текстовые операции).

12.8 Оператор RESTORE

Оператор RESTORE имеет две следующие формы. RESTORE DATABASE. Восстановление всей базы данных либо

файла или группы файлов RESTORE LOG. Восстановление журнала транзакций Выбор оператора зависит от типа выполняемой вами операции

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

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

RESTORE DATABASE имя_базы_данных [ FROM устройство_резервного_копирования ] [ WITH необязательные параметры ]


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

синтаксис:

RESTORE DATABASE имя_базы_данных

102

[FILE = имя_файла ] [FILEGROUP = имя_группы_файлов ] [ FROM устройство_резервного_копирования ] [ WITH необязательные параметры ]


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

Оператор RESTORE для восстановления журнала транзакций имеет следующий синтаксис:

RESTORE LOG имя_базы_данных [ FROM устройство_резервного_копирования ] [ WITH необязательные параметры ]

Во всех этих операторах имя_базы_данных представляет базу данных, для которой будет выполнено восстановление. Устройство_резервного_копирования – это имя логического устройства резервного копирования или имя физического устройства. Если указано физическое устройство, то имени устройства должен предшествовать тип устройства, т.е. DISK =, TAPE = или PIPE =. Вы можете задать одно или несколько устройств. (Имена нескольких устройств разделяются запятыми.)

Если вы не указываете предложение FROM, то восстановление не происходит, но все же происходит воспроизведение (если не задан параметр NORECOVERY). Этот метод можно использовать для установки базы данных в режим воспроизведения без восстановления каких-либо дополнительных данных. Например, вы можете выполнить несколько операций восстановления из разностных резервных копий и затем запустить операцию RESTORE без предложения FROM, чтобы задать для базы данных режим воспроизведения, запустив тем самым процесс воспроизведения.

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

Таблица 12.2 — Необязательные параметры оператора RESTORE Параметр Описание RESTRICTED_USER Задает ограничение доступа к вновь восстановленной базе

данных, чтобы разрешать доступ только ролям db_owner, dbcreater и sysadmin

FILE = номер_файла Указывает используемый набор резервной копии, если носитель содержит более одного набора. Например, если задать значение 2, то будет использоваться второй набор резервной копии на данном носителе

PASSWORD = пароль Указывает пароль для набора сохранения MEDIANAME = имя_носителя

Указывает имя носителя

103

MEDIAPASSWORD = пароль

Указывает пароль, который был присвоен этому набору носителей

MOVE 'имя_логического_файла' TO 'имя_файла_ОС'

Изменяет местоположение восстанавливаемого файла, например: MOVE 'Northwind' TO 'D:\data\Northwind.mdf'. Вы можете использовать этот параметр, если выполняете восстановление на новом диске, поскольку старый диск непригоден

NORECOVERY | RECOVERY |STANDBY = файл_отката

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

KEEP_REPLICATION Указывает, что будут сохранены параметры репликации, если база данных восстанавливается на издателе

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

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

RESTART Указывает, что SQL Server должен перезапускать операцию восстановления, если она была прервана

STATS [ = процент ] казывает вывод сообщения после выполнения определенного процента операции восстановления. Его полезно использовать, если вы хотите следить за ходом выполнения операций

PARTIAL Указывает, что нужно выполнить частичное восстановление STOPAT = дата_время Указывает, что базу данных следует восстановить (только

восстановление журнала к состоянию, в котором она находилась на дату, транзакций) указанную значением дата_время

STOPATMARK = 'метка' Указывает, что операция восстановления выполняется, пока не встретится указанная метка

STOPBEFOREMARK = 'метка'

Указывает, что операция восстановления заканчивается непосредственно перед указанной меткой

104

Именованные транзакции – новая возможность SQL Server 2000. Эти именованные транзакции, создаваемые с помощью оператора BEGIN TRANSACTION ... WITH MARK имя_метки, позволяют вам использовать параметры STOPATMARK и STOPBEFOREMARK оператора RESTORE.

12.9 Доставка журнала (Log Shipping)

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

В случае отказа основного сервера резервный сервер можно быстро и легко преобразовать в новый основной сервер. Первый сервер (primary server) - это промышленный сервер, на котором расположена исходная база данных. Второй сервер (secondary server) содержит резервную базу данных, в которую копируется и восстанавливается журнал регистрации транзакций исходной базы данных. Сервер мониторинга (monitor server) контролирует первый и второй сервер. Для настройки Log Shipping используется Database Maintenance Plan Wizard. Прежде, чем использовать этот визард, Вы должны сделать некоторые первоначальные приготовления. Выполните следующие шаги:

1. Определите пары серверов для log shipping (то есть, primary server и резервные варианты сервера, которые должны участвовать в log shipping). Хотя Вы можете устанавливать log shipping между двумя базами данных на одном сервере, предполагается, что Вы устанавливаете log shipping между разными серверами.

2. Определите monitor server, который должен быть отдельным от промышленного и резервных серверов.

3. Установите политики безопасности для всех серверов. Учетная запись Windows, которая будет использоваться для установки log shipping, должна иметь привилегии системного администратора SQL Server (sa) на всех серверах.

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

105

ресурсов. Установите разрешения на этот совместно используемый файловый ресурс для учетной записи Windows, которую использует SQL AGENT каждого сервера.

5. Решите, каким способом Вы создадите и проведёте первоначальную синхронизацию резервных баз данных. Вы можете воспользоваться встроенными средствами при установке log shipping для создания и первоначальной синхронизации резервных баз данных, или восстановить полную резервную копию базы данных вручную.

6. Зарегистрируйте все три сервера (то есть: primary server, secondary сервера и monitor server) в Enterprise Manager.

После того, как будут завершены эти предварительные приготовления, Вы готовы использовать Database Maintenance Plan Wizard для установки log shipping. Первые два шага визарда не обязательны. Если Вы в начале не синхронизировали базы данных основного и резервного сервера, на шаге №1 будет сделана резервная копия исходной базы данных. На шаге №2, визард копирует резервную копию на secondary server и восстанавливает её поверх резервной базы данных.

Визард всегда исполняет следующие три шага: На шаге №3 он создаёт задачу для SQLAGENT на primary server. Эта задача периодически выполняет резервное копирование в файл. Этот визард также создает ориентированный на log shipping план обслуживания (maintenance plan) для базы данных на secondary server. Этот план состоит из двух заданий SQL AGENT: первое для копирования журнала транзакций на secondary server (Шаг №4), а второе для восстановления журнала регистрации транзакций поверх резервной базы данных (Шаг №5).

Эти шаги создают log shipping пару (то есть: две базы данных участвующих в log shipping). Чтобы ещё больше повысить избыточность или установить связанный сервер, Вы можете сформировать дополнительные log shipping пары, установив log shipping для primary server с другими, дополнительными резервными серверами.


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

транзакций? 3. Для чего служит режим доставки журнала (Log Shipping)? 4. В чем разница между восстановлением базы данных из резервной

копии и восстановлением после сбоя?

106

13 Административные задачи и их автоматизация

13.1 Административные задачи

Для автоматизации административных задач используются три основных средства: задания (jobs), оповещения (alerts) и операторы (operators). Агент SQL Server Agent запускается отдельно от SQL Server, как служба с именем SQLServerAgent.

Задания – это административные задачи, которые определяются один раз и могут выполняться многократно. Вы можете запускать задание вручную, а также планировать запуск задания системой в определенное время, в соответствии с регулярным расписанием или при возникновении оповещения Задания могут состоять из операторов Transact-SQL (T-SQL), команд ОС, исполняемых программ или сценариев Microsoft ActiveX. Задания также автоматически создаются для вас, когда вы используете репликацию или создаете план обслуживания базы данных. Задание может состоять из одного или нескольких шагов, и каждый шаг может быть вызовом более сложного набора шагов, например обращением к хранимой процедуре. SQL Server автоматически следит за результатом выполнения заданий (успешное или неуспешное завершение); вы можете задавать оповещения, которые будут отправляться в каждом случае.

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

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

107

Чтобы определить задание, вы можете использовать Enterprise Manager, сценарии T-SQL, мастер создания заданий Create Job Wizard.

13.2 Управление заданием

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

sp_start_job. Сразу запускает указанное задание. В этой процедуре нужно указывать имя задания или идентификационный номер задания.

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

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

SQL Server поддерживает журнал (историю) с информацией о выполнении задания в таблице sysjobhistory системной базы данных msdb. Вы можете просмотреть информацию журнала выполнения задания с помощью Enterprise Manager или T-SQL.

Для просмотра журнала с информацией о выполнении запланированных заданий с помощью T-SQL запустите хранимую процедуру sp_help_jobhistory в базе данных msdb. Эта процедура имеет следующий синтаксис:

sp_help_jobhistory [[@job_id =] job_id] [, [@job_name =] 'job_name'] [, [@step_id =] step_id] [, [@sql_message_id =] sql_message_id] [, [@sql_severity =] sql_severity] [, [@start_run_date =] start_run_date] [, [@end_run_date =] end_run_date] [, [@start_run_time =] start_run_time] [, [@end_run_time =] end_run_time] [, [@minimum_run_duration =] minimum_run_duration] [, [@run_status =] run_status] [, [@minimum_retries =] minimum_retries] [, [@oldest_first =] oldest_first] [, [@server =] 'server'] [, [@mode =] 'mode']

Если запустить эту процедуру без параметров или без параметра job id

(Идентификатор задания) или job name (Имя задания), то будет возвращена информация обо всех запланированных заданиях. Параметр mode (режим)

108

указывает, нужно ли возвращать всю информацию журнала задания (FULL) или только сводку (SUMMARY). Значение по умолчанию – SUMMARY.

13.3 Оповещения

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

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

Запуск оповещения для определенного состояния производительности происходит в том случае, если указанный объект SQL Server в System Monitor достигает определенного порогового значения производительности, например, счетчик User Connections (Количество пользовательских соединений) внутри объекта General Statistics (Общая статистика) в System Monitor. Например, вы можете указать запуск оповещения, если значение этого счетчика достигнет 50. Для запуска оповещений требуется, чтобы работала служба SQLServerAgent.

Прежде чем перейти к созданию оповещения для какого-либо события, мы рассмотрим типы событий, которые приводят к передаче сообщений в журнал событий приложений; только эти события можно использовать для создания оповещений. События (или ошибки) с уровнем серьезности (severity level) от 19 до 25 автоматически передаются в журнал событий приложений и поэтому могут использоваться для запуска оповещений. По умолчанию события с уровнем серьезности меньше 19 не протоколируются в журнале, и поэтому эти события не могут использоваться для запуска оповещений. Чтобы эти события протоколировались в журнале, вы должны использовать sp_altermessage, оператор RAISERROR WITH LOG или xp_logevent, позволяющие изменить статус протоколирования события или сообщения.

Вся информация для системных и определенных пользователем сообщений сохраняется в таблице sysmessages базы данных master. Чтобы создать определенное пользователем сообщение, используйте системную хранимую процедуру T-SQL sp_addmessage. Она имеет следующий синтаксис:

sp_addmessage [@msg_num =] msg_id, [@severity=] severity,

109

[@msg_text=] 'msg_text' [,[@lang =] 'language'] [,[@with_log=] 'with_log'] [,[@replace =] 'replace']

Определенное пользователем сообщение должно иметь значение

идентификатора сообщения (msg_id) 50001 или больше. Параметр severity – это уровень серьезности ошибки, на который ссылается сообщение, в диапазоне от 1 до 25, причем более высокие значения означают более высокий уровень серьезности ошибки. Уровни серьезности от 19 до 25 может задавать только системный администратор. Параметр msg_text – это текст сообщения об ошибке, который появится в журнале событий приложений при возникновении данной ошибки. Параметр language указывает, на каком языке будет написано сообщение, поскольку вместе с SQL Server может быть инсталлировано несколько языков. Параметр with_log (с журналом) может иметь значение TRUE или FALSE, указывая, будет ли данное сообщение всегда протоколироваться в журнале событий приложений. Значение по умолчанию – FALSE. Оператор RAISERROR WITH LOG изменяет это значение, если оно равно FALSE. Параметр replace указывает, что данное сообщение должно заменить существующее сообщение, имеющее тот же идентификатор.

Рассмотрим пример использования sp_addmessage. Следующий оператор создает новое сообщение, которое будет всегда протоколироваться в журнале событий (поскольку для параметра with_log задано значение TRUE):

sp_addmessage 50001, 16, "Customer ID is out of range.", @with_log = "TRUE"

Предположим, что существующее сообщение, или сообщение, которое

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

sp_altermessage 50001, WITH_LOG, "TRUE"

В качестве альтернативного средства вы можете использовать оператор

RAISERROR с параметром WITH LOG, чтобы возвращать данное сообщение в ваше приложение, а также в журнал событий приложений и в журнал SQL Server.

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

sp_add_alert [@name =] 'name'

110

[, [@message_id =] message_id] [, [@severity =] severity] [, [@enabled =] enabled] [, [@delay_between_responses =] delay_between_responses] [, [@notification_message =] 'notification_message'] [, [@include_event_description_in =] include_event_description_in] [, [@database_name =] 'database'] [, [@event_description_keyword =] 'event_description_keyword_pattern'] [, {[@job_id =] job_id | [@job_name =] 'job_name'}] [, [@raise_snmp_trap =] raise_snmp_trap] [, [@performance_condition =] 'performance_condition'] [, [@category_name =] 'category']

Для модификации оповещения, просмотра информации оповещения и

удаления оповещения используются соответственно хранимые процедуры sp_update_alert, sp_help_alert и sp_delete_alert. Все эти хранимые процедуры находятся в базе данных msdb.

13.4 Операторы

Операторы – это люди, которые могут получать уведомление от SQL Server по завершении какого-либо задания или при возникновении какого-либо события. Имеется три метода, используемых для связи с операторами: отправка сообщений электронной почты, отправка на пейджер и использование команды NET SEND (которая отправляет сетевое сообщение на компьютер оператора.) Для связи через электронную почту и с пейджером вы должны инсталлировать на сервере MAPI-совместимый клиент — Microsoft Outlook или Microsoft Exchange Client, и создать почтовый профиль для службы SQLServerAgent. Для пейджинговой связи вам нужно также инсталлировать на почтовом сервере программное обеспечение для связи электронной почты с пейджером.

Можно создать несколько операторов для разделения между ними обязанностей, а также резервного оператора, который получит уведомление, когда недоступны другие операторы. Команды T-SQL, используемые для создания оператора, модифицирования информации об операторе, просмотра информации об операторе и удаления оператора, – это хранимые процедуры, находящиеся в базе данных msdb: sp_add_operator, sp_update_operator, sp_help_operator и sp_delete_operator. Ниже представлен синтаксис sp_add_operator:

sp_add_operator [@name =] 'name' [, [@enabled =] enabled] [, [@email_address =] 'email_address'] [, [@pager_address =] 'pager_address'] [, [@weekday_pager_start_time =] weekday_pager_start_time] [, [@weekday_pager_end_time =] weekday_pager_end_time]

111

[, [@saturday_pager_start_time =] saturday_pager_start_time] [, [@saturday_pager_end_time =] saturday_pager_end_time] [, [@sunday_pager_start_time =] sunday_pager_start_time] [, [@sunday_pager_end_time =] sunday_pager_end_time] [, [@pager_days =] pager_days] [, [@netsend_address =] 'netsend_address'] [, [@category_name =] 'category']

13.5 Журнал ошибок службы SQLServerAgent

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


1. Какие действия может выполнять задача SQL Agent? 2. Какие есть способы доставки оповещений? 3. Как зарегистрировать оператора? 4. Какой уровень серьезности должна иметь ошибка, чтобы было

отправлено оповещение?

112

14 Мониторинг и управление производительностью сервера БД

14.1 Использование SQL Query Аnalyzer для мониторинга

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

Query Analyzer можно использовать для просмотра выбранного плана исполнения. На панели Estimated Execution Plan запрос представлен в графическом виде, показана "стоимость" каждой операции и методы доступа к данным. Чтобы увидеть дополнительные данные для любой операции плана, задержите указатель мыши на значке этой операции. Появится всплывающее окно, содержащее дополнительные данные.

Это всплывающее окно содержит следующую информацию: Physical operation/Logical operation (Физическая

операция/Логическая операция). Операции, выполняемые данным запросом, такие как поиск в индексе, соединение, агрегирование и т.д. Если физический оператор представлен красным цветом, это означает, что оптимизатор запросов выдал предупреждение.

Estimated Row Count (Оценка количества строк). Количество строк, которое будет выбрано данной операцией.

Estimated Row Size (Оценка размера строк). Оценка размера считываемых строк в байтах.

Estimated I/O cost/Estimated CPU cost (Оценка стоимости ввода-вывода/Оценка стоимости ЦП). Чем меньше, тем лучше.

Estimated number of executes (Оценка количества выполнений). Приблизительное количество выполнений данной операции во время выполнения данного оператора.

Estimated cost (Оценка стоимости). Стоимость операции по оценке оптимизатора запросов. Эта стоимость показана в процентах от полной стоимости данного оператора.

Estimated subtree Cost (Оценка стоимости поддеревьев). Оценка стоимости выполнения предыдущих частей и данной части оператора. Если имеется несколько поддеревьев, то это средство позволяет просматривать стоимость выполнения каждого поддерева.

Argument (Параметры). Параметры, используемые данным оператором.

113

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

В примерах ниже используется таблица Orders базы данных Northwind. Таблица Orders имеет кластеризованный индекс с именем PK_Orders по колонке OrderID и восемь других индексов. Рассмотрим пример запроса информации по заказам (orders), помещенным сотрудником (employee), идентификационный номер которого (employee ID) равен 4. Вот этот запрос:

SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM Orders WHERE EmployeeID = 4

В данной организации каждый сотрудник обрабатывает небольшую

часть от всех заказов, поэтому можно предположить, что SQL Server будет использовать индекс EmployeeID. Вместо этого Query Analyzer информирует вас, что SQL Server будет использовать доступ с помощью кластеризованного индекса PK_Orders.

Чтобы оптимизатор запросов использовал вместо этого индекс EmployeeID, можно использовать подсказку в операторе SELECT:

SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM Orders WITH (INDEX(EmployeeID)) WHERE EmployeeID = 5

Выполнение операции соединения включает в себя намного больше

процессов:

SELECT OrderID, CustomerID, Employees.EmployeeID, FirstName, LastName, OrderDate FROM Orders JOIN Employees ON Orders.EmployeeID = Employees.EmployeeID

SQL Server поддерживает несколько операций связывания, включая

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

SELECT CustomerID, SUM("Order Details".UnitPrice) FROM Orders JOIN "Order Details" ON Orders.OrderID = "Order Details".OrderID GROUP BY CustomerID

114

14.2 Использование SQL Profiler для мониторинга

В дополнение к использованию Query Analyzer для поиска неэффективных операторов T-SQL вы можете также использовать утилиту SQL Server Profiler. Profiler позволяет наблюдать за всеми операторами T-SQL, которые выполняются в системе, с графическим отображением информации об этих операторах. Profiler также предоставляет возможности сортировки и фильтрации, которые можно использовать для выявления операторов T-SQL, использующих основную часть ресурсов ЦП и ввода-вывода.

Имеются следующие шаблоны трассировки, поставляемые вместе с SQL Server.

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

SQLServerProfilerStandard.tdf. Собирает общую информацию о соединениях, выполненных хранимых процедурах и пакетах SQL в порядке их выполнения.

SQLServerProfilerTSQL.tdf. Собирает информацию обо всех операторах T-SQL в порядке их поступления в SQL Server от пользователей. Эта трассировка содержит просто операторы T-SQL и моменты времени их запуска.

SQLServerProfilerTSQL_Duration.tdf. Выводит запущенные операторы T-SQL, а также время (в миллисекундах), которое потребовалось для выполнения этих операторов.

SQLServerProfilerTSQL_Grouped.tdf. Собирает данные, аналогичные тому, что собирает SQLServerProfilerTSQL, но группирует операторы по пользователям, запустившим эти операторы.

SQLServerProfilerTSQL_Replay.tdf. Предоставляет подробную информацию о запускавшихся операторах T-SQL. Эта трассировка содержит данные, которые можно использовать для воспроизведения операторов T-SQL в Query Analyzer.

SQLServerProfilerTSQL_SPs.tdf .Выводит указанные хранимые процедуры, а также команды T-SQL внутри этих процедур. Результаты выводятся в порядке выполнения.

SQLServerProfilerTuning.tdf. Собирает данные о хранимой процедуре и выполнении пакета SQL.

14.3 Принципы управления производительностью СУБД

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

115

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

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

Современные процессоры, используемые в серверах, могут обрабатывать данные в несколько раз быстрее, чем оперативная память может их предоставлять. Пропускная способность оперативной памяти в несколько раз превышает пропускную способность самых быстрых сетевых интерфейсов и внешних накопителей. Из-за различий в скорости ввода-вывода получение данных с диска намного дороже, чем получение данных из памяти. Размер страницы данных в SQL Server – 8 КБ. Блок в SQL Server состоит из восьми страниц размером 8 КБ каждая и соответственно имеет размер 64 КБ. Это важно понимать, поскольку, когда SQL Server запрашивает определенную страницу с диска, выполняется получение всего блока, содержащего страницу, а не только этой страницы. Получение страницы из буферного пула выполняется в течение половины миллисекунды; получение одного блока с диска занимает не менее 2 мс (типичное время лежит в интервале от 4 до 10 мс).

14.4 Способы определения узких мест

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

Часто используется системный счетчик производительности «% загруженности процессора», который отображает время, в течение которого процессоры заняты работой. Как правило, загруженность процессоров считается высокой, когда это значение превышает 80% в течение длительного интервала времени работы. Другой важный счетчик «Длина очереди процессора», который находится в объекте «Система» системного монитора, показывает количество потоков, ожидающих выполнения. SQL Server использует только один поток для каждого логического процессора. Это означает, что в очереди процессора системы, выполняющей только SQL Server, должно находиться минимальное количество потоков. На серверах, где кроме СУБД используются и другие программы, на этот счетчик необходимо обращать особое внимание.

116

Таблица 14.1 — Используемые счетчики производительности Счетчик производи-тельности

Объект счетчика Пороговое значение

Примечания

«% используемого времени процессора»

Процессор > 80% Возможные причины включают недостаток памяти, редкое повторное использование плана запроса, неоптимизированные запросы.

«Контекстных переключений /сек»

Система > 5000* (число процесс-соров)

Возможные причины включают другие приложения на сервере, несколько экземпляров SQL Server на одно сервере, включение технологии hyper-threading.

«Длина очереди процессора»

Система > 5* (число процесс-соров)

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

«Compilations /sec» (Компиляций/с)

SQLServer: статистика SQL

Тенденция Сравнение со счетчиком «Запросов пакетов/с»

«Reсompilations /sec» (Перекомпи-ляций/с)


Тенденция Сравнение со счетчиком «Запросов пакетов/с»

«Запросов пакетов /с»


Тенденция Сравнение с количеством компиляций и перекомпиляций в секунду.

«Ожидаемый срок жизни страницы»

SQLServer: диспетчер буферов

< 300 Возможная нехватка памяти.

«Отложенных записей /с»


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

«Checkpoints /sec» (Контрольных точек/с)


Тенденция Оценка контрольных точек с помощью счетчиков «Ожидаемый срок жизни страницы» и «Отложенных записей/с».

Коэффициент попадания в кэш: планы SQL

SQLServer:кэш планов

< 70% Указывает на редкое повторное использование плана.

Коэффициент попадания в буферный кэш


< 97% Возможная нехватка памяти.

При высокой загрузке ЦП можно проверить у объекта

производительности «SQL Server: статистика SQL» счетчики «Compilations/sec» (Компиляций/с) и «Re-Compilations/sec» (Повторных компиляций/с). Запросы и хранимые процедуры нужно оптимизировать, чтобы свести к минимуму количество повторных компиляций (оно не должно составлять существенную долю от количества поступающих в

117

команд SQL, которое можно увидет с помощью счетчика «Пакетных запросов/с», который также находится в объекте «SQL Server: статистика SQL»).

Если на сервере выполняется не только SQL Server, нужно контролировать счетчик «Контекстных переключений/сек», показывающий количество переключений потоков планировщиком операционной системы. Нормальное значение – не больше количества процессоров, умноженного на 5000.

Модуль отложенной записи SQL Server (в SQL Server 2005 — монитор ресурсов) — это процесс SQL Server, выбирающий страницы для сохранения и страницы для записи из буферного пула на диск. Всем страницам в буфере и кэшах процедур изначально присвоены стоимости, представляющие ресурсы, потребляемые при помещении этой страницы в кэш. Эти значения стоимостей уменьшаются при каждой проверке монитором ресурсов. При необходимости для запроса пространства в кэше страницы удаляются из памяти на основе их стоимостей; в первую очередь удаляются страницы с самой низкой стоимостью. Операции монитора ресурсов можно отследить с помощью счетчика «Отложенных записей/с» объекта «SQL Server: диспетчер буферов» системного монитора. Обычно этот счетчик используется вместе со счетчиками «Ожидаемый срок жизни страницы» и «Checkpoints/sec» (Контрольных точек/с) для выявления нехватки памяти. Счетчик «Ожидаемый срок жизни страницы» показывает длительность нахождения страницы данных в буферном кэше. Типичное пороговое значение для этого счетчика – 300 секунд. Значение ниже среднего значения в 300 секунд, сохраняющееся в течение длительного времени, свидетельствует о том, что страницы данных удаляются из памяти слишком часто. Это увеличивает объем работы монитора ресурсов, что в свою очередь приводит к увеличению загрузки процессоров.

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

14.5 Трассировка приложения

При трассировке приложения SQL Server имеет смысл использовать не только SQL Server Profiler (он увеличивает нагрузку на систему на 15…25%), но и хранимые процедуры, что может вдвое снизить процент увеличения нагрузки.

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

118

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

SELECT substring(text,qs.statement_start_offset/2 ,(CASE WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2 ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) ,qs.plan_generation_num as recompiles ,qs.execution_count as execution_count ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time ,qs.total_worker_time as cpu_time ,qs.total_logical_reads as reads ,qs.total_logical_writes as writes FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st LEFT JOIN sys.dm_exec_requests r ON qs.sql_handle = r.sql_handle ORDER BY 3 DESC

Планы запросов анализируются, оптимизируются, компилируются и

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

Ниже приведены некоторые важные моменты, касающиеся оптимизации ЦП для T-SQL.

Повторное использование плана запроса Уменьшение количества компиляций и повторных компиляций Операции сортировки Недопустимые соединения Отсутствующие индексы Просмотры таблиц/индексов Использование функций в предложениях SELECT и WHERE Многопоточные операции Рассмотрим эти моменты. Обычно SQL Server получает данные из

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

119

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

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

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

Представление the sys.dm_exec_sessions позволяет определять только активные сеансы, поэтому это одно из первых мест для поиска при высокой загрузке ЦП. Сначала необходимо выполнять проверку сеансов с большим числом ЦП. Использование sys.dm_exec_sessions вместе с sys.dm_exec_requests может предоставить большое количество информации, доступной через хранимые процедуры sp_who и sp_who2. При объединении данных с функцией sys.exec_sql_text в столбце sql_handle можно получить текущий выполняемый запрос сеанса.

SELECT es.session_id,es.program_name,es.login_name ,es.nt_user_name,es.login_time,es.host_name ,es.cpu_time,es.total_scheduled_time ,es.total_elapsed_time,es.memory_usage ,es.logical_reads,es.reads,es.writes,st.text FROM sys.dm_exec_sessions es LEFT JOIN sys.dm_exec_connections ec ON es.session_id = ec.session_id LEFT JOIN sys.dm_exec_requests er ON es.session_id = er.session_id OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st WHERE es.session_id > 50 -- < 50 system sessions ORDER BY es.cpu_time DESC

Этот оператор позволяет определить приложения, которым необходимо

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

120

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


1. Как узнать план выполнения запроса? 2. Как узнать стоимость отдельного физического оператора из плана

выполнения запроса? 3. Для чего служит прдеставление sys.dm_exec_sessions? 4. Создает ли SQL Profiler дополнительную нагрузку на сервер?

121

15 Экспорт и импорт данных

15.1 Протоколирование операций массовой загрузки данных

По умолчанию все операции вставки в базу данных полностью протоколируются, что позволяет выполнить восстановление и откат транзакций в случае отказа системы. Отключая полное протоколирование массовой загрузки, можно снизить объем протоколируемых данных. Это повысит производительность резервного копирования, но потребует повторной массовой загрузки данных в случае отказа системы. Еще один параметр базы данных – trunc. log on chkpt – отключает сохранение журнальных записей, когда для этого параметра задано значение TRUE. В этом случае происходит усечение журнала транзакций каждый раз, как встречается контрольная точка. Это повышает производительность массового копирования, но может сделать систему невосстанавливаемой. Таким образом, этот параметр никогда не следует использовать в производственной системе при обычных операциях, когда восстановление важно для системы. Если вы все-таки задали значение TRUE для параметра trunc. log on chkpt, не забудьте отключить его, когда закончите операцию массовой загрузки. Чтобы задать этот параметр с помощью хранимой процедуры, используйте sp_dboption со следующими параметрами:

exec sp_dboption имя_базы_данных, "trunc. log on chkpt", TRUE

15.2 Оператор BULK INSERT

Оператор BULK INSERT можно использовать для массового копирования данных из файла данных в базу данных SQL Server. Он имеет несколько обязательных параметров и много необязательных. Синтаксис оператора BULK INSERT:

BULK INSERT [['имя_базы_данных'.]['владелец'].] {'имя_таблицы' | 'имя_представления' FROM 'файл_данных' } [WITH ( [BATCHSIZE [ = размер_группы ]] [[,] CHECK_CONSTRAINTS ] [[,] CODEPAGE [ = 'ACP' | 'OEM' | 'RAW' | 'кодовая_страница']] [[,] DATAFILETYPE [ = {'char'|’native’| 'widechar'|’widenative’}]] [[,] FIELDTERMINATOR [ = 'ограничитель_полей' ]] [[,] FIRSTROW [ = первая_строка ]] [[,] FIRETRIGGERS [ = триггеры ]] [[,] FORMATFILE [ = 'путь_к_форматному_файлу' ]] [[,] KEEPIDENTITY ] [[,] KEEPNULLS ] [[,] KILOBYTES_PER_BATCH [ = килобайт_на_группу ]] [[,] LASTROW [ = последняя_строка ]] [[,] MAXERRORS [ = максимум_ошибок ]] [[,] ORDER ( { колонка [ ASC | DESC ]}[ ,...n ])] [[,] ROWS_PER_BATCH [ = строк_на_группу ]]

122

[[,] ROWTERMINATOR [ = 'разделитель_строк' ]] [[,] TABLOCK ] )]

Местоположение файла данных указывается параметром файл_данных.

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

Таблица 15.1 — Необязательные параметры для оператора BULK INSERT Необязательный параметр

Описание

BATCHSIZE = размер Указывает количество строк в группе (пакетном задании). Каждая группа обрабатывается как одна транзакция

CHECK_ CONSTRAINTS

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

CODEPAGE [ = 'ACP' | 'OEM' | 'RAW' | 'кодовая_страница' ]

Указывает кодовую страницу данных в файле данных. Этот параметр полезно использовать только с типами данных char, varchar и text

ATAFILETYPE [ = 'char' | 'native' | 'widechar' | 'widenative' ]

Указывает тип данных в файле данных; по умолчанию это тип char. Другие типы: native (собственные типы данных базы данных), widechar (символы Unicode) и widenative (то же, что и native, но типы char, varchar и text сохраняются как Unicode)

FIELDTERMINATOR [ = ограничитель_полей ]

Указывает ограничитель полей, используемый с типами данных char и widechar. По умолчанию это символ табуляции (\t)

FIRSTROW [ = первая_строка ]

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

FORMATFILE [ = форматный_файл ]

Указывает путь доступа к форматному файлу

KEEPIDENTITY Указывает, что в импортируемых файлах данных присутствуют значения для колонки со свойством identity

KEEPNULLS Указывает, что в пустых колонках сохраняется значение null KILOBYTES_PER_ BATCH [ = число ]

Указывает приблизительное количество килобайт на одну группу (пакетное задание), используемую при массовом копировании

LASTROW [ = последняя_строка ]

Указывает последнюю строку для выполнения массового копирования. По умолчанию используется значение 0. Этот параметр полезно использовать, если вы хотите вставить только определенное количество строк

MAXERRORS [ = максимум_ошибок ]

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

ORDER ( колонка [ASC | DESC] )

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

ROWS_PER_BATCH [ = строк_на_группу ]

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

123

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

ROWTERMINATOR [ = разделитель_строк ]

Указывает разделитель строк для данных типа char и widechar. По умолчанию используется символ новой строки (\n)

15.3 Data Transformation Services (DTS)

Администраторы базы данных, часто сталкиваются с задачами перемещения информации между разнородными источниками данных. Data Transformation Services (DTS) — это технология, реализующая возможность обмена и трансформации данных между любыми OLE DB источниками. DTS реализован, как набор программируемых объектов, доступных через API и создание скриптов, а также через простой в использовании графический интерфейс. Независимо от выбранного способа, все действия по перемещению и преобразованию данных оформляются в виде специальных модулей, называемых пакетами. Каждая функция DTS-пакета может быть представлена, как контейнер для четырех типов компонентов:

Подключение — представляет источник и получателя данных, которые имеют соответствующего OLE DB провайдера. SQL 2000 DTS имеет встроенные подключения для SQL Server, Access, Excel, Visual FoxPro, текстовых и HTML файлов, а также для баз данных третьих фирм, таких как: Oracle, Paradox и dBase.

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

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

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

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

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

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

124

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

Структурированные хранимые файлы (с расширением .DTS) - идеальное решение для копирования пакетов между SQL-серверами. Вы можете сохранить любой существующий пакет (или несколько пакетов) в .DTS файл. Они могут быть исполнены даже без SQL Server, при использовании утилиты командной строки DTSRUN.exe.

Файлы модулей Visual Basic (с расширением .BAS) предназначены для разработчиков на Visual Basic, которые могут использовать методы программирования объектной модели DTS для изменения существующих пакетов. Обратите внимание, что такие пакеты не предназначены для импорта в DTS Designer или Microsoft Repository.

15.4 Создание DTS-пакетов с помощью DTS Designer

DTS Designer можно вызвать из папки Data Transformation Services, и он предоставляет возможность создавать и редактировать DTS пакеты с помощью графического интерфейса. Пакет состоит из нескольких компонент, таких как подключение, задачи и реализующие бизнес-логику процессы. Эти компоненты обозначаются соответствующими значками, которые формируют визуальное представление потока данных и их трансформации. Вы можете легко посмотреть на структуру типичного пакета, открыв предварительно созданный мастером Export/Import пакет.

Подключения составляют основную часть любого пакета, так как они обеспечивают доступ к источнику и получателю данных. Свойства каждого типа подключений зависят от провайдера OLE DB. Например, при создании подключения к SQL Server будет запрошено имя экземпляра сервера, тип аутентификации, имя/пароль пользователя (если была выбрана SQL Server Authentication) и имя подключаемой базы данных. Для каждого пакета Вы должны использовать уникальные имена подключений. Чтобы не менять пакет для корректировки параметров подключения, можно использовать файлы Microsoft Data Link. Новые свойства подключения можно просто сохранить в файле с расширением .UDL. Если для такого файла выбрать пункт "Открыть" в контекстно-зависимом меню Проводника Windows, будет отображено диалоговое окно мастера "Свойства связи с данными", разделенное на четыре закладки.

Закладка «Поставщик данных» позволяет выбирать OLE DB провайдера, используемого подключением. Закладка «Подключение» содержит параметры подключения, которые необходимы указанному ранее OLE DB провайдеру. Здесь может быть указано местоположение источника данных и варианты аутентификации. Закладка «Дополнительно» определяет "Уровень олицетворения" и "Уровень защиты", время ожидания подключения и права доступа.

125

Уровень олицетворения используется сервером при исполнении роли клиента:

Аноним - анонимное подключение клиента к серверу. Процессу сервера недоступны идентификационные сведения клиента, поэтому представление клиента невозможно.

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

Идентификация - клиент может быть опознан сервером. Сервер может исполнять роль клиента при проверке таблицы управления доступом ACL (Access Control List), однако получить доступ к системным объектом как клиент он не может.

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

Уровень защиты относится к данным, передаваемым между сервером и клиентом:

Вызов - проверка подлинности источника данных в начале каждого запроса от клиента к серверу.

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

Не проверяется - подлинность отправляемых на сервер данных не проверяется.

Пакет - проверка подлинности того, что все полученные данные исходят от клиента.

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

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

Время ожидания подключения - это время (в секундах), в течение которого поставщик OLE DB ожидает завершения инициализации. По истечении этого времени соединение установлено не будет и возникнет ошибка.

Выберите также одно или несколько прав доступа: Read - только чтение. ReadWrite - чтение и запись. Share Deny None - никому не отказывать ни в чтении, ни в записи. Share Deny Read - запретить всем работу в режиме чтения. Share Deny Write - запретить всем работу в режиме записи.

126

Share Exclusive - запретить всем работу в режиме чтения/записи. Write - только запись. UDL - это обычный текстовый файл, так что вся его информация может

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

Шаг 2. Далее, в SQL Server Enterprise Manager средствами интерфейса DTS

Designer нужно создать ссылку на UDL файл, созданный в первом шаге. При использовании UDL файлов, одним из важных вопросов обеспечения безопасности является то, что внутри этих файлов вся информация (включая пароли) хранится в не зашифрованном виде, в обычном текстовом формате. Чтобы упростить решение этой проблемы, Вы можете использовать Windows Authentication, при который не требуется, чтобы учётная информация логина была сохранена, и вместо этого используется контекст безопасности пользователя, который зарегистрировался в системе для исполнения пакета.

Ещё одним моментом, который нужно учитывать при настройке подключений, является параллельная обработка задач в DTS пакете. Такие задачи могут одновременно обращаться к одному и тому же источнику данных, но в этом случае Вы должны убедиться, что все эти задачи используют отдельные объекты подключения. Обратите внимание, что этим не подразумевается использование отдельных UDL файлов, т.к. один UDL файл обеспечит несколько подключений Microsoft Data Link в DTS пакете (UDL файл содержит только информацию о подключении, и не является в DTS объектом подключения).

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

Рассмотрим основные предопределённые задачи DTS. Bulk Insert task - исполняет функцию "обёртки" для T-SQL команды

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

Copy SQL Server Objects task - выполняет копирование объектов между двумя базами данных, например: таблиц (включая данные), представлений, хранимых процедур, ограничений, триггеров, индексов, пользователей, ролей, логинов, первичных и внешних ключей, а так же разрешений этих объектов. Не стоит использовать эту задачу только для того, чтобы копировать данные, т.к. для этого более эффективен Transform Data task. Кроме того, если нужно копировать всю базу данных, лучше использовать Transfer Databases task.

127

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

Execute SQL task - исполняет SQL запрос (включая хранимые процедуры). Запрос может быть разделён на пакеты, разделённые командой GO. Диалоговое окно свойств Execute SQL Task позволяет устанавливать время блокировки, по истечении которого соответствующая задача будет прервана. SQL запрос может быть проверен на правильность его синтаксиса, в нём доступны параметры ввода - вывода и глобальные переменные.

o Глобальные переменные используются для хранения данных, которые могут быть доступны нескольким компонентам одного пакета или переданы другим пакетам.

o Входные параметры включаются в SQL запрос как вопросительные знаки, после чего их можно привязать к глобальным параметрам в последовательности появления их в запросе, как Parameter 1, Parameter 2 и т.д.

Execute SQL task часто применяется после задач выполняющих импорт данных (например, чтобы пересоздать индексы или обновить статистику). File Transfer Protocol task - помогает решать распространённые

задачи в смешанных или распределённых системах, где данные должны быть переданы по File Transfer Protocol.

Send Mail task - позволяет посылать сообщения электронной почты из DTS пакета. Это обычно используется для оповещения о результатах выполнения пакета. Результаты могут быть помещены в тело письма или в прикреплённый к письму файл.

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


1. Зачем отключают протоколирование при массовой загрузке данных. 2. Чем отличаются операторы BULK INSERT и INSERT? 3. Могут ли задачи в DTS-пакете обрабатываться параллельно? 4. Как с помощью DTS можно передать файл по протоколу FTP?

128

16 Распределенные транзакции

16.1 Введение

Microsoft Distributed Transaction Coordinator (MS DTC – координатор распределенных транзакций) позволяет осуществлять доступ к нескольким базам данных из одной транзакции, обеспечивая при этом целостность данных. Такая транзакция называется распределенной. Базы данных, к которым она обращается, могут находиться в отдельных компьютерных системах или в одной системе.

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

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

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

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

129

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

16.2 Пример использования MS DTC

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

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

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

1. Обновляют счет 1 в системе A, снимая с него n долларов. 2. Фиксируют транзакцию. 3. Обновляют счет 2 в системе B, добавляя к нему n долларов. 4. Фиксируют транзакцию. Этот метод действует, пока в любой из систем нет никаких проблем, но

это отнюдь не самый надежный способ перевода денег. Что произойдет при сбое в одной из систем во время этих операций? Возможны следующие результаты:

Не будет выполнена первая транзакция из-за ошибки в системе A или в клиентской системе. Тем самым не будет выполнена вторая транзакция и поэтому никаких денег не будет переведено.

Первая транзакция выполнится успешно, но не будет выполнена вторая транзакция из-за ошибки в системе B или в клиентской системе. Деньги будут потеряны.

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

1. Обновление счета 1 в системе A; с него снимается n долларов. 2. Обновление счета 2 в системе B; к нему добавляется n долларов. 3. Фиксация обеих транзакций в одном наборе. Фиксируются либо обе

транзакции, либо ни одна из них.

130

Используя службу MS DTC, вы можете указывать, какие распределенные транзакции фиксируются как один набор. Либо фиксируются все эти транзакции, либо для всех них выполняется откат.

16.3 Свойства MS DTC

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

Вы можете вызывать MS DTC с помощью одного из следующих методов:

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

Обновление данных в нескольких источниках данных OLE DB. Встраивание команд MS DTC в ваше приложение. При использовании одного из первых трех методов распределенная

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

При использовании четвертого метода (встраивание команд MS DTC в ваше приложение) клиентское приложение и сетевой интерфейс SQL Server будут взаимодействовать с MS DTC, а также с SQL Server. Клиент SQL Server будет помогать в координировании распределенной транзакции.

16.4 Программирование MS DTC

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

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

Явное использование команды BEGIN DISTRIBUTED TRANSACTION. Это явный способ создания распределенной транзакции.

Использование параметра конфигурирования SQL Server REMOTE_PROC_ TRANSACTIONS. Это приводит к немедленному расширению транзакций до распределенных транзакций при вызове удаленной хранимой процедуры.

131

Вызов функций OLE DB или ODBC. В OLE DB и в SQL Server включается синтаксис для инициирования распределенных транзакций.

Вы можете проверить работу MS DTC, инициируя распределенную транзакцию с помощью команды BEGIN DISTRIBUTED TRANSACTION, и вы фиксируете ее с помощью команды COMMIT:

BEGIN DISTRIBUTED TRANSACTION SELECT EmployeeID FROM Northwind.dbo.Employees SELECT emp_id FROM pubs.dbo.employee GO COMMIT GO

Введите только первые четыре строки этой последовательности.

Задерживая команду COMMIT и команду завершения GO, вы сможете просмотреть транзакцию в папке Transaction List (Список транзакций) папки Distributed Transaction Coordinator консоли администрирования MMC Component Services. Для просмотра этой папки раскройте папку Component Services, раскройте папку Computers, затем – My Computer и, наконец, раскройте Distributed Transactions Coordinator в консоли администрирования MMC Component Services. После просмотра данной транзакции введите последние две строки этой последовательности команд T-SQL. Отметим, что данная транзакция, теперь уже фиксированная, больше не появится в окне Transaction List. Конечно, большинство распределенных транзакций сложнее данной транзакции и включает обновления и вставки, но этот пример легко выполнить и он не изменяет никаких таблиц базы данных.

Вызов распределенных транзакций обычно происходит из программы с помощью API-вызовов ODBC или DB-LIB, используемых для запуска и завершения каждой транзакции. Распределенные транзакции программируются почти так же, как и другие транзакции, за исключением того, что соединения должны открываться с отключенным параметром автофиксации (Autocommit), чтобы каждый оператор SQL Server не фиксировался автоматически. Служба MS DTC будет управлять двухфазным фиксированием каждый раз, когда соответствующее приложение заканчивает транзакцию с помощью команды COMMIT или ROLLBACK.


1. Объясните разницу между локальной и распределенной транзакцией. 2. Зачем нужна вторая фаза в протоколе двухфазной фиксации

транзакций? 3. Что произойдет, если один из серверов, участвующих в

распределенной транзакции, станет недоступен? 4. Приведите пример распределенной транзакции.

132

17 Основы репликации

17.1 Понятие репликации

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

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

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

Издатель – система Microsoft Windows Server 2000/2003/2008, содержащая базу данных SQL Server. Эта база данных содержит данные, которые должны реплицироваться в другие системы. Кроме того, SQL Server следит за тем, какие данные изменились, чтобы их можно было эффективно реплицировать. Издатель также поддерживает информацию о том, какие данные сконфигурированы для репликации. В зависимости от выбранного типа репликации издатель выполняет больший или меньший объем работы во время процесса репликации. Это описывается более подробно далее.

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

133

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

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

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

17.2 Типы репликации

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

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

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

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

134

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

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

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

17.3 Данные репликации

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

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

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

135

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

Реплицируемые данные можно распространять целым рядом способов. Все методы распространения базируются либо на push-подписке (принудительная подписка), либо на pull-подписке (подписка по запросу). Подписчик может одновременно использовать сочетание push- и pull-подписок.

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

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

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

Для выполнения операций, необходимых для перемещения реплицируемых данных от издателя к дистрибьютору и затем подписчику, используются несколько агентов: Snapshot Agent, Log Reader Agent, Distribution Agent и Merge Agent.

Агент Snapshot Agent используется для создания и распространения снимков мгновенного состояния от издателя дистрибьютору (или в местоположение снимка). Snapshot Agent создает данные репликации (снимок), а также создает информацию (метаданные), которая используется агентом Distribution Agent для распространения этих данных. Snapshot Agent сохраняет снимок на дистрибьюторе (или в указанном вами месте). Snapshot Agent также обеспечивает поддержку информации о состоянии

136

синхронизации объектов репликации; эта информация хранится в дистрибутивной базе данных.

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

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

2. Snapshot Agent устанавливает соединение от издателя к дистрибьютору. После установления этого соединения Snapshot Agent формирует копию схемы для каждой статьи и сохраняет эту информацию в дистрибутивной базе данных. Эти данные трактуются как метаданные.

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

4. После копирования данных Snapshot Agent обновляет информацию в дистрибутивной базе данных.

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

Как видите, Snapshot Agent обеспечивает только создание снимка; он не распространяет его подписчикам. Эту задачу выполняют другие агенты.

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

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

Агент Distribution Agent распространяет снимки и транзакции из дистрибутивной базы данных подписчикам. Каждая публикация имеет собственного агента Distribution Agent. Если вы используете push-подписку, то Distribution Agent выполняется на дистрибьюторе. Если вы используете pull-подписку, то Distribution Agent выполняется на подписчике.

Агент Merge Agent используется в репликации слиянием для согласования (слияния) накопившихся изменений, выполненных с момента

137

последнего согласования. Если вы используете репликацию слиянием, то агенты Distribution Agent и Snapshot Agent не используются: взаимодействие с издателем и дистрибьютором осуществляет Merge Agent.

Агент Queue Reader Agent используется для распространения выполненных изменений подписчикам репликации снимков или репликации транзакций, которые были сконфигурированы с опцией отложенных обновлений (Queued updating). Эта опция позволяет вносить изменения на подписчике без необходимости использования какой-либо распределенной транзакции.

17.4 Репликация моментальных снимков

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

К типам приложений, которым может помочь применение репликации снимков, можно отнести:

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

Поисковые таблицы, которые не требуют частого обновления. Поисковые таблицы обычно имеют относительно статичные данные.

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

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

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

Прежде чем конфигурировать подписчиков, вы должны активизировать их в дистрибутивной базе данных. Активизация подписчика позволяет системе SQL Server взаимодействовать с дистрибутивной базой данных. Установив соединение между дистрибутивной базой данных и подписчиком, вы можете конфигурировать подписки либо из подписчика, либо из издателя. Из подписчика вы можете конфигурировать pull-подписку (подписку по запросу); из издателя вы можете конфигурировать push-подписку (принудительную подписку).

138

Управление и конфигурирование pull-подписок осуществляет подписчик. Тем самым вы должны выбрать подписчика в Enterprise Manager, прежде чем вызывать мастера pull-подписки Pull Subscription Wizard. Обычно pull-подписку используют подписчики, которые не подсоединены постоянно к сети. Например, pull-подписка подходит для используемых мобильным торговым персоналом переносных компьютеров, которые нерегулярно подсоединяются к сети и обновляют подписку.

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

Push-подписка (принудительная подписка) инициируется на издателе. Push-подписка конфигурируется с помощью мастера Push Subscription Wizard. При использовании push-подписки расписание репликаций определяется на дистрибьюторе. Push-подписка – это типичный метод подписки для стационарных подписчиков. Причиной использования таких подписок является удобство управления всеми подписками с дистрибьютора вместо необходимости отдельного управления каждой подпиской с подписчика. Для запуска мастера Push Subscription Wizard выполните следующие шаги.

17.5 Настройка и мониторинг репликации снимков

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

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

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

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

139

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

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

Мониторинг системы репликации снимков осуществляется с помощью монитора производительности Microsoft Windows 2000 Performance Monitor. В этом мониторе имеется ряд объектов, которые добавляются при использовании репликации SQL Server. Кроме того, для мониторинга репликации снимков полезен ряд стандартных объектов Performance Monitor.

SQLServer:Replication Agents. Указывает количество работающих агентов репликации каждого типа.

SQLServer:Replication Dist. Предоставляет информацию о задержке при распространении.

SQLServer:Replication Snapshot. Предоставляет информацию о производительности репликации снимков.

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

Processor. Позволяет вам следить за процессорами системы. System. Предоставляет информацию о системе в целом. Эти счетчики дают вам достаточно хорошее представление о том,

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

Узкие места подсистем ввода-вывода. При слишком высокой интенсивности ввода-вывода следите за числом операций ввода-вывода в секунду и за временем на одну операцию ввода-вывода.

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


1. Объясните разницу между способами репликации. 2. Зачем нужна репликация? 3. Для чего служит сервер дистрибутора? Почему недостаточно издателя? 4. На каком сервере должна конфигурироваться pull-подписка?

140

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

1. Кузнецов С.Д. Основы баз данных. Учебное пособие. — М.:Интернет-университет информационных технологий – ИНТУИТ.ру, 2005. — 488 с. 2. Мирошниченко Г.А. Реляционные базы данных: практические приемы оптимальных решений. — СПб.:БХВ-Петербург, 2005. — 400с. 3. Новиков Б.А. Домбровская Г.Р. Настройка приложений баз данных. — СПб.:БХВ-Петербург, 2006. — 240с. 4. Пирогов В.Ю. SQL Server 2005: Программирование клиент-серверных приложений. — СПб.:БХВ-Петербург, 2006. — 336с. 5. Станек У.Р. Microsoft SQL Server 2005. Справочник администратора. — М.: Русская Редакция, 2006. — 544 с. 6. Михеев Р.Н. MS SQL Server 2005 для администраторов. — СПб.: БХВ-Петербург, 2006. — 544 с. 7. Моисеенко С. SQL. Задачи и решения. — СПб.:Питер, 2006. — 256с. 8. Клайн К., Клайн Д. Хант Б. SQL. Справочник. 2-е изд. М.:Кудиц-образ, 2006. — 832с. 9. Байдачный С., Маленко Д., Лозинский Ю. SQL Server 2005. Новые возможности для разработчиков. — М.: Солон-Пресс, 2006. — 208 с. 10. Каленик А. Использование новых возможностей Microsoft SQL Server 2005. — СПб.: Питер, 2006. —334 с. 11. Виейра Р. Программирование баз данных Microsoft SQL Server 2005. Базовый курс. — К.:Диалектика, 2007. — 832 с. 12. Дибетта П. Знакомство с Microsoft SQL Server 2005. — М.: Русская Редакция, 2005. — 288 с.

Учебное издание

Брейман А.Д.

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

Учебное пособие

ЛР №020418 от 08 октября 1997 г. Подписано к печати Формат 60x80 1/16 Объем 8,75 п.л. Тираж 100 экз. Заказ №

Московский государственный университет приборостроения и информатики

107996, Москва, ул. Стромынка, 20

Documents

Брейман А.Д. Управление большими базами данных, 2009г