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

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

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

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 предоставляет "окно" в систему, достаточно прозрачное для того, чтобы разработчики могли использовать его для ответа на этот вопрос.

Tips for DBA: INSERT Overclocking

Одной из трудно оптимизируемых задач SQL Server является вставка. Не раз мне приходилось сталкиваться с ситуациями, когда уже и схема оптимизирована под вставку, и сайзинг файлов вставке не препятствует, а желаемой производительности массовой или не массовой вставки достичь не удаётся. Не хватает совсем немногого…

Разработчики SQL Server 2008 позаботились о том, чтобы предоставить нам с вами в распоряжение некую «палочку – выручалочку», которая призвана как раз снизить затраты на вставку, путём её не полного журналирования. Для этого предлагается задействовать на серверах флаг трассировки 610, который по моим наблюдениям действительно может немного облегчить вставку. Флаг, и его побочные эффекты, подробно описан тут: The Data Loading Performance Guide

Ещё одна мера, в дополнение к включению флага трассировки 610, описана в документе вендора: SQL Server Best Practices Article. Там, среди прочего, подробно описано исследование того, что будет эффективней, вставка в таблицу с единственным некластеризованным индексом, или вставка в таблицу с единственным кластеризованным индексом. Кластеризация данных может дать выигрыш на вставке до 3%.

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

В тему:

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

Tips for DBA: Table operational/physical stats

Вашему вниманию предлагается сценарий, который для каждой таблицы текущей базы данных показывает статистику по операциям INSERT, UPDATE и DELITE. Кроме этого, вы может оценить, к чему эти операции приводят, с точки зрения роста строк данных, занимаемых страниц и фрагментации. Сценарий основан на использовании двух функций динамического управления: sys.dm_db_index_operational_stats и sys.dm_db_index_physical_stats

/* Внимание!!! Запрос исполняется несколько минут */
SELECT  t.name AS [TableName]
      , fi.page_count AS [Pages]
      , fi.record_count AS [Rows]
      , CAST(fi.avg_record_size_in_bytes AS int) AS [AverageRecordBytes]
      , CAST(fi.avg_fragmentation_in_percent AS int) AS [AverageFragmentationPercent]
      , SUM(iop.leaf_insert_count) AS [Inserts]
      , SUM(iop.leaf_delete_count) AS [Deletes]
      , SUM(iop.leaf_update_count) AS [Updates]
      , SUM(iop.row_lock_count) AS [RowLocks]
      , SUM(iop.page_lock_count) AS [PageLocks]
FROM    sys.dm_db_index_operational_stats(DB_ID(),NULL,NULL,NULL) AS iop
JOIN    sys.indexes AS i
ON      ((iop.index_id = i.index_id) AND (iop.object_id = i.object_id))
JOIN    sys.tables AS t
ON      i.object_id = t.object_id
AND     i.type_desc IN ('CLUSTERED', 'HEAP')
JOIN    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') AS fi
ON      fi.object_id=CAST(t.object_id AS int)
AND     fi.index_id=CAST(i.index_id AS int)
AND     fi.index_id < 2
GROUP BY t.name, fi.page_count, fi.record_count
      , fi.avg_record_size_in_bytes, fi.avg_fragmentation_in_percent
ORDER BY [TableName]

Tips for DBA: Logical Disk FreeSpace Notification

В SQL Server с помощью службы SQL Server Agent и PowerShell можно достаточно просто соорудить задание, которое будет заглядывать в метаданные WMI локального или удалённого сервера, и сообщать по электронной почте, в случае если свободное место на указанном диске перешагнуло заданный порог. Ниже представлен облегчённый концепт сценария подобного задания (расписаний в нём нет и данные берутся по локальному серверу). Вам нужно будет заменить фиктивный адрес на реальный и указать почтовый профиль, если нельзя воспользоваться профилем по умолчанию.

Tips for DBA: Percentage of work completed for DBA commands

Как вы наверняка знаете, повторное исполнение команды KILL для сеанса показывает процент завершения отката прерванной инструкции. Это замечательная возможность, которая позволяет сберечь нервы администратора баз данных. Однако, есть и другие долгоиграющие команды, процент завершения которых тоже интересно было бы отслеживать. Ну, например, примерно таким же образом, как сообщает о прогрессе своей работы команда BACKUP. Вашему вниманию предлагается сценарий, который позволяет отслеживать прогресс исполнения следующих команд:

