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

 

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

 

Службы Notification Services

Бак Вуди (Buck Woody)

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

Давайте начнем с того, что изучим несколько приложений служб Notification Services и выясним, какими возможностями вы располагаете для их распространения. Наиболее очевидные варианты применения включают приложения, которые требуют предоставления пользователю немедленного отклика. Такие приложения включают изменение стоимости, уровней цен, перечня товаров и любой другой устаревающей информации.

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

Вы можете использовать службы Notification Ser­vi­ces для того, чтобы помочь системным администраторам управлять вашими системами в режиме реагирования на возникновение событий. Как правило, управлять всем подряд в сфере ИТ в режиме реагирования — это неудачная идея, но, используя службы Notification Services, вы можете встроить упреждающую логику так, чтобы за объектами (например, за резервным копированием или за другими операциями в рамках технического обслуживания) вместо вас следил сервер и чтобы он мог уведомить вас о достижении некоторого порога.

Так что же это такое — службы Notification Ser­vi­ces? Это инфраструктура в рамках SQL Server 2005, которая включает службу, экземпляры и приложения, а также набор программ, которые создают ваши разработчики для взаимодействия с системой. В этой статье я сосредоточусь на экземплярах и приложениях служб Notification Services.

Самый легкий способ создать такую систему — запрограммировать ее, используя объекты управления уведомлениями (Notification Management Objects, NMO).

Вы можете также создавать службы Notification Services и управлять ими с помощью встроенных в SQL Server 2005 инструментов, используя XML­файлы. Мы рассмотрим структуру этих файлов и проанализируем результаты их реализации с тем, чтобы вы могли видеть, как ими управлять и как их сопровождать. На практике большинство приложений программируется с помощью NMO­объектов, но вы всегда можете создать XML­файлы объектов и приложения, выполнив команду Export в контекстном меню Object Explorer в среде SQL Server Management Studio.

Архитектура служб Notification Services

В документации Books Online представлено очень много полезнейших сведений о службах Notification Services, но эта информация организована таким образом, что не обеспечивает целостного представления о системе. Для этого имеется серьезная причина. Службы Notification Services используют для выполнения своих задач несколько компонентов платформы SQL Server 2005. Все те возможности, которые предоставляет фирма Microsoft, ваши разработчики могут дополнить пользовательскими программами и интерфейсами. Чтобы получить картину того, как все это увязывается вместе, давайте начнем с тыла системы и доберемся до пользователя, который получает уведомление.

Службы Notification Services имеют много компонентов, поэтому я рассмотрю их трижды. В первом рассмотрении я дам вам общее представление, затем вернусь к началу и добавлю еще подробностей, а потом рассмотрю различные базовые компоненты в ходе объяснения, что собой представляют файл конфигурации экземпляра (Instance Configuration File, ICF) и файл определения приложения (Application Definition File, ADF). Даже располагая всей этой информацией, вы получите только краткий обзор данной темы.

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

В тылу процесса находится SQL Server 2005, который хранит данные, необходимые пользователю, и все метаданные, которые требуются для работы службам Notification Services. «Над» сервером SQL Server находится программа NSServer.exe, которая исполняет все экземпляры, формирующие уведомления для пользователей. У вас есть две возможности для того, чтобы создать эти экземпляры: ваши разработчики могут создать их с помощью программ, использующих NMO­объекты, или вы можете создать их, используя XML­документ, который называется ICF.

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

Эти события сравниваются с подписками, которые посылаются подписчикам (пользователям) по различным протоколам на такие устройства, как сотовые телефоны или электронная почта. Опять­таки, ваши разработчики могут создать приложения служб Notification Services, используя NMO­объекты, или вы можете создавать их с помощью XML­документа, который называется ADF и который детализирует составные части приложения.

Если вы создаете экземпляры и приложения, используя XML­файлы, выполняется импорт этих файлов из среды SQL Server Management Studio или из программы NSControl.exe командной строки.

Это первое представление, которое не раскрывает всех подробностей. Давайте проанализируем процесс немного глубже. После того как экземпляры и приложения созданы и исполняются, экземпляр использует программу, которая называется NSServer.exe и исполняется в фоновом режиме, отслеживая наступление событий с помощью поставщика событий. Поставщики событий следят за изменениями базы данных, файловой системы и другими событиями. Затем они применяют правила сравнения, чтобы объединить подписки и события в пары, а потом посылают эти данные поставщику. Поставщик — это составная часть программного обеспечения, которая получает данные и форматирует их для доставки.

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

