DeepEdit!

Когда мы были инструкторами по Oracle, мы любили начинать курсы по на-
стройке с показа демонстрационных материалов с помощью настольного про-
ектора (в те времена была такая        Пользуясь им, мы могли показать
свою точку зрения на установку целей настройки. Конечно, проектор необходи-
мо было сфокусировать, или "настроить". Каждую ночь команда уборщиков

проводила уборку помещений и протирала проектор. Во время этой протирки
проектор, естественно, сбивался с фокуса.        утро мы приходили в

аудиторию и обнаруживали, что необходимо снова его приводить в рабочее со­стояние. Это служит прекрасным примером, как нужно перенастраивать систе­му. Нам приходилось начинать, когда слайд был абсолютно не в фокусе. Пока

проецируемое изображение было        оно как бы представляло

которой требуется настройка. Мы медленно подкручивали ручку, и постепенно

изображение становилось четче. Хотя наша цель состоит в том, чтобы 

остано­вить настройку, 

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

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

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

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

Основной ответ на вопрос: "Не пора ли остановиться?" зависит от того, на­сколько хорошо идентифицируется и измеряется эффект усилий по настройке.

Во время идентификации проблем системы можно столкнуться со множеством

изменений конфигурации, которые способны помочь в решении проблемы. Но

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

индексов для одной таблицы.

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

эскалация уровня страничной подкачки файлов (paging), а в некоторых случа­ях — даже деактивация и свопинг процессов).

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

решили ее в первый раз. Использование хирургического подхода к управлению производительностью позволяет увеличить практический опыт АБД, так как появляется большое количество возможностей для настройки.

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

стратегически важных 

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

Когда удается достичь намеченных целей по производительности, следует

прекратить все попытки настройки. Не забывайте контролировать процесс и

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