Новые возможности SQL Server 2005 изменят жизнь администраторов к лучшему
Привнесенные в SQL Server 2005 усовершенствования и дополнительные функции окажут влияние на все аспекты использования продукта и позволят создавать абсолютно новые инфраструктуры и платформы. Эта статья посвящена новым функциям и средствам, адресованным администраторам баз данных. Приступая к написанию статьи, я составил список функций, которые претерпели значительные изменения, а также новых функций и без труда насчитал более десятка таких, о которых стоило бы рассказать. И тут я понял, что есть риск, как говорится, за деревьями не заметить леса. Поэтому я решил, что необходимо осветить два основных момента. Во-первых, те преимущества, которые заставляют задуматься о переходе на SQL Server 2005, и, во-вторых, какое влияние сразу окажут новые функции на задачи повседневного управления и сопровождения баз данных. Я не буду останавливаться на улучшениях в инструментальных средствах — это достаточно подробно описано в статье Кэлен Дилани и Рона Телмеджа «Средства управления SQL Server 2005».
Зеркалирование базы данных
Новые средства зеркалирования баз данных в SQL Server 2005 позволят обеспечить действительно высокую отказоустойчивость. Проще говоря, зеркалирование базы данных позволяет создать в реальном времени точную копию базы данных на резервном сервере. В случае отказа основного сервера исполнение автоматически передается на резервный сервер.
В редакциях SQL Server 2000 Enterprise и SQL Server Developer для поддержания резервного сервера использовался перенос журнала транзакций. Эта практика получила широкое распространение, так как подход к организации резервного сервера здесь достаточно прост и не требует использования специализированного оборудования. Однако следует отметить, что перенос журнала транзакций представляет собой гибрид технологий, которые изначально не были предназначены для решения этой задачи. По сути дела, перенос журнала транзакций заключается в сохранении журнала транзакций на исходном сервере, копировании этой резервной копии на целевой (резервный) сервер. Для выполнения таких операций настраивается SQL Agent. Следует отметить, что технология переноса журналов характеризуется некоторыми ограничениями.
- Затраты времени на сохранение/копирование/загрузку журналов вызывают неизбежные задержки.
- Невозможно организовать работу в синхронном режиме, если транзакция не подтверждена на исходном сервере или если она не была принята на резервном сервере.
- В случае отказа не происходит автоматическое переключение на резервный сервер.
- Потенциально существует несколько точек отказа, причем в случае отказа настройка заново переноса журнала транзакций может оказаться сложной задачей.
Зеркалирование баз данных является штатной функцией и позволяет устранить все перечисленные выше недостатки, связанные с организацией резервного сервера.
|
| Рисунок 1. Зеркалирование базы данных |
При организации зеркалирования используются три сервера. На основном (principal) размещается главная база данных. Сервер резерва (mirror) содержит копию. Третий сервер, свидетель (witness), является необязательным и позволяет организовать автоматическое переключение. Для автоматического переключения клиентов в случае отказа основного сервера используется новая функция автоматического перенаправления клиентов. Для организации зеркалирования базы не требуется использование специализированного аппаратного обеспечения, а сам процесс настройки удивительно прост. Вместо копирования файлов журналов при зеркалировании между серверами устанавливается специализированный сеанс зеркалирования, который используется для передачи между серверами отдельных записей транзакций. Зеркальная копия базы данных находится в режиме non-recovered — это означает, что она недоступна для чтения. На рис. 1 приведена схема топологии для зеркалирования серверов. Имеется также возможность организации доступа для чтения данных из зеркальной копии с использованием снимков (snapshot) базы данных (подробнее о снимках будет рассказано ниже).
Сеанс зеркалирования может быть настроен для работы в синхронном или асинхронном режиме. В синхронном режиме изменения в базе основного сервера завершаются только в том случае, когда завершена запись этих изменений в базу данных на резервном сервере. В этом режиме задержки определяются скоростью передачи данных по сети и объемом изменений. Асинхронный режим позволяет добиться увеличения скорости работы и сократить задержки, поскольку завершение изменений основным сервером осуществляется без подтверждения от резервной базы данных. Более подробные сведения о зеркалировании баз данных можно найти в статье Рона Телмеджа «Database Mirroring in SQL Server 2005 — Зеркалирование баз данных в SQL Server 2005», которая доступна на сайте Microsoft по адресу http://www.microsoft.com/technet/prodtechnol/ sql/2005/dbmirror.mspx.
Важное замечание. Поскольку, по данным Microsoft, в ходе начального бета-тестирования технология зеркалирования баз данных была опробована меньшим числом пользователей, чем ожидалось, и, соответственно, полученные сведения не обеспечивают полной уверенности в абсолютной надежности этого средства обеспечения высокой отказоустойчивости баз данных, было принято решение о необходимости продолжения тестирования, прежде чем эту технологию можно будет сделать общедоступной. Технология успешно выдержала расширенное внутреннее тестирование, и в Microsoft было принято решение сделать ее широко доступной в первой половине 2006 года. В окончательной версии для производства SQL Server 2005 технология зеркалирования баз данных будет по умолчанию отключена, но будет доступна для опробования в режиме трассировки. Microsoft продолжит «полевые испытания» с заинтересованными заказчиками и сделает технологию зеркалирования широко доступной, как только это станет возможным.
Снимки базы данных
Снимки базы данных представляют собой новую функциональность SQL Server 2005, которая позволит повысить надежность и отказоустойчивость базы данных. Снимок — это специальный объект, представляющий собой доступную только для чтения копию базы данных в определенный момент времени. Можно создать снимок-копию состояния базы данных в определенный момент времени, присвоить этому снимку имя и назначить собственные имена файлов данных для каждого из файлов данных исходной базы данных. Поскольку снимки доступны только для чтения и не могут быть изменены по определению, файлы журналов для них создаваться не будут. Снимок базы данных предельно эффективно использует дисковое пространство. Создаваемые файлы данных изначально пусты и не содержат никаких данных. Копирование страниц данных в файлы снимка происходит только в момент изменения страниц в исходной базе данных. При повторном изменении тех же страниц в исходной базе дополнительное копирование в файл снимка не происходит — понятно почему.
При выполнении запроса к данным из снимка SQL Server осуществляет чтение страниц, которые претерпели изменение, из файла снимка, а остальные страницы, данные в которых не изменялись, будут запрошены из файла данных исходной базы. Максимальный размер, который может иметь снимок, равен размеру исходной базы данных в момент создания снимка — это может быть в том случае, если каждая страница исходной базы данных после создания снимка оказалась изменена.
SQL Server 2005 позволяет создавать множественные снимки базы данных в различные моменты времени. Можно настроить периодическое создание снимков — каждый день или каждый час. В случае непреднамеренного удаления данных их можно восстановить из наиболее свежего снимка. Можно создавать снимки базы данных перед выполнением сложных задач и запросов, в результате которых данные могут быть испорчены. Например, какой-то процесс может оказаться слишком сложным, чтобы заключать его в одну транзакцию. В этом случае можно сделать снимок, и в случае сбоя при выполнении процесса можно будет вернуться к исходному состоянию — при условии, что в промежутке не были сделаны другие снимки. Использование снимков незаменимо, если вам необходимо формировать отчеты по всем данным в базе как они есть в определенные моменты времени.
Наконец, снимки базы данных можно создавать на резервной зеркальной базе данных (в таком случае зеркальная база становится доступной для чтения), это позволяет значительно снизить нагрузку на основную базу данных.
Хотя преимущества, которые достигаются при использовании снимков базы, очевидны, не следует забывать, что при каждом изменении новой страницы в основной базе данных происходит копирование этой страницы данных в файл снимка. Эта операция требует ресурсов и может замедлить выполнение некоторых изменений в исходной базе данных.
Версии строк и изоляция снимков
В SQL Server 2000 существует только одна версия строки данных — текущая, т. е. актуальная, наиболее свежая. В SQL Server 2005 представлена новая технология, позволяющая сохранять различные версии строки в виде списка значений, сохраняемых в базе tempdb. Благодаря этому достигается сразу несколько целей: обеспечение разных уровней изоляции снимков, построение вставленных и удаленных таблиц в триггерах и онлайн-операциях с индексами, а также поддержка технологии Multiple Active Result Sets (MARS).
Новый уровень изоляции выполняемых операций позволяет SQL Server работать в режиме, не требующем при чтении данных использования блокировок без монополизации (shared locks). Таким образом, операции записи не препятствуют чтению. Благодаря использованию версионности строк SQL Server при выполнении запросов на чтение данных возвращает согласованные корректные значения строки таблицы. В случае изоляции выполняемых операций снимков SQL Server возвращает наиболее свежую согласованную версию строки данных, которая существовала на момент начала исполнения транзакции чтения (если быть точным, это соответствует времени получения сервером первого предложения транзакции). Благодаря этому гарантируется, что множественные операции чтения, выполняемые в рамках одной транзакции, будут возвращать одну и ту же версию строки данных. Этот уровень изоляции снимков позволяет обнаруживать конфликты при обновлении данных. Если во время выполнения одной транзакции, осуществляющей чтение строки данных, обработку и последующее изменение этой строки, та же самая строка данных оказалась изменена другой транзакцией, первая транзакция получит отказ и может быть отменена.
В SQL Server 2005 также представлен новый уровень изоляции исполнения, основанный на версионности строк данных. Этот уровень изоляции, называемый Read Committed with Snapshot (подтверждение чтения из снимка), представляет собой усовершенствованный вариант существующего уровня изоляции. В этом режиме изоляции исполнения транзакции последовательные запросы SELECT будут возвращать действительные подтвержденные значения строки данных. Другими словами, последовательные операции чтения, выполняемые в рамках одной транзакции, могут возвращать разные версии значений одной и той же строки данных, причем все они будут подтвержденными. Выполняемые операции чтения могут не дожидаться завершения операций изменения данных.
Новые уровни изоляции позволяют повысить производительность работы приложений, которые преимущественно считывают данные, поскольку не тратится время на завершение операций модификации данных. Это простой способ обеспечить режим оптимистичной блокировки с обнаружением конфликтов. Конечно, эти уровни изоляции могут оказаться неприемлемыми в некоторых видах приложений из-за накладных расходов на поддержку и обработку связанных списков версий строк данных, хранящихся в tempdb. Очевидно, что подобные уровни изоляции не дадут выигрыша для приложений, совершающих много операций по изменению из-за значительного числа конфликтов при обновлении данных.
Версионность строк данных используется в SQL Server 2005 для построения в триггерах вставленных и удаленных таблиц. В SQL Server 2000 вставленные и удаленные таблицы являются представлениями раздела журнала транзакций, содержащими изменения данных, вызвавших выполнение триггеров. Выполняя запросы о вставленных и удаленных данных, можно получить версии данных по состоянию на момент до и после выполнения изменений. Таким образом, обработка этих запросов в действительности является сканированием отдельных участков журнала транзакций. Даже без учета триггеров такое использование журнала транзакций может оказаться узким местом, особенно для приложений оперативной обработки транзакций OLTP (online transaction processing). Запись в журнал транзакций SQL Server может выполняться только последовательно. Поэтому вмешательство в работу с журналом транзакций (а именно это происходит при запросе вставленных и удаленных в триггерах и при репликации журнала транзакций) в конечном счете вызывает задержки в сохранении изменений данных. При проектировании и оптимизации базы данных всегда требуется учитывать особенности и механизмы работы журнала транзакций.
SQL Server 2005 использует версионность строк для отслеживания изменений, которые вызывают выполнение триггеров и выполняются в самих триггерах. SQL Server строит таблицы вставленных и удаленных из связанных списков версий строк данных (эти связанные списки хранятся в tempdb). В отличие от журнала транзакций, чтение и запись tempdb могут осуществляться в параллельном режиме, если база tempdb распределена между несколькими дисковыми накопителями. Да, присущие журналу транзакций ограничения удалось снизить, но взамен потребуется оптимизировать базу tempdb.
Еще одно важное нововведение, использующее технологию версионности строк данных, — это онлайновые операции с индексами. В SQL Server 2000 все операции с индексами (в том числе создание, перестройка и удаление) производятся в автономном режиме. Необходимо периодически выполнять перестройку индексов для предотвращения их фрагментации (фрагментация значительно замедляет выполнение упорядоченного сканирования). Для выполнения перестройки кластерного индекса SQL Server осуществляет эксклюзивную блокировку таблицы, так что таблица оказывается недоступна для чтения и записи. При перестройке обычного индекса выполняется блокировка таблицы без монополизации, т. е. таблица для записи недоступна, а сам перестраиваемый индекс оказывается недоступен на время выполнения операции. В SQL Server 2000 имеется утилита для оперативной дефрагментации индексов (DBCC INDEXDEFRAG), позволяющая обойти некоторые проблемы, связанные с перестройкой индексов. Однако эта утилита иногда требует для выполнения больше времени, чем обычная перестройка индекса, затрачивает больше ресурсов журнала транзакций, а результат ее работы по качеству отстает от полной перестройки индекса.
В SQL Server 2005 введены оперативные операции с индексами (создание, перестройка, удаление). Я считаю, что это важный шаг вперед, поскольку управление индексами имеет большое значение для организации регулярного сопровождения баз данных. SQL Server использует версионность строк данных для обеспечения возможности выполнения изменений, которые происходят во время перестройки индексов. Это можно представить как построение второй копии индекса, которая замещает первый индекс после завершения построения. При этом во время создания копии индекса данные и исходный индекс остаются доступными для использования. Конечно, эта операция требует наличия достаточного дискового пространства. Появление подобных операций с индексами будет особо востребовано приложениями, требующими непрерывной отказоустойчивости данных в режиме работы 7х24, которые не могут допускать простоя в операциях.
Встроенная поддержка работы с разделами
Работа с разделами не является новой концепцией в SQL Server 2005. Масштабирование и сопровождение огромных таблиц данных может доставить массу хлопот администраторам баз данных, поскольку при этом требуется перестраивать индексы, бороться с фрагментацией, архивировать и удалять устаревшие данные — все это весьма трудоемкие операции, отнимающие много времени и требующие внимания и аккуратности. С ростом объема таблиц выполнение загрузки данных начинает требовать все больше времени из-за необходимости поддержки различных индексов. В качестве одного из способов обхода описанных трудностей администраторы баз данных используют разделы — это позволяет физически разделить слишком большие таблицы данных на группу меньших по размеру единиц управления, которыми проще управлять. Таким образом, использование разделов позволяет обеспечить масштабирование данных.
Работа с разделами в SQL Server 2000 реализуется как гибрид нескольких элементов, которые не предназначались для этой цели, а именно таблиц, проверочных ограничений, представлений и некоторых дополнительных приемов. Для работы с разделами в SQL Server 2000 требовалось выполнить следующие действия.
- Создание групп таблиц меньшего размера взамен одной большой.
- Ограничение диапазона, поддерживаемого каждой из таблиц с помощью механизма проверочных ограничений.
- Создание представлений для объединения отдельных таблиц в единое целое, подобное исходной большой таблице, для приложений и пользователей.
Тот факт, что в SQL Server 2000 отсутствует встроенная поддержка секционирования, накладывает существенные ограничения на управление разбитыми на разделы данными и существенно снижает производительность. Администраторам баз данных приходится иметь дело с множеством объектов управления вместо одного. Каждый раздел представляет собой отдельную таблицу, так что могут возникнуть различия в схемах данных и индексировании разделов. Оптимизатор SQL Server по отдельности обрабатывает разделы при построении плана исполнения — это приводит к большим затратам времени на построение плана, а сам он оказывается более сложным. Обновление данных, использующих представления для объединения множества таблиц (см. рис. 2), требует выполнения определенных условий и накладывает существенные ограничения.
|
| Рисунок 2. Секционированное представление в SQL Server 2000 |
В SQL Server 2005 реализована встроенная поддержка секционирования на разделы для таблиц и индексов, что позволяет устранить многие ограничения, присущие работе с разделами в SQL Server 2000. Теперь можно создать один объект, таблицу или индекс, имеющие внутреннее разбиение на разделы, как показано на рис. 3. Работа осуществляется как с обычным объектом, что позволяет значительно снизить накладные расходы на управление и сопровождение. Создание, удаление и переключение разделов осуществляется непосредственно новыми встроенными командами SQL Server 2005. Устранено большинство ограничений, связанных с чтением и изменением данных. Кроме того, значительно упростилась задача оптимизатора SQL Server; поскольку все разделы таблицы имеют идентичную схему данных и индексы, планы исполнения оказываются, как правило, значительно проще.
|
| Рисунок 3. Секционированная таблица в SQL Server 2005 |
Мониторинг с использованием DMV и DMF
В SQL Server 2005 представлено 70 новых динамических представлений для управления (Dynamic Management Views, DMV) и динамических функций управления (Dynamic Management Functions, DMF), которые обеспечивают доступ к информации о текущем состоянии сервера SQL Server, его производительности, позволяют выполнять диагностику проблем и настраивать производительность экземпляров сервера и баз данных.
Диагностическая информация теперь легко доступна, полностью документирована и представляется в виде обычных таблиц. Некоторая часть этой информации была вообще недоступна в SQL Server 2000, часть была документирована, но не была представлена в табличном виде (например, сведения о фрагментации DBCC SHOWCONTIG), а часть — доступна только через недокументированные средства (информация об ожидании DBCC SQLPERF(WAITSTATS)).
Новые DMV и DMF представляют сведения о двух контекстах — контексте базы данных и контексте сервера. Новые динамические объекты управления представляют следующие категории диагностики: Common Language Runtime (общая среда исполнения), Database Mirroring (зеркалирование баз данных), Databases (базы данных), Execution (исполнение), Full-Text Search (полнотекстовый поиск), Indexing (индексация), I/O (ввод/вывод), Query Notifications (уведомления о запросах), Replication (репликация), Service Broker (брокер служб), SQL Operating System (операционная система SQL) и Transactions (транзакции). Полная информация об этих объектах доступна в оперативной документации SQL Server 2005 Books Online в разделе Dynamic Management Object (динамические объекты управления). Не стоит жалеть времени на изучение этих объектов — предоставляемая ими информация имеет огромную ценность.
Безопасность
В SQL Server 2005 значительно усовершенствованы средства безопасности. Все разрешения теперь предоставляются с помощью предложения GRANT. В SQL Server 2000 некоторые разрешения предоставлялись непосредственно, а некоторые можно было назначить только косвенным образом, например через назначение роли. Управление безопасностью в SQL Server 2005 построено по иерархическому принципу и потребует привыкания к новому словарю. Например, термином securables (объекты защиты) обозначаются объекты (entity), доступ к которым может быть предоставлен или ограничен с помощью разрешений (это регистрация в базе данных на уровне сервера, сборки или службы на уровне базы данных либо сущности низкого уровня, такие как тип на уровне схемы или таблица на уровне объектов). Разрешения над объектами защиты securables предоставляются принципалам (principals) т. е. группам/учетным записям Windows, ролям/учетным записям SQL Server, ролям/пользователям баз данных.
SQL Server 2005 использует корректное понятие схемы, как оно определено комитетом ANSI, и полностью отделяет пользователей базы данных от схем. В SQL Server 2000 схема, к которой принадлежат объект и пользователь базы данных, создавший объект, не могут быть отделены, т. е. если пользователь user1 создал таблицу Table1, таблица имеет имя user1.Table1. Если нужно удалить пользователя user1 (например, по причине увольнения), необходимо будет сначала изменить владельца для всех объектов, созданных пользователем user1, и назначить их другим пользователям. SQL Server 2005 позволяет создавать объекты в схемах, при этом схема не содержит сведений о пользователе базы данных. Можно предоставлять, запрещать и отзывать разрешения доступа к схеме (securable в терминологии SQL Server 2005) у принципалов. Никаких проблем с удалением пользователей не возникает, ведь пользователи не являются владельцами объектов. Кроме того, достигается значительно большая гибкость в управлении защитой коллекций объектов (т. е. схемами).
Еще одно усовершенствование, которого давно ждали администраторы баз данных, — появление в базе встроенных средств шифрования данных. SQL Server 2005 представляет новые средства, позволяющие управлять контекстом безопасности для команд и процедур с использованием предложения EXECUTE AS. EXECUTE AS заменяет старое предложение SETUSER и обеспечивает большую гибкость для изменения контекста безопасности. Более подробные сведения об изменениях в системе безопасности SQL Server 2005 содержатся в библиотеке SQL Server 2005 Books Online. Также можно прочитать статью «Introduction to SQL Server 2005 Relational Engine Security Features» (http://www.microsoft.com/ technet/prodtechnol/sql/2005/sqlsysec.mspx).
Усовершенствования T-SQL
Если в сферу ваших обязанностей входит разработка, анализ и сопровождение кода T-SQL, вы найдете для себя в SQL Server 2005 массу нового и интересного. Достаточно подробно изменения T-SQL описаны в статье «T-SQL 2005», которая доступна на сайте SQL Server Magazine по ссылке http://www.windowsitpro.com/departments/ DepartmentID/946/946.html. Здесь я упомяну только наиболее важные и интересные изменения в языке описания данных Data Definition Language (DDL) и языке манипулирования данными Data Manipulation Language (DML).
В SQL Server 2005 были введены триггеры DDL, которые позволяют отвергать или выдавать другую реакцию на события DDL. Триггеры позволяют реагировать на события уровня сервера (например, ALTER LOGIN) или уровня базы данных (такие, как CREATE TABLE). Результат использования таких триггеров трудно переоценить — например, подобным образом можно установить твердое соблюдение политик именования объектов, аудита, изменений версии схемы и обеспечить выполнение множества других операций.
В SQL Server 2005 введен новый тип данных XML, позволяющий сохранять данные XML в базе данных и использовать XML в локальных переменных и входных/выходных аргументах процедур. Данные XML могут быть проиндексированы с помощью специальных индексов XML, можно задействовать специальные ограничения XML и выполнять запросы и изменение данных с использованием языка XQuery.
Изменения коснулись и типов данных переменного размера (VARCHAR, NVARCHAR, VARBINARY) — теперь можно задействовать описатель MAX для определения максимального размера элемента вместо точного указания размера. С помощью описателя MAX SQL Server может самостоятельно определять, использовать ли такие данные как обычное значение или большой объект. Особенно удобно то, что для новых типов унифицировано обращение в программировании для регулярных типов и больших объектов. Можно использовать новые типы в качестве локальных переменных, параметров процедур и выполнять большинство операций, применимых к обычным типам данных.
Также нельзя не упомянуть два расширения языка запросов — Analytical Ranking Functions и Recursive Queries. Аналитические функции позволяют получать номера строк и другие значения сравнения для строк в результирующем наборе. Использование этих функций позволило мне произвести настройку и отладку многих решений. Рекурсивные запросы очень удобны при обработке и манипулировании иерархическими данными.
Что дает SQL Server 2005 администраторам баз данных?
SQL Server 2005 содержит огромное количество нововведений и улучшений. Надеюсь, что моя выборка пробудит у читателей интерес к продукту и поможет более эффективно воспользоваться новыми преимуществами, которые он предоставляет. SQL Server 2005 позволит администраторам баз данных работать более продуктивно, а организациям — в полной мере воспользоваться разнообразными возможностями SQL Server 2005.
Ицик Бен-Ган - Cтарший преподаватель на курсах по SQL Server в колледже Hi-Tech в Израиле. Имеет сертификаты MCDBA, MCSE+I, MCSD, MCT и SQL Server MVP. Глава израильской группы пользователей SQL Server. itzikb@hi-tech.co.il