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

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

Увеличит ли переход на 64-разрядную архитектуру производительность моего приложения?

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

Многие сталкиваются с сюрпризами, когда обнаруживают, что в 32­разрядной среде приложения работают быстрее. Предположение о том, что 32­разрядная среда всегда медленнее 64­разрядной, не имеет под собой основания, и фактическая производительность в основном зависит от характеристик конкретной нагрузки и оборудования. Если приложение выполняет большое количество однородных мелких транзакций, использующих относительно простые планы исполнения (то, что называют приложением класса OLTP), и при этом не испытывает недостатка в памяти, то переход на 64­разрядную архитектуру может и не дать прироста производительности на 64-разрядной версии SQL Server.

В чем разница между 32- и 64-разрядными архитектурами?

Существуют фундаментальные различия между 32­ и 64­разрядными процессами, которые в полной мере относятся и к SQL Server. У 64­разрядного процесса SQL Server working set больше как в коде, так и в данных, в основном за счет удвоения размера указателей, 64­разрядных инструкций, структур, которые выравниваются в кеше, и прочего. Это означает, что 64­разрядные приложения более чувствительны к размеру кеша процессора и могут использовать его менее эффективно, чем 32­разрядные приложения, что в результате приводит к более высоким затратам на одну инструкцию. В результате приложения, которые в 32­разрядной среде не испытывают недостатка в памяти (особенно это относится к OLTP­приложениям), могут исполняться медленнее при миграции в 64­разрядную среду на том же самом оборудовании. Нам приходилось сталкиваться с падением производительности на 10­15%, хотя конкретные цифры зависят от характеристик нагрузки и используемого оборудования.

Кто в наибольшей степени выиграет от миграции на 64 разряда?

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

•    Кеш процедур-Большое количество хранимых процедур и динамического SQL (OLTP).

•    Память под рабочий процесс-Большое количество одновременно запрошенных планов с использованием hash join или конструкций group by; массивные сортировки и построение индексов (хранилища данных).

•    Память под соединения-Большое число соединений.

•    Память под потоки-Системы класса OLTP с высокой конкурентностью доступа, сложные планы запросов на многопроцессорных машинах.

•    Память под CLR (GC Heap memory)-Выделение памяти под хранимые процедуры, написанные под CLR.

•    Память под блокировки-Крупные OLTP­приложения.

32­разрядные версии SQL Server позволяют использовать память за пределами 2 или 3 Гб (ограничения 32­разрядного пользовательского виртуального адресного пространства) через посредство Address Windowing Extensions, однако его использование подчиняется ряду ограничений. Так, перечисленные выше компоненты рабочего процесса не могут использовать память, доступную через AWE. Подробности см. ниже.

Что следует учитывать при выборе 32- или 64-разрядной архитектуры?

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

1.  Значительное влияние оказывает архитектура процессора-Используемый процессор вносит свою лепту в дополнительные расходы по исполнению 64­разрядной версии SQL Server на 64­разрядной версии Windows; особенно это зависит от кеша процессора. Процессоры старых моделей с небольшим кешем 2 или 3 уровня, скорее всего, создадут дополнительные расходы при исполнении 64­разрядного кода по сравнению с более современными процессорами, оснащенными большим объемом кеша. Преимущества, которые дает кеш процессора, можно определить только тестированием. Исключением являются процессоры от AMD, которые имеют только кеш 2 уровня, но не оснащены кешем 3 уровня. Архитектура процессоров от AMD сильно отличается от процессоров Intel, и отсутствие кеша 3 уровня может быть нивелировано архитектурой передачи данных между процессором и памятью. Важно отметить, что мы не пытаемся указать на преимущество одного типа процессоров перед другими. Нам доводилось видеть прекрасно работающие приложения на базе SQL Server, исполняющиеся на серверах, оснащенных процессорами обоих производителей.

2.  Задержки памяти-Скорость передачи данных между процессором и памятью оказывает значительное влияние на производительность приложения. При доступе к основной памяти задержки могут давать существенный эффект. Невысокая скорость передачи приводит к более высоким задержкам и большим затратам, если данные не обнаружены в кеше. Более высокая скорость передачи оказывает положительное и часто существенное влияние на производительность приложений, работающих под управлением 64­разрядной версии SQL Server. Сокращение задержек при обращении к памяти — ключевой аспект и важное преимущество серверов, построенных с использованием архитектуры Non­Uniform Memory Access (NUMA).

