Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
31.10.2005, 07:27
|
|||
|---|---|---|---|
Инкрементальное пополнение Хранилище данных(ORACLE) |
|||
|
#18+
Здравствуйте, Подскажите пожайлуста, как реализовать инкрементальное пополнение таблицы с помощью OWB (может где то опцию поставить:) итд) заранее спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2005, 09:52
|
|||
|---|---|---|---|
|
|||
Инкрементальное пополнение Хранилище данных(ORACLE) |
|||
|
#18+
owb_bЗдравствуйте, Подскажите пожайлуста, как реализовать инкрементальное пополнение таблицы с помощью OWB (может где то опцию поставить:) итд) заранее спасибо Допустим источник таблица А и цель таблица Б, обе таблицы идентичны. 1 -ый способ: с помощью тригеров формируете список новых строк ( это удобно делать в другой таблице отлавливая всего лишь ID ) - потом из табл. А выбираете те строки, ID которых имеются в таблице-ловушке ( в этой таблице также удобно добавить поле даты- которое будет соответсвовать моменту саписи ID). После чего подчищате таблицу до момента даты с которого вы начали делать выборку. ( Не исключено, что в ловушку попадут новые записи к тому времени как закончится выборка из неё). 2. -ой способ : делаете view , которая через MINUS показывает разницу между таблицами А и Б. Соответсвенно - берёте и выгрибаете всё из этой view в таблицу Б. 3. Читаете про MERGE. -- PS каждый способ хорош для частного случая и не является универсальным, думаю это понятно. Посему для частой синхронизации рекомендую 1-ый способ. Для больших объёмом и редкой синхроницации 2 или 3-ий. Так же все эти способы могут применены для поиска изменившися строк и тех которые нужно удалить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2005, 09:59
|
|||
|---|---|---|---|
Инкрементальное пополнение Хранилище данных(ORACLE) |
|||
|
#18+
А Вы не могли бы более четко сформулировать постановку задачи? Какие объемы, какой регламент, простое перекачивание из одной таблицы в другую или с преобразованиями по пути? Тогда и ответить будет легче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2005, 10:28
|
|||
|---|---|---|---|
Инкрементальное пополнение Хранилище данных(ORACLE) |
|||
|
#18+
если во все кубы (ая так понимаю что вопрос именно про них) входит измерение времени, то мы просто удаляли за интересующий период и снова заливали. но если в кубе несколько паказателй, а перезалить нужно не все, то тогда MERGE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2005, 11:29
|
|||
|---|---|---|---|
Инкрементальное пополнение Хранилище данных(ORACLE) |
|||
|
#18+
Andrew IFА Вы не могли бы более четко сформулировать постановку задачи? Какие объемы, какой регламент, простое перекачивание из одной таблицы в другую или с преобразованиями по пути? Тогда и ответить будет легче. Объем около 60000 строк ежедневно (весь объем таблицы 20 млн. записей)(это пока самая большая таблица в базе) регламент ежедневно (для не которых таблиц хотелось бы по мере изменения в основной таблице :)) преоброзований нет пока ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=49&mobile=1&tid=1870930]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 247ms |
| total: | 385ms |

| 0 / 0 |
