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

 

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

Не нужно переходить на SQL Server 2005

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

Не нужно переходить

Предположим, у вас в компании установлен набор SQL Server’ов разных версий. Маловероятно, чтобы они все были версии 2005. Скорее всего, основная часть установленных версий — это 2000, некоторое количество версии 7 (правда?) и, надеюсь, совсем нет 6.5. Будем считать, что у вас установлено несколько экземпляров SQL Server 2005 или вы используете эту версию только на настольном компьютере или лэптопе.

Учитывая, что поддержка от Microsoft для SQL Ser­ver 2000 заканчивается следующим летом и давно закончилась для всех предыдущих версий, вам следует уйти с SQL Server 2000 в течение следующего года.

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

Поддержка

В июле 2008 года поддержка SQL Server 2000 заканчивается. Я имею ввиду, что заканчивается так называемый mainstream support. Выпуск заплаток по безопасности будет продолжаться, и можно будет заключить специальный контракт на поддержку с почасовой оплатой. Интересно отметить, что на странице, где упоминается SP4, стоит N/A (неизвестно) в поле окончания поддержки и есть примечание, что поддержка закончится через 12 или 24 месяца после выхода следующего пакета обновлений. Я исхожу из предположения, что SP5 не будет выпущен, но никто не может сказать это точно.

С другой стороны, известно, что Microsoft обычно поддерживает две версии того или иного продукта. Вряд ли поддержка с SQL Server 2000 будет снята до выхода SQL Server 2008.

Еще стоит подумать о том, что следующей версией, скорее всего, будет SQL Server 2011. Слабо верится в выход версии в 2010 году. Соответственно, если вы перейдете на SQL Server 2005 сейчас, то до следующего вынужденного перехода у вас будет 4–5 лет, тогда как переход сразу на SQL Server 2008 даст вам период спокойной жизни длиной в 7–8 лет. И если вы сейчас используете версию 2000, то это достаточно длительный период, чтобы сформировать стабильную среду работы.

Стабильность

SQL Server 2005 — прекрасный продукт. Он очень стабилен и имеет немного проблем. Хотя и было выпущено больше модификаций, чем я ожидал, ни одна из них не связана с безопасностью, и в целом я весьма впечатлен. Мне он нравится больше чем версии 7 и 6.5. Я говорю именно о двух версиях, потому что Microsoft, создается впечатление, работает по прин­ципу двух версий в одном продуктовом цикле. Версии 6.0 и 6.5 почти не отличались, и 6.5 был очень стабильным продуктом (особенно в сравнении с версией 4.2). Потом вышел полностью переработанный 7.0. Он представлял собой принципиально новый подход, но имел немало проблем, и эту версию нельзя было назвать стабильной, что неудивительно для полностью переработанного продукта. Выпущенная двумя годами позже версия 2000 отличалась большей стабильностью и оказалась фантастическим продуктом для тысяч пользователей.

В свете сказанного, я рассматриваю SQL Server 2005 как первый выпуск новой версии платформы, а SQL Server 2008 как стабилизированную версию. Следовательно, имеет смысл подождать выхода SQL Server 2008. У меня нет никакой информации относительно будущих возможностей версии 2011, но можно предположить, что она будет использовать NET 4.0, улучшенные средства интеграции и усовершенствованные способы работы с неструктурированными данными.

Функциональность

Я успел написать одну статью о функциональности и над другой статьей работаю. Вначале я полагал, что комплект новых возможностей будет не так уж велик и вряд ли станет реальной причиной, по которой стоит мигрировать на новую версию. Теперь я уже не так в этом уверен. Если рассматривать описания к альфа­версии, то ничего особенного там и не было. Кое­что, вроде сжатия резервных копий, может не очень понравиться сторонним разработчикам, но больше всего меня впечатлило, что для работы отчетного сервера больше не нужен IIS. Теперь же, после выхода июньской сборки CTP и докладов на techEd, я обнаружил гораздо больше запланированных изменений, которые реально меня взволновали. И в основном это касается средств администрирования. Могло показаться, что SQL Server 2005 был в основном ориентирован на разработчиков, тогда как SQL Server 2008 стремится выровнять дисбаланс для администраторов. Это касается и административных политик, и возможности деинсталлировать сервисные пакеты, и, конечно, администратора ресурсов (resource governor), который позволит управлять загрузкой процессора и памятью на уровне групп соединений.

Заключение

Мне очень нравится SQL Server. Именно это побудило моих партнеров и меня начать разработку сайта sqlservercentral.com. Этот продукт не просто позволил мне построить карьеру, он приносит мне удоволь­ствие от работы.

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

Подождите год и постройте свой цикл стабильной жизни с SQL Server 2008.

Quaere Verum — сканирование кластерных индексов. Часть 2*

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

Методы доступа SQL Server для полного сканирования данных таблицы, если не указана опция ORDER BY

1. Сканирование упорядоченного кластерного индекса

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

2. Сканирование неупорядоченного кластерного индекса/сканирование таблицы

