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

Содержание номера за Февраль 2009 год

SQL Server
для администраторов

Февраль 2009
№ 2 (32)

 Рэнди Дайс

Публичная (Public) роль сервера в SQL Server 2008

Джеймс Ри

Знакомство с журналом транзакций (Transaction Log). Часть 2 

Пол С. Рэндал

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

Edgewood Solutions Engineers Автоматизация обработки отказов зеркалирования нескольких баз данных

Майкл Колз

Полнотекстовый поиск а-ля Google

Иэн Стирк

Какие SQL-операторы выполняются в данный момент?

Публичная (Public) роль сервера в SQL Server 2008

В свое время, работая с CTP5, я набирал материал, чтобы переработать мой учебный материал SQL Server DBA Bootcamp под нововведения в SQL Server 2008. Одной из вещей, которую я там нашел, стала новая предопределенная роль сервера (fixed server role) Public.

Знакомство с журналом транзакций (Transaction Log). Часть 2*

Как работает журнал транзакций

Как упоминалось в разделе «Логическая архитектура (концепция)», транзакции записываются в журнал последовательно. LSN каждой транзакции имеет значение большее, чем у предыдущей транзакции. Это на самом деле очень просто; никаких сложных математических методов не используется. Не нужно никакого сложного программирования, чтобы добавить новые транзакции. Это буквально так же, как взять лист бумаги и записать каждое событие, произошедшее с вами за день, пронумеровав события по порядку от единицы. Можно сказать, что большинство ниже перечисленных событий произошли с вами перед прочтением этой статьи и именно в таком порядке:

•    Вы перешли по ссылке или открыли документ, содержащий эту статью.

•    Ваше устройство отобразило статью на дисплее или вывело статью в другом формате.

•    Вы начали читать статью.

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

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

Дополнительные источники

