Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
Добрый день!
Есть регулярно обновляемая процедура с большим SQL запросом (INSERT INTO() SELECT, большая таблица фактов и справочники, большие Joinы и сортировки), однако пересчитывать ее не имеет смысла если не обновлялась ни одна из таблиц присутствующих в процедуре. Вот теперь стоит задача проверить дату последнего DML на ряд таблиц, и если она больше даты последнего запуска процедуры => запустить процедуру, если меньше, соответственно пересчитывать SQL запрос нет необходимости. Причем нужно понимать сколько строк обновилось в результате DML (т.е. если 0 => таблица не изменилась). Ранее задача решалась с помощью MVIEW LOG, но MVIEW LOG при обновлении одной секции из таблицы фактов участвующей в процедуре генерит > 10млн строк, а фактически все эти данные не нужны, нужно проверить только сам факт обновления (да/нет).

В какую сторону стоит посмотреть? Аудит?
24 май 12, 10:07    [12605904]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
Всё зависит через что меняются те самые таблицы, в зависимости от которых надо или не надо обновлять главную. Если через UI - то всё просто - либо прям с клиента ставить галку где-нибудь что надо менять мега-таблицу, либо если клиент вызывает ХП для изменения таблиц в этих ХП эту же галку ставить. Ежели в дочерниие таблицы возможны инсерты в обход API Для UI (например, всякие импорты из экселей), то я вижу только аудит на триггерах... Причём возможно не в чистом виде аудит,а тоже с галкой: например
1. главная таблица зарефрешилась, поставили галку, что обновлять не надо
2. при повторном рефреше смотрим туда стоит ли галка или нет. если галка говорит, что не обновлялось, то ничего и не делаем если галка говорит что обновлялось - делаем
3. в триггерах на дочерних таблицах просто делаем update этой галки если она ещё не стоит в положении Обновить. Тем самым аудитные таблицы не пухнут, не тратится время на лишние инсерты в аудит, а задача решена
24 май 12, 11:07    [12606362]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

paveloder
Ранее задача решалась с помощью MVIEW LOG, но MVIEW LOG при обновлении одной секции из
таблицы фактов участвующей в процедуре генерит > 10млн строк, а фактически все эти данные
не нужны, нужно проверить только сам факт обновления (да/нет).

Ну так что мешает самому написать триггера, которые будут взводить флаг(и)? Или вообще
изменить логику, чтобы данные в таблицу фактов пересчитывались на лету, триггерами только
на изменённые данные базовых таблиц?..

Posted via ActualForum NNTP Server 1.5

24 май 12, 11:07    [12606366]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
-2-
Member

Откуда:
Сообщений: 15330
paveloder,

механизмов cdc не один и все имеют свои недостатки. аудит может вполне быть достаточным при аккуратном его использовании.
если не жалко времени на проверку факта обновления, самый простой способ - max(orarowscn).
24 май 12, 11:14    [12606414]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
Dimitry Sibiryakov,

автор
Ну так что мешает самому написать триггера, которые будут взводить флаг(и)?

Тоже думал в сторону триггеров, но здесь возникла проблема "Причем нужно понимать сколько строк обновилось в результате DML (т.е. если 0 => таблица не изменилась)". Если не найду другого решения так и сделаю.

автор
Или вообще
изменить логику, чтобы данные в таблицу фактов пересчитывались на лету, триггерами только
на изменённые данные базовых таблиц?..

Ресурсозатратно слишком это будет, если я все правильно понял.
24 май 12, 11:43    [12606745]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
Shtock,

С триггерами непонятно обновилось-ли вообще что-то в таблице при запуске UPDATE. Я не нашел способа в триггере определить сколько строк участвовало в DML.
24 май 12, 11:45    [12606778]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
-2-
Member

Откуда:
Сообщений: 15330
paveloder
С триггерами непонятно обновилось-ли вообще что-то в таблице при запуске UPDATE. Я не нашел способа в триггере определить сколько строк участвовало в DML.
в строчном - одна
24 май 12, 11:50    [12606865]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
-2-,

Можно потестить строчные триггеры для справочников, согласен. А таблица фактов загружается ETL процедурой, так что можно факт обновления прописать туда. Спасибо.
24 май 12, 11:57    [12606946]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
-=SwiMMeR=-
Member

Откуда: Россия, Краснодар
Сообщений: 110
1. Создаем глобальную переменную Х
2. Создаем флаг
3. Создаем два триггера
а) before/after insert/update/delete for each row
б) after insert/update/delete (statement)

В сессии триггер А увеличивает переменную Х (+1)
Триггер Б в зависимости от значения Х (>0) взводит флаг в true (1/'Y' и т.д.)

При необходимости в триггере А можно проводить проверку изменения значений полей для Update.
24 май 12, 12:04    [12607031]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

-=SwiMMeR=-
В сессии триггер А увеличивает переменную Х (+1)
Триггер Б в зависимости от значения Х (>0) взводит флаг в true (1/'Y' и т.д.)

А прямо в триггере А взводить флаг мешает что?..

Posted via ActualForum NNTP Server 1.5

24 май 12, 12:20    [12607235]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
Подумал тут немного и есть что-то порочное вообще в подходе с триггерами и взводом галки. НАпример, делаются 2 апдейта последовательно:

Предусловие
В поле F1 находится число 3

1. update table_1 set f1=2 where id = 3 Галка поставилась
2. update table_1 set f1=3 where id = 3 Галка поставилась опять

И налицо хрень - мы запускаем процесс обновления хотя на самом то деле ничего не поменялось.