Связный список на уровне листьев кластерного индекса — это один механизм, посредством которого SQL Server может локализовать данные таблицы. Но есть еще одна система, которую SQL Server использует для отображения данных и которая называется IAM (сокращение для Index Allocation Map, карта размещения индекса). Я не буду приводить ужасные подробности относительно карты IAM, а вместо этого сосредоточусь на существенных вещах, необходимых для рассмотрения поднятой мной темы. IAM­страницы — это битовые образы, которые отображают экстенты, принадлежащие индексу или «куче» («куча» — это таблица без кластерного индекса), в том порядке, в котором эти экстенты размещаются в файле. SQL Server поддерживает одну или несколько IAM­страниц, чтобы отобразить/сохранить след тех экстентов, которые находятся на уровне листьев кластерного индекса, в порядке их размещения в файле. IAM­страница имеет по одному биту для каждого размещенного в файле экстента; и этот бит получает значение 1, если представляемый им экстент принадлежит тому объекту, который владеет данной IAM­страницей, или он получает значение 0 в противном случае. Каждая IAM­страница отображает 4 Гб файлового пространства.

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

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

Обратите, впрочем, внимание на то, что если план выполнения демонстрирует неупорядоченное сканирование индекса (Ordered: False), это не обязательно означает, что SQL Server будет использовать IAMстраницы для сканирования данных, напротив, это означает, что SQL Server не должен сканировать данные в порядке связного списка.

3. Расширенное сканирование (Advanced Scanning)

Вот фрагмент из документации Books Online, который объясняет расширенное сканирование:

«Одна из функциональных возможностей реализованного в редакции SQL Server Enterprise Edition режима расширенного сканирования позволяет нескольким задачам совместно осуществлять полное сканирование таблицы. Если план выполнения предложения языка Transact­SQL требует, чтобы было проведено сканирование страниц данных таблицы, а реляционный механизм Database Engine обнаруживает, что эта таблица уже была просканирована для другого плана выполнения, механизм Database En­gine объединяет второе сканирование с первым в текущем расположении второго сканирования. Механизм Database Engine один раз считывает каждую страницу и передает строки каждой страницы в оба плана выполнения. Это продолжается до тех пор, пока не будет достигнут конец таблицы.

К этому моменту первый план выполнения получает результат сканирования в полном объеме, но для второго плана еще необходимо извлечь те страницы данных, которые встретили ранее точки объединения с уже исполнявшимся сканированием. Значит, сканирование для второго плана выполнения возвращается обратно к первой странице данных таблицы и выполняет сканирование в прямом направлении до той точки, в которой произошло объединение с первым сканированием. Аналогичным образом может быть объединено любое число сканирований. Механизм Database Engine будет продолжать циклический перебор страниц данных до тех пор, пока не завершит все сканирования. Этот механизм иногда называют «карусельным сканированием» (merry­go­round scanning), и он является той причиной, по которой не может быть гарантирован порядок результатов выполнения предложения SELECT без предиката сортировки».

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

 См. Итцик Бен­Ган. Quaere Verum — сканирование кластерных индексов. Часть 1 // SQL Server для профессионалов. 2007. № 8.

SQL Server 2005: введение в язык XQuery

Опытный эксперт по SQL Server Майкл Коулз представляет вторую часть своего вводного обзора реализации формата XML в версии SQL Server 2005: краткое исследование языка XQuery — средства, позволяющего обращаться с запросами к XML-данным.

Одной из самых замечательных новых возможностей, реализованных в версии SQL Server 2005, является встроенная поддержка языка запросов XQuery. Новый тип данных XML, который мы рассмотрели в последней статье, в сочетании со встроенной поддержкой этого типа языком XQuery обеспечивает самый легкий из всех известных способов формирования запросов и манипулирования XML­данными на стороне сервера.

В этой статье рассматривается реализация языка XQuery в версии SQL Server 2005. Мы начнем с определения того, что собой представляет язык XQuery.

Что такое XQuery?

