Oracle для профессионалов
Используйте связываемые переменные
Если бы мне пришлось писать книгу о том, как создавать немасштабируемые приложения Oracle, первая и единственная ее глава называлась бы "Не используйте связываемые переменные". Это — основная причина проблем, связанных с производительностью, и основная помеха масштабируемости. Особенности использования разделяемого пула Oracle (очень важной структуры данных разделяемой памяти) требуют от разработчиков использовать разделяемые переменные. Если надо замедлить работу приложения Oracle, вплоть до полного останова, — откажитесь от их использования.
Связываемая переменная — это подставляемый параметр запроса. Например, для получения записи доя сотрудника с номером 123, можно выполнить запрос:
select * from emp where empno = 123;
Но можно задать и другой запрос:
select * from emp where empno = :empno;
В обычной системе информацию о сотруднике с номером 123 могут запрашивать всего один раз. В дальнейшем будут запрашивать информацию о сотрудниках с номерами 456, 789 и т.д. При использовании в запросе литералов (констант) каждый запрос является для СУБД абсолютно новым, никогда ранее не выполнявшимся. Его надо разбирать, уточнять (определять объекты, соответствующие именам), проверять права доступа, оптимизировать и т.д. — короче, каждый выполняемый уникальный оператор придется компилировать при каждом выполнении.
Во втором запросе используется связываемая переменная, :empno, значение которой подставляется в запрос при выполнении. Этот запрос компилируется один раз, а затем план его выполнения запоминается в разделяемом пуле (в библиотечном кеше), из которого его можно выбрать для повторного выполнения. Различие между этими двумя вариантами в плане производительности и масштабируемости — огромное, даже принципиальное.
Из представленного выше описания вполне понятно, что разбор оператора с явными, жестко заданными константами (так называемый полный разбор) выполняется дольше и требует намного больше ресурсов, чем повторное использование уже сгенерированного плана запроса (его называют частичным разбором). Менее очевидным может оказаться, насколько постоянный полный разбор сокращает количество пользователей, поддерживаемых системой. Отчасти это связано с повышенным потреблением ресурсов, но в гораздо большей степени — с механизм защелок, используемых в библиотечном кеше. При полном разборе запроса СУБД будет дольше удерживать определенные низкоуровневые средства обеспечения последовательного доступа, которые называются защелками (подробнее о них см. в главе 3). Защелки защищают структуры данных в разделяемой памяти сервера Oracle от одновременного изменения двумя сеансами (иначе эти структуры данных Oracle в конечном итоге были бы повреждены) и от чтения этой структуры данных по ходу изменения другим сеансом. Чем чаще и на более продолжительное время на эти структуры данных устанавливаются защелки, тем длиннее становится очередь для установки этих защелок. Точно так же происходит при использовании длинных транзакций в среде MTS, — монополизируются критические ресурсы. Временами машина может казаться минимально загруженной, а СУБД работает очень медленно. Вполне вероятно, что один из сеансов удерживает защелку и формируется очередь в ожидании ее освобождения. В результате работа с максимальной скоростью невозможна. Достаточно одного неверно работающего приложения для существенного снижения производительности всех остальных приложений. Одно небольшое приложение, не использующее связываемые переменные, приводит со временем к удалению из разделяемого пула необходимых SQL-операторов других хорошо настроенных приложений. Достаточно ложки дегтя, чтобы испортить бочку меда.
При использовании связываемых переменных любой сеанс, выдающий тот же самый запрос, будет использовать уже скомпилированный план выполнения из
библиотечного пула. Подпрограмма компилируется один раз, а используется многократно. Это очень эффективно, и именно такую работу пользователей предполагает СУБД. При этом не только используется меньше ресурсов (частичный разбор требует намного меньше ресурсов), но и защелки удерживаются значительно меньше времени, и нужны гораздо реже. Это повышает производительность и масштабируемость.
Чтобы хоть примерно понять, насколько существенно это может сказаться на производительности, достаточно выполнить очень простой тест:
tkyte@TKYTE816> alter system flush shared_pool;
System altered.
Здесь я начинаю с "пустого" разделяемого пула. Если потребуется выполнять этот тест многократно, придется очищать разделяемый пул каждый раз, иначе представленный ниже оператор SQL, в котором не используются связываемые переменные, окажется в кеше и будет выполняться очень быстро.
tkyte@TKYTE816> set timing on tkyte@TKYTE816> declare 2 type rc is ref cursor; 3 l_rc rc; 4 l_dummy all_objects.object_name%type; 5 l_start number default dbms_utility.get_time; 6 begin 7 for i in 1 .. 1000 8 loop 9 open l_rc for 10 'select object_name 11 from all_objects 12 where object_id = ' i; 13 fetch l_rc into l_dummy; 14 close l_rc; 15 end loop; 16 dbms_output.put_line 17 ( round( (dbms_utility.get_time-l_start)/100, 2 ) 18 ' seconds...' ); 19 end; 20 / 14.86 seconds...
PL/SQL procedure successfully completed.
В этом коде используется динамический SQL для запроса одной строки из представления ALL_OBJECTS. Он генерирует 1000 уникальных запросов со значениями 1, 2, 3, ... и так далее, жестко заданными в конструкции WHERE. На моем ноутбуке с процессором Pentium 300 Мгц для его выполнения потребовалось около 15 секунд (скорость выполнения на разных машинах может быть различной).
Теперь сделаем то же самое с использованием связываемых переменных:
tkyte@TKYTE816> declare 2 type rc is ref cursor; 3 l_rc rc; 4 l_dummy all_objects.object_name%type; 5 l_start number default dbms_utility.get_time; 6 begin 7 for i in 1 .. 1000 8 loop 9 open l_rc for 10 'select object_name 11 from all_objects 12 where object_id = :x' 13 using i; 14 fetch l_rc into l_dummy; 15 close l_rc; 16 end loop; 17 dbms_output.put_line 18 (round( (dbms_utility.get_time-l_start)/100, 2 ) 19 ' seconds...'); 20 end; 21 / 1.27 seconds...
PL/SQL procedure successfully completed.
В этом коде использован точно такой же алгоритм. Единственное изменение — вместо жестко заданных значений 1, 2, 3... и так далее в запросе используется связываемая переменная. Результаты весьма впечатляющи. Код не только выполняется намного быстрее (разбор запросов требовал больше времени, чем их реальное выполнение!), но и позволяет большему количеству пользователей одновременно работать с системой.
Выполнение операторов SQL без связываемых переменных во многом подобно перекомпиляции подпрограммы перед каждым вызовом. Представьте себе передачу клиентам такого исходного кода на языке Java, что перед любым вызовом метода класса им необходимо вызывать компилятор Java, компилировать класс и выбрасывать сгенерированный байт-код сразу после выполнения метода. При необходимости вызова того же метода в дальнейшем им пришлось бы делать то же самое — компилировать, запускать и выбрасывать байт-код. В своих приложениях никто так не поступает — не делайте этого и в СУБД.
В главе 10 мы рассмотрим способы определить, используются ли связываемые переменные, различные варианты их применения, поддерживаемую СУБД возможность автоматической подстановки связываемых переменных и т.д. Мы также рассмотрим особый случай, когда использование связываемых переменных нежелательно.
Часто, как и в рассматриваемом проекте, — переписать существующий код так, чтобы использовались связываемые переменные, является единственно возможным выходом. Получаемый в результате код работает на несколько порядков быстрее и во много раз увеличивается количество поддерживаемых системой одновременно работающих пользователей. Для этого, однако, требуется много времени и усилий. Дело не в том, что использовать связываемые переменные сложно или при этом часто делают ошибки, — проблема в том, что с самого начала этого не делали, и поэтому пришлось пересмотреть и изменить практически весь код. Разработчикам не пришлось бы платить такую цену, если бы они с первого дня понимали принципиальную важность использования в приложении связываемых переменных.