3.  Обратите внимание на особенности вашего приложения-Если ваше приложение, работающее в 32­разрядной среде не испытывает недостатка по памяти и не имеет требований, перечисленных выше, возможно, вы не получите преимущества от перехода на 64­разрядную среду.

4.  Обратите внимание на неожиданное поведение приложения при тестировании-Нам приходилось видеть несколько случаев, когда приложение демонстрировало неожиданное поведение в результате избавления от ограничений виртуального пространства. На 32­разрядных системах обычно включают AWE, чтобы получить доступ к памяти за пределами 2 или 3 Гб. Однако эта память может быть использована только под кеш данных. Для 64­разрядной версии это ограничение отсутствует, и неотносящаяся к кешу данных зона памяти может вырастать до значений, невозможных в 32­разрядной среде. Это касается областей памяти, используемых под кеш процедур, блокировки, память рабочего процесса и прочее. Хотя в большинстве случаев отсутствие ограничений дает преимущества, существуют сценарии, когда такая свобода создает проблемы:

•   Существенный рост кеша процедур при использовании большого количества не параметризированных SQL­запросов. Выпущенный для SQL Server 2005 Service Pack 2 включает ряд исправлений, призванных снизить влияние подобных проблем, но это не снимает рекомендаций о необходимости параметризации запросов, и оптимизация, реализованная в SP2, не отменяет этого требования.

