Встановлення SQL Server 2022

Microsoft SQL Server 2022 можна встановити за кілька натискань у майстрі, але стандартні параметри рідко підходять для робочого сервера. Помилки під час вибору дисків, облікових записів служб, collation або режиму автентифікації доводиться виправляти вже після запуску прикладних систем. Частина таких змін потребує простою, перенесення системних баз або повної повторної інсталяції екземпляра.

У цій інструкції розглянемо встановлення окремого екземпляра SQL Server 2022 Database Engine на Windows Server 2022. Підхід також можна застосувати до Windows Server 2019, якщо операційна система має актуальні оновлення та відповідає вимогам обраної редакції SQL Server.

Перед початком потрібно визначити майбутнє навантаження, модель ліцензування, вимоги прикладної системи та спосіб резервного копіювання. Якщо сервер входить до корпоративного домену, спочатку варто завершити створення нового домену Active Directory або приєднання вузла до наявного домену, а вже потім створювати доменні облікові записи для служб SQL Server.

Підготовка Windows Server і дискової підсистеми

Для SQL Server 2022 потрібна 64-бітна Windows Server, стабільне мережеве ім’я, статична IP-адреса та встановлені оновлення без незавершеного перезавантаження. Сервер не варто одночасно використовувати як контролер домену, файлове сховище, RDS Session Host або вузол із несумісним навантаженням. База даних передбачає інтенсивні операції з диском і пам’яттю, тому консолідація ролей ускладнює прогнозування продуктивності.

Перевірити версію системи, обсяг оперативної пам’яті та стан дисків можна через PowerShell від імені адміністратора:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, CsTotalPhysicalMemory
Get-Volume | Select-Object DriveLetter, FileSystem, Size, SizeRemaining, HealthStatus
Get-PendingReboot

Команда `Get-PendingReboot` доступна не в кожній системі. Якщо її немає, перевірте Windows Update вручну та перезавантажте сервер перед інсталяцією.

Для невеликого середовища достатньо розділити системний диск і дані SQL Server. Для інтенсивнішого навантаження доцільно передбачити окремі томи:

- `C:` — Windows Server і системні компоненти; - `D:` — файли даних MDF та NDF; - `L:` — журнали транзакцій LDF; - `T:` — файли бази `tempdb`; - `E:` — локальний буфер резервних копій, якщо він потрібний.

Окремі літери дисків не гарантують кращої швидкодії, якщо всі томи розміщені на одному фізичному масиві. Потрібно перевірити реальне розташування сховища, політику кешування контролера, відмовостійкість і затримку запису. Для NTFS-томів із файлами баз часто використовують розмір кластера 64 КБ. Форматування слід виконувати до перенесення даних і лише після перевірки вимог конкретної системи зберігання.

Створимо базові каталоги:

New-Item -ItemType Directory -Path D:\MSSQL\Data -Force
New-Item -ItemType Directory -Path L:\MSSQL\Log -Force
New-Item -ItemType Directory -Path T:\MSSQL\TempDB -Force
New-Item -ItemType Directory -Path E:\MSSQL\Backup -Force

Для служб Database Engine і SQL Server Agent бажано використовувати окремі доменні керовані облікові записи або gMSA. Не додавайте такі записи до локальної групи Administrators. Потрібні права призначає інсталятор. Винятком є право `Perform volume maintenance tasks`, яке вмикає Instant File Initialization і прискорює створення та збільшення файлів даних. Воно не поширюється на файли журналів транзакцій.

Планування ресурсів, оновлень і моніторингу варто включити до загального процесу обслуговування серверів, оскільки працездатність СУБД залежить не лише від параметрів самого екземпляра.

Встановлення SQL Server 2022 Database Engine

Завантажте офіційний інсталяційний образ SQL Server 2022 потрібної редакції та перевірте його контрольну суму. Для лабораторії підійде Developer Edition, але вона не ліцензується для робочого навантаження. Express Edition має обмеження на розмір бази, використання процесора та пам’яті. Standard і Enterprise потрібно обирати відповідно до функціональних вимог і моделі ліцензування.

Після монтування ISO запустіть `setup.exe` від імені адміністратора. У SQL Server Installation Center спочатку відкрийте розділ перевірки конфігурації, а потім виберіть створення нового автономного екземпляра.

На етапі **Feature Selection** для звичайного сервера баз даних достатньо компонента **Database Engine Services**. Не встановлюйте Machine Learning Services, PolyBase, Analysis Services або інші модулі без реальної потреби. Кожен додатковий компонент збільшує площу оновлення та кількість служб.

