AskTom in Moscow: отчет Дмитрия Подушко

Общие впечатления

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

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

Первая тема доклада — «Откуда вы знаете, что вы знаете…»

Самая краткая часть доклада. Отчасти юмористическая.

«Предположим, что все наши знания мы черпаем из телепрограмм» — предложил автор доклада и далее минут пять приводил некоторые последствия этого опрометчивого шага. Так, у него лично не оставалось бы сомнений в том, что вентиляционная система любого здания прекрасно подходит для того, чтобы в ней прятаться, а также то, что пользуясь ей можно попасть в любую точку этого здания. Кроме того, он был бы уверен, что сталкиваясь, автомобили практически всегда взрываются. Когда вы окружены превосходящим числом врагов, продолжал Том Кайт, они всегда будут нападать строго в порядке живой очереди, терпеливо ожидая пока вы разделаетесь с их предшественниками. Он также верил бы в то, что наличие большого объема работы заставляет всех отцов забывать дни рождения своих детей; все бомбы имеют очень большие, красные LED дисплеи, показывающие точное время, оставшееся до взрыва; а все иностранцы между собой говорят только по-английски.

Убедившись по вымученным улыбкам аудитории, что юмор оценен, оратор затем перешел на более профориентированные примеры. «Когда замедляется работа системы, то все знают почему — не хватает мощности процессора или необходимо переместить файлы с данными на другие диски. Мощность добавлена, файлы перемещены — нет результата. Добавили, переместили еще раз — тот же результат, вид сбоку. Взглянули на проблему вооруженным глазом — ба! Ну кто бы мог подумать, обнаружились массовые блокировки. Увеличение мощности только ухудшило ситуацию, перемещение файлов не оказало никакого влияния вообще…».

Законы ораторского искусства потребовали ввернуть в этот момент заковыристое высказывание кого-нибудь из великих и докладчик не стал изменять традициям. Афоризм Артемуса Уорда "It ain’t so much the things we don’t know that get us into trouble. It’s the things you know that just ain’t so " был призван послать переводчика в нокаут и подвести черту под рассуждениями о знаниях и их очевидности. И таки подвел, потому что далее автор перешел с высокой поэзии на демократическую прозу, оформленную в виде кусочков кода. К вящей, надо заметить, радости присутствовавших.

Свежий тезис о том, что «things change», был проиллюстрирован на примере конструкции BULK COLLECT в 9i и в 10g. В десятой версии выражение for x in (select * from big_table)… неявно переписывается в array fetching, что избавляет в некоторых случаях от необходимости писать дополнительный код («жизнь-то налаживается…»).

В продолжении зарисовок были приведены еще несколько «очевидных» проблем и их решений, которыми изобилует интернет и к которым докладчик призывал относиться скептически (или не очень — это как фишка ляжет в зависимости от версии Oracle). Среди них:

• Тюнинг начинается с перемещения файлов, реорганизации таблиц и пересозданию всего, до чего только можно дотянуться;
• У таблиц должен быть один (несколько) экстент(ов);
• Разнести индексы и данные;
• Неукоснительно следовать «oracle tuning tips», полученным из Google;
• Во всем виновата база.

В заключении первой части выступающий тактично, но настойчиво порекомендовал не оставлять высказывания экспертов «по моему мнению…», «я утверждаю…», «я думаю…», «я чувствую…», «я знаю…» без доказательств. Для сбора доказательств под рукой предлагал иметь джентльменский набор из tkprof, statspack и runstats. Еще раз прозвучали слова-заклинания, что «things change», «nothing is 100 % good, nothing is 100 % evil», хит многих сезонов «it depends», и много, много других проверенных временем паттернов изворотливости дипломатичности.

Позже на сайте AskTom нашел статью, датированную 2005 г. примерно по той же теме: False Knowledge Article, why evidence is a good thing. Why advice from anyone needs to be questioned, especially from «experts».

Вторая тема доклада — «The Best Way»

