Иногда случается, что службы SQL Server могут по-прежнему существовать на сервере, но связанные записи SQL Server отсутствуют в «Программах и компонентах». Это может происходить из-за отсутствующих или повреждённых записей реестра, неполного удаления или неудачных действий по установке исправлений.
19.10.26
Очистка установки SQL Server с помощью UninstallString, когда запись в «Программах и компонентах» отсутствует
Исправление безопасности для SQL Server 2025 CU9 - KB5126967
Описание: KB5126967
Скачать: SQLServer2025-KB5126967-x64.exe
Дата выпуска: 13 октября 2026 г.
SQL Server 2025 — Версия: 17.0.5015.4
Краткий перечень исправлений:
- PolyBase: усилена проверка данных, устранены падения при работе с внешними источниками, добавлена валидация схемы delta-таблиц, исправлена небезопасная десериализация очереди отката, обновлена обработка разделяемой памяти.
- Backup Restore (VDI): устранены переполнения буфера и выходы за границы памяти при открытии виртуальных устройств и обработке данных; ужесточена проверка размеров и границ.
- Extended Events: устранены уязвимости раскрытия информации и отказа в обслуживании при чтении специально сформированных файлов .xel.
- Extensibility: обновлён сторонний компонент распаковки архивов; исправлено небезопасное чтение памяти в параметрах AI_GENERATE_EMBEDDINGS; устранены повреждения и раскрытие памяти в парсинге протокола SQL Satellite.
- Replication: повышена безопасность и надёжность очередей обновляемых подписок, метаданных безопасности, Log Reader Agent, change feed и потоковой передачи событий; исправлено переполнение буфера при >250 записей
- WebSync; усилены проверки авторизации; исправлены проблемы валидации данных.
- High Availability: добавлена проверка размера фрагментов FILESTREAM на вторичных репликах.
- Query Store: улучшена обработка входных данных Showplan.
- Distributed Query: исправлен сбой подключений через MSDASQL при отсутствии UID в строке провайдера.
- SQL Trace: ограничена обработка LoginSid размером внутреннего буфера для предотвращения выхода за границы.
6.11.25
Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering?
Должен ли SQL Server DBA понимать, как устроен кластер Windows Server Failover Clustering (WSFC), уметь создавать его или диагностировать проблемы? Или нам, DBA, лучше не выходить за рамки своей зоны? В некоторых организациях проведена чёткая граница между тем, что можно и чего нельзя DBA, а роли инфраструктуры отданы системным администраторам (SA). Это нормально, но это не означает, что DBA не должен уметь разбираться с проблемами FCI (Failover Cluster Instance) или AG (Availability Group) после непланового отказа на уровне кластера. (Да, AG можно создать и без кластера, но здесь мы этот вариант не рассматриваем.)
17.9.25
Всё, что нужно знать про управление ключами TDE при восстановлении базы данных
Прозрачное шифрование данных (TDE) в Azure SQL с ключом, управляемым клиентом (Customer-Managed Key, CMK), поддерживает сценарий «принеси свой ключ» (Bring Your Own Key — BYOK) для защиты данных в состоянии покоя и даёт возможность разделения обязанностей по управлению ключами и данными. При клиентском управлении TDE пользователь отвечает за жизненный цикл ключей (создание, загрузка, ротация, удаление), права на их использование и аудит операций с ключами. Ключ, используемый для шифрования ключа шифрования базы данных (Database Encryption Key, DEK), называемый TDE-протектором, — это асимметричный ключ, которым управляет клиент и который хранится в Azure Key Vault.
После включения TDE с использованием ключа из Key Vault новые резервные копии продолжают шифроваться с использованием того же TDE-протектора. Смена TDE-протектора не изменяет уже созданные резервные копии — чтобы восстановить резервную копию, зашифрованную ключом Key Vault, необходимо, чтобы материал соответствующего ключа был доступен серверу, на который выполняется восстановление. Особенность реализации TDE требует, чтобы для успешного восстановления были доступны как текущий, так и предыдущие TDE-протекторы. Рекомендуется сохранять все предыдущие версии протектора в хранилище ключей, чтобы иметь возможность восстановить резервные копии базы данных.
В этой статье подробно объясняются, какие ключи должны быть доступны для восстановления базы данных и почему это необходимо.
6.9.25
Развёртывание SQL Server одним скриптом (dbatools)
В этой и двух последующих статьях я соберу различные команды из модуля dbatools в набор скриптов, которые смогут выполнить полное развёртывание SQL Server, проверить основные показатели работоспособности и конфигурации, а также привести в норму уже существующий экземпляр. Это будет рассказ об установке с нуля: это будет не только установка самого SQL Server, но и настройка хоста, конфигурация экземпляра, развёртывание задач обслуживания — в общем, всё, о чём я додумался.
25.4.23
Tips for DBA: Store Performance Counters in Database (Job-Step: Power Shell)
С помощью Power Shell и нового в SQL Server 2008 типа шага в заданиях по расписанию, который позволяет запускать под управлением SQL Server Agent сценарии Power Shell, теперь можно получить абсолютно любые счётчики производительности. Причём, сделать это можно как для локального, так и удалённого в сети сервера. А получение сведений о счётчиках посредством WMI избавляет от необходимости агрегации сырых значений, что делает этот метод простым и понятным.
21.4.23
Tips for DBA: Logical Disk FreeSpace Notification
В SQL Server с помощью службы SQL Server Agent и PowerShell можно достаточно просто соорудить задание, которое будет заглядывать в метаданные WMI локального или удалённого сервера, и сообщать по электронной почте, в случае если свободное место на указанном диске перешагнуло заданный порог. Ниже представлен облегчённый концепт сценария подобного задания (расписаний в нём нет и данные берутся по локальному серверу). Вам нужно будет заменить фиктивный адрес на реальный и указать почтовый профиль, если нельзя воспользоваться профилем по умолчанию.
19.4.23
Сравнения списка объектов SQL Server в PowerShell на примере сравнения логинов на двух серверах
14.4.23
Tips for DBA: Scripting jobs using Powershell (separated files)
Вашему вниманию предлагается сильно упрощённый пример сценария Powershell, который предназначен для скриптования заданий SQL Server в отдельные файлы. Тут используется папка для файлов C:\TEMP, которая должна быть предварительно создана и, желательно, пуста. Поскольку имена заданий будут использованы в качестве имён файлов, желательно, что бы в них не использовались недопустимые для имён файлов символы. Если это неудобно, попробуйте внести изменения в то место сценария, где подобные символы заменяются на пробелы.



