GJSS Ответов: 1

Отчетливый запрос, требующий много времени для выполнения

Привет - у меня есть этот запрос insert в одном из моих proc для загрузки данных в целевую таблицу, где предложение distinct оказывает огромное влияние и занимает слишком много времени(так как каждая таблица содержит записи более 2 и 3 миллионов записей). Есть ли у них какой-нибудь способ оптимизировать этот запрос select с помощью distinct?

Что я уже пробовал:

Insert into target table
SELECT  DISTINCT

        tab1.col1 col1,

        tab1.col2  col2,

        tab2.col3  col3,

        tab2.col4 col4,

        tab3.col5 col5,

        tab3.col6 col6,

        tab3.col7 col7,

        tab3.col8 col8,

        tab3.col9 col9,

        to_char(tab3.col7, 'YYYY-MM') col10,

        to_char(tab3.col7, 'YYYY') col11,

        to_char(tab3.col7, 'MM') col12,

        CURRENT_DATE  col13

      FROM tab3@dblink t2

        JOIN tab4@dblink ON tab3.col5 = tab4.col13

        JOIN tab5@dblink ON tab4.col14 = tab5.col15

        JOIN tab2@dblink ON tab5.col16 = tab2.col17

        JOIN tab1 ON tab1.col18 = tab2.col3;

0x01AA

Не уверен насчет этого: но, вероятно, left join это немного помогло бы. В противном случае имейте это в виду:
- Отчетливо видно, что столько колонн-это тяжелая операция
- Убедитесь, что поля, участвующие в join индексируются

GJSS

Какой индекс мог бы увеличить скорость работы?

1 Ответов

Рейтинг:
7

Wendelius

Что касается отдельной проблемы, то если у вас много строк и вам нужно найти не дубликаты на основе нескольких столбцов, это потребует времени и ресурсов. Если избирательность высока, то правильная индексация принесет вам пользу, но если запрос извлекает, скажем, более 10% строк в таблице, то индексация не является жизнеспособным вариантом.

Судя по синтаксису, я так понимаю, что это Оракул? Если это так, то мало что нужно учитывать:

- На данный момент Вы используете отдельные ссылки на базы данных. Это, вероятно, заставляет все строки передаваться по ссылке перед выполнением соединения. Если ссылки указывают на одну и ту же исходную базу данных, рассмотрите возможность создания представления в источнике с соединениями и различиями и выберите только это представление. Это может устранить необходимость ненужной передачи данных между базами данных

- Убедитесь, что доступно достаточное количество PGA, другими словами, что вы не ограничиваете размер

- Но в то же время убедитесь, что сервер не подкачивает. Если происходит подкачка, это резко замедляет запрос.

GJSS

Привет Венделиус - я использую ту же ссылку на БД, которая указывает на ту же базу данных.Кроме того, мы ссылаемся не только на удаленные таблицы, но и на таблицы, находящиеся в локальной базе данных. В таком случае, как же мы создадим представление, которое включает в себя полные результаты этого запроса select?

Wendelius

Если вы используете таблицы из обоих местоположений, вы должны убедиться, что передано минимальное количество строк. Попробуйте создать представление в удаленном конце, которое выполняет фильтрацию и объединение на основе данных, присутствующих в этой базе данных. Кроме того, вы, вероятно, можете добавить операцию distinct также в это представление, чтобы данные уже были различны при выборе из представления. После этого измените свой запрос, чтобы выбрать из представления через dblink и присоединить его к таблицам в локальной базе данных.

GJSS

Спасибо, Венделиус. Если мы создадим представление для хранения результатов запроса,которое имеет join и distinct., то как же оно будет обновляться с обновленными данными каждый раз? здесь мы должны запускать этот процесс еженедельно, чтобы загрузить инкрементные данные в целевую таблицу.
В таком случае, можем ли мы пойти с материализованным представлением?

Wendelius

Материализованное представление может быть вариантом, если вы, например, запрашиваете представление несколько раз, и возможные изменения в исходных данных не имеют значения. Однако почему бы не начать с традиционного взгляда и не посмотреть, что получится. После этого внесите изменения, если потребуются дополнительные корректировки. При обычном просмотре вам не нужно беспокоиться об обновлении данных. Это просто запрос, поэтому он не будет хранить никаких данных.

GJSS

Спасибо, Венделиус.