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

Содержание номера за Декабрь 2007 год

SQL Server

Декабрь 2007
№ 12 (84)

Editorial

Сунил Агарвал Сжатие данных: зачем нам это?

DB Design & Warehousing

Грант Фритчи

Кластерные индексы и первичные ключи

Other

Крис Брюмме

Хостинг. Часть 2

Дайнеш Асанка

Работа с электронной почтой в SQL Server 2005

Марио Брудбаккер

SQL Server ждут перемены: исключаем догадки из процесса профилирования производительности

Сжатие данных: зачем нам это?

Как было объявлено на Tech-Ed 2007, сжатие данных — новая и очень интересная функциональность, заявленная к выходу в новой версии SQL Server 2008. Это слишком значительная тема, чтобы можно было раскрыть ее в одной статье, так что я планирую написать несколько, каждая следующая будет базироваться на материале предыдущей.

Итак, начиная с версии 2008 SQL Server должен поддерживать встроенные средства сжатия данных. Это позволит вам сжать таблицу, или индекс, или секцию таблицы для экономии места на диске. В следующих статьях я рассмотрю более детально технические аспекты этой темы, а сейчас давайте поговорим о том, зачем нам вообще нужно сжатие. Вполне возможно, для тех из вас, кто давно желает иметь эту функциональность в своем распоряжении, вопрос «иметь или не иметь» вообще не стоит, но тем не менее, полезно будет еще раз вернуться к истокам. Давайте обсудим, почему сжатие данных может оказаться необходимым или полезным.

Первая очевидная причина — экономия места на диске. Это может показаться странным, ведь диски сейчас дешевы. Легко найти 100 Гб пространства меньше чем за 100 долларов. О чем же тогда вообще говорить? Во­первых, если вы еще не знаете, диски для систем класса предприятия вовсе не так дешевы. (Например, можно сходить на tpc.org и оценить там стоимость комплекта дисков для тестирования; в сумме только сами диски, 72 Гб 15K Ultra320, легко набирают более миллиона долларов. — Прим. ред.). Во­вторых, редко кто хранит одну копию промышленных данных. Если вы используете такие средства обеспечения отказоустойчивости, как репликация или зеркалирование, у вас появляется как минимум вторая копия данных. А как насчет тестовой среды? Еще одна копия. Все это только увеличивает стоимость оборудования. В­треть­их, резервное копирование. Если вы храните несколько резервных копий вашей базы, то увеличивайте затраты на дисковое пространство еще в несколько раз. Вы можете сказать, что резервные копии можно хранить на менее дорогих носителях, и я соглашусь, но и они чего­то стоят.

Вторая причина — стоимость управления данными. Чем больше база данных, тем дольше длится процесс создания резервной копии, восстановления, дольше исполняются команды DBCC, перестроение индексов, массивное копирование и экспорт данных. Очевидно, что эти команды непосредственно связаны с процедурами ввода/вывода, так что если мы сможем уменьшить размеры файлов данных, все эти задачи будут исполняться быстрее. Интересно отметить, что если ваша база данных сжата, ее резервная копия автоматически будет меньшего размера. Вы можете спросить, как это связано со сжатием резервных копий — еще одним нововведением SQL Server 2008. Так вот, сжатие резервных копий может быть использовано совместно со сжатием данных.

Третья причина — память. Нам всем хотелось бы иметь больше памяти на серверах. Если данные сжаты, мы сможем в тот же объем памяти поместить их больше. Так, сжав данные на 50%, мы вдруг получаем увеличение объема памяти на 100% (удваиваем объем данных, которые можно поместить в имеющуюся память). Не сон ли это? Даже на 64­разрядной архитектуре, поддерживающей большие объемы адресуемой памяти, большинство заказчиков работает с базами, размеры которых на порядки превышают объемы памяти сервера. Так что сжатие оказывается полезным и для серверов старших классов. Очевидно, что операции ввода/вывода будут выполняться быстрее, так как объем данных для чтения также уменьшается.

Надеюсь, что я достаточно заинтриговал вас. Следите за новостями.

Кластерные индексы и первичные ключи

Тестирование производительности SQL Server

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

