(Возврат на основную страницу)
Питер Гэлли (Peter Galli) и Мэтт Хикс (Matt Hicks)
Microsoft готовится к выходу новой версии SQL Server под кодовым именем Yukon, органично вписывающегося в ее концепцию вместе с .Net, Web-сервисами и новыми технологиями унификации и интеграции данных.
Microsoft планирует внедрить в механизм SQL общую систему поддержки времени выполнения (Common Language Runtime, CLR) из .Net, а также предоставить углубленную и более богатую поддержку XML.
Как заявил директор SQL Server Стэн Соренсен (Stan Sorensen) на конференции TechEd, после интеграции CLR в SQL Server разработчики получат возможность писать хранимые процедуры, помимо Microsoft T-SQL, дополнительно на 23 языках.
Однако, по отзывам ИТ-функционеров, они более заинтересованы в новых возможностях, связанных с повышением масштабируемости и надежности. Как было заявлено, наряду с активно продвигаемыми Microsoft улучшениями в сфере разработки приложений для SQL Server, им бы хотелось также увидеть больше улучшений в ключевых областях обработки БД.
«Хотелось бы узнать, какая работа была проделана по улучшению механизмов обработки БД, а не ее интерфейса, — отметил Дэррел Стернс (Darrell Starnes), заместитель директора по связям с общественностью Ashford.com отделения компании Global Sports Interactive, Inc, расположенного в Хьюстоне, — в настоящее время наше пристальное внимание обращено на масштабируемость и надежность, службы кластеров, средства восстановления после сбоев и репликацию».
По утверждениям официальных лиц, Yukon должен выйти в следующем году, а его бета-версия — уже в конце этого года.
«С поддержкой CLR <…> будет достигнута симметрия между БД и средой программирования на промежуточном уровне, — сказал Пол Флесснер (Paul Flessner), старший вице-президент группы, ответственной за разработку промышленных серверов .Net, — теперь разработчик может решать, где будет исполнен его код, во время выполнения, а не во время разработки, основываясь на быстродействии и масштабируемости».
Yukon также будет поддерживать улучшенную технологию хранения и извлечения всех видов данных в формате XML (внутреннее название этой технологии — Storage+). В Yukon поддержка XML будет встроена в механизм SQL Server вместе с поддержкой XQuery — стандартного языка запросов, предлагаемого для документов XML.
Общеизвестная корпорация со штаб-квартирой
в Редмонде (штат Вашингтон) не планирует непосред-
ственно интегрировать SQL Server в другие свои программные продукты. Однако есть
планы по постепенной интеграции в другие программные продукты унификации данных
и ряда других технологий, которые должны войти в состав Yukon.
«Мы не собираемся разбрасывать все свои достижения, воплощенные в SQL Server, по другим програм-мным продуктам», — заявил Соренсен. К этому он добавил, что текущей задачей является реализация возможности поиска как структурированных, так и неструктурированных данных в реляционных БД, файловой системе или почтовых базах.
Однако ни в одном из анонсов о Yukon до сих пор ничего не сказано о тех областях, в которых SQL Server отстает от конкурентов, например о недостаточной (по сравнению с конкурирующими продуктами от Oracle Corp.) функциональности кластерной среды БД.
Стэрнс из Ashford.com заявил, что дополнительная функциональность кластеров в Yukon станет стимулом к переходу с SQL Server 7.0 в его компании.
Ли Маргулин (Lee Margulin), начальник отдела администрирования БД в компании MGM Mirage (Лас-Вегас) сказал, что, несмотря на существенное улучшение функциональности кластеров в SQL Server 2000, ему, как и Стэрнсу, были бы весьма кстати возможности балансировки, встроенные в SQL Server, которые облегчили бы одновременное управление несколькими серверами.
«В SQL Server 2000 им удалось улучшить аспекты работы кластеров, составлявшие большую проблему в SQL Server 7.0. — сказал Маргулин. — мы сталкивались с ситуациями, в которых оптимальным решением было передать обслуживание одной БД нескольким серверам, балансируя нагрузку между ними. В настоящее время подобная задача заставляет администратора БД изрядно попотеть».
Соренсен из Microsoft заявил, что в Yukon была улу-чшена поддержка кластеров, а также сделаны улучшения в других проблемных областях, таких как восстановление после аварий, но, по его словам, говорить о деталях пока еще слишком рано.
Брайан Найт (Brian Knight)
В этой статье будет показано, как расширить возможности хранимых процедур sp_msforeachtable и sp_msforeachdb, распространив их на другие объекты SQL Server.
В SQL Server 6.x Microsoft ввела в употребление хранимые процедуры sp_msforeachtable и sp_msforeachdb. Они позволяют администратору БД обрабатывать в цикле каждую таблицу или БД, выполняя над объектами определенные действия. Однако, у этих мощных процедур есть недостаток — они не работают с другими объектами.
Сначала мы кратко поговорим о том, как эти процедуры работают в современных версиях SQL Server, а потом разберем, как заставить их делать то, что нам нужно, с другими объектами. В новых процедурах операции, для которых раньше пришлось бы писать сложный курсор, выполняются при помощи одной-единственной строки кода.
Леон Платт (Leon Platt)
В этой статье рассказывается, как избежать
падения производительности при выполнении динамических запросов.
Данная проблема постоянно возникает при создании хранимых процедур, принимающих несколько параметров в разделе WHERE. Фактически она состоит из двух частей. Первая — узнать, какие параметры следует включить в раздел WHERE; вторая — заставить SQL Server кэшировать план выполнения хранимой процедуры.
Брэд МакГи (Brad M. McGehee)
Эта статья открывает серию статей, публикация которых будет продолжаться в течение следующих нескольких месяцев.
Если вы достаточно долго были администратором БД, то должны знать, что оптимизация производительности SQL Server не похожа на точную науку, а если бы и была похожа, то все равно было бы трудно найти «оптимальную» конфигурацию, дающую «оптимальную» производительность. Основное препятствие в том, что в оптимизации производительности почти нет абсолютных ориентиров. Например, один и тот же прием может повысить производительность, если оценивать ее по одним параметрам, и в то же время снизить, если брать за основу другие параметры.
За последние пять лет, проведенных в должности администратора БД SQL Server, я составил собственный список мероприятий по оптимизации производительности. Этим списком я пользуюсь как руководством, когда первый раз провожу «аудит производительности» нового (для меня) экземпляра SQL Server. Меня часто просят «посмотреть» какой-нибудь сервер и посоветовать, как можно повысить его производительность. До сих пор я никогда не пытался описать на бумаге все свои шаги при оптимизации производительности SQL Server. Но так как мне приходится все больше и больше консультировать по поводу оптимизации производительности, я решил, что уже пора… Надеюсь, это и для вас окажется не менее полезным.
Рэнди Дайесс (Randy Dyess)
С ростом вашего мастерства разработчика на языке Transact-SQL или администратора БД SQL Server придет время, когда вам потребуется отказаться от тех блокировок, которые SQL Server использует по умолчанию, и принудительно установить на таблице набор собственных блокировок.
Для этих целей Transact-SQL предоставляет набор указаний блокировки на уровне таблицы (table hint). Применяя их вместе с операторами SELECT, INSERT, UPDATE и DELETE, можно указать SQL Server, какие блокировки установить. При этом указания заменяют любые блокировки, установленные на другом уровне (общесистемном или на уровне изоляции транзакций).
В этой статье рассказывается об
использовании указаний блокировки на уровне таблицы, а также приводится описание
общих табличных указаний, доступных разработчикам на Transact-SQL и админи-
страторам БД SQL Server. Мы также попытаемся рассмотреть ситуации, в которых
следует использовать те или иные указания. Помните, что оптимизатор запросов SQL
Server автоматически определяет лучший, на его взгляд, тип блокировки для
объекта или запроса, и изменять выбранные им блокировки нужно только при
необходимости.
Следует отметить, что время от времени исправлять результаты оптимизатора все же приходится. В этих случаях администратор или разработчик при помощи указаний принуждает SQL Server к использованию индекса, отличного от выбранного оптимизатором, или просто управляет использованием блокировок. Например, следует выбрать другой индекс, если оптимизатор запросов постоянно выбирает индекс, который все время содержит неактуальные данные, и нет ресурсов на приведение индекса в актуальное состояние перед запуском запроса. Управление блокировками необходимо и для блокирования таблицы с целью оптимизации работы оператора BULK INSERT.
(Возврат на основную страницу)