Материализованный просмотр быстрого обновления с предложением HAVING?

В Oracle 11g Я пытаюсь создать материализованное представление с FAST REFRESH ON COMMIT, которое содержит предложение HAVING.Материализованный просмотр быстрого обновления с предложением HAVING?

Database Data Warehousing Guide говорит:

General Restrictions on Fast Refresh

The defining query of the materialized view is restricted as follows:

It cannot contain a HAVING clause with a subquery.

Но если добавить HAVING count(*)>1 (примечание: нет подзапросов) в противном случае рабочий материализованного представления, я получаю эту ошибку:

ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view

dbms_mview.explain_mview() говорит:

REFRESH_FAST     N 
REFRESH_FAST_AFTER_INSERT  N 2011 a HAVING clause is present

Фактические команды:

SQL> create materialized view mv1 refresh fast on commit as 
    2  select UserId, count(*) from USERS group by UserId; 

Materialized view created. 

SQL> DROP MATERIALIZED VIEW mv1; 

Materialized view dropped. 

SQL> create materialized view mv1 refresh fast on commit as 
    2  select UserId, count(*) from USERS group by UserId 
    3   having count(*)>1; -- the only difference 
    having count(*)>1 
        * 
ERROR at line 5: 
ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view

Примечание: Созданы материализованные журналы просмотра (в противном случае даже первый пример не будет работать).

Почему это не работает? Кто-нибудь знает пример MV с предложением HAVING? Так что, по крайней мере, я мог бы начать оттуда (я искал Google, но не нашел).

Note2: Причина, по которой я хочу HAVING, состоит в том, чтобы уменьшить количество строк в представлении от тысяч или даже миллионов до нескольких. Чтобы сохранить память (и, возможно, повысить производительность).

PS: Exact версия базы данных Oracle используется: 11.2.0.3.0

источник

2016-08-05 David Balažic

@GordonLinoff - функциональность документально не связана с предложением HAVING ** с подзапросом **. Вопрос имеет смысл - OP * утверждает, что у него нет подзапросов в его определении MV. Независимо от того, делает он или нет, другой вопрос - он опубликовал что-то отличное от своего фактического определения MV, но вопрос имеет смысл. – mathguy

@mathguy Примеры в вопросе воспроизводят проблему, и у них нет подзапросов. Я удалю упоминание «другого» запроса, чтобы избежать путаницы. (хотя тогда кто-то скажет, что простой опубликованный пример не имеет смысла для бизнеса ...). –

Хорошо, тем временем Гордон отозвал свой вопрос/возражение на ваш пост, так что это спорный вопрос. Недавно я установил версию Enterprise на одном из моих компьютеров (я энтузиаст, который просто учился для себя) - ваш вопрос дает мотивацию, сегодня, попробуйте точно, что вы описали и подтвердите. Известно, что иногда даже документация ошибочна, просто помните об этом. – mathguy

Да, документация не кажется, чтобы быть точным.

В качестве обходного пути вы можете попробовать реализовать вложенные материализованные виды.

CREATE MATERIALIZED VIEW mv1 
REFRESH FAST ON COMMIT 
AS 
SELECT col1, 
     COUNT(col1) count_col1 
FROM test_table 
GROUP BY col1 

ALTER MATERIALIZED VIEW mv1 ADD CONSTRAINT pk_mv1 PRIMARY KEY (col1) 

CREATE MATERIALIZED VIEW LOG ON mv1 WITH PRIMARY KEY; 

CREATE MATERIALIZED VIEW MV2 
REFRESH FAST ON COMMIT AS 
SELECT col1, 
     count_col1 
FROM mv1 
WHERE count_col1 > 1

источник

2016-08-05 05:08:46

Да, это работает, но моя цель - не иметь этих строк, хранящихся на диске вообще. Я уточню вопрос, чтобы это отразить. –

Материализованный просмотр быстрого обновления с предложением HAVING?

ответ

Смежные вопросы