В компании, где я работаю, сейчас занимаются созданием системы, призванной заменить некоторые устаревшие приложения для мейнфреймов. Разработка ведется на базе Visual Studio. Система будет работать с SQL Server 2000. Новый дизайн базы данных должен соответствовать требованиям как старых, так и довольно многочисленных новых приложений. В мои обязанности входило создание первоначального проекта. Успешно справившись с этой задачей, я передал проект команде разработчиков и некоторое время довольно тесно работал с ними над приложением, но потом мне пришлось переключиться на другие задачи, и разработка базы данных и приложения продолжалась без меня. Однажды разработчики выразили опасение, что база данных функционирует слишком медленно и не справится с предполагаемым объемом нагрузки. И тогда я стал разбираться.

Хостинг. Часть 2*

Политика эскалации

Я выбрал HPA на System.Threading.Monitor по причине, описанной в приведенном выше примере. Если вы читали мои более ранние публикации в блоге о Thread.Abort, то знаете, что асинхронно прерывать выполнение потока опасно. Поток может выполнять конструктор класса, и тогда класс останется недоступным в рамках AppDomain. Также этот поток может находиться в процессе обновления разделяемого состояния приложения, и приложение может остаться в противоречивом состоянии.

В версиях V1 и V1.1 было невозможно написать код, ведущий себя устойчиво в ситуации асинхронных исключений вроде Abort. В Whidbey мы представляем некоторые конструкции (Constrained Execution Regions и Critical Finalization), с которыми это стало возможно. Я не собираюсь обсуждать их в этой публикации, достаточно сказать, что, хотя написание полностью устойчивого кода стало возможным, оно не стало простым. Без программных конструкций высокого уровня, вроде транзакций, очень сложно писать полностью устойчивый код. Вы должны завладеть всеми необходимыми для продвижения при пересылке ресурсами, подавляя возникающие в этой фазе исключения. После этого вы переходите в фазу продвижения при пересылке (forward progress), которая либо не может завершиться неудачей, либо безусловно вызывает при ошибке код, выполняющий откат к исходному состоянию. Если такой код запущен, должен быть гарантирован возврат системы в непротиворечивое состояние.

Если вы знакомы с написанием такого кода, то знаете, что это очень обременительная задача. Мы никак не можем ожидать, что большое число программистов будет писать крупные фрагменты не содержащего ошибок кода, основываясь на этом плане. Поэтому в версиях V1 и V1.1 мы рекомендовали применять Abort либо на текущем потоке (когда эта операция не является асинхронной), либо в связке с AppDomain.Unload (когда любое противоречивое состояние приложения с большой долей вероятности будет сброшено).

В Whidbey стало возможным избегать асинхронных операций Abort на потоках, выполняющих откат к исходному состоянию (то есть с блоками filter, finally, catch или fault) или удерживающих блокировки. У нас в ходу довольно широкое определение блокировки. Оно включает выполнение конструктора класса, поскольку любое выполнение .cctor синхронизируется в соответствии с правилами CLR. Оно также включает Monitor.Enter, Mutex, ReaderWriterLock и т. п. И, наконец, в него входят установленные вручную блокировки, если вы устанавливаете их так, чтобы мы об этом знали.

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

Если мы доверяем этой эвристике, значит, мы можем использовать Abort без последующей выгрузки AppDomain, если данный поток не удерживает никаких блокировок и не выполняет откат. Так случилось, что весь управляемый код, выполняющийся в рамках SQL Server, попадает в множество Safe — которое на удивление не желает устанавливать блокировки, благодаря HPA.

Другими словами, возникновение асинхронного исключения в коде из множества Safe почти никогда не затрагивает другие потоки в том же AppDomain. Это действительно так, даже притом, что этот код написан разработчиками, которые могут не понимать всей глубины связанных с асинхронными исключениями проблем. Это также означает, что если мы поймаем такой поток в тот момент, когда бросать асинхронное исключение без последующей выгрузки AppDomain небезопасно, мы сможем это определить. Когда такой промежуток времени определен, мы можем либо воздержаться от вызова исключения до его завершения, либо выгрузить весь AppDomain, чтобы не оставлять приложение в несогласованном состоянии. Хост может выбрать отложить вызов исключения или выгрузить AppDomain на основе таких критериев, как степень стесненности хоста в ресурсах.

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

Например, SQL Server может заявить, что любая попытка прервать выполнение потока с помощью Abort должна быть отложена, если этот поток удерживает блокировку. Но если задержка превышает 30 секунд, попытка выполнить Abort должна быть расширена до AppDomain.Unload. Разумеется, эта функция шире нужд SQL Server. В самом деле, функцию перезапуска процесса в версии V1 ASP.NET теперь можно рассматривать как частный случай политики эскалации Whidbey.

Заключение

