Долго commit, обновление мат. вьюхи

Коллеги добрый день.
Есть такая мат. вьюха.

CREATE MATERIALIZED VIEW MV_RMU_CALC
TABLESPACE TBS_REPMSG Pctfree 10 INITRANS 50 
PARALLEL LOGGING
REFRESH FORCE ON COMMIT
ENABLE QUERY REWRITE AS
SELECT
      T.USER_ID,
      T.ID_MSG_GROUP,
      SUM(EXPIRED * (1-DELETED)) e_c,
      SUM(READED * EXPIRED * (1-DELETED)) e_r,
      SUM((1-EXPIRED) * (1-DELETED)) a_c,
      SUM(READED * (1-EXPIRED) * (1-DELETED)) a_r,
      SUM(EXPIRED * (DELETED)) d_e_c,
      SUM(READED * EXPIRED * (DELETED)) d_e_r,
      SUM((1-EXPIRED) * (DELETED)) d_a_c,
      SUM(READED * (1-EXPIRED) * (DELETED)) d_a_r       
  FROM (SELECT
  RMU.ROWID RMU_ROWID,
  RM.ROWID  RM_ROWID,
  RMU.USER_ID,
  RM.ID_MSG_GROUP,
  RMU.READED,
  RMU.DELETED,
  RM.ENABLED,
  RM.EXPIRED
  FROM
      REP_MESSAGES_USERS RMU,
      REP_MESSAGES RM
 WHERE
      RMU.MESS_ID=RM.ID AND 
      RM.ENABLED=1) T
 GROUP BY T.USER_ID,
      T.ID_MSG_GROUP;

2 базовые таблицы,
REP_MESSAGES_USERS - привязка сообщений к пользователям (3 млн.) - hash партиц. по
USER_ID
REP_MESSAGES RM - сообщение (10 млн.) - Партицирована по дате начала действ. сообщ.

DELETED - поле в REP_MESSAGES (0,1).

Всё бы хорошо, но вот такой оператор

update rep_messages_users rmu
   set rmu.deleted=0
   where rmu.mess_id in (265019,269199)

Сам по себе выполняется быстро, поиск по ПК.
А вот при commit происходит одновление мат. вьюхи, и тут секунд 9.

Подскажите куда копать?

Пока, что есть идея, делать
так. Изначально создаётся базовая таблица, структура что у мат. вьюхи.
А потом при выполнении оператора

update rep_messages_users rmu
   set rmu.deleted=0
   where rmu.mess_id in (265019,269199)

тут же в рамках транзакции вызывать функцию (другой оператор),
которая бы выполняла update на таблицу имитирующую мат. вьюху.,

По сути ведь меняется очень маленький объём данных, и пересчитывать/агрегировать не так много.

Журнал есть?

Вячеслав Любомудров,
Что за журнал?

И сорри, конечно так

update rep_messages_users rmu
   set rmu.deleted=0
   where rmu.mess_id in (265019,269199) and
         rmu.user_id=224

Метка об удалении ставится на привязку сообщения к пользователю,
а не на само сообщение.

По сути при данной операции мат., вьюха должна ("выполнить") сделать что-то наподобие.

SELECT
      T.USER_ID,
      T.ID_MSG_GROUP,
      SUM(EXPIRED * (1-DELETED)) e_c,
      SUM(READED * EXPIRED * (1-DELETED)) e_r,
      SUM((1-EXPIRED) * (1-DELETED)) a_c,
      SUM(READED * (1-EXPIRED) * (1-DELETED)) a_r,
      SUM(EXPIRED * (DELETED)) d_e_c,
      SUM(READED * EXPIRED * (DELETED)) d_e_r,
      SUM((1-EXPIRED) * (DELETED)) d_a_c,
      SUM(READED * (1-EXPIRED) * (DELETED)) d_a_r       
  FROM (SELECT
  RMU.ROWID RMU_ROWID,
  RM.ROWID  RM_ROWID,
  RMU.USER_ID,
  RM.ID_MSG_GROUP,
  RMU.READED,
  RMU.DELETED,
  RM.ENABLED,
  RM.EXPIRED
  FROM
      REP_MESSAGES_USERS RMU,
      REP_MESSAGES RM
 WHERE
      RMU.MESS_ID=RM.ID AND 
      RM.ENABLED=1
      -----------------------
      AND RM.ID IN (265019,269199)
      AND RMU.USER_ID=224
      -----------------------
      ) T
 GROUP BY T.USER_ID,
      T.ID_MSG_GROUP;

Выполняется мгновенно.

MATERIALIZED VIEW LOG
Он как раз используется для быстрого (FAST) обновления

Делаю их так:

create materialized view log on REP_MESSAGES_USERS with rowid;
create materialized view log on REP_MESSAGES with rowid;

Может помимо rowid, и другие поля добавить.
Подскажите.
Не пинайте., не знаком, зачем они нужны, эти журналы.

AlexGru

По сути при данной операции мат., вьюха должна ("выполнить") сделать что-то наподобие.

Можно снять трассировку сессии и посмотреть, что на самом деле выполняет сервер. Потом эти запросы оптимизировать.

А какой трассировки будет достаточно?
10046 или надо 10053?

Сделал трассировку 10046, в архиве.
Исходный файл трассировки, и прогнаный через tkprof, + c опцией aggregate=yes

AlexGru,