Oracle для профессионалов. Глава 1. Часть 1

Разработка успешных приложений для Oracle

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

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

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

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

Этот список тем для начального изучения может показаться слишком длинным, но давайте рассмотрим следующую аналогию: если бы вы разрабатывали масштабируемое, высокопроизводительное приложение для абсолютно новой операционной системы (ОС), с чего бы вы начали? Надеюсь, ваш ответ: "С изучения особенностей функционирования этой новой ОС, работы приложений в ней и т.п.". Если ответ принципиально другой, ваша разработка обречена на неудачу.

Рассмотрим, например, одну из ранних версий Windows (скажем, Windows 3.x). Она, как и ОС UNIX, была "многозадачной" операционной системой. Однако эта многозадачность была не такой, как в ОС UNIX, - использовалась модель невытесняющей многозадачности (т.е., если работающее приложение не возвращает управление, ничто другое работать не может, включая операционную систему). Фактически, по сравнению с UNIX, Windows 3.x вообще не была многозадачной ОС. Для создания эффективных приложений разработчики должны были точно знать, как реализована возможность "многозадачности" Windows. Если необходимо разрабатывать приложение, работающее непосредственно в среде определенной ОС, понимание особенностей этой ОС очень важно.

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

Мой подход

Прежде чем начать, хотелось бы объяснить вам мой подход к разработке. Я предпочитаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в СУБД, я так и сделаю. Для этого есть две причины. Первая и главная состоит в том, что если встроить функциональность в СУБД, то ее можно будет применять где угодно. Я не знаю серверной операционной системы, для которой нет реализации СУБД Oracle. Одна и та же СУБД Oracle со всеми опциями работает везде - от Windows до десятков версий ОС UNIX и больших ЭВМ типа OS/390. Я часто разрабатываю и тестирую программы на моем портативном компьютере, где работает СУБД Oracle8i для Windows NT. А применяются эти программы на различных серверах с ОС UNIX, на которых работает та же версия СУБД. Если приходится реализовать функциональность за пределами СУБД, ее очень сложно переносить на любую другую платформу. Одна из основных особенностей, делающих язык Java привлекательным для многих разработчиков, состоит в том, что программы всегда компилируются в одной и той же виртуальной среде, виртуальной машине Java Virtual Machine (JVM), и поэтому максимально переносимы. Именно эта особенность привлекает меня в СУБД. СУБД Oracle - это моя виртуальная машина, моя "виртуальная операционная система".

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

Таким образом, зная лишь особенности работы одной "виртуальной ОС", можно создавать приложения, демонстрирующие отличную производительность и масштабируемость во многих операционных системах. Я не утверждаю, что можно полностью игнорировать базовую ОС, - просто разработчик приложений баз данных достаточно хорошо от нее изолирован, и ему не придется учитывать многие ее нюансы. Ваш АБД, отвечающий за поддержку СУБД Oracle, должен знать намного больше об особенностях базовой ОС (если не знает - найдите нового АБД!). При разработке клиент-серверного программного обеспечения, если основная часть кода вынесена из СУБД и виртуальной машины (наиболее популярной виртуальной машиной, вероятно, является Java Virtual Machine), разработчику придется учитывать особенности ОС сервера.

При разработке приложений баз данных я использую очень простую мантру:

• если можно, сделай это с помощью одного оператора SQL;
• если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
• если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
• если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке C;
• если это нельзя реализовать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...

В книге вы увидите применение этого подхода. Мы будем использовать язык PL/SQL и его объектные типы для реализации того, что нельзя сделать в SQL. Язык PL/SQL существует давно, за ним стоит более тринадцати лет настройки, и нет другого языка, настолько тесно интегрированного с языком SQL и настолько оптимизированного для взаимодействия с SQL. Когда возможностей PL/SQL оказывается недостаточно, например, при доступе к сети, отправке сообщений электронной почты и т.п., мы будем использовать язык Java. Иногда мы будем решать определенные задачи с помощью языка C, но обычно лишь в тех случаях, когда программирование на C - единственно возможный вариант или когда обеспечиваемая компилятором C скорость работы программы действительно необходима. Во многих случаях сейчас последняя причина отпадает при использовании компиляции в машинные коды программ на языке Java (возможности преобразовать байт-код Java в специфический объектный код операционной системы для данной платформы). Это обеспечивает программам на Java такую же скорость работы, как и у программ на языке C.

Подход с использованием принципа черного ящика

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

