В этой статье попытаемся понять, как изменились процедуры обслуживания индексов для таблиц Microsoft SQL Server в современных условиях: при размещении файлов данных и журнала транзакций на SSD-дисках, многократном увеличении числа процессорных ядер и в условиях, когда оперативная память сервера стала измеряться Терабайтами.
Действительно, мир стал другим. С тех пор как появились первые версии SQL Server, многое изменилось и многие методики, основанные на старых компьютерных ресурсах, работают уже не так эффективно, как прежде, когда без них невозможно было обойтись. Одной из таких методик, которая с давних пор воспринимается чуть ли не «серебряной пулей», а на деле превратилась в миф, является обязательная дефрагментация индексов, если в данные индекса достаточно часто вносятся изменения. Цель статьи развеять этот миф. Read the rest of this entry »
You are currently browsing the archive for the Tips for DBA category.
Миграция в новый кластер подразумевает, что для перемещаемой группы доступности необходимо создать новую первичную реплику на сервере в новом кластере. Основной целью планирования миграции группы доступности в другой кластер является минимизация времени недоступности ресурсов. Для этого ресурсы переезжают на новый, специально выделенный для этого сервер. Новый сервер вначале подключается, как вторичная реплика с синхронной фиксацией, а потом принимает на себя роль первичной реплики. Прослушиватель группы доступности удаляется из старого кластера и заново создаётся в новом кластере, вслед за созданием группы доступности.
Read the rest of this entry »
Если выполнение отключения 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;
Подробности можно найти тут: Manually Clearing the Query Store
Если в журнале приложений есть ошибки для 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” статьи: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms189067(v=sql.105)
Одной из обязательных задач администрирования баз данных MS SQL Server является периодическое восстановление баз, дабы убедиться, что база восстанавливается успешно. Ещё одной такой задачей является периодическая проверка баз посредством DBCC CHECKDB. Зачастую, полезно эти задачи объединить, и запускать проверку базы после восстановления её на специально предназначенном для этого сервере. Если у базы имеется несколько файловых групп и размер базы настолько большой, что проверка каждой занимает несколько часов, резонно проверять не всю база сразу, а поочерёдно все файловые группы. Сократить время проверки также можно отказавшись от проверки индексов, например вот так: DBCC CHECKFILEGROUP (‘PRIMARY’, NOINDEX). Read the rest of this entry »
Не существует рекомендованного Майкрософт способа уведомления администраторов о том, что SQL Server выгрузил дамп страниц памяти на диск. Также весьма затруднительно отслеживать такие дампы средствами SQL Server или операционной системы, поскольку во время выгрузки дампа работа сервера баз данных и большинства системных процессов «замирает». Однако, вполне возможно обнаружить последствия выгрузки дампа, поскольку в указанной для дампов папке вместе с файлами дампа появится файл с именем: «SQLDUMPER_ERRORLOG.log». Имя этого файла неизменно, на этом и основан предлагаемый вашему вниманию способ слежений за появлением новых дампов. Настройка пути к папке дампов хранится в системном реестре. По этому пути можно посредством PowerShell узнать существует ли в папке дампов файл с именем «SQLDUMPER_ERRORLOG.log». Такую проверку можно делать по расписанию в задании Агента SQL Server. Если файл обнаружен, то можно совершить необходимое действие. Например, в приведенном ниже сценарии будет отправлено письмо электронной почты на указанный список адресов. Отправку осуществит подсистема SQL Server DatabaseMail. Для корректной отправки сообщения нужно указать существующий почтовый профиль.
Обычно, администраторы изучают причины, вызвавшие создание дампа по файлам текстовых описаний дампа и логу. Вместе с этим можно переименовать и/или скопировать файлы дампа в другое место, или удалить. Также, можно составить сценарий PowerShell таким образом, чтобы необходимые действия выполнялись в дополнение к предлагаемому ниже примеру сценария: Read the rest of this entry »
По материалпм статьи: SQL 2016 – It Just Runs Faster: Automatic Soft NUMA
30 марта 2016
Автор: Nitin Verma – Principal SQL Server Developer, Bob Dorr – Principal SQL Server Escalation Engineer
Мощности серверного оборудования растут из года в год, что обусловлено многолетним развитием технологий изготовления процессоров. Анализируя результаты наших исследований того, как работает SQL Server на современном оборудовании, и как наши клиенты достигают оптимального для себя масштабирования вычислительных ресурсов, мы выдвинули на передний план дальнейшего развития сервера баз данных необходимость улучшения возможностей секционирования обслуживания нагрузки. В настоящее время, именно основанный на секционировании дизайн является самым распространённым способом локализации обслуживания нагрузки и улучшения производительности и масштабируемости. Примером того, как SQL Server использует секционирование нагрузки является объект CMemThread.