Oracle постоянно обращалась к участникам программы бета-тестирования OracleS с просьбой не использовать при выполнении тестов на производительность предварительные версии этого ПО, но мы не можем не отметить, что в последней бета-версии простое соединение с OracleS на Windows NT из программы SQL*Plus потребовало около 2 Мб оперативной памяти. Пользователи программы SQL*Plus с активными сеансами (сеансами, которые уже какое-то время работати) использовали 10 Мб оперативной памяти. Умножьте эти цифры (или даже цифры, значительно меньшие) на 100000 одновременно работающих пользователей, обычно поддерживаемых самыми большими OLTP-системами на базе мэйнфреймов, и все станет ясно. Когда терабайт нужен для базы данных — это одно, а когда он нужен только для файла pagefile.sys — совершенно другое.
Мы повторим тезис, выдвинутый нами в книге "Oracle: проектирование баз данных" — эффективная поддержка большого числа одновременно подключенных пользователей требует совместного использования соединений (как правило, с помощью менеджера транзакций). Это, в свою очередь, обусловливает необходимость в трехуровневой архитектуре. В такой архитектуре логика представления обычно размещается в клиентской части, прикладная логика — на среднем уровне, а логика данных — на сервере данных. Мы обеспокоены тем, что Oracle, кажется, скрывает это от своих пользователей (возможно, из коммерческих соображений), потому что трехуровневая архитектура предполагает передачу функций общей координации транзакций и управления аутентификацией пользователей и привилегиями менеджеру транзакций, а серверу базы данных остаются полномочия только собственно сервера.
Идентификация пользователей
Настоящее совместное использование соединений с базой данных требует, чтобы задачи-исполнители в менеджере транзакций поддерживали устойчивые соединения с базой данных, которые назначены ими для обработки атомарных запросов, производящихся от имени их клиентов. Как правило, каждая задача-исполнитель соединяется с сервером как один из ограниченного числа "пользователей", работающих в широком диапазоне полномочий (например, ACCOUNTS_QUERY_USER, ACCOUNTSJJPDA-TE_USER и т.д.). При этом не требуется, чтобы сервер базы данных формально распознавал отдельного пользователя, даже если сама база данных является хранилищем, используемым менеджером транзакций для регистрации данных пользователей.
Это имеет большое значение, потому что мы вполне обоснованно можем предполагать, что у Web-сервера будет неограниченное число пользователей. В момент написания данной книги потенциальное число пользователей составляло 50 миллионов, и эта цифра быстро растет. Однако, к нашему удивлению и ужасу, в OracleS установлено ограничение всего в 65535 пользовательских идентификаторов.
Совет:
Перед регистрацией пользователей базы данных Oracle, убедитесь, что общее число таких пользователей не превышает указанный лимит.
4.  "Большие" особенности Oracle8	79