26.4.23

Новое в SQL Server 2022: работа с time series (временные ряды)

Данные временных рядов — это набор значений, упорядоченных так, как они появляются и поступают для обработки. В отличие от транзакционных данных SQL Server, которые не зависят от времени и могут часто обновляться, данные временных рядов обычно записываются один раз и, если обновляются, то крайне редко.

Вот несколько примеров данных временных рядов: цены на акции, телеметрия от датчиков, счётчики производительности SQL Server (например, утилизация ЦПУ, памяти, устройств ввода-вывода и сети).

25.4.23

Tips for DBA: sp_create_plan_guide позволяет администратору менять план запроса

В статье речь пойдёт о системной хранимой процедуре sp_create_plan_guide, которая включена в поставки SQL Server Enterprise Edition и Standard Edition.

Эта процедура описана в электронной документации в разделе, посвящённом производительности запроса. Её назначение сводится к тому, что бы, цитирую: Эта процедура может использоваться, когда нельзя или не нужно напрямую менять текст запроса. Руководства планов полезны, когда небольшое подмножество запросов в приложении базы данных стороннего разработчика выполняются не так, как ожидается.

Tips for DBA: Searching unused indexes

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

Tips for DBA: Missing indexes recommendations

Вы, наверное, уже заметили, какую полезную информацию об индексах и о статистике использования существующих и, как это не удивительно, не существующих индексов можно получить в SQL Server из системных динамических административных представлений. Особенно впечатляет эта информация, когда её видишь в виде пользовательского отчёта приборной панели производительности SQL Server, которую в качестве бесплатного дополнения к SQL Server Management Studio предлагает использовать Майкрософт.
Ниже представлен сценарий, который позволяет получить рекомендации по индексам, которых в обозримом прошлом недоставало базе данных, в контексте которой этот сценарий исполняется. Учтите, что сценарий в целях наглядности был упрощён, поэтому результирующие команды по созданию индексов, наверняка, будут содержать ошибки, т.к. тут не учитывается возможность отсутствия не относящихся к предикатам эквивалентности колонок, а также колонок, которые в индексе будут присоединёнными. Впрочем, эти ошибки легко устранимы, просто поищите лишние запятые перед запуском сценария, а также не забудьте удалить пустые инструкции INCLUDE.

Tips for DBA: Using sys.dm_db_index_physical_stats in a script to rebuild or reorganize indexes

В электронной документации к SQL Server описано замечательное динамическое административное представление sys.dm_db_index_physical_stats. Описание сопровождается примерами использования, один из которых (в русской редакции страницы это пример "Г", а в английской "D") предлагает метод и правила автоматизации операций дефрагментации индексов в базе данных. Суть метода в том, что если значение avg_fragmentation_in_percent находиться в диапазоне от 10 до 30, то в инструкции ALTER INDEX используется ключевое слово REORGANIZE, а если значение больше 30, то используется ключевое слово REBUILD. Однако, существует и другой алгоритм выбора метода дефрагментации, который подробно изложен в книге: " Microsoft SQL Server 2005. Реализация и обслуживание. Учебный курс Microsoft". Вот выдержка из этой книги, со страницы 368: "Исполняйте инструкцию ALTER INDEX … REORGANIZE, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent в диапазоне от 60 до 75 или значение avg_fragmentation_in_percent в диапазоне от 10 до 15. Исполняйте инструкцию ALTER INDEX … REBUILD, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent меньше 60 или значение avg_fragmentation_in_percent больше 15.".

Tips for DBA: Deadlock Event Notifications

Начиная с SQL Server 2005, на службе DBA появилась такая замечательная возможность, как Event Notifications, что в русской версии BOL принято называть уведомлением о событиях. Этот механизм позволяет включить незаметную трассировку системных событий и извлекать информацию о заданных события из очереди для анализа или реакции со стороны администратора. Полный список событий, которые таким образом можно отслеживать, можно найти в статье: События трассировки для использования с уведомлениями о событии

Давайте рассмотрим упрощённый пример организации уведомлений о тупиковой блокировке и сделаем так, чтобы по электронной почте можно было получить письмо с графом блокировок.

Tips for DBA: Database is in transition?!

Сегодня утром на одном из серверов произошёл "казус" с пользовательской базой данных, которую мои коллеги пытались перевести в OFFLINE, но процесс пошёл не штатно, база попала в переходное состояние, став недоступной и затруднив при этом мониторинг активности других пользовательских и системных баз… Ситуация точно такая же, какая была описана Полом Ибисоном в группе новостей: OFFLINING and "Database 'xxx' is in transition. Try the statement later."

Tips for DBA: Быстрое резервирование пакетов планов обслуживания

