Оптимизация Oracle SQL: запрос SQL занимает очень много времени

Если у вас еще нет индексов для столбцов L_code и licensing_no, я бы попробовал это.

Если есть много записей с L_code = '1000' и единственный дополнительный тест - это NOT NULL, у вас, вероятно, проблема с количеством элементов. Индексам сложно выбрать значение NULL или нет.

Количество возвращаемых строк неважно - вопрос в количестве проверенных строк.

Какие есть индексы?

Избавьтесь от ОТЛИЧИТЕЛЬНОГО.

Хммм ... избавление от DISTINCT может помочь, учитывая, что код является ПЕРВИЧНЫМ КЛЮЧОМ. Я не думаю, что это является причиной основных проблем обработки. Если вы считаете, что RPAD и т. д. Вызывают большую часть задержки запроса.

Индексы в основном восходят к полю КОД. Это единственные релевантные индексы в таблице.

Вы можете предварительно построить производное значение RECORD во вторичной таблице, представлении или столбце, используя триггер и запрос, которые вместо создания его на лету, если к таблице часто запрашиваются.

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

Мне жаль всех, кто смотрит на этот SQL, но это ошеломляющая проблема с сервером или что-то в этом роде. Сценарий, кажется, исчерпал себя, и я считаю, что это проблема доступности данных относительно того, где находится БД, но кто-то может дать мне некоторое представление.

На своем Localhost запускаю код, работает мгновенно. Я экспортирую данные, которые он дает мне, из таблицы данных в текстовый файл менее чем за секунду ... готово.

В нашей среде разработки такая же страница находится в старом ASP. Половина нашего сайта находится в классическом ASP, поскольку мы конвертируемся в .NET. Проблема, похоже, в том, что на сайте DEV классическая страница ASP работает отлично, быстро и выполняется менее чем за секунду. Когда я загрузил недавно преобразованный файл ASPX, он завис на этом запросе около 30 секунд.

На Localhost старый классический ASP зависает примерно на 30 секунд.

Итак, у меня наоборот проблема в том, что классический ASP висит не на сайте DEV, а на моей машине, в то время как моя собственная страница ASPX висит на сайте DEV, но НЕ на моей машине. Разница в том, что я считаю, что данные извлекаются в моем собственном коде на сайте DEV, в то время как страница ASP извлекает данные из кода, который находится на старом сервере сайта DEV, который переносит результаты на сайт DEV. Таким образом, технически код не запускается на одном сервере. Классический код ASP находится на нашем старом сервере сайта.

Я предполагаю, что между двумя сайтами есть какая-то проблема со скоростью или проблема с сервером.

Вы не сможете диагностировать эту проблему, если не знаете, как оптимизируется запрос.

Попробуй это:

explain plan for SELECT DISTINCT 
'LRS-TECH  1' || rpad(code,7) || rpad('APPTYPE',30) || 
 rpad(licensing_no,30) || rpad(' ',300) AS RECORD 
FROM APPS
WHERE L_code = '1000' AND licensing_no IS NOT NULL
/

select * from table(dbms_xplan.display)
/

Теперь попробуйте это тоже ... это поможет вам обнаружить проблему со статистикой:

explain plan for SELECT /*+ dynamic_sampling(4) */ DISTINCT 
'LRS-TECH  1' || rpad(code,7) || rpad('APPTYPE',30) || 
 rpad(licensing_no,30) || rpad(' ',300) AS RECORD 
FROM APPS
WHERE L_code = '1000' AND licensing_no IS NOT NULL
/

select * from table(dbms_xplan.display)
/

Пожалуйста, обновите исходное сообщение результатами тех.

Как указано в большинстве ответов здесь, ваш вопрос звучит как вопрос оптимизации. Ваш последующий ответ существенно меняет характер вопроса. Я предлагаю опубликовать его как новый вопрос или изменить исходный вопрос, чтобы задать то, что вы действительно хотите знать.

Я не могу помочь вам с проблемой ASP / ASPX, но если бы это был вопрос оптимизации, я бы предложил создать индекс на основе функций для нового предложения WHERE следующим образом:

SELECT DISTINCT 
    'LRS-TECH  1' || rpad(code,7) || rpad('APPTYPE',30) || 
     rpad(licensing_no,30) || rpad(' ',300) AS RECORD 
FROM APPS
WHERE DECODE(L_code,'1000',licensing_no,NULL) IS NOT NULL;

Индекс на основе функции DECODE (L_code, '1000', licensing_no, NULL) будет включать все записи, которые вы хотите вернуть. Если вам нужна еще большая скорость, вы могли бы создать материализованное представление результатов запроса, но это было бы скорее последней попыткой.

Интересно, связано ли это с тем, что оракул использует другой индекс (или вообще не использует) для запроса со страницы aspx. Я бы посоветовал обновить статистику в таблице, чтобы увидеть, имеет ли это значение. См. этот вопрос, чтобы узнать, как это сделать (и комментарии о том, что «вычислять статистику» устарели, вместо этого заменены пакетом)

Решение простое.

Создайте индекс для (code, licensing_no) и индекс для (l_code, licensing_no), чтобы быстрее получать записи. Сделайте «украшение» позже в приложении или просто во внешней оболочке, например:

SELECT    'LRS-TECH  1'
       || RPAD (code, 7)
       || RPAD ('APPTYPE', 30)
       || RPAD (licensing_no, 30)
       || RPAD (' ', 300) AS RECORD
  FROM (SELECT DISTINCT code, licensing_no
                   FROM apps
                  WHERE l_code = '1000' AND licensing_no IS NOT NULL)