SQL Server 2005
Часть 4. Сценарии использования
Средства создания отчетов (Reporting Services)
Интеграционные сервисы (Integration Services)
Средства репликации (SQL Server Replication)
В рамках обсуждения вопросов, связанных с переходом на SQL Server 2005 (см. № 10, 11’2005, 1’2006), мы рассмотрели собственно процесс перехода, обозначив его основные этапы, а также шаги, которые следует предпринимать на каждом из этих этапов. Затем мы затронули вопросы, связанные с возможными путями включения функциональности SQL Server в существующие приложения, и предложили подходы, которые можно использовать для миграции приложений на SQL Server 2005. В ходе этого обсуждения мы начали рассматривать сценарии применения новых, расширенных и улучшенных возможностей, появившихся в продукте. В предыдущей части мы привели возможные варианты использования различных сервисов, входящих в состав SQL Server 2005, — нотификационных сервисов, SQL Server Service Broker и web-сервисов. В данной части мы расскажем о сценариях использования других компонентов SQL Server 2005: средств создания отчетов, интеграционных сервисов, SQLXML, средств репликации, а также SQL Server Agent и Database Mail.
Средства создания отчетов (Reporting Services)
ходящие в состав SQL Server 2005 средства создания отчетов (SQL Server Reporting Services) — это серверная платформа, позволяющая создавать отчеты и управлять ими. Создаваемые средствами SQL Server 2005 отчеты могут содержать данные из различных реляционных и многомерных источников данных. Для пользователей предоставляется возможность просмотра и управления отчетами через web-интерфейс.
В состав служб SQL Server Reporting Services входят Report Builder — средство, предназначенное для пользователей и служащее для быстрого создания отчетов на основе шаблонов, и Report Designer — средство, рассчитанное на разработчиков комплексных отчетов.
Наличие возможности создания отчетов — обычное требование к большинству бизнес-приложений. Генерация отчетов может потребовать выполнения длинных запросов, комплексных вычислений и форматирований. Эта дополнительная нагрузка на сервер баз данных может отрицательно сказаться на производительности всей системы. При использовании сервисов, предоставляемых SQL Server Reporting Services, появляется возможность переноса части нагрузки на другой сервер.
Ниже перечислен ряд сценариев, для реализации которых можно использовать функциональность, предоставляемую службами SQL Server Reporting Services:
- не требуется обновление данных — многие web-приложения обеспечивают только отображение информации без возможности ее обновления. В большинстве подобных случаев интерактивных возможностей Reporting Services может оказаться вполне достаточно для того, чтобы обеспечить пользователей необходимой информацией без предоставления им непосредственного доступа к источнику данных;
- данные, на основе которых строятся отчеты, обновляются нечасто — примерами таких отчетов могут быть еженедельные или ежемесячные сводки. Если существует большое число пользователей, которым требуются именно такие отчеты, доступ к необходимой им информации может быть обеспечен средствами Reporting Services;
- отчеты содержат информацию, сгруппированную или отсортированную различными способами, — имеется возможность объединения нескольких отчетов в один с помощью параметров группировки и сортировки. Затем можно применять интерактивные возможности Reporting Services для обеспечения пользователей информацией, которая отсортирована или сгруппирована согласно их потребностям;
- требуется получение информации в определенном формате — администратор базы данных может использовать Reporting Services для генерации отчетов в часы наименьшей загрузки системы, а затем распространить отчеты среди пользователей без непосредственного подключения к источникам данных.
Занимаясь дизайном системы, частью которой будет применение функциональности Reporting Services, следует помнить, что в Reporting Services используется собственная система безопасности, работающая отдельно от системы безопасности SQL Server. Также требуется тщательное планирование для соблюдения баланса между нагрузкой на сервер баз данных и данными, скэшированными Reporting Services. И еще одно замечание: доступ к сохраненным в кэше отчетам или к отчетам, сохраненным в виде снэпшотов (мгновенных снимков), потребует дополнительного места для хранения, причем как самих отчетов, так и их резервных копий.
Масштабируемость Reporting Services может быть увеличена за счет разделения функциональности, связанной с запросами к базам данных и с непосредственным построением отчетов. Например, можно извлекать данные из базы, работающей на одном сервере, а форматировать отчет средствами Reporting Services, выполняющимися на другом сервере. Еще один способ увеличения масштабируемости — использование отдельной базы данных в качестве источника для построения отчетов. В этом случае вы копируете требуемые для отчетов данные в новую базу, оптимизированную для эффективной отработки запросов. Для копирования данных можно применять механизмы репликации (SQL Server Replication) или интеграционные сервисы (SQL Server Integration Services) для переноса данных в новую базу. Помимо этого можно создать хранилище данных (data warehouse), которое будет использоваться в качестве источника данных для генерации отчетов. И наконец, можно применять несколько экземпляров Reporting Services, обращающихся к одной и той же базе данных. Такая конфигурация может использоваться для выполнения сервисов Reporting Services в кластерных средах. Отметим, что Reporting Services не включают поддержку кластеров — для этого могут потребоваться дополнительные программные компоненты, входящие в состав SQL Server 2005.
 |