• ALTER INDEX REORGANIZE
• AUTO_SHRINK с ALTER DATABASE
• BACKUP DATABASE
• CREATE INDEX
• DBCC CHECKDB
• DBCC CHECKFILEGROUP
• DBCC CHECKTABLE
• DBCC INDEXDEFRAG
• DBCC SHRINKDATABASE
• DBCC SHRINKFILE
• KILL (Transact-SQL)
• RESTORE DATABASE
• UPDATE STATISTICS

Tips for DBA: Log Flush Performance

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

MSMQ 3.0 в Кластере

Здесь будет идти речь о кластере Windows Server 2003 Enterprise Edition и о запуске в кластере службы MSMQ. MSMQ, как кластерный ресурс, зависит от двух кластерных ресурсов: сетевого имени и физического диска. Зависимость от сетевого имени позволяет идентифицировать кластерную группу по IP адресу, и позволяет клиентам обращаться к группе как к виртуальному серверу. Физический диск нужен для хранилища сообщений и очередей.

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

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

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

Флаги трассировки для эталонного теста производительности TPC-C

По материалам статьи: Microsoft SQL Server 2005 TPC-C Trace Flags

Наиболее часто используемым способом изменения поведения SQL Server является выставление флагов трассировки. Следующие флаги трассировки поддерживаются в настоящее время Майкрософт для публикации результатов тесов производительности, таких как TPC-C. Если сотрудники Майкрософт рекомендуют Вам использовать другие флаги трассировки, которые не представлены в списке ниже, пожалуйста, сообщите об этом Джейми Редингу (Jamie.Reding@Microsoft.com) или Чарльзу Левину (Charles.Levine@Microsoft.com) до того, как вы опубликуете использование этих флагов.

Флаги трассировки для эталонного теста производительности TPC-E

По материалам статьи: Microsoft SQL Server 2008 TPC-E Trace Flags

Наиболее часто используемым способом изменения поведения SQL Server является выставление флагов трассировки. Следующие флаги трассировки поддерживаются в настоящее время Майкрософт для публикации результатов тесов производительности TPC-E. Если сотрудники Майкрософт рекомендуют Вам использовать другие флаги трассировки, которые не представлены в списке ниже, пожалуйста, сообщите об этом Джейми Редингу (Jamie.Reding@Microsoft.com) или Чарльзу Левину (Charles.Levine@Microsoft.com) до того, как вы опубликуете использование этих флагов.
Единственными поддерживаемыми для SQL Server 2008 флагами трассировки для TPC-E являются флаги: -T661 -T834 -T3502 -T8744.
Единственным поддерживаемыми для SQL Server 2008 параметрами запуска сервера для теста TPC-E являются параметры: -c -E -x, которые хорошо описаны в BOL.

Query Processor Modeling Extensions

По материалам стать Иан Джоз (Ian Jose): Query Processor Modelling Extensions in SQL Server 2005 SP1

Редактура Алексея Халако

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

Как справиться с 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. Средняя продолжительность ожидания была десятки миллисекунд, и таких ожиданий было очень много. Такое их количество оказалось для нас неожиданностью, ожидалось, что продолжительность не будет превышать несколько миллисекунд.
В этой технической заметке вначале будет описано, как диагностировать подобную проблему и как для разрешения подобной проблемы использовать секционирование таблиц.

Tips for DBA: Замена для стандартного "Back Up Database Task"

Очень часто получается так, что реальные бизнес -требования оказываются сложнее, чем возможности мастеров программного инструментария, поставляемого разными производителями ПО для задач администрирования SQL Server 2008. Например, недавно мне стало недостаточно гибкости мастера создания задачи резервного копирования базы данных для стандартного плана обслуживания БД. У меня возникла необходимость делать копию в несколько фалов на разных дисковых массивах и поддерживать хронологию копий по единым правилам. В несколько файлов выполнять резервное копирование бывает необходимо для повышения производительности этой операции, например, как это рекомендовано в этой статье: "A Technical Case Study: Fast and Reliable Backup and Restore of Multi-Terabytes Database over the Network". Мастер SSMS может либо поддерживать хронологию для одного файла копий, либо копировать в фиксированные имена нескольких указанных файлов. К счастью, совершенно не составляет труда заменить задачу резервного копирования на задачу исполнения сценария T-SQL, в котором выполнить нужную работу. Ниже представлен соответствующий шаблон сценария, взяв который за основу можно составить необходимую задачу исполнения сценария T-SQL.