Для першого або єдиного екземпляра можна залишити ім’я `MSSQLSERVER`. Це default instance, до якого клієнти підключаються за DNS-іменем сервера без додаткового суфікса. Іменований екземпляр доречний, коли на вузлі працює кілька незалежних конфігурацій, але він ускладнює керування портами та підключеннями.

У розділі **Server Configuration** вкажіть підготовлені облікові записи служб. Для Database Engine задайте автоматичний запуск. SQL Server Agent також краще запускати автоматично, якщо через нього виконуватимуться резервні копії, перевірки цілісності або інші регламентні завдання.

Вибір collation потрібно узгодити з вимогами прикладної системи. Зміна серверного collation після інсталяції є складною операцією. Не обирайте значення лише за мовою інтерфейсу Windows. Деякі програми очікують конкретний регістр, кодову сторінку або двійковий порядок порівняння.

На сторінці **Database Engine Configuration** виконайте такі дії:

1. Додайте доменну групу адміністраторів SQL Server, а не лише персональний обліковий запис. 2. За можливості залиште Windows Authentication. Mixed Mode вмикайте тільки тоді, коли програма справді потребує SQL-логінів. 3. На вкладці Data Directories задайте окремі шляхи для даних, журналів, `tempdb` і резервних копій. 4. На вкладці TempDB створіть кілька однакових за розміром файлів даних із однаковим кроком автозбільшення. 5. Увімкніть Instant File Initialization, якщо політика захисту це дозволяє.

Для сервера з невеликим навантаженням не потрібно одразу створювати десятки файлів `tempdb`. Поширена початкова конфігурація — до восьми файлів, але їх кількість треба визначати за числом логічних процесорів і фактичним очікуванням на сторінках розподілу. Важливіше, щоб файли мали однаковий початковий розмір і фіксований приріст у мегабайтах, а не у відсотках.

Перед натисканням **Install** збережіть конфігураційний файл. Він стане основою для відтворюваної інсталяції на іншому сервері. Не зберігайте паролі служб у відкритому вигляді в репозиторії або загальнодоступному каталозі.

Налаштування після інсталяції

SQL Server Management Studio не входить до Database Engine і встановлюється окремо. Встановіть актуальну версію SSMS на адміністративну станцію або сервер керування. Постійно працювати в графічній оболонці безпосередньо на сервері баз даних необов’язково.

Після першого підключення перевірте версію екземпляра:

SELECT
    SERVERPROPERTY('ServerName') AS server_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel') AS product_level;

Інсталяційний образ зазвичай не містить останнього Cumulative Update. Завантажте актуальний CU для SQL Server 2022, перевірте примітки до випуску та встановіть його спочатку в тестовому контурі. Після оновлення переконайтеся, що служби запустилися, системні бази доступні, а номер збірки змінився.

За замовчуванням SQL Server може використовувати майже всю доступну оперативну пам’ять. Параметр `max server memory` потрібно обмежити, залишивши ресурс операційній системі, драйверам, антивірусу, агентам резервного копіювання та іншим службам. Наприклад, на виділеному сервері з 32 ГБ RAM можна почати з 24 ГБ для Database Engine і скоригувати значення після спостереження:

EXEC sys.sp_configure N'show advanced options', 1;
RECONFIGURE;
EXEC sys.sp_configure N'max server memory (MB)', 24576;
RECONFIGURE;

Це лише приклад, а не універсальне значення. На сервері з кількома екземплярами ліміти потрібно розподілити між ними. Мінімальну пам’ять не варто встановлювати без розуміння її поведінки.

Для зменшення витрат кешу на велику кількість одноразових запитів можна ввімкнути оптимізацію ad hoc workloads:

EXEC sys.sp_configure N'optimize for ad hoc workloads', 1;
RECONFIGURE;

TCP/IP вмикається через **SQL Server Configuration Manager**. Для default instance доцільно призначити статичний TCP-порт, наприклад 1433, очистити поле динамічних портів і перезапустити службу Database Engine. Відкривайте порт Windows Firewall лише для довірених підмереж або конкретних серверів застосунків:

New-NetFirewallRule `
  -DisplayName 'SQL Server 2022 TCP 1433' `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 1433 `
  -RemoteAddress 10.10.20.0/24 `
  -Action Allow

Перевірка мережевого доступу з клієнтського вузла:

Test-NetConnection -ComputerName sql01.corp.local -Port 1433

Якщо встановлено `sqlcmd`, локальну автентифікацію Windows можна перевірити так:

sqlcmd -S tcp:localhost,1433 -E -Q "SELECT @@SERVERNAME, @@VERSION;"

Для шифрування з’єднань випустіть сертифікат на DNS-ім’я сервера, установіть його в локальне сховище комп’ютера, надайте службі SQL Server доступ до приватного ключа та виберіть сертифікат у SQL Server Configuration Manager. Примусове шифрування вмикайте після перевірки всіх клієнтських драйверів.