•    TechNet: Working with Transaction Log Backups (http://technet.microsoft.com/en­us/library/ms190440.aspx)

•    TechNet: Restoring a Database to a Point Within a Backup (http://technet.microsoft.com/en­us/library/ms190244.aspx)

•    TechNet: Recovering to a Log Sequence Number (LSN) (http://technet.microsoft.com/en­us/library/ms191459.aspx)

•    TechNet: Best Practices for Recovering a Database to a Specific Recovery Point (http://technet.microsoft.com/en­us/library/ms191468.aspx)

•    TechNet: Security Considerations for Backup and Restore (http://technet.microsoft.com/en­us/library/ms190964.aspx)

•    MSDN: DBCC SHRINKFILE (Transact­SQL) (http://msdn.microsoft.com/en­us/library/ms189493.aspx)

•    MSDN: DBCC SQLPERF (Transact­SQL) (http://msdn.microsoft.com/en­us/library/ms189768.aspx)

*См. Джеймс Ри. Знакомство с журналом транзакций (Transaction Log). Часть 1 // SQL Server для администраторов. 2009. № 1.

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

Для разработчиков одной из сложных проблем в SQL Server является отслеживание того, какие данные изменились в базе. Еще более серьезной задачей является создание простого решения, которое не наносит серьезного удара по производительности рабочих нагрузок и несложно в создании, реализации и управлении. Так зачем идти на все эти заботы ради отслеживания изменений? Действительно ли отслеживание изменений стоит всех этих усилий? Двумя часто цитируемыми примерами являются поддержка обновлений в хранилище данных и поддержка синхронизации гетерогенных, изредка подключаемых систем. В хранилище данных обычно как-либо представлены таблицы из базы данных оперативной обработки транзакций (OLTP), но схемы таблиц могут существенно отличаться. Это означает необходимость процесса извлечения, преобразования и загрузки данных (extract, transform, load — ETL), перемещающего данные из базы данных OLTP в хранилище данных.

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

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

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

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

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

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

Технологии, которые были разработаны для отслеживания изменений данных в SQL Server 2008, не предназначались для поддержки аудита, однако SQL Server 2008 предлагает новый компонент, именуемый подсистемой аудита SQL Server, предназначенный специально для аудита. Рик Бихэм (Rick Byham) рассказывал о компоненте подсистемы аудита SQL Server Audit в своей статье «SQL Server 2008: Security» («SQL Server 2008: Безопасность») в апрельском выпуске журнала TechNet Magazine за 2008 год (доступен по адресу technet.microsoft.com/magazine/cc434691).

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

Табл. 1. Сравнение отслеживания изменений и сбора данных изменений

Автоматизация обработки отказов зеркалирования нескольких баз данных

Проблема

Функция зеркалирования базы данных (Database Mirroring) появилась в SQL Server 2005 и стала популярным решением для обработки отказов. Одним из главных свойств зеркалирования баз данных является то, что обработка отказов выполняется в пределах одной базы данных, поэтому если происходит отказ в базе данных, то вступает в дело зеркальный сервер, но все остальные базы данных функционируют на основном сервере.

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

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

Решение

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

Для зеркалирования базы данных вы можете использовать события трассировки или установить SQL Server Alert для проверки события WMI (Windows Management Instrumentation) об изменении состояния зеркалирования базы данных. Прежде чем мы начнем, вам предстоит выполнить несколько шагов.

Ссылки

•    DATABASE_MIRRORING_STATE_CHANGE (http://msdn.microsoft.com/en­us/library/ms180711.aspx).

•    Database Mirroring State Change Event Class (http://msdn.microsoft.com/en­us/library/ms191502­(SQL.90)­.aspx).

Полнотекстовый поиск а-ля Google

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

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

Стиль Google

Ключом к успешности приложения является простота использования и мощь. Google добилась этого в своей поисковой системе. Синтаксис запросов прост и интуитивен, но в тоже время полнофункционален. Хотя основные элементы запросов Google очень просты, но вы можете комбинировать их, составляя очень сложные выражения. Я начну с базового синтаксиса запросов Google и добавлю некоторые дополнительные операторы для демонстрации мощи синтаксиса предиката CONTAINS из SQL Server. Полное описание синтаксиса запросов Google можно найти по адресу: http://www.google.com/help/cheatsheet.html.

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

Download

Исходный код, используемый в этой статье, доступен для скачивания. Этот код написан на C# с помощью Visual Studio 2008, и рассчитан на использование с тестовой базой данных SQL Server 2005 AdventureWorks. Irony .NET Compiler Construction Toolkit доступен для скачивания по адресу http://www.codeplex.com/irony.

Благодарности

В завершение статьи я бы хотел поблагодарить Романа Иванцова за создание Irony .NET Compiler Con­struction Toolkit, за помощь в создании грамматики и алгоритма обхода AST­дерева.

Какие SQL-операторы выполняются в данный момент?

sp_who2 — хорошо известный способ получения spid, выполняющихся в данный момент команд. Однако информация, которую он предоставляет, относительно ограничена. Например, показывается только тип выполняемой команды (SELECT, DELETE и т. д.), без каких-либо ссылок на фактически выполняющийся SQL-код. Знание выполняющегося в данный момент SQL-кода может быть жизненной необходимостью во время выяснения причины слишком длительного выполнения запроса или выяснения факта блокировки выполнения запроса. Это также может пригодиться для индикации хода выполнения хранимой процедуры, т. е. выяснения, какой именно оператор в хранимой процедуре выполняется в данный момент. Утилита, описанная в данной статье, лишена ограничений присущих sp_who2. Эта утилита использует динамические административные представления (DMV), поэтому может использоваться с версиями от SQL Server 2005 и выше.

Утилита, показывающая выполняемые в данный момент SQL-операторы

Код утилиты ‘dba_WhatSQLIsExecuting’ показан в листинге 1. Динамическое административное представление (DMV) sys.db_exec_requests показывает выполняемые в данный момент запросы, в том числе и дескриптор всего SQL­кода пакета или хранимой процедуры (sql_handle) вместе со смещениями относительно начала участка SQL­кода выполняемого пакета (statement_start_offset и statement_end_offset).

Для определения выполняемого в данный момент участка SQL­кода, нам нужно вызвать динамическую административную функцию (DMF) sys.dm_exec_sql_text, передав ей дескриптор выполняющегося SQL­пакета, а затем применив относительные смещения.

Мы можем получить больше информации о запросе, комбинируя DMV sys.db_exec_requests с системным представлением sys.processes (соединенных по spid/session_id). Эта информация включает в себя инициатора выполнения запроса, компьютер, с которого он выполняется, и имя базы данных.

Наша утилита выбирает нужные поля из представлений sys.db_exec_requests и sys.sysprocesses.

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