Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 mat.view fast refresh & mat.view log scan  [new]
Мубин
Member

Откуда:
Сообщений: 31
Привет всем!

Если кто сталкивался прошу помочь в след.:

Имеется большая таблица (rows>60 млн), которая постоянно "растёт". Требуется периодически синхронизировать содержимое этой таблицы с её копией на другой базе (односторонняя репликация). Для этого я создал журнал для материализованного представления и само мат.представление на второй базе с опцией fast refresh. При первом обновлении происходит complete refresh - это понятно, т.к. до этого никаких данных не было там. При следующем обновлении вижу что действительно происходит "быстрое" обновление. Но когда 2-й раз запускаю обновление объем сканируемых данных для обновления растет с каждым разом (судя по v$session_longops и времени выполнения обновления). Причем при одном обновлении журнал для мат.представления сканируется как минимум 3 раза (???). Вопросы: 1. Зачем каждый раз сканировать ВЕСЬ журнал мат.представления? Нужно ли дополнительно что-то делать (очищать) после обновления если да то что? 2. Зачем происходит тройное сканирование когда само мат.представление создано от простого запроса select * from table. ??

Заранее спасибо всем откликнувшимся.
18 мар 08, 10:01    [5422177]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
А текст запроса, на котором матвьюха построена, можно увидеть? Интересует наличие или отсутствие в нем аггрегаций
18 мар 08, 10:09    [5422225]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Попробуйте снять трассировку обновления Вашей матвьюхи и выложите ее вместе со сценариями создания матвьюхи и базовой таблицы сюда. Там все будет видно.
Логи чиститься должны сами.
18 мар 08, 10:19    [5422276]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Мубин
Member

Откуда:
Сообщений: 31
givanov
Попробуйте снять трассировку обновления Вашей матвьюхи и выложите ее вместе со сценариями создания матвьюхи и базовой таблицы сюда. Там все будет видно.
Логи чиститься должны сами.


в приложении сценарии создания матвьюхи и самой таблицы, а трейс как приложить сюда если заархивированный размер превышает 100 кб ?

К сообщению приложен файл (DDLs.rar - 1Kb) cкачать
18 мар 08, 11:32    [5422736]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Трейс обработайте tkprof.
18 мар 08, 11:42    [5422820]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Мубин
Member

Откуда:
Сообщений: 31
сори - думал сырой нужен.

в трейсе вижу кучу фул сканов на журнале от матвьюхи - означает ли это что необходимо оптимизировать эти запросы/удаления ? например создав индекс по полю snap_time ?

К сообщению приложен файл (ppcdb_ora_1283.out - 22Kb) cкачать
18 мар 08, 11:48    [5422875]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Чего-то у вас в трейсе не хватает, ни одного insert/update/delete.
Я провел простой тест:
create table a as select * from all_objects;

alter table a add constraint a_pk primary key(object_id);

create materialized view log on a with primary key;

create materialized view b
refresh fast on demand
as
select * from a;

select * from b;

update a
  set object_name = 'DUAL'
  where object_id = 259;

alter session set events = '10046 trace name context forever, level 8'

begin
dbms_mview.refresh('B','F');
end;
Так вот в трейсе и update mview видно, и очистку логов.
Может, у вас DBLink задействован?

К сообщению приложен файл (gi_ora_7504.zip - 10Kb) cкачать
18 мар 08, 12:46    [5423311]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Мубин
Member

Откуда:
Сообщений: 31
трейс обработанный tkprof 10.2.0.3 и после alter session set optimizer_mode='CHOOSE';

К сообщению приложен файл (ppcdb_ora_14455.out - 9Kb) cкачать
18 мар 08, 13:39    [5423812]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Да, у вас, действительно, используется DBLink, и, действительно, не видно, что бы логи чистились.
Содержание логов можно посмотреть в
select min("SNAPTIME$$") from MLOG$_CALL_03_2008
Как вы обновляете?

ЗЫ Вот это еще странно:
  Event waited on                             Times   Max. Wait  Total Waited
  SQL*Net more data to client                 11653        0.60         80.65 
Посмотрите работу сети.
18 мар 08, 14:32    [5424213]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Может это пригодится: Настраиваем сетевые ожидания при работе с СУБД Oracle.
18 мар 08, 16:31    [5425277]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Тынц.
Guest
Проверьте, не использует ли у вас ещё какая-нибудь mview тот же лог (и при этом не обновляется), нет ли некорректно дерегистрированных mview (- Суслика видишь? - Да. -А него нет. :) ). Лог не очистится, пока не обновятся все использующие его mview. Могли, например, сказать drop какой-нибудь mview на mview site во время отсутствия связи с master site - т.е. удалили, но master site ничего об этом не подозревает.
Список - user_registered_mviews, время обновления - user_base_table_mviews, описание механизма работы лога - Note:236233.1 Materialized View Refresh : Log Population and Purge и далее по ссылкам + Note:258252.1 и оттуда тоже по ссылкам.
18 мар 08, 22:06    [5427072]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
Автору топика:

