> [18] ANB   (23.12.09 16:11)
> RBS не хватит столько проапдейтить.

Никто и не заставляет всю кучу сразу тянуть. Тяни пачками.

> У меня сейчас под рукой нет ни одной книги по DWH в Oracle,
>  я б процитировал насчет materialized views.

Игорь, материализованные представления мы первым делом опробовали. Может мы их неправильно готовили, конечно.
Делали :
1) Прицепили на одну таблицу снап шот лог (всего их надо несколько десятков реплицировать)
2) Создали мат.представление с фаст обновлением раз в сутки
Запустили массовую процедуру. Причем обновление в этот момент не работало. Массовая процедура отработала раза в 3 медленнее. Да и вся система стала притормаживать. Снесли логи - система задышала.

> Никто и не заставляет всю кучу сразу тянуть. Тяни пачками.

апдейт 30 миллионов записей что пачками что разом - не быстро это. Плюс тянульщиков уже минимум 2 образовалось.

Можно пофлудить? Просто интересна область применения такого огромного количества данных? Сори за офтоп

> Можно пофлудить? Просто интересна область применения такого
> огромного количества данных? Сори за офтоп

Маленький скромный банк.

чем плохи Oracle Streams, BPEL?

> [22] ANB   (23.12.09 17:25)
> апдейт 30 миллионов записей что пачками что разом - не быстро это.

Ну во первых не так уж и много. Во вторых это же не каждый день, а раз в месяц (как я понял) по 30 лимонов. В третьих - ночь все таки довольно длинная. В четвертых ты вряд ли найдешь решение, которое будет работать за 5 минут - большому кораблю большое плавание.

> Возможно стОит подумать об организации отдельной IOT таблицы,
>  с ID-шником основной и временной меткой. Ее можно будет
> периодически чистить от старья.

зачем ориентироваться на timestamp, который к тому же надо будет дважды в год анализировать на таймзону, когда в Oracle есть SCN?
если банк, то база точно в архивлогах, поэтому стандартный механизм репликации не создаст существенной доп. нагрузки наOLTP-сервер.

> чем плохи Oracle Streams, BPEL?

А чем хороши ? У них другой принцип, по сравнению с мат.вьюхами ?
У меня почему то сложилось стойкое предубеждение к новомодным фичам оракла.
Испытывались :
1. Репликация односторонняя
2. Адвансед репликация (двухсторонняя)
3. Очереди
От всех этих фичей осталось самое хреновое впечатление. Тормозят безбожно, много ограничений, писать под них много и неудобно.
И при любом раскладе требуют толстого и надежного канала связи.


> Ну во первых не так уж и много.

Для инсерта - да. Для апдейта - достаточно много.

ANB   (24.12.09 09:25) [28]
Streams - фича довольно-таки "старая"
в 10-ке Ваши пп.1-3 отлично работают
"тормозов" не замечено
удобство написания: три основных пакета с основными интерфейсами - capture, propagation, apply - ничего сложного
канал связи - действительно, желателен стабильный, но если связь прервется - ничего страшного, т.к. при возобновлении соединения данные польются ровно с того места(SCN), на котором связь пропала

> [28] ANB   (24.12.09 09:25)
> Для инсерта - да. Для апдейта - достаточно много.

Помнится в институте слышал - критерием истины является практика. Наколбасить 30 лимонов записей да проапдейтить.

Кстати можно и без апдейта и без всяких доп полей.
В отдельной таблице хранятся просто ид-шники измененных/новых и НЕзаархивированных записей. При перетаскивании/архивации из нее соответственно удалять.

> В отдельной таблице хранятся просто ид-шники измененных/новых
> и НЕзаархивированных записей. При перетаскивании/архивации
> из нее соответственно удалять.

Примерно так и работает фаст мат.вьюха на снапшот логах. Тормоза начинаются.


> "тормозов" не замечено

На каких обьемах ?

> Наколбасить 30 лимонов записей да проапдейтить.

Колбасил - апдейт висит долго.

> [32] ANB   (24.12.09 10:52)
> Тормоза начинаются.

На чем тормоза? На перекачке? Так они ИМХО по любому будут на таких объемах. Потому и надо их на ночь переносить - пусть подтормаживает. Лишь бы за ночь отрабатывало.

> Потому и надо их на ночь переносить - пусть подтормаживает.
>  Лишь бы за ночь отрабатывало.

Нужно каждый час запускать.
На перекачке тормозов не будет - минут 5-10. Висеть будет апдейт. Более того - он будет тормозить ОЛТП базу.

Кстати, покопал стрим - вроде ничего по идее. Архивные логи пишуться по любому.
У нас уже отрабатывается такой вариант. Только места под него пока нет - придется еще один дисковый массив покупать, а он дорогой зараза.
Сейчас архив логи раз в сутки у нас чистяться.

> [35] ANB   (24.12.09 12:02)
> Висеть будет апдейт.

Можно же без апдейта. На отдельную таблицу ссылок не будет - удалить должно быстро. Да и будет она при таком подходе небольшая.

> ANB   (24.12.09 10:52) [32]
> > "тормозов" не замечено
> На каких обьемах ?

на сравнимых, т.е. порядка 10^6 записей в день
впрочем, объемы не важны, т.к. репликация идет по мере поступления, а 10-20 записей в секунду - не тот объем, который повесит Oracle)

> Можно же без апдейта. На отдельную таблицу ссылок не будет
> - удалить должно быстро.

Таблицу можно вообще транкейтить.
С обработкой отдельной таблицы проблем особых нет, но :
1) Будет момент, когда в ней будет 30 миллионов записей (джойн с основной таблицей повиснет)
2) Можно не джойнить, а сразу складывать все поля, но ведение лога сильно затормозит массовые процессы.
Короче, будем смотреть в сторону стрима, если не придумаем ничего толкового с таймштампом.
Но, милин, начальство нас убъет :)
Там не один лям баксов надо будет вложить.

> не тот объем, который повесит Oracle)

По стриму, как я понял, самое полезное, что ОЛТП база вообще не затрагивается. Все на архив.логах сделано. А тормоза DWH нас волнуют слабо. Не наша проблема.