|
Интеграционные сервисы (Integration Services)
нтеграционные сервисы, входящие в состав SQL Server 2005 (SQL Server Integration Services, SSIS), — это платформа для интеграции и консолидации данных. С ее помощью можно задавать и автоматически выполнять комплексные процессы обработки данных, которые разбиваются на три основных этапа: извлечение, преобразование и загрузка. Индустриальное название таких сервисов — ETL-сервисы (Extract, Transform, Load).
Интеграционные сервисы в SQL Server 2005 представляют собой развитие механизмов DTS (Data Transformation Services), которые были в предыдущих версиях SQL Server. Интеграционные сервисы включают:
- ядро преобразования данных (Data Flow Engine), которое поддерживает разные источники данных, трансформации и различные способы загрузки данных;
- дизайнер, позволяющий задавать последовательности, циклы, события и группировать задания в атомарные операции;
- набор задач по подготовке данных, обеспечивающих доступ к файловой системе, web-сервисам и XML-документам;
- набор задач для бизнес-аналитики, включающий доступ к аналитическим службам и запросам к многомерным хранилищам данных, включая различные алгоритмы обнаружения данных (data mining);
- обширную объектную модель, позволяющую создавать решения на основе интеграционных сервисов.
SQL Server Integration Services обеспечивает функциональность, позволяющую выполнять извлечение, преобразование и загрузку данных в базы данных SQL Server. Необходимо учитывать, что выполнение комплексных преобразований над большими объемами данных может сильно отразиться на загрузке сервера баз данных. При рассмотрении SQL Server Integration Services как возможного кандидата на использование в составе приложения следует обратить внимание на следующие характеристики этого сервиса:
- автоматизация операций загрузки данных — SSIS может применять сервисы SQL Server Agent (см. ниже) для выполнения операций загрузки данных по предопределенному расписанию. Эта функциональность может быть полезной при необходимости периодической загрузки данных;
- объединение данных из гетерогенных источников — возможно, вам потребуется консолидация информации из разных репозитариев. SSIS обеспечивает простой доступ к различным источникам данных, включая Microsoft Office Excel, Microsoft Office Access, базы данных Oracle, XML-файлы, а также источники данных, доступные через ODBC и OLE DB. Построенная на основе провайдеров модель расширения при необходимости позволяет подключать и другие источники данных;
- распределение данных по получателям на основе бизнес-правил — SSIS может использоваться для исследования данных и рассылки их по различным базам данных на основании предопределенного набора бизнес-правил;
- заполнение хранилищ данных и подготовка сводных данных — SSIS поддерживает набор расширенных операций, например заполнение хранилищ данных и выполнение операций бизнес-аналитики. К таким операциям, в частности, относятся операции над редко изменяющимися измерениями (Slowly Changing Dimensions) в OLAP-хранилищах;
- очистка и преобразование данных — SSIS содержит ряд механизмов, которые могут применяться для очистки данных в процессе их загрузки. Расширенная функциональность включает возможность выполнения сравнений со справочными таблицами, а также обнаружение и очистку данных даже при нечетких совпадениях (fuzzy lookup). И наконец, в процессе загрузки данных существует возможность их преобразования на основе задаваемых разработчиками алгоритмов, отражающих требования к составу и формату данных, которые помещаются в хранилища.
|
|
SQL XML
оддержка языка XML, впервые реализованная в SQL Server 2000 (и в минимальном наборе — в SQL Server 7.0), получила свое логическое развитие в SQL Server 2005. Теперь имеется возможность хранения XML-значений в базе данных в полностью поддерживаемом на уровне ядра виде. Новый тип данных XML позволяет, в частности, указать набор XML-схем, которые SQL Server будет использовать для проверки данных, сохраняемых в записях этого типа. В SQL Server 2005 появились расширения механизмов SQL XML, FOR XML и OpenXML. Все это делает SQL Server 2005 мощной платформой для разработки приложений, которым необходимы хранение и обработка XML-данных.
Применение данных в формате XML требует определения целесообразности использования именно этого формата и рассмотрения вопросов, связанных с преобразованием данных из реляционного формата в XML и обратно.
В целом перед принятием однозначного решения о применении данных в формате XML следует провести анализ, который может состоять из следующих шагов:
- Изучить требования к приложению с точки зрения форматов данных. В процессе планирования приложения необходимо определить, как будут использоваться данные и как они будут представляться пользователям. Частью этого процесса должно стать определение необходимого формата данных. Например, если данные поступают от web-сервиса, то вам придется работать с XML-данными; если же приложение поддерживает онлайновые транзакции, то данные будут реляционными. Возможно, вашему приложению потребуется доступ к данным, хранящимся в XML-документах, или генерация XML-документов из данных, находящихся в базе. Одним словом, на первом шаге вы должны точно определить требования к форматам представления данных, которые будут поступать в приложение, находиться внутри него и выдаваться как результат работы приложения.
- Определить наиболее эффективные способы хранения данных. После того как вы узнали типы данных, поддерживаемых приложением, вы должны определить способы их хранения. Например, если вы извлекаете данные из XML-документов, то можете хранить их в XML-виде или преобразовать в реляционный формат. Реляционные данные также можно преобразовать в XML-представление. Окончательное решение зависит от конкретных требований к приложению.
- Определить способы доступа и модификации данных. На этом шаге вы должны учесть способы доступа и модификации данных, которые могут отличаться в тех случаях, когда к данным обращается более одного приложения. Эти способы помогут вам понять, требуется ли преобразование данных (из реляционного представления в XML или в обратную сторону) и когда необходимо выполнять такое преобразование.
- Определить, требуется ли преобразование данных на клиентской или серверной стороне. Если предыдущие шаги привели к пониманию необходимости преобразования данных в процессе работы приложения, следует определить, где это преобразование должно выполняться — на клиентской или на серверной стороне приложения. Правильный ответ на этот вопрос поможет вам, в частности, решить ряд вопросов, связанных с производительностью приложения, использованием транспортных механизмов для передачи данных, формулированием требований к характеристикам системы. Например, при преобразовании реляционных данных в XML на стороне сервера объем пересылаемых данных будет меньше, чем при пересылке XML-данных с их преобразованием на клиенте. Однако если требуется разгрузка сервера, то данные должны преобразовываться на клиенте. Если, например, необходимо обращение к SQ Server Web Service, данные также должны преобразовываться на клиенте.
Как видите, применение XML-данных требует тщательного анализа на основе множества факторов, а в результате может оказаться, что, несмотря на всю свою привлекательность, XML-данные не подходят для конкретного приложения.
|
|
Средства репликации (SQL Server Replication)
QL Server Replication — это набор технологий, позволяющих распространять и копировать данные и объекты баз данных между географически распределенными базами. В SQL Server 2005 появился набор расширений механизмов репликации. Например, реализована возможность транзакционной репликации «точка-точка» (peer-to-peer transactional replication), с помощью которой различные серверы могут передавать друг другу изменения по мере выполнения транзакций над реплицируемыми данными; также можно выполнять объединение репликаций через Интернет и по HTTP-соединениям. Помимо этого имеется возможность интегрироваться с базами данных других производителей.
При рассмотрении возможных сценариев применения репликационных механизмов SQL Server 2005 рекомендуем обращать внимание на следующие характеристики:
- репликация данных через Интернет — можно использовать объединение репликаций по HTTP-соединениям (HTTP merge replication) для синхронизации серверов, подключенных через web, применяя протокол HTTPS (Hypertext Transfer Protocol Secure) и сервер IIS. Объединение репликаций по HTTP-соединениям поддерживается и для подписчиков, использующих SQL Server Mobile Edition. Имеется возможность реализации транзакционной репликации через Интернет с применением серверов SQL Server, подключенных через соединения VPN (Virtual Private Network);
- ограничение операций, выполняемых подписчиками, — разработчикам и администраторам предоставляется полный контроль над операциями над реплицированными данными, доступными подписчикам. Можно сконфигурировать доступ подписчиков к таким данным в режиме «только чтение» или «чтение/запись»;
- поддержка различных моделей соединения — подписчики не должны быть постоянно соединены с публикатором репликаций и дистрибьютором репликаций, они могут работать автономно, а соединение требуется только для выполнения синхронизации данных. Тем не менее в этом сценарии данные, находящиеся у подписчика, могут быстро устаревать — обновления, выполняемые другими пользователями и подписчиками, могут приводить к конфликтам. Постоянно соединенные системы могут распространять изменения с минимальной задержкой, обеспечивать быструю синхронизацию и соответствие данных между публикатором данных и подписчиками;
- выполнение DDL-операций — в SQL Server 2005 возможна простая репликация изменений в схеме данных. Благодаря этому больше не требуется использовать специальные хранимые процедуры для добавления или удаления колонок. Выполнение DDL-команд у публикатора приводит к автоматическому распространению в рамках процесса синхронизации вызванных этими командами изменений всем подписчикам;
- поддержка гетерогенных репликаций — механизмы репликации в SQL Server 2000 поддерживали базы данных Oracle и IBM DB2. В SQL Server 2005 появилась поддержка Oracle 8.0.4 и более поздних версий в качестве публикатора изменений, что делает более простой интеграцию данных, хранимых в СУБД Oracle, в решения, построенные на основе SQL Server 2005;
- улучшенная производительность и масштабируемость — в SQL Server 2005 появилась поддержка параллельной обработки для агентов распространения и объединения (merge and distribution agents), а также возможность использования заранее посчитанных разделов для отфильтрованных публикаций с объединением.
Таким образом, возможности, реализованные в SQL Server Replication, могут применяться для расширения функциональности приложений, особенно в тех случах, когда требуется синхронизация данных в географически распределенных системах. Наиболее характерным примером таких систем являются системы автоматизации бизнеса, рассчитанные на использование как в головных офисах, так и в региональных представительствах.
К последней группе сервисов, которые мы рассмотрим, относятся сервисы, предназначенные в первую очередь для администрирования баз данных. Но и их функциональность может применяться при разработке приложений — важно правильно идентифицировать требования и подобрать наиболее подходящие для их реализации механизмы, входящие в состав SQL Server 2005.
|
|
SQL Server Agent
QL Server Agent — это специальный сервис Microsoft Windows (с именем SQLSERVERAGENT для экземпляров SQL Server с именем по умолчанию и SQLAgent$имя_экземпляра для именованных экземпляров SQL Server), который выполняет задачи по расписанию. Одна из возможностей SQL Server Agent — это мониторинг SQL Server Database Engine и генерация событий и оповещений при изменении каких-либо заданных характеристик. По умолчанию функциональность SQL Server Agent отключена, для его активизации следует воспользоваться утилитой SQL Server Surface Area Configuration. К способам использования SQL Server Agent можно отнести:
- выполнение по расписанию операций по поддержанию функционирования базы данных — создание резервных копий, перестройка индексов и т.п.;
- реагирование на определенные уведомления — SQL Server Agent обладает возможностью распознавания и ответа на уведомления: он посылает сообщение оператору и выполняет ту или иную задачу. В зависимости от типа уведомления можно задавать различные задачи и, таким образом, автоматически исправлять сложные ситуации, которые могут возникнуть в процессе эксплуатации SQL Server. Например, можно определить, что транзакционный протокол для определенной базы данных близок к заполнению, и запустить процедуру создания резервной копии протокола еще до того, как база данных перестанет функционировать;
- в SQL Server 2005 имеется возможность заставить SQL Server Agent реагировать на события Windows Management Instrumentation (WMI) и изменения значений различных счетчков производительности SQL Server. Эта функциональность может быть полезной, например, для сбора статистики в процессе стабилизации приложения, построенного на основе SQL Server, для интеграции корпоративных приложений в процесс унифицированного управления на основе Microsoft Operations Manager (MOM) и в ряде других случаев;
- функциональность, предоставляемую SQL Server Agent, можно использовать и для выполнения по расписанию различных задач, непосредственно связанных с основной функциональностью бизнес-приложений, построенных на основе SQL Server 2005, например для создания консолидированной отчетности в конце квартала. Этот процесс может привести к выполнению ряда операций над базой данных и транзакций, причем некоторые из них могут потребовать значительного времени для выполнения и дополнительных ресурсов. Используя SQL Server Agent, можно составить расписание выполнения операций таким образом, что они будут осуществляться в часы наименьшей загруженности сервера и благодаря этому минимально отразятся на выполнении повседневных операций.
|
|
Database Mail
atabase Mail — это реализованный в ядре SQL Server 2005 механизм для отсылки электронной почты (хранимая процедура sp_send_dbmail). По сравнению с SQL Mai, знакомым многим разработчикам и администраторам компонентом, Database Mail — менее ресурсоемкая, «легкая» альтернатива, не требующая установки MAPI-клиента (например, Microsoft Office Outlook Express) на сервере, где установлен SQL Server 2005, — Database Mail использует SMTP-протокол. Задача Database Mail — не предоставить всю инфраструктуру, связанную с приемом и отсылкой электронной почты, а дать разработчикам и администраторам простой и надежный механизм только для отсылки почты.
Преимущества использования Database Mail
При рассмотрении возможных способов применения Database Mail в приложениях следует обратить внимание на то, что допустимо использование Database Mail для отсылки электронной почты из кода на T-SQL, включая хранимые процедуры и триггеры. Как уже отмечалось, Database Mail нельзя применять для получения и обработки электронной почты — для этого нужно использовать компонент SQL Mail, но следует иметь в виду, что в будущих версиях SQL Server этот компонент поддерживаться не будет. Поскольку Database Mail задействует SMTP-протокол для общения с почтовыми серверами, она может применяться даже на компьютерах, где не установлены почтовые клиенты (в отличие от SQL Mail, требующей наличие MAPI-совместимых клиентских приложений и более сложной настройки и конфигурации). Благодаря тому, что Database Mail выполняется в отдельном процессе, изолированном от SQL Server Database Engine, нарушения в функционировании Database Mail никак не влияют на работу ядра базы данных. Механизм Database Mail управляется Service Broker, и это, в частности, снимает нагрузку с ядра базы данных, делая процесс отсылки почты асинхронным, то есть приложения продолжают работать даже при остановке Database Mail — почта скапливается в очереди и отсылается при возобновлении работоспособности Database Mail.
|
|
Заключение
а этом мы завершаем рассмотрение сценариев использования SQL Server 2005. В следующем номере мы применим полученные знания к практическому примеру — обсудим способы выбора компонентов SQL Server 2005 для решения задач, связанных с переносом приложений на новую версию системы управления базами данных.