Вашему вниманию предлагается упрощённый вариант копирования хранящихся на сервере пакетов планов обслуживания.

Идея взята из статьи: Using dtutil to copy SSIS packages stored in SQL Server

Дополнительная информация тут: Программа dtutil

Суть демонстрации, создать список команд для копирования пакетов. Команды, после анализа кода, нужно скопировать через буфер обмена в окно запроса и выполнить.

Tips for DBA: How to trace Deprecated Features

Если необходимо отследить статистику использования отключаемого в будущих версиях функционала SQL Server 2008, можно воспользоваться представленным ниже сценарием. За основу этого сценария взятя информация о статистике значений счётчиков производительности, извлекаемая из административного динамического представления sys.dm_os_performance_counters

SELECT instance_name   AS [Старый функционал]
     , sum(cntr_value) AS [Число использований]
FROM   sys.dm_os_performance_counters
WHERE  object_name = 'SQLServer:Deprecated Features'
AND    cntr_value <> 0
GROUP BY instance_name
ORDER BY [Число использований] DESC

Tips for DBA: The Spy for stored procedures

Вашему вниманию предлагается макет сценария и методики, позволяющей организовать учёт исполнения хранимых процедур пользовательской базы данных. Пример сценария само-достаточен, т.е. для его успешной работы необходимо только заменить в тексте сценария слово 'ТУТДОЛЖНОБЫТЬИМЯВАШЕЙБАЗЫДАННЫХ!!!!!!!!!!!!!!!!' на имя вашей базы данных, использование процедур которой необходимо отслеживать. Сценарий создаёт задание Агента SQL Server, которое по установленному расписанию (расписание подбирается в зависимости от нагрузки сервера) исполняет сценарий T-SQL. Исполняемый заданием сценарий создаёт по необходимости в базе TEMPDB таблицу Activproc, и потом записывает в ней статистику использования процедур, получая актуальные на момент исполнения метаданные сервера. Для того, чтобы понять принципы работы сценария, ознакомьтесь с теми разделами BOL, в которых описаны задействованные в сценарии административные динамические представления и функции.

Tips for DBA: Store Performance Counters in Database (Job-Step: Power Shell)

Остались в прошлом те времена, когда средствами SQL Server можно было получить состояния счётчиков производительности, которые относились только к самому SQL Server. Для этого традиционно использовались системные представления sys.sysperfinfo и sys.dm_os_performance_counters.

С помощью Power Shell и нового в SQL Server 2008 типа шага в заданиях по расписанию, который позволяет запускать под управлением SQL Server Agent сценарии  Power Shell, теперь можно получить абсолютно любые счётчики производительности. Причём, сделать это можно как для локального, так и удалённого в сети сервера. А получение сведений о счётчиках посредством WMI избавляет от необходимости агрегации сырых значений, что делает этот метод простым и понятным.

Tips for DBA: Signal Waits vs. Resource Waits

Прочитал сегодня интересный рецепт, как быстро определить, кто даёт слабину, процессор или дисковая подсистема. Ну и заодно в очередной раз убедился в полезности книжки: Проектированиеи оптимизация доступа к базам данных Microsoft SQL Server 2005. Учебный курсMicrosoft (+ CD-ROM)

Авторы этого учебного курса считают, что соотношение суммарных ожиданий процессоров и ввода-вывода можно использовать для того, чтобы определить, кто из них из-за кого простаивает. Впрочем, вот выдержка из этой замечательной книги, со страницы 400:

Одной из самых сложных задач, с которыми сталкиваются разработчики баз данных, является прогнозирование поведения приложения в реальных условиях. Чтобы иметь точное представление о характеристиках производительности приложения, разработчик должен знать конкретную причину любого состояния ожидания, которое возникает во время выполнения приложения. На самом общем уровне состояния ожидания можно разбить на две категории: ожидание сигнала и ожидание ресурса. В SQL Server ожидание сигнала происходит, когда планировщик ждет процессор, чтобы запланировать задачу, а ожидание ресурса возникает, когда задача получила время процессора, но находится в ожидании ресурсов диска или памяти. При исследовании состояний ожидания в приложении нужно иметь в виду следующее. Если отношение времени ожидания сигнала ко времени ожидания ресурса велико (т.е. если состояний ожидания сигнала значительно больше, чем состояний ожидания ресурса), это может служить показателем неэффективного использования процессора. Если же велик коэффициент отношения времени ожидания ресурса ко времени ожидания сигнала, это может указывать на неэффективное использование ресурсов диска. Приступая к оценке производительности приложения, разработчики должны понимать, какой из типов ожидания преобладает. К счастью, SQLOS предоставляет "окно" в систему, достаточно прозрачное для того, чтобы разработчики могли использовать его для ответа на этот вопрос.