посмотрите поле ALL_MVIEWS.fast_refreshable по вашей mview. Надо бы в концепты залезть, чтобы освежить память, но скажу сразу, что меня смутило - ваша mview не будет выполнять fast refresh. Аггрегатов там нет, значит, для быстрого обновления требуется:

a) mview log with primary key, rowid
b) ROWID всех задействованных таблиц

ROWID в приведенном селекте не выбирается.
Есть еще один пункт по поводу mview на основе распределенного запроса... вот не помню... то ли fast refresh on commit не работает в таких случаях, то ли вообще fast refresh.
19 мар 08, 05:22    [5427569]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Вадиман
Автору топика:
Не смущайте человека:-))
Сначала сами в концепты залезте.
19 мар 08, 09:53    [5427985]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
А в чем я неправ?
19 мар 08, 10:17    [5428127]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Если Вы посмотрите на логи, Вы сразу поймете, что fast refresh выполняется.
Это условие задачи, не надо с ним бороться.

off: Кроме того, посты типа "я сам не помню, почитайте тут и тут" в качестве ответа на вопрос не катят.
19 мар 08, 10:28    [5428207]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
TiG
Member

Откуда:
Сообщений: 780
Тынц.
Проверьте, не использует ли у вас ещё какая-нибудь mview тот же лог (и при этом не обновляется), нет ли некорректно дерегистрированных mview (- Суслика видишь? - Да. -А него нет. :) ). Лог не очистится, пока не обновятся все использующие его mview. Могли, например, сказать drop какой-нибудь mview на mview site во время отсутствия связи с master site - т.е. удалили, но master site ничего об этом не подозревает.
Список - user_registered_mviews, время обновления - user_base_table_mviews, описание механизма работы лога - Note:236233.1 Materialized View Refresh : Log Population and Purge и далее по ссылкам + Note:258252.1 и оттуда тоже по ссылкам.

+1
основная причина таких проблем - не очищающийся мат.вью лог из-за того что оракл считает что его данные нужны еще каким-то мат.вьюхам, которые в действительности либо не существуют, либо просто не обновляются. найдете - либо избавьтесь от них, либо обновляйте регулярно. ну а чтоб лог сильно не распухал - после решения первой проблемы сделайте ему shrink space и уменьшайте интервал обновления, если за час слишком много изменений накапливается - поставьте полчаса, 15 минут
19 мар 08, 16:13    [5431214]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
Мубин
Member

Откуда:
Сообщений: 31
Приношу свои извинения, но кажись я криво обработал tkprof-ом трейс. В приложении тотже трейс но со всеми курсорами. На самом деле в трейсе видно что лог очищается, но както вся задумка с FAST REFRESH мне всё меньше нравиться. Ведь для одного фаст рефреша выполняется четырехкратный фулскан лога от матвьюхи (судя по логу 1 для апдейта поля snaptime, 2 для отбора primary key, по которым произошли изменения, 3 - непосредственное обновление, 5 - очищение лога) какой же это фаст рефреш? Видимо такой фастрефреш поможет только в таблицах где изменения происходит очень редко. Какой метод оптимальнее использовать для репликации таблицы, которая растёт быстро?

К сообщению приложен файл (ppcdb_ora_1283.out2 - 42Kb) cкачать
19 мар 08, 23:38    [5433298]     Ответить | Цитировать Сообщить модератору
 Re: mat.view fast refresh & mat.view log scan  [new]
givanov
Member

Откуда:
Сообщений: 757
Есть подозрение, что однажды в таблице mv лога было очень много записей, которые потом удалились, а место осталось. В результате сейчас есть таблица, в которой немного занятого пространства, и много свободного, но TABLE ACCESS FULL читает ее всю, включая свободное место. ALTER TABLE MOVE должен помочь уменьшить таблицу MLOG$_CALL_03_2008 до разумных размеров.

С этим что-нибудь сделать получилось?
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net more data to client                 22986        1.75        168.43

Если таблица только растет, update/delete нет, то можете просто дописывать в свою таблицу изменения, произошедшие после последней репликации. Проблема только зафиксировать момент этой репликации.
20 мар 08, 12:14    [5435249]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить