(Возврат на основную страницу)
Тема настройки производительности близка и дорога мне. Как консультанту, мне нравится помогать заказчикам решать сложные (и иногда простые) проблемы и выжимать максимальную производительность из SQL Server. Кроме того, это так захватывающе интересно, когда за счет корректировки индексов удается сократить время исполнения запроса с 2–3 часов до нескольких минут или даже секунд.
Одним из способов поиска нужного набора индексов является использование Мастера SQL Server Index Tuning Wizard. Однако начинающие разработчики часто склонны полностью полагаться на этот инструмент, а это может оказаться опасным.
Мастер способен быстро проанализировать данную нагрузку, выраженную в форме набора T-SQL-запросов, а затем может предложить индекс или индексы, которые, по мнению оптимизатора запросов, способны повысить скорость исполнения. Проблема в том, что Index Tuning Wizard отличается известной ненадежностью в смысле определения всех возможных индексов (иногда включая довольно очевидные), способных повысить скорость исполнения запросов. Подбор индексов для сложной БД — это непростая задача, и я просто не ожидаю от Мастера идеальной работы. Поэтому, вместо того чтобы полностью полагаться на Мастер, я часто использую его в качестве средства быстрого тестирования того, будет ли запрос исполняться быстрее, если я добавлю новый индекс. По собственному опыту могу сказать, что Мастер редко предлагает плохие индексы. Однако я никогда не посчитаю, что запрос проиндексирован идеально, если Мастер не предлагает никаких изменений.
Я вовсе не отказываюсь решить проблему за 10 секунд вместо того, чтобы тратить на нее минуты или часы, и вы можете недоумевать, зачем я вообще завел об этом речь, если Мастер действительно помогает в некоторых ситуациях. Причина в том, что слишком многие заказчики, особенно начинающие, пола- гаются на решение Мастера, как на истину в последней инстанции, когда анализируют выбранную схему индексирования. Мне не раз приходилось слышать (или читать в переписке): “Мои индексы не нуждаются в корректировке, потому что Мастер не предлагает изменений”.
Обычно я предупреждаю администраторов БД, что Мастер не всегда гарантирует идеальное решение. Однако я полагаю, что и Microsoft следует повесить некоторый предупредительный знак. Проблема в том, что большинство Мастеров (если не все) вполне качественно справляется со своими обязанностями. Например, я не стану подвергать сомнению, что все мои резервные копии будут созданы, если я воспользовался услугами Database Maintenance Wizard. Кроме того, новички особенно склонны как можно чаще прибегать к услугам Мастеров и просто могут не знать, что, в отличие от других, этот Мастер не всегда способен помочь найти недостающие индексы.
Несомненно, Index Tuning Wizard — полезная штука, которую вы можете использовать для облегчения своей работы. Я уверен, что аналогичный инструмент в составе Yukon будет еще лучше. Но SQL Server должен быть снабжен четким указанием, что для получения оптимального набора индексов вам нужно нечто большее, чем Index Tuning Wizard.
DB Design & Warehousing
Десять подсказок по лучшим приемам работы с T-SQL
Рон Тэлмэйдж (Ron Talmage)
Есть надежда, что этой статьей Рон Тэлмэйдж сподвигнет сообщество на возобновление усилий по установлению стандартов языка T-SQL. Возможно, что читатели, являющиеся профессионалами по SQL Server, воспользуются этим случаем и пришлют Рону свои предложения.
Большинство солидных организаций сферы информационных технологий имеет развитую практику и стандарты для разработки ПО клиентского и промежуточного слоя. Но это не распространяется на T-SQL или программирование хранимых процедур. Полагаю, в этом нет ничего удивительного, поскольку, по сути, в литературе по SQL Server не существует какого-либо детализированного предписывающего стандарта по стилю и правилам этого языка. В последнее время меня все больше поражает, как часто при написании кода для SQL Server обычно очень аккуратные разработчики отходят от стандартов и соглашений. Даже если правила относятся только к вопросу стиля, очень важно использовать согласованный с другими разработчиками проекта стиль. Итак, с чего нам стоит начать? Предлагаю начать с операторов T-SQL, относящихся к определению данных (CREATE и DROP) и управлению данных (SELECT, INSERT, UPDATE и DELETE). О них мы и поговорим в этой статье.
Рон Тэлмэйдж (Ron Talmage)
Приготовьтесь получить еще
одну порцию практических советов от профессионала.
На этот раз это 15 ясно сформулированных «правил» от Рона Тэлмэйджа, которые
призваны помочь вам создавать более качественные хранимые процедуры. И не
удивляйтесь,
если обнаружите, что нарушаете некоторые из этих аксиом.
Я собираюсь продолжить нашу беседу о лучших приемах работы с SQL Server, остановившись на работе с хранимыми процедурами. Многое из описанного в статье применимо также для триггеров и функций, но, если вы похожи на большинство разработчиков, имеющих дело с SQL Server, то чаще создаете коды хранимых процедур, чем коды для триггеров или функций. На случай, если вас удивляет моя методика, поясняю, что выбрал эти правила потому, что часто вижу, как именно они нарушаются.
Programming
Генерация сценария создания хранимых процедур в порядке зависимости
Робби Д. Моррис (Robbe D. Morris)
Вы облазили MSDN, Google Groups и все закоулки web-сайтов разработчиков в поисках способа создания сценария SQL для ваших хранимых процедур в порядке зависимости, но безуспешно.
Вы, как и я, предпочитаете не видеть пачки сообщений об ошибках при использовании собственных хранимых процедур в Query Analyzer в среде контроля качества (QA, quality assurance) или в производственной среде. Мне не нравится бродить по списку этих сообщений, выискивая действительную причину ошибки, только потому, что я забыл что-то при развертывании процедуры. Итак, вы не справились с этой задачей, но, вероятно, я смогу помочь вам в этом.
Некоторое время назад я обнаружил, что зависимости для хранимых процедур не всегда точны. Это связано с тем, что таблица sysdepends не всегда имеет правильные ключи, связывающие объекты БД. Поэтому я решил попытаться создать сценарий, проверяющий фактический исходный код каждой процедуры в БД, чтобы выяснить, ссылается ли на нее одна или несколько процедур. Если да, то она помечается с тем, чтобы могла быть сгенерирована первой. Я реализовал счетчик, призванный следить за числом экземпляров каждой процедуры, вызываемой другими процедурами. Чем больше его значение, тем вероятнее необходимость генерировать данную процедуру раньше других. Полагаю, что это не идеальный способ, но тестирование на нескольких БД с зависимыми хранимыми процедурами показало, что мой метод справлялся с большинством ситуаций.
Есть небольшой изъян, не создающий проблем, но способный значительно увеличить размеры SQL-сценария. Если код источника этой хранимой процедуры превышает максимально допустимое количество байтов в таблице syscomments, SQL Server разделит код источника на несколько записей и будет использовать sp_helptext для обратного соединения кода в длинную строку. Хранимые процедуры, попадающие в эту категорию, генерируются с помощью моего сценария несколько раз. Чтобы этот пример был прост для понимания, я не реализовал в нем никаких проверок, позволяющих определить, выполнялась ли уже процедура. Оставим все, как есть, просто удаляя и создавая эти процедуры большее число раз, чем это на самом деле необходимо.
Играем в ODS. Часть 1
Пол Сторер-Мартин (Paul Storer-Martin)
В первой части этой
статьи Пол Сторер-Мартин описывает основной цикл разработки и API, вовлеченных в
создание расширенных хранимых процедур с помощью ODS
(Open Data Services).
Во второй части он продолжит
это обсуждение, проверяя возможность написания расширенных хранимых процедур в
качестве управляемых сборок (managed assembly) в SQL Server 7.0 и 2000.
Полученные результаты ошеломляют, поскольку это, по существу, распространяет
понятие расширенных хранимых процедур в область всей инфраструктуры классов
.NET и индивидуальных компонентов, написанных на любом из языков .NET.
Исторически ODS использовались либо для создания расширенных хранимых процедур, либо как шлюзовое приложение (gateway application), позволяющее службам, не входящим в SQL Server, иметь его «фасад», что дает возможность доступа к гетерогенным средам через API доступа к данным SQL Server. Подобная шлюзовая функциональность в настоящее время отошла в историю, главным образом, вследствие роста альтернативных технологий, таких как связанные серверы (linked server) и возможности распределенных запросов. В результате большинство ODS API используются сегодня только для того, чтобы обеспечить обратную совместимость1 . Другими словами, вам не придется изучать множество API для того, чтобы писать собственные хранимые процедуры.
Линчи Шиа (Linchi Shea)
Просмотр журналов errorlog, выходных данных DBCC и файлов журналов запланированных заданий едва ли занимают первые места вашего рейтинга любимых способов проводить время, но добросовестный администратор БД не может обойтись без этой утомительной и скучной ежедневной рутины. В этой практической статье Линчи Шиа описывает сценарий на Perl, сводящий все эти файлы журналов в единый настраиваемый итоговый отчет.
Ежедневно в моей среде SQL Server создаются или обновляются сотни связанных с ним файлов журналов. Нет, я не имею в виду файлы журналов транзакций SQL Server, я говорю о текстовых файлах, таких как SQL Server errorlog, выходных файлах DBCC, файлах журналов SQL agent и выполняемых по расписанию заданий, а иногда даже файлах журналов кластеров, если используются отказоустойчивые кластеры (failover cluster). Эти файлы содержат ценную для администраторов БД информацию, и я считаю частью своей ежедневный работы их просмотр, гарантирующий, что ни одно важное событие не пройдет незамеченным.
Однако ежедневный ручной просмотр этих файлов не является лучшим использованием времени администратора БД и, как правило, малоэффективен, поскольку администратор БД утомляется и начинает быстро «прокручивать» файлы. Отдельные администраторы БД полагаются на простые инструменты, подобные утилите findstr.exe, входящей в состав NT Resource Kit, для захвата строк с некоторыми ключевыми словами, такими, например, как “error” или “corrupt”1 . Но подобный упрощенный подход часто приводит к большому числу «ошибочных результатов», захватывая строки файла журнала, являющиеся безвредными или содержащие повторяющиеся сообщения.
Мне хотелось иметь нечто более мощное, и результатом явился написанный на Perl сценарий.
(Возврат на основную страницу)