Наиболее типичной причиной неудачи является нехватка практических знаний по используемой СУБД - элементарное непонимание основ работы используемого инструментального средства. Подход по принципу "черного ящика" требует осознанного решения: оградить разработчиков от СУБД. Их заставляют не вникать ни в какие особенности ее функционирования. Причины использования этого подхода связаны с опасениями, незнанием и неуверенностью. Разработчики слышали, что СУБД - это "сложно", язык SQL, транзакции и целостность данных - не менее "сложно". Решение: не заставлять никого делать что-либо "сложное". Будем относиться к СУБД, как к черному ящику, и найдем инструментальное средство, которое сгенерирует необходимый код. Изолируем себя несколькими промежуточными уровнями, чтобы не пришлось сталкиваться непосредственно с этой "сложной" СУБД.

Такой подход к разработке приложений баз данных я не мог понять никогда. Одна из причин, почему мне трудно это понять, состоит в том, что для меня изучение языков Java и C оказалось намного сложнее, чем изучение основ работы СУБД. Я сейчас очень хорошо знаю языки Java и C, но для их освоения мне понадобилось намного больше практического опыта, чем для достижения соответствующего уровня компетентности при использовании СУБД. В случае СУБД необходимо знать, как она работает, но детали знать необязательно. При программировании на языке C или Java, необходимо, например, знать все особенности используемых компонентов; кроме того, это очень большие по объему языки.

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

Вот типичный сценарий такого рода разработки.

• Разработчики были полностью обучены графической среде разработки или соответствующему языку программирования (например, Java), использованных для создания клиентской части приложения. Во многих случаях они обучались несколько недель, если не месяцев.
• Команда разработчиков ни одного часа не изучала СУБД Oracle и не имела никакого опыта работы с ней. Многие разработчики вообще впервые сталкивались с СУБД.
• В результате разработчики столкнулись с огромными проблемами, связанными с производительностью, обеспечением целостности данных, зависанием приложений и т.д. (но пользовательский интерфейс выглядел отлично).

Не сумев обеспечить нужную производительность, разработчики обращались за помощью ко мне. Особенно показателен один случай. Я не мог вспомнить точный синтаксис новой команды, которую надо было использовать, и попросил руководство SQL Reference. Мне принесли экземпляр из документации по СУБД Oracle версии 6.0, хотя разработка велась на версии 7.3, через пять лет после выхода версии 6.0! Ничего другого для работы у них не было, но это вообще никого не беспокоило. Хотя необходимое им для трассировки и настройки инструментальное средство в то время вообще не существовало. Хотя за пять лет, прошедших после написания имевшейся у них документации, были добавлены такие средства, как триггеры, хранимые процедуры, и многие сотни других. Несложно понять, почему им потребовалась помощь, гораздо труднее было решить их проблемы.

Странная идея о том, что разработчик приложения баз данных должен быть огражден от СУБД, чрезвычайно живуча. Многие почему-то считают, что разработчикам не следует тратить время на изучение СУБД. Неоднократно приходилось слышать: "СУБД Oracle - самая масштабируемая в мире, моим сотрудникам не нужно ее изучать, потому что СУБД со всеми проблемами справится сама". Действительно, СУБД Oracle - самая масштабируемая. Однако написать плохой код, который масштабироваться не будет, в Oracle намного проще, чем написать хороший, масштабируемый код. Можно заменить СУБД Oracle любой другой СУБД - это утверждение останется верным. Это факт: проще писать приложения с низкой производительностью, чем высокопроизводительные приложения. Иногда очень легко создать однопользовательскую систему на базе самой масштабируемой СУБД в мире, если не знать, что делаешь. СУБД - это инструмент, а неправильное применение любого инструмента может привести к катастрофе. Вы будете щипцами колоть орехи так же, как молотком? Можно, конечно, и так, но это неправильное использование инструмента, и результат вас не порадует. Аналогичные результаты будут и при игнорировании особенностей используемой СУБД.

Я недавно работал над проектом, в котором проектировщики придумали очень элегантную архитектуру. Клиент с помощью Web-браузера взаимодействовал по протоколу HTTP с сервером приложений, обеспечивающим поддержку Java Server Pages (JSP). Алгоритмы работы приложения целиком генерировались инструментальными средствами и реализовывались в виде компонентов EJB (с использованием постоянного хранения на базе контейнеров), причем физически они выполнялись другим сервером приложений. В базе данных хранились только таблицы и индексы.

Итак, мы начали с технически сложной архитектуры. Для решения задачи должны взаимодействовать друг с другом четыре компонента. Web-браузер получает страницы JSP от сервера приложений, который обращается к компонентам EJB, а те, в свою очередь, - к СУБД. Для разработки, тестирования, настройки и внедрения этого приложения необходимы были технически компетентные специалисты. После завершения разработки меня попросили оценить производительность приложения. Прежде всего я хотел узнать подход разработчиков к СУБД:

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

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

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

Все это стало понятно уже через час тестирования. Как оказалось, в приложении сначала выполнялся оператор:

select * from t for update;

