(Возврат на основную страницу)
Распространенные мифы о SQL Server. Часть 8
Пол С. Рендал (Paul S. Randal)
Расширение CHARINDEX для поиска конкретного вхождения строки
Парта Пал (Partha Pal)
Анализ привилегий роли Db_DataReader
Ник автора - Hawkeye_DBA
Выбор индексов и оптимизатор запросов
Бенджамин Неварез (Benjamin Nevarez)
В защиту репликации транзакций как технологии с высоким
уровнем надежности
Пол Рендалл (Paul Randall)
Методы преобразования хранимой процедуры
Эли Лейба
Распространенные мифы о SQL Server. Часть 8
Пол С. Рендал (Paul S. Randal)
Читайте первую, вторую и третью части статьи в журналах за ноябрь, декабрь 2010
года и за январь, февраль, март, апрель, май 2011 года.
Расширение CHARINDEX для поиска конкретного вхождения строки
Парта Пал (Partha Pal)
Часто
при работе со строками, нам приходится пользоваться функцией CHARINDEX для
поиска вхождения строки. Однако, в некоторых случаях, нам необходимо найти
первое вхождение искомой комбинации символов, или второе… В этой ситуации
требуется писать довольно большое количество кода.
Для устранения ограничений, присущих CHARINDEX я написал пользовательскую
функцию, основанную на двух наиболее часто используемых строковых функциях TSQL:
CHARINDEX и SUBSTRING.
Анализ привилегий роли Db_DataReader
Ник автора - Hawkeye_DBA
Код предназначен для поиска ролей db_dbreader, имеющих иные чем Select или Connect привилегии в каждой БД
Выбор индексов и оптимизатор запросов
Бенджамин Неварез (Benjamin Nevarez)
В то
время, как всем известно, что Оптимизатор Запросов использует Индексы для
составления более оптимальных планов выполнения, не все знают какие конкретно
индексы дадут наилучшие результаты. Бенджамин Неварез провел исследования и в
этой выборке выдержке из его будущей книги «Inside the SQL Server Query
Optimizer» он поможет нам разобраться в том, как оптимизатор запросов выбирает
индексы для улучшения планов выполнения. (В статье постоянно идут ссылки на
"главы" и пр. разделы. речь идет о главах упомянутой книги. прим. ред.)
Выбор индекса это одна из наиболее важных методик, используемых в оптимизации
запросов. Используя правильные индексы, SQL Server может увеличить скорость
ваших запросов и существенно улучшить производительность ваших приложений. В
этой статье я покажу вам, как SQL Server выбирает индексы, как вы можете
использовать понимание этого процесса для получения более подходящих индексов и
как проверить ваши планы выполнения, чтобы убедиться в правильном использовании
этих индексов.
Кроме того, статья содержит разделы, посвященные помощнику по настройке ядра
СУБД и функционалу отсутствующих индексов, которые покажут, как вы можете
использовать оптимизатор запросов для соблюдения рекомендаций по настройке
индексов. Однако важно отметить, что независимо от того, какие рекомендации дают
эти инструменты, при анализе своих собственных индексов последнее слово остается
за администратором баз данных или разработчиком и именно они принимают
окончательное решение каких рекомендаций стоит придерживаться. Так же, поскольку
мы будем изучать эти инструменты в основном с точки зрения оптимизатора
запросов, ознакомьтесь с более подробной информацией относительно этих функций в
Books Online.
В защиту репликации транзакций как технологии с высоким
уровнем надежности
Пол Рендалл (Paul Randall)
Вчера
в Твиттере несколько человек выразили недовольство слайдами конференции,
характеризующими репликацию транзакций как технологию с высоким уровнем
надежности. Я возражал и аргументировал свою позицию. Думаю, тема заслуживает
отдельной статьи в блоге. Это спорная точка зрения и я готов к встречным
комментариям – пожалуйста, высказывайтесь!
Я преподаю высокую надежность в самой Microsoft и на уровне MCM и всегда без
исключений утверждаю, что репликация транзакций и ее более продвинутая версия –
одноранговая репликация позиционируются как высоко-надежные. В двух статьях на
тему высокой надежности, написанных для Microsoft за последние два года,
репликация транзакций так же обсуждаются как высоко-надежная технология (ссылка
ниже).
Для начала, давайте определимся с понятием высоко-надежной технологии. Это
технология, которая обеспечивает более высокую надежность данных в аварийной
ситуации. Это определение не характеризует предполагает никаких ограничений на
число потерь данных или величину простоя – и таким образом некорректнои
накладывать такие ограничения было бы некорректно.
Для справки, многие, стремясь к высокой надежности, идут неверным путем – или
подстраивая новую стратегию под неподходящую технологию, или просто выбирая
технологию, о которой где-то услышали – обычно это отказоустойчивая
кластеризация. Планирование высоко-надежной стратегии подразумевает аккуратное
определение организационных требований, учет технических и нетехнических
ограничений, достижение компромисса между технологами и менеджерами и лишь ПОСЛЕ
этого начало разработки технологии. Как только начинается ее разработка,
обнаруживается, что нет единой высоко-надежной технологии, которую SQL Server
обеспечит в духе «все в одном» - все имеют свои ЗА и ПРОТИВ. Конечная стратегия
обычно объединяет множество технологий для удовлетворения ее потребностей.
Подробно о моей методике планирования высокой надежности можно прочесть в
статье, написанной для Microsoft год назад «Высокая надежность в SQL Server
2008» (High Availability with SQL Server 2008). Помимо прочего в ней содержится
хороший обзор репликации транзакций и одноранговой репликации.
Далее приведу семь основных аргументов, услышанных мною против репликации
транзакций как высоко-надежной технологии – рассмотрим их по очереди.
Методы преобразования хранимой процедуры
Эли Лейба
Целью
этой статьи является рассказ о технических средствах, с помощью которых
программист может сочетать выполнение хранимой процедуры изнутри инструкции
SELECT с возвратом результирующей выборки этой процедуры и обычное выполнение
хранимой процедуры посредством инструкции exec.
Помимо этого статья рассказывает о способах загрузки результатов процедуры во
временную таблицу с помощью другой хранимой процедуры, которая создает и
удерживает в памяти эту таблицу до тех пор, пока приложение не удалит ее. Я
использовал функцию OPENROWSET с именем хранимой процедуры в качестве параметра
функции.
OPENROWSET это специальная функция, используемая для прямых (ad-hoc) запросов в
другом соединении. На вход OPENROWSET подается другой запрос, объект имя объекта
или хранимая хранимой процедурапроцедуры. В этой статье я пользуюсь этой
функцией при подключении к тому же источнику SQL Server, но в качестве
параметра, определяющего источник данных, на вход подается хранимая процедура, с
целью получить результат в запросе, а не в предложении exec.
(Возврат на основную страницу)