Распространитель форматирует выходные данные, используя модуль форматирования содержимого, и затем отсылает их поставщику протокола доставки, который может посылать данные по протоколам SMTP, HTTP и SMS. Подписчик получает конкретные данные в определенном формате по заданному протоколу.

В качестве третьего объяснения процесса давайте более пристально рассмотрим два из основных его компонентов, с которыми вы будете работать: файлы ICF и ADF. Используя эти XML­файлы, вы готовите экземпляры и приложения, которые позволят вашим разработчикам создать полноценную систему служб Notification Services. Все фрагменты, о которых я веду речь, начнут собираться вместе по мере изучения вами этих файлов.

Вопросы и ответы по SQL

64-разрядные установочные пакеты, выделение памяти кластера и другое

Под редакцией Нэнси Мичелл (Nancy Michell)

Эффективность работы электронной документации

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

Ответ:    Возможно, замедление связано с настройками параметров загрузки справки. Электронная документация имеет три варианта ее отображения. Первый — сначала обратиться к справке в Интернете и лишь затем к локальной; второй — сначала использовать локальные данные и лишь затем Интернет; третий — ограничиться только локальной справкой. Выбор между ними делается при первом использовании электронной документации по SQL Server, но его можно изменить.

Откройте электронную документацию, зайдите в меню «Сервис». Выберите пункт «Параметры» и перейдите в раздел «Справка | Справка в сети». Выберите один из двух первых вариантов, чтобы загрузить справку локально.

Пока электронная документация открыта, не помешает проверить ее версию, чтобы убедиться в том, что установленная версия является самой последней и лучшей. Посмотрите строку заголовка в верх­ней части экрана. Если указана более ранняя дата, чем февраль 2007 года, или если дата вообще отсут­ствует, то эта версия устарела и следует загрузить по­следнюю версию с веб­узла, расположенного по адресу microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx. На этом веб­узле электронная документация обновляется несколько раз в год.

32- и 64-разрядные установочные пакеты

Вопрос:    Не могу разобраться, какие типы и версии приложения SQL Server можно устанавливать на серверы x86, x64/EMT64 и IA64. Говорят, что у SQL Server 2005 не такие типы установочных пакетов, как у SQL Server 2000. Так ли это?

Ответ: SQL Server 2000 поставляется в виде установочных пакетов двух типов (и различных выпусков): 32­ и 64­разрядных. Его можно устанавливать на платформы x86 и x64/EMT64, на которых это приложение будет работать как 32­разрядное. 64­разрядная версия SQL Server 2000 работает на платформе IA64.

SQL Server 2005 поставляется в виде установочных пакетов трех типов (и различных выпусков). Его можно устанавливать на платформы x86 или x64/EMT64 в качестве 32­разрядного приложения, на платформу x64/EMT64 в качестве 64­разрядного приложения, если она работает под управлением операционной системы Windows x64/EMT64, и на платформу IA64 в качестве 64­разрядного приложения.

Поиск информации о SQL Server

Вопрос:    Существует ли простой способ поиска информации, касающейся SQL Server? Часто приходится искать во многих разных местах, хотелось бы иметь что­то более удобное.

Ответ:    Веб­узлы корпорации Microsoft определенно содержат массу информации о SQL Server, и есть отличный новый ресурс, подготовленный группой обучения пользователей SQL Server для предоставления помощи в ее поиске. Это специально настроенная поисковая система Windows Live, результаты действия которой ограничиваются электронной документацией по SQL Server (рис. 1). Система находится по адресу search.live.com/macros/sql_server_user_education/booksonline. Не забудьте отправить с этой страницы свои отзывы группе разработчиков.

Выделение памяти кластера

Вопрос:    Как лучше задать максимальный объем памяти для SQL Server в моем активном трехстороннем кластере (четвертый узел простаивает)? Равным одной трети общего объема памяти? Или предоставить SQL Server всю имеющуюся память, чтобы при восстановлении после отказа вышедшие из строя экземпляры сами боролись за нее?

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