Это приводило к строго последовательной работе всех клиентов. В базе данных была реализована такая модель, что перед выполнением любых существенных действий приходилось блокировать весьма большой ресурс. Это моментально превращало приложение в очень большую однопользовательскую систему. Разработчики не верили мне (в другой СУБД, использующей разделяемую блокировку чтения, наблюдалась другая ситуация). После десяти минут работы с инструментальным средством TKPROF (о нем подробно написано в главе 10) я смог продемонстрировать, что именно этот оператор SQL выполнялся приложением (они об этом не знали - просто никогда не видели генерируемых операторов SQL). Я не просто показал, какие операторы SQL выполняются приложением, но и с помощью пары сеансов SQL*Plus продемонстрировал, что второй сеанс не начинается до полного завершения работы первым сеансом.

Итак, вместо того, чтобы неделю тестировать производительность приложения, я употребил это время на обучение разработчиков настройке, особенностям блокирования в базах данных, механизмам управления одновременным доступом, сравнение их реализаций в СУБД Oracle, Informix, SQL Server, DB2 и так далее (во всех этих СУБД они различны). Но сначала мне пришлось понять, однако, почему использовался оператор SELECT FOR UPDATE. Оказалось, что разработчики хотели добиться повторяемости при чтении.

Повторяемость при чтении - это такой режим работы СУБД, когда повторное чтение в транзакции строки, которая уже один раз прочитана в этой транзакции, дает тот же результат.

Зачем им это было нужно? Они слышали, что "это хорошо". Ладно, предположим, повторяемость при чтении действительно необходима. В СУБД Oracle это делается путем установки уровня изолированности транзакции SERIALIZABLE (что дает не только повторяемость при чтении строки, но и повторяемость при выполнении любого запроса - если два раза выполнить один и тот же запрос в пределах транзакции с таким уровнем изолированности, будут получены одинаковые результаты). Для обеспечения повторяемости при чтении в Oracle не нужно использовать SELECT FOR UPDATE - это делается только для обеспечения последовательного доступа к данным. К сожалению, использованное разработчиками инструментальное средство это не учитывало - оно было создано для использования с другой СУБД, где именно так повторяемость при чтении и достигалась.

Итак, в данном случае для установки уровня изолированности транзакций SERIALIZABLE пришлось создать триггер на регистрацию в базе данных, изменяющий параметры сеанса (уровень изолированности транзакций) для данного приложения. Затем мы отключили все установки повторяемости при чтении в использовавшемся инструментальном средстве и повторно запустили приложение. Теперь, без конструкции FOR UPDATE, в базе данных определенные действия стали выполняться одновременно.

Это была далеко не последняя проблема данного проекта. Нам пришлось разобраться:

• как настраивать операторы SQL, не изменяя их кода (это сложно - некоторые методы мы рассмотрим в главе 11);
• как измерять производительность;
• как находить узкие места;
• что и как индексировать, и так далее.

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

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

Подводя итоги: СУБД - это краеугольный камень приложения. Если она не работает как следует, все остальное не имеет значения. Если плохо работает черный ящик, что с ним делать? Его нельзя исправить, нельзя настроить (поскольку непонятно, как он устроен), и такую позицию вы выбрали сами. Но есть и другой подход, который я отстаиваю: разберитесь в используемой СУБД и принципах ее работы, поймите, что она может делать, и используйте весь ее потенциал.

Как надо (и как не надо) разрабатывать приложения баз данных

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

В следующих разделах я опишу ряд важнейших особенностей СУБД Oracle, не вдаваясь в подробности их реализации и использования. Например, я опишу только одно из последствий использования архитектуры многопотокового сервера (Multi-Threaded Server - MTS) - режима, в котором можно (а иногда и нужно) конфигурировать сервер Oracle для поддержки множества пользовательских сеансов. Я, однако, не буду детально описывать архитектуру MTS, особенности ее работы и т.п. Все это подробно описано в руководстве Oracle Server Concepts Manual (дополнительную информацию можно найти также в руководстве Net8 Administrators Guide).

Понимание архитектуры СУБД Oracle

Недавно я участвовал в проекте, создатели которого решили использовать только новейшие, самые совершенные технологии: все программное обеспечение было написано на Java в виде компонентов EJB. Клиентское приложение взаимодействовало с СУБД через эти компоненты - никакого протокола Net8. Между клиентом и сервером не предавались операторы SQL - только обращения к компонентам EJB с помощью вызовов удаленных методов (Remote Method Invocation - RMI) по протоколу Internet Inter-Orb Protocol (IIOP).

Об организации RMI по протоколу IIOP можно узнать на сайте http://java.sun.com/products/rmi-iiop/.

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

Проблема, однако, была не в СУБД, а в незнании особенностей ее работы, и некоторые решения, принятые на этапе проектирования, привели к краху приложения в целом. Чтобы использовать компоненты EJB в базе данных, сервер Oracle должен быть сконфигурирован для работы в режиме многопотокового (MTS), а не выделенного сервера. Чего не понимала команда разработчиков в принципе, так это последствий использования режима MTS в сочетании с компонентами EJB для их приложения. При отсутствии этого понимания, как и знания основ работы СУБД Oracle вообще, были приняты два ключевых решения.

• В компонентах будут запускаться хранимые процедуры, работающие по 45 и более секунд (иногда - намного дольше).
• Связываемые переменные использоваться не будут. В условиях всех запросов будут использоваться литеральные константы. Все входные данные для процедур будут передаваться в виде строк. Это "проще", чем использовать связываемые переменные.

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

Избегайте длительных транзакций в среде MTS

Решение использовать транзакции продолжительностью более 45 секунд в среде MTS выдало недостаточное понимание назначения режима MTS и особенностей его работы в Oracle. Если коротко, в режиме MTS используется общий пул серверных процессов, обслуживающий намного больший пул конечных пользователей. Это похоже на пул подключений. Поскольку создание и управление процессом - наиболее дорогостоящие операции, выполняемые операционной системой, режим MTS дает большие преимущества для крупномасштабной системы. Можно обслуживать 100 пользователей всего пятью или десятью разделяемыми серверными процессами.

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

Если все операторы выполняются быстро, архитектура MTS работает отлично. Можно эффективно обслуживать небольшим количеством процессов большое сообщество пользователей. Если же имеются сеансы, монополизирующие разделяемый сервер надолго, то кажется, что СУБД "зависает". Пусть сконфигурировано десять разделяемых серверов для поддержки 100 пользователей. Если в некоторый момент времени десять пользователей одновременно введут оператор, выполняющийся более 45 секунд, то всем остальным транзакциям (и новым подключениям) придется ждать. Если некоторым из ожидающих в очереди сеансов необходимо выполнять оператор такой же продолжительности, возникает большая проблема - "зависание" будет продолжаться не 45 секунд, а намного дольше. Даже если желающих выполнить подобный оператор одновременно будет не десять, а лишь несколько, все равно будет наблюдаться существенное падение производительности сервера. Мы отберем на длительное время совместно используемый ресурс, и это плохо. Вместо десяти серверных процессов, выполняющих быстрые запросы в очереди, остается пять или шесть (или еще меньше). Со временем система станет работать с производительностью, заметно меньше предполагаемой, исключительно из-за нехватки этого ресурса.

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

Реальное решение этой проблемы оказалось простым: не выполнять продолжительные транзакции на сервере, работающем в режиме MTS. А вот реализация этого решения оказалась сложнее. Это можно было сделать несколькими способами, но все они требовали существенных изменений архитектуры. Самым подходящим способом, требующим минимальных изменений, оказалось использование средств расширенной поддержки очередей (Advanced Queues - AQ).

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

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

Хотя, судя по описанию, этот подход прост (подключение механизма AQ полностью решает проблему), потребовалось сделать намного больше. Этот 45-секундный процесс генерировал идентификатор транзакции, необходимый на следующем шаге в интерфейсе для соединения таблиц - по проекту интерфейс без этого не работал. Используя механизм AQ, мы не ждем генерации идентификатора транзакции, - мы обращаемся к системе с просьбой сделать это когда-нибудь. Поэтому приложение опять оказалось в тупике. С одной стороны, мы не можем ждать завершения процесса 45 секунд, но, с другой стороны, для перехода к следующему экрану необходим сгенерированный идентификатор, а получить его можно только спустя 45 секунд. Для того чтобы решить эту проблему, пришлось синтезировать собственный поддельный идентификатор транзакции, изменить продолжительный процесс так, чтобы он принимал этот сгенерированный поддельный идентификатор и обновлял таблицу, записывая его по завершении работы, благодаря чему реальный идентификатор транзакции связывался с поддельным. То есть, вместо получения реального идентификатора в результате длительного процесса, этот идентификатор становится для процесса входными данными. Во всех "подчиненных" таблицах использовался этот поддельный идентификатор транзакции, а не реальный (поскольку генерации реального надо ждать определенное время). Нам также пришлось пересмотреть использование этого идентификатора транзакции, чтобы понять, как это изменение повлияет на другие модули, и так далее.

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

В результате пришлось существенно пересмотреть структуру базы данных. Пришлось добавить новое программное обеспечение (AQ). Пришлось также создать новые процессы (управление потоками заданий и другие служебные процессы). К положительным последствиям этих изменений можно отнести не только решение проблемы с архитектурой MTS, но и удобство для пользователя (создавалась видимость более быстрой реакции системы). С другой стороны, все эти изменения существенно задержали завершение проекта, поскольку проблемы были выявлены лишь непосредственно перед внедрением, на этапе тестирования масштабируемости. Очень жаль, что приложение сразу не был правильно спроектировано. Если бы разработчики знали, как физически реализован механизм MTS, было бы ясно, что исходный проект не обеспечивает требуемой масштабируемости.