Как обычно, я не смог даже приблизиться к массе интересных тем. Например, явно мало было сказано о том, когда и как выполняется хостинг. Еще я не объяснил, как делаются некоторые простые вещи, вроде выбора между параллельным, непараллельным и серверным сбором мусора. В предшествующем тексте отсутствуют какие­либо конкретные сведения о самих API для хостинга (частично из­за того, что до выхода Whidbey они могут существенно измениться). Кроме того, помимо API для хостинга я не коснулся ни одной из связанных с хостингом тем, таких как соображения по поводу AppDomain. Как вы, наверное, догадались, я также мог бы многое рассказать о безопасности и пространстве имен Security. API для хостинга, например, позволяют хосту использовать защиту, основанную на ролях, и олицетворение пользователей Windows… Ну ладно. К счастью, один из участвующих в проекте Whidbey менеджеров, кажется, пишет книгу, куда войдут основные вопросы хостинга. Предположительно, туда попадут все не раскрытые ранее темы. И, надеюсь, автора не поразит творческий кризис, как это случилось со мной. (На самом деле, конец моему творческому кризису положила простуда жены. Когда ее нет рядом, мои выходные становятся скучны настолько, что я начинаю думать о работе. За этот уикенд я опубликовал в блоге две статьи только потому, что Кэтрин на неделю уехала в Мауи без меня.) Наконец, здесь много говорится о SQL Server.

Надеюсь, вам очевидно, что CLR хочет стать великолепной средой исполнения для самых разных серверов. В версии V1 мы сконцентрировались на ASP.NET. При этом практически без дополнительных усилий был достигнут прогресс с другими серверами. Например, EnterpriseServices поместили нас в свой серверный процесс, просто выбрав серверный режим для нашего сборщика мусора. Для вполне эффективной работы ничего другого не потребовалось. (Вообще­то мы проделали в CLR массу работы, нацеленной на поддержку EnterpriseServices. Но эта работа была связана с моделью программирования и инфраструктурой COM+, а не с архитектурой сервера. Ее пришлось бы проделать независимо от того, загружались бы EnterpriseServices в рабочий процесс ASP.NET или любого другого сервера или работали в своем соб­ственном серверном процессе.)

В Whidbey мы сконцентрировались на расширении CLR с тем, чтобы она удовлетворяла нуждам SQL Server. Но при любой возможности мы обобщали требования SQL Server и старались создать нечто, охватывающее большее число продуктов. Мы надеемся, что так же, как работа над ASP.NET вызвала к жизни большое число базовых сценариев хостинга серверов, работа над SQL Server породит еще больше продвинутых сценариев такого рода.

Если у вас есть «коммерчески значимая» проблема, связанная с хостингом, неважно, на сервере или на клиенте, и вы пытаетесь применить в этой области управляемый код, мне бы хотелось ознакомиться с вашим опытом. Пришлите мне по электронной почте описание того, чего вы пытаетесь достигнуть, и я попытаюсь вам помочь. Конечно, моя поддержка может заключаться всего лишь в соображениях о том, как бы я сам попытался решить данную проблему. Однако я могу удариться в другую крайность и предложить более формальную поддержку и, возможно, кое­какую ограниченную доработку функций. Это зависит от коммерческого значения вашего продукта и того, насколько совпадают наши бизнес­интересы. Разумеется, не в моей компетенции принимать такие решения, но я могу, по крайней мере, свести вас с нужными людьми.

*См. Крис Брюмме. Хостинг. Часть 1 // SQL Server для профессионалов. 2007. № 11.

Работа с электронной почтой в SQL Server 2005

Отправка электронной почты — важная часть любой системы, где требуется рассылка оповещений. В SQL Server есть встроенная почтовая система. С выходом SQL Server 2005 появилась функциональность Database Mail, отличающаяся от SQL Mail в SQL Server 2000.

В этой статье я хотел бы представить вам Database Mail и подчеркнуть ее преимущества над более старой SQL Mail.

Проблемы с SQL Mail

Если вы работали с SQL Mail в SQL Server 2000, то вам знакомы ее недостатки. Лично я не слишком часто пользовался SQL Mail из­за сложностей в реализации. Инсталляции Outlook, профили Messaging Application Pro­gram­ming Interface (MAPI), коннектор Simple Mail Trans­fer Protocol (SMTP) сторонних производителей и расширенные хранимые процедуры — все это требуется для работы с SQL Mail. Но еще важнее то, что SQL Mail отрицательно сказывается на производительно­сти SQL Server.

