Ваши SQL-запросы выполняются слишком быстро? Я думал, что нет! Многие администраторы баз данных не знают, с чего начать настройку производительности. В августовском выпуске SQL Server Pro предлагаются стратегии достижения максимальной производительности. Также есть статья о T-SQL Best Practices, которая находится в свободном доступе в Интернете.
Ваши SQL-запросы выполняются слишком быстро? Я думал, что нет! Многие администраторы баз данных не знают, с чего начать настройку производительности. 10 лучших советов по настройке производительности SQL Server в августовском выпуске ежемесячного онлайн-журнала на основе подписки. SQL Server Pro предлагает стратегии для достижения максимальной производительности. Я настоятельно рекомендую вам прочитать и статью, и ссылки на нее, если вы хотите повысить производительность своих SQL-запросов.
Рассматриваемые советы включают:
Хватит ждать. Когда SQL не работает, причина ожидания записывается SQL Server, проверка этих ожиданий может улучшить производительность. Эти ожидания можно расшифровать с помощью статьи Тома Дэвидсона.
Найдите узкие места ввода-вывода. Ввод-вывод часто является основной причиной низкой производительности. Вы можете проверить ввод-вывод с помощью статистики ожидания, DMF sys.dm_io_virtual_file_stats () и счетчиков Perfmon, связанных с диском. Причины включают медленные диски, размещение диска, плохо написанный SQL и отсутствие хороших индексов.
Устранение проблемных запросов. DMV sys.dm_exec_query_stats агрегирует метрики запросов (продолжительность, время на ЦП, ожидание, чтение, запись, выполнение и т. Д.) На уровне отдельных операторов SQL — отлично подходит для определения самого долго выполняющегося SQL. Затем можно оптимизировать эти
Планируйте повторное использование. Измените динамический SQL, чтобы использовать хранимые процедуры для повторного использования плана, иначе по мере увеличения количества транзакций вы можете получить низкую производительность
Мониторинг использования индекса. DMF sys.dm_db_index_operational_stats () детализирует, что использовалось, как использовалось, сканирует, синглтоны, вставляет, удаляет, обновляет, защелкивает и блокирует
Отдельные файлы данных и журналов. Важно как для DAS, так и для SAN. Отделяйте произвольный доступ (данные) от последовательного доступа (журнал)
Используйте отдельные промежуточные базы данных. Затем можно использовать простую модель восстановления, которая ускоряет импорт и использует меньше ЦП, операций ввода-вывода и памяти.
Обратите внимание на файлы журналов. Расширение журнала может быть дорогостоящим, поэтому лучше убедиться, что у вас есть необходимое свободное пространство. Также убедитесь, что у вас не слишком много файлов виртуальных журналов (VLF).
Сведите к минимуму конкуренцию за tempdb. tempdb может использоваться всеми другими базами данных на сервере, и это часто наиболее используемая база данных
Измените максимальный предел памяти. Не забудьте оставить как минимум 1 или 2 ГБ памяти для других процессов. Также учитывайте влияние нескольких экземпляров
В T-SQL Best Practices Ицик Бен-Ган описывает некоторые важные практики, которым нужно следовать, и их обоснование. Обе части этой статьи находятся в свободном доступе (т.е. без подписки). В Части 1 его совет:
Мыслите наборами. Примите непроцедурный подход. Избегайте курсоров и циклов.
Подумайте о NULL и трехзначной логике. В NULLS отсутствуют значения, и вы всегда должны их учитывать.
Избегайте NOLOCK. Использование NOLOCK — обычная практика, позволяющая SQL работать быстрее, без блокировок. Стоимость не подтвержденных и непоследовательных чтений. Вместо этого используйте изоляцию зафиксированных снимков при чтении.
Примите хорошие методы кодирования:
Завершать операторы точкой с запятой
Избегать *
Всегда используйте имена объектов с указанием схемы
Имейте стиль и используйте правильный корпус
Избегайте синтаксиса соединения в старом стиле
Во второй части он продолжает:
Подумайте об облаке (некоторые языковые функции не разрешены в облаке, а кучи недопустимы).
Рекомендации по работе с датой и временем
Используйте не зависящие от языка литералы
Будьте осторожны с ошибками округления
Пишите стандартный код (в отличие от проприетарного SQL от Microsoft).
Остерегайтесь практических правил (ответ часто бывает «в зависимости от обстоятельств»).
Используйте аргументы поиска
Статья полезна как для начинающих разработчиков SQL, так и для опытных разработчиков, которые хотят освежиться. Иногда это может показаться немного педантичным, например, не используйте термин «значение NULL», поскольку значения NULL не имеют значения. Я могу не согласиться на 100% с предложениями, поскольку некоторые из них не всегда могут быть практичными в коммерческой среде, но любой контент из Itzik всегда стоит прочитать.
В редакционной статье этого месяца говорится, что Microsoft слишком далеко опередила своих клиентов? В настоящее время Microsoft продвигает использование облака (или гибридного облака) и уже начала выделять следующую версию SQL Server (2014). К сожалению, большинству клиентов еще предстоит поэкспериментировать с облаком и они остановились на SQL Server 2005 или 2008. Приводятся убедительные аргументы в пользу того, что, хотя клиенты хотят, чтобы технологическая компания занимала лидирующие позиции, следует учитывать текущие потребности пользователей.
Саураб Дхобл (Saurabh Dhoble) предоставляет обширную 16-страничную статью, посвященную стратегии развертывания SSIS для SQL Server 2012. SSIS — это главный инструмент ETL, однако часто возникают проблемы с настройками конфигурации при перемещении пакетов между средами (например, от разработки к пользовательскому тестированию). В статье подробно рассказывается, как можно упростить развертывание проектов SSIS в различных средах и управлять их конфигурацией с помощью переменных среды.
В статье VMWare High Availability in SQL Server Денни Черри обсуждает варианты высокой доступности, которые доступны как побочный продукт использования VMWare vSphere на виртуальных машинах. Преимущества распространяются на все версии (например, SQL Server 2012) и выпуски (например, стандартный выпуск) SQL Server. Это должно быть особенно интересно для организаций с ограниченным бюджетом.
Краткая серия статей о повреждении базы данных начинается с книги «Повреждение базы данных SQL Server, часть 1: Что такое повреждение?». Цель этой серии — обсудить, что такое коррупция, почему вы не можете ее предотвратить и как с ней бороться, чтобы обеспечить доступность и время безотказной работы. В этой первой части коррупция определяется как неправильное хранение нулей и единиц в подсистеме ввода-вывода. Повреждение часто вызвано проблемами с подсистемой ввода-вывода, например. диск, контроллер или драйвер. Эта 3-страничная статья показалась немного легкой по содержанию, я подозреваю, что ее можно было сжать до единой страницы без потерь.
Большинство технологов с нетерпением ждут новых редакций своего любимого программного обеспечения. В разделе «Новые возможности SQL Server 2014» выделены несколько привлекательных функций, в том числе
В оперативной памяти OLTP Engine (AKA Hekaton). Ожидаемый прирост производительности от x10 до x50 и скомпилированные хранимые процедуры
Улучшенная масштабируемость. Масштабирование до 640 логических процессоров и 4 ТБ памяти
Интегрированное резервное копирование Windows Azure (резервное копирование и восстановление в и из Windows Azure)
Интегрированные группы доступности AlwaysOn в Azure (полезно для аварийного восстановления)
Для меня журнал в этом месяце был гораздо более приятным, чем недавние номера. Возможно, это связано с тем, что в нем содержались некоторые ключевые постоянные темы, представляющие интерес, например, производительность и передовые практики. Вдобавок предстоящий SQL Server 2014 выглядит «интересно».