Контекст: CDC на Exadata — где всплывают сюрпризы
Когда банк переносит хранилище на Exadata, CDC сталкивается с двумя особенностями платформы: Hybrid Columnar Compression (HCC) и строгая модель supplemental logging на источнике. Обе не блокируют репликацию, но обе любят всплывать именно на нагрузочном тесте, если их не проверить заранее. Эта статья — честный DBA-разбор из обзора CDC в банке. Все примеры обезличены, технические утверждения сверены с документацией Qlik и поведением Oracle.
Full Load на Oracle target: Direct Path и parallel load
Для первичной заливки на Oracle/Exadata у Qlik есть механизмы ускорения:
- Use direct path full load (по умолчанию включён для Oracle target) — заливка через OCI Direct Path, в обход обычного пути, bulk-insert. Требует соответствующих прав на target.
- Parallel Load — разбивка source-таблицы по партициям, суб-партициям или диапазонам с параллельным чтением; ускоряет Full Load крупных объектов в разы.
Это штатные инструменты, и для большинства таблиц их достаточно. Нюанс начинается там, где целевые таблицы сжаты HCC.
HCC честно: компрессия живёт только на direct path
Ключевой факт об HCC, который определяет всё поведение: HCC сжимает строки только при загрузке через direct path (CREATE TABLE AS, direct-path INSERT с APPEND, ALTER TABLE MOVE). Строки, вставленные обычным (conventional) путём в HCC-таблицу, ложатся несжатыми, в обычные блоки.
Что это значит для CDC. Поток изменений (apply фазы CDC) применяется обычным DML, не direct path. Поэтому строки, прилетающие через CDC в HCC-таблицу на Exadata, не получают HCC-компрессию и занимают больше места, чем «родные» сжатые данные. Это не баг Qlik — так устроен HCC в Oracle. Практический вывод: для постоянно меняющихся таблиц HCC на target плохо сочетается с онлайн-CDC; компрессию приходится восстанавливать периодическим ALTER TABLE MOVE или не применять HCC к «горячим» CDC-таблицам.
На стороне источника тоже есть граница: по документации Qlik при чтении через Replicate Log Reader уровень HCC Query Low поддерживается только в режиме Full Load. То есть реплицировать CDC-изменения из HCC-сжатых таблиц-источников нужно проверять под конкретный уровень компрессии.
SELECT table_name, compress_for FROM user_tables WHERE compress_for LIKE 'QUERY%' OR compress_for LIKE 'ARCHIVE%' покажет HCC-объекты.Supplemental logging: частый и решаемый класс ошибок
CDC из Oracle требует supplemental logging на реплицируемых таблицах. На пилотах ошибка «не все поля учтены в supplemental log» — один из самых частых сюрпризов, особенно при переезде на новый target: те же архив-логи, та же таблица, но на одном таргете поток поднимается, а на другом ругается на supplemental.
В подавляющем большинстве случаев причина — права и фактическое состояние логирования, а не инструмент. Практический подход:
- Проверить, что supplemental logging действительно включён на всех нужных колонках таблицы, а не только на части.
- Решить модель прав: либо учётке Replicate выдаётся грант на
ALTER(тогда логирование добавляется само), либо DBA выполняетALTER TABLE ... ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNSв тех-окно. - Убедиться, что target не ограничивает число соединений на таблицу — Qlik резервирует несколько соединений на таблицу, и жёсткие лимиты на target могут мешать.
Batch Optimized Apply: где ограничения для банка
Для Oracle target Qlik применяет изменения через Batch Optimized Apply (bulk-DML через промежуточную таблицу). Тут важно честно перечислить границы, потому что в банковской схеме с constraints они срабатывают:
- Bulk-режим имеет ограничения по таблицам с foreign keys и по LOB-колонкам без заданного лимита размера — такие таблицы уходят в transactional apply и идут медленнее.
- Параллельное применение изменений по нескольким таблицам не поддерживается для Oracle target (это для ряда облачных хранилищ). Для Oracle используется bulk-apply через промежуточную таблицу.
Вывод: на Exadata часть тяжёлых таблиц с FK и LOB всё равно будет применяться transactional-режимом. Это нужно заложить в ожидания по латентности заранее.
Чек-лист перед нагрузочным тестом на Exadata
- Найти HCC-таблицы на source и target (
compress_for); решить стратегию для «горячих» CDC-таблиц. - Подтвердить уровень HCC-компрессии источника и режим чтения (Replicate Log Reader, Full Load vs CDC).
- Проверить supplemental logging на всех колонках нужных таблиц; согласовать модель прав (грант на
ALTERили DBA-окно). - Выписать таблицы с FK и крупными LOB — они пойдут transactional apply; оценить их латентность отдельно.
- Снять pre-state метрик до пиковой нагрузки, чтобы было с чем сравнивать.
Мостик: альтернатива HCC-боли на target
Часть проблем с HCC на CDC-таргете снимается сменой самого таргета. Если целевое хранилище для аналитики — не Oracle/Exadata, а lakehouse на Apache Doris / VeloDB, то компрессия и обновления решаются на стороне Doris (columnar storage, обновления по Unique Key), а Qlik Replicate просто стримит CDC-поток в него. Это убирает конфликт «онлайн-CDC против HCC» и даёт быструю аналитику для отчётности, скоринга и RegTech.