Tips for DBA: Log Flush Performance

Одной из распространённых задач систем с высокой транзакционной загрузкой является определение того, достаточно ли производительна подсистема ввода-вывода, обслуживающая журнал транзакций. Часто «узким местом» становиться дисковая подсистема, используемая в качестве долговременного носителя для файла журнала транзакций обслуживаемой SQL Server базы данных. Одним из важных параметров дисковой подсистемы является время доступа к данным на диске. Современным дисковым подсистемам характерно время доступа порядка 1 – 5 ms. Проверить, какое время доступа у используемой для размещения файла журнала транзакций дисковой подсистемы можно с помощью административного динамического представления: sys.dm_os_wait_stats (Transact-SQL). Данные в этом представлении накапливаются с момента последнего запуска службы SQL Server, поэтому, рекомендуется очистить эту статистику.

Настройка Windows Server 2008/2003 x64 для обслуживания SQL Server 2008

По состоянию на 2009 год

Эта статья - вольная интерпретация рекомендаций: Microsoft, IBM, HP, Dell, QLogic, LSI, EMC, ACER, Bull, Fujitsu, Hitachi, NEC и Unisys. Некоторые рекомендуемые настройки требуют отдельного, обстоятельного разговора, и потому не включены в эту статью, а найти эти рекомендации можно в этом блоге.

Как справиться с PAGELATCH при больших INSERT-нагрузках

По материалам статьи: "Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads".
Авторы: Thomas Kejser, Lindsey Allen, Arvind Rao и Michael Thomassy
При участии и с рецензиями: Mike Ruthruff, Lubor Kollar, Prem Mehra, Burzin Patel, Michael Thomassy, Mark Souza, Sanjay Mishra, Peter Scharlock, Stuart Ozer, Kun Cheng и Howard Yin
Введение

Недавно, мы проводили лабораторные испытания в Microsoft Enterprise Engineering Center, при которых использовалась большая рабочая нагрузка, характерная для OLTP систем. Целью этой лабораторной работы было определить, что случится при увеличении числа процессоров с 64 до 128, при обслуживании Microsoft SQL Server интенсивной рабочей нагрузки (примечание: эта конфигурация была ориентирована на релиз Microsoft SQL Server 2008 R2). Рабочая нагрузка представляла собой хорошо распараллеленные операции вставки, направляемые в несколько больших таблиц.
Рабочая нагрузка масштабировалась до 128 процессорных ядер, но в статистике ожиданий было очень много кратких блокировок PAGELATCH_UP и PAGELATCH_EX. Средняя продолжительность ожидания была десятки миллисекунд, и таких ожиданий было очень много. Такое их количество оказалось для нас неожиданностью, ожидалось, что продолжительность не будет превышать несколько миллисекунд.
В этой технической заметке вначале будет описано, как диагностировать подобную проблему и как для разрешения подобной проблемы использовать секционирование таблиц.

Счётчики производительности, позволяющие идентифицировать узкие места дисковой подсистемы SQL Server

По материалам статьи Маттео Лорини (Matteo Lorini): «Perfmon Counters to Identify SQL Server Disk Bottlenecks».

Описание проблемы

Известны несколько статей об обнаружении проблем ввода-вывода, связанных с SQL Server. Существуют разные методы поиска «узких мест» ввода-вывода, мы же сконцентрируемся тут на вопросе: Какие счётчики производительности необходимы для того, чтобы быстро понять, являются ли диски «узким местом»?

Атрибут логического диска IdlePrioritySupported рекомендован официально

Такая рекомендация попалась мне на глаза в последней редакции документа: Performance Tuning Guidelines for Windows Server 2012 R2

Там, в главе Performance Tuning for Workloads, в разделе, посвящённом оптимизации OLTP - Server under test tunings, предлагают следующий  способ оптимизации производительности логических дисков (которые предполагает ковыряние реестра, что, напоминаю, не безопасно и только на ваш страх и риск!):

• Configure storage devices.

◦ Disable low priority I/O. For each logical volume in HKLM\SYSTEM\CurrentControlSet\Enum\SCSI under Device Parameters\ClassPnp, create a REG_DWROD registry entry named IdlePrioritySupported and set the value to 0.

