Хранимая процедура работает ужасно - увеличьте время ожидания или устраните проблему

Question

Я унаследовал интерфейс, написанный сторонним разработчиком. Этот интерфейс взаимодействует с Oracle через процедуры, написанные другой третьей стороной. Рассматриваемая хранимая процедура требует 2 минуты и 36 секунд для возврата результатов поиска, когда она выполняется вручную. Я не вижу процедуры, и эта команда предложила увеличить время ожидания в веб-приложении (размещенном на общем сервере).

В моем мире все, что занимает более 30 секунд, потребовало бы исправления производительности перед развертыванием в производство с несколькими исключениями (устаревший код, сумасшедшие отчеты и т. Д.). Вариант, который мне предложили, состоял в том, чтобы увеличить время ожидания с 30 секунд (явно добавленных разработчиком внешнего интерфейса) до 180 секунд.

Мой вопрос к вам: Каковы риски, связанные с легким подходом и увеличением времени ожидания? Если возможно, предоставьте ссылки на статьи, которые поддерживают ваши взгляды, чтобы я мог ссылаться на них.

Также не стесняйтесь, если вы считаете, что это не проблема.

Answer 1

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

Две вещи, которые нужно сделать:

Получить трассировку SQL сохраненногопроцедура.

exec dbms_monitor.session_trace_enable(binds => false, waits => true);
exec poor_performing_procedure();
exec dbms_monitor.session_trace_disable();

Посмотрите, как часто выполняются операторы и сколько времени уходит на их выполнение.

Добавление в код хуков в DBMS_PROFILERдля хранимой процедуры.

У меня есть такой код во всех моих пакетах, чтобы я мог определить, нужно ли их профилировать, установив переменную пакета:

PROCEDURE profiler_control(p_start_stop IN VARCHAR2, p_run_comm IN VARCHAR2, p_ret OUT BOOLEAN) AS
  l_ret_code INTEGER;
BEGIN
  l_ret_code:=dbms_profiler.internal_version_check;
  IF l_ret_code !=0 THEN
    p_ret:=FALSE;
  ELSIF p_start_stop NOT IN ('START','STOP') THEN
    p_ret:=FALSE;
  ELSIF p_start_stop = 'START' THEN
    l_ret_code:=DBMS_PROFILER.START_PROFILER(run_comment1 => p_run_comm);
    IF l_ret_code=0 THEN
      p_ret:=TRUE;
    ELSE
      p_ret:=FALSE;
    END IF;
  ELSIF p_start_stop = 'STOP' THEN
    l_ret_code:=DBMS_PROFILER.FLUSH_DATA;
    l_ret_code:=DBMS_PROFILER.STOP_PROFILER;
    IF l_ret_code=0 THEN
      p_ret:=TRUE;
    ELSE
      p_ret:=FALSE;
    END IF;
  END IF;
END profiler_control;

Таким образом, внутри процедур есть код, подобный следующему:

create or replace procedure poorly_performing_procedure() 
begin
  if run_profiler then
    profiler_control('START', 'poorly_performing_procedure', g_retval);
  end if;
...
  if run_profiler then
    profiler_control('STOP', 'poorly_performing_procedure', g_retval);
  end if;
end poorly_performing_procedure;
/

Oracle предоставляет сценарии (один с именем profiler.sql), которые можно использовать для получения красивых отчетов, показывающих, сколько раз каждая инструкция / операция PL / SQL былавыполняется во время пробега.Вот ссылка на документацию DBMS_PROFILER для 10g.

Answer 2

Проблема увеличения времени ожидания во всем мире заключается в том, что в будущем вы можете столкнуться с несколькими проблемами:

1. Атаки отказа в обслуживании.
2. Исчерпание ресурса на сервере.
3. Пониженная пропускная способность.

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

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

Answer 3

Если вы действительно хотите, чтобы процедура завершилась, вы должны запустить ее как фоновую задачу (не в контексте скрипта) и сообщить о ее состоянии в ресурсе, доступном через AJAX или на простой странице.

Если процедура выполняется в контексте сценария, то всякий раз, когда сценарий умирает, сеанс Oracle также умирает и процедура откатывается, если она еще не завершена.

Это может быть вызвано причинами, отличными от тайм-аута (соединение прерывается, пользователь закрывает страницу и т. Д.)

Answer 4

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

1. Увеличьте время ожидания и
2. Поощряйте сторонних поставщиков к решению проблемы.

Как уже говорили другие, увеличение тайм-аута не является хорошим решением по разным причинам. Поощрение сторонних поставщиков помочь (например, угрожая заменить их заявку конкурентом или отказаться платить лицензионные сборы до тех пор, пока не будут решены ваши проблемы), может быть вашим лучшим выбором. Как правило, человек, с которым вы хотите поговорить об этом, - ПАРЕНЬ, а не технический персонал. Техники, как правило, не кричат ​​о потере дохода, потому что это не влияет на них напрямую. Менеджер по продажам DOES заботится, потому что, если вы внесете залог или откажетесь платить, это, вероятно, окажет прямое влияние на его зарплату, поэтому он заинтересован в том, чтобы вы были довольны, и он, вероятно, имеет некоторый уровень влияния на тек-х. Ключевые фразы для работы с продавцами: «... производительность недопустима в нашей среде ...», «... невозможно поддержать бизнес с помощью вашего приложения ...», «... не будет платить ни на один цент больше для этого приложения, пока оно не отвечает нашим потребностям ... ", и всегда популярное" ... мы будем оценивать альтернативные решения ... ". Помните, чувак по продажам должен быть вашим интерфейсом с его компанией - так что узнайте его - или, что еще лучше, попросите какого-нибудь менеджера пообщаться с чуваком по продажам на некоторое время. (Это то, что менеджеры для ...). Скрипучее колесо получает смазку ...

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

Удачи.

Answer 5

Не думаю, что увеличение времени ожидания до 180 секунд - это хорошая идея. Я работал в быстро растущей компании в течение 2 лет. За это время у нас были десятки хранимых процедур, время выполнения которых было изменено. Они начали бегать менее чем за 1 секунду, затем они заняли 30 секунд, а затем в итоге 2 или 3 минуты. Как только они дойдут до 2 минут, они вызовут тайм-аут на сайте, мы его поймаем и перепишем процесс, чтобы сделать его более эффективным. Короче говоря, если вы увеличили время до 180 секунд, это означает, что вы можете увеличить время ожидания до 360 секунд в месяц, а затем до 720 секунд через 2 месяца. Вы можете видеть, куда это идет. Если другие не согласны, вам нужно понять, откуда они берутся, потому что любой рост данных замедлит вашу производительность.