Сравнения списка объектов SQL Server в PowerShell на примере сравнения логинов на двух серверах

В данном примере я покажу как с помощью PowerShell можно сравнивать списки объектов на двух серверах на примере сравнения логинов: поиск одинаковых, поиск разницы. Для этого сначала выполним подключение к серверам. В данном примере первый сервер – локальный. К нему будем подключаться с использованием Windows аутентификации. Второй сервер – удаленный, к нему будем подключаться с использованием аутентификации SQL Server и запросом на ввод логина и пароля при подключении.

Высокая доступность в репликации SQL Server 2008 с зеркалированием и доставкой журналов

Статья написана по мотивам технического документа Майкрософт: "SQL Server Replication: Providing High Availability using Database Mirroring" и описания в электронной документации SQL Server 2008 Books Online (далее BOL): "Репликация и зеркальное отображение базы данных".
В этой статье мы рассмотрим новые возможности обеспечения высокой доступности тиражируемых данных, используя для этого Репликацию транзакций, Доставку журналов и зеркальные копии баз данных.
Основанная на Репликации транзакций распределённая система хранения данных может обеспечить высокую устойчивость к отказам серверов баз данных. Подобные решения позволяют достичь высокой степени доступности, за счёт поддержки избыточных копий данных. Кроме Репликации, избыточность на уровне баз данных способны обеспечить несколько механизмов SQL Server 2008. Это такие возможности, как резервное копирование с последующим восстановлением, Доставка журналов и Зеркальное отображение базы данных. Причём, Зеркальное отображение является единственным механизмом, который поддерживает точную копию защищаемой базы данных практически в реальном масштабе времени, и гарантирует отсутствие потерь данных.
В этой статье на примерах мы посмотрим, как можно использовать Зеркальное отображение реплицируемой базы данных для повышения её доступности. Мы рассмотрим как Репликация и Зеркальное отображение влияют друг на друга, а также, как Зеркальное отображение совместимо с Доставкой журналов и как Доставка журналов совместима с Репликацией. Кроме того, в этой статье мы коснёмся возможностей использования для первоначальной синхронизации баз данных механизмов Доставки журналов, и вкратце рассмотрим принципы работы инициализации подписчика, основанной на логических номерах виртуальных журналов (LSN), которая позволяет сократить время восстановления после отказа при наличии зеркальной копии базы данных Подписчика.

Пример настройки Soft-NUMA

Сегодня получили широкое распространение многоядерные системы. Персональные компьютеры с четырьмя ядрами уже не редкость. Т.о. счастливые обладатели подобных многоядерных систем могут на практическом примере апробировать Soft-NUMA и как можно привязать к Soft-NUMA узлу порт сетевого протокола TCP/IP.

Tips for DBA: sys.dm_os_wait_stats и правильный способ сбора статистики ожиданий

Статистика ожидания является очень удобным и практичным инструментом для выявления узких мест в работе SQL Server. Познакомиться со списком существующих типов ожиданий и рекомендациями по реакции на отклонения ожиданий от нормы можно в описании динамического административного представления sys.dm_os_wait_stats

Для анализа статистики ожиданий необходимо собирать эту статистику в то время, в которое проявляются проблемы, либо обслуживается нагрузка, которую необходимо исследовать. Для этого обращение непосредственно к sys.dm_os_wait_stats не очень подходит, т.к. там накоплена статистика с момента последнего запуска сервера, либо с момента последней очистки результатов динамического представления командой: DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);

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

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

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

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

Повышение пропускной способности сетевых интерфейсов для SQL Server с помощью настройки параметров RSS

По материалам статьи: Кун Ченг (Kun Cheng) Maximizing SQL Server Throughput with RSS Tuning

Рецензенты: Thomas Kejser, Curt Peterson, James Podgorski, Christian Martinez, Mike Ruthruff
Перевод: Александр Гладченко
Технические редакторы перевода: Алексей Халяко, Ирина Наумова

Функциональность Receive-Side Scaling (RSS) впервые появилась в Windows 2003. Это нововведение было призвано повысить возможности масштабируемости операционной системы Windows, и этим предоставить новые возможности по обслуживанию большого сетевого трафика. Такой трафик характерен для систем, где SQL Server обслуживает OLTP нагрузку. Подробное описание того, какие усовершенствования RSS получила операционная система Windows 2008, можно узнать из отчёта - Receive-Side Scaling Enhancements in Windows Server 2008 и в блоге - Scaling Heavy Network Traffic with Windows.