Самые распространенные проблемы с SQL Mail вы можете найти в статье KB 315886 (315886 INF: Com­mon SQL Mail Problems. Документация SQL Server 2005). Из­за этих проблем пользователи были вынуждены искать другие средства отправки почты с SQL Ser­ver, такие как хранимые процедуры с CDO.

Особенности Database Mail

Перед подробным описанием настройки функциональности Database Mail стоит рассказать о ее основных особенностях.

•     Database Mail можно сконфигурировать для работы с несколькими профилями и несколькими учетными записями SMTP на нескольких SMTP­серверах. В случае отказа одного SMTP­сервера отправка почты перепоручается следующему доступному серверу. Это увеличивает надежность почтовой системы.

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

•     Работу с почтой осуществляет внешний процесс, поэтому не падает производительность базы данных. Этот процесс соответствует исполняемому файлу DatabaseMail90.Exe, расположенному в каталоге MSSQL\Binn.

•     Одним из основных улучшений в Database Mail является возможность аудита. Раньше администраторы не могли проверить, отправлено ли почтовое сообщение. Теперь все связанные с электронной почтой события заносятся в журнал, так что DBA может с легкостью просмотреть историю. Вдобавок можно посмотреть описания возникших ошибок, что очень полезно при устранении проблем SMTP. Плюс ко всему появилась возможность отправки сообщений в формате HTML.

•     Database Mail может ограничивать размер файлов во вложении, чтобы отправка слишком больших файлов не снижала производительность почтового сервера. Вдобавок, у вас есть возможность ограничить отправку файлов в зависимости от их расширений, например запретить отправку файлов .exe и .com с сервера баз данных.

SQL Server ждут перемены: исключаем догадки из процесса профилирования производительности

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

Несмотря на то что DMV позволяют получить статистику только на уровне сервера (и иногда базы данных), это очень полезные инструменты для профилирования и диагностики производительности. Другой интересный сценарий — это параллельные запросы, где множественные контексты выполнения работают в рамках одного SPID или сеанса в SS2005. В этом случае вы не можете просто сложить все время ожидания и работы процессора и сопоставить полученное значение со временем реакции, но можете суммировать значения времени на уровне контекста выполнения.

В следующей статье я приведу еще несколько примеров работы с событиями ожидания и расскажу, как их интерпретировать. Это будет относиться и к SQL Server 2000, и к SQL Server 2005.

Ссылки

События ожидания

•     Команда Microsoft SQL Server Development Cus­to­mer Advisory Team: http://blogs.msdn.com/sqlcat/de­fault.aspx.

•     К сожалению, Герт Дрэперс (Gert Drapers) и Том Дэвидсон (Tom Davidson), которые писали о событиях ожидания, перешли в другие команды. У Герта на его сайте есть презентации на эту тему: http://www.sqldev.net/.

•     Вот также очень хорошая презентация, где описано большое число событий ожидания SQL Server 2005: http://www.microsoft.com/technet/prod­technol/sql/2005/tsprfprb.mspx.

SQLOS

Блог Славы Окса (Slava Oks) (где я только что прочитал, что он тоже ушел в другую команду!): http://blogs.msdn.com/slavao/.

У Славы есть несколько очень хороших статей на тему SQLOS, где рассматривается, в основном, управление памятью, но упоминается также планировщик. Кроме того, он написал замечательную главу в новой книге под редакцией Кена Хендерсона (Ken Henderson) «SQL Server 2005 Practical Troubleshooting». В этой же книге есть прекрасная глава о SQLOS и проблемах диспетчеризации, написанная Самиром Теджани (Sameer Tejani), и глава «Waiting and blocking issues» Сантери Воутилайнена (Santeri Voutilainen).

Помимо этого, Кен Хендерсон написал «The Guru’s Guide to SQL Server: Architecture and Internals». На мой взгляд, это несколько странная книга, из которой, как мне кажется, должны были получиться две книги. Первая половина на очень хорошем уровне рассказывает о внутреннем устройстве SQL Server 2000, зато вторая довольно поверхностно пробегает по самым разным темам. Некоторые главы этой книги доступны в MSDN. Я с нетерпением жду издания по SQL Server 2005.

IOMeter

IOMeter — это инструмент для измерения и стрессового тестирования характеристик ввода­вывода, разработанный Intel. Теперь это программа с открытым исходным кодом, которую можно загрузить с сайта http://www.iometer.org/.

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