Опыт размещения файлов баз данных

В этой статье отражён опыт построения и поддержания инфраструктуры для больших (больше 10Тб) баз данных. Статья не предлагает универсального решения всех возможных задач MS SQL Server и не отражает всего разнообразия возможных типов нагрузки. Поэтому использовать представленные ниже выводы и рекомендации стоит с оглядкой на свою специфику. Всё, что тут описано, было апробировано на OLTP нагрузках с немалой долей больших аналитических запросов, агрегации, процессинга и массовых выгрузок/загрузок данных. Нагрузка была блочная, неоднородная во времени и по структуре. Характерными чертами нагрузки являлся высокий параллелизм, большое число блокировок, листаний, асинхронных операций, очередей, ожиданий процессора и окончания ввода-вывода. Сама нагрузка балансировалась на уровне логики работы приложения, ресурсы распределялись сообразно возможностям задач, запросы снабжались «хинтами», а распределения памяти для многих задач исчислялись десятками и сотнями Мегабайт.

Статья предназначена для администраторов баз данных и хранилищ. Подразумевается, что она облегчит понимание особенностей размещения файлов данных и журналов SQL Server в сетях SAN.

Основы I/O в SQL Server

По материалам статьи Bob Dorr: SQL Server 2000 I/O Basics

Изучение требований к операциям ввода-вывода (I/O) с файлами баз данных Microsoft SQL Server поможет Вам поднять производительность системы и избежать ошибок, связанных с I/O.

ВВЕДЕНИЕ

Поскольку на рынке продолжают появляться новые устройства и решения для дисковых хранилищ, условия, в которых работает Microsoft SQL Server, стали чрезвычайно разнообразным. Чтобы гарантировать целостность данных, которые обслуживает SQL Server, очень важно, что бы подсистема I/O обладала соответствующими функциональными возможностями.
Цель этой статьи состоит в том, чтобы описать требования к I/O для операций с файлами баз данных SQL Server, на основании чего поставщики решений и пользователи могли бы проанализировать и оптимизировать свои системы с SQL Server.

Важно: При планировании, развертывании и поддержке Microsoft SQL Server, убедитесь, что система ввода-вывода удовлетворяет всем факторам, на которые акцентируется внимание в этой статье.

Microsoft Knowledge Base и Microsoft SQL Server Books Online (BOL) содержат много подробной информации, связанной с операциями I/O в SQL Server. В тексте, при необходимости, автором указываются ссылки на информацию, которая важна для понимания предлагаемого в этой статье материала.
Важно: Автор рекомендует полностью ознакомиться с материалом, на который он ссылается, перед тем, как Вы начнёте изучать следующие за ссылкой главы.
Справочная система Books Online (BOL): Все ссылки на BOL, используемые в этой статье, взяты из Microsoft SQL Server 2000 Books Online (обновлённая редакция, с учётом новшеств SP3), который можно скачать по этой ссылке: http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp. Если в открывшейся странице нажать на ссылку Product Documentation, можно выбрать альтернативный вариант просмотра BOL в интерактивном режиме.

Руководство по производительности загрузки данных

По материалам технической статьи, посвящённой SQL Server: The Data Loading Performance Guide

Авторы: Томас Кайзер (Thomas Kejser), Питер Карлин (Peter Carlin) и Стюарт Озер (Stuart Ozer)
Техническая рецензия и экспертиза: Sunil Agarwal, Ted Lee, David Schwartz, Chris Lee, Lindsey Allen, Hermann Daeubler, Juergen Thomas,Sanjay Mishra, Denny Lee,

Peter Carlin, Lubor Kollar
Особая благодарность: Henk van der Valk (Unisys), Alexei Khalyako и Marcel van der Holst
Перевод: Александр Гладченко, Ирина Наумова, Влад Щербинин и Алексей Халяко
Дата издания: январь 2009г.
Статья относится к продуктам: SQL Server 2008 и SQL Server 2005