Поэтому если позволяет место (админы не считаю гигов) то я бы сделал бы так:
1. сделал словарик таблиц которые справочные и учавствую в пересчёте
2. по завершению мега-etl процедуры согласно словарю делал бы вначале delete, а потом insert as select * для всех этих спрачников в полные их копии но с префиксом P_ например (previous)
3. commit
4. при повторном запуске процедуры для всех таблиц из мега-словаря:
select count(*) from (select * from основная таблица minus select * from P_основная таблица )
5. если где-либо нашлась разница - пересчёт даже не дожидаяся как дошли до конца словаря (ну а если хотите полный трейс - то уж пройти по всему словарю).

Чтобы не возникало проблем с многопользовательским доступом (а то ведь навставляют всякого в табы) по этому же словарю до запуска etl-процы делал бы эксклизивный лок всех справочных таблиц, чтобы никакие изменения на период расчета разницы в них не осуществлялись.
24 май 12, 12:49    [12607525]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
Shtock,

В этом-то и самая главная сложность. В принципе применимый подход (хотя чем-то он мне напоминает подход с анализом MVIEW LOG). Надо бы проверить по производительности. Спасибо
24 май 12, 13:35    [12607922]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
-=SwiMMeR=-
Member

Откуда: Россия, Краснодар
Сообщений: 110
Dimitry Sibiryakov
-=SwiMMeR=-
В сессии триггер А увеличивает переменную Х (+1)
Триггер Б в зависимости от значения Х (>0) взводит флаг в true (1/'Y' и т.д.)

А прямо в триггере А взводить флаг мешает что?..


А если апдейт на миллион строк?
Миллион раз взводить флаг?
Причем флаг это не мифический флаг - скорее всего это поле таблицы. Не так ли?
24 май 12, 13:51    [12608031]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
-=SwiMMeR=-
Member

Откуда: Россия, Краснодар
Сообщений: 110
Shtock
Подумал тут немного и есть что-то порочное вообще в подходе с триггерами и взводом галки. НАпример, делаются 2 апдейта последовательно:

Предусловие
В поле F1 находится число 3

1. update table_1 set f1=2 where id = 3 Галка поставилась
2. update table_1 set f1=3 where id = 3 Галка поставилась опять

И налицо хрень - мы запускаем процесс обновления хотя на самом то деле ничего не поменялось.


Согласен. Можно поиграться с FlashBack в рамках идеи с триггерами.
24 май 12, 13:54    [12608058]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Заблудшая душа
Guest
paveloder,

1) ORA_ROWSCN
2) Добавить LAST_UPDATE_TIMESTAMP
24 май 12, 13:54    [12608059]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

-=SwiMMeR=-
А если апдейт на миллион строк?
Миллион раз взводить флаг?

А чем это хуже миллиона увеличений переменной на единицу?..

-=SwiMMeR=-
Причем флаг это не мифический флаг - скорее всего это поле таблицы.

Скорее это такая же переменная пакета.

Posted via ActualForum NNTP Server 1.5

24 май 12, 14:06    [12608170]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Dimitry Sibiryakov
-=SwiMMeR=-
А если апдейт на миллион строк?
Миллион раз взводить флаг?

А чем это хуже миллиона увеличений переменной на единицу?..

-=SwiMMeR=-
Причем флаг это не мифический флаг - скорее всего это поле таблицы.

Скорее это такая же переменная пакета.

принципиально хуже, если на ровном месте (т.е. исключительно для этой требухи) строчных триггеров на всё подряд налабать.
не забываем, что цель была добыть перформенс..
24 май 12, 14:46    [12608536]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

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

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

Posted via ActualForum NNTP Server 1.5

24 май 12, 14:48    [12608562]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Dimitry Sibiryakov
orawish
принципиально хуже, если на ровном месте (т.е. исключительно для этой требухи) строчных
триггеров на всё подряд налабать.
не забываем, что цель была добыть перформенс..

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

лично для меня изначальная постановка запроса звучит дико. живут таблицы. их кто-то обновляет и об этом (на уровне бизнес-приложений) никаких следов, типа элементарного протокола ( кто, когда,зачем, чего и сколько. )
вы (это топикстартеру и его коллегам :) в бирюльки что-ли играете?
24 май 12, 15:00    [12608664]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
orawish,

Все DML операции могут выполняться как из приложения, так и вручную скриптами. Что здесь странного?
24 май 12, 16:04    [12609338]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
paveloder
orawish,

Все DML операции могут выполняться как из приложения, так и вручную скриптами. Что здесь странного?

странно, что не заботитесь о сохранности данных. они ничего не стОят?
24 май 12, 16:08    [12609366]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
Dimitry Sibiryakov,

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

В дальнейшем full scan этого большого лога => медленное обновление.
24 май 12, 16:10    [12609391]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
paveloder
Member

Откуда:
Сообщений: 59
orawish,

к схеме имеют доступ очень ограниченное кол-во лиц. Часто возникает необходимость обновления большого числа данных, что через UI проблематично.
24 май 12, 16:16    [12609437]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
Не медленное обновление, а медленное ожидание обновления...
24 май 12, 16:17    [12609439]     Ответить | Цитировать Сообщить модератору
 Re: Проверка изменения таблиц  [new]
-2-
Member

Откуда:
Сообщений: 15330
paveloder
В дальнейшем full scan этого большого лога => медленное обновление.
зачем его фул-сканировать, если нужно только знать есть или нет изменения?
24 май 12, 16:19    [12609469]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить