(Возврат на основную страницу)

Содержание номера за Сентябрь 2009 год

SQL Server

Сентябрь 2009
№ 9 (105)

Editorial

Тони Дэвис

Блеск и нищета Log Shipping 

Programming

Эрик Браун

Шифрование без проблем  

DB Design & Warehousing

Мишель А. Пуле

Организация хранилищ данных: начальные сведения об измерениях (основы измерений) 

Организация хранилищ данных: обмер фактов 

Other

Роберт Шелдон

SQL Server 2008: задача «Профилирование данных» служб SSIS. Часть 2

Эндрю Дж. Келли

Знакомство со статистиками ожидания

Блеск и нищета Log Shipping

С появлением в составе SQL Server 2005 технологии зеркалирования баз данных (Database Mirroring), показалось разумным предположить, что log shipping постепенно выйдет из моды. Зеркалирование — способ обеспечения отказоустойчивости SQL Server за счет мгновенной передачи управления серверу горячего резерва, причем это делается незаметно для приложения, использующего БД. (При использовании SQL Native Client в качестве провайдера. — Прим. ред.) Это, в теории, мечта для .Net­разработчиков: от приложения не требуется никаких дополнительных действий для получения преимущества от устойчивости БД к аппаратным сбоям.

В то же время, Log Shipping существует гораздо дольше. Сначала, как что­то вроде «самопального» решения, которое неустрашимый администратор мог заставить работать с версиями 6.5 и 7.0, до появления официального варианта, встроенного в enterprise edition SQL Server 2000. Это технология, базирующаяся на заданиях SQL Server Agent, которые обеспечивают передачу копий журналов транзакций с основного на резервный сервер. Таким образом, у вас появляется возможность поддерживать один или более резервных серверов в состоянии готовности на случай падения основного сервера. Этот способ обеспечения отказоустойчивости работает хорошо, требует всего нескольких щелчков мыши для настройки, но для перевода резервного сервера в рабочий режим администратору приходится побегать и обычно такой перевод приводит к простою длительностью 15­30 минут. Кроме того, перенастройка клиента также требует некоторого количества ручной работы.

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

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

В этом последнем аспекте работы log shipping кроется особенность технологии, позволяющая ей так долго продержаться в числе лидеров. Многие администраторы рассматривают обеспечение высокой доступности как побочный продукт от возможности создавать вторичные серверы для нужд подготовки отчетов. При использовании зеркалирования, БД на резервном сервере доступна для конечных пользователей только после его перехода в промышленный режим. Единственный способ обойти это ограничение — использование «снимков» резервной БД, что автоматически выставляет требование использовать Enterprise Edition. При использовании log shipping все, что вам необходимо, — это резервные копии журнала и несколько дешевых серверов, на которых работает SQL Server Express. При этом вы получаете эффективное решение с вынесенным сервером отчетности и дополнительно отказоустойчивую систему для бедных в качестве бесплатного приложения! (У автора явно эмоции затмили здравый смысл. Во­первых, ограничения SQL Server Express достаточно обширны: http://technet.microsoft.com/ru­ru/library/ms165636(SQL.90).aspx, но самое главное, на момент закачки очередной копии журнала, из базы нужно выгнать всех пользователей. Соответственно, либо задержки между накатом журнала будут слишком велики, либо пользователи будут все время выгоняться из базы. Не говоря уж о том, что использование слабого сервера с Express — очень плохая замена мощному основному серверу на случай реального падения. Так что нарисованная картина требует тщательного анализа и осмысления. — Прим. ред.)

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

Администраторы цепляются за log shipping и у них есть на то реальные причины, которые не всегда заметны борцам за «чистоту». Но есть ли у технологии долговременные перспективы?]

Шифрование без проблем

Эрик Браун — автор «SQL Server 2005 Distilled», изданной Addison-Wesley. Это скорее оригинальная статья, чем выдержка, но она основывается на материале этой книги. В этой статье мы ознакомимся с тем, как шифрование базы данных, новая возможность SQL Server 2005, может использоваться для защиты объектов базы данных, а также самих данных.

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

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

Группа разработчиков SQL Server не стала изобретать велосипед для реализации шифрования; данная возможность основана на мощных и надежных API шифрования Windows.

Азы криптографии

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

Примечание: Действительно хороший источник информации по шифрованию — http://en.­wikipedia.org/wiki/Encryption.

Существует два типа алгоритмов шифрования: симметричные и асимметричные. При симметричном методе используется засекреченная пара ключей, имеющаяся как у отправителя, так и у получателя сообщения. Не существует открытого (public) ключа. И обе стороны априори знают друг о друге. Обе они применяют один и тот же ключ для зашифровывания и расшифровки сообщений. В примере далее в этой статье мы используем симметричный ключ, чтобы проиллюстрировать возможное применение шифрования. Его не рекомендуется использовать при работе с Веб, но оно прекрасно подходит для приложений, передающих конфиденциальные данные там, где вам известно, кто подсоединяется к источнику данных. Мы использовали эти функциональные возможности в приложениях, предоставляющих данные серверу SharePoint Portal посредством специально разработанных веб­частей (custom web parts), а также в приложениях сервер­сервер.