•   Если администраторы забывают указать верх­ний предел памяти, используемой SQL Server (max server memory), то SQL Server начинает зажимать операционную систему. При работе в 64­разрядной среде рекомендуется ограничивать верхний предел памяти SQL Server и давать бюджету, от которого он исполняется, привилегию Lock pages in memory (для 64­разрядной версии SQL Server эта привилегия работает только для Enterprise Edition). Целью ограничения SQL Server по памяти является резервирование достаточного объема для операционной системы, других приложений, исполняющихся на сервере, и потребностей самого SQL Server, которые удовлетворяются из областей памяти за рамками buffer pool. У SQL Server размер buffer pool меняется динамически и может корректироваться в соответствии с запросами других потребителей, но предварительное конфигурирование всегда считалось правильным подходом. Для систем с большим объемом оперативной памяти ( 16 Гб) считается нормальным оставлять несколько гигабайт под указанные потребности. (См. http://support.microsoft.com/kb/918483 для получения дополнительной информации.)

5.  Не забывайте о долговременных перспективах-Хотя существуют приложения, которые могут исполняться медленнее в 64­разрядной среде, падение обычно невелико (обычно 10% или менее). Важно, чтобы незначительное падение производительности не затеняло долговременные преимущества от перехода на 64­разрядную архитектуру. Использование 64­разрядной среды обработки данных позволяет получить гораздо более высокий уровень масштабируемости по сравнению с 32­разрядной средой и открывает вам основное направление общего развития систем обработки данных. Даже если текущая ситуация не требует использования 64­разрядной архитектуры, это может потребоваться в ближайшем будущем.

6.  Наблюдайте и проверяйте-Мониторинг текущего поведения приложения позволит вам лучше понять тенденции его развития и даст информацию о том, получит ли приложение преимущества от использования 64­разрядной среды. Некоторые индикаторы нехватки памяти, которая может быть устранена переходом на 64­разрядную архитектуру, выглядят так:

•   Высокий объем операций ввода вывода, сопровождающийся низким временем жизни страниц в памяти (page life expectancy) и/или интенсивной работой компонента lazy writer.

•   Постоянное ненулевое значение показателей memory grants pending.

•   Высокая интенсивность создания и удаления временных объектов.

•   Высокое значение показателя stolen pages в процентах от общего объема памяти, потребляемой SQL Server buffer pool.

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

SQL Server: практикум по курсорам

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

Этот практикум по курсорам, в отличие от разного рода руководств, не ставит целью дать всю возможную информацию по теме, но после того, как вы попытаетесь что­нибудь сделать самостоятельно, вам станет гораздо проще разбираться в BOL.

Для чего нужны курсоры?

Курсоры создавались, чтобы преодолеть разрыв между «основанным на записях» традиционным программированием и основанным на множествах миром реляционных баз данных.

У курсоров есть полезное свойство: они позволяют с минимальными затратами времени и усилий переходить от баз данных ISAM или KSAM (таких, как DBase) к SQL Server. Курсоры широко используются DBLIB и ODBC для «обмана» простых источников данных на основе файлов.

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

Осторожно: новые подсказки в запросах в SQL Server 2005

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

Если вы достаточно долго читали мои советы, ответы на вопросы и статьи, то, возможно, заметили, что я не слишком люблю использовать подсказки в запросах. Для новичков в области SQL Server подсказка в запросе (query hint) — это способ заставить оптимизатор запросов SQL Server обработать данный запрос особым способом. Например, с помощью подсказки можно заставить оптимизатор запросов всегда применять указанный индекс или заданный тип объединения или использовать для выполнения запроса только один процессор. Есть множество различных подсказок для разных целей.

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

С другой стороны, если ваш экземпляр SQL Server перегружен или пользователи жалуются на низкую производительность, то придется вам засучить рукава и выяснить, что происходит. Есть множество причин неоптимального поведения запроса, и неоптимизированный план выполнения — лишь одна из них. Так что если в процессе выявления причин низкой производительности вы выяснили, что для какого­то запроса используется неоптимальный план выполнения, то, возможно, решить проблему вам поможет подсказка. Например, пусть оптимизатор запросов всегда использует сканирование таблицы, хотя на таблице создан подходящий индекс. По какой­то причине оптимизатор запросов «не видит» индекса и выдает неоптимальный план запроса. Если у вас как у DBA достаточно опыта, чтобы распознать проблему, вы можете добавить к запросу подсказку, заставив его воспользоваться нужным индексом. Тогда оптимизатор запросов сгенерирует оптимальный план выполнения, что снизит потребление ресурсов SQL Server и увеличит производительность запроса, и вы на коне.

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

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

•    RECOMPILE;

•    OPTIMIZE FOR;

•    USE PLAN;

•    PARAMETERIZATION.

Хранимые процедуры для ведения журнала обновлений независимо от структуры
базы данных

SQL Server: хранимые процедуры для ведения журнала обновлений независимо от структуры базы данных (доработка на скорую руку)

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

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

Maintenance Wizard в SQL 2005. Часть 1

Введение

Есть несколько операций обслуживания баз данных, которые следует выполнять регулярно, чтобы обеспечить хороший уровень производительности и целостность данных в SQL Server. Резервное копирование баз данных, реорганизация файлов данных и индексов, сжатие файлов данных, обновление статистик индексов и проверка непротиворечивости данных — только некоторые из них. Все эти задачи можно выполнить с помощью команд T­SQL. Однако в SQL 2005 есть мастер с графическим интерфейсом (Maintenance Plan Wizard), который значительно упрощает выбор и настройку этих операций. Вдобавок, мастер может составить из выбранных заданий отдельный настраиваемый пакет, который можно использовать снова и снова.

Ранее сохраненные строки могут быть пропущены, если используется опция NOLOCK

Я получил вопрос от одного из наших заказчиков относительно использования опции NOLOCK: не может ли эта опция приводить к потере строк при сканировании даже в том случае, если эти строки были успешно сохранены до того, как началось исполнение команды SELECT с опцией NOLOCK?

Опция NOLOCK применяется многими пользователями с целью избежать возникновения конфликта таблиц в случае одновременного выполнения нескольких обновлений с помощью команд select. Распространено мнение, что единственным побочным эффектом использования опции NOLOCK является то, что ее применение может вызвать чтение несохраненных строк. Это строки, для которых, возможно, был выполнен откат назад, либо они являются частью более крупной параллельной транзакции, в которой какие­то строки, может быть, не были извлечены, потому что не были записаны на страницы к тому моменту, когда команда SELECT с опцией NOLOCK приступила к их сканированию. Гораздо менее очевидно, что при сканировании могли быть пропущены даже те строки, которые были сохранены задолго до начала NOLOCK­транзакции. (После того как я опросил некоторых находящихся рядом со мной SQL Server­экспертов, выяснилось, что никто, за исключением руководителя разработки, которому принадлежал интересующий меня компонент, этого не знал.) Кроме того, теоретически существует сценарий (у меня пока еще нет возможности его воспроизвести; читайте далее), в котором одна и та же запись могла бы быть принята за две, если бы предложение SELECT читало таблицу с опцией NOLOCK.

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

Далее я покажу, как вы можете реализовать такое же преимущество параллельности, которое обеспечивает опция NOLOCK, для сервера SQL Server 2005, не нарушая целостности транзакций и не используя опцию NOLOCK. Затем я разъясню, в каких случаях сканирование таблиц могло бы столкнуться с этой проблемой, а в каких — нет (даже при использовании опции NOLOCK) и как вы можете различить такие случаи сканирования путем исследования планов выполнения (showplans) сканирования. Затем, я ставлю задачу — обеспечить воспроизведение ситуации, которая демонстрирует двойной подсчет ранее сохраненных строк при использовании опции NOLOCK.

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