Главная SQL, Новое SQL Server 2008 R2. The SQL Server Utility.Практика применения
  • SQL Server 2008 R2. The SQL Server Utility.Практика применения

    1226059553_pic_id159312 В настоящее время даже весьма не крупные предприятия и организации имеют по несколько SQL серверов (более формально – экземпляров серверов, instance), хранящих и обслуживающих бизнес-данные такого предприятия. Большие предприятия могут иметь десятки MS SQL серверов/экземпляров, очень крупные – сотни. Как показывает практика, такое разрастание количества экземпляров ставит перед IT-отделами организаций один не сложный (как кажется не посвященному взгляду) вопрос: как управляться со всем этим хозяйством? Взгляд просвещённый же мгновенно поймет всю не тривиальность задаваемого вопроса. Экземпляры могут быть одной редакций и разных. Располагаться и работать они могут на компьютерах современных и морально устаревших. Обслуживать они могут 2 базы по 5 таблиц в каждой, а могут 50 баз по 100 таблиц. С большой степенью вероятности хотя бы часть (а иногда все) экземпляров будут иметь свои настройки и требовать в отношении себя соблюдения своих собственных «правил поведения» (научно называемых политиками). И, не забудем, все эти сервера могут еще дополнительно быть географически разнесены, а вовсе не находиться в одной серверной комнате. Так как не запутаться в этом море настроек, правил, редакций?

    Вопрос, по видимому, встал настолько остро, что в предыдущем выпуске SQL Server 2008 (тот что без R2) сразу 2 новшества были посвящены именно ему: Policy-Based Management (PBM) и the Data Collector (DC). PBM позволял централизовано (крайне важно!) создавать политики направленные на экземпляры, базы, таблицы, да и вообще на любые типы объектов мира SQL. Далее созданную политику можно было заставить соблюдать на любом целевом экземпляре. Таким образом администратор БД находясь за «центральным компьютером» издавал «правила поведения» для любого инстанса находящегося в сфере его влияния. Вторая новинка тех дней – DC, помогал интегрировать сбор, анализ, хранение, а так же поиск «узких мест» различной диагностической информации собираемой, опять-таки, с любого инстанса и выгружаемой на «центральный компьютер». Совместными усилиями PBM и DC внесли весомый вклад в обсуждаемый острый вопрос управления множеством серверов, но, конечно, не закрыли его окончательно. Например, не раскрытой осталась такая тема: в фирме есть 4 экземпляра MS SQL Server (не важно хостит их 1 супер-компьютер или 4 «умеренно навороченных» сервера или какая-то комбинация предыдущего, типа 2*2). Каждый экземпляр обслуживает ровно по 3 БД, а всего нам нужно поддерживать 12 баз: DB_01, DB_02, DB_03, DB_04, DB_05...DB_12. Как и откуда мы можем узнать, что 2-й экземпляр буквально «задыхается» от непомерной нагрузки ложащейся на базы 04, 05, 06, в то время как 4-й экземпляр обслуживает базы 10-12 «левым мизинцем» 98% времени пребывая «в спячке» от нечего делать? Кто нам подскажет что базы 04, 06, а заодно и 02 с первого экземпляра стратегически выгодно и грамотно переместить на 4-й экземпляр тем самым балансируя нагрузку? Не было у нас такого советчика, ни или по крайней мере не было до появления последней версии SQL Server-а – R2.

    Строго говоря, с привлечением DC из SQL Server 2008 создать такое решение было можно. Но это были бы custom-solutions, причем каждый БД-администратор изобретал один и тот же, по сути, велосипед снова, и снова, и снова… SQL Server Utility попросту предлагает такой «велосипед» «из коробки», освобождая нас от далеко не банальной задачи написания custom collection set, а так же от написания отчетов выводящих собранные ими данные в удобоваримом виде. В данной утилите все уже расчерчено, заполнено и, самое главное – тщательно протестировано. Остается лишь чуть «подточить» под наши конкретные условия. Но, еще раз повторю, технически все предлагаемое SQL Server Utility реализуется и просто через DC, вопрос лишь в трудоемкости последнего подхода. Как думается автору в 99% реальных ситуаций, мониторинга представленного обсуждаемой далее утилитой хватит, что называется, «за глаза». В 1% уж очень изощренных случаев – да, придется потрудиться создавая некий «мониторинг-индивид» на базе классического DC.

    Как уже понятно, герой нашего повествования — SQL Server Utility – есть «фирменное» решение вопроса мониторинга ресурсов потребляемых серверами предприятия, а так же отслеживания трендов такого потребления. В рамках данной статьи мы выполним несколько практических работ которые покажут нам все аспекты этой новинки. Но прежде чем переходить к «живой» работе ознакомимся с терминологией новой утилитой и с более-менее формализованным описанием ее возможностей.

    Итак, SQL Server Utility является нововведением в SQL Server 2008 R2 и в своей работе она оперирует следующими понятиями и сущностями:

    • Утилита сервера (SQL Server Utility) – непосредственно само решение построенное на платформе DC. Позволяет утверждать и отслеживать соблюдение т.н. политик утилизации ресурсов (resource utilization policies). Технически представляет собой набор работ SQL Agent-а, пакетов SSIS и особых наборов элементов сбора (collection set).
    • Сервисная точка управления (Utility Control Point, UCP). Это, собственно, «центральный» или, если хотите, «управляющий» компьютер. Генеральная идея здесь такая: один из экземпляров серверов предприятия назначается как «управляющий». Его задача (иногда эксклюзивная, иногда совмещенная с обычной обработкой запросов к БД) – собирать и хранить информацию о производительности и потреблении ресурсов. Информация эта стекается к «управляющему» инстансу со всех «управляемых» инстансов, и именно первый ее сохраняет. Мы, разумеется, увидим как экземпляры становятся «управляющими» и «управляемыми», а пока констатируем, что UCP – это и есть тот самый «центральный»/«управляющий» компьютер.
    • Хранилище данных утилиты (Utility Management Data Warehouse, UMDW). Обычная реляционная БД, но предопределенной структуры. Предназначена для хранения всей информации что SQL Server Utility собирает во время мониторинга. Создается автоматически при «подъеме» на компьютере UCP и, понятно, всегда размещается именно на последнем.
    • Проводник утилиты (Utility Explorer). Новое окно в составе SQL Server Management Studio (SSMS). Ближайшим аналогом можно считать хорошо всем знакомое окно Object Explorer. Однако в последнем корневым узлом выступает тот или иной экземпляр сервера. В Utility Explorer корневой узел – та или иная UCP. Именно с помощью этого окна мы создаем UCP, подключаемся к существующему UCP, регистрируем управляемые экземпляры и открываем отчеты о потреблении ресурсов. В общем это наш пользовательский интерфейс для взаимодействия с UCP.
    • Инструментальные панели и представления проводника (Utility Explorer dashboard and list views). Те самые отчеты открываемые из предыдущего окна. Выдают накопленную информацию в виде и формате удобном для ее анализа.

    Итого, высокоуровневый алгоритм работы с новой утилитой сводится к таким шагам:

    1. Выбрать один из серверов в качестве управляющего и назначить его на эту роль путем создания на нем новой UCP.
    2. Внести в список управляемых экземпляров новой UCP все «подчиненные» инстансы за «здоровьем» которых мы хотим наблюдать
    3. Периодически подключаться к новой UCP и просматривать, и анализировать собранные данные о потреблении ресурсов.

    Разумеется по каждому из этих шагов есть не мало «но» и «при условии» (и мы эти условия будем обсуждать), однако в целом все действительно вот так не сложно.

    Теперь, поскольку мы знаем что собираемся изучить решение мониторинга, резонно задать себе такие вопросы:

    • за чем (в смысле за какими сущностями) это решение будет в состоянии наблюдать?
    • какие аспекты этих сущностей будут мониториться и, следовательно, информация о каких аспектах будет сохранена в Utility Management Data Warehouse?

    Ответ на первый вопрос достаточно лаконичен. Наблюдение с помощью новой утилиты возможно за:

    • самое главное и вполне ожидаемо – экземпляры SQL Server-а
    • новой сущностью появившейся только в SQL Server 2008 R2 — Data-tier applications
    • местом в файлах данных и транзакционного лога той или иной БД
    • местом на жестких дисках (volumes)

    В своем дальнейшем повествовании я исхожу из предположения знакомства читателя с Data-tier applications. Если это предположении не верно рекомендую прерваться и сначала изучить этот новый тип приложений с помощью другой моей статьи «SQL Server 2008 R2. Data-tier Application. Разработка, внедрение, модернизация» или цикла статей в MSDN «Understanding Data-tier Applications». Полное понимание материалов статьи данной без знания Data-tier applications будет затруднено, а осмысленное выполнение части практических работ и вовсе не возможно.

    Ответ на второй вопрос тоже не займет много места: контролировать и утверждать политики потребления можно:

    • в отношении потребления ресурсов CPU
    • в отношении потребления свободного места на жестком диске и в файлах БД

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

    Далее, необходимо учитывать, что UCP мониторит и собирает данные о производительности/потреблении ресурсов только с Database Engine. Компоненты типа Analysis Services и Reporting Services ею не поддерживаются. Так же НЕ отслеживаются данные хранилища типа FILESTREAM.

    Помимо этого, необходимо четко себе представлять, что на предприятии может быть много утилит SQL Server Utility (как следствие – множество UCP) и каждый будет следить за своей группой инстансов/data-tier applications. Однако каждый SQL Server Utility будет иметь ровно одну UCP проводящую сбор информации в интересах именно этого SQL Server Utility. Соответственно, включение в работу SQL Server Utility производится путем создания его UCP. Каждый инстанс/data-tier приложение который(-ое) мы желаем мониторить может быть «приписано» ровно одному SQL Server Utility, а значит будет наблюдаться через UCP последнего. В нашей практике все будет максимально просто (один экземпляр будет представлять UCP, а два других будут этой UCP управляться), но нужно понимать что реальные архитектурные возможности разбираемой утилиты несколько шире и мы не обязаны все 20 инстансов наблюдение за которыми нам необходимо заводить на ровно один UCP. Как говорится – возможны варианты.

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

    Все используемое программное обеспечение является финальными версиями (release) с английским интерфейсом пользователя. MS SQL Server был проинсталлирован на машину в трех экземплярах (instance): экземпляр по умолчанию и два именованных – MSSQLSERVER2 и MSSQLSERVER3. Никаких особых баз данных на экземпляре по умолчанию не требуется, но на нем не должно быть зарегистрировано никаких Data-tier applications. Иными словами узел Management->Data-tier Applications этого инстанса НЕ должен содержать никаких под-узлов. Экземпляры же именованные (MSSQLSERVER2 и MSSQLSERVER3) должны содержать по паре идентичных учебных баз – Northwind и Pubs. На них так же НЕ должно быть до начала наших экспериментов никаких зарегистрированных Data-tier applications. Скрипт инсталлирующий обе указанных базы данных можно загрузить здесь: http://www.microsoft.com/downloads/details.aspx?familyid=06616212-0356-46a0-8da2-eebc53a68034&displaylang=en.

    Читателю желающему повторить все практические упражнения описанные далее рекомендуется создать такое же или максимально близкое окружение на своем тестовом оборудовании (физическом или виртуальном).

    Сценарий же который мы попробуем реализовать можно не формально описать так. У нас на предприятии есть 3 сервера (в нашем тестовом окружении – экземпляра сервера). Мы принимаем решение что один из них (экземпляр по умолчанию) будет управляющим, а два других управляемыми. Иными словами мы хотим видеть как и сколько ресурсов потребляют MSSQLSERVER2 и MSSQLSERVER3. При этом на MSSQLSERVER2 зарегистрировано (пока это не так, но мы сделаем этот шаг чуть позже) 2 приложения слоя данных, а на MSSQLSERVER3 – одно. Мы так же желаем быть в курсе потребления ресурсов и всеми тремя этими приложениями.

    Ну что же, первый шаг согласно приведенному выше алгоритму – «подъем» новой UCP. К нему и приступаем.

    Создание новой сервисной точки управления (UCP).

    Создание UCP возможно 2 путями: через мастера 'Create Utility Control Point Wizard' в SSMS или через Windows PowerShell скрипт. Второй путь вряд ли обретет большую популярность в виду разовости такого действия как создание новой UCP и мы его рассматривать не будем сосредоточившись на первом варианте. Однако в любом случае прежде чем воспользоваться любым из двух путей убедитесь что целевой экземпляр сервера готов к «подъему» на нем UCP. А он готов к этому процессу если у него, помимо самоочевидных требований вроде «версия SQL Server не ниже 2008 R2», есть:

    1. протокол подключения TCP/IP для целевого экземпляра д.б. разрешен (иначе в конце мастера получаем warning)
    2. SQL Agent д.б. настроен на автозапуск И запущен до старта мастера (иначе в конце мастера получаем warning)
    3. редакция целевого сервера одна из: Datacenter, Enterprise, Developer, Enterprise Evaluation (иначе в конце мастера получаем error)
    4. целевой сервер хостится OS Windows Server 2003/08/08 R2

    Замечу, кстати, что в контексте разбираемого мастера принципиальной разницы между предупреждениями и ошибками нет никакой, появление хотя бы одного из них приводит к невозможности завершения мастера. Так что единственный путь для нас — выполнить абсолютно все требования выдвигаемые к целевому экземпляру. В данный момент это означает что мы должны запустить Configuration Manager и в нем убедиться что для экземпляра по умолчанию (ведь именно он является целевым сервером для «подъема» UCP):

    • сетевой протокол TCP/IP разрешён
    • служба SQL Server Agent этого экземпляра включена и поставлена в режим автозапуска

    По желанию можно назначить все той же службе SQL Server Agent доменную учетную запись однако я собираюсь воспользоваться «обходным маневром» и оставлю этой службе ту учетку которая была ей назначена в процессе инсталляции сервера, в моем случае – встроенная учетная запись LocalSystem. После проверки приведенных выше условий запускаем SSMS (причем подключаться к какому либо серверу для нашей текущей задачи необходимости нет) и немедленно открываем упомянутое ранее новое окно Utility Explorer, выбирая для этого в главном меню View одноименный подпункт, рис. 01.


    Рис. 01

    Вместе с новым окном открываются и две вкладки имеющие к нему отношение: Getting Started и Utility Explorer Content. Последняя потребуется нам только после того как мы создадим хотя бы одну UCP, пока же она полностью бесполезна. Первая же интересна тем, что содержит ссылки на обучающее видео наглядно демонстрирующее различные фазы работы с новой утилитой – создание UCP, создание списка «подчиненных» серверов и т.д. Однако реальный функционал этой закладки (т.е. непосредственное создание UCP, непосредственное создание списка и т.д.) полностью дублируется самим окном Utility Explorer, и совсем не зря на этой вкладке есть чек-бокс 'Do not show this page again' коим я и предлагаю незамедлительно воспользоваться. Все наши дальнейшие активности будут брать свое начало из окна Utility Explorer и/или с вкладки Utility Explorer Content.

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


    Рис. 02

    Слева-направо:

    • подключиться к существующей UCP
    • отключиться от той UCP к которой в настоящий момент подключен Utility Explorer
    • создать новую UCP

    Нам, как все безусловно догадались, прямо сейчас требуются услуги последней кнопки, ее и щелкаем. Запускается мастер 'Create Utility Control Point Wizard' и первая страница в нем (что традиционно для мастеров в составе SSMS) чисто ознакомительная — просто Next >. На странице 'Specify The Instance Of SQL Server' с помощью кнопки Connect следует указать целевой экземпляр (в нашей практике это экземпляр по умолчанию), а в поле 'Utility Control Point Name' нужно указать (или принять вариант по умолчанию — Utility) имя создаваемой точки управления (UCP). Именно это имя мы будем в дальнейшем видеть в качестве корневого узла дерева окна Utility Explorer при подключении к создаваемой в настоящий момент точке. Давайте назовем нашу точку MyUtility. Так же, как нам уже известно из приведенных выше ограничений UCP может быть создана, фактически, лишь на двух редакциях сервера — Datacenter или Enterprise (Developer и Enterprise Evaluation редакции на которых UCP тоже может быть создана являются лишь под вариантами последней). Однако есть разница в количестве экземпляров серверов за которыми возможно наблюдение с этой самой UCP в том и другом случае:

    • если UCP создана на сервере редакции Datacenter то возможно наблюдение вплоть до 200 управляемых экземпляров
    • если UCP создана на сервере редакции Enterprise то указанная цифра будет скромнее ровно в 8 раз, т.е. вплоть до 25 управляемых экземпляров

    Разбираемая страница еще раз напомнит нам об одном из этих ограничений (25, т.к. у автора в качестве «испытательного стенда» работает Enterprise редакция сервера). Внешний вид текущей страницы мастера непосредственно перед щелчком по Next > представлен на рис. 03.


    Рис. 03

    Щелкаем кнопку продвижения по страницам и переходим на 'Utility Collection Set Account'. Существование этой страницы вызвано вот каким моментом: создание UCP это, помимо прочего, еще создание специального набора элементов сбора (collection set), а именно набора по имени 'SQL Server Utility collection set'. Как, надеюсь, понимают все читатели данной статьи набор элементов сбора логически эквивалентен набору пакетов службы SSIS (SQL Server Integration Services). Именно последние обеспечивают реальные механизмы для сбора данных и передачи их в хранилище (БД по имени sysutility_mdw, она же Utility Management Data Warehouse). Эти пакеты будут созданы мастером над страницами которого мы сейчас работаем, а запускаться на выполнение будут всем известным SQL Server Agent-ом. При этом служба Server Agent может выполнять эту процедуру под собственной учетной записью (той, что назначена ей в момент инсталляции экземпляра или позже, к примеру, через утилиту SQL Server Configuration Manager). А может на время выполнения той же задачи переключаться на какую-то персональную доменную (и обязательно доменную!) учетную запись (т.н. Server Agent proxy account) умышленно созданную администратором именно для этих целей. Страница 'Utility Collection Set Account' позволяет выбрать между этими двумя подходами. В последнем случае мы обязаны в соответствующих полях этой страницы ввести имя/пароль той самой специальной доменной учетной записи. А в первом случае, понятно, ничего вводить не надо, достаточно передвинуть радиокнопку на опцию 'Use the SQL Server Agent service account'. Однако как раз в первом случае в действие вступает ограничение приведенное в начале данного раздела — та учетная запись что назначена в текущий момент Agent-у должна быть именно что доменной. Локальные встроенные (built-in) учетки типа LocalSystem/NetworkService/LocalService не «прокатят». Как уже упоминалось я не хочу менять текущую учетку сервиса (LocalSystem) и поэтому заведу отдельного пользователя. Start->Administrative Tools->Computer Management, выбираем узел Local Users and Groups и его под-узел Users и через контекстное меню последнего заводим, самым обычным порядком, пользователя с произвольным именем, допустим UCPuser. Пароль и прочие атрибуты выбираем по вкусу. Новый пользователь помещается в группу Users где ему самое место – административные права ему ни к чему. Закрываем окно Computer Management и возвращаемся к нашему мастеру где, напомню, мы все еще находимся на странице 'Utility Collection Set Account'. В соответствующие поля этой странице вводим имя учетной записи в формате WIN2008\UCPuser и пароль этой записи, Next > и приходим на страницу 'SQL Server Instance Validation'. Здесь мастер проверит — соблюдены ли все и каждое условие предъявляемые для экземпляра сервера на котором создается UCP. Наша задача — добиться 100% «зеленых галочек» в левой колонке таблицы на этой странице. Появление там хотя бы одного желтого треугольника (warning) или уж тем более красного крестика (error) ведет к блокировке кнопки Next > и невозможности продолжения работы. По счастью правая колонка 'Result' всегда будет содержать ссылки по щелчку на которые будут открываться информационные окошки с довольно толковыми пояснениями не только по теме «что не так?», но и сразу по теме «и что же делать?». В общем добиться состояния этой страницы как на рис. 04 необходимо и сделать это достаточно не сложно.


    Рис. 04

    Щелчок по Next > переносит нас на довольно формальную страницу Summary с итогами всего что было введено на предыдущих шагах, а очередной Next > выводит нас на страницу финальную, 'Utility Control Point Creation'. Именно на ней запускается процесс физического создания сервисной точки управления разбитый на несколько этапов. Прохождение и успешное завершение каждого из этапов можно наблюдать в таблице этой страницы в реальном времени. Наконец после завершения всех этапов можно щелкнуть Finish завершая тем самым работу мастера.

    Посмотрим что изменилось на нашем сервере в результате успешной работы мастера 'Create Utility Control Point'. Ну, во-первых, появилась ожидаемая новая БД по имени sysutility_mdw, рис. 05. Это та самая Utility Management Data Warehouse.


    Рис. 05

    В этой базе будут храниться все собранные данные со всех управляемых инстансов и о ее администрировании мы еще поговорим. Кстати, факт ее появления вкупе с сообщениями только что завершившегося мастера служит практически 100% гарантией что создание UCP закончилось успешно. Если вы не находите указанной БД в под-узлах корневого узла Databases то это явный индикатор проблем.

    Во-вторых, сам инстанс на котором мы только что «подняли» UCP назначается первым управляемым инстансом (managed instance). Проверить это можно так: переключиться в окно Utility Explorer (оно будут подключено к только что созданной нами UCP с именем MyUtility), щелкнуть по узлу Managed Instance и в закладке Utility Explorer Content увидеть требуемое, рис. 06. Т.е. наблюдение за нашим экземпляром по умолчанию уже началось.


    Рис. 06

    В факте наблюдения «за собой самим» нет ничего плохого, иногда это именно то что и требуется. Однако более «чистая» работа – организовать UCP на выделенном под эти нужды экземпляре. Мы реализуем именно такой сценарий и экземпляр по умолчанию в списке управляемых серверов нам не нужен. Правый клик по нему и 'Remove Managed Instance...'. Появляется окно удаления управляемого инстанса в котором через кнопку 'Connect...' требуется указать какое-либо имя входа имеющее администраторские привилегии. После такого указания остается кликнуть OK и неугодный экземпляр убран из списка, мониторинг за ним остановлен.

    Наконец, в-третьих, обратим внимание что в узле Management->Data Collection->System Data Collection Sets того же инстанса у нас есть новый (относительно предыдущей версии SQL Server-а) системный набор элементов сбора по имени Utility Information, рис. 07. Описание этого набора (его можно посмотреть в свойствах набора) не оставляет сомнений в его предназначении: «Collects data about instances of SQL Server that are managed in the SQL Server Utility». Как я уже упоминал вся описываемая утилита построена на платформе DC в чем мы лишний раз и убедились.


    Рис. 07

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

    Администрирование SQL Server Utility

    На текущий момент у нас есть «простаивающая» UCP не ведущая мониторинг ни за одним объектом. Utility Explorer в данный момент подключен к этой новой UCP и мы способны проводить лишь одну активность – администрировать нашу утилиту. Сейчас мы этим и займемся, однако сперва научимся подключаться к нашей сервисной точке, ведь если мы закроем студию (или, что эквивалентно для данного предложения, нажмем среднюю кнопку на панели Utility Explorer, см. рис. 02) Utility Explorer от UCP отключится, а сама эта точка, очевидно, останется. Как нам подключиться к ней в следующей сессии работы? Очень просто. Открыть все тоже окно Utility Explorer (View-> Utility Explorer если это окно скрыто) и нажать первую кнопку той же панели. Будет выдан стандартный запрос подключения, такой же как для окна Object Explorer. Следует просто указать тот экземпляр на котором была создана нужная нам UCP и щелкнуть 'Connect'.

    Сделайте небольшую паузу и подумайте – почему для подключения к UCP достаточно обозначить лишь целевой сервер где эта точка была в свое время создана? Почему нас не спрашивают хотим ли мы подключиться к UCP с именем MyUtility или к какой-то другой расположенной на том же самом сервере?

    Замечу, что попытка подключения к серверу на котором НЕ была создана UCP не приводит, конечно же, ни к каким деструктивным последствиям. Нам просто вежливо сообщат, что мол «Cannot connect to <instance_name> because the target instance is not a utility control point». Иными словами нам говорится о том, что целевой сервер не является сервисной точкой управления. Можно повторить попытку с более правильным инстансом.

    Поскольку мы, я надеюсь, указали правильный экземпляр, мы оказываемся вновь подключены к все той же UCP MyUtility и готовы приступить к ее администрированию, для чего в дереве объектов окна Utility Explorer следует выбрать последний узел – Utility Administration. Тогда во вкладке Utility Explorer Content появятся 3 странички с ярлыками – Policy, Security, Data Warehouse. Рассмотрим их последовательно.

    На первой странице (политика) мы определяем те самые политики утилизации ресурсов. Идея определения такой политики базируется на трех состояниях того или иного ресурса:

    Все эти «нормально», «недо-», «пере-» интуитивно понятны но что они означают более формально и когда статус ресурса меняется с одного на другой? На самом деле эти границы переходов не являются фиксированными, а устанавливаются нами, а набор этих границ и называется обобщено политикой утилизации ресурсов. Однако необходимо еще иметь в виду, что на обсуждаемой странице мы устанавливаем т.н. глобальную политику (здесь и далее слово «политика» эквивалентно словосочетанию «политика утилизации ресурсов»), а еще есть совершенно идентичные по назначению локальные политики. Дело в том, что когда мы наконец добавим управляемые инстансы и data-tier приложения для каждого из них можно будет установить локальную политику на персональной странице данного экземпляра/приложения. И если это сделать, то к этому экземпляру/приложению будет применяться именно вот такая, локальная политика. А вот если этого НЕ делать «в игру» вступит та политика над редактированием которой мы сейчас работаем, т.е. глобальная.

    Ну – давайте уже посмотрим за настройкой глобальной политики в реальности. Щелкаем по заголовку Global Policies for Data-tier applications и попадаем в графический интерфейс настройки политики именно для этих типов объектов (полагаю, что читатели уже поняли, что и на глобальном, и на локальном уровнях политики для экземпляров серверов и для приложений «оформляются» независимо друг от друга. Т.е. при использовании SQL Server Utility у нас, самое меньшее, будет задействовано 2 политики – глобальная для инстансов и такая же для приложений). Первый раздел этого интерфейса (Ѕресіfу the CPU utilization policies for all dаtа-tіег applications) определяет три отрезка нагрузки в которых использование любым dаtа-tіег приложением центрального процессора будет расценено как «недо-», «пере-» и «нормально». Например первая строчка говорит, что по умолчанию использование CPU засчитывается как чрезмерное (обратите внимание на красную стрелку), если его использование данным dаtа-tіег приложением превышает 70%. Аналогично, вторая строка говорит, что нагрузка на CPU исходящая от данного dаtа-tіег приложения будет расценена как недостаточная если его потреблении упадет ниже 0%, а нагрузка в диапазоне этих границ, 0%-70%, будет трактоваться как «нормальная». Понятно, нагрузка на CPU стать отрицательной не может, а посему в политике для dаtа-tіег applications в отношении CPU по умолчанию может быть лишь 2 состояния:

    • CPU потребляется нормально (<70%)
    • CPU потребляется чрезмерно (>70%)

    Давайте, просто для эксперимента, утвердим иную политику:

    • CPU потребляется нормально, если нагрузка на него лежит в диапазоне 20%-85%
    • CPU потребляется чрезмерно, если нагрузка на него превышает 85%
    • CPU потребляется недостаточно, если нагрузка на него падает ниже 20%

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

    Следующие два раздела помогут нам выяснить и уловить момент когда в файлах данных или файле транзакционного лога той базы данных что является «подлежащей» для данного приложения станет недостаточно свободного места. Второй раздел управляет политикой для файлов данных, причем высчитывается свободное место (в процентах) для всех файлов данных объединено (если, разумеется, БД состоит более чем из одного файла данных). Видно, что по умолчанию считается что пока используется 0%-70% места в фале (-ах) данных этот ресурс засчитывается как «нормально» утилизируемый, а как только свободного места останется менее 30% произойдет переключение на статус «пере-утилизирован». Интерпретацию двух оставшихся строк политики (те, что имеют отношение к свободному месту в файле журнала) я оставляю на самостоятельную работу читателям. Уверен, что никаких проблем здесь быть не может.

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

    Рис. 08

    Не забудьте щелкнуть 'Apply' для фиксации новых значений политики!

    Теперь список Global Policies for Data-tier applications можно свернуть и раскрыть второй список, Global policies for Managed Instances. Понимание его после разбора предыдущего проблем не составляет, разве что необходимы пояснения по теме «что именно меряется» в том или ином разделе:

    • Specify the CPU utilization policies for all managed instance of SQL Server – меряется загрузка CPU «спровоцированная» только данным экземпляром, активность прочих процессов не учитывается
    • Specify the file space utilization policies for all managed instances of SQL Server – меряется процентный остаток свободного места во всех файлах данных/лога для всех баз обслуживаемых тем или иным инстансом
    • Specify the computer CPU utilization policies for all managed instances of SQL Server – меряется загрузка CPU «спровоцированная» любой активностью на компьютере где находится управляемый инстанс: службы, приложения «крутящиеся» в фоне и т.д.
    • Specify the storage volume utilization policies for all managed instances of SQL Server – меряется процентный остаток свободного места на тех HDD (томах) где располагаются файлы баз данных обслуживаемых данным экземпляром сервера

    Давайте тоже немного «подвигаем циферки» и в этом разделе, рис. 09.

    Рис. 09

    И снова не забудьте щелкнуть 'Apply'.

    Наконец, открываем третий список, Volatile Resource Policy Evaluation. Его назначение – уменьшить «шум» или «дребезг» неизбежно возникающие в процессе мониторинга. Дело в том, что, допустим, та же загрузка CPU может меняться очень часто и в очень широких пределах. Вот CPU загружен на 98%, а через 0.2 секунды – только на 3%, а еще через 0.5 секунды – на 74% и т.д. Здесь мы имеем тот редкий случай когда нам реально нужна «средняя температура по больнице», мы не собираемся впадать в панику если дважды в сутки на протяжении 0.1 секунды загрузка CPU достигнет 95%. Иными словами нам не интересны пиковые значения утилизации, нам нужна лишь общая картина. Но как составить такую «общую картину»? Третий список как раз дает ответ. Раздел 'How frequently should CPU utilization policies be in violation before reporting as overutilized?' объясняет когда действительно пора переводить статус утилизации CPU в состояние «пере-», а раздел 'How frequently should CPU utilization policies be in violation before reporting as underutilized?' делает тоже самое для состояния «недо-». Оба раздела уменьшают «дребезг» только для замеров утилизации CPU, т.к. утилизация свободного места на диске/в файле крайне редко будет «вибрировать», а однажды пересекая установленные нами границы снизу-вверх (или сверху-вниз) будет иметь обыкновение двигаться в том же направлении и далее.

    Пара ползунков в каждом из обсуждаемых разделов, по сути, отвечает на один вопрос: сколько раз за указанный период верхняя/нижняя граница политики должна быть нарушена что бы статус утилизации действительно был изменен? К примеру, по умолчанию в первом разделе верхний ползунок имеет значение 1 час, нижний – 20%. Чуть забегая вперед отметим, что данные с управляемых экземпляров и приложений собираются один раз каждые 15 минут, и эта установка не изменяема (почему так мы еще обсудим). Стало быть, за час будет произведено 4 «оценки» (60мин./15мин.) загруженности CPU. Если выход «за границы» не будет отмечен ни разу (0/4*100%<20%) то и делать ничего не надо. Если выход будет отмечен хотя бы в одном замере, то порог второго ползунка будет пройден (¼*100%>20%) и статус утилизации сменится на overutilized. Разумеется тоже самое произойдет и при 2-х, 3-х и т.д. нарушениях границ. А что если мы хотим что бы статус переключился только в случае если 3 (как минимум) из 4-х замеров будут с нарушением границ? Тогда мы должны посчитать процентное соотношение «всего нарушений/всего замеров», в данном случае ¾*100%=75% и выставить порог чувствительности (второй ползунок) на цифру выше просчитанной, например 80%. Или 90%. В любом случае, строка курсивного текста внизу обсуждаемого раздела в режиме реального времени обобщает настройки обоих ползунков и сообщает:

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

    С разделом underutilized ситуация совершенно аналогичная, только временное окно значительно грубее и находится в диапазоне 1 день–1 месяц, в отличии от 1 час–1 неделя раздела предыдущего. Идея авторов утилиты понятна, мы с гораздо большей тщательностью подходим к вопросу избыточной нагрузки нежели нагрузки не достаточной.

    Что же, давайте выставим ползунки как на рис. 10.


    Рис. 10

    Т.е. говоря обычным языком только если 14 (как минимум) замеров из 48 последних рапортуют о нарушении верхней границы утилизации CPU статус переводится в состояние «пере-», иначе остается состояние «норма». И только если 67 (как минимум) замеров из 672 последних рапортуют о нарушении нижней границы утилизации CPU статус переводится в состояние «недо-», иначе остается состояние «норма». Щелкнув 'Apply' мы можем, наконец, переключиться на вторую страницу администрирования – Security.

    На этой странице все значительно проще. В левой колонке таблицы на данной странице показываются все имена входов (logins) известные тому инстансу, чью UCP мы в данный момент администрируем. Мы можем против любого из логина поставить галочку в колонку Utility Reader, тем самым занося указанный логин в одноименную роль. Чисто технически после простановки галочки и нажатия на 'Apply' происходит вот что:

    • если для указанного логина еще нет пользователя (user) в нашей Utility Management Data Warehouse базе данных (имя её, напомню, sysutility_mdw) такой пользователь создается
    • пользователь из предыдущего пункта регистрируется как член роли UtilityMDWCacheReader. Указанная роль характерна для БД sysutility_mdw

    А по сути это будет значить что отмеченные галочками логин (-ы) будут иметь возможность:

    • подключаться (через Utility Explorer) к данной SQL Server Utility
    • просматривать всю информацию видимую в инструментальных панелях и представлениях Utility Explorer (и о чем речь у нас еще впереди)
    • в т.ч. он сможет видеть (но не редактировать!) все настройки узла Utility Administration над которыми мы трудимся в данный момент

    Для последней возможности необходимо пояснить что изменять настройки (и, соответственно, менять политики утилизации ресурсов) может лишь администратор утилиты, а стать им можно очень просто: необходимо что бы ваш логин с которым вы подключаетесь к UCP был членом фиксированной серверной роли sysadmin. Разумеется администратор утилиты автоматически является Utility Reader и лишить его этой возможности нельзя, для него (и вообще для всех администраторов БД) галочки в одноименной колонке проставлены и стиранию не поддаются. А вот логины рядовые можно как помещать в эту роль, так и удалять из нее.

    По желанию, сделайте 1-2 логина членами роли Utility Reader или пропустите этот шаг, на дальнейшую активность он не повлияет, т.к. мы будем подключаться к MyUtility всегда как администраторы.

    И, напоследок, страница заключительная — Data Warehouse. Еще раз напоминаю, что все данные собираемые SQL Server Utility сохраняются в выделенной для этой цели системной БД sysutility_mdw. Хостит эту базу тот же экземпляр на котором мы «поднимаем» UCP. Мы можем, до некоторой степени, управлять этой БД, а именно:

    • можно отрегулировать время в течении которого собранные данные хранятся в базе; иными словами можно регулировать срок после которого данные (более точно — данные собранные ранее установленного срока) будут автоматически удалены из sysutility_mdw с целью освобождения дискового пространства
    • можно изменить путь для файла данных обсуждаемой базы, а так же путь для файла ее транзакционного лога; по умолчанию оба файла находятся там же, где создается любая пользовательская БД (обычно c:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\)

    Из этих двух пунктов только первый выполняется с разбираемой страницы, а второй реализуется стандартной командой ALTER DATABASE, опция MODIFY FILE. При настройке первой опции исходите из того, что каждый инстанс за которым ведется наблюдение увеличивает размер обсуждаемой базы на (приблизительно) 2GB в год. Отсюда можете прикинуть сколько месяцев (лет) в вашей ситуации разумно хранить прошлую информацию. Технически этот диапазон значений ограничен одним месяцем снизу и двумя годами сверху. Давайте для наших упражнений выставим самый короткий срок хранения данных – 1 месяц (не забывайте о кнопке 'Apply').

    Наконец заметим, что в текущей версии сервера (2008 R2) мы НЕ можем управлять такими параметрами этой БД:

    • имя базы; оно фиксировано и всегда равно, как я уже упоминали не раз, sysutility_mdw
    • частота сбора новых данных с управляемых экземпляров; и этот параметр фиксирован и равен 15 минутам, что выяснилось еще когда мы настраивали «чувствительность» переключения статуса потребления ресурса

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

    Что же, с администрированием утилиты мы разобрались весьма подробно. Пора уже увидеть ее основной функционал – мониторинг экземпляров серверов и data-tier приложения. А для этого, как мы помним, существующей UCP надо указать – за какими, собственно, экземплярами необходимо вести наблюдение. Переходим к этой задаче.

    Внесение экземпляра сервера в список управляемых серверов

    Начнем мы, однако, не с самого списка, а с регистрации data-tier приложений. Мы же хотим посмотреть возможности мониторинга как инстансов, так и приложений, верно? Вот давайте создадим парочку последних.

    Итак – подключитесь к экземпляру по имени MSSQLSERVER2 и зарегистрируйте на нем 2 приложения слоя данных Northwind и pubs. Используйте одноименные учебные базы развернутые на этом экземпляре.

    Напомню, что узнать больше о dаtа-tіег applications можно из моей статьи «SQL Server 2008 R2. Data-tier Application. Разработка, внедрение, модернизация». В частности, раздел «Создание Data-Tier Application и DAC модулей непосредственно на сервере» упомянутой статьи подробнейше объясняет процесс регистрации приложения из готовой базы данных.

    Проверьте что регистрация была успешна. Узел Management->Data-tier Applications экземпляра MSSQLSERVER2 должен выглядеть примерно как на рис. 11.


    Рис. 11

    На экземпляре третьем, MSSQLSERVER3, пока давайте никаких приложений регистрировать не будем (проверьте заодно, что у этого инстанса узел Management->Data-tier Applications пуст).

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

    • включаемый экземпляр должен быть версии 2008 R2 (т.е. 10.5) или выше; да, увы, UCP не может мониторить даже 2008-е сервера, только R2 🙁
    • включаемый экземпляр не должен быть уже приписан никакой иной UCP
    • если UCP входит в домен, то и включаемый экземпляр должен входить в тот же самый домен (если это не так и домены разные придется установить между ними двусторонние доверительные отношения, two-way trust relationships)
    • так же как и на самом UCP SQL Agent включаемого экземпляра д.б. настроен на автозапуск И запущен до старта мастера включения серверов

    Итак, что бы начать процесс составления списка нам снова надо перейти в окно Utility Explorer и, если это еще не сделано, подключится к той UCP список которой, собственно, мы хотим пополнить новыми экземплярами. В нашем случае у нас единственная UCP, к ней и подключаемся. Далее из контекстного меню узла Managed Instances вызываем пункт Enroll Instance..., рис. 12 .


    Рис. 12

    Страницу знакомства традиционно пролистываем, Next >. На странице 'Specify The Instance Of SQL Server' с помощью кнопки Connect следует указать целевой экземпляр, т.е. тот против которого мы желаем вести мониторинг. Начнем с экземпляра MSSQLSERVER2, его и указываем, Next >. Страница 'Utility Collection Set Account' имеет абсолютно тот же смысл что и одноименная страница мастера создания UCP. Пользуемся уже существующей учетной записью (WIN2008\UCPuser) и ее паролем, Next >. Опять как и в мастере предыдущем на странице 'SQL Server Instance Validation' произойдет проверка включаемого экземпляра на соответствие всем необходимым условиям. И снова наша задача добиться 100% «зеленых галочек» в левой колонке таблицы на этой странице. Возможно это получится не сразу (не запустили SQL Agent для MSSQLSERVER2? не перевели эту службу в режим автозапуска? еще что-нибудь?), тогда не закрывая мастера исправьте проблемы и щелкните кнопку Rerun Validation, что приведет к перезапуску процедуры проверки. По достижению результата (при этом страница 'SQL Server Instance Validation' приобретет вид очень близкий виду той же страницы из предыдущего мастера, см. рис. 04) — Next >. Так же как и в предыдущем мастере мы попадаем на довольно формальную страницу Summary с итогами всего что было введено на предыдущих шагах, а очередной Next > выводит нас на страницу финальную, Enrollment of SQL Server Instance. Тут и происходит трехэтапный (за прохождением этапов, как обычно, можно наблюдать в реальном времени) процесс включения указанного экземпляра в список подлежащих мониторингу инстансов. Наконец Finish завершает работу этого мастера. Мониторинг только что включенного в список MSSQLSERVER2 уже начат, однако не отвлекаясь пока на достигнутый результат сразу же перезапустите тот же мастер и включите в список еще один экземпляр, MSSQLSERVER3. По его завершению удостоверьтесь что теперь при выборе узла Managed Instances у вас в Utility Explorer Content присутствуют оба наблюдаемых сервера, рис. 13.


    Рис. 13

    Мы сейчас внимательно осмотримся в новом графическом интерфейсе узлов Managed Instances и Data-tier Applications, однако прежде давайте зададим некоторую работу обоим инстансам, т.е. эмулируем обычный рабочий день реальных пользователей с сервером, который, очень упрощено, может быть представлен как выборка данных-вставка данных-удаление строк-пауза случайной величины-выборка-и т.д. Подготовленный скрипт WorkLoad.sql делает примерно такие же вещи нагружая наши экземпляры работой бессмысленной, но синтаксически корректной. Будем надеяться что результаты этой нагрузки будут видны в отчетах по потребляемым ресурсам. Запустим этот скрипт на обоих экземплярах через утилиту sqlcmd. Для этого сохраните указанный скрипт в любую папку на вашем диске, откройте 2 окна консоли и в обоих сделайте эту папку текущей. Далее в обоих окнах выполните команду вида

    sqlcmd -E -S <имя_компьютера>\<имя_экземпляра> -i WorkLoad.sql -o nul

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

    sqlcmd -E -S WIN2008\MSSQLSERVER2 -i WorkLoad.sql -o nul

    sqlcmd -E -S WIN2008\MSSQLSERVER3 -i WorkLoad.sql -o nul

    в первой и второй консолях соответственно. Благодаря опции '-o nul' мы не увидим на консоли километровые и абсолютно нам не интересные результирующие наборы от команд выборки находящихся в указанном скрипте. Скрипт работает не ограниченно долго (бесконечный цикл), однако я предлагаю оставить его в рабочем состоянии на пару часов, а пока можно вернуться к чтению статьи, разумеется НЕ закрывая консолей.

    Итак, что мы видим при выборе узла Managed Instances? Мы видим все приписанные данной UCP управляемые экземпляры, в нашем случае всего 2. В верхней части вкладки Utility Explorer Content приводится сжатое «резюме» (таблица) по потреблению ресурсов каждым из экземпляров. Четыре важнейших характеристики (первые четыре столбца таблицы слева-направо):

    • потребление CPU данным инстансом
    • потребление CPU всем компьютером на котором расположен данный инстанс
    • занятое/свободное место во всех файлах данных и файлах транзакционного лога тех баз, которые обслуживает данный инстанс
    • занятое/свободное на диске (-ах) (томе (-ах)) на котором (-ых) расположены файлы предыдущего пункта

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

    Может потребоваться вплоть до 45-ти мин. для отрисовки первоначальной информации собранной SQL Server Utility. А вот в дальнейшем графики, диаграммы и пиктограммы будут обновляться уже каждые 15 мин. Почему это будет случаться именно каждые четверть часа и никак иначе мы уже обсудили. По крайне мере до следующего релиза MS SQL Server-а это будет только так.

    На закладке соответствующей узлу Data-tier Applications мы пока не видим ни одного приложения, хотя, как мы помним MSSQLSERVER2 имеет их целых 2. Это тоже следствие предыдущего замечания, нужно просто подождать. Пока давайте посмотрим, какие еще колонки кроме 4-х уже упомянутых содержит таблица узла Managed Instances. По умолчанию, кроме этих 4-х основных должна присутствовать еще одна вспомогательная колонка — Policy Type. Она показывает какой именно политикой управляется данный инстанс. Слово «Global» в этой колонке означает что него действуют глобальные правила (те, что мы настраивали в разделе Администрирование SQL Server Utility), а слово «Override» означает что инстанс будет руководствоваться своими особыми правилами. Как такие особые правила можно назначить управляемому серверу мы еще обсудим. Так вот помимо этих 5 колонок по умолчанию можно добавить (а можно и наоборот — убрать) еще с десяток колонок несущих дополнительную информацию по каждому инстансу и/или о компьютере где этот инстанс «обитает». Тут и число процессоров, и объем RAM, и версия SQL Server-а, и его редакция и т.д. Добавление/скрытие колонок производится посредством правого щелчка по полосе заголовка колонок. В появляющемся вследствие этого действия списке достаточно поставить/снять отметку в зависимости интересна нам данная колонка или нет. С полным списком возможных колонок предлагаю ознакомиться самостоятельно, благо название почти каждой не оставляет сомнений о значении ею представляемой, рис. 14.


    Рис. 14

    По примерно похожей схеме строится и подвергается редактированию состав колонок таблицы управляемых приложений (для ее просмотра щелкните узел Data-tier Applications), но почти все колонки (например та же Application CPU) будут характерны именно для приложений, а не для экземпляров/компьютеров. Так же как во всех современных пользовательских интерфейсах колонки поддаются «тасованию» методом «схвати-за-заголовок-и-тащи».

    Итак, к этому моменту серые кружочки в 4-х основных колонках, вероятно, уже сменились пиктограммами (если нет – дождитесь этого момента, затем продолжайте чтение). Допустим в моем конкретном окружении Utility Explorer Content для узла Managed Instances выдал такую картинку, рис. 15:


    Рис. 15

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

    • два ресурса не догружаются работой – CPU каждого инстанса и место в файлах их баз данных
    • один ресурс имеет нормальную загрузку – CPU всего компьютера
    • один ресурс перегружен работой – свободное место на диске (томе)
    • наконец, то, что определения «не догружаются», «нормально», «перегружен» берутся, в конкретном числовом представлении, из политики глобальной

    Разумеется, в реальной работе у нас будет, например, 20 экземпляров каждый со своими пиктограммами. Было бы не плохо быстро посмотреть все экземпляры не догружающие CPU. Или те у кого свободное место на томе подходит к концу. Или те, что не догружают CPU И при этом НЕ имеют проблем с местом на томе. Ну и так далее. Этот момент создателями утилиты также предусмотрен: правый щелчок по узлу Managed Instances, Filter->Filter Settings. Для нас открывается одноименное окно где экземпляры из таблицы на рис. 15 можно отфильтровывать по различным критериям. Скажем на рис. 16 можно видеть настройки отвечающие последнему из трех условий приведенных для примера чуть ранее.


    Рис. 16

    Щелчок по 'OK' вводит фильтр в действие оставляя в таблице только удовлетворяющие условию экземпляры. Дабы мы не забыли, что часть инстансов, возможно, оказывается «за бортом» графического интерфейса имя узла меняется с 'Managed Instances' на 'Managed Instances (filtered)'. Что бы вернутся к списку по умолчанию (иными словами отменить любую фильтрацию): снова правый щелчок по узлу Managed Instances, Filter->Remove Filter. Замечу, что накладывать фильтры для самых популярных критериев (только экземпляры недогружающие CPU, только экземпляры перегружающие CPU и т.п.) можно вообще одним щелчком, однако разговор об этом я оставлю до того времени как мы начнем изучать корневой узел окна Utility Explorer.

    Теперь давайте посмотрим что у нас творится в закладке Utility Explorer Content ниже той таблицы о которой мы говорили только что. А там, как легко заметить, нас ждут 4-е вкладки: CPU Utilization, Storage Utilization, Policy Details, Property Details. Пройдемся по ним.

    Первая вкладка рассказывает и показывает в виде ломанной линии как во времени менялась загрузка CPU. Графика два, левый толкует о загрузке CPU тем инстансом что выбран в таблице (рис. 15), правый о загрузке CPU любой активностью компьютера. Ясно, что для любого количества инстансов размещенных на одном физическом сервере правые графики всегда будут идентичны. По оси Y графиков откладывается непосредственно загрузка CPU в процентах от 0% до 100%. Масштаб этой оси не меняется, да, наверно, и нет в этом необходимости. По X же, как обычно, откладывается время. В зависимости от того какая радиокнопка выбрана в панели Interval масштаб ее будет разным. Радиокнопка влияет на оси X обоих графиков. В принципе все выглядит достаточно разумно. Мы можем наглядно видеть как менялась нагрузка в течении дня, недели, месяца и года. Очень удобно для составления представлений о тенденциях ждущих нас впереди!

    Вкладка Storage Utilization рассказывает нам о колебаниях в объемах свободного места на диске вообще и в файлах данных в частности. Вкладка состоит из двух основных элементов – дерева объектов слева и графика справа. Объекты исследования могут представлять собой или отдельные базы данных инстанса, или диски (тома) всего компьютера этого инстанса.

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

    Переключение между этими вариантами осуществляется радиокнопкой из группы Group Files by. Если выбран вариант 'Database' то каждый корневой узел дерева представляет собой отдельную базу расположенную на экземпляре. Через под-узлы можно выйти на отдельные файлы данных и транзакционного лога. Для любого узла и под-узла кроме представляющих отдельные файлы данных/лога слева отображается одна из все тех же трех пиктограмм. Значение их все тоже – сообщить о статусе потребления ресурса в данный момент времени. Например из рис. 17 ясно видно что на моем инстансе MSSQLSERVER2 все базы данных имеют чрезмерно много не использованного пространства, причем как в файлах данных, так и в файлах транзакционного лога.


    Рис. 17

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

    • если файл НЕ сконфигурирован на авто-рост (auto-grow) то этот термин означает место на диске отведенное файлу в момент его создания
    • если файл сконфигурирован на авто-рост (auto-grow) то этот термин означает текущее место на диске выделенное файлу плюс все текущее свободное место на томе

    Вот к одному из этих двух значений соотносится объем реальных данных хранящихся в файле и результат выражается в процентах. Если «завесить» мышиный курсор над «прогресс-баром», то всплывающая подсказка покажет – что на что делилось для получения тех процентов что стоят за «прогресс-баром», рис. 18.


    Рис. 18

    Если же мы радиокнопкой выбираем второй тип группировки, 'Volume', то тогда корневыми узлами становятся диски компьютера, а под-узлами – все файлы данных/транзакционного лога на этом диске расположенные. Для диска показывается и одна из трех пиктограмм и «прогресс-бар» соотносящий объем всех (всех! не только файлов данных и лога, а вообще всех!) файлов с общей вместимостью диска. Для отдельных файлов показывается только «прогресс-бар» рассчитываемый по тому же алгоритму что и в случае группировки 'Database'. Снова для каждого «прогресс-бара» можно увидеть методику расчета через всплывающую подсказку.

    При любой методике группировки после выбора любого узла или под-узла справа отображается график показывающий — как менялась заполняемость того или иного объекта (диска, всех файлов отдельной базы, всех файлов отдельной файловой группы, отдельного файла) во времени. Шкала Y градуируется автоматически в кило- , мега- или гига-байтах и масштабируется (тоже автоматически) по алгоритму от 0 до максимально зафиксированное за «отчетный период» наполнение объекта данными. «Отчетный период» представлен осью X и вновь поддается масштабированию теми же 4-мя радиокнопками как и в случае предыдущей вкладки.

    Вкладка Policy Details позволяет настроить локальную политику потребления ресурсов данного экземпляра. Разницу между локальным и глобальным вариантом такой политики мы подробно разобрали в разделе Администрирование SQL Server Utility, и к текущему моменту я не вижу необходимости пояснять хоть один элемент интерфейса этой вкладки, все должно быть ясно из работы по настройке глобальной политики. Отмечу лишь, что по умолчанию любой инстанс изначально берет на вооружение политику именно глобальную, которую с данной вкладки просмотреть можно, а изменить – нет. И еще отмечу, что данной вкладке, на первый взгляд, не хватает раскрывающегося списка 'Volatile Resource Policy Evaluation' что имеет место быть при настройке политики глобальной. Однако это потому, что уровень чувствительности задается один раз и действует сразу на все политики – и глобальные, и локальные. Так что для его изменения придется снова обратится к узлу Utility Administration рассмотренному нами в упомянутом разделе.

    Наконец вкладка финальная, Property Details, попросту сообщает нам некоторые факты об экземпляре и компьютере на котором он расположен. Вкладка не имеет активных элементов управления и задерживаться на ней мы тоже не станем.

    Теперь давайте переключимся (в окне Utility Explorer) на узел Data-tier Applications. Если к этому моменту у нас состоялся хотя бы 1 сбор информации с наших инстансов, то увиденное в закладке Utility Explorer Content не оставляет сомнений в следующем немаловажном факте: при добавлении в список наблюдаемых любого экземпляра, все зарегистрированные на нем data-tier приложения так же начинают мониториться утилитой. У нас на 2 наших управляемых инстанса 2 приложения (оба на MSSQLSERVER2), верно? Вот мы и получаем картинку как на рис. 19.


    Рис. 19

    Легко заметить, что это практически та же самая таблица что и на рис. 15, и с теми же пиктограммами, только с иными колонками (в основном; понятно что колонки типа Computer CPU или Volume Space будут одинаковы для обеих таблиц). Тут важно понимать что нет процедуры внесения того или иного приложения в список управляемых (в отличии от аналогичной процедуры для экземпляров, разобранной нами буквально только что). И нет процедуры исключения приложения из этого списка. Data-tier приложения «приходят» в- и «уходят» из- этого списка одновременно с включением/исключением того инстанса на котором они расположены. А вот инстансы действительно могут вносится в список и исключаться из него по желанию администратора, мы уже умеем делать и то, и другое. Давайте проверим это предположение. Перейдите в окно Object Explorer и в нем:

    • удалите на MSSQLSERVER2 приложение Northwind; выберите вариант удаления 'Delete registration'; при необходимости проконсультируйтесь с разделом «Удаление Data-tier приложения с сервера» статьи «SQL Server 2008 R2. Data-tier Application. Разработка, внедрение, модернизация».
    • на MSSQLSERVER3 зарегистрируйте приложения слоя данных pubs; используйте одноименную базу развернутую на этом экземпляре

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


    Рис. 20

    Хм, Northwind (MSSQLSERVER2) был убран, это верно, но где же pubs с MSSQLSERVER3 зарегистрированный только что? И снова наблюдаемый эффект следствие «задумчивости» утилиты (впрочем при планируемом непрерывном времени работы в несколько лет и с учетом того факта, что любой мониторинг это в той или иной степени усреднение наблюдаемых значений, мгновенная реакция на изменения и не нужна). Помните, что первая информация о вновь зарегистрированном объекте (инстансе, приложении) может поступить с задержкой вплоть до 45-ти минут. В общем, если просто проявить еще терпения и подождать мы придем к ожидаемому, рис. 21.


    Рис. 21

    Два одноименных Data-tier Application но с разных инстансов (какое к какому относится можно судить по колонке Instance Name; если в вашем случае такая колонка в таблице не наблюдается, то правый клик по заголовку колонок должен помочь устранить этот пробел).

    Если говорить о графическом наполнении закладки Utility Explorer Content для узла Data-tier Applications, то вполне можно быть кратким: на 90% информация дублируется той что находится на одноименных вкладках узла предыдущего (как мы видим у Data-tier Applications те же 4 вкладки внизу таблицы — CPU Utilization, Storage Utilization, Policy Details, Property Details), а мы уже изучили правила работы с ними в предыдущих абзацах. Пожалуй самостоятельную ценность имеет лишь левый график закладки CPU Utilization, ведь только на нем можно увидеть как был нагружаем (во времени) CPU работой относящейся только к выбранному приложению.

    Как и в предыдущем случае информация в любой из 4-х изучаемых вкладок всегда относится к тому приложению (или компьютеру/инстансу где это приложение расположено) что выбрано в таблице (рис. 19).

    Все остальное с равным успехом можно видеть и в узле Managed Instances. Ну и еще на вкладке Policy Details можно настроить локальную политику для данного приложения (а не инстанса, как в было в узле Managed Instances). Снова по умолчанию все приложения берут на вооружение политику глобальную (а активная политика всегда видна в колонке Policy Type таблицы, см. рис. 19). И, конечно же, на месте фильтры отображаемых приложений. Устанавливать/стирать их можно аналогично фильтрам для экземпляров: правый клик по узлу Data-tier Applications, пункт Filter контекстного меню и далее Filter Settings/Remove Filter по ситуации.

    Ну что же, для нашего внимания остался последний узел, корневой. В нашем случае он имеет имя MyUtility, по нему и щелкаем. Закладка Utility Explorer Content меняет свой внешний вид и отображает т.н. Utility Dashboard (панель мониторинга). Ее цель — дать самую общую информацию по всем экземплярам/приложениям за которыми ведется наблюдение, без погружения в детали. Так же сообщается некоторая информация о самой утилите, а точнее о ее UMDW (проще говоря о базе данных sysutility_mdw). Панель разделена на 9 секций, кратко, слева-направо и сверху-вниз, о каждой:

    • в левом верхнем углу панели располагается секция Managed Instance Health; сообщает как управляемые инстансы распределяются среди «недо-», «пере-» и «хорошо-» потребляющих ресурсы. Четвертый вариант, 'No Data Available' говорит о количестве инстансов для которых сбор данных не был произведен еще ни разу. При этом, для данной секции:
      • если инстанс чрезмерно нагружает хотя бы 1 ресурс, то он попадает в категорию Overutilized
      • если нет чрезмерно нагруженных ресурсов, но есть хотя бы 1 недогруженный – инстанс отправляется в категорию Underutilized
      • наконец, только если все и каждый ресурс потребляется эффективно (с т.з. активной политики, разумеется) – инстанс отправляется в категорию Well-utilized

      в категорию No Data Available обычно попадают инстансы недавно добавленные в список управляемых (или имеющие технические проблемы); не хитрая секторная диаграмма показывает распределение инстансов по этим 4-м категориям

    • секция Utility Summary попросту сообщает об общем количестве экземпляров и приложений находящихся «на контроле» данной сервисной точки управления (UCP)
    • секция Data-tier Application Health имеет тот же смысл то и первая секция, но в разрезе управляемых приложений, а не экземпляров
    • четыре следующих секции (Managed Instances with Overutilized Resources, Data-tier Applications with Overutilized Resources, Managed Instances with Underutilized Resources, Data-tier Applications with Underutilized Resources) по сути поясняют почему (из-за каких ресурсов) количество инстансов/приложений в каждой из трех категорий (Underutilized, Overutilized, Well-utilized) именно таково, как представлено секциями Managed Instance Health/Data-tier Application Health; скажем из фрагмента Utility Dashboard представленного на рис. 22 можно сделать вывод что оба управляемых приложения попали в категорию Overutilized т.к. оба компьютера на которых они расположены чрезмерно нагружают свои CPU (с местом на диске у этих компьютеров тоже не все ладно). У обоих приложений есть и недогруженные ресурсы, однако для секций Health перегрузка имеет преимущество при отнесении объекта к той или иной категории. Еще можно заметить что поясняющие надписи (Underutilized Data-tier Application CPU, Underutilized Database Files и т.д.) этих 4-х секций подчеркнуты, и это действительно ссылки, по ним можно щелкать. При этом мы переходим на соответствующий узел окна Utility Explorer и дополнительно устанавливается фильтр. Помните я обещал рассказать об установке фильтров для самых популярных критериев одним щелчком? Это они и есть. Щелкните по Overutilized Instance CPU – вы перенесетесь на узел Managed Instances и увидите только экземпляры перегружающие CPU; щелкните по Underutilized Database Files (в секции Data-tier Applications with Underutilized Resources) – вы перенесетесь на узел Data-tier Applications и увидите только приложения имеющие слишком много свободного места в файлах данных/лога подлежащей БД. И т.д. После ухода с соответствующих узлов такие «быстрые фильтры» остаются активными, поэтому всегда внимательно смотрите на присутствие слова filtered в названии двух упомянутых узлов, рис. 23. При его наличии помните, что закладка Utility Explorer Content, с большой долей вероятности, отображает не все инстансы/приложения. Не забывайте своевременно очищать установленные фильтры через правый щелчок по узлу.
    • секция Utility Storage Utilization History показывает как в течении дня/недели/месяца/года (можно переключать радиокнопкой) менялась заполненность того тома где располагаются файлы данных самой утилиты (т.е. файлы БД sysutility_mdw)
    • наконец, секция Utility Storage Utilization показывает текущее распределение (более точно – то, каким оно было на момент последнего сбора информации) «занято/свободно» на том же самом томе


    Рис. 22


    Рис. 23

    Итак, в этом центральном разделе статьи мы научились добавлять к списку управляемых экземпляров новые элементы, которые (потенциально и автоматически) могут добавить элементы в список управляемых приложений. Мы так же достаточно подробно разобрали графический интерфейс новой утилиты и поняли как интерпретировать его многочисленные графики и отчеты. Нам остался вопрос совсем уж пустяковый – если нужда в услугах утилиты отпала, то как удалить с управляющего экземпляра ранее созданную UCP и сэкономить место (и ресурсы) за счет избавления этого экземпляра от присутствия утилитной БД sysutility_mdw? Давайте разберем и этот момент.

    Удаление существующей сервисной точки управления (UCP).

    Сразу к делу:

    • подключаемся (в окне Utility Explorer) к точке требующей удаления
    • переходим на узел Managed Instances и последовательно, один за одним, удаляем ВСЕ управляемые данной UCP экземпляры
    • убедившись что список управляемых экземпляров пуст (не забывайте о возможных фильтрах!, см. рис. 23) отключаемся от точки; окно Utility Explorer можно тоже закрыть
    • против того экземпляра на котором все еще существует точка (теперь уже не ведущая наблюдений) выполняем скрипт:

    EXEC msdb.dbo.sp_sysutility_ucp_remove;

    • при условии что скрипт выполнился без ошибок процедура удаления завершена

    Удалилась ли с управляющего экземпляра БД sysutility_mdw? В общем случае – да (проверьте!), однако если наш управляющий экземпляр (теперь уже бывший) содержит иные (кроме созданных SQL Server Utility) наборы элементов сбора (data collection set) то sysutility_mdw после выполнения указанного скрипта удалена НЕ будет и указанные наборы смогут безболезненно продолжить свое функционирование. Обратите внимание, что в последнем случае если мы позже задумаем пересоздать UCP на том же самом инстансе, то указанная база должна быть удалена вручную, до начала процесса пересоздания. Это положение диктуется необсуждаемым правилом: тот инстанс на котором планируется создать UCP НЕ ДОЛЖЕН иметь базу данных с именем sysutility_mdw.

    Заключение.

    Ну что же, из всего увиденного, опробованного а так же из некоторого опыта работы с утилитой в реальных условиях можно сделать вывод что предложенная система мониторинга потребления ресурсов получилось на удивление зрелой. Не сложной для обучения, легко реализуемой на практике, визуально привлекательной и с легко понимаемыми отчетами по потреблениям. Для пилотной версии – очень не плохо, 4.5/5! Пол-балла снято за не умение мониторить потребляемую память, а ведь именно дефицит этого ресурса зачастую ведет к проблемам производительности. Однако что касается двух других важнейших ресурсов (CPU/HDD) все сделано почти идеально: можно следить за «прожорливостью» отдельного приложения, целого инстанса, а то и всего компьютера; рисуемые графики позволят выявить тенденции с достаточной точностью и можно будет весьма своевременно озаботиться покупкой, допустим, более мощного CPU; наличие фильтров позволит легко видеть только проблемные экземпляры/приложения, либо напротив – только объекты не имеющие проблем с ресурсами; простая, но на удивление гибкая система глобальных и локальных политик позволит настраивать понятия «пере-» и «недо-» использованного ресурса даже для самых неоднородных окружений; наличие продуманной системы «пороговых значений» не позволит мониторингу «поднимать шум» по каждому пустяку, а заставит его реагировать лишь на действительно значимые изменения в характере потребления ресурсов.

    Если Вы работаете на достаточно крупном предприятии с несколькими SQL серверами, то, не сомневаюсь, вы найдете SQL Server Utility своим лучшим помощником в деле мониторинга ресурсов. Еще раз повторю, что система весьма продуманна, надежна, эффективна и безусловно может быть рекомендована к внедрению на реальные сервера, пользуйтесь на здоровье! 🙂

    Я же традиционно благодарю всех своих читателей за внимание и за будущие отзывы на данную статью и надеюсь на новую встречу.

    Щербунов Нейл Анатольевич

    net4net@gmail.com

    • Рубрика: SQL,Новое
    • Автор: Щербунов Нейл
    • Дата: Четверг 15 Июл 2010

Комментарии

  1. О, долгожданная статья, почитаем 🙂

  2. Автору статьи огромное спасибо за большую проделанную работу.

    Статья просто шикарная получилась!

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

  3. Нажмите «Версия для печати» под статьей) Это кнопка плохо видна, но она есть)

  4. Спасибо не заметил 🙂 Может ее лучще сделать справой стороны, так она не будет сливаться с комментариями.

  5. >Статья просто шикарная получилась!

    Благодарю, коли так. 🙂 Как и любому автору мне важны любые отзывы моих читателей, но такие отзывы еще и приятны, спасибо!

  6. [...] Собирался я написать афигительную статью по UCP, но таку... [...]

  7. Здравствуйте!

    Спасибо за статью, очень познавательно.

    А можно перезалить файл «WorkLoad.sql», а то при попытке его скачать, появляется ошибка «Error 404 — Not Found»

Опубликовать

Я не робот.