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

О они выбрали язык программирования, привязанный к определенной операционной системе и поддерживаемый единственным производителем (можно было выбрать язык Java);

они выбрали технологию создания компонентов, привязывающую к одной операционной системе и производителю (они могли выбрать технологию EJB или CORBA);

они выбрали Web-сервер, работающий на единственной платформе того же производителя (почему не Apache?).

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

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

Можно рассмотреть это с точки зрения открытости . Все данные помешаются в базу данных. СУБД, поддерживающая эту базу данных, - очень открытое средство. Она обеспечивает доступ к данным через SQL, с помощью компонетов EJB, по протоколам HTTP, FTP, SMB и с помощью множества других протоколов и механизмов доступа. Пока все отлично: что может быть более открытым?

Затем вне базы данных добавляются алгоритмы и, что важнее, механизмы защиты. Например, в компоненты, обеспечивающие доступ к данным, или в код на Visual Basic, работающий на сервере Microsoft Transaction Server (MTS). В результате с открытостью базы данных покончено - она уже закрыта . Пользователи теперь не могут использовать эти данные с помощью существующих технологий - они должн1 использовать предложенные методы доступа (или обращаться к данным в обход защиты). Сегодня это не кажется проблемой, но помните: то, что сегодня является самой современной технологией, например компоненты EJB, вчера б1ло идеей, а завтра будет устаревшей, неэффективной технологией. Что осталось неизменным за последние 20 с лишним лет в мире реляционного программирования (да, собственно, и объектно-оритентированно-го) - это базы данных. Средства работы для пользователей меняются практически ежегодно, и по мере этого все приложения, самостоятельно, а не с помощью СУБД, реализующие защиту, становятся препятствиями на пути дальнейшего прогресса.

СУБД Oracle предлагает возможность тщательного контроля доступа (Fine Grained Access Control, FGAC, - ему посвящена глава 21). Если коротко, эта технология позво-

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

запросы, выполняемые в нерабочее время определенным классом пользователей, не возвращают никаких записей;

данные могут читаться с терминала в охраняемом офисе, но на терминал удаленного клиента конфиденциальная информация не выдается.

Эта возможность позволяет организовать контроль доступа в СУБД, непосредственно в1дающей данн1е. Теперь уже неважно, получает ли пользователь данные через компоненты, страницы JSP, из приложения на VB с помощью ODBC или через SQL*Plus, - будут применяться одинаковые правила защиты. Вы готовы воспринять любую новую технологию.

Теперь я спрошу: какая технология более открытая ? Та, что позволяет обращаться к данным только из кода VB и управляющих элементов ActiveX (замените язык VB языком Java, а компоненты ActiveX - компонентами EJB, если хотите; я говорю не о кон-ретной технологии, а о подходе)? Или та, что обеспечивает доступ из любой среды, способной взаимодействовать с СУБД, по столь отличающимся протоколам, как SSL, HTTP и Net8, или с помощью функциональных интерфейсов ODBC, JDBC, OCI и т. д.? Покажите мне средство создания отчетов, способное выполнять запросы к коду на VB. Я же назову десятки таких средств, выполняющих SQL-запросы.

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

Как ускорить работу?

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

Со временем появился ряд установок, включая которые на уровне СУБД, можно снизить влияние груб1х ошибок программирования. Например, в 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 duy=X and 1 = 0; select * from dual where duy=X and 1 = 0

ERROR at line 1:

ORA-00933: SQL coand not properly ended

ops$tkyte@ORA8I.WORLD> alter session set cursor sharing=exact; Session altered.

ops$tkyte@ORA8I.WORLD> select * from dual where duy=X and 1 = 0;

no rows selected

Принятый способ переписывания запроса дает некорректный результат в версии 8.1.6 (из-за отсутствия пробела между X и ключевым словом AND). В итоге запрос приобретает вид:

select * from dual where duy=:SYS B 0 and :SYS B 1=:SYS B 2;

Ключевое слово AND стало частью имени связываемой переменной :SYS B 0. В версии 8.1.7, однако, этот запрос переписывается так:

select * from dual where duy=: SYS B 0 and : SYS B 1 = : SYS B 2 ;

Теперь на уровне синтаксиса все работает, но переписывание может отрицательно сказаться на производительности приложения. Например, обратите внимание, что в рассмотренном ранее коде условие 1=0 (всегда ложное) переписано как : SYS B 1 = : SYS B 2 . Теперь на этапе анализа у оптимизатора нет полной информации чтобы определить, вернет ли этот запрос ноль строк (еще до его выполнения). Я понимаю, что запросов с конструкциями типа 1=0 у вас немного, но подозреваю, что в некоторых запросах литералы используются ум1енно. В таблице может быть столбец с весьма неравномерным распределением значений (например, 90 процентов значений в столбце - больше 100, а 10 процентов - меньше 100). Причем лишь 1 процент значений меньше 50. Хотелось бы, чтобы при выполнении запроса:

select * irom t where x < 50 ;

индекс использовался, а при выполнении запроса:

select * Irom t where x > 100;

не использовался. Если установить параметр CURSOR SHARING=FORCE, оптимизатор не сможет учесть значения 50 или 100, поэтому будет выбирать план для общего