|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
И в зависимости от длины строки и pctfree - можно получить кучу chained rows после раздувания строки на длину значения в personid ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 05:33 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
dbms_photoshopЯ так нигде и не нашел описания почему при увеличении параллелизма может сильно "раздуваться" потребление темпа. Не очень понимаю тут вопроса "почему". ИМХО, все естественно. Слэйвы обязаны координировать между собой только непересечение конечных результатов работы, а кухня у каждого своя, без учета, что таких слейвов еще N-цать. Хотя, конечно, по уму, ограниченность темпа при построении плана запроса стоило бы учитывать. Ограничивать это как-то можно с помощью Automatic DOP и (против лома нет приема) прямым ограничением parallel на сессию с помощью Resource Manager. ....вообще, конечно, данный топик показывает выигрышный способ получить толковое обсуждение вопроса вместо сра dropping bricks - зарегистрироваться под женским именем. Истинность логина ТС никоим образом не подвергаю сомнению. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 09:52 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Nobody1111, 😓 оскорбилась :-( меня приняли за мужика :D ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 10:05 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
E_SchekaturovaNobody1111, 😓 оскорбилась :-( меня приняли за мужика :D Я ж написал - "Истинность логина ТС никоим образом не подвергаю сомнению". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 10:09 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Nobody1111, На самом деле, я очень довольна полученными ответами, много полезных советов, такому нубному нубу, как я))) я уже несколько предложений попробовали, эффекта немного ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 10:18 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Изя Кацман, Значительно ускорился, не самолет, но уже намного лучше :) Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 11:53 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Если нужен "самолет" выгрузите обе таблицы в другую БД создайте реплику изменения в COLLECT_FE.TELEPHONE, потом уже накатите эту реплику на вашу исходную базу. Можно даже сделать не самолет, а ракету...)) конечно, речь идет о БД in-memory решении... как известном мульте "лучше день потерять, потом за 5 минут долететь" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 12:45 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Поделюсь опытомконечно, речь идет о БД in-memory решении... " Обычно большой апдейт страдает от избыточности lio, а не от скорости доставки данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 13:02 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
персонидE_SchekaturovaAlexander Ryndin, кстати, индексов там целая куча, в т.ч. и PERSONID попробуй еще эти (в которых есть PERSONID) индексы перед апдейтом отклюячить, а потом перестроить. не согласен, индексы с PERSONID не надо трогать я б даже сказал наоборот, добавить если нет а вот с COLLECT_FE.TELEPHONE (CIFID ) ЕСЛИ можно я б грохнул/отключил и пересоздал возможно на перестройку индекса и тратится основное время персонидИ в зависимости от длины строки и pctfree - можно получить кучу chained rows после раздувания строки на длину значения в personid причем тут personid, она ж меняет CIFID да и при смене числа на число врядли получат кучу "chained rows" хотя всякое бывает, из-за дурацкой економии блок пакуют под завязку імхо надо пробовать вплоть до банального tel.PERSONID=prs.PERSONID and tel.CIFID <> prs.CIFID and rownum<100000 (подобрать) но условие tel.CIFID <> prs.CIFID добавил БЫ почти по любому ...... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 14:04 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
stax.., добавила и перезапустила свой трэш ) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 14:20 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
stax..персонидпропущено... попробуй еще эти (в которых есть PERSONID) индексы перед апдейтом отклюячить, а потом перестроить. не согласен, индексы с PERSONID не надо трогать я б даже сказал наоборот, добавить если нет а вот с COLLECT_FE.TELEPHONE (CIFID ) ЕСЛИ можно я б грохнул/отключил и пересоздал возможно на перестройку индекса и тратится основное время ...... stax +много, индексы с первым столбцом PERSONID не будут тормозить, а остальные сессия при обновлении записей в таблице будет рекурсивно перебирать FULLSCAN-ами. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 14:27 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
ORA-38104: Columns referenced in the ON Clause cannot be updated: "TEL"."CIFID" таки ругается, что в фильтре обновляемое значение ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 14:33 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
E_Schekaturova, Перепиши на апдейт. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 14:40 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Павел Воронцов, так? Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 14:54 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
E_SchekaturovaORA-38104: Columns referenced in the ON Clause cannot be updated: "TEL"."CIFID" таки ругается, что в фильтре обновляемое значение Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:09 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
dbms_photoshop, хехъ) исправила) благодарю ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:19 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
E_SchekaturovaORA-38104: Columns referenced in the ON Clause cannot be updated: "TEL"."CIFID" таки ругается, что в фильтре обновляемое значение сначала надо проанализировать, если у Вас скажем совпадений 100штук то не стоит и проверять если "много" то надо да, я забыл указать что пользуюсь "обычным" update + insert если надо отсюда и возник форал если условие для update неудобное раз у вас проходит мерже, то скорее всего ext_eshchekaturova.PERSON_tel(personid) можно сделать ПК (шоб не лезло в таблицу PERSONID,CIFID или ИОТ) и я б менял примерно так Код: 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.
зы можно через where exists ..., короче надо пробовать и не забывать про индексы с CIFID у приемника и триггера "пустишки" тож могут сильно притормозить ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:28 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
stax.., совпадений не десятки далеко, а миллионы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:31 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
stax..персонидпропущено... попробуй еще эти (в которых есть PERSONID) индексы перед апдейтом отклюячить, а потом перестроить. не согласен, индексы с PERSONID не надо трогать я б даже сказал наоборот, добавить если нет а вот с COLLECT_FE.TELEPHONE (CIFID ) ЕСЛИ можно я б грохнул/отключил и пересоздал возможно на перестройку индекса и тратится основное время персонидИ в зависимости от длины строки и pctfree - можно получить кучу chained rows после раздувания строки на длину значения в personid причем тут personid, она ж меняет CIFID да и при смене числа на число врядли получат кучу "chained rows" хотя всякое бывает, из-за дурацкой економии блок пакуют под завязку stax Да, конечно, CIFID (смотрю в книгу - вижу... и далее по тексту). про pctfree я говорил потому что E_Schekaturova Спасибо! :) И , соответственно, добавит новый CIFID в TELEPHONE, если там поле пустое? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:33 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
E_Schekaturovastax.., совпадений не десятки далеко, а миллионы. тогда update і свою табличку с ПК PERSONID,CIFID (или ИОТ) должно помочь, оракля если зачения совпадают всеравно меняет со всем своим наворотом мож и в обычную квоту на ТС влезете да и время в разы должно уменьшиться ДБА (если есть) должны помочь, мож есть смысл разбить на порции напр по 100тысч ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:57 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Nobody1111dbms_photoshopЯ так нигде и не нашел описания почему при увеличении параллелизма может сильно "раздуваться" потребление темпа. Не очень понимаю тут вопроса "почему". ИМХО, все естественно. Слэйвы обязаны координировать между собой только непересечение конечных результатов работы, а кухня у каждого своя, без учета, что таких слейвов еще N-цать. Хотя, конечно, по уму, ограниченность темпа при построении плана запроса стоило бы учитывать. Ограничивать это как-то можно с помощью Automatic DOP и (против лома нет приема) прямым ограничением parallel на сессию с помощью Resource Manager. ....вообще, конечно, данный топик показывает выигрышный способ получить толковое обсуждение вопроса вместо сра dropping bricks - зарегистрироваться под женским именем. Истинность логина ТС никоим образом не подвергаю сомнению.Дядя Том в принципе на пальцах все хорошо рассказывает https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:374218170986#2653212400346307852 each parallel execution server will need it's own temp space and the coordinator could need its own and each parallel execution server might need as much (or more since they get less RAM overall to use - each one does) temp as the single thread did. For a query like that - we would pick the smaller of the two tables and full scan/hash it. Each parallel execution server might have to spill that to temp (whereas in single threaded mode, just one would) It is very very very easy for parallel query to require considerably more of every resource than a single threaded query.А мой топик на эту тему на форумах oracle.com где-то затерялся ну и ладно. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 15:59 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
E_SchekaturovaИ , соответственно, добавит новый CIFID в TELEPHONE, если там поле пустое? ой, проморгал если там поле пустое, то не добавит, а заменит условие update тогда надо поменять напр на nvl(tel.CIFID,-1e111) <> prs.CIFID ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 16:06 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
Я прошу прощения, а что у Вас за база? DSS,OLAP, OLTP? Если честно, то воспользовавшись некоторыми советами, например про PARALLEL DML, Вы рискуете убить OLTP. А APPEND её убъет гарантированно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 16:28 |
|
Как ускорить MERGE?
|
|||
---|---|---|---|
#18+
ArtNickЯ прошу прощения, а что у Вас за база? DSS,OLAP, OLTP? Если честно, то воспользовавшись некоторыми советами, например про PARALLEL DML, Вы рискуете убить OLTP. А APPEND её убъет гарантированно.Про APPEND особенно оригинально. Тебе лучше в менеджеры идти если любишь порассуждать о различии OLAP vs OLTP и когда первое становится вторым и наоборот. А у меня одна из систем и OLTP и OLAP, так что теперь не использовать параллельность? Или просто боятся "риска смерти"? PS E_Schekaturovaвсе операции будут производиться в схеме collect_fe 1 раз в месяц ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2015, 16:35 |
|
|
start [/forum/topic.php?fid=52&msg=38942165&tid=1880955]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 157ms |
0 / 0 |