Используйте связываемые переменные

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

Связываемая переменная - это подставляемый параметр запроса. Например, для получения записи доя сотрудника с номером 123, можно выполнить запрос:

select * from emp where empno = 123;

Но можно задать и другой запрос:

select * from emp where empno = :empno;

В обычной системе информацию о сотруднике с номером 123 могут запрашивать всего один раз. В дальнейшем будут запрашивать информацию о сотрудниках с номерами 456, 789 и т.д. При использовании в запросе литералов (констант) каждый запрос является для СУБД абсолютно новым, никогда ранее не выполнявшимся. Его надо разбирать, уточнять (определять объекты, соответствующие именам), проверять права доступа, оптимизировать и т.д. - короче, каждый выполняемый уникальный оператор придется компилировать при каждом выполнении.

Во втором запросе используется связываемая переменная, :empno, значение которой подставляется в запрос при выполнении. Этот запрос компилируется один раз, а затем план его выполнения запоминается в разделяемом пуле (в библиотечном кеше), из которого его можно выбрать для повторного выполнения. Различие между этими двумя вариантами в плане производительности и масштабируемости - огромное, даже принципиальное.

Из представленного выше описания вполне понятно, что разбор оператора с явными, жестко заданными константами (так называемый полный разбор) выполняется дольше и требует намного больше ресурсов, чем повторное использование уже сгенерированного плана запроса (его называют частичным разбором). Менее очевидным может оказаться, насколько постоянный полный разбор сокращает количество пользователей, поддерживаемых системой. Отчасти это связано с повышенным потреблением ресурсов, но в гораздо большей степени - с механизм защелок, используемых в библиотечном кеше. При полном разборе запроса СУБД будет дольше удерживать определенные низкоуровневые средства обеспечения последовательного доступа, которые называются защелками (подробнее о них см. в главе 3). Защелки защищают структуры данных в разделяемой памяти сервера Oracle от одновременного изменения двумя сеансами (иначе эти структуры данных Oracle в конечном итоге были бы повреждены) и от чтения этой структуры данных по ходу изменения другим сеансом. Чем чаще и на более продолжительное время на эти структуры данных устанавливаются защелки, тем длиннее становится очередь для установки этих защелок. Точно так же происходит при использовании длинных транзакций в среде MTS, - монополизируются критические ресурсы. Временами машина может казаться минимально загруженной, а СУБД работает очень медленно. Вполне вероятно, что один из сеансов удерживает защелку и формируется очередь в ожидании ее освобождения. В результате работа с максимальной скоростью невозможна. Достаточно одного неверно работающего приложения для существенного снижения производительности всех остальных приложений. Одно небольшое приложение, не использующее связываемые переменные, приводит со временем к удалению из разделяемого пула необходимых SQL-операторов других хорошо настроенных приложений. Достаточно ложки дегтя, чтобы испортить бочку меда.

При использовании связываемых переменных любой сеанс, выдающий тот же самый запрос, будет использовать уже скомпилированный план выполнения из библиотечного пула. Подпрограмма компилируется один раз, а используется многократно. Это очень эффективно, и именно такую работу пользователей предполагает СУБД. При этом не только используется меньше ресурсов (частичный разбор требует намного меньше ресурсов), но и защелки удерживаются значительно меньше времени, и нужны гораздо реже. Это повышает производительность и масштабируемость.

Чтобы хоть примерно понять, насколько существенно это может сказаться на производительности, достаточно выполнить очень простой тест:

tkyte@TKYTE816> alter system flush shared_pool;

System altered.

Здесь я начинаю с "пустого" разделяемого пула. Если потребуется выполнять этот тест многократно, придется очищать разделяемый пул каждый раз, иначе представленный ниже оператор SQL, в котором не используются связываемые переменные, окажется в кеше и будет выполняться очень быстро.

tkyte@TKYTE816> set timing on
tkyte@TKYTE816> declare
 2 type rc is ref cursor;
 3 l_rc rc;
 4 l_dummy all_objects.object_name%type;
 5 l_start number default dbms_utility.get_time;
 6 begin
 7 for i in 1 .. 1000
 8 loop
 9 open l_rc for
 10 'select object_name
 11 from all_objects
 12 where object_id = ' // i;
 13 fetch l_rc into l_dummy;
 14 close l_rc;
 15 end loop;
 16 dbms_output.put_line
 17 ( round( (dbms_utility.get_time-l_start)/100, 2 ) //
 18 ' seconds...' );
 19 end;
 20 /
14.86 seconds... 

PL/SQL procedure successfully completed.

В этом коде используется динамический SQL для запроса одной строки из представления ALL_OBJECTS. Он генерирует 1000 уникальных запросов со значениями 1, 2, 3, ... и так далее, жестко заданными в конструкции WHERE. На моем ноутбуке с процессором Pentium 300 Мгц для его выполнения потребовалось около 15 секунд (скорость выполнения на разных машинах может быть различной).

