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).

Погружение в уникальные индексы

Автор оригинала: Craig Freedman: Maintaining Unique Indexes

Рассмотрим следующий пример:

CREATE TABLE T (PK INT PRIMARY KEY, A INT, B INT)
CREATE INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)
INSERT T VALUES (0, 0, 0)
INSERT T VALUES (1, 1, 1)

Теперь предположим, что мы выполним обновление:

UPDATE T SET A = 1 – A

Это изменение влияет на кластерный индекс (PK__T__15502E78) и на некластерный индекс TA. План в значительной степени такой, какой мы ожидали:

  |--Clustered Index Update(OBJECT:([T].[PK__T__15502E78]), OBJECT:([T].[TA]), SET:([T].[A] = [Expr1003]))
       |--Compute Scalar(DEFINE:([Expr1016]=[Expr1016]))
            |--Compute Scalar(DEFINE:([Expr1016]=CASE WHEN [Expr1004] THEN (1) ELSE (0) END))
                 |--Compute Scalar(DEFINE:([Expr1003]=(1)-[T].[A], [Expr1004]=CASE WHEN [T].[A] = ((1)-[T].[A]) THEN (1) ELSE (0) END))
                      |--Top(ROWCOUNT est 0)
                           |--Clustered Index Scan(OBJECT:([T].[PK__T__15502E78]))

Это типичный «узкий» план обновления. В одном операторе обновления затрагиваются кластерный и некластерный индексы. План содержит Compute Scalar, которые определяют, нужно ли изменять соответствующую строку некластерного индекса. О подобных планах я писал в этой статье.

Доступна для скачивания SQL Server Management Studio 19.0.2

SSMS 19.0.2 — это последняя общедоступная версия. Если у вас установлена предварительная версия SSMS 19, ее следует удалить перед установкой SSMS 19.0.2. Если у вас установлена среда SSMS 19.x, при установке SSMS 19.0.2 она обновляется до версии 19.0.2.

• Номер выпуска: 19.0.2
• Номер сборки:   19.0.20209.0
• Дата выпуска:    13 марта 2023 г.

Скачать SSMS можно по ссылке: SSMS-Setup-ENU.exe

Подробное описание и версии для других языков доступны тут: Скачивание SQL Server Management Studio (SSMS)

Вышел Cumulative Update 2 for SQL Server 2022 (KB5023127)

Дата выпуска:15.03.2023

Версия MSSQL: 16.0.4015.1

Версия SSAS: 16.0.43.208

Подробное описание: https://support.microsoft.com/ru-ru/topic/kb5023127-cumulative-update-2-for-sql-server-2022-e4e4db2a-4639-457d-8dbc-f6f8d99d1f9a

Скачать обновление: https://download.microsoft.com/download/9/6/8/96819b0c-c8fb-4b44-91b5-c97015bbda9f/SQLServer2022-KB5023127-x64.exe

Поиск и устранение повреждений данных

Это выдержка из восьмой главы книги Rodney Landrum: «SQL Server Tacklebox», в которой описывается, как DBA может устранить последствия повреждения данных. Будут продемонстрированы инструменты и сценарии, необходимые для своевременного поиска и устранения повреждений данных и предотвращения их попадания в резервные копии.

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

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