Вторая итерация

Кто виноват и что делать

Что вы будете делать, если спроектировали систему, для которой можно поставить галочку на каждой странице Database Worst Practices?

Необходимость что-то делать приходит довольно быстро. Как только вы осознаете, что самый большой сервер для СУБД в мире не способен вас спасти. Одного этого должно быть достаточно, чтобы начать приходить к мысли "что-то было сделано чертовски неправильно".

Но что? Ах... вот тут у нас проблема! Всем известно, что Oracle плохо сортирует данные, поэтому все пишут сортировку на клиентах методом пузырька. А ещё Oracle плохо джойнит таблицы. И все знают, что проблема PL/SQL заключается в том, что это интерпретируемый язык - он никогда не будет работать быстро. Ребята из Redwood Shores просто слишком много смотрели телевизор.

Вот и ответ - архитектура СУБД Oracle не даёт нам масштабироваться. Трасса для формулы 1 не подходит для езды по ней на лыжах? Заберите нас в Гималаи - нас спасут сервера приложений.

Сервер приложений и надёжность

Сервера приложений в Гималаях совсем не похожи на своих собратьев из остального цивилизованного мира. В отсутствии благоприятных климатических условий, этим серверам приходится выживать в тяжелейшей среде. Не допустимо, чтобы не выдержавший козней судьбы сервер при падении утащил за собой остальных бедняг, которые использовали его услуги. Поэтому наш сервер приложений не будет способен исполнять более одного приложения одновременно. Ведь это гималайский сервер приложений. Разумеется, мы не будем это упоминать в маркетинговых буклетах.

Сервер приложений и новейшая технология

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

Только представьте себе механизмы обеспечения одновременного доступа к таким данным.

Сервер приложений и название

Как что-то может работать медленно, если у него в названии стоит слово High Speed?

Первая итерация

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

Если вы собираетесь работать с данными, то лучшим местом для ваших транзакций будет сама СУБД. В конечном итоге PL/SQL находится настолько близко к данным, насколько это только возможно. СУБД была рождена для обработки данных - не один десяток лет инженеры Oracle работали над максимально эффективными алгоритмами. Вы получаете консолидированную систему, которую проще и дешевле сопровождать и которая может работать везде, где способна работать СУБД Oracle.

Идиллия? Не тут-то было.

Разработчики не могут диктовать СУБД подходы к программированию. Наверняка вы уже видели презентацию Тома Кайта Database Worst Practices. Один из слайдов говорит вам, что масштабирование не происходит само по себе. Для того, чтобы получить масштабируемую систему, вам необходимо следовать соответствующим подходам к проектированию и программированию. Использование самой масштабируемой СУБД в мире не гарантирует вам ничего, если ваши разработчики не понимают, что им необходимо читать столько же книг по СУБД Oracle, сколько они читают по своим любимым языкам программирования. Или, лучше того, - СУБД Oracle и должна быть их любимой средой программирования.

Что происходит, если вы начинаете использовать кувалду, потому что всё выглядит для вас как гвоздь (© Abraham Maslow)? Все шансы, что вы получите самое медленное и не масштабируемое приложение в мире.

Примерно год назад я видел кандидатскую диссертацию. В числе прочего в ней была написанная под СУБД Oracle программа. Автор не использовал order by - вообще. Вместо этого, он тащил все данные на клиента и сортировал их методом пузырька. Вы думаете, что я шучу? Если бы так. Безусловно, для всех является очевидным, что инженеры Oracle за три десятка лет не смогли реализовать нормальные алгоритмы для сортировки - новоявленный кандидат явно переплюнул их за один вечер... Или он просто не знал про order by? Стоит ли говорить, что эта кандидатская была успешно защищена. Ещё одно доказательство, что система оценок нашего образования не имеет ничего общего с практической применимостью?

Я уже писал об этом. Разработчики умудряются допускать все известные миру ошибки, просто потому что не способны прочитать два десятка страниц.

