(Возврат на основную страницу)
Мониторинг кольцевых буферов с помощью XML
Билл Вундер (Bill Wunder)
Принципы резервирования ядром SQL Server пространства VAS
(область MemToLeave)
Джонатан Кехайяс (Jonathan Kehayias)
Что изменилось?
Билл Вундер (Bill Wunder)
Мониторинг кольцевых буферов с помощью XML
Билл Вундер (Bill Wunder)
Мониторинг в версии SQL Server 2008 отличается от мониторинга во всех предыдущих
релизах сервера SQL Server. Хотя основные принципы, определяющие, за чем следить
и как реагировать, остаются, главным образом, теми же, что и раньше, сбор
информации, необходимой для выбора правильного решения, осуществляется совсем
иначе. В версии SQL Server 2008 существуют динамические административные
представления (Dynamic Management Views, DMV), которые демонстрируют: какие
запросы выполняются неэффективно, какие таблицы являются проблемными с точки
зрения индексации и какие процессы сталкиваются с трудностями при получении
необходимых им данных. В этой версии есть хранилище (Management Data Warehouse),
предназначенное для автоматической регистрации данных о производительности
системы на протяжении некоторого периода времени. В SQL Server 2008 доступна
информация об использовании дискового пространства и о производительности
запросов. Кроме того, в этой версии по умолчанию выполняется трассировка,
которая позволяет не упустить из виду какое-то проблемное функциональное
поведение. Политики используются для того, чтобы облегчить получение
согласованных конфигураций, аудит — чтобы помочь проследить любые изменения на
сервере, и есть еще подсистема расширенных событий, задача которой — собрать
подробную информацию на этапе выполнения, не жертвуя при этом
производительностью ради приложений SQL Profiler и SQL Trace.
Тех из нас, кто многие годы занимался администрированием баз данных SQL Server, такое количество изменений способно почти что напугать. В некотором смысле, современный SQL Server невозможно распознать как эволюцию продукта 10-летней давности. Кроме того факта, что инструкции SELECT, INSERT, UPDATE и DELETE по-прежнему остаются тем, что SQL Server делает наилучшим образом, мало что еще сохранилось в неизменном виде.
Примите во
внимание, как далеко и как быстро продвинулись вперед языки XML и XQuery в
качестве жизнеспособных инструментов разработчика баз данных в SQL Server,
начиная с версии SQL Server 2000.
С появлением версии SQL Server 2008 пора, наконец, администраторам баз данных
освоить и это измерение. Администратор БД со знанием языка XML в большей степени
соответствует условиям работы, сложившимся после появления версии SQL Server
2000.
Если используется ядро СУБД SQL Server 2000, администратору БД достаточно знать о внутренней функциональности XML только то, что реализация XML в любом варианте способна создать еще большую нагрузку на и без того уже перегруженную область памяти memtoleave. В стремлении избежать возникновения условий «недостаточно памяти» у администратора есть только один способ — воспрепятствовать подготовке документов XML на сервере баз данных. Разработчики могут получить ограниченный выигрыш от расширений для XML-данных на стороне сервера SQL Server при условии, что к масштабируемости и производительности предъявляются умеренные требования. У администратора БД нет никакой реальной необходимости в понимании того, как работать с XML-документами, и он может обращаться с ними так же, как с любыми другими данными типа BLOB: с большой неохотой и трепетом душевным.
Начиная с
версии SQL Server 2005, потребность в том, чтобы администраторы БД овладели
XML-способностями SQL Server, стала более насущной. Умение распознать
необходимость использования XML-индексов, настроить базу данных для поддержки
XML, создать XML- индексы и обеспечить надлежащее техническое обслуживание
XML-индексов для повышения производительности XML-запросов, не говоря уже о
понимании того, как получить схемы XML для поддержки типизированных
XML-документов — такие знания и навыки требуются от администратора БД,
работающего с версиями SQL Server 2005 и старше. Кроме того, наличие у
администратора БД способностей потреблять и манипулировать частично
структурированными (semi-structured) данными вроде XML-кода предполагают
несколько заслуживающих внимания представлений с данными о производительности
системы, ее безопасности и параметрах, характеризующих функциональную
совместимость системы на низком уровне для экземпляра SQL Server. Например,
набор записей о самых последних системных событиях, связанных с
производительностью, полезный для документирования узких мест в
производительности, содержится в виде XML-данных в представлении DMV
sys.dm_os_ring_buffers. Чтобы во всех деталях расшифровать содержимое этой
очереди событий монитора ресурсов, как ее описывает Слава Окс (Slava Oks http://blogs.msdn.com/slavao/archive/2005/02/19/376714.aspx),
необходимо обратиться с запросом к столбцу с типом XML, найденному в каждой
строке результирующего набора представления DMV. Несмотря на наличие примеров,
где для разбора столбца record используются фильтры с аргументом LIKE
применительно к хранящемуся в виде строки XML- документу, использование
XML-методов обеспечивает значительно более эффективный, читабельный, повторно
используемый и предоставляющий большие возможности путь доступа к встроенной
XML-информации.
Принципы резервирования ядром SQL Server пространства VAS
(область MemToLeave)
Джонатан Кехайяс (Jonathan Kehayias)
Уже довольно давно у меня имеется Word-документ, над которым я работал, чтобы
раскрыть тему резервирования ядром SQL Server виртуального адресного
пространства (Virtual Address Space, VAS) (известного также как область
MemToLeave). В этом году я был довольно сильно загружен и потому никак не мог
найти время для завершения этой работы. На сегодняшний день на сайте SQL Server
Central опубликована статья под заголовком «SQL Server Memory Configuration,
Determining MemToLeave Settings» («Конфигурирование памяти SQL Server,
определение настроек MemToLeave»), в которой дается неверная информация и
которая не в состоянии адекватно раскрыть тему. Я оставил комментарий к этой
публикации, но тема резервирования пространства VAS ядром SQL Server слишком
обширна, чтобы ее можно было раскрыть в комментариях к статье, которую вряд ли
будут читать те, кто испытывает затруднения с виртуальным адресным пространством
на экземпляре SQL Server.
Начать с того,
что MemToLeave — это имя, или, так будет точнее, неправильное имя. Выбор имени
MemToLeave основывался на том способе, который сервер SQL Server использует для
выделения памяти в момент его запуска, но в итоге такое имя формирует ошибочное
представление, будто речь идет о памяти, распределением которой SQL Server
заниматься не будет. Подобающая терминология для того, что широко известно под
именем MemToLeave, — это резервирование виртуального адресного пространства (VAS
Reservation). Используемая ядром SQL Server, эта область памяти часто
оказывается первопричиной множества встречающихся в интернете вопросов,
связанных с исключениями «Недостаточно памяти» (Out of Memory Exceptions) внутри
SQL Server; к тому же, эта область является одним из тех фрагментов памяти SQL
Server, для которых в наибольшей степени характерно неправильное их понимание.
Прежде чем приступить к разбору внутренней организации памяти в SQL Server,
давайте сначала рассмотрим виртуальное адресное пространство вообще и выявим
отличия, существующие между 32- и 64-разрядными серверами.
Что изменилось?
Билл Вундер (Bill Wunder)
Прокладываем кратчайший путь к ответам на вопросы, возникающие при диагностике и
разрешении проблем надежности и производительности Microsoft SQL Server
В версиях 2000, 2005 или 2008 экземпляр ядра СУБД Microsoft SQL Server может использовать метаданные, чтобы собрать коллекцию регуляторов, переключателей, настроек и сценариев языка определения данных (Data Definition Language, DDL), необходимых для точного воссоздания данного экземпляра SQL-сервера. При возникновении непредвиденных проблем с базой данных, будь то на рабочем сервере или на автономном настольном компьютере, который используется для тестирования, быстрый и легкий доступ к информации об изменениях в конфигурации базы данных, сопутствовавших возникшей проблеме, неоценим для диагностики неисправности или скорейшего восстановления. По сути дела, одно только наличие предыдущей конфигурации, легкодоступной для осуществления отката в прежнее состояние, может служить тем отличием, которое определяет: обеспечен ожидаемый уровень обслуживания или нет. После того, как кризисную ситуацию стабилизировали, способность идентифицировать изменения, внесенные в конфигурацию за некоторый период времени, полезна для того, чтобы разобраться, в чем заключалась ошибка, и, что более важно, для того, чтобы предотвратить повторное возникновение этих же проблем в будущем. Для вычислительных центров, занимающихся разработкой, и некоторых ферм серверов баз данных возможность сравнить конфигурации экземпляров SQL-серверов необходима для понимания — или, еще лучше, предотвращения — причин снижения работоспособности системы, либо ее выхода из строя в результате внесения изменений.
Почти каждый администратор БД располагает арсеналом инструментальных средств, которые отчасти помогают в таком, совсем не редком, сценарии. К сожалению, многие из этих инструментов дорого обходятся серверу. Многие из них требуют, чтобы администратор БД подключился к аварийной системе и вручную обратился к ней с несколькими довольно "тяжелыми" запросами. Кроме того, разрешение на доступ к рабочим экземплярам SQL- серверов, выданное сотрудникам, не принадлежащим к группе администраторов БД, с целью проведения специальных исследований и сравнений, может не только повлиять на производительность, но существенно повышает риск ухудшить ситуацию. К тому же, возрастает вероятность того, что произойдет нечто непредвиденное, и это "непредвиденное" почти никогда не будет желанным побочным эффектом. Например, если сервер в течение длительных периодов времени работает с нагрузкой, скажем, 65%+ ЦП, вероятность того, что любой административный или аналитический запрос может негативно повлиять на производительность оказывается выше, чем в том случае, когда нагрузка ЦП большую часть времени удерживается на уровне 20% или менее. Даже если проблема не связана напрямую с производительностью, исследовательские работы могут вызвать блокировку и непредусмотренный аварийный сбой при выполнении приложением операций с базой данных.
Диагностический
арсенал администраторов БД —это до некоторой степени проверенные средства. В
версиях SQL Server 2005 и SQL Server 2008 полезным инструментом является также
выделенное административное подключение. С другой стороны, аналитики и
разработчики склонны к прямолинейности при диагностике и исправлении
неисправностей и опираются в большей степени на свое знание приложения, нежели
на следствия, к которым приводят их действия на инспектируемом сервере SQL
Server. По этой причине, особенно, если для организации важны надежность и
производительность базы данных, внутренний анализ не должен сопровождаться
требованием прямого доступа аналитика или разработчика к рабочим системам.
Вместо этого, предпочтительнее вести мониторинг изменений, отображаемых в
стандартизованных метаданных о конфигурации и производительности, обеспечить
общий доступ и асинхронное распространение информации среди коллективов,
занимающихся разработкой и поддержкой приложения SQL Server, и не предоставлять
всем и каждому прямой и неограниченный доступ к информации, необходимой для
того, чтобы надлежащим образом обслуживать приложение. В равной степени важно
защитить рабочую базу данных и одновременно рабочую систему от ненужного
произвольного доступа.
(Возврат на основную страницу)