Теперь сделаем то же самое с использованием связываемых переменных:

tkyte@TKYTE816> declare
 2 type rc is ref cursor;
 3 l_rc rc;
 4 l_dummy all_objects.object_name%type;
 5 l_start number default dbms_utility.get_time;
 6 begin
 7 for i in 1 .. 1000
 8 loop
 9 open l_rc for
 10 'select object_name
 11 from all_objects
 12 where object_id = :x'
 13 using i;
 14 fetch l_rc into l_dummy;
 15 close l_rc;
 16 end loop;
 17 dbms_output.put_line
 18 (round( (dbms_utility.get_time-l_start)/100, 2 ) //
 19 ' seconds...');
 20 end;
 21 /
1.27 seconds...

PL/SQL procedure successfully completed.

В этом коде использован точно такой же алгоритм. Единственное изменение - вместо жестко заданных значений 1, 2, 3... и так далее в запросе используется связываемая переменная. Результаты весьма впечатляющи. Код не только выполняется намного быстрее (разбор запросов требовал больше времени, чем их реальное выполнение!), но и позволяет большему количеству пользователей одновременно работать с системой.

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

В главе 10 мы рассмотрим способы определить, используются ли связываемые переменные, различные варианты их применения, поддерживаемую СУБД возможность автоматической подстановки связываемых переменных и т.д. Мы также рассмотрим особый случай, когда использование связываемых переменных нежелательно.

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

Особенности управления одновременным доступом

Управление одновременным доступом - это то, чем отличаются различные СУБД. Именно это отличает СУБД от файловой системы и одну СУБД от другой. Для программиста важно, чтобы его приложение базы данных корректно работало в условиях одновременного доступа, и именно это постоянно забывают проверять. Приемы, прекрасно работающие в условиях последовательного доступа, работают гораздо хуже при одновременном их применении несколькими сеансами. Если не знать досконально, как в конкретной СУБД реализованы механизмы управления одновременным доступом, то:

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

Обратите внимание: я не пишу "возможно, будет..." или "вы рискуете..." - все эти проблемы точно будут. Все это вы получите, даже не представляя, что именно происходит. При неправильном управлении одновременным доступом будет нарушена целостность данных, поскольку то, что работает отдельно, будет работать не так, как предполагалось, в многопользовательской среде. Приложение будет работать медленнее, поскольку придется ждать доступа к данным. Возможность масштабирования будет потеряна из-за проблем с блокированием и конфликтов блокировок. По мере усложнения запросов к ресурсу ждать придется все дольше и дольше. Можно провести аналогию с таможенным переходом на границе. Если машины приезжают по одной, равномерно, с предсказуемой частотой, никаких очередей нет. Если же одновременно приедет много машин, начинают формироваться очереди. Причем время ожидания растет нелинейно по отношению к длине очереди. С определенного момента больше времени сотрудников уходит на "наведение порядка" в очереди, чем на таможенный досмотр машин (в случае СУБД мы говорим о планировании процессов и переключении контекста).

Проблемы одновременного доступа выявлять сложнее всего - трудности сопоставимы с отладкой многопотоковой программы. Программа может отлично работать в управляемой, искусственной среде отладчика, но постоянно "слетать" в "реальном мире". Например, в условиях интенсивных обращений может оказаться, что два потока одновременно изменяют одну и ту же структуру данных. Такого рода ошибки очень сложно выявлять и исправлять. Если приложение тестировалось только в однопользовательском режиме, а затем внедряется в среде с десятками одновременно обращающихся пользователей, вполне вероятно проявление болезненных проблем с одновременным доступом.

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

Реализация блокирования

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

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

Ниже приведены принципы блокирования в СУБД Oracle.

• Oracle блокирует данные на уровне строк и только при изменении. Эскалация блокировок до уровня блока или таблицы никогда не выполняется.
• Oracle никогда не блокирует данные с целью считывания. При обычном чтении блокировки на строки не устанавливаются.
• Сеанс, записывающий данные, не блокирует сеансы, читающие данные. Повторю: операции чтения не блокируются операциями записи. Это принципиально отличается от практически всех остальных СУБД, в которых операции чтения блокируются операциями записи.
• Сеанс записи данных блокируется, только если другой сеанс записи уже заблокировал строку, которую предполагается изменять. Сеанс считывания данных никогда не блокирует сеанс записи.

Эти факты необходимо учитывать при разработке приложений, однако следует помнить, что эти принципы используются только в Oracle. Разработчик, не понимающий, как используемая СУБД обеспечивает одновременный доступ, неизбежно столкнется с проблемами целостности данных (особенно часто это происходит, когда разработчик переходит с другой СУБД на Oracle, или наоборот, и не учитывает в приложении различия механизмов обеспечения одновременного доступа).