Когда ключ асимметричен, отправитель зашифровывает сообщение закрытым (private) ключом, который не используется совместно с получателем сообщения. Вместо этого у получателя имеется ключ, с помощью которого сообщение можно открыть. Открытый ключ не может использоваться для установления закрытого ключа; таким образом, обладатель закрытого ключа имеет значительный уровень доверия. Преимущество открытого ключа/асимметричной модели состоит в том, что закрытый ключ неизвестен клиенту. Это более безопасно, поскольку необходимости отправлять ключ клиенту нет. Модель с симметричным ключом, напротив, требует, чтобы получателю был отправлен ключ и, как правило, какой­то пароль для его открытия. Нынешние модели TLS и SSL, используемые на общественно доступных сайтах, применяют модель с открытым ключом. В Википедии есть отличная статья (http://en.wikipedia.org/wiki/Secure_Sockets_Layer) об этом. И, наконец, модель SSL применяется в Интернете, поскольку серверу необязательно знать, «кто» к нему подключен.

SQL Server 2005 поддерживает следующие алгоритмы асимметричного шифрования: RSA, RC2 (Ron’s Code 2) и RC4 (Ron’s Code 4). Протокол RSA широко применяется и интенсивно используется в транзакциях наподобие электронной коммерции. Я рекомендую до некоторой степени узнать об этих протоколах и иметь общекорпоративное соглашение об их использовании. Алгоритм RC2 был опубликован в Интернете в виде сообщений групп Usenet.

Симметричные алгоритмы шифрования, применяемые в SQL Server 2005, — это Data Encryption Stan­dard (DES), Triple DES, DEX­X и Advanced Encryption Standard (стандарт, принятый правительством США).

Организация хранилищ данных: начальные сведения об измерениях (основы измерений)

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

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

Организация хранилищ данных: обмер фактов

Многомерное моделирование состоит из моделирования логического и физического. Меры (measures) — это ядро многомерной модели, это элементы данных, которые можно суммировать, для которых можно вычислять среднее значение или математически оперировать которыми. Таблицы фактов находятся в центре схемы «звезда» (являющейся физически реализованной многомерной моделью), а витрины данных формируются из нескольких таблиц фактов. Вы можете применять многомерное моделирования для создания корпоративного хранилища данных, облегчающего бизнес-аналитикам (BI) и конечным пользователям доступ к данным и их интерпретацию. Теперь давайте исследуем различия между моделью типа «сущность-связь» (ER) и многомерными моделями, изучим компоненты, из которых состоит многомерная модель, а также то, почему они спроектированы так, а не иначе.

Сравнение многомерного и ER-моделирования

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

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

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

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

SQL Server 2008: задача «Профилирование данных» служб SSIS. Часть 2*

Формирование профиля включения

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

*См. Роберт Шелдон. SQL Server 2008: задача «Профилирование данных» служб SSIS. Часть 1 // SQL Server для профессионалов. 2009. № 8.

Знакомство со статистиками ожидания

В статье «Знакомство со статистиками виртуальных файлов» («Getting to Know Virtual File Stats») я показывал, каким образом применять конкретное динамическое административное представление (dynamic management view — DMV) для слежения за использованием физического ввода-вывода применительно к SQL Server 2005. В этом месяце я применю тот же подход с другим DMV, позволяющим отслеживать статистики ожидания на вашем экземпляре SQL Server.

Основы статистик ожидания

Когда бы ни делался запрос, если в SQL Server он по одной из многих причин не может быть удовлетворен немедленно, система переводит его в состояние ожидания. Ядро SQL Server внутренне отслеживает время, проведенное в ожидании, собирает его воедино на уровне экземпляра и хранит в памяти. Используя DMV SQL Server 2005, называемое sys.dm_os_wait_stats, вы можете прочитать эти метрики (или статистики) в любое время. Sys.dm_os_wait_stats материализует значения статистик ожидания, хранящиеся в памяти, в виде типичного результирующего набора, который представляет совокупные времена ожиданий для всех процессов, завершившихся с того момента, когда в последний раз были сброшены счетчики. Знайте, что SQL Server сбрасывает эти счетчики в 0 при каждом перезапуске; или же вы можете сбросить их вручную, выполнив команду

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);

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

На момент написания этой статьи существует чуть больше 200 различных типов ожиданий, доступных для отслеживания в SQL Server. Microsoft будет со временем добавлять еще больше с каждой новой версией и пакетом обновлений. Вам, вероятно, никогда не потребуется иметь дела с большинством этих типов ожиданий, поэтому не стоит слишком беспокоиться о том, чтобы знать, что все они значат. Если вам нужны подробности о каждом типе ожидания, обратитесь к статье Microsoft «SQL Server 2005 Waits and Queues» (http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/performance_tuning_waits_queues.mspx). Эта статья содержит некоторые скрипты для сбора информации об ожиданиях в вашей системе и оповещения о них. В подфорум SQL Server Magazine Performance Tuning and Optimization (http://sqlforums.windowsitpro.com/web/forum/categories.aspx?catid=256) я добавлю собственную трактовку того, как фиксировать статистики ожиданий и сообщать о них как в SQL Server 2005, так и в SQL Server 2000.

(Возврат на основную страницу)