Налаштування СУБД під UBD: MS SQL / Oracle / DB2

UBD працює з трьома основними СУБД: Microsoft SQL Server, Oracle Database, IBM Db2. Для кожної є специфічні параметри, що дають істотний приріст продуктивності. Стаття — для DBA або системного адміністратора, який налаштовує СУБД під UBD-навантаження.

Загальні принципи

Незалежно від конкретної СУБД, три речі найбільше впливають на продуктивність:

Memory tuning

Кеш-буфер БД (buffer pool, SGA, bufferpool — назва залежить від СУБД) — основний споживач пам’яті. Принцип: гарячі дані повинні поміщатися у пам’ять. Якщо БД 100 GB, а кеш-буфер 16 GB — більшість запитів читає з диска, що на порядки повільніше.

Орієнтовний розмір кеш-буфера: 60-80% RAM сервера БД. Решта — для ОС, тимчасових структур, з’єднань.

Statistics

Оптимізатор запитів використовує статистику для побудови плану виконання. Застаріла статистика → погані плани → повільні запити.

Принцип: статистика автоматично оновлюється, але для активно змінюваних таблиць — додатково ручне оновлення раз на тиждень.

Indexing

UBD генерує запити через свою ORM-логіку. Найчастіше — фільтрація по статусу, даті, ID власника, tenant_id. Індекси на ці колонки обов’язкові. Без них — повний scan таблиці на кожний запит.

Microsoft SQL Server

Max degree of parallelism (MAXDOP)

Default: 0 (auto, всі ядра). Оптимально для UBD: 4-8.

SQL Server може паралелити один запит на кілька ядер. Для аналітичних запитів — це добре. Для OLTP-навантаження UBD (багато коротких запитів) — поганий компроміс: один запит займає кілька ядер, інші запити чекають.

Налаштування: EXEC sp_configure 'max degree of parallelism', 4;

tempdb

tempdb — спільна тимчасова БД. SQL Server активно використовує її для сортувань, тимчасових таблиць, snapshot isolation. Вузьке місце на навантажених системах.

Налаштування:

• Кілька файлів tempdb (1 файл на 2-4 ядра, до 8 файлів). Це зменшує конкуренцію за page allocation.
• tempdb на окремому диску, бажано NVMe.
• Початковий розмір файлів — більший за очікуваний пік, щоб уникнути auto-growth у бойовий час.

Snapshot isolation

Для UBD рекомендується READ COMMITTED SNAPSHOT. Це зменшує блокування читання-запису: читачі бачать «знімок» даних, не чекають на закінчення транзакції-писача.

Налаштування: ALTER DATABASE ubd SET READ_COMMITTED_SNAPSHOT ON;

Ціна: додаткове використання tempdb для version store. Враховувати при tempdb sizing.

Oracle Database

SGA / PGA

SGA — спільна область пам’яті (buffer pool, shared pool, redo buffers). PGA — приватна область сесій.

Для UBD типове співвідношення: SGA 60% RAM, PGA 20% RAM, решта — ОС. Конкретно: на сервері 96 GB — SGA 58 GB, PGA 20 GB.

Параметри: sga_max_size, sga_target, pga_aggregate_target. З Oracle 11g+ доступний automatic memory management — спрощує налаштування.

Sequence caching

UBD активно використовує sequence для генерації первинних ключів. Default CACHE 20 — мало для високого навантаження.

Налаштування: ALTER SEQUENCE my_seq CACHE 1000;. Кеш у RAC-конфігурації — окрема історія, потрібен NOORDER щоб уникнути cross-instance синхронізації.

AWR-аналіз

Automatic Workload Repository — стандартний інструмент Oracle для аналізу продуктивності. Перед tuning обов’язково — AWR-звіт за пік-годину.

На що дивитись: Top SQL by elapsed time, Top events, latch contentions. Найчастіше виявляються 5-10 запитів, що дають 80% загального часу — їх і tunуємо.

IBM Db2

Bufferpool

Аналог buffer pool. Для UBD: окремий bufferpool для системних tablespace, окремий для даних. Розмір — 60-80% RAM.

Налаштування: CREATE BUFFERPOOL ubd_bp SIZE 16000000 PAGESIZE 8K; (значення у сторінках, не байтах).

Lock list

Default: 50 сторінок. Оптимально: AUTOMATIC або великий розмір (5000+).

Замала LOCKLIST → lock escalation (рядки → таблиця) → блокування. Симптом: SQL0911N deadlock-помилки у логах.

Налаштування: UPDATE DB CFG FOR ubd USING LOCKLIST AUTOMATIC;

RUNSTATS

Аналог UPDATE STATISTICS у MS SQL. Для активно змінюваних таблиць — щонайменше раз на тиждень з WITH DISTRIBUTION AND DETAILED INDEXES ALL.

Типові SQL-патерни UBD

УBD генерує запити певних типів. Розуміння цих патернів допомагає правильно індексувати:

• Фільтрація по tenant_id + status: композитний індекс (tenant_id, status).
• Сортування за created_at DESC: індекс з DESC для уникнення sort step.
• Lookup по зовнішньому ключу: індекси на всіх FK обов’язково.
• Авторизаційні запити по owner_id: індекс на owner_id.
• Audit log queries по date range: partition по даті + індекс на user_id.

Коли DBA, коли UBD-консультант