|
Обновление
|
|||
---|---|---|---|
#18+
Здравствуйте! Подскажите, пожалуйста, как решить данную проблему? Есть таблица, на основе которой формируется другая. Так вот. Теперь нужно обновить сформированную таблицу на основе изменений исходной, но только нужно учитывать обновления после отсчетной даты, например от '03.02.2018'. код формирования таблиц: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.
Примерные изменения: Код: plsql 1. 2. 3.
Есть ограничения - максимум: 1 insert, 1 update,1 delete; так же нужно через один merge. Надеюсь на Вашу помощь. Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 13:36 |
|
Обновление
|
|||
---|---|---|---|
#18+
vgpframedЕсть таблица, на основе которой формируется другая проходили уже ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 13:54 |
|
Обновление
|
|||
---|---|---|---|
#18+
123йй, это продолжение. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 13:57 |
|
Обновление
|
|||
---|---|---|---|
#18+
vgpframed, а какой смысл в таблице end_table ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 14:00 |
|
Обновление
|
|||
---|---|---|---|
#18+
123йй, можно сказать, что это своеобразные остатки от таблицы start_table по временным интервалам. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 14:03 |
|
Обновление
|
|||
---|---|---|---|
#18+
Кто-нибудь, помогите пожалуйста! ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 15:37 |
|
Обновление
|
|||
---|---|---|---|
#18+
vgpframedКто-нибудь, помогите пожалуйста! задача, которую вы пытаетесь решить, называется change data capture, и в зависимости от конкретной ситуации она может быть весьма нетривиальной. например, вы удалили строку из start_table. процесс, который обновляет end_table, должен об этом откуда-то узнать. какие у него есть варианты? навскидку не так много. а) посмотреть в некий журнал операций, в котором будет написано, что строка была удалена. б) догадаться об этом, каким-то образом сравнив end_table со start_table выбор будет обусловлен множеством факторов, большинство из которых известны только вам. вряд ли вам тут сходу предложат готовое решение ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 17:08 |
|
Обновление
|
|||
---|---|---|---|
#18+
кит северных морейvgpframedКто-нибудь, помогите пожалуйста! вы удалили строку из start_table. процесс, который обновляет end_table, должен об этом откуда-то узнать. Думаю что триггером это сделать легче всего . ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 17:33 |
|
Обновление
|
|||
---|---|---|---|
#18+
maverick2104кит северных морейпропущено... вы удалили строку из start_table. процесс, который обновляет end_table, должен об этом откуда-то узнать. Думаю что триггером это сделать легче всего . хорошо. вы сделали after insert for each row trigger. я загрузил в таблицу 300 миллионов строк одной партией через insert+append. ваш триггер превратил direct path load в conventional load, загрузка заняла десять часов вместо десяти минут, мы нарушили SLA, нас всех уволили. потом бизнес решил, что из 300 миллионов строк нужны только 150, и наш последователь решил удалить половину. он сделал это через CTAS+exchange partition. ваш after delete for each row trigger никогда об этом не узнал нельзя говорить что легче, а что нет, не понимая, как устроены процессы в конкретной БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2019, 17:56 |
|
|
start [/forum/topic.php?fid=52&msg=39840950&tid=1882271]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 126ms |
0 / 0 |