Должен ли SQL Server DBA понимать, как устроен кластер Windows Server Failover Clustering (WSFC), уметь создавать его или диагностировать проблемы? Или нам, DBA, лучше не выходить за рамки своей зоны? В некоторых организациях проведена чёткая граница между тем, что можно и чего нельзя DBA, а роли инфраструктуры отданы системным администраторам (SA). Это нормально, но это не означает, что DBA не должен уметь разбираться с проблемами FCI (Failover Cluster Instance) или AG (Availability Group) после непланового отказа на уровне кластера. (Да, AG можно создать и без кластера, но здесь мы этот вариант не рассматриваем.)
6.11.25
Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering?
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, которая должна быть предварительно создана и, желательно, пуста. Поскольку имена заданий будут использованы в качестве имён файлов, желательно, что бы в них не использовались недопустимые для имён файлов символы. Если это неудобно, попробуйте внести изменения в то место сценария, где подобные символы заменяются на пробелы.