Tips for DBA: Экспресс-диагностика достаточности памяти системе и экземпляру SQL Server

По ссылке в сценарии можно найти статью, которая меня вдохновила написать пример сценария, который может оказаться полезным для экспресс-диагностики проблем распределения оперативной и виртуальной памяти для нужд запрашиваемого экземпляра SQL Server и операционной системы. Я оставил только реальные (как мне думается) сценарии, которые могут случиться с памятью. Прогон на моих серверах вроде показал правдивость обнаруженного. Посмотрите у себя? Обсудить результаты и сам сценарий можно в коментариях.

Tips for DBA: Scripting jobs using Powershell (separated files)

Вашему вниманию предлагается сильно упрощённый пример сценария Powershell, который предназначен для скриптования заданий SQL Server в отдельные файлы. Тут используется папка для файлов C:\TEMP, которая должна быть предварительно создана и, желательно, пуста. Поскольку имена заданий будут использованы в качестве имён файлов, желательно, что бы в них не использовались недопустимые для имён файлов символы. Если это неудобно, попробуйте внести изменения в то место сценария, где подобные символы заменяются на пробелы.

Чего не стоит делать при использовании менеджера службы отказоустойчивого кластера для управления AlwaysOn Availability Group

Представляем вашему вниманию новую бесплатную электронную книгу в формате PDF, выпущенную командой SQLCAT: SQLCAT's Guide to High Availability and Disaster Recovery

Ниже представлен свободный перевод одной из глав книги.

Атрибут логического диска 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.

Накопительные пакеты обновления SQL Server 2022 CU3 и SQL Server 2019 CU20

Накопительный пакет обновления 3 для SQL Server 2022

SQL Server 2022 — версия продукта: 16.0.4025.1, версия файла: 2022.160.4025.1

Analysis Services — версия продукта: 16.0.43.211, версия файла: 2022.160.43.211

Описание: KB5024396, SQL Server 2022 CU3: How Stella Got Her Groove Back

Скачать: SQLServer2022-KB5024396-x64.exe

Накопительный пакет обновления 20 для SQL Server 2019

SQL Server 2019 — версия продукта: 15.0.4312.2, версия файла: 2019.150.4312.2

Analysis Services — версия продукта: 15.0.35.39, версия файла: 2018.150.35.39

Описание: KB5024276

Скачать: SQLServer2019-KB5024276-x64.exe

Важное изменение алгоритма создания LSN в SQL Server 2014

http://www.sqlskills.com/blogs/paul/important-change-vlf-creation-algorithm-sql-server-2014/

Автор: Paul Randal

Опубликовано: 6 января 2015г.

SQL Server 2014 был выпущен еще в апреле прошлого года, и ходили некоторые слухи об изменениях в алгоритме создания VLF. Они направлены на уменьшение числа VLF, когда журнал увеличивается по команде или автоматически (далее я буду говорить для простоты авто-приращение, поскольку это наиболее распространенный сценарий). Я сделал несколько экспериментов и подумал, что понял изменения указанного алгоритма. Оказывается, я понял не всё. На прошлой неделе в переписке MVP всплыл вопрос, который породил целую дискуссию, и мы вместе пришли к выводу, что алгоритм ведет себя недетерминированно… другими словами, мы не знаем, что он делает. Так что я обратился к моим друзьям в CSS, которые исследовали код (спасибо Bob Ward и Suresh Kandoth!) и объяснили изменения.

SQL Server Real Time Query Monitoring

Автор: Daniel Farina

http://www.mssqltips.com/sqlservertip/3328/sql-server-2014-real-time-query-monitoring/

Проблема

Если вдруг один из запросов к SQL Server выполняется слишком долго, вы может получить его план исполнения, что даст вам понимание того, что этот запрос делает, но из этого плана вы не сможете точно определить, что запрос делает именно в это время, т.е. на каком операторе плана он «застрял»?
Продолжая читать эту статью, вы узнаете, как научится следить за прогрессом исполнения запроса в режиме реального времени.

Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

По материалам статьи: Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

Данная статья относится к следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи был опубликован в 2011г.