Резюме: Этот документ описывает стратегию массовой загрузки больших объёмов информации в базы данных SQL Server. Статья охватывает два распространённых метода, а также методологии повышения производительности и оптимизации процесса массовой загрузки данных.

Введение

Настоящая техническая статья описывает существующие стратегии массовой загрузки данных, которые применяются для быстрого внесения масштабных изменений в базах данных Microsoft ® SQL Server ®.
Прежде, чем углубиться в подробности методов массовой загрузки, давайте освежим в памяти некоторые базовые принципы минимального протоколирования, которые будут представлены в главе: “Разъяснения по минимально протоколируемым операциям”.
Следующие две главы: “Методы массовой загрузки” и “Другие минимально протоколируемые операции и операции над метаданными” содержат краткий обзор двух ключевых и взаимосвязанных концепций высокопроизводительной загрузки данных, таких как массовый импорт и экспорт данных и операции только над метаданными.
После небольшого погружения в тему, мы приступим к описанию способов использования этих методов в пользовательских сценариях. Приводимые тут примеры сценариев призваны проиллюстрировать типовые подходы, которые можно найти в главе: “Решения для типовых задач массовой загрузки”. Особо будут рассмотрены такие сценарии, когда загрузка данных в таблицу должна выполняться при одновременном чтении из этой же таблицы. В главе “Массовая загрузка, запросы с NOLOCK и Read Committed Snapshot Isolation” описаны методы, которые могут использоваться для достижения параллельной загрузки и чтения данных.
Эта техническая статья заканчивается главой “Оптимизация массовой загрузки данных”, в которой рассказано о поиске и устранении сопутствующих загрузке данных проблем.

10 рекомендаций по настройке хранилищ данных

 Автор: Алексей Халяко

Правильная настройка дисковых подсистем ввода-вывода является критически важным фактором в достижении высокой производительности и оптимальной работы систем SQL Server. В этой статье приводятся некоторые из наиболее распространенных рекомендаций для настройки подсистемы хранилища данных в SQL Server, предлагаемые группой разработчиков SQL Server.

Поиск узких мест ввода-вывода для MS SQL Server

По материалам статьи Tibor Nagy: How to Identify I/O Bottlenecks in MS SQL Server - 17.03.2011

Проблема

   Суть проблематики данной статьи - регулярное замедление в работе баз данных SQL Server. После статей, посвящённых анализу использования памяти и CPU, мы хотели бы продолжить исследование причины замедления путём анализа узких мест ввода-вывода.

Вариант стратегии быстрого и надежного резервного копирования/восстановления VLDB по сети

 По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network

 

Автор: Томас Грохсер (Thomas H. Grohser)

При содействии: Линдсей Аллен (Lindsey Allen)

Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel

Перевод: Александр Гладченко,  Ирина Наумова

Дата издания: июнь 2009г.

Тематика статьи: SQL Server 2008

 

Резюме: Размер баз данных непрерывно растёт, так же, как и растут требования к надежности и доступности баз. Одновременно с этим как никогда важным становится  требование быстрого и надежного восстановления данных. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). В этой статье на реальном примере демонстрируется как лучше всего использовать функциональность SQL Server 2008 для осуществления    резервного  копирования и   восстановления, которыми обладает SQL Server 2008,  а также  создание планов резервного копирования и восстановления VLDB по сети.

Отказ от ежедневной дефрагментации

В этой статье попытаемся понять, как изменились процедуры обслуживания индексов для таблиц Microsoft SQL Server в современных условиях: при размещении файлов данных и журнала транзакций на SSD-дисках, многократном увеличении числа процессорных ядер и в условиях, когда оперативная память сервера стала измеряться Терабайтами.Действительно, мир стал другим. С тех пор как появились первые версии SQL Server, многое изменилось и многие методики, основанные на старых компьютерных ресурсах, работают уже не так эффективно, как прежде, когда без них невозможно было обойтись. Одной из таких методик, которая с давних пор воспринимается чуть ли не «серебряной пулей», а на деле превратилась в миф, является обязательная дефрагментация индексов, если в данные индекса достаточно часто вносятся изменения. Цель статьи развеять этот миф.