Один из побочных эффектов принятого в СУБД Oracle "неблокирующего" подхода состоит в том, что если действительно необходимо обеспечить доступ к строке не более чем одного пользователя в каждый момент времени, то именно разработчику необходимо предпринять для этого определенные усилия. Рассмотрим следующий пример. Один разработчик показывал мне только что завершенную им программу планирования ресурсов (учебных классов, проекторов и т.д.), находящуюся в стадии внедрения. Это приложение реализовало бизнес-правило, предотвращающее выделение ресурса более чем одному лицу на любой период времени. То есть, приложение содержало специальный код, который проверял, что никто из пользователей не затребовал ресурс на тот же период времени (по крайней мере разработчик думал, что его код это проверяет). Код обращался к таблице планов и, если в ней не было строк с перекрывающимся временным интервалом, вставлял в нее новую строку. Итак, разработчик просто работал с парой таблиц:

create table resources 
 ( resource_name varchar2(25) primary key, ... );
create table schedules 
 ( resource_name varchar2(25) references resources,
 start_time date,
 end_time date );

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

select count(*) 
 from schedules 
 where resource_name = :room_name
 and (start_time between :new_start_time and :new_end_time
 or 
 end_time between :new_start_time and :new_end_time)

Он казался разработчику простым и надежным: если возвращено значение 0, учебный класс можно занимать; если возвращено ненулевое значение, значит, учебный класс на этот период уже кем-то занят. Ознакомившись с используемым алгоритмом, я подготовил простой тест, показывающий, какая ошибка будет возникать при реальной эксплуатации приложения. Эту ошибку будет крайне сложно обнаружить и тем более установить ее причину, - кому-то может даже показаться, что это ошибка СУБД.

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

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

select * from resources where resource_name = :room_name FOR UPDATE;

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

Этот подход обеспечивает высокую степень параллелизма, поскольку резервируемых ресурсов могут быть тысячи, а мы всего лишь гарантируем, что сеансы изменяют конкретный ресурс поочередно. Это один из немногих случаев, когда необходимо блокирование вручную данных, которые не должны изменяться. Требуется уметь распознавать ситуации, когда это необходимо, и, что не менее важно, когда этого делать не нужно (пример, когда не нужно, приведен далее). Кроме того, такой прием не блокирует чтение ресурса другими сеансами, как это могло бы произойти в других СУБД, благодаря чему обеспечивается высокая масштабируемость.

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

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

Многоверсионность

Эта тема очень тесно связана с управлением одновременным доступом, поскольку создает основу для механизмов управления одновременным доступом в СУБД Oracle - Oracle использует модель многовариантной согласованности по чтению при одновременном доступе. В главе 3 мы более детально рассмотрим технические аспекты многоверсионности, но по сути это механизм, с помощью которого СУБД Oracle обеспечивает:

• согласованность по чтению для запросов: запросы выдают согласованные результаты на момент начала их выполнения;
• неблокируемые запросы: запросы не блокируются сеансами, в которых изменяются данные, как это бывает в других СУБД.

Это две очень важные концепции СУБД Oracle. Термин многоверсионность произошел от того, что фактически СУБД Oracle может одновременно поддерживать множество версий данных в базе данных. Понимая сущность многоверсионности, всегда можно понять результаты, получаемые из базы данных. Наиболее простой из известных мне способов продемонстрировать многоверсионность в Oracle:

tkyte@TKYTE816> create table t
 2 as
 3 select * from all_users;

Table created.

tkyte@TKYTE816> variable x refcursor

tkyte@TKYTE816> begin
 2 open :x for select * from t;
 3 end;
 4 /

PL/SQL procedure successfully completed.

tkyte@TKYTE816> delete from t;

18 rows deleted.

tkyte@TKYTE816> commit;

Commit complete.

tkyte@TKYTE816> print x

USERNAME USER_ID CREATED
------------------------------ ---------- ---------
SYS 0 04-NOV-00
SYSTEM 5 04-NOV-00
DBSNMP 16 04-NOV-00
AURORA$ORB$UNAUTHENTICATED 24 04-NOV-00
ORDSYS 25 04-NOV-00
ORDPLUGINS 26 04-NOV-00
MDSYS 27 04-NOV-00
CTXSYS 30 04-NOV-00
...
DEMO 57 07-FEB-01

18 rows selected.

В этом примере мы создали тестовую таблицу T и заполнили ее данными из представления ALL_USERS. Мы открыли курсор для этой таблицы. Мы не выбирали данные с помощью этого курсора, просто открыли его.

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