В результате выходит реализованная на базе самой масштабируемой СУБД в мире система, которая не может масштабироваться. Что вы будете делать? Безусловно, вы осознаете - проблема в том, что пока вы не знаете, как масштабироваться в этой СУБД? Или нет...? Но об этом в следующей части.

Странное поведение

В субботу мы завершили миграцию очередной системы на базе 9.2.0.7 на 10.2.0.2.

Между делом, я обратил своё внимание на наличие большого количества shared-серверов в статусе wait (receive). Эти сервера, по какому-то стечению обстоятельств, были "привязаны" к сессиям в статусе inactive - иными словами, простаивающие сессии "занимали" shared-сервер и не давали его использовать остальным. Понаблюдав за приложениями, примерно через 15 минут я смог составить test case, демонстрирующий проблему:

--Объявляем переменную типа ref-курсор
SQL> variable cur refcursor;
SQL> exec open :cur for select object_id from dba_objects order by object_name;

PL/SQL procedure successfully completed.

--Нам понадобится SID сессии
SQL> select sys_context('userenv', 'sid') from dual;

SYS_CONTEXT('USERENV','SID')
----------------------------------------------------
145

--Выберем одну строку из ref-курсора
SQL> variable n number;
SQL> exec fetch :cur into :n;

PL/SQL procedure successfully completed.

Теперь, в другой сессии:

SQL> select status, server from v$session where sid=145;

STATUS SERVER
-------- ---------
INACTIVE SHARED

Мы имеем проблему - сессия "заняла" shared-сервер, либо до закрытия курсора, либо до выборки всех записей из него.

Интересное наблюдение - если убрать из запроса order by, то ситуация не повторяется...

Добавление от 29.11.2006:
При беглом просмотре Metalink были обнаружены bug 5447395 и 5060296.

Три года спустя

В 2003 году в свет вышла книга, которая при прочтении окончательно расставила точки над i, которые давно крутились в моей голове. Спустя три года, Cary Millsap написал небольшой paper - Questioning Method R, в котором привёл "обновлённое" понимание Method R с учётом трёхлетнего опыта его использования. Мне понравился пример со skewed data (и если вы возьмётесь выписать на листе бумаги, чем плохи агрегации - список будет действительно длинным...).

В свободное время обратите внимание на эту историю. Действительно - для универсальной системы вам нужна всего одна таблица... Если бы не эти пользователи, которые хотят использовать данные :) Я только могу процитировать из статьи - "RUN LIKE HELL"!

Мой вариант

Kevin Closson привёл эту цитату.

Я хочу её перефразировать в своём варианте.

"Далеко не все понимают, что проблема заключается не сколько в масштабировании железа, сколько в отсутствии масштабирования у приложений."

А что у Вас?

На Hotsos сейчас замечательный баннер. Он гласит:

"У вас система на базе Oracle?"
...
"Или у вас критичные для бизнеса задачи на базе Oracle?"

Здесь два ключевых слова - бизнес и задачи. Когда-то давно я написал это. С тех пор ситуация не стала намного лучше.

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

Проблем с системой... Позвольте, но я повторюсь:

"У вас система на базе Oracle?"
...
"Или у вас критичные для бизнеса задачи на базе Oracle?"

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

Где бы я не появился - я знаю эту ситуацию ещё до того, как переступлю порог кабинета Директора по ИТ. Я беру любой из написанных ими отчётов и всё что я могу сказать - это "ну и что?".

Один вендор?

Для тех из вас, кто не заметил - теперь вы можете пойти сюда и скачать вот это.

Теперь вы можете скачать ОС от вендора вашей СУБД. Вы получили клон RHEL и обещание того, что Ларри называет enterprise support.

Но Oracle оказалась там, где она сейчас, благодаря работе на открытых системах.

