Один из самых серьезных недостатков традиционного метода настрой­ки Oracle заключается в том, что отсутствует критерий завершения. В результате основанные на этом методе проекты могут длиться до тех пор, пока не иссякнет терпение или деньги (по причине возникновения маниакально-настроечного психоза (CTD), упоминавшегося в главе 3). В методе R, наоборот, условие завершения определено:

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

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

В действительности большинство проектов повышения производи­тельности вполне могут обходиться без формального финансового анализа. В штате многих компаний имеется персонал, решающий задачи повышения производительности там, где в этом возникает необходи­мость. Во многих случаях штатные аналитики еженедельно несколько часов посвящают вопросам производительности. Расходы, вызванные наличием у аналитика даже острой формы синдрома CTD третьей сте­пени настолько незначительны, что остаются незамеченными в боль­шинстве компаний.

Даже в тех ситуациях, когда аналитики по производительности распо­лагают свободным временем, неудобства доставляет отсутствие возмож­ности определить, действительно ли пользовательская операция опти­мизирована, т. е. выполняется так быстро, как это возможно. Это прак­тически нельзя выяснить, измеряя производительность по общесистем­ной статистике, как это практикуется в обычных методах настройки. В то же время время отклика, положенное в основу метода R, позволяет узнать, есть ли еще у пользовательской операции резервы повышения производительности. По профилю ресурсов и данным расширенной трассировки, по которым он построен, очень просто определить, есть ли возможность дальнейшего улучшения времени отклика операции.

В примере 10.7 показано, как выглядит профиль ресурсов, когда поль­зовательская операция оптимизирована. Обратите внимание на сле­дующие характерные моменты:

Общее время отклика невелико. Это обязательное условие. Если об­щее время отклика недостаточно мало, значит, работа не закончена и не имеет значения, что остальные параметры в норме. «Достаточ­но малое» значение определяется бизнесом, об этом рассказывалось в главе 4.

В общем времени отклика преобладает процессорное время (обычно более 80% общего времени отклика), но приложение не расходует его понапрасну.

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

Операции, не связанные с использованием процессора и доступом к файлам, занимают очень незначительное время.

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

Почему в оптимальном профиле ресурсов работа процессора и физиче­ский ввод/вывод занимают верхние строчки? Это естественно. Конеч­но, что-то должно быть наверху, если общее время отклика отлично от нуля. Что вы хотели бы там увидеть? В действительности база дан­ных выполняет очень простую работу: управляет данными, находящи­мися в долговременном хранилище. База данных читает, обрабатыва­ет и записывает данные. В оптимальном профиле ресурсов процессор­ная обработка опережает физический ввод/вывод по той причине, что проблемы производительности ввода/вывода решаются проще и де­шевле (обычно путем оптимизации SQL в приложении). Если решение проблемы стоит недорого, она, скорее всего, будет решена, что умень­шит затрачиваемое из-за нее время, и в верхних строках профиля ока­жется другое событие. Таким образом, по мере оптимизации произво­дительности системы, процессорное время перемещается в начало профиля ресурсов. Даже если длительность процессорной обработки мала, она обычно занимает верхнюю строчку, т. к. большинство приложений требуют от Oracle значительно больше времени на обработку данных, чем на их чтение и запись.

Вся прочая активность базы данных обычно «необходима, но нежела­тельна». Например, событие latch free сигнализирует об использова­нии ресурса, призванного предотвратить повреждение ряда внутрен­них структур данных Oracle в условиях высокой конкуренции [Millsap (2001c)]. Нам необходима эта возможность «сделать паузу, пока за­щелка недоступна», но наши приложения будут выполняться быст­рее, если мы сможем добиться того, чтобы они ожидали события latch free как можно реже. Подавляющее большинство так называемых со­бытий ожидания Oracle относятся к категории «необходимая возмож­ность, которой следует избегать».

Основным ресурсом, потребляемым хорошо отлаженным запро­сом, будет, скорее всего, процессорное время. Однако из этого не следует, что если основной потребляемый запросом ресурс -процессорное время, то он хорошо отлажен. Вполне возможно, что запрос мог бы расходовать гораздо меньше процессорного времени и возвращать при этом верный результат. Наиболее подходящий способ для этого... (барабанная дробь) ...исключе­ние лишних вызовов LIO.

Работа заканчивается, когда расходы на сокращение количества и про­должительности вызовов начинают превышать выигрыш от прироста производительности.