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

Содержание номера за Июль 2008 год

SQL Server

Июль 2008
№ 7 (91)

Editorial

Шон МакКоун

Конец Windows?

Programming

Эрланд Соммарског

Условия динамического поиска в T-SQL. Часть 3

DB Design & Warehousing

Кален Делани

Погружение в метаданные объектов хранения

Other

Грэг Ларсэн

Измерение производительности операторов T-SQL  

Брэд МакГи

Использование монитора производительности. Часть 1 

Конец Windows?

Не так давно в моем почтовом ящике оказался журнальчик, предрекающий конец Windows. Хотя эта мысль и греет кое­кому душу, с практической точки зрения это вряд ли реально. Например, мои друзья в Oracle постоянно жалуются о необходимости использовать Windows, но даже они признают, что Linux еще не доросла до практического применения в бизнесе.

Аргумент журнальчика в основном основывался на том, что Vista работает медленно и чудовищно раздута, что Microsoft не предоставляет пользователям требуемого, продолжая пользоваться своей репутацией. Отчасти это верно, но я не думаю, что близко то время, когда кто­нибудь откажется от Windows в пользу Mac или Linux. По ссылке http://blogs.techrepublic.com.com/hiner/?p=661 я нашел прекрасную заметку, развенчивающую утверждения о кончине Windows.

Однако, со своей стороны, должен сказать, что Vista меня чудовищно разочаровала. В ней есть несколько неплохих идей, но исполнение настолько хромает, что оно того почти и не стоит. Сама OC настолько медленно работает, что иногда непросто выполнить самые простые задачи. Я поставил ее на весьма навороченный компьютер под столом, но она по­прежнему еле ворочается. Такого плохого выпуска Windows уже не было много лет (разве что кто­то вспомнит Windows ME).

Трудно поверить, чтобы группа разработки Vista сама работает на этом творении. Если бы так, они выпустили бы патчи, способные исправить ситуацию. А может быть оно и не лечится. Может быть, нужно слишком много переработать, чтобы избавиться от основной причины тормозов? Не знаю. Я не разговаривал на эту тему с разработчиками Vista. Все что я знаю как конечный пользователь (притом опытный) — я очень разочарован результатами.

Давным­давно я написал, что разработчики должны премироваться в соответствии с качеством кода, который они создают. Если бы такой принцип использовался в Microsoft, Vista так бы и не вышла.

По большей части мои интересы лежат в мире SQL и знаю, что в команде разработчиков SQL Server есть правило, что код не выходит из группы разработки, пока он не готов. Не вижу, чтобы в команде Windows использовалась бы подобная философия. Если ОС проходит хоть какое­то тестирование на качество, то нет никаких шансов, чтобы Vista прошла этот тест. Просто никогда не поверю, чтобы на внутренних тестах все было хорошо, а потом при массовом использовании начались проблемы. Соответственно, возникают два предположения. Либо Vista не проходила надлежащего тестирования, либо Miscrosoft просто наплевать на то, как ее воспримут в массах, и продукт был выпущен несмотря ни на что. У меня производительность труда на Vista и близко не подходит к тому, что было на XP. Однако есть пара вещей, которые мне реально нужны, и я вынужден ими пользоваться независимо от чудовищно медленной работы. Это похоже на отвратительную работу с великолепной оплатой. Утром вас тошнит от одной мысли, что нужно идти на службу, в то же самое время не получается найти ничего приемлемого за подобную зарплату.

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

Я зарабатываю на жизнь использованием продуктов Microsoft и я очень их поддерживаю. Я защищаю Windows, SQL Server, IIS и все остальное от тех, кто старается приложить Microsoft. Но даже я устаю от необходимости переходить на новую версию только для того, чтобы оказаться в еще худшем положении.

Так что, Microsoft, вы просто не тестируете или вам все равно?

Условия динамического поиска в T-SQL. Часть 3

DOWNLOAD

Использование временных таблиц

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

Заключение

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