В том же (или в другом) сеансе мы затем удаляем все данные из таблицы. Более того, мы даже фиксируем (COMMIT) это удаление. Строк больше нет - не так ли? На самом деле их можно извлечь с помощью курсора. Фактически, результирующее множество, возвращаемое командой OPEN, было предопределено в момент открытия курсора. Мы не прочитали при открытии курсора ни одного блока данных таблицы, но результат оказался жестко зафиксированным. Мы не сможем узнать этот результат, пока не извлечем данные, но с точки зрения нашего курсора результат этот неизменен. Дело не в том, что СУБД Oracle скопировала все эти данные в другое место при открытии курсора; данные сохранил оператор delete, поместив их в область данных под названием сегмент отката.

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

Давайте рассмотрим последствия использования многоверсионной согласованности запросов по чтению и неблокируемых чтений. Для тех, кто не знаком с многоверсионностью, представленные ниже результаты могут показаться удивительными. Для простоты предположим, что в каждом блоке данных (это минимальная единица хранения в СУБД) считываемой таблицы хранится всего одна строка и что выполняется полный просмотр таблицы.

В запрашиваемой таблице хранятся балансы банковских счетов. Она имеет очень простую структуру:

create table accounts 
( account_number number primary key, 
 account_balance number 
);

В реальной таблице счетов будут сотни тысяч строк, но для простоты мы будем рассматривать таблицу всего с четырьмя строками (более детально мы рассмотрим этот пример в главе 3):

Требуется создать отчет, который в конце банковского дня позволяет определить количество денег в банке. Это делается с помощью предельно простого запроса:

select sum(account_balance) from accounts;

Конечно, в данном примере ответ очевиден - 1250 $. Однако что произойдет, если мы прочитаем строку 1, а при считывании строк 2 и 3 с одного из банкоматов будет выполнена транзакция, переводящая 400 $ со счета 123 на счет 456? Наш запрос прочтет 500 $ в строке 4 и выдаст результат 1650 $, не так ли? Конечно, этого надо избежать, так как подобный результат ошибочен - никогда такого баланса по счетам в базе данных не было. Нужно понять, как СУБД Oracle избегает подобных ситуаций и чем отличаются используемые при этом методы от используемых во всех остальных СУБД.

Практически в любой другой СУБД для получения "согласованного" и "корректного" ответа на этот запрос необходимо блокировать либо всю таблицу, по которой идет суммирование, либо строки по мере их чтения. Это предотвратит изменение результата другими сеансами в ходе его получения. Если заблокировать всю таблицу, будет получен результат, соответствующий состоянию базы данных в момент начала выполнения запроса. Если блокировать данные по мере чтения (такая разделяемая блокировка чтения предотвращает изменения, но не чтение данных другими сеансами), будет получен результат, соответствующий состоянию базы данных в момент завершения выполнения запроса. Оба эти метода существенно снижают возможности одновременного доступа. Блокировка таблицы предотвращает любые изменения таблицы во время выполнения запроса (для таблицы из четырех строк этот период очень короток, но для таблиц с сотнями тысяч строк запрос может выполняться несколько минут). Метод "блокирования по ходу чтения" предотвращает изменение уже прочитанных и обработанных данных и потенциально может приводить к взаимным блокировкам выполнения вашего запроса и других изменений.

Как уже было сказано, вы не сможете в полном объеме использовать преимущества СУБД Oracle, если не понимаете концепцию многоверсионности. В СУБД Oracle многоверсионность используется для получения результатов, соответствующих моменту начала выполнения запроса, при этом не блокируется ни единой строки (пока транзакция по переводу денег изменяет строки 1 и 4, они будут заблокированы от других изменений, но не от чтения, выполняемого, например, нашим запросом SELECT SUM...). Фактически в СУБД Oracle нет "разделяемых блокировок чтения", типичных для других СУБД, - они в ней просто не нужны. Все устранимые препятствия для одновременного доступа были устранены.

Итак, как же СУБД Oracle получает корректный, согласованный результат (1250 $) при чтении, не блокируя данных, другими словами, не мешая одновременному доступу? Секрет - в механизме выполнения транзакций, используемом в СУБД Oracle. При любом изменении данных Oracle создает записи в двух разных местах. Одна запись попадает в журнал повторного выполнения, где Oracle хранит информацию, достаточную для повторного выполнения, или "наката", транзакции. Для оператора вставки это будет вставляемая строка. Для оператора удаления это будет запрос на удаление строки в слоте X блока Y файла Z. И так далее. Другая запись - это запись отмены, помещаемая в сегмент отката. Если транзакция завершается неудачно и должна быть отменена, СУБД Oracle будет читать "предварительный" образ из сегмента отката, восстанавливая необходимые данные. Помимо отмены транзакций, СУБД Oracle использует сегменты отката для отмены изменений в блоках при их чтении, то есть для восстановления данных блока на момент начала выполнения запроса. Это позволяет читать данные несмотря на блокировку и получать корректные, согласованные результаты, не блокируя данные.

Часть 2