DeepEdit!

Редактору редко выпадает удача работать с такой книгой. Едва увидев заявку Кэри Миллсапа и Джеффа Хольта на книгу «Optimizing Oracle Response Time» (Оптимизация времени отклика Oracle) - таким было ее рабочее название, я сразу понял, как мне повезло. Эта книга вопло­щает в себе все мечты редактора: талантливые авторы, серьезное ис­следование и огромный материал.

Я хорошо помню первое знакомство с настройкой производительности Oracle. Это было еще в дни Oracle7, когда я знакомился с основами Oracle. Мне как раз поручили работу администратора всех баз данных, используемых моей группой разработки, и я подумал, что нет ничего лучше для начала карьеры администратора БД Oracle, чем серьезные работы по настройке производительности. Я купил и прочитал учеб­ник по Oracle. Узнал о кэше буферов, разделяемом пуле и коэффициен­тах попаданий.

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

Однако все получилось не так, как я себе представлял. Я удвоил размер кэша буферов, но никакого ускорения не заметил. Я сделал размер кэ­ша буферов равным половине исходного, и ничто не стало работать мед­леннее. Я увеличил разделяемый пул. Потом уменьшил его. Я метался от одного параметра к другому, но база данных упрямо продолжала работать все с той же скоростью. Было очевидно, что настройка оказа­лась более сложным делом, чем мне казалось, а я просто недостаточно умен для того, чтобы заниматься этим. Униженный, я оставил свои мечты стать суперпрофессионалом в настройке производительности.

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

В конце концов я понял, что настоящее значение имеет то, на что жа­луются пользователи. Пользователей не волнуют ни коэффициенты попаданий, ни скорость обмена с диском; им не важно, возникает ли конкуренция за защелки; не интересует их и загадочная статистика, которая может беспокоить вас или системного администратора. Поль­зователям важно только одно: насколько быстро выполняются их задания. Теперь я практически не беспокоился ни о чем, кроме того, что волновало моих клиентов. Когда клиент жаловался на низкую производительность, я думал не о каких-то коэффициентах или стати­стиках, а о том, сколько времени я могу для него сэкономить. Однако меня все еще часто мучили мысли о том, что я что-то упускаю в своей настройке, что существует какой-то уровень, которого я не в состоя­нии достичь. Я был убежден в том, что настоящие администраторы баз данных отслеживают такие статистики, как коэффициенты попада­ний, чтобы поддерживать общую эффективность их баз данных. Поче­му я не мог делать то же самое?

Заявка на книгу Кэри и Джеффа, мои беседы с ними, их курс, который я прошел, освободили меня от остатков чувства вины и стыда по пово­ду отсутствия у меня успехов по настройке экземпляра базы данных с использованием коэффициентов попаданий и других статистик уровня экземпляра. Я научился концентрироваться на времени откли­ка; Кэри и Джефф подтверждают правильность этого. Я расстраивал­ся, более того, моя самооценка снизилась, т. к. у меня не получалось управлять производительностью путем отслеживания коэффициентов попаданий и других статистик уровня экземпляра; Кэри и Джефф по­казывают, что коэффициенты попаданий можно выбросить вон. Моим главным достижением в настройке было применение статистик фай­лов трассировки (трассировки SQL и tkprof) конкретного задания для определения команд SQL, потреблявших больше всего времени; Кэри и Джефф поднимают работу со статистиками файлов трассировки на совершенно новый уровень.

Теперь вы понимаете, почему впечатление, произведенное на меня этой книгой, было (и продолжает оставаться) таким сильным. Все, что Кэри и Джефф рассказали о своем методе, резонирует с моим собствен­ным опытом. Во время наших бесед я ловил себя на том, что как только они поднимали новый вопрос, я тут же кивал в ответ: «Да, да, конеч­но, это именно так!». Рассказывая мне в первый раз, как они представ­ляют себе эту книгу, они «проповедовали перед церковным хором»1, хотя, скорее всего, и не подозревали об этом тогда. Поразительно было то, что Кэри и Джефф ясно видели там, где я блуждал впотьмах. Несо­мненно, существовал более высокий уровень, чем тот, на котором я на­ходился, но я мог его достичь, и вы тоже сможете - с помощью Кэри и Джеффа.

Обсудив с Кэри и Джеффом их планы относительно книги, я сразу по­нял, что она должна быть опубликована издательством O'Reilly. Мне понравилось редактировать их работу. Перечитывая главу за главой снова и снова, я узнал много нового и уверен, так будет и с вами. На­стоятельно рекомендую вам эту книгу. Я рад, что вы купили ее, вы не пожалеете вложенных денег. Если вы читаете эти строки, стоя у книж­ного прилавка, пожалуйста, не ставьте книгу обратно на полку. Купите ее - вложите средства в собственное развитие. Не сомневайтесь, это окупится сторицей.