Примечание: в данной статье под количеством процессоров подразумеваются не сокеты, а представленные в системе логические процессоры. Рекомендации статьи применимы в тех случаях, когда для сервера баз данных доступно более восьми логических процессоров.

В зависимости от того, для каких нужд SQL Server использует память, дизайн ядра сервера баз данных предусматривает возможность секционирования распределения памяти. В процессе разработки SQL Server можно было выбирать схему секционирования исполнителя по процессорам, узлам или глобально. Некоторые связанные с распределением памяти функциональные модули SQL Server используют модуль распределения CMemPartitioned. Этот модуль секционирует память по процессорам или NUMA узлам, что может способствовать повышению параллелизма и производительности.

Tips for DBA: Оповещение о новых дампах SQL Server

Не существует рекомендованного Майкрософт способа уведомления администраторов о том, что SQL Server выгрузил дамп страниц памяти на диск. Также весьма затруднительно отслеживать такие дампы средствами SQL Server или операционной системы, поскольку во время выгрузки дампа работа сервера баз данных и большинства системных процессов «замирает». Однако, вполне возможно обнаружить последствия выгрузки дампа, поскольку в указанной для дампов папке вместе с файлами дампа появится файл с именем: «SQLDUMPER_ERRORLOG.log». Имя этого файла неизменно, на этом и основан предлагаемый вашему вниманию способ слежений за появлением новых дампов. Настройка пути к папке дампов хранится в системном реестре. По этому пути можно посредством PowerShell узнать существует ли в папке дампов файл с именем «SQLDUMPER_ERRORLOG.log». Такую проверку можно делать по расписанию в задании Агента SQL Server. Если файл обнаружен, то можно совершить необходимое действие. Например, в приведенном ниже сценарии будет отправлено письмо электронной почты на указанный список адресов. Отправку осуществит подсистема SQL Server DatabaseMail. Для корректной отправки сообщения нужно указать существующий почтовый профиль.

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

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

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

Автоматизация проверки баз данных

Одной из обязательных задач администрирования баз данных MS SQL Server является периодическое восстановление баз, дабы убедиться, что база восстанавливается успешно. Ещё одной такой задачей является периодическая проверка баз посредством DBCC CHECKDB. Зачастую, полезно эти задачи объединить, и запускать проверку базы после восстановления её на специально предназначенном для этого сервере. Если у базы имеется несколько файловых групп и размер базы настолько большой, что проверка каждой занимает несколько часов, резонно проверять не всю база сразу, а поочерёдно все файловые группы. Сократить время проверки также можно отказавшись от проверки индексов, например вот так: DBCC CHECKFILEGROUP (‘PRIMARY’, NOINDEX).

Tips for DBA: The SQL Server service and the SQL Server Agent Service fail to start on a stand-alone server

Если в журнале приложений есть ошибки для MSSQLService: “…TDSSNIClient initialization failed with error 0x80092004…” нужно В POWERSHELL создать самоподписной сертификат (заменив в скрипте имя SERVERNAME.DOMENNAME.ru на полное имя вашего сервера):

New-SelfSignedCertificate -Type SSLServerAuthentication -DnsName SERVERNAME.DOMENNAME.ru -KeyLength 2048 -KeySpec KeyExchange -KeyUsage KeyEncipherment -TextExtension @(“2.5.29.37={text}1.3.6.1.5.5.7.3.1”) -NotAfter (Get-Date).AddMonths(1200)

Далее нужно указать для протоколов созданный сертификат, как это описано в главе “Configuring SSL for SQL Server” статьи: Encrypting Connections to SQL Server

Tips for DBA: “SET QUERY_STORE = OFF” AND “QUERY STORE BACKGROUND FLUSH DB”

Если выполнение отключения QS для базы данных блокируется системным процессом: QUERY STORE BACKGROUND FLUSH DB

SET DEADLOCK_PRIORITY HIGH

ALTER DATABASE [DATABASENAME] SET QUERY_STORE = OFF WITH NO_WAIT

GO

Подключиться через DAC и сделать:

TRUNCATE table sys.plan_persist_runtime_stats;

TRUNCATE table sys.plan_persist_runtime_stats_interval;

TRUNCATE table sys.plan_persist_plan;

TRUNCATE table sys.plan_persist_query;

TRUNCATE table sys.plan_persist_query_text;

TRUNCATE table sys.plan_persist_context_settings;