Позвольте еще раз подчеркнуть, что неважно, используете ли вы динамический или статический SQL, вы должны тестировать свои процедуры на предмет всех входных параметров и желательно их различных комбинаций, определяя корректность работы и производительность. Чтобы протестировать производительность, вам необходимы данные, похожие на вашу реальную информацию. Если вы собираетесь работать с десятью миллионами заказов и 50000 покупателями, то вам нельзя использовать игрушечные по размерам базы типа Northwind и даже Northgale.

Погружение в метаданные объектов хранения

Новые представления в SQL Server 2005 предоставляют вам больше доступа к внутренней организации страниц

Как вы узнали из статьи «Управление пространством данных», SQL Server 2005 управляет пространством, в котором хранятся объекты базы данных (т. e. таблицы, индексы и большие объекты — LOB) иначе, чем SQL Server 2000. Основное отличие состоит в том, что SQL Server 2005 предусматривает не одну таблицу или представление для хранения информации об объектах, занимающих пространство; по аналогии с системной таблицей sysindexes в SQL Server 2000. Вместо этого в SQL Server 2005 предусмотрено несколько новых представлений, в которых содержится информация, которая раньше была доступна через sysindexes. Давайте поближе рассмотрим эти представления и примеры запросов, которые вы можете использовать для изучения содержащихся в этих видах метаданных объектов хранения.

Измерение производительности операторов T-SQL

Каким образом вы определяете производительность вашего приложения? Какие инструменты для этого вы используете? Каждый разработчик должен быть уверен, что любое T-SQL-выражение в его приложении оптимизировано. Настроив как следует каждый запрос, вы можете быть уверены в том, что ваше приложение работает так быстро, как это возможно. Гораздо удобнее модифицировать код приложения работая в среде разработки. После того как ваше приложение передается в эксплуатацию, внесение изменений в код для его оптимизации может занять длительное время, если это вообще возможно. Поэтому необходимо периодически переоценивать производи­тельность вашего приложения в ходе разработки приложения. В этой статье описано несколько разных способов определения медленно выполняющихся запросов, а также некоторые советы по слежению за произво­дительностью запросов во время внесения итеративных изменений в каждый запрос для оценки и увеличения производительности.

Использование монитора производительности. Часть 1

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

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

Как хорошие администраторы, мы не хотим узнавать от наших пользователей, что SQL Server имеет проблемы с производительностью. Наоборот, мы хотим упредить и разрешить проблемы производительности до того, как они возникнут. Именно эти задачи нам поможет решить монитор производительности (Performance Monitor). Это инструмент, который позволяет нам отслеживать состояние SQL­сервера и предоставляет информацию, которая нам нужна для эффективной настройки нашего SQL­сервера.

Монитор производительности это важный инструмент, т. к. он не только предоставляет нам информацию о производительности SQL­сервера, но также информирует о состоянии Windows Server, которое, безусловно, напрямую влияет на производительность SQL­сервера.

«Производительность» («Performance Monitor») из пункта «Microsoft SQL Server» меню Пуск (Start) — это то же, что и «Производительность» («Performance Monitor») из пункта «Администрирование» («Admi­nistrative Tools») меню Пуск (Start). Это одинаковые программы. Отличие в том, что когда вы запускаете монитор производительности из меню «Microsoft SQL Server», он открывается с несколькими предварительно сконфигурированными счетчиками производительности SQL­сервера.

Монитор производительности из меню «Администрирование» («Administrative Tools») открывается без каких­либо предварительно сконфигурированных счетчиков. Лично мне не нравится пользоваться первой программой и я всегда пользуюсь монитором производительности из меню «Администрирование». Поэтому мне всегда приходится выбирать счетчики SQL­сервера, которые я предпочитаю использовать.

