(Возврат на основную страницу)
Мониторинг кольцевых буферов с помощью XML
Билл Вундер (Bill Wunder)
Принципы резервирования ядром SQL Server пространства VAS
(область MemToLeave)
Джонатан Кехайяс (Jonathan Kehayias)
Что изменилось?
Билл Вундер (Bill Wunder)
Сниффинг параметров
Грэг Ларсен (Greg Larsen)
Если запрос SQL имеет параметры, SQL Server создает план выполнения,
адаптированный к ним, для увеличения производительности посредством процесса,
называемого «сниффинг параметров». План сохраняется и используется повторно по
той причине, что это, как правило, наилучший план выполнения. Лишь иногда это не
так, и вы можете столкнуться с проблемами производительности, как объясняет Грэг
Ларсен.
SQL Server старается оптимизировать выполнение ваших хранимых процедур, создавая
скомпилированные планы выполнения. Такой план для хранимой процедуры создается
при ее первом выполнении. Когда движок базы данных SQL Server компилирует
хранимую процедуру, он просматривает значения полученных параметров и создает на
их основе план выполнения. Процесс поиска значений параметров во время
компиляции хранимой процедуры часто называют «сниффингом параметров» (parameter
sniffing). Сниффинг параметров иногда может привести к неэффективному плану;
особенно, когда хранимая процедура вызывается с кардинально отличающимися
значениями параметров. В этой статье я объясню, что такое сниффинг параметров и
затем покажу различные способы решения проблем, связанных с производительностью,
которые могут быть связаны с этим процессом.
Что такое сниффинг параметров?
Я уверен, что
слово «сниффинг» все воспринимают несколько иначе, чем то, что оно обозначает на
самом деле. Сниффинг параметров — это процесс, в ходе которого SQL Server
создает для хранимой процедуры оптимальный план с использованием переданных
параметров при первом выполнении хранимой процедуры. Под «первым выполнением»
стоит понимать ситуацию, когда SQL Server вынужден проводить компиляцию хранимой
процедуры, не находящейся в кеше. Каждый последующий вызов той же процедуры с
теми же параметрами так же будет выполняться по оптимальному плану, тогда как ее
вызов с другими значениями параметров может быть выполнен не по оптимальному
плану. (Единожды создан, план фиксируется, и изменение параметров вызова не
приводит к созданию нового плана исполнения, — прим. ред.).
Не все планы выполнения создаются идентично. Планы выполнения оптимизируются на
основе того, что они должны выполнить. Движок SQL Server просматривает запрос и
определяет оптимальную стратегию его выполнения. Он смотрит на то, что делает
запрос, использует параметры для получения статистики, выполняет некоторые
вычисления и, в конечном счете, принимает решение о том, какие шаги требуются
для выполнения запроса. Это упрощенное объяснение того, как создается план
выполнения. Важным моментом для нас является то, какие переданные параметры
используются для определения того, как SQL Server будет выполнять запрос.
Оптимальный план выполнения для одного набора параметров может быть операцией
сканирования индекса (index scan), в то время как другой набор может лучше
подходить выполнению операции поиска по индексу (index seek).
PowerShell версия 2: что нового и почему это важно?
Джонатан Мэдд (Jonathan Medd)
Прошел год с того момента, как компания Microsoft представила PowerShell 2.
Джонатан Мэдд перечислил десять основных причин, почему PowerShell 2 должна быть
важным инструментом в вашей работе.
22-го октября 2009 года Microsoft выпустила Windows Server 2008 R2 и Windows 7;
PowerShell версии 2.0 была включена в этот релиз. Первая версия PowerShell была
представлена несколькими годами ранее в Барселоне на ITForum в ноябре 2006 года.
Так что же изменилось за эти три прошедших года, как развивался продукт и почему
это должно интересовать рядовых системных администраторов и администраторов баз
данных?
В этой статье я
раскрою десять наиболее важных причин того, почему это важно для вас, независимо
от того, интересовала вас Windows PowerShell ранее или нет.
fn_fixeddrives(): альтернатива для xp_fixeddrives
Дэвид Баффало (David Baffaleuf)
Вы никогда не расстраивались тем, что видели на выходе xp_fixeddrives? Ощущение
можно описать фразой «черт возьми, как жаль, что нельзя получить полный объем
каждого диска с помощью этой расширенной хранимой процедуры для расчета того,
какой объем использован». Теперь, когда у вас есть SQLCLR в SQL Server 2005 и
его более поздние версии, оправданий быть не может. В этой статье мы обсудим
способ отображения характеристик приводов сервера с помощью табличной функции
SQLCLR.
Определение положения аргументов поиска в соединении
Кимберли Л. Трипп (Kimberly L. Tripp)
При написании запроса с соединением я всегда удивляюсь тому, как можно увеличить
производительность перемещением аргумента поиска в выражение JOIN вместо того,
чтобы оставить его в секции WHERE. Листинг 1 показывает пример, когда аргумент
поиска находится в выражении WHERE, а Листинг 2 демонстрирует его размещение в
выражении JOIN. Какой эффект будет иметь это изменение, на самом ли деле это
выгодно?
В случае
выражения WHERE аргументы поиска применяются ко всем записям в конечной выборке.
В INNER JOIN положение аргументов поиска не влияет на конечную выборку по той
причине, что INNER JOIN требует того, чтобы все записи имели совпадение во всех
соединенных таблицах, а так же все записи должны удовлетворять условиям
аргумента в выражении WHERE. Это важный момент, так как если выполняется запрос
с внешним соединением OUTER JOIN, конечная выборка будет отличаться в
зависимости от положения аргумента поиска. Подробней я объясню это позже.
(Возврат на основную страницу)