|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
В бд1 есть таблица1 В бд2 есть таблица2 запрос из первой БД работает быстро авторselect * from таблица1 where id in (select id from таблица2@бд2) аналогичный запрос из второй БД работает бесконечно медленно авторselect * from таблица1@бд1 where id in (select id from таблица2) при этом на второй БД подзапрос выполняется мгновенно авторselect id from таблица2 если на второй БД вместо подзапроса указать конкретные значения (результат подзапроса) - запрос выполнится мгновенно. авторselect * from таблица1@бд1 where id in (1,2,3) куда копать? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2019, 13:07 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
reaque, driving_site? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2019, 13:16 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
Спасибо, проблему решило авторselect /*+ DRIVING_SITE(таблица1) */ * from таблица1@бд1 where id in (select id from таблица2) Если раньше этот запрос работал быстро и без хинта, что могло повлиять, если структура объектов в запросе не менялась? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2019, 13:44 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
Если результат запроса необходимо сохранить в какую таблицу через insert into, то запрос вновь бесконечно долго выполняется. Похожая проблема обсуждалась тут: https://www.sql.ru/forum/146331/driving-site-insert Но решения нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 09:32 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
reaqueЕсли результат запроса необходимо сохранить в какую таблицу через insert into, то запрос вновь бесконечно долго выполняется данных много для вставки? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 09:42 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
Запрос выдает 0 строк, так задумано, т.е. вставлять по идее нечего. Тут на форуме прочитал, что когда идет DML операция (в данном случае INSERT), то хинт в подзапросе не работает. Еще уточнение: таблица1 это не таблица, а представление. Если сделать create table MyTable1 as select * from "указанное представление", а в запросе прописать вместо представления созданную таблицу - запрос работает быстро. Созданная таблица на несколько миллионов строк, без индексов. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 11:03 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
reaqueЗапрос выдает 0 строк, так задумано, т.е. вставлять по идее нечего. Тут на форуме прочитал, что когда идет DML операция (в данном случае INSERT), то хинт в подзапросе не работает. Еще уточнение: таблица1 это не таблица, а представление. Если сделать create table MyTable1 as select * from "указанное представление", а в запросе прописать вместо представления созданную таблицу - запрос работает быстро. Созданная таблица на несколько миллионов строк, без индексов. Попробуйте, напишите например функцию, которая будет возвращать коллекцию элементов, если элементов > 0, то сделать вставку из коллекции. Пусть запрос делается "там" внутри функции, а вставка, если есть что вставлять, "здесь" ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 11:38 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
Еще уточнение: если вместо представления указать текст запроса представления - все работает быстро. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 12:50 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
reaque, https://www.freelists.org/post/oracle-l/plan-shows-insert-into-remote-table-using-all-remote-selects,1 Jonatahn LewisYou can't. The query that supplies data to the insert has to be executed by the database where the DML is taking place - which means the remote (to you) database. The plan you see is the plan from the perspective of the remote (to you) database, which is why it reports the table which you think of as local as being remote (to the executing session). If you want a plan which does ALL the work at the local (to you) database you need to create a local (to you) view for the query (possibly with a no_merge hint) and the do "insert into remote_table select * from local_view". You might, however, manage to get away with creating a set of hints on the query that force a nested loop join all the way through every table, then the plan would be (just like operation 22 in the current plan) just "REMOTE", with the join query being reported as the remote SQL. Alternatively you could create a pipelined function that returns the data you want and "insert ... select from pipelined function" https://jonathanlewis.wordpress.com/2010/10/07/distributed-pipelines/ Regards Jonathan Lewis ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 13:03 |
|
запрос к таблицам из разных БД
|
|||
---|---|---|---|
#18+
Решение: создали представление на локальной базе, в тексте запроса которого идет обращение к таблицам удаленной БД. Пока работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:15 |
|
|
start [/forum/topic.php?fid=52&msg=39825369&tid=1882392]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 158ms |
0 / 0 |