Стоит следущая задача (не передо мной, но нас коснется) :
Имеется таблица (проводки) в которой чуток больше миллиарда записей.
Нужно :
1) Скопировать данные в хранилище данных
2) Ежедневно поддерживать хранилище в актуальном состоянии
3) Не притормозить ОЛТП систему
Дельта :
в обычные дни в таблицу добавляется несколько сотен тысяч записей. В особые дни - несколько миллионов, в конце месяца - порядка 30-40 миллионов.

Вопрос : у кого нибудь есть опыт, как реализовать данную задачу ?
Своих идей хватает, но т.к. опыта работы с DWH нету - все варианты стремно применять из-за условия 3).

Примерно на таких же условиях у нас каждую ночь данные джобами переносятся из биллинга в ОЛАП-кубы. Правда на МССКЛ, но сути, думаю, это не меняет.
Главное, ИМХО, не затягивать с началом копирования - как только ОЛТП активность кончилась, так и начинай.

> Sergey13 ©   (23.12.09 09:46) [1]

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

> [2] ANB   (23.12.09 09:48)

Отдельное поле с датой последней модификации записи не подходит?

> Отдельное поле с датой последней модификации записи не подходит?

Да вот думаем, но его заполнять неоткуда (все места в коде не поправишь) - это придется триггер вешать.
Сидим чешем репу - замедлит или нет потом массовые процедуры.

> [4] ANB   (23.12.09 10:08)
> Сидим чешем репу - замедлит или нет потом массовые процедуры.

А с чего бы ему замедлять? Он же никуда не полезет - просто возьмет текущую системную дату. И уникальность (как источник тормозов) не надо поддерживать.

> Sergey13 ©   (23.12.09 10:16) [5]

Идея катит. На удаление повесим триггер - пусть складывает логи, это редко бывает и плевать на скорость.
Остается вопрос с местом решить.

> [6] ANB   (23.12.09 11:12)
> На удаление повесим триггер - пусть складывает логи

А у вас физически проводка удаляется? Вроде как неправильно это.

> А у вас физически проводка удаляется? Вроде как неправильно
> это.

Тока в особых случаях лично главбухом с объяснительной накосячившего. И логгированием. Собственно, логгирование удаления для проводок уже есть, это для других таблиц.

> Отдельное поле с датой последней модификации записи не подходит?
> Да вот думаем, но его заполнять неоткуда (все места в коде не поправишь) - это придется триггер вешать.
timestamp ?

блин, не обратил внимания на оракл, сбило
> Правда на МССКЛ,

> timestamp ?

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

> [11] ANB   (23.12.09 12:33)

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

> Только заполнять при апдейте придется триггером.
я вообще то предложил его как раз потому, что заполнять не надо... в mssql. уникальное возрастающее значение после любого редактирования записи, можно использовать в общем, и без тригера. т.к. было -
> Да вот думаем, но его заполнять неоткуда (все места в коде не поправишь) - это придется триггер вешать.

но в общем то ладно, все одно не пойдет, из-за  платформы.

materialized views ? оно само умеет "актуальность" поддерживать, AFAIK

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

30 миллионов записей джойнить нестед лупсом стремно потом.


> materialized views ? оно само умеет "актуальность" поддерживать,
>  AFAIK

Пробовали. ОЛТП система легла. Ведение снапшот логов затормозило массовые процедуры раза в 3.

Тут с тамйштампом проблемка рисуется.

Имеем :
1) последний раз выгружали 00:00:00.0000, сейчас 01:00:00.0000.
В 00:59:59.9999 легла инсертом запись. Таймштамп триггером выставился, есно 00:59:59.9999. Коммита не было. Стартует джоб, выгребает все записи
с 00:00:00.0001 по 01:00:00.0000. Запись 00:59:59.9999 он не видит (не закоммичена).
2) сейчас 02:00:00.0000. Стартует джоб. Запись 00:59:59.9999 закоммитилась в 01:00:01.0000. Но в новой итерации джоб опять ее не видит, т.к. джоб смотрит с 01:00:00.0001 по 02:00:00.0000.
Проводка потерялась.

Чего тут можно придумать ?

> [15] ANB   (23.12.09 15:27)
> 30 миллионов записей джойнить нестед лупсом стремно потом.

Зато получается почти автономная система, которую можно легко выключить если попытка будет неудачной.

> Чего тут можно придумать ?

Еще одно поле-признак архивирована/нет. Может тогда и дату время не надо писать.

> Пробовали. ОЛТП система легла. Ведение снапшот логов затормозило
> массовые процедуры раза в 3.


Что вы пробовали ?

Это читал наизусть ?
http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/basicmv.htm#i1007299
http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/advmv.htm#i1007694

> Еще одно поле-признак архивирована/нет. Может тогда и дату
> время не надо писать.

RBS не хватит столько проапдейтить.


> Зато получается почти автономная система, которую можно
> легко выключить если попытка будет неудачной.

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


> Это читал наизусть ?
> http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/basicmv.
> htm#i1007299
> http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/advmv.
> htm#i1007694

Читал и даже делал. Игорь, не держи нас за полных лохов.
С материализованных представлений и начали. Вот только мой прошлый опыт работы с ними показал, что не такая уж это и клевая штука.
Она хорошо работает в фулл режиме, но у нас нет столько времени и ресурсов на ежедневную полную перекачку.
А фаст режим достаточно капризный и, как показал эксперимент, включение логов торомозит ОЛТП систему, что недопустимо.

ANB   (23.12.09 16:11) [18]

Видишь ли, проблема перекачки данных из OLTP в DWH появилась не у тебя первого. Из большого OLTP в большой DWH тоже. Потому я склонен все-таки доверять Oracle, который на этих процессах не одну собаку съел.
У меня сейчас под рукой нет ни одной книги по DWH в Oracle, я б процитировал насчет materialized views.

Martin Rennhackkamp в журнале DBMS много писал как про организацию DWH, так и про его загрузку, причем было это лет 8 назад. Я к чему - я к тому, что с тех пор многое из описанного взято на вооружение производителями СУБД :)