Но если SQL Server занимает весь объем ОЗУ сервера и при этом происходит запуск нового экземпляра SQL Server, то что происходит с памятью имеющегося экземпляра SQL Server? Очевидно, стоит планировать в расчете на худший вариант, когда только один узел сохраняет рабочее состояние и всем экземплярам SQL Server приходится работать на нем.

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

В большинстве случаев лучше настраивать каждый экземпляр таким образом, чтобы он использовал большую часть памяти каждого узла. Пусть, например, на каждом узле в наличии есть 32 Гб ОЗУ. Разумным будет установить для каждого экземпляра примерно 28 Гб памяти.

Теперь в случае отказа узла выполняющийся на этом узле экземпляр переключится на пассивный узел и потенциально может получить доступ к 28 Гб памяти. Состояние двух других экземпляров не изменится. Они будут продолжать выполняться на двух других узлах кластера.

Вы говорите о рассчитанном на восстановление при отказе кластере из четырех узлов с пятью экземплярами SQL Server и одним экземпляром служб Analysis Services. Если вы используете SQL Server 2000 в режиме расширенной адресации (AWE), то для экземпляров реляционной базы данных следует настроить какие­то тщательно подобранные предельные значения объема памяти, так как они не будут освобождать память, которую получили. В более гибкой ситуации, когда используются 64­разрядные экземпляры SQL Server 2005, имеющие доступ к большому адресному пространству независимо от наличия расширений AWE, все происходит иначе. Даже если в этой ситуации используется AWE, память может динамически освобождаться по запросу. Таким образом, ответ на вопрос, что происходит с изначальным экземпляром SQL Server и памятью, которую он занял во время восстановления при отказе, сопровождающемся запуском на компьютере нового экземпляра, зависит от того, используется SQL Server 2000 или SQL Server 2005 и используются ли расширения AWE.

Планирование исходя из сценария худшего случая, в принципе, разумно, но на практике очень маловероятно, что вам удастся сохранить работоспособность при выходе из строя трех из четырех узлов кластера, на котором выполняются пять экземпляров СУБД SQL Server и один экземпляр служб Analysis Services — если только это не система с завышенными техническими характеристиками. У оставшегося узла не хватит ресурсов процессора для обслуживания имеющихся экземпляров на сравнимом уровне производительности. Исходя из этого, в общем случае лучше проектировать решение, при котором поддерживается оптимальная производительность при потере одного узла, а при потере большего их количества может потребоваться некоторое вмешательство вручную. Такое решение, скорее всего, обеспечит хорошее сочетание высокой доступности (HA) и достаточно полного использования дорогостоящих ресурсов.

Наконец, при использовании SQL Server 2005 конечный пользователь может фактически масштабировать кластер до восьми узлов. Для SQL Server 2000 максимально возможным был кластер из четырех узлов.

Предельные возможности зеркального отображения

Вопрос:    Читая о зеркальном отображении баз данных SQL Server 2005, я обнаружил ограничение предельного количества зеркально отображаемых баз данных для экземпляра сервера, равное 10 базам. Мне необходимо иметь два отдельных экземпляра SQL Server с раздельными хранилищами данных, автоматическим переключением между этими экземплярами и резервированием данных.

Я планировал использовать одноранговую (P2P) транзакционную репликацию SQL Server 2005 в сочетании с сервером кластеров Microsoft (MSCS), при этом у меня был бы IP­адрес кластера, который присваивался бы одному из двух узлов, чтобы весь трафик вставки, обновления, удаления и чтения записей направлялся на один узел кластера. Я бы использовал дополнительный узел в качестве пассивного, но выполнял бы репликацию транзакций на него. В случае отказа сервер MSCS передавал бы обращения к этому IP­адресу на другой узел, и так как он настроен как одноранговый и двунаправленный, то для начала публикации транзакций на исходный узел (после того как он снова начнет работать) никаких ручных действий не требовалось бы. Для снижения потребности в общем дисковом ресурсе для кворума я бы использовал на сервере MSCS конфигурацию в виде набора узлов большинства. Вариант зеркального отображения все еще рассматривается. Мы сократили число баз данных на кластер SQL Server с 1000 до 100. Следует ли подвергать системы такой нагрузке?

Ответ:    Информацию и указания по зеркальному отображению в SQL Server см. в электронной документации или на веб­узле технического центра SQL Server по адресу microsoft.com/technet/prodtechnol/sql и msdn2.microsoft.com/sql.