Если вы — как я, то у вас есть один или два производственных сервера с SQL Server, за состоянием которых очень важно следить. Для того чтобы упростить слежение за состоянием этих «важных» SQL­серверов, я всегда держу запущенным на моем (рабочем компьютере экземпляр монитора производительности, который отслеживает информацию о этих серверах. Я не записываю эти данные, но мне нравится возможность просмотра ключевых счетчиков производительности (в виде диаграмм) на протяжении дня.

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

Для минимизации влияния этого постоянного мониторинга ваших SQL­серверов, не следует отслеживать слишком много счетчиков. Ниже перечислены основные счетчики, которые я предпочитаю отслеживать на регулярной основе:

• Память — Обмен страниц/сек (Memory — Pages/Sec). Чтобы понять, как часто на сервере выполняется страничная подкачка. Это значение должно быть близко к нулю для выделенных SQL­серверов. Вы заметите пики при выполнении резервного копирования и восстановления, но это нормально.

• Сетевой Интерфейс — Всего байт/сек (Network Interface — Bytes Total/sec). Чтобы узнать, как интенсивно используется сетевой интерфейс.

• Физический диск — % активности диска (Physical­Disk — % Disk Time — _Total). Чтобы узнать, насколько загружены все физические диски.

• Физический диск — Текущая длина очереди диска (PhysicalDisk — Current Disk Queue Length — _Total). Также покажет, насколько загружены диски.

• Система — % Всего времени процессора (System — % Total Processor Time). Чтобы узнать, как загружены процессоры в целом.

• Система — Длина очереди процессора. Также показывает, насколько загружены процессоры.

• SQLServer: Общая статистика — Пользовательских соединений (SQLServer: General Statistics — User Con­nections). Показывает, как много соединений и пользователей используют сервер. Учтите, что одно соединение не соответствует одному пользователю. Каждый пользователь может иметь более одного соединения и одним соединением могут пользоваться несколько пользователей.

• SQLServer: Методы доступа — Разбиений страницы/сек (SQLServer: Access Methods — Page Splits/sec). Позволяет узнать, произошло разбиение страницы или нет. Если да, то это значит, что необходимо либо увеличить коэффициент заполнения индексов, или перестраивать индексы чаще.

• SQLServer: Диспетчер буфера — Коэффициент попадания в буферный кеш (SQLServer: Buffer Manager — Buffer Cache Hit Ratio). Показывает, достаточно ли памяти имеет сервер. Помните, что этот коэффициент основывается на среднем значении попадания в буферный кеш с момента запуска сервера и не отражает текущее значение попадания в буферный кеш.

• SQLServer: Диспетчер памяти — целевой объем памяти (Target Server Memory)(KB). Показывает, сколько SQL­сервер готов захватить памяти. Если это значение равно значению счетчика SQLServer: Диспетчер памяти — Всего памяти (KB), то я уверен, что SQL Server обладает необходимым количеством памяти.

• SQLServer: Диспетчер памяти — Всего памяти (KB) (SQLServer: Memory Manager — Total Server Me­mory). Показывает количество фактически используемой сервером памяти. Если это значение равно значению счетчика SQLServer: Диспетчер памяти — Необходимо памяти (KB), то я уверен, что SQL Server обладает необходимым количеством памяти. Но если меньше — значит SQL Server нуждается в большем объеме памяти, чтобы выполняться с оптимальной производительностью.

Исходя из моего опыта, я предпочитаю отслеживать данные счетчики постоянно. Если я нахожу что­либо интересное в показаниях счетчиков, то я добавляю дополнительные счетчики, чтобы получить более детальную картину происходящего. Я запускаю монитор производительности на своем настольном компьютере, а не на сервере, мониторинг которого производится для того, чтобы уменьшить нагрузку на SQL Server.

По умолчанию, считывания производятся каждую секунду и менее чем раз в две минуты обновляется график. Мне показался этот временной масштаб не очень удобным, поэтому я изменил его до 36 секунд с ежечасным обновлением экрана активности. Это позволило мне держать руку на пульсе моих критически важных SQL­серверов и, в то же время, не нагружать их непомерно.

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

Когда вы определите нужные вам счетчики, вы можете сохранить их в файл и загрузить позднее, когда это понадобится. Таким образом, вам не нужно заново добавлять счетчики в монитор производительности каждый раз, когда они вам понадобятся. На самом деле, вы можете создать различные наборы счетчиков, под разными именами, чтобы отслеживать различные типы счетчиков одновременно. Более того, каждый тип модели монитора производительности, такой как «Диаграмма» или «Журнал», позволяет вам хранить свой набор счетчиков.

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

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

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