Oracle Database¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Oracle Database 19c; edition/options проверять отдельно. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. Instance объединяет SGA и background processes; database — persistent datafiles, control files и redo logs. Sessions выполняют SQL в транзакциях, schema задаёт объекты и constraints. Oracle 19c не следует смешивать с облачными autonomous-сервисами или возможностями другой edition.

flowchart LR
  Session --> Buffer[Buffer cache and undo]
  Buffer --> Redo[Redo log and LGWR]
  Redo --> Commit[Durable commit]
  Buffer --> Data[DBWR datafile writes]
  Redo --> Guard[Configured Data Guard transport]

2. Физическое хранение и путь записи¶

Heap segments состоят из extents/blocks; buffer cache обслуживает изменённые blocks. Изменение порождает redo, а undo records позволяют rollback и consistent read. LGWR пишет redo; DBWR позже сохраняет dirty buffers. COMMIT не требует немедленно переписать все data blocks, но должен соблюдать выбранный commit/durability режим.

Источники механизма: документация 3.

3. Индексы и путь чтения¶

B-tree leaf entries связывают indexed key и rowid; index-organized table хранит rows в структуре primary-key index. Bitmap indexes эффективны в подходящем аналитическом доступе, но их конкурентные изменения могут блокировать значительно шире одной бизнес-строки. Function-based indexes требуют совпадения выражения и корректных statistics; full scan может быть дешевле невыборочного index lookup.

Источники механизма: документация 4.

4. Транзакции и consistency guarantees¶

READ COMMITTED обеспечивает statement-level read consistency через undo; SERIALIZABLE фиксирует transaction snapshot, но может завершиться ORA-08177. Это не PostgreSQL SSI и не доказательство отсутствия write skew для любого межстрочного инварианта. READ ONLY подходит для согласованного чтения. Undo retention и доступность старых версий ограничивают длительность запроса: snapshot too old не лечится бесконечным retry без анализа.

Источники механизма: документация 2.

5. Репликация, partitioning и sharding¶

Data Guard redo transport/apply и режим protection определяют последствия failover. RAC — несколько instances, обращающихся к общей database, с Cache Fusion; это не независимые shards. Partitioning делит таблицы и indexes внутри database, а Oracle Sharding — отдельная технология с ограничениями/лицензированием. Применимость функций проверять по edition и договору.

6. Конкурентная запись и конфликты¶

Row locks сериализуют conflicting DML; readers обычно используют undo, не ожидая row lock для consistent read. Для двух account rows нужен единый lock order. Unique constraints защищают idempotency key, а retry проверяет payload. Distributed transaction через database links может использовать 2PC; внешнее HTTP-подтверждение в него автоматически не входит.

Источники механизма: документация 1, документация 2.

7. Отказы и восстановление¶

Instance recovery применяет redo и откатывает незавершённые изменения с undo. Media recovery требует backup и archived redo; RMAN обеспечивает управляемый lifecycle backup/recovery. Control file/catalog и encryption keys — часть DR. In-doubt distributed transactions требуют решения координатора, а не ручного «снять lock» без проверки исхода.

Источники механизма: документация 5.

8. Масштабирование и ограничения¶

Scale-up и RAC уменьшают разные ограничения; горячий block может создавать межinstance cache traffic. Partition pruning и partition-wise operations помогают только при подходящем запросе. Добавление RAC instance не устраняет serial access к одному счёту. Для global shards надо заранее определить cross-shard transaction policy.

9. Performance trade-offs¶

Индексы и materialized views ускоряют чтение ценой redo/undo и обслуживания. Частые COMMIT уменьшают lock duration, но могут увеличить commit waits и нарушить business atomicity. Большой undo помогает длинным snapshots, но не создаёт бесконечную историю. Выбор требует оценки лицензий, hardware и operations наряду с query cost.

10. Мониторинг и эксплуатация¶

V$SESSION, V$SYSTEM_EVENT, V$SQL, V$LOCK, redo/undo pressure, archive destination fullness, Data Guard transport/apply lag и RMAN jobs. AWR/ASH и diagnostic packs использовать только при наличии соответствующих прав. Runbook должен различать lock wait, I/O wait и log file sync, прежде чем менять параметры.

11. Сценарии FinTech и iGaming¶

INFERENCE. Core banking/settlement с существующей Oracle-экосистемой, строгими constraints и отработанным recovery. Outbox в той же local transaction полезен для интеграции. Наличие Oracle не доказывает характеристики конкретного банка; здесь корпоративных кейсов не заявлено.

12. Когда не выбирать¶

Не выбирать только ради «enterprise» при отсутствии лицензии/операционной компетенции и при простой embedded analytics. RAC не является бесплатным решением global multi-writer partitions. Если система требует произвольного horizontal key distribution, сначала проверить sharding restrictions.

13. Вопросы на собеседовании¶

Зачем одновременно redo и undo? Redo восстанавливает изменения после crash, undo обслуживает rollback и consistent reads.

Почему COMMIT не ждёт записи всех blocks? Durability опирается на корректно сохранённый redo и recovery.

RAC — sharding? Нет: shared database и координация cache отличаются от независимых data shards.

14. Практические SQL/config примеры¶

CREATE TABLE wallet_balance (
  account_id NUMBER(19) PRIMARY KEY,
  currency CHAR(3) NOT NULL,
  amount_minor NUMBER(20,0) NOT NULL,
  CONSTRAINT balance_nonnegative CHECK (amount_minor >= 0)
);
SELECT account_id, amount_minor FROM wallet_balance
WHERE account_id = 101 FOR UPDATE;
ROLLBACK;

DDL не создаёт полноценный ledger: нет journal и idempotency. Oracle runtime недоступен; parser check не подтверждает locking/recovery. Практика: спроектировать RMAN restore с потерей control file и отдельно потерей primary site.

15. Дополнительные источники¶

Типичные ошибки проектирования¶

Игнорировать выбранный engine/consistency mode; считать replica backup; повторять ambiguous write без idempotency; переносить guarantee другой СУБД. Конкретные опасные случаи разобраны в разделах 4–7.

Практические упражнения¶

Для примера выше опишите успешный commit с потерянным ответом и потерю primary. Укажите authoritative copy, способ обнаружения результата, допустимый retry и процедуру restore. Выполните эксперимент на выбранной версии; текущие проверки не заменяют его.