Представьте себе холдинг. У вас есть производитель и потребитель программного обеспечения. В дополнение, инвесторы заставляют потребителя покупать программное обеспечение только у данного производителя. Идея очевидна - деньги остаются внутри холдинга. Всё хорошо, но... Есть одно элементарное правило - без конкуренции невозможно качество. Этот денежный кот на самом деле питается вашими деньгами. Вы можете кидать в него тонны денег и повышать отдачу от инвестиций путём превращения компании в руины.

Не собираемся ли мы снова забыть то время, когда множество вендоров боролись за самое эффективное с точки зрения нашего бизнеса решение?

Это не ответ?

"RTFM это не ответ".

Я услышал это сегодня.

Хорошо. Если вы не можете переносить просьбу прочитать (наконец?) документацию, то у меня есть один ответ для вас.

Этим ответом будет 42.

Вы поняли - вы в первую очередь не имеете понятия, о чём вы спрашиваете. Если вы думаете, что знания будут поступать в вашу голову автомагическим способом - тогда я вас разочарую. Этого не произойдёт - экспертами не становятся за пять минут.

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

И если вы считаете, что "RTFM это не ответ" - вы уже построили всё на песке.

Ещё одна причина

Наверняка вы все слышали, насколько важно использовать bind-переменные в СУБД Oracle.

Но следующее просто не имеет смысла:

BEGIN PKG_NAME(:DBP_AABEG,:DBP_AABEH,:DBP_AABEI); END;
BEGIN PKG_NAME(:DBP_AABGQ,:DBP_AABGR,:DBP_AABGS); END;
BEGIN PKG_NAME(:DBP_AABMJ,:DBP_AABMK,:DBP_AABML); END;

Я обнаружил это в одном из форумов Metalink.

Ещё одна причина, почему важно понимать, зачем Вам необходимо что-то делать.

Вы можете послушать...

На этой странице собраны различные podcast, в том числе и с последнего Oracle Open World.

Несколько записей, обративших на себя моё внимание:

OpenWorld 2006 Keynote Snapshot: Larry Ellison. Анонс Oracle Unbreakable Linux. Наиболее забавная вещь происходит в середине этой записи - не пропустите (и я отвечу Вам "да" - это связано с пингвинами).

OpenWorld 2006: Making Plans with PL/SQL. В числе прочего Steven Feuerstein говорит о применяемых менеджерами аргументах в попытках ускорить выпуск программного обеспечения ("что? вы собрались тестировать свой код? А я думал вы профессионалы..."). Просто не говорите менеджерам об этом :)

OpenWorld 2006: Going to Eleven. Том Кайт рассказывает о самых интересных на его взгляд новых возможностях 11 версии СУБД Oracle. Знайте что Вам ожидать.

Даже и не думайте

Вы знаете, зачем может понадобиться установка на каждый компьютер программы, которая считает количество нажатий на клавиши?

Только подумайте - для измерения производительности труда. Я говорю здесь о программистах и тестерах.

Иными словами, теперь...

1. Чем меньше вы читаете документацию - тем лучше (в это время вы не нажимаете на клавиши...).
2. Чем меньше вы думаете - тем лучше (в это время вы не нажимаете на клавиши...).
3. Вместо одной страницы кода лучше написать десять (так вы будете более производительны...).

Вы думаете, что я шучу? На самом деле это было первое, что я сам спросил. Только что разговаривал со своим другом, который работает на компанию - производителя программного обеспечения. Они действительно делают это.

Ok, теперь я скажу вам, как это происходит...

Допустим, вы начинаете измерять производительность труда программистов в LOC (lines of code) и количестве исправленных ошибок. Вы уже догадались - наиболее эффективно при такой парадигме будет выглядеть тот, кто пишет много кода с ошибками.

Если вы начнёте измерять производительность труда колл-центра в количестве принятых звонков за час - наиболее эффективным для них будет положить трубку сразу же после получения звонка от абонента.

