|
Распределенные запросы. Мистические действия оптимизатора
|
|||
---|---|---|---|
#18+
Приветсвую ! Недавно обсуждался сабж про распределенные запросы. Задача решилась, но, как оптимайзер понял чего надо делать я так и не догнал Запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Не работает, так как выдается эксепшн ORA-02064 (distributed operation not supported). Прокрыжив кучу оракуловских доков типа [Administrators Guide].[Tuning distributed Queries] а также [Performance guide and reference] не нашел никакого описания того, чего надо настраивать и как [У меня 9i EE удаленный сервак оказался 8.x ]. Добрые люди подсказали установить distributed transactions>0 [у меня стояло 46 до админа удаленного сервака дозвониться невозможно] После кучи комбинаций вышеуказанного сиквела, я нашел некое заветное сочетание, которое выполнилось мгновенно. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Вопрос: 1. Так как нужно настраивать оракул, чтобы distributed operation поддерживались и я мог использовать хинты типа DRIVING_SITE 2. Если последний cиквел выполняется как надо, значит distributed operations все таки поддерживаются? 3. В последнем примере план выглядит след образом: Код: plaintext 1. 2. 3. 4.
Чего и нужно было. Так в чем же секрет, мать его ...... Где/куда рыть? Спасибо большое .... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2002, 16:10 |
|
Распределенные запросы. Мистические действия оптимизатора
|
|||
---|---|---|---|
#18+
У вас судя по предыдущим постингам (там где вы приводите старый план выполнения) исползуется RBO. Вы поменяли запрос (like подразумевает невозможность использования индекса) вот и план выполнения поменялся. Если вы считаете, что удаленная таблица будет всегда больше локальной, то сохраните этот план в query outlines. Если же надо менять план динамически, то поэксперементируйте с CBO (мне кажется, что удаленная статистика также принимается во внимание, но не уверен). ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2002, 16:59 |
|
Распределенные запросы. Мистические действия оптимизатора
|
|||
---|---|---|---|
#18+
Вероятно, повлиял порядок соединения таблиц. Попробуйте выполнить тот же запрос , но во FROM поменяйте таблицы местами: Код: plaintext 1. 2.
Если станет медленно, то это ОНО :-) Далее Код: plaintext 1. 2. 3. 4. 5.
Опять быстро ? Тогда читайте в доке про ordered и другие хинты, и помните про фичу - в отсутствие многих причин влияющих на порядок соединения (хинты, режим оптимизатора и т.д.) оно будет производится в обратном порядке, т.е. FROM a, b к b будет присоединяться a ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2002, 17:05 |
|
Распределенные запросы. Мистические действия оптимизатора
|
|||
---|---|---|---|
#18+
Порядок соединения может влиять только на RBO и то при некоторых условиях ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2002, 17:11 |
|
Распределенные запросы. Мистические действия оптимизатора
|
|||
---|---|---|---|
#18+
2killed >Порядок соединения может влиять только на RBO и то при некоторых условиях Дык ! ... В данном случае - удаленные таблички на 50 килотысяч записей - как-то боязно отдавать план в шаловливые ручки CBO :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2002, 17:42 |
|
|
start [/forum/topic.php?fid=52&fpage=2843&tid=1993152]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 295ms |
total: | 427ms |
0 / 0 |