Materialized View быстрое обновление занимает много времени

Question

У меня есть большая таблица, которая реплицируется из Oracle 10.2.0.4 в базу данных Oracle 9i с использованием репликации MView по сети. Основная таблица составляет около 50 ГБ, 160 МБ строк, и в день появляется около 2–3 МБ новых или обновляемых строк.

В основной таблице есть материализованный журнал представлений, созданный с использованием rowid.

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

Тем не менее, быстрое обновление изо всех сил пытается не отставать. Похоже, что для обновления Oracle требуется два запроса к таблице mlog и master, первый выглядит так:

SELECT          /*+ */
   DISTINCT "A1"."M_ROW$$"
       FROM "GENEVA_ADMIN"."MLOG$_BILLSUMMARY" "A1"
      WHERE "A1"."M_ROW$$" <> ALL (SELECT "A2".ROWID
                                     FROM "GENEVA_ADMIN"."BILLSUMMARY" "A2"
                                    WHERE "A2".ROWID = "A1"."M_ROW$$")
        AND "A1"."SNAPTIME$$" > :1
        AND "A1"."DMLTYPE$$" <> 'I'

Текущий план:

---------------------------------------------------------------
| Id  | Operation                     | Name                  |
---------------------------------------------------------------
|   0 | SELECT STATEMENT              |                       |
|   1 |  HASH UNIQUE                  |                       |
|   2 |   FILTER                      |                       |
|   3 |    TABLE ACCESS BY INDEX ROWID| MLOG$_BILLSUMMARY     |
|   4 |     INDEX RANGE SCAN          | MLOG$_BILLSUMMARY_AK1 |
|   5 |    TABLE ACCESS BY USER ROWID | BILLSUMMARY           |

Когда изменено 3M строк, этот запрос выполняется буквально навсегда - в принципе, он бесполезен. Однако, если я немного перезаписываю его и указываю полное сканирование основной таблицы и таблицы mlog, это завершается через 20 минут.

Проблема в том, что приведенный выше запрос исходит из внутренностей Oracle, и я не могу его изменить. Проблема в действительности заключается в операции FILTER в строке 2 - если бы я мог получить ее для полного сканирования обеих таблиц и хеш-соединения / анти-соединения, я уверен, что смогу завершить его достаточно быстро, но никакой подсказки, которые я предлагаю, не получит этот запрос, чтобы прекратить использование операции FILTER - возможно, он даже не действителен. Я могу использовать подсказки, чтобы получить полное сканирование обеих таблиц, но операция FILTER остается, и я понимаю, что она выполняет long 5 для каждой строки, возвращаемой строкой 3, которая будет 2-3 строки.

Кто-нибудь получил какие-либо идеи о том, как превратить этот запрос в план, который я хочу, без изменения фактического запроса, или, что лучше, о каких-либо способах заставить репликацию принять более разумный план для моих таблиц?

Спасибо

Стивен.

Answer 1

Как вы писали, запросы являются частью внутреннего механизма Oracle, поэтому ваши параметры настройки ограничены. Алгоритм быстрого обновления, кажется, ведет себя по-разному в более поздних версиях, проверьте анализ Альберто Dell’Era .

Вы также можете посмотреть профили SQL (функция 10g). С пакетом DBMS_SQLTUNE это должно позволить вам настраивать отдельные операторы SQL.

Answer 2

Как оценивается количество кардиналов для запроса на обновление по сравнению с фактическим количеством элементов? Возможно, статистика таблицы MLOG $ неверна.

Может быть, лучше не иметь статистики в таблице и блокировать ее, чтобы вызвать динамическую выборку, которая должна дать разумную оценку на основе нескольких предикатов в запросе.