|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 23.03.06 | |
Итак, в нашем примере Oracle получает результат следующим образом:
Время |
Запрос |
Транзакция по переводу со счета на счет |
| T1 | Читает строку 1, sum получает значение 500 $ | |
| T2 | Изменяет строку 1, устанавливает исключительную блокировку на строку 1, предотвращая другие изменения. В строке 1 теперь хранится значение 100 $ | |
| T3 | Читает строку 2, sum получает значение 750 $ | |
| T4 | Читает строку 3, sum получает значение 1150 $ | |
| T5 | Изменяет строку 4, устанавливает исключительную блокировку на строку 4, предотвращая другие изменения (но не чтение). В строке 4 теперь хранится значение 500 $. | |
| T6 | Читает строку 4, определяет, что она была изменена. Выполняется откат блока до того состояния, которое он имел в момент времени T1. Запрос затем прочитает значение 100 $ из этого блока | |
| T7 | Транзакция фиксируется | |
| T8 | Выдает 1250 $ в качестве результата суммирования |
В момент времени T6 СУБД Oracle фактически "читает поверх" блокировки, установленной транзакцией на строке 4. Именно так реализуется неблокируемое чтение: СУБД Oracle просто проверяет, изменились ли данные, игнорируя тот факт, что они в настоящий момент заблокированы (т.е. определенно изменены). Она извлечет старое значение из сегмента отката и перейдет к следующему блоку данных.
Это еще одна убедительная демонстрация многоверсионности: в базе данных имеется несколько версий одной и той же информации, по состоянию на различные моменты времени. СУБД Oracle использует эти сделанные в разное время "моментальные снимки" данных для поддержки согласованности по чтению и неблокируемости запросов.
Это согласованное по чтению представление данных всегда выполняется на уровне оператора SQL, — результаты выполнения любого оператора SQL всегда согласованы на момент его начала. Именно это свойство позволяет получать предсказуемый набор данных в результате, например, следующих вставок:
for x in (select * from t)
loop
insert into t values (x.username, x.user_id, x.created);
end loop;
Результат выполнения оператора SELECT * FROM T предопределен в момент начала выполнения запроса. Оператор SELECT не будет "видеть" новых данных, генерируемых операторами INSERT. Представьте себе, что было бы в противном случае: оператор превратился бы в бесконечный цикл. Если бы по мере генерации оператором INSERT дополнительных строк в таблице T, оператор SELECT мог "видеть" эти вставляемые строки, представленный выше фрагмент кода создал бы неизвестное количество строк. Если бы в таблице T первоначально было 10 строк, в результате могло бы получиться 20, 21, 23 или бесконечное количество строк. Точно предсказать результат было бы невозможно. Согласованность по чтению обеспечивается для всех операторов, так что операторы INSERT, вроде представленного ниже, тоже работают предсказуемо:
insert into t select * from t;
Оператор INSERT получит согласованное по чтению представление таблицы T — он не "увидит" строки, которые сам же только что вставил, и будет вставлять только строки, существовавшие на момент начала его выполнения. Во многих СУБД подобные рекурсивные операторы просто не разрешены, поскольку они не могут определить, сколько строк вообще будет вставлено.
Поэтому если вы привыкли к реализации согласованности и одновременности запросов в других СУБД или просто никогда не сталкивались с такими понятиями (не имеете реального опыта работы с СУБД), то теперь понимаете, насколько важно для вашей работы их понимание. Чтобы максимально использовать потенциальные возможности СУБД Oracle, необходимо понимать эти проблемы и способы их решения именно в Oracle, а не в других СУБД.
Вы, наверное, уже поняли направление моей мысли. Я ссылался на другие СУБД и описывал различия реализации одних и тех же возможностей в каждой из них. Я убежден: за исключением некоторых приложений, исключительно читающих из базы данных, создать полностью независимое от СУБД и при этом масштабируемое приложение крайне сложно и даже практически невозможно, не зная особенностей работы всех СУБД.
Например, давайте вернемся к первому примеру планировщика ресурсов (до добавления конструкции FOR UPDATE). Предположим, это приложение было разработано на СУБД с моделью блокирования/обеспечения одновременного доступа, полностью отличающейся от принятой в Oracle. Я собираюсь продемонстрировать, что при переводе приложения с одной СУБД на другую необходимо проверять, работает ли оно корректно в новой среде.
Предположим, что первоначально приложение по планированию ресурсов работало в СУБД, использующей блокирование на уровне страниц и блокировку чтения (чтение блокируется при изменении считываемых данных), и для таблицы SCHEDULES был создан индекс:
create index schedules_idx on schedules(resource_name, start_time);
Предположим также, что бизнес-правило было реализовано с помощью триггера (после выполнения оператора INSERT, но перед фиксацией транзакции мы проверяем, что для указанного временного интервала в базе данных имеется только наша, только что вставленная строка). В системе с блокированием на уровне страниц, из-за изменения страницы индекса по столбцам RESOURCE_NAME и START_TIME, очень вероятно, что транзакции будут выполняться строго последовательно. Система будет выполнять вставки поочередно, поскольку страница индекса блокируется (все близкие значения по полю START_TIME для одного ресурса RESOURCE_NAME будут находиться на той же странице). В такой СУБД с блокированием на уровне страниц наше приложение, вероятно, будет работать нормально, так как перекрытие выделяемых ресурсов будет проверяться последовательно, а не одновременно.
Если просто перенести это приложение в СУБД Oracle, исходя из предположения, что она работает точно так же, можно получить шок. В СУБД Oracle, выполняющей блокирование на уровне строк и не блокирующей чтения, оно окажется некорректным. Как уже было показано, необходимо использовать конструкцию FOR UPDATE для упорядочения доступа. Без этой конструкции два пользователя могут зарезервировать ресурс на одно и то же время. Это будет прямым следствием непонимания особенностей работы используемой СУБД в многопользовательской среде.
С подобными проблемами я сталкивался многократно при переносе приложений из СУБД А в СУБД Б. Когда приложение, без проблем работавшее в СУБД А, не работает или работает весьма странно в СУБД Б, сразу же возникает мысль, что "СУБД Б — плохая". Правда, однако, в том, что СУБД Б работает иначе. Ни одна из СУБД не ошибается и не является "плохой" — они просто разные. Знание и понимание особенностей их работы поможет успешно решить подобные проблемы.
Совсем недавно я помогал перевести код с языка Transact SQL (язык создания хранимых процедур для СУБД SQL Server) на PL/SQL. Разработчик, занимавшийся переводом, жаловался, что SQL-запросы в Oracle возвращают "неправильный" ответ. Запросы выглядели следующим образом:
declare
l_some_variable varchar2(25);
begin
if ( some_condition )
then
l_some_variable := f( ... );
end if;
for x in ( select * from T where x = l_some_variable )
loop
...
Целью является получение всех строк таблицы T, которые в столбце X имеют пустое значение, если некоторое условие не выполнено, или определенное значение, если это условие выполнено.
Суть жалобы состояла в том, что, в Oracle этот запрос не возвращал данных, если переменная L_SOME_VARIABLE не получала значения явно (когда у нее оставалось значение NULL). В СУБД Sybase или SQL Server все было не так — запрос находил строки с неопределенным (NULL) значением в столбце X. Я встречался с этим практически при любом переводе приложения с СУБД Sybase или SQL Server на Oracle. Язык SQL предполагает использование трехзначной логики, и СУБД Oracle реализует неопределенные значения так, как того требует стандарт ANSI SQL. По этим правилам сравнение столбца X со значением NULL не дает ни True, ни False — результат фактически неизвестен. Следующий пример показывает, что я имею в виду:
ops$tkyte@ORA8I.WORLD> select * from dual; D - X ops$tkyte@ORA8I.WORLD> select * from dual where null=null; no rows selected ops$tkyte@ORA8I.WORLD> select * from dual where null<>null; no rows selected
В первый раз это может показаться странным: в Oracle NULL не равен и не не равен NULL. СУБД SQL Server по умолчанию ведет себя не так: в SQL Server и Sybase NULL равен NULL. Ни Oracle, ни Sybase, ни SQL Server не выполняет операторы SQL неправильно — они просто делают это по-разному. Все эти СУБД якобы соответствуют стандарту ANSI, но все равно работают по-разному. Есть неоднозначности, проблемы совместимости с прежними версиями и так далее, которые необходимо решать. Например, СУБД SQL Server поддерживает метод сравнения со значением NULL, диктуемый стандартом ANSI, но не по умолчанию (это нарушило бы работу тысяч уже существующих приложений, созданных для этой СУБД).
Одним из решений проблемы могло быть переформулирование запроса следующим образом:
select *
from t
where ( x = l_some_variable OR
(x is null and l_some_variable is NULL ))
Однако это привело бы к еще одной проблеме. В СУБД SQL Server при выполнении этого запроса использовался бы индекс по столбцу X. В СУБД Oracle индекс на основе B*-дерева (подробнее о методах индексирования читайте в главе 7) не позволяет индексировать значения ключа NULL. Поэтому, если необходимо найти неопределенные значения, индексы на основе B*-деревьев не сильно помогут.
В рассматриваемом случае, чтобы свести к минимуму изменения в коде, столбцу X присваивалось значение, которого не могло быть в реальных данных. Так, X, по определению, был числом положительным, поэтому было выбрано значение -1. Запрос приобрел следующий вид:
select * from t where nvl(x,-1) = nvl(l_some_variable,-1)
Мы создали индекс по функции:
create index t_idx on t( nvl(x,-1) );
С минимальными изменениями мы добились того же результата. Отсюда можно сделать следующие важные выводы.
Разработчики часто спрашивают меня, как сделать в СУБД что-то конкретное. Например, меня спрашивают: "Как создать временную таблицу в хранимой процедуре?". На такие вопросы я не даю прямого ответа — я всегда отвечаю вопросом: "А для чего вам это нужно?". Неоднократно в ответ я слышал: "Мы создавали временные таблицы в хранимых процедурах в SQL Server, и теперь нам надо это сделать в Oracle". Именно это я и предполагал услышать. В таком случае мой ответ прост: "Вы ошибаетесь, думая, что надо создавать временные таблицы в хранимой процедуре в Oracle". На самом деле в СУБД Oracle это будет крайне неудачным решением. При создании таблиц в хранимых процедурах в Oracle вскоре обнаружится, что:
Итак, не надо делать в точности так, как в SQL Server (если временная таблица в Oracle вообще понадобится). Делать следует то, что является наиболее оптимальным для Oracle. При обратном переходе из Oracle в SQL Server тоже не стоит создавать одну большую таблицу с временными данными для всех пользователей (как это делается в Oracle). Это приведет к снижению масштабируемости и возможностей одновременного доступа в данной СУБД. Каждая СУБД имеет существенные отличия.
Если все СУБД соответствуют стандарту SQL92, они должны быть одинаковы. Так считают многие. Сейчас я развею этот миф.
SQL92 — это стандарт ANSI/ISO для СУБД. Он является развитием стандарта ANSI/ISO SQL89. Этот стандарт задает язык (SQL) и поведение (транзакции, уровни изоляции и т.д.) для СУБД. Знаете ли вы, что многие коммерческие СУБД соответствуют стандарту SQL92? А знаете ли, как немного это значит для переносимости запросов и приложений?
Начиная читать стандарт SQL92, обнаруживаешь, что он имеет четыре уровня.
В стандарт начального уровня не входят такие конструкции, как внешние соединения, новый синтаксис для внутренних соединений и т.д. Переходный уровень требует поддержки соответствующего синтаксиса внешнего и внутреннего соединения. Промежуточный уровень добавляет новые возможности, а полный и представляет собой, собственно, SQL92. В большинстве книг по SQL92 не различаются эти уровни поддержки, что сбивает с толку. В них демонстрируется, как должна работать "идеальная" СУБД, полностью реализующая стандарт SQL92. В результате нельзя взять книгу по SQL92 и применить представленные в ней приемы к СУБД, соответствующей стандарту SQL92. Например, в СУБД SQL Server предлагаемый стандартом синтаксис "внутреннего соединения" в SQL-операторах поддерживается, а в СУБД Oracle — нет. Но обе эти СУБД соответствуют стандарту SQL92. В СУБД Oracle можно выполнять внешние и внутренние соединения, но делать это надо не так, как в SQL Server. В результате начальный уровень стандарта SQL92 мало что дает, а при использовании средств более высоких уровней возможны проблемы при переносе на другую СУБД.
Не надо бояться использовать специфические средства конкретной СУБД, — за них заплачено немало денег. В каждой СУБД есть свой набор уникальных возможностей, и в любой СУБД можно найти способ выполнить необходимое действие. Используйте в текущей СУБД лучшее и реализуйте новые компоненты при переходе на другие СУБД. Используйте соответствующие приемы программирования, максимально изолирующие остальную часть приложения от этих изменений. Эти же приемы программирования применяются разработчиками переносимых приложений, поддерживающих несколько ОС. Цель в том, чтобы в полной мере использовать имеющиеся средства, но при этом иметь возможность менять реализацию в каждом конкретном случае.
Например, типичная функция многих приложений баз данных — генерация уникального ключа для каждой строки. При вставке строки система должна автоматически сгенерировать ключ. В Oracle для этого предлагается объект базы данных — последовательность (SEQUENCE). В Informix имеется тип данных SERIAL. Sybase и SQL Server поддерживают тип данных IDENTITY. В каждой СУБД имеется способ решить эту задачу. Однако методы решения различны, различны и возможные последствия их применения. Поэтому знающий разработчик может выбрать один из двух вариантов:
Теоретическое преимущество первого подхода состоит в том, что при переходе с одной СУБД на другую ничего менять не придется. Я назвал это преимущество "теоретическим", поскольку недостатки такого решения настолько велики, что делают его практически неприемлемым. Для создания полностью независимого от СУБД процесса придется создать таблицу вида:
create table id_table (id_name varchar(30), id_value number);
insert into id_table values ('MY_KEY', 0);
Затем для получения нового ключа необходимо выполнить следующий код:
update id_table set id_value = id_value + 1 where id_name = 'MY_KEY'; select id_value from id_table where id_name = 'MY_KEY';
Выглядит он весьма просто, но выполнять подобную транзакцию в каждый момент времени может только один пользователь. Необходимо изменить соответствующую строку, чтобы увеличить значение счетчика, а это приведет к поочередному выполнению операций. Не более одного сеанса в каждый момент времени будет генерировать новое значение ключа. Проблема осложняется тем, что реальные транзакции намного больше транзакции, показанной выше. Показанные в примере операторы UPDATE и SELECT — лишь два из множества операторов, входящих в транзакцию. Необходимо еще вставить в таблицу строку с только что сгенерированным ключом и выполнить необходимые действия для завершения транзакции. Это упорядочение доступа будет огромным ограничивающим фактором для масштабирования. Подумайте о последствиях, если этот метод применить для генерации номеров заказов в приложении для обработки заказов на Web-сайте. Одновременная работа нескольких пользователей станет невозможной, — заказы будут обрабатываться последовательно.
Правильное решение этой проблемы состоит в использовании для каждой СУБД соответствующего кода. В Oracle (предполагается, что уникальный ключ необходимо генерировать для таблицы T) лучшим способом будет:
create table t ( pk number primary key, ... ); create sequence t_seq; create trigger t_trigger before insert on t for each row begin select t_seq.nextval into :new.pk from dual; end;
В результате каждая вставляемая строка автоматически и незаметно для приложения получит уникальный ключ. Тот же эффект можно получить и в других СУБД с помощью их типов данных — синтаксис оператора создания таблицы изменится, а результат будет тем же. Мы использовали второй вариант — специфические средства каждой СУБД для неблокируемой, высокопараллельной генерации уникального ключа, что, однако, не потребовало реальных изменений в коде приложения — все необходимые действия выполнены операторами DDL.
Приведу еще один пример безопасного программирования, обеспечивающего переносимость. Если понятно, что каждая СУБД реализует одни и те же возможности по-разному, можно при необходимости создать дополнительный уровень доступа к базе данных. Предположим, вы программируете с использованием интерфейса JDBC. Если используются только простые операторы SQL, SELECT, INSERT, UPDATE и DELETE, дополнительный уровень абстракции скорее всего не нужен. Можно включать код SQL непосредственно в приложение, если использовать конструкции, поддерживаемые во всех СУБД, с которыми должно работать приложение. Другой подход, одновременно упрощающий перенос и повышающий производительность, состоит в использовании хранимых процедур, возвращающих результирующие множества. Если разобраться, окажется, что все СУБД могут возвращать результирующие множества из хранимых процедур, но способы при этом используются абсолютно разные. Для каждой СУБД придется написать свой исходный код.
Теперь появляется выбор — либо не использовать хранимые процедуры, возвращающие результирующие множества, либо писать отдельный исходный код для каждой СУБД. Я, несомненно, выбрал бы метод "отдельный код для каждой СУБД" и активно использовал бы хранимые процедуры. Казалось бы, что при этом для перехода на другую СУБД потребуется больше времени. Однако оказывается, что этот подход упрощает создание приложений, переносимых на различные СУБД. Вместо поисков идеального кода SQL, работающего во всех СУБД (причем, как правило, в одних лучше, а в других — хуже), используется код SQL, максимально эффективный в конкретной СУБД. Его можно вынести из приложения, что дает дополнительные возможности настройки. Можно исправить запрос с низкой производительностью непосредственно в СУБД, и это изменение будет немедленно учтено, без исправлений в приложении. Кроме того, при использовании этого метода можно свободно и в полном объеме использовать преимущества предлагаемых производителем СУБД расширений языка SQL. Например, СУБД Oracle поддерживает иерархические запросы с помощью конструкции CONNECT BY в операторах SQL. Эта уникальная возможность очень поможет при создании рекурсивных запросов. В Oracle вы свободно сможете использовать это расширение SQL, поскольку оно — "вне" приложения (скрыто в базе данных). В других СУБД для достижения аналогичных результатов, возможно, придется использовать временные таблицы и хранимые процедуры. Вы заплатили за эти возможности, так почему же их не использовать.
Такие же методы используют разработчики, создавая код, предназначенный для работы на множестве платформ. Корпорация Oracle, например, применяет описанную выше методику при разработке СУБД. Есть большой фрагмент кода (составляющий, однако, небольшую часть всего кода СУБД), который называется OSD-код (Operating System Dependent) и создается отдельно для каждой платформы. С помощью этого уровня абстракции в СУБД Oracle можно использовать специфические возможности ОС для обеспечения высокой производительности и интегрирования, не переписывая при этом код самой СУБД. Именно благодаря этому СУБД Oracle может работать как многопотоковое приложение в Windows и как многопроцессное — в UNIX. Механизмы межпроцессного взаимодействия абстрагированы до такого уровня, что могут воплощаться по-разному для каждой ОС; при этом обеспечивается такая же производительность, как и в приложениях, написанных специально для данной платформы.
Помимо синтаксических различий в языке SQL, различаются реализации операторов, различной будет и производительность выполнения одного и того же запроса, есть проблемы управления одновременным доступом, уровней изолированности транзакций, согласованности запросов и т.д. Все это более детально будет рассмотрено в главах 3 и 4, — мы увидим, как сказываются эти различия. В стандарте SQL92 попытались дать четкие определения того, как должна выполняться транзакция, как должны обеспечиваться уровни изоляции, но в конечном итоге в разных СУБД результаты получаются различными. Все это связано с реализацией. В одной СУБД приложение будет вызывать взаимные блокировки и заблокирует все, что можно. В другой СУБД это же приложение не вызывает никаких проблем и работает отлично. В одной СУБД блокирование (физически упорядочивающее обращения) намеренно использовалось в приложении, а при его переносе в другую СУБД, где блокирования нет, получается неверный ответ. Чтобы перенести готовое приложение в другую СУБД, требуется много труда и усилий, даже если при первоначальной разработке неукоснительно соблюдался стандарт.
Противники обязательного обеспечения "независимости от СУБД" приводят следующий аргумент: нужно хорошо понимать, что именно предлагает конкретная СУБД, и полностью использовать ее возможности. В этом разделе не описываются все уникальные возможности Oracle 8i, — для этого понадобилась бы отдельная большая книга. Новым возможностям СУБД Oracle 8i посвящена специальная книга в наборе документации по СУБД Oracle. Если учесть, что вместе с СУБД Oracle поставляется документация общим объемом около 10000 страниц, детальное рассмотрение каждой возможности и функции практически нереально. В этом разделе просто показано, почему даже поверхностное представление об имеющихся возможностях дает огромные преимущества.
Как уже было сказано, я отвечаю на вопросы о СУБД Oracle на Web-сайте. Если честно, процентов 80 моих ответов — ссылки (URL) на документацию. Меня спрашивают, как реализовать те или иные сложные функциональные возможности в базе данных (или вне ее). А я просто даю ссылку на соответствующее место в документации, где написано, как это уже реализовано в СУБД Oracle и как этими возможностями пользоваться. Часто такие случаи бывают с репликацией. Я получаю вопрос: "Хотелось бы сохранять копию данных в другом месте. Эта копия должна быть доступна только для чтения. Обновление должно выполняться раз в сутки, в полночь. Как написать соответствующий код?". Ответ простой: см. описание команды CREATE SNAPSHOT. Вот что такое встроенные возможности СУБД.
Можно, конечно, для интереса написать собственный механизм репликации, но это будет не самое разумное действие. СУБД делает многое и, как правило, лучше, чем создаваемые нами приложения. Репликация, например, встроена в ядро, написанное на языке C. Она работает быстро, сравнительно проста в использовании и надежна. Работает в разных версиях, на разных платформах. При возникновении проблем служба поддержки Oracle поможет их решить. После обновления версии репликация будет поддерживаться с новыми, дополнительными возможностями. Теперь предположим, что вы разработали собственный механизм репликации. Вам придется заняться его поддержкой во всех версиях СУБД, которые вы собираетесь поддерживать. Одинаковое функционирование в версии 7.3, 8.0, 8.1 и 9.0 и так далее вы должны будете обеспечивать сами. Если произойдет сбой, обращаться будет не к кому. По крайней мере, пока не удастся получить маленький тестовый пример, демонстрирующий основную проблему. При выходе новой версии вам придется самостоятельно переносить в нее код механизма репликации.
Недостаточное понимание того, что предлагает СУБД, может серьезно помешать в будущем. Недавно разработчики демонстрировали мне созданное ими "очень нужное" программное обеспечение. Это была система обмена сообщениями, решавшая проблему очередей в базе данных. Она обычно возникает при необходимости использования таблицы несколькими сеансами в качестве "очереди". Необходимо, чтобы несколько пользователей могли заблокировать очередную запись, пропустив все уже заблокированные записи (они уже обрабатываются). Проблема в том, что нет задокументированной возможности СУБД для пропуска заблокированных строк. Поэтому, не зная о существовании средств, предоставляемых СУБД Oracle, можно приняться за реализацию поддержки очередей самостоятельно (или приобрести готовое решение).
Именно это и сделала упомянутая группа разработчиков. Они создали набор процессов и придумали функциональный интерфейс для организации очередей сообщений в СУБД. Они потратили на это немало времени и сил и были уверены, что сделали нечто действительно уникальное. Когда я увидел систему в действии и узнал ее функциональные возможности, мне осталось сказать лишь одно: это аналог расширенной поддержки очередей, Advanced Queues. Эта возможность давно встроена в СУБД. Она решает задачу "получить первую незаблокированную запись в очереди и заблокировать ее". Все, что нужно, уже сделано. Разработчики, не зная о существовании такой возможности, потратили на ее реализацию много времени и сил. Кроме того, им придется тратить немало времени и на ее поддержку в дальнейшем. Их руководитель не очень обрадовался, узнав, что вместо уникального программного обеспечения получилась эмуляция встроенной возможности СУБД.
Я видел, как разработчики в СУБД Oracle 8i создавали процессы-демоны, читающие сообщения из программных каналов (это механизм межпроцессного взаимодействия в СУБД). Процессы-демоны выполняли операторы SQL, содержавшиеся в прочитанных из программного канала сообщениях, и фиксировали сделанное. Это делалось для проверки транзакций, чтобы записи проверки откатывались при откате основной транзакции. Обычно если для проверки доступа к данным использовались триггеры и основной оператор впоследствии выполнить не удавалось, все изменения откатывались (см. главу 4, где неделимость операторов рассматривается более детально). Посылая же сообщение другому процессу, можно записывать информацию в другой транзакции и фиксировать ее независимо. Запись проверки при этом оставалась, даже если основная транзакция откатывалась. В версиях Oracle до Oracle 8i это был приемлемый (и практически единственный) способ реализации описанной функции. Когда я рассказал разработчикам об автономных транзакциях, поддерживаемых СУБД (мы их подробно рассмотрим в главе 15), они очень расстроились. Автономные транзакции, реализуемые добавлением единственной строки кода, делали то же, что вся их система. Положительным моментом оказалось то, что можно было выкинуть существенную часть кода и не поддерживать его в дальнейшем. Кроме того, система заработала быстрее и стала проще для понимания. Но их это все равно мало радовало, — очень уж много времени было потрачено на изобретение велосипеда. Особенно расстроился создатель процессов-демонов, плоды трудов которого были отправлены в мусорную корзину.
С подобными случаями я сталкиваюсь постоянно: затрачиваются громадные усилия на решение проблем, уже давно решенных в самой СУБД. Если вы не потратите время на изучение того, что предлагается, рано или поздно будете наказаны, изобретая велосипед. Во второй части книги, "Структуры и утилиты базы данных", мы детально рассмотрим отдельные функциональные возможности, предлагаемые СУБД. Я выбрал те возможности и функции, которые часто используют разработчики или которые стоило бы использовать намного чаще. Описана будет, однако, лишь вершина айсберга. В СУБД Oracle намного больше средств и возможностей, чем можно описать в одной книге.
Всегда есть два способа решения любой проблемы: простой и сложный. Но люди почему-то всегда выбирают сложный. Это не всегда делается намеренно, чаще — по незнанию. Разработчики просто не предполагают, что СУБД может делать "это". Я же предполагаю, что СУБД может делать все, и пишу что-то собственноручно, только если оказывается, что этого она не делает.
Например, меня часто спрашивают: "Как сделать, чтобы пользователь мог подключиться к базе данных только один раз?". (Есть еще сотня примеров, которые я мог бы здесь привести в качестве иллюстрации.) Наверное, это требование многих приложений; правда, в моей практике разработки такие приложения не встречались — я не вижу веской причины для того, чтобы ограничивать пользователей подобным образом. Однако другим разработчикам это нужно, и они обычно придумывают сложное решение. Например, создают пакетное задание, выполняемое операционной системой и просматривающее представление V$SESSION, а затем произвольно прекращающее сеансы пользователей, подключившихся к базе данных более одного раза. Или создают собственные таблицы, в которые приложение вставляет строку при регистрации пользователя и удаляет ее по завершении работы. Подобная реализация неизбежно приводит к многочисленным обращениям в службу поддержки, поскольку если приложение завершает работу нештатно, строка из этой таблицы не удаляется. Я видел еще много "творческих" способов добиться этого, но ни один из них не был таким простым:
ops$tkyte@ORA8I.WORLD> create profile one_session limit sessions_per_user 1; Profile created. ops$tkyte@ORA8I.WORLD> alter user scott profile one_session; User altered. ops$tkyte@ORA8I.WORLD> alter system set resource_limit=true; System altered.
Вот и все. Теперь любой пользователь с профилем ONE_SESSION может подключиться только один раз. Простота этого решения обычно приводит разработчиков в восторг и запоздалым сожалениям. Потратьте время на ознакомление с имеющимися средствами и их возможностями — это позволит сэкономить много времени и сил при разработке.
Тот же принцип "делай проще" применяется и на более высоком, архитектурном уровне. Я рекомендую подумать дважды, прежде чем браться за сложные реализации. Чем больше "движущихся частей" в системе, тем больше компонентов, которые могут работать неверно, а при использовании сложной архитектуры определить, что именно является причиной ошибки, будет непросто. Может быть, использование "надцатиуровневой" архитектуры — это действительно "круто", но лишено смысла, если в простой хранимой процедуре можно сделать то же самое, но лучше, быстрее и с использованием меньших ресурсов.
Я участвовал в разработке приложения, продолжающейся более года. Это было Web-приложение, используемое в масштабе компании. Клиент на базе HTML и с использованием технологии JSP динамически получал страницы с сервера промежуточного уровня, который взаимодействовал с CORBA-объектами, в свою очередь, обращавшимися к СУБД. CORBA-объекты должны были поддерживать "состояние" и подключаться к СУБД для организации сеанса. В ходе тестирования этой системы оказалось, что потребуется много серверов приложений и очень мощная машина для работы СУБД, чтобы поддерживать10000, как предполагалось, одновременно работающих пользователей. Более того, иногда возникала проблема нестабильности, связанная со сложностью взаимодействия компонентов (ответить на вопрос, где именно и почему произошла ошибка в этой сложной системе, было трудно). Система масштабировалась, но требовала при этом огромных ресурсов. Кроме того, поскольку для реализации использовалось много сложных технологий, для разработки и сопровождения системы требовалось много опытных программистов. Мы разобрались в этой системе и ее предполагаемых функциях и поняли, что архитектура ее несколько сложнее, чем необходимо для решения поставленных задач. Мы увидели, что с помощью модуля PL/SQL сервера приложений Oracle iAS и ряда хранимых процедур можно было сделать такую же систему, работающую на существенно менее мощном оборудовании, причем усилиями менее опытных разработчиков. Никаких компонентов EJB, никаких сложных взаимодействий между страницами JSP и компонентами EJB — обычное преобразование указанного адреса URL в вызов хранимой процедуры. Эта новая система работает и используется до сих пор, поддерживает больше пользователей, чем предполагалось, и работает так быстро, что порой не верится. Она использует самую простую архитектуру, минимум компонентов, работает на дешевом 4-процессорном сервере уровня рабочих групп и никогда не дает сбоев (ну, один раз табличное пространство переполнилось, но это уже другая проблема).
Для решения задачи я всегда предпочитаю наиболее простую архитектуру. Результат часто получается потрясающий. Для каждой технологии есть соответствующие инструменты — не всегда надо просто гвоздь забить, так что может понадобиться что-то кроме молотка...
Есть еще одна причина, почему при разработке часто выбирается сложный способ решения проблемы, — сложившееся представление, что надо жертвовать всем ради "открытости" и "независимости от СУБД". Разработчики хотят избежать использования "закрытых", "специфических" возможностей СУБД — иногда даже таких простых, как хранимые процедуры или последовательности, поскольку это привяжет их к определенной СУБД. Я настаиваю на том, что если создается приложение, читающее и изменяющее данные, оно уже в некоторой степени привязано к СУБД. Когда запросы начнут выполняться одновременно с изменениями, вы сразу обнаружите небольшие (а иногда — и большие) отличия в работе СУБД. Например, в одной СУБД может оказаться, что оператор SELECT COUNT(*) FROM T вступает во взаимную блокировку с простым изменением двух строк. В Oracle же запрос SELECT COUNT(*) никогда не блокирует другие сеансы. Мы уже рассматривали пример, когда в одной СУБД бизнес-правило работало как побочный эффект используемой модели блокирования, а в другой СУБД — нет. Было показано, что при одном и том же порядке выполнения транзакций в различных СУБД приложение может давать разные результаты. Причина — принципиальные различия в реализациях. Вы со временем поймете, что лишь очень немногие приложения можно непосредственно перенести из одной в другую СУБД. Различия в интерпретации (например, выражения NULL=NULL) и обработке операторов SQL будут всегда.
В одном из недавних проектов разработчики создавали Web-приложение с использованием Visual Basic, управляющих элементов ActiveX, Web-сервера IIS и СУБД Oracle 8i. Разработчики выразили опасение по поводу реализации бизнес-логики на языке PL/SQL - приложение становится зависимым от СУБД — и спрашивали, можно ли это исправить.
Меня этот вопрос несколько удивил. Просматривая список выбранных технологий, я не мог понять, чем им "не понравилась" зависимость от СУБД:
Все остальные технологии они выбрали так, что оказались привязанными к конкретной операционной системе — фактически свобода выбора оставалась только в отношении СУБД.
Независимо от того, что у них, видимо, были веские причины выбрать именно эти технологии, разработчики почему-то решили не использовать в полном объеме возможности критического компонента своей архитектуры и сделали это во имя "открытости". Мне кажется, что нужно сначала вдумчиво выбрать технологии, а затем максимально использовать предоставляемые ими возможности. За все эти технологии заплачены немалые деньги — не в ваших ли интересах максимально их использовать? Причем, создавалось впечатление, что они собирались воспользоваться преимуществами остальных технологий, так почему же для СУБД сделано исключение? На этот вопрос особенно сложно ответить, если учесть, что для эффективности приложения успешная работа с СУБД имеет первостепенное значение.
Можно рассмотреть это с точки зрения "открытости". Все данные помещаются в базу данных. СУБД, поддерживающая эту базу данных, — очень открытое средство. Она обеспечивает доступ к данным через SQL, с помощью компонентов EJB по протоколам HTTP, FTP, SMB и множества других протоколов и механизмов доступа. Пока все отлично: что может быть более открытым?
Затем вне базы данных добавляются алгоритмы и, что важнее, механизмы защиты. Например, в компоненты, обеспечивающие доступ к данным, или в код на Visual Basic, работающий на сервере Microsoft Transaction Server (MTS). В результате с открытостью базы данных покончено — она уже "закрыта". Пользователи теперь не могут использовать эти данные с помощью существующих технологий — они должны использовать предложенные методы доступа (или обращаться к данным в обход защиты). Сегодня это не кажется проблемой, но помните: то, что сегодня является "самой современной" технологией, например компоненты EJB, вчера было идеей, а завтра будет устаревшей, неэффективной технологией. Что осталось неизменным за последние 20 с лишним лет в мире реляционного программирования (да, собственно, и объектно-ориентированного) — это базы данных. Средства работы для пользователей меняются практически ежегодно, и по мере этого все приложения, самостоятельно, а не с помощью СУБД, реализующие защиту, становятся препятствиями на пути дальнейшего прогресса.
СУБД Oracle предлагает возможность детального контроля доступа (Fine Grained Access Control, FGAC, — ему посвящена глава 21). Если коротко, эта технология позволяет разработчику встраивать в базу данных процедуры, которые изменяют поступающие в базу данных запросы. Это изменение запросов используется для ограничения количества строк, которые клиент может получать или изменять. Процедура может определять, кто выполняет запрос, когда этот запрос выполняется, с какого терминала и т.д., и ограничивать соответствующим образом доступ к данным. С помощью FGAC можно организовать такую защиту, когда:
Эта возможность позволяет организовать контроль доступа в СУБД, непосредственно выдающей данные. Теперь уже неважно, получает ли пользователь данные через компоненты, страницы JSP, из приложения на VB с помощью ODBC или через SQL*Plus, — будут применяться одинаковые правила защиты. Вы готовы воспринять любую новую технологию.
Теперь я спрошу: какая технология более "открытая"? Та, что позволяет обращаться к данным только из кода VB и управляющих элементов ActiveX (замените язык VB языком Java, а компоненты ActiveX — компонентами EJB, если хотите; я говорю не о конкретной технологии, а о подходе)? Или та, что обеспечивает доступ из любой среды, способной взаимодействовать с СУБД, по столь отличающимся протоколам, как SSL, HTTP и Net8, или с помощью функциональных интерфейсов ODBC, JDBC, OCI и т. д.? Покажите мне средство создания отчетов, способное выполнять запросы к коду на VB. Я же назову десятки таких средств, выполняющих SQL-запросы.
Решение идти на жертвы ради независимости от СУБД и полной "открытости" волен принять каждый, и многие так и поступают, но я считаю такое решение ошибочным. Независимо от СУБД, ее функциональные возможности необходимо использовать в полной мере. Именно это, как правило, и делается на этапе настройки производительности (этим приходится заниматься сразу же после внедрения). Удивительно, как быстро отказываются от требования независимости, если использование специфических возможностей СУБД позволяет ускорить работу приложения в пять раз.
Вынесенный в название раздела вопрос мне задают постоянно. Все ищут, где бы сделать установку fast = true, предполагая, что настройка производительности базы данных выполняется на уровне СУБД. Мой опыт показывает, что более 80 процентов (часто — намного больше, до 100 процентов) всего повышения производительности достигается на уровне приложения, а не базы данных. Нельзя заниматься настройкой СУБД, пока не настроено приложение, использующее данные.
Со временем появился ряд установок, включая которые на уровне СУБД, можно снизить влияние грубых ошибок программирования. Например, в Oracle 8.1.6 добавлен новый параметр — CURSOR_SHARING=FORCE. Он позволяет включить автоматическое использование связываемых переменных. В результате запрос SELECT * FROM EMP WHERE EMPNO = 1234 автоматически переписывается в виде SELECT * FROM EMP WHERE EMPNO = :x. Это может существенно сократить количество полных разборов и уменьшить ожидание защелок в библиотечном кеше, которые описаны в главе об архитектуре, но (всегда есть но) может также иметь ряд побочных эффектов. Можно нарваться на проблему (или ошибку) при использовании этой возможности, как, например, в первоначальной версии:
ops$tkyte@ORA8I.WORLD> alter session set cursor_sharing=force;
Session altered.
ops$tkyte@ORA8I.WORLD> select * from dual where dummy='X'and 1=0;
select * from dual where dummy='X'and 1=0
*
ERROR at line 1:
ORA-00933: SQL command not properly ended
ops$tkyte@ORA8I.WORLD> alter session set cursor_sharing=exact;
Session altered.
ops$tkyte@ORA8I.WORLD> select * from dual where dummy='X'and 1=0;
no rows selected
Принятый способ переписывания запроса дает некорректный результат в версии 8.1.6 (из-за отсутствия пробела между 'X' и ключевым словом AND). В итоге запрос приобретает вид:
select * from dual where dummy=:SYS_B_0and :SYS_B_1=:SYS_B_2;
Ключевое слово AND стало частью имени связываемой переменной :SYS_B_0. В версии 8.1.7, однако, этот запрос переписывается так:
select * from dual where dummy=:"SYS_B_0"and :"SYS_B_1"=:"SYS_B_2";
Теперь на уровне синтаксиса все работает, но переписывание может отрицательно сказаться на производительности приложения. Например, обратите внимание, что в рассмотренном ранее коде условие 1=0 (всегда ложное) переписано как :"SYS_B_1" = :"SYS_B_2". Теперь на этапе анализа у оптимизатора нет полной информации чтобы определить, вернет ли этот запрос ноль строк (еще до его выполнения). Я понимаю, что запросов с конструкциями типа 1=0 у вас немного, но подозреваю, что в некоторых запросах литералы используются умышленно. В таблице может быть столбец с весьма неравномерным распределением значений (например, 90 процентов значений в столбце — больше 100, а 10 процентов — меньше 100). Причем лишь 1 процент значений меньше 50. Хотелось бы, чтобы при выполнении запроса:
select * from t where x < 50;
индекс использовался, а при выполнении запроса:
select * from t where x > 100;
не использовался. Если установить параметр CURSOR_SHARING = FORCE, оптимизатор не сможет учесть значения 50 или 100, поэтому будет выбирать план для общего случая, когда индекс скорее всего не будет использоваться (даже если 99,9 процентов запросов будут содержать конструкцию WHERE x < 50).
Кроме того, я обнаружил, что, хотя установка CURSOR_SHARING = FORCE обеспечивает намного большую скорость работы, чем повторный анализ и оптимизация множества одинаковых запросов как уникальных, это все равно медленнее, чем выполнение запросов, где связываемые переменные используются изначально. Это происходит не из-за неэффективности механизма совместного использования кода курсора, а из-за неэффективности самой программы. В главе 10 мы рассмотрим, как анализ операторов SQL может влиять на производительность в целом. Во многих случаях приложение, не использующее связываемые переменные, также не обеспечивает эффективного анализа и повторного использования курсоров. Поскольку в приложении предполагается уникальность каждого запроса (так как для каждого из них создается уникальный оператор), то и курсор в нем не будет использоваться более одного раза. Факт в том, что если программист использует связываемые переменные, то он зачастую также анализирует курсор один раз и затем использует многократно. Именно затраты ресурсов на повторный анализ приводят к наблюдаемому снижению производительности.
Итак, важно помнить, что просто добавление параметра инициализации CURSOR_SHARING = FORCE не всегда позволяет решить проблемы. Могут даже возникнуть новые. Во многих случаях параметр CURSOR_SHARING — действительно полезное средство, но это не панацея. Для хорошо продуманного приложения он не нужен. В долгосрочной перспективе обоснованное использование связываемых переменных (и при необходимости — констант) — наиболее правильно.
Даже если есть соответствующие параметры, которые можно установить на уровне базы данных, а их пока немного, проблемы одновременного доступа и неэффективных запросов (неудачно сформулированных или вызванных неудачной организацией данных) нельзя решить только установкой параметров сервера. Для решения этих проблем необходимо переписать приложение (а зачастую и изменить его архитектуру). Перенос файлов данных с одного диска на другой, изменение количества блоков, читаемых подряд одной операцией ввода, и другие настройки "на уровне базы данных" часто мало влияют на общую производительность приложения. Они никак не дадут ускорения в 2, 3, ... N раз, необходимого для достижения приемлемой скорости работы приложения. Как часто требуется ускорить работу приложения на 10 процентов? Если надо ускорить работу на 10 процентов, обычно никто вообще не поднимает вопрос об этом. Пользователи начинают жаловаться, когда, по их мнению, скорость надо увеличить раз в пять. Однако повторяю: вы не увеличите скорость работы в пять раз за счет переноса файлов данных на другие диски. Это можно сделать только путем изменения приложения, например, сократив объем ввода-вывода.
О производительности необходимо думать уже на уровне проекта, а затем непрерывно проверять в процессе разработки. Это нельзя откладывать на потом. Я удивляюсь, сталкиваясь со случаями, когда разработчики передают приложение заказчику, устанавливают и только после этого начинают настраивать. Я видел приложения, которые поставлялись клиентам только с первичными ключами, вообще без дополнительных индексов. Запросы никто не настраивал и вообще не тестировал их производительность. С приложением никогда не работало более десятка пользователей. Настройка считается частью процесса установки и внедрения программного продукта. Для меня такой подход неприемлем. Пользователи должны получать быстро работающую, хорошо настроенную систему. Проблем с продуктом у них будет достаточно и без производительности. Пользователи готовы к тому, что в приложении будут ошибки, но не заставляйте их бесконечно ждать появления сообщений об этих ошибках на экране.
На обложке книги сказано, как важно для АБД представлять, чего пытаются добиться разработчики, а для разработчиков — знать стратегию, используемую АБД для управления данными. Точно известно, что в основе большинства успешно работающих информационных систем лежит плодотворное взаимодействие между АБД и разработчиками приложений. В этом разделе я хочу представить точку зрения разработчика на разделение труда между разработчиком и АБД (исходя из предположения, что при любой важной разработке необходима поддержка группы АБД).
Разработчик не обязан знать, как устанавливать и конфигурировать программное обеспечение. Этим должен заниматься АБД и, возможно, системный администратор. Настройка Net8, запуск программы прослушивания, конфигурирование режима MTS, организация пула подключений, установка СУБД, создание базы данных и т.д. возлагаются на АБД и системного администратора.
Не обязан разработчик также уметь настраивать операционную систему. Лично я обычно предлагаю сделать это системным администраторам. Разработчик приложений баз данных должен быть квалифицированным пользователем соответствующей операционной системы, но нельзя требовать от него знания тонкостей ее настройки.
Пожалуй, одной из основных забот АБД является резервное копирование и восстановление базы данных, и я считаю это обязанностью исключительно АБД. А вот знать принцип работ и использования сегментов отката и журналов повторного выполнения разработчик должен. Знать, как выполнить восстановление табличного пространства по состоянию на определенный момент времени разработчику необязательно. Знание того, что это в принципе возможно, может пригодиться, но делать это самостоятельно вам не придется.
Настройка на уровне экземпляра базы данных, определение оптимального значения параметра SORT_AREA_SIZE — этим обычно занимается АБД. Бывают ситуации, когда разработчику необходимо изменить ряд параметров сеанса, но за параметры уровня базы данных отвечает АБД. Обычно база данных поддерживает приложения нескольких разработчиков, поэтому только АБД, занимающийся поддержкой всех приложений, может принять правильное решение.
Выделение пространства на диске и управление файлами данных — обязанность АБД. Разработчики должны оговорить необходимый объем пространства (сколько им предположительно потребуется), но остальное должны делать АБД и системный администратор.
Итак, разработчики могут не знать, как запустить СУБД, но должны уметь работать в ней. Разработчик и АБД совместно решают разные части одной головоломки. АБД связывается с разработчиком, заметив, что запросы потребляют слишком много ресурсов, а разработчик обычно обращается к АБД когда не знает, как ускорить работу системы (вот когда занимаются настройкой экземпляра — когда приложение полностью настроено).
Конечно, в зависимости от среды разработки возможны варианты, но мне нравится делить обязанности. Хороший разработчик обычно — очень плохой АБД, и наоборот. У них разные навыки и опыт, а также, по моим наблюдениям, разное устройство ума и личностные характеристики.
Мы в общих чертах рассмотрели, почему необходимо знать используемую СУБД. Приведенные примеры — не уникальны, подобное происходит на практике каждый день. Давайте кратко повторим ключевые моменты. Если вы разрабатываете ПО для СУБД Oracle:
Программные проекты начинаются и заканчиваются, языки и среды программирования появляются и исчезают. От нас, разработчиков, ждут создания работающих систем в течение недель, может быть, месяцев, а затем мы переходим к следующей задаче. Если мы будем каждый раз изобретать велосипед, то никогда не перейдем к сути разработки. Никто ведь не создает класс, реализующий хеш-таблицу в Java, — он входит в набор стандартных компонентов. Вот и используйте имеющиеся функциональные возможности СУБД. Первый шаг к этому — узнать их. Читайте дальше.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||