Поточний стан Windows, служб, подій і дисків доцільно контролювати в межах адміністрування серверів Windows і Linux, доповнюючи системний моніторинг метриками SQL Server.

Перевірка баз, резервного копіювання та безпеки

Перед передаванням сервера прикладній команді перевірте системні бази, журнал помилок, доступність SQL Server Agent і каталоги резервного копіювання. Обліковий запис служби SQL Server повинен мати доступ до каталогів даних, а SQL Server Agent — до ресурсів, які використовуватимуть його завдання.

Створіть тестову базу та переконайтеся, що її файли потрапляють на правильні диски:

CREATE DATABASE InstallationCheck;
GO

SELECT
    DB_NAME(database_id) AS database_name,
    name AS logical_name,
    physical_name,
    size * 8 / 1024 AS size_mb
FROM sys.master_files
WHERE database_id = DB_ID(N'InstallationCheck');
GO

Після перевірки тестову базу можна видалити:

DROP DATABASE InstallationCheck;
GO

Для кожної робочої бази визначте recovery model. `FULL` дає змогу відновлюватися до потрібного моменту часу, але вимагає регулярних резервних копій журналу транзакцій. Якщо їх не виконувати, файл LDF продовжуватиме зростати. Модель `SIMPLE` не замінює повні резервні копії та не підходить для всіх сценаріїв.

Приклад повної резервної копії з контрольною сумою та стисненням:

BACKUP DATABASE [AppDb]
TO DISK = N'E:\MSSQL\Backup\AppDb_full.bak'
WITH INIT, COMPRESSION, CHECKSUM, STATS = 10;
GO

RESTORE VERIFYONLY
FROM DISK = N'E:\MSSQL\Backup\AppDb_full.bak'
WITH CHECKSUM;
GO

`RESTORE VERIFYONLY` перевіряє структуру набору, але не гарантує успішного відновлення в реальній аварії. Потрібно регулярно виконувати тестове відновлення на окремому екземплярі, запускати `DBCC CHECKDB` і фіксувати фактичний час процедури.

Не надавайте прикладним обліковим записам роль `sysadmin`. Створюйте окремі логіни та користувачів із мінімальними дозволами. Персональні адміністратори мають входити через доменні записи, а не користуватися спільним SQL-логіном. Обліковий запис `sa` у Mixed Mode слід захистити довгим унікальним паролем, а за можливості перейменувати або вимкнути після створення альтернативного адміністративного доступу.

Типові помилки

**Усі файли розміщені на системному диску.** Заповнення `C:` може зупинити не лише базу, а й Windows Server. Дані, журнали та резервні копії потрібно рознести відповідно до архітектури сховища.

**Не обмежено max server memory.** Database Engine поступово займає пам’ять, а операційна система починає активно використовувати файл підкачки. Наслідком стають затримки, нестабільність служб і складна діагностика.

**Автозбільшення налаштовано у відсотках.** Чим більший файл, тим більшим стає наступне розширення. Використовуйте фіксований приріст у мегабайтах і заздалегідь виділяйте достатній початковий розмір.

**Залишено динамічний TCP-порт.** Після перезапуску або зміни конфігурації клієнти можуть втратити доступ. Для серверного екземпляра простіше використовувати документований статичний порт і точкові правила firewall.

**Встановлено застарілу збірку з ISO.** Після базової інсталяції потрібно застосувати перевірений актуальний CU та включити SQL Server до процесу керування оновленнями.

**Резервні копії зберігаються тільки на тому самому сервері.** Втрата вузла або сховища знищить одночасно бази й копії. Файли необхідно переносити в незалежне захищене сховище та перевіряти відновлення.

**Антивірус сканує MDF, LDF і tempdb у реальному часі.** Це може створювати затримки й блокування. Виключення потрібно налаштовувати за рекомендаціями Microsoft і внутрішньою політикою захисту, не вимикаючи антивірус повністю.

Висновок

Якісне встановлення SQL Server 2022 починається не із запуску `setup.exe`, а з підготовки ресурсів, сховища, облікових записів і моделі відновлення. Під час інсталяції потрібно правильно вибрати компоненти, collation, каталоги, конфігурацію `tempdb` та адміністративні групи. Після встановлення слід застосувати актуальний CU, обмежити пам’ять, увімкнути потрібний мережевий протокол, перевірити firewall і протестувати резервне копіювання.

Перед запуском робочого навантаження зафіксуйте параметри екземпляра, порти, версію збірки, місця зберігання файлів, розклад копіювання та відповідальних адміністраторів. Така документація спрощує оновлення, аудит, діагностику й відновлення після аварії.