 |
  |
|||
 |
 |
 |
||
 |
|
 |
||
Издатель: Algorithm Online При поддержке ORACLE в России  Техническая поддержка  официальный дистрибутор ORACLE |
|
|
Доступ к большим базам данных через Web1 июня 2000 г. Supporting Large Databases on the Web, by Bradley D.Brown, ORACLE MAGAZINE, vol.XII/no.4, 1998 Бредли Браун Обеспечение Web-доступа к проблемной информации может предоставить любой компании новые возможности в конкурентной борьбе, но следует удостовериться, что подобное нововведение полезно для пользователей и безопасно для компании. Практически каждая корпорация, или уже использует Web, или находится в стадии подготовки. Но достаточно ли этого, чтобы действительно задействовать, быть "на Web"? Вряд ли. Когда компания говорит, что она находятся на Web, под этим обычно подразумевается, что эта компания получает статистическую маркетинговую информацию, доступную через Всемирную Паутину (World Wide Web). Однако, согласно исследованиям Gartner Group, выгода от использования Web состоит не только в получении статистической информации: она возрастает от обеспечения доступа в реальном масштабе времени к информации баз данных, что и решает множество реальных проблем. Другими словами, если Вы хотите конкурировать в глобальном масштабе, следует предоставить клиентам доступ к самой современной информации, которую они смогут использовать. Для того чтобы максимизировать выгоду от нахождения на Web, необходимо управлять как позициями спроса, так и позициями предложения. Выгода только возрастает от привлечения в вашу клиентскую базу дополнительных сведений, что дает Вам преимущество в конкурентной борьбе и помогает увеличить продажи. Кроме увеличения рыночной прибыли, имеются и другие преимущества от предоставления информации из базы данных через Web:
Поэтому, если Вы еще не поместили информацию вашей базы данных на Web в форме, доступной и полезный для ваших клиентов, то сейчас как раз наступает время сделать это. В этой статье рассматриваются некоторые наиболее общие проблемы, к которым следует быть готовым, когда Вы размещаете очень большую базу данных (VLDB - very large database) или большое хранилище данных (large data warehouse) на Web. Хорошо, но кто же занимает CPU?Проблема: в вычислительной среде с неопределенным статусом обычно трудно идентифицировать, кто какие выполняет запросы. Но именно это является важнейшей проблемой, когда вступает в дело VLDB или большое хранилище данных. Как же определить, кто расходует все время CPU? Решение: используя механизм аутентификации (authentication – установление подлинности) в базе данных, можно легко идентифицировать, какие пользователи занимают время CPU. Аутентификация в базе данных является методом обеспечения безопасности, при котором имена пользователей (username) и пароли (password) сохранены в базе данных Oracle, а не в файле операционной системы, как было бы при применении базисного варианта или в случае справочной аутентификации (digest-authentication). Когда используются средства мониторинга базы данных, например, утилита Performance Monitor (Монитор Производительности), входящая в состав Oracle Enterprise Manager, журналы содержат списки пользователей системы с именами их учетных записей в Oracle, что делает легким идентификацию пользователей и использование ими ресурсов. Многие из подобных инструментальных средств агрегируют, обобщают такие сведения и выдают отчеты об использовании ресурсов. Но Вы можете сделать подобное и сами. Ой-ой, Вы запрашиваете слишком много!Проблема: поскольку в системе клиент/сервер пользователи регистрируются в базе данных, всегда можно определить, кто использует ресурсы. Если же используется Web, можно отказаться от аутентификации пользователей в силу того, что в системе имеются слишком много пользователей, или же разрешить выполнение запросов без обязательной регистрации. (Без аутентификации в базе данных нет возможности выявления, кто какие запускает запросы.) Как же удержать пользователей от выполнения запросов, которые могут поставить систему на колени? Решение: когда нельзя узнать, кто выполняет запросы, настройка запросов в значительной степени затруднена. Для того чтобы все-таки выполнить настройку, следует разработать и заранее настроить определенные запросы, чтобы избежать затем случайных жестоких всплесков занятости. Например, можно разработать экранную форму с полями сортировки и критериев поиска. В дальнейшем можно разрешить пользоваться этой формой всем пользователям, чтобы они сохраняли свои критерии для последующих выборок. В дополнение к запросам предварительной настройки (pretuning), можно использовать виртуальное представление v$sqlarea, чтобы разделять в реальном времени проблемные запросы по числу операций чтения с диска. Из общего списка следует выделить предложения, которые в каждом запуске требуют большое число обращений к диску по чтению. Это, как правило, более важно, чем общее количество дисковых чтений: предложение, которое выполнило за 5 запусков 100,000 дисковых чтений (каждый раз по 20,000 операций), представляет большую проблему, чем предложение, запускавшееся 100,000 раз, с 1,000,000 дисковых чтений (по 10 операций за выполнение). Как только подобная проблема вычленена, можно настроить запрос в приложении. Если возникают проблемы в результате случайных (ad hoc) запросов, следует установить ограничения профиля (profile limits), чтобы автоматически уничтожать нескончаемые (runaway) запросы. Если разместить на Web-сервере и воспользоваться показанной на листинге 1 процедурой query_sqlarea, можно увидеть отсортированные (по умолчанию – по количеству операций чтения за выполнение) конкретные SQL-предложения, а также следующие сведения: ID запроса, количество запусков, количество сортировок, вид команды и число прочитанных блоков. Используя подобную информацию, можно пропускать те запросы, которые не требуют настройки, и сфокусировать все свое внимание только, скажем, на 10 самых тяжелых, а не на всех, например, 1,000 запросах. В этой процедуре можно установить определенное число дисковых чтений в качестве порогового значения (in_access_level). И, когда установлен порог, например, 1,000, будут показаны только те запросы, которые осуществляют более 1,000 операций чтения блоков. То ли Вы отыскали?Проблема: Вам требуется быстро обработать значительный объем информации, получаемый через Web. Но если по запросу выбирается 1 миллион записей (или пусть только 1,000 записей), кто же реально сможет продраться сквозь такое слишком большое количество данных и воспользоваться ими в оперативном режиме? Кроме того, данные, отображаемые браузером, обычно оформляются в виде HTML-таблицы, но HTML-таблица не покажет данные до тех пор, пока все они не будут получены. Поэтому просмотр с использованием браузера тысяч записей входит в противоречие с тем постулатом, что браузер, как предполагалось, является тонким клиентом. Как же Вам управиться с таким большим количеством информации? Решение: имеются несколько способов, чтобы извлечение данных по запросу сделать более дружественным. Во-первых, если пользователи выбирают большие объемы данных, важно удостовериться, что предоставленная информация полезна. Как правило, лучше обеспечить наиболее возможно высокий уровень итоговой информации и позволить пользователям спускаться вниз до того информационного уровня, который им требуется. Например, в нашей консультационной фирме клиенты находятся на самом верху информационной лестницы, ниже идут проекты, разрабатываемые для наших клиентов, еще ниже следует занятость служащих в клиентских проектах, и, наконец, время и расходы, потраченные служащими в этих проектах. Предположим, что сначала я хочу посмотреть список клиентов и величину дохода, получаемого от каждого клиента. Затем я щелкаю по отметке какого-то клиента и вижу список проектов этого клиента и величину дохода от каждого такого проекта. Если я щелкаю по отметке проекта, я могу видеть доход от служащего в данном проекте. Наконец, я выбираю служащего, участвующего в проекте, и вижу расход времени и других ресурсов, потраченных этим служащим для конкретного клиентского проекта. В качестве другого способа представления информации можно придумать, что служащие общаются с менеджерами, менеджеры подчиняются старшим менеджерам и так далее. Следуя по этому пути, можно было бы показывать список старших менеджеров и общее количество запланированных и сверхурочных часов, отработанных каждым менеджером, подчиненному конкретному старшему менеджеру. Тогда, щелкая по отметке какого-либо менеджера, можно было бы увидеть служащих, которые общаются с этим менеджером. Если я щелкаю отметке часов конкретного менеджера, то могу получить информацию о расходе времени и других ресурсов за прошедшую рабочую неделю этого менеджера. Секундочку, сначала попробуем выполнить запрос, который определит только число записей, которые требуется выбрать. Если это число превышает установленный порог, надо спросить пользователя, действительно ли он или она захочет увидеть такое большое количество данных. Тем самым, формируется система с предварительной оценкой, которая побуждает пользователя сузить свой запрос. Наконец, когда отображаемые данные возвращаются назад к браузерам пользователей, следует удостовериться, что ваше приложение посылает ровно столько записей, сколько Вы (или пользователь) в состоянии обработать за один прием. Можно, например, так построить логику подкачки страниц (paging logic), что пользователь сможет единовременно увидеть только 100 записей за один прием. (Механизм подкачки страниц устанавливает разовое количество посылаемых записей.) Это действие можно выполнять как дополнительное, а переменную отсечки страниц добавить к таблице профиля пользователя. Однако, это применимо только в том случае, если производится идентификация или аутентификация пользователей. Разрешая пользователям определение размеров их собственных страниц, Вы позволяете им задавать и объем отображаемой информации. На листинге 2 показано, как работает подкачка страниц при составлении списка служащих. Можно ввести дополнительные условия ("<<", "<", ">", ">>"), которые позволят организовать переходы пользователя к первой, предыдущей, последующей, последней порциям записей соответственно. Нет, Вы не должны знать это.Проблема: требуется обеспечить доступ через Web к большой базе данных, которая содержит, в том числе, такую информацию, к которой не желателен широкий публичный доступ. Как следует установить защиту схемы так, чтобы обеспечить только уполномоченным пользователям доступ к определенной конфиденциальной информации, как обеспечить защиту разгружаемой информации (информация, показываемая браузером на экране) от других данных в процессе разгрузки, как ограничить круг уполномоченных лиц в организации, кто имеет право доступа к базе данных, и установить, к каким информационным областям им предоставлено право доступа? Решение: каждое решение в области защиты данных требует отдельного решения. Во-первых, следует использовать механизм аутентификации базы данных, чтобы ограничить доступ к базе. В процессе аутентификации пользователи должны идентифицировать себя к системе прежде, чем они получат доступ к приложению. (Для получения более детальной информации по обеспечению безопасности следует обратиться к руководству "Security Management for Oracle8" ("Управление средствами защиты в Oracle8")). Когда пользователь запрашивает информацию через браузер, данные в достаточной степени защищены при передаче от сервера к серверу. Единственной дырой в защите в терминологии ISP (International Standardized Profile - Международный Стандартизированный Профиль (архитектура ВОС - Взаимодействие Открытых Систем)) может стать точка взаимодействия (interconnection point) в том случае, если кто-то перехватил (sniffing) пакеты данных и использовал информацию злонамеренным образом. Однако, это очень маловероятно. Другими словами, если я нахожусь в своем офисе в Денвере и делаю по Интернет запрос в наш офис в Чикаго, маловероятно, что кто-либо сможет увидеть информацию, проходящую по Web. Информация защищена на пути от сервера, который связан с Web в Денвере, до сервера, который связан с Web в Чикаго. Однако, как только данные поступают в каждую оконечную сеть, эти пакеты в достаточной степени открыты для пакетных перехватчиков (packet sniffers). Пакетный перехватчик является частью аппаратных средств, которые занимаются мониторингом сети и собирают информацию о пакетах, которые транспортируются между машинами (между клиентами и серверами). Они перехватывают ("обнюхивают") пакеты, которые проходят по сети, но могут делать это только в пределах своих собственных сетей. Поэтому, любое лицо в любом офисе, которое обладает надлежащими инструментами, которое получило соответствующее обучение и обладает склонностью к этому роду деятельности, может перехватывать пакеты. Защита информации на пути от клиента к клиенту может быть обеспечена при помощи механизма SSL (Secure Sockets Layer - защита на уровне сокетов), на котором производится шифровывание (scramble) или криптографирование (encrypt) данных, посылаемых от сервера к клиентам (и наоборот) таким способом, что только конкретные клиенты могут расшифровать их. Если Вы заинтересованы в безопасности информации в базе данных, зашифруйте данные, содержащиеся в определенных полях базы. Таким образом, только определенное приложение может расшифровать информацию. Действие по расшифровке обычно сочетается с аутентификацией, коль скоро требуется ограничить круг лиц, которым разрешен доступ к информации. Существует большое число криптографических функций, доступных в Web, как, например, класс Java-криптографических функций, разработанных компанией Sun Microsystems. А защищен ли он?Проблема: Вы установили Oracle Application Server (сервер приложений Oracle) в конфигурации по умолчанию. Обеспечены ли защитой Ваши данные и приложения? Решение: конфигурация по умолчанию Oracle Application Server не обеспечивает достаточной защиты для производственных приложений, которые выходят в Web. Применение конфигурации по умолчанию оставляет дыру в защите системы, что может создать проблемы производственных приложениях: опция по умолчанию создает учетную запись с привилегиями DBA (администратор базы данных) и PL/SQL-агента (PL/SQL Agent), который работает с этим бюджетом. Опытный знаток (sharp - также и жулик), Web-разработчик может вычислить, как проникнуть в вашу базу данных, используя эту информацию. Если Вы пока не установили Oracle Application Server, не следует использовать возможность конфигурации по умолчанию. Если Вы уже это сделали, следует удалить пользователя WWW_DBA и PL/SQL-агента WWW_DBA. Независимо от варианта установки сервера приложений, надо удостовериться, что ваши административные директории защищены на уровне операционной системы, а также что ваши административные пароли не тривиальны. И последнее, рекомендуется назначить для административного листенера (listener – процесс прослушивания сети) другой, нежели по умолчанию (8888), порт и установить, или IP-, или доменное ограничение на порт административного листенера. Далее, как обеспечить максимумПроблема: желательно получить максимальную производительность некоего приложения, но механизм инсталляции картриджей по умолчанию порождает PL/SQL-картридж, используемый в качестве общей программы межсетевого интерфейса (CGI - common gateway interface), без постоянно функционирующих экземпляров. Как это исправить? Решение: следует использовать административные функции Oracle Application Server, чтобы установить для PL/SQL-картриджа значение параметра Minimum Number of Instances (минимальный число экземпляров) равным ожидаемому среднему числу одновременных пользователей. Это значение определяет, сколько экземпляров PL/SQL-картриджа стартует и затем продолжит функционирование после того, как стартует Web Request Broker (Web-брокер запросов). По умолчанию оно равно 0, что означает, что каждый раз, когда производится запрос к PL/SQL-агенту, Web-брокер запросов должен стартовать новый экземпляр картриджа. А после того, как система запустит процедуру, она избавится от уже отработавшего экземпляра картриджа. Для того чтобы избежать подобной ситуации, следует задать такое минимальное число экземпляров, которое имеет смысл для конкретного приложения. Например, если ожидается, что приложение одновременно будут использовать 10 человек, надо установить минимальный число экземпляров равным 10. На уровне операционной системы можно наблюдать фактическое количество функционирующих экземпляров картриджа и регулировать это значение, но в любом случае не следует снижать его до нуля. ИнвентаризацияПроблема: как определить требуемое число лицензий для Oracle Application Server? Решение: трудно предсказать число клиентов, которые будут использовать некое Web-приложение. Однако можно задать максимальное число экземпляров, соответствующее вашему лицензионному соглашению. Если задается число экземпляров, большее, чем число полученных лицензий, возникает необходимость отслеживать высшую точку (high-water mark) использования этого приложения, чтобы докупить соответствующее число Oracle-лицензий. Рекомендуется обсудить этот вопрос с представителем продаж Oracle. Остановите нескончаемый запросПроблема: когда пользователь стартует запрос и затем щелкает кнопке Stop в браузере, это освобождает браузер от ожидания ответа на этот запрос. Однако, в точно неустановленной (nonstate) вычислительной среде, действие кнопки Stop реализуется только на стороне клиента. Сервер никогда об этом не уведомляется, так что запрос на сервере продолжает выполняться. Это обычно случается тогда, когда пользователь устал от ожидания результата, причиной чего может быть "нескончаемый" ("runaway") запрос. Как же предохранить систему от перенагрузки в результате нескончаемых запросов? Решение: один из способов предотвращения нескончаемых запросов состоит в том, чтобы присвоить схемам профили (profile), которые устанавливают пределы времени CPU, предоставляемое пользователю до того, как система прервет процесс. Можно также разработать кнопку Abort Query (аварийное прекращение запроса) и проинструктировать пользователей, как применять именно ее, вместо остановки браузера. При этом надо разработать соответствующую программную логику, чтобы система прервала запрос по сведениям, посланным по кнопке Abort Query. В настоящее время не имеется общего, оформленного в виде пакета, решения по обработке прерванных пользователем запросов. Об авторе: Bradley D.Brown (brownb tusc.com) - президент компании TUSC (www.tusc.com), многопрофильной консалтинговой компании, которая специализируется на внедрении Oracle. Brown является автором книги "Oracle Application Server: Web Toolkit Reference", опубликованной издательством Oracle Press. Автор выражает особую благодарность Джо Треззо (Joe Trezzo), Феликсу Лакапу (Felix Lacap) и Матту Малецки (Matt Malcheski) за их вклад в эту статью. Листинг 1. Процедура query_sqlarea используется для мониторинга предложений. |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Письмо в редакцию