XQuery (XML Query) — это стандарт, полученный от тех же разработчиков, которые дали XML (XML 1.0 — http://www.w3.org/TR/2006/REC­xml­20060816/, XML 1.1 — http://www.w3.org/TR/2006/REC­xml11­20060816/), XSL (http://www.w3.org/Style/XSL/) и массу других родственных спецификаций консорциума World Wide Web Consortium (http://www.w3.org). Консорциум W3C определяет язык XQuery 1.0 как расширение языка XPath 2.0 со множественными заимствованиями из нескольких других стандартов языков запросов, включая XPath 1.0, XQL, XML­QL, SQL и OQL.

XQuery — это декларативный, функциональный язык запросов, который оперирует экземплярами объектов модели XQuery/XPath Data Model (спецификация XQuery 1.0/XPath 2.0 Data Model (XDM) — http://www.w3.org/TR/xpath­datamodel/). Модель XDM определяет развитую систему типов, позволяя языку XQuery работать с «абстрактной, логической структурой XML­документа, а не с ее внешним синтаксисом» (W3C­стандарт XQuery 1.0). Это означает, что модель XDM позволяет языку XQuery обращаться с запросами к XML­данным, используя «древовидное» логическое представление XML­данных. Концепция «XML в виде дерева» должна быть знакома тем веб­программистам, которые динамически манипулируют HTML­ и XML­кодом, используя модель Document Object Model (DOM) (хотя сходство между моделью DOM и моделью XDM по большей части на этом и заканчивается). Каждая ветвь (или узел) XDM­дерева поддерживает набор атрибутов, описывающих этот узел. В таком дереве каждый узел имеет XML­тип узла, информацию о типе XDM­данных, контент узла (строки и типизированные представления (typed representations)), данные о родителях/потомках и, может быть, еще какую­то информацию, специфичную для узла данного типа.

Рассмотрим листинг 1, который определяет коллекцию XML­схем, создает типизированную XML­переменную, указывающую на коллекцию XML­схем, а затем заполняет эту XML­переменную допустимым XML­документом.

Язык XQuery может запрашивать типизированные XML­данные, используя древовидную структуру, сформированную моделью XDM. На рис. 1 показано XDM­дерево, сформированное согласно этой XML­схеме для примера XML­документа. Модель XDM может также формировать деревья для нетипизированных XML­данных, в этом случае она назначает тип xdt:untyped узлам­элементам и тип xdt:untypedAtomic атрибутам, это значит, что они не являются допустимыми с точки зрения XML­схемы.

Реализация языка XQuery в версии SQL Server 2005 является подмножеством W3C­стандарта XQuery 1.0, и определенные разделы этого стандарта остались нереализованными в текущей итерации поддержки сервером SQL Server языка запросов XQuery. Это важно знать, если вы пытаетесь выполнить конвертацию готовых XQuery­сценариев, полученных из других источников, например из готовых приложений, по­священных XQuery книг или даже примеров, взятых с веб­сайта консорциума W3C.

Разработка плана восстановления для служб SQL Reporting Services

С каждым днем службы SQL Server 2000 Reporting Services приобретают все большую и большую популярность как средство создания отчетов. Однако план восстановления этого дополнения в случае аварии не ограничивается простым резервным копированием с последующим возвратом в исходное состояние, поскольку в процесс, как правило, вовлечено несколько компонентов и серверов. Впрочем, DBA-ад­ми­нистраторы могут нести ответственность за всю систему в целом. Майк Пирсон знакомит нас с некоторыми сценариями, которые следует учитывать и которые могли бы пригодиться при подготовке к восстановлению в случае аварийного сбоя в работе служб SQL Server 2000 Reporting Services.

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

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

•     Имеются стандартные и актуальные резервные копии баз данных ReportServer и Report­Ser­ver­TempDB.

•     Имеется резервная копия ключей шифрования.

Управление ключами шифрования (Encryption Keys) — это сущность всех процедур восстановления баз данных SQLRS­служб, которые могут потребоваться. Рекомендуется, следовательно, чтобы лица, ответ­ственные за сопровождение экземпляров SQLRS­служб, ознакомились с теми концепциями, которые изложены в документации SQLRS Books Online (BOL) в разделе «Managing Encryption Keys».

Во время установки SQLRS­службы создают ключи шифрования, которые затем используются для защиты удостоверений (credentials), данных подключения и тех учетных записей, которые используются в операциях сервера. Как только вы завершили инсталляцию SQLRS­служб, вы должны сделать копию симметричного ключа (symmetric key). Если вам когда­либо понадобится восстановить инсталляцию служб Reporting Services в связи с изменением имени компьютера, имени экземпляра или параметров учетной записи пользователя, вы можете применить этот ключ, чтобы обеспечить работоспособность базы данных сервера отчетов.

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

Выявление подмены данных в SQL Server

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

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

Постановка задачи

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

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

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

Особенности решения

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

•     Оно может выявлять изменения любой строки в таблице.

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

•     Это решение не обязательно применять ко всей базе данных, его можно задействовать избирательно, для одной или нескольких таблиц, например выявление подмены данных может вестись только в базе Audit Trail, а не в базе данных приложения.

•     Оно может выявлять подмену за некоторый период времени, то есть в заданном диапазоне дат, за конкретную дату или за указанную неделю. Это особенно удобно для баз типа Audit Trail, которые со временем сильно разрастаются.

•     Оно не прибегает к другим языкам и дополнительным средствам, не поставляемым в составе SQL Server, так что может быть реализовано сразу после установки (требуется только SQL Server).

•     Поскольку это всего лишь набор выражений и процедур на языке SQL, для него не требуется особой стратегии развертывания.

Как и любая другая хорошая вещь, это решение имеет и свои недостатки! Вот они:

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

•     И больше ничего — терпеть не могу отыскивать недостатки в собственных идеях!

Генерация файлов журналов с помощью триггеров

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

Когда вы, как DBA, предоставляете данные другим специалистам,  вы стараетесь представлять их в формате, знакомом потребителю этих данных. Информацию в бухгалтерию вы передаете в формате MS Excel, а для обычных пользователей генерируете отчет в формате HTML. Системные администраторы и администраторы безопасности не являются исключением; они привыкли просматривать журналы в виде текстовых файлов или в Event Viewer.

Примечание: Здесь даны примеры для выражения Insert, но их можно легко изменить для работы с De­lete или Update.

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