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

Уже известно, что Microsoft изменила список доступных редакций своей СУБД. Наряду с Web Developer и Express, о которых пока известно не очень много, основными станут редакции Enterprise, Business Intelligence и Standard. Присутствовавшая в SQL Server редакция Datacenter объединится с Enterprise, а Workgroup и Standard for Small Business войдут в Standard. Появление редакции Business Intelligence, которой прежде не было вовсе, объясняется, по-видимому, существенным ростом спроса на инструменты бизнес-аналитики, отмечаемого большинством авторитетных экспертов. В ней доступны все функции редакции Enterprise, за исключением мощных средств обеспечения безопасности (аудита и прозрачного шифрования данных), высокой готовности и, как ни странно, инструментов для построения хранилищ данных (поколоночного индексирования, хранения и сжатия ColumnStore, а также секционирования).

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

Прежде всего, он обращает внимание на средства повышения доступности и катастрофоустойчивости AlwaysOn. В настоящее время для реализации этих качеств выполняются определенные операции либо над базой данных (распространение логов журнала регистрации, репликация, зеркалирование), либо над экземпляром СУБД (отказоустойчивая кластеризация). В SQL Server 2012 можно будет манипулировать также еще и группой БД как одной сущностью. Эта функция называется Availability Group и особенно полезна при эксплуатации современных комплексных приложений, опирающихся на несколько БД. Она поможет восстанавливать группу БД целиком. А поскольку один экземпляр SQL Server будет способен управлять множеством подобных групп, то в случае аварии одна группа может быть восстановлена на экземпляре A, другая — на B, третья — на C и т. д. Это означает, что не нужно будет поддерживать всю нагрузку первичного сервера на одном резервном сервере: ее можно распределить по множеству не столь мощных резервных серверов, сохранив прозрачность привычных механизмов зеркалирования БД.

Более того, теперь можно будет поддерживать несколько реплик каждой Availability Group: часть из них будет располагаться на той же площадке, обеспечивая локальную отказоустойчивость, другая — в удаленном дата-центре, гарантируя устойчивость к выходу из строя главного ВЦ. И наконец, вспомогательные резервные серверы БД, работающие только в режиме чтения, могут взять на себя часть нагрузки по резервному копированию и генерации отчетов, освободив от нее главный сервер. Такую конфигурацию обычно называют Active Secondaries.

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

Еще одно важное новшество, отмеченное Аароном Бертраном, имеет отношение к миграции БД. Как правило, администратору БД приходится решать задачу передачи базы данных под управление другого экземпляра СУБД, если необходимо перенести ее на более мощный сервер, продвинуться на следующий этап жизненного цикла (разработка, тестирование, обеспечение гарантированного уровня качества, пилотная и промышленная эксплуатация) или в процессе восстановления работоспособности после сбоя. Основная трудность здесь в том, что БД не является изолированным объектом: у нее всегда есть некие связи или зависимости, без учета которых нельзя гарантировать, что она будет после переноса функционировать в составе конкретного приложения точно так же, как и ранее. К такому контексту относятся идентификационные данные пользователей, задания SQL Server Agent, сообщения, хранящиеся отдельно от БД, отличия в интерпретации строковых переменных СУБД и операционной системой и т. д. В SQL Server 2012 появится новая функция Contained Databases, которая призвана уменьшить или даже исключить зависимость БД от того, каким экземпляром СУБД она будет управляться. В результате процесс миграции БД должен стать гораздо проще.

В частности, благодаря тому, что идентификатор и пароль пользователя будет позволено определять на уровне БД (contained database user), ее можно переносить на другой сервер не меняя параметров подключения. Аналогично решается проблема несовпадающей интерпретации строк на разных языках (collation) сервером БД и серверной ОС: во избежание разночтений соответствующие правила также будут зафиксированы на уровне Contained Databases и их действие не будет зависеть от платформы нового сервера. Аарон Бертран убежден, что хотя средства Contained Databases еще не решают данную проблему в полной мере, они станут первым важным шагом к тому, чтобы БД могла переноситься с сервера на сервер как полностью автономный объект.

В SQL Server 2012 (точнее в редакции Enterprise) впервые будет реализован механизм поколоночного хранения и индексирования, появившийся в арсенале Microsoft в результате покупки ею несколько лет назад компании VertiPaq. Его основные преимущества — увеличение производительности (для некоторых типов запросов — десятикратное), способность к существенному сжатию и возможность обходиться без предварительного вычисления агрегированных значений. В то же время автор отмечает, что у индексов ColumnStore есть одно важное ограничение: они функционируют только в режиме чтения. После того как индекс ColumnStore построен, никакие операции по внесению изменений в таблицы БД не допускаются (иначе придется перестраивать индекс с самого начала). Из-за этого указанный механизм без каких-либо ухищрений может применяться только для анализа данных, предварительно загруженных в хранилище. Тем не менее, отметил Аарон Бертран, его целесообразно использовать и для отдельных транзакционных задач. К примеру, если БД может быть естественным образом секционирована (скажем, по дням или месяцам), то изменениям будет подвержен лишь раздел таблицы текущего календарного периода, а все остальные могут быть проиндексированы и обработаны с помощью ColumnStore. После завершения календарного периода соответствующий раздел (и только он) индексируется и становится доступным для высокоскоростной аналитической обработки.

СПЕЦПРОЕКТ