TG Telegram Group & Channel
Oracle Developer👨🏻‍💻 | United States America (US)
Create: Update:

Друзья, всем привет! 👋

Сегодня понедельник — самое время для технической задачки 🔥

Один из наших подписчиков прислал интересный кейс, и мы решили им поделиться с вами.

Итак, ситуация:

На проекте по импортозамещению выполнили миграцию с одной из западных CRM-систем на продукт собственной разработки.
В качестве СУБД используется Oracle 19c (Standard Edition).

Во время переноса:

🔶 для истории действий пользователей была создана таблица user_logs.
🔶 Объём — 3 миллиарда строк 🔥
🔶 По требованиям законодательства данные должны храниться не менее 5 лет.
🔶 Таблица НЕ секционирована (ограничения редакции SE).

Периодически нужно получать все события (event_type) по клиенту (client_id) за последние N дней.

Пример запроса:

SELECT event_type, event_date, description
FROM user_logs
WHERE client_id = :client_id
AND event_date >= SYSDATE - 90
ORDER BY event_date DESC;


❗️ Проблемка:

🔶 Запрос к одному клиенту выполняется 20–30 секунд.
🔶 Если клиент активный (около 100 000 событий за 3 месяца) — всё становится совсем грустно 🐌
- В плане видно Index Range Scan по индексу (client_id, event_date), но нагрузки на I/O всё равно большие 🤷‍♂️

Условия:

1️⃣ Materialized View не вариант — нет места под дублирование данных.
2️⃣ Переехать на Enterprise Edition в ближайшие месяцы нет возможности 🤷‍♂️

Вопрос: как ускорить выполнение запроса без секционирования

Кто решит — плюсик в карму и +100 к уважению в нашем чате Oracle-разработчиков 🚀

Разбор задачи, как всегда, в четверг 🎓

#oracle #оптимизация #задача #оптимизация #performance #Pavel_Dolganov

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Друзья, всем привет! 👋

Сегодня понедельник — самое время для технической задачки 🔥

Один из наших подписчиков прислал интересный кейс, и мы решили им поделиться с вами.

Итак, ситуация:

На проекте по импортозамещению выполнили миграцию с одной из западных CRM-систем на продукт собственной разработки.
В качестве СУБД используется Oracle 19c (Standard Edition).

Во время переноса:

🔶 для истории действий пользователей была создана таблица user_logs.
🔶 Объём — 3 миллиарда строк 🔥
🔶 По требованиям законодательства данные должны храниться не менее 5 лет.
🔶 Таблица НЕ секционирована (ограничения редакции SE).

Периодически нужно получать все события (event_type) по клиенту (client_id) за последние N дней.

Пример запроса:

SELECT event_type, event_date, description
FROM user_logs
WHERE client_id = :client_id
AND event_date >= SYSDATE - 90
ORDER BY event_date DESC;


❗️ Проблемка:

🔶 Запрос к одному клиенту выполняется 20–30 секунд.
🔶 Если клиент активный (около 100 000 событий за 3 месяца) — всё становится совсем грустно 🐌
- В плане видно Index Range Scan по индексу (client_id, event_date), но нагрузки на I/O всё равно большие 🤷‍♂️

Условия:

1️⃣ Materialized View не вариант — нет места под дублирование данных.
2️⃣ Переехать на Enterprise Edition в ближайшие месяцы нет возможности 🤷‍♂️

Вопрос: как ускорить выполнение запроса без секционирования

Кто решит — плюсик в карму и +100 к уважению в нашем чате Oracle-разработчиков 🚀

Разбор задачи, как всегда, в четверг 🎓

#oracle #оптимизация #задача #оптимизация #performance #Pavel_Dolganov

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10


>>Click here to continue<<

Oracle Developer👨🏻‍💻






Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)