Этот вопрос вызвал длительное обсуждение. Можем предложить два варианта.

Ответ номер один сводится к тому, что не существует принудительного ограничения количества баз данных, для которых может выполняться зеркальное отображение в определенном экземпляре. Полагаю, что вы узнали о нем из статьи, в которой отмечается, что лучшие методы работы предполагают зеркальное отображение не более 10 баз данных для одного экземпляра, но это просто приблизительная оценка, а не ограничение — никаких конкретных ограничений нигде не установлено. Все зависит от имеющихся в наличии ресурсов системы. Зеркальное отображение может быть приемлемым вариантом, но 1000 баз данных для него — практически неподъемно, если только не используется действительно очень мощный сервер. Если вы не хотите использовать общее хранилище данных, но хотите применять встроенные в SQL Server технологии, можно попробовать использовать зеркальное отображение, доставку журналов или репликацию. Каждый из вариантов имеет свои положительные и отрицательные стороны.

Ответ номер два таков: при наличии большого количества баз данных без общего хранилища и при желании использовать решение в области аварийного восстановления корпорации Microsoft стоит рассмотреть вариант применения доставки журналов с использованием набора небольших пользовательских вспомогательных программ, снижающих административную нагрузку. Такая программа может выполнять резервное копирование и восстановление баз данных по очереди, а не устранять необходимость в запуске нескольких агентов доставки журналов. Обратите внимание, что в этом случае существует вероятность потери данных. Не существует встроенного решения, которое не требовало бы для полной сохранности данных ни общего хранилища данных, ни СУБД.

Конечно, остается вопрос о том, как сервер MSCS будет обнаруживать отказ и осуществлять восстановление. Настройки MNS в кластере обычно не устраняют полностью потребность в общем хранилище данных, а просто устраняют потребность в выделенном номере логического устройства (LUN) для кворума. Единственный способ реализовать эту схему — настроить кластер на управление только IP­адресами и сетевыми именами. SQL Server не может быть кластеризован без общего хранилища данных, поэтому невозможно кластеризовать SQL­службу, что означает, что кластер не сможет обнаруживать и отслеживать службы SQL Server в типовой конфигурации.

Службу SQL Server можно кластеризовать, добавив ее в качестве обычной службы, которую нужно отслеживать, но тогда возникает проблема с восстановлением при отказе: в случае кластеризации данной службы сервер MSCS будет пытаться при восстановлении при отказе запустить эту службу на пассивном узле, но какая­то SQL­служба уже будет на нем запущена. Конечно, его можно использовать для простой кластеризации IP­адресов и сетевых имен, а затем в случае необходимости осуществлять восстановление при отказе вручную. То же самое можно выполнять с помощью службы NLB (Network Load Balancing — балансировка сетевой нагрузки), что используется в других случаях. Подробнее см. в статье microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx.

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

Командная оболочка Microsoft Windows PowerShell и объектная модель SMO сервера SQL Server 2005. Часть 1

Мафесами Ананта Кумар (Muthusamy Anantha Kumar)

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

Командная оболочка Windows PowerShell требует наличия библиотеки .NET framework 2.0.

Модель SQL Server Management Objects, известная под именем SMO, — это объектная модель, предназначенная для управления SQL Server и настройки его конфигурации. В приложениях, созданных на базе модели SMO, для программирования этой модели, которая размещается в оперативной памяти (in­memory object model), используются языки платформы .NET Framework вместо пересылки на сервер команд языка Transact­SQL (T­SQL).

В этой серии статей я намерен продемонстрировать обширные возможности, которыми обладает оболочка Windows PowerShell, в сочетании с возможностями SQL Server 2005.

В первой части этой серии публикаций планируется показать, как можно инсталлировать оболочку PowerShell и использовать простые команды этой оболочки и модели SMO.

Изоляция моментального снимка: угроза целостности? Часть 1

Хьюго Корнелис (Hugo Kornelis)

Одна из прекрасных новых возможностей SQL Server 2005 — изоляция на уровне моментального снимка (snapshot isolation). Но насколько она безопасна? Можете ли вы по­прежнему гарантировать целостность данных, если используете уровень изоляции моментального снимка?

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

 

 

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

Hosted by uCoz