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

Дополнительные сведения см. по следующей ссылке: https://docs.microsoft.com/en-us/sql/relational-databases/performance/performance-monitoring-and-tuning-tools?view=sql-server-2017 > (на английском языке).

Копия данных SQL Server, которую можно использовать для восстановления данных после сбоя. Резервная копия данных SQL Server создается на уровне базы данных или одного или нескольких файлов либо групп файлов. Невозможно создать резервные копии на уровне таблиц. В дополнение к резервным копиям данных для модели полного восстановления требуется создание резервных копий журнала транзакций.

Свойство базы данных, которое управляет поддержкой журнала транзакций в базе данных. Существует три модели восстановления: "простая", "полная" и "с неполным протоколированием". Модель восстановления базы данных определяет требования к резервному копированию и восстановлению.

Многофазный процесс, при котором копируются все страницы данных и журналов из указанной резервной копии SQL Server в указанную базу данных, а затем выполняется накат всех транзакций, зарегистрированных в резервной копии, путем применения записанных изменений с целью переноса данных во времени.

Для получения дополнительных сведений см. следующие разделы:

Масштабируемость - это способность приложения эффективно использовать большее количество ресурсов для выполнения более полезной работы.

Простейшее масштабируемое решение, доступное для применения в SQL Server, - масштабируемые общие базы данных. В этом сценарии создается база данных в SAN, к базе данных присоединяется до восьми экземпляров SQL Server, работающих на различных серверах, и начинается обработка запросов. Это классическое решение масштабирования в стиле "общий диск", в котором выполняется масштабирование вычислительной мощности, но используется только один образ данных на диске. На этом этапе у пользователей, знакомых с SQL Server, могут возникать примерно такие вопросы: "А что произошло с блокировкой? Мне казалось, что каждый экземпляр сервера SQL сохраняет собственные блокировки в собственной памяти". Это правильно. Каждый экземпляр будет сохранять свои собственные блокировки базы данных, и ни один из экземпляров не будет получать информацию о блокировках в других экземплярах. Единственный способ осуществления этого - отсутствие блокировок; таким образом, работа масштабируемых общих баз данных возможна, только если базы данных присоединяются в режиме "Только для чтения". Это означает, что масштабируемые общие базы данных отлично подходят для хранилищ данных или баз данных отчетов, но они не подходят для приложений, выполняющих обновление данных. Что касается характеристик данных, масштабируемые общие базы данных могут работать, только если частота обновлений равна нулю. Эти данные по определению являются историческими и, следовательно, ссылочными данными.

В MSSQL Server максимальное число байтов в любом ключе индекса не может превышать 900 байтов. Хотя ключ может быть определен с помощью столбцов переменной длины, максимальные размеры которых могут превышать 900, в этом случае в такие столбцы не должны вставляться строки объемом более 900 байт данных. (https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2014&redirectedfrom=MSDN.)