Вы поняли, к чему я клоню. С точки зрения этих метрик наивысшую оценку получают наихудшие с точки зрения производительности подходы. И, ох - Вы уже слышали про грейды? Это когда каждый сотрудник пишет, что он делает с точки зрения бизнеса. Поскольку в конечном итоге Вас оценивают люди, далёкие от вашей предметной области - чем больше дел Вы себе напишите - тем лучше...

Великолепно!

Замечательно - что я могу ещё сказать? Сколько это твердят миру, выбрасывая в мусорную корзину информацию, которой там и место?

Сколько людей говорят "мы делаем это, потому что где-то про это слышали"? Или потому, что им посоветовали это так называемые "эксперты"?

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

Финал

Финалом этой истории будет...

Они (эти ребята из Oracle Support) попросили нас закачать сбойный backup piece к ним на ftp, чтобы они смогли разобраться с ним "на месте". Резонное желание, если только не считать, что...

53.7 гигабайта. В сжатом виде. Закачать на ftp. Ух.

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

Крайний срок был назначен на 11 число. Если к этому времени поддержка не смогла бы найти решение - был бы запущен процесс по перестройке данных. Да - эти данные могут быть пересозданы "с нуля". Это будет недёшево, как с точки зрения денег, так и времени. Тем не менее, ребята из поддержки сказали, что до 11 числа они не успеют в любом случае - сделаем мы закачку к ним на ftp или нет.

Поцесс по перестройке уже запущен.

Битва с ...

... вы назовите это.

Пара перлов из общения на металинке.

- (Oracle Support) В том логе, который вы предоставили, нет этой ошибки. В конце лога совсем другая ошибка, пожалуйста, предоставьте лог с ошибкой, о которой вы говорите.
- (Я) Посмотрите на линию номер 88 - ошибка как раз там.
- (Oracle Support) Прошу прощения, ошибка действительно там.

Мораль - не все ошибки всегда находятся только в конце файлов :)

- (Oracle Support) Вы уверены, что не создали дисковую группу там же, где у вас были бэкапы?
- (Я) Это разные дисковые массивы (по-видимому, из названия дисковых групп ASM - EVA01 и MSA1000 - это совсем не очевидно).

Удалил все бэкапы и стал пытаться восстановиться туда, где они раньше были?.. Huh?

Битва за терабайт

В наши дни администраторы СУБД Oracle при возникновении нештатных ситуаций начинают битву с ... индусами на металинке.

Мы получили то, что мы получили - терабайт данных повис в воздухе из-за сбойного блока в backup piece RMAN'а. Да - существуют процедуры проверки бэкапа. К сожалению, когда ваш бэкап закончился в 6 утра, а в 11 вы должны ехать в аэропорт - нет сильно большого выбора, кроме как немедленно приступить к восстановлению.

Вы когда-нибудь видели ORA-19599? Надеюсь, что нет. Впрочем, кое в чём нам повезло - system и undo оказались не в сбойном backup piece, поэтому нам удалось поднять базу сделав offline drop datafile'ам в "подпорченном" табличном пространстве.

Вам нужны archive log с самого создания датафайла, чтобы сделать media recovery в случае, если часть блоков датафайла оказывается полностью потерянной - безусловно, их ни у кого не было, поэтому встал вопрос - как перевести табличное пространство в online, не делая media recover одному датафайлу? Как "объехать" сбойный блок в самом backup piece?

Вопрос как раз для Oracle Metalink, поэтому вскоре был создан SR, описывающий проблему.

Для тех из вас, кто не знает - существует event 19549, который инструктирует RMAN "пропускать" сбойные блоки в backup piece, полностью очищая их содержимое.

Похоже на решение? Не тут-то было. Backup был сделан в сжатом формате (да - было ещё и это....) - похоже, этот event не действует в этом случае. К сожалению, к тому времени как мы это выяснили, у нашего индусского коллеги по несчастью закончился рабочий день и новую парочку недокументированных event'ов мы, похоже, увидим в понедельник.

А это значит, что продолжение следует...

Парадокс?

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