Более восьми тысяч вопросов о лучшем способе выполнения той или иной работы, заданных на сайте AskTom, по-видимому, настроили Тома Кайта на философский лад.

«Что такое лучший способ?» — интересовался он у аудитории, старательно делая вид, что только сейчас обдумывает свой ответ — «Если бы существовал универсальный способ решений всех задач, то не возникало бы необходимости реализовывать другие способы». Затем непродолжительное время сыпал цитатами, целью которых было дать понять собравшимся, что не только он один так думает. В качестве живого примера неоднозначности привел HASH JOIN и NESTED LOOP для пары таблиц. В зависимости от их размера и настроения оптимизатора контекста звание «лучшего пути» плавно переходит от одного метода соединения к другому.

Вообще, слово «контекст» с тех пор звучало часто. Видимо, это была замена слегка приевшемуся, но не потерявшему своей актуальности «все зависит».

Процесс решения проблемы (и определения лучшей практики для нее) по Тому Кайту выглядел так:

• получить факты (tkprof и т. д.);
• добавить еще немного фактов (обработав данные из первого пункта);
• определить контекст;
• определить те правила, которые не подходят для данной ситуации.

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

Как говорится, «конец был немного предсказуем» — тепло поблагодарив выступающего аплодисментами за его профессионализм, энергетику и сильную харизму, народ пошел на перерыв.

Третья тема доклада — «Worst practices»

Часть, в которой автор доклада показал, что жанр «Вредные советы» успешно освоил не только Г.Остер.

Топ-лист советов выглядит, по мнению Тома Кайта, так:

• Никогда не задавайте вопросы экспертам. Это им очень не нравится. А если уж спрашиваете, то верьте на слово;

• Не стоит пользоваться связываемыми переменными. Код легче пишется, он безопасен. Проблема повторного разбора запросов — не проблема.

• Не стоит огорчать пользователя сообщениями об ошибках. Даже если пользователь — это другая программа. Достаточно просто сохранить сообщение в журнале;

• Чем более универсально то, что вы делаете, тем лучше. И, вообще говоря, вам не стоит заниматься архитектурой приложения. Все, что вам нужно, это одна таблица с ключом и xml документом. В конце концов, всегда можно создать новую базу, если старая вдруг стала недостаточно быстрой;

• Имеет смысл запустить максимально возможное количество экземпляров Oracle на одном сервере. Многочисленные процессы dbwr не будут конкурировать друг с другом. Также существует магическое глобальное представление, способное показать все узкие места в использовании памяти;

• Необходимо изобрести как можно больше велосипедов. Во-первых, потому что кодирование — это весело, во-вторых, никто не хочет зависеть от производителя ПО, а в третьих, это просто дешевле;

• Ни в коем случае не тестируйте. Программа просто не может сломаться. А раз так, то зачем тратить время. Проблем производительности тоже, по всей видимости, не предвидится. Если уж вы все-таки решились тестировать, то знайте, что однопользовательский тест на вашем компьютере даст такие же результаты, как и тест на полностью загруженном сервере. И да, тестирование на пустой базе аналогично тестированию на заполненной. Смело обновляйте версию сервера — это не может вызвать никаких трудностей;

• Бессмысленно использовать типы отличные от varchar. Это проще, а оптимизатор сам разберется какой реальный тип вы имели в виду;

• Вы должны делать commit как можно чаще. Лучше всего в этом смысле — auto commit. Это экономит ресурсы и программа работает быстрее;

• Управление конфигурацией вам не нужно. Нет необходимости отслеживать многочисленные grant, create, alter и прочие инструкции. В конце концов, все можно извлечь из словаря данных;

• Масштабируемость не нужна, так как Oracle сам по себе очень масштабируем;

• Не стоит думать о безопасности данных;
• DBA и программисты просто очень разные — смиритесь с этим. Главный приоритет у DBA — это защитить базу от разработчика. Главный приоритет у разработчика — редко, а лучше никогда не общаться с DBA, помня при этом, что за производительность, масштабируемость и безопасность ответственен именно DBA. А не разработчик.

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

---

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