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

Миграция группы доступности AlwaysON в другой кластер

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

Агрегат WITH ROLLUP

Автор оригинала: Craig Freedman: Aggregation WITH ROLLUP

В этой статье мы обсудим, как устроен агрегат WITH ROLLUP. Использование предложения WITH ROLLUP позволяет выполнить несколько «уровней» агрегации в одном операторе. Например, предположим, что у нас есть некие данные о продажах (это те же данные, которые я использовал в серии статей об операторе PIVOT).