- •2.Опорная модель osi
- •2 Обзор программных средств
- •2.1 Аутентификация и авторизация. Система Kerberos
- •2.2 Установка и настройка протоколов сети
- •4 Классификация архитектур информационных приложений
- •2.1. Файл-серверные приложения
- •2.2. Клиент-серверные приложения
- •2.3. Intranet-приложения
- •2.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных
- •2.5. Интегрированные распределенные приложения
- •5 Файл-серверные приложения
- •3.1. Традиционные средства и методологии разработки файл-серверных приложений
- •3.1.1. Системы программирования и библиотеки
- •3.1.2. Средства и методы разработки приложений на основе субд на персональных компьютерах
- •3.2. Новые средства разработки файл-серверных приложений
- •3.2.1. Общая характеристика современных средств
- •3.2.2. Примеры новых подходов
- •3.2.2.1. Пакет ms Access
- •3.2.2.2. Система Visual FoxPro
- •3.2.2.3. Среда программирования ca-Visual Objects
- •3.3. Перенос файл-серверных приложений в среду клиент-сервер
- •3.3.1. Библиотеки доступа к базам данных
- •3.3.2. Протокол odbc и его реализации
- •3.3.3. Укрупнение приложений (Upsigsing)
- •3.4. Рекомендации по использованию инструментальных средств разработки файл-серверных приложений
- •6 Клиент-серверные приложения
- •7 Принципы работы архитектуры клиент-сервер
- •Частично децентрализованные (гибридные) сети
- •Пиринговая файлообменная сеть
- •Пиринговые сети распределённых вычислений
- •Пиринговые финансовые сети
- •Сети клиент/сервер
- •10 Intranet приложения
- •Intranet - корпоративная , но не публичная сеть
- •Intranet - это применение Web-технологии
- •Intranet - это архитектура клиент-сервер
- •Intranet - не панацея от всех бед
- •11 Организация адресации в интернете
- •4. Практическая часть.
- •Основы сокетов
- •Системные вызовы
- •Создание и уничтожение сокетов
- •Вызов connect
- •Отправка данных
- •Серверы
- •Локальные сокеты
- •Пример использования локальных сокетов
- •Internet-Domain сокеты
- •Пары сокетов
- •Основные конструкции языка Java
- •Библиотека классов языка Java
- •Общие сравнительные характеристики:
- •Вызов расширения isapi сервером www
- •Функция GetExtensionVersion
- •Функция HttpExtensionProc
- •Получение данных расширением isapi
- •Функция GetServerVariable
- •Функция ReadClient
- •Посылка данных расширением isapi
- •Функция WriteCilent
- •Функция ServerSupportFunction
- •Способы поиска в Интернете Три способа поиска в Интернете
- •Поисковые серверы
- •Язык запросов поисковой системы
- •Классификация вторжений
- •Физическая безопасность
- •Утилизация старых компьютеров
- •Программный доступ
- •Идентификация пользователей
- •Системные демоны и службы
- •Службы tcp/ip, которые иногда можно отключить
- •Образец политики корпоративной безопасности
6 Клиент-серверные приложения
Даже в нынешний век сложных многозвенных архитектур многие программы выполняются в простом клиент-серверном режиме, в особенности пакетные задания. Выделяя компонент приложения для тестирования, вы наверняка не откажете себе в такой роскоши. В подобной конфигурации любой сеанс Oracle создает единственный трассировочный файл, содержащий данные только этого сеанса (см. рис. 6.1).
Отсутствие межплатформенного стандарта именования трассировочных файлов вызвало у нашей компании затруднения при создании переносимого инструмента для поиска таких файлов. Мы рассматривали вариант с пополняемой таблицей шаблонов имен (т. е. регулярных выражений), которую можно было бы исправлять по мере переноса Oracle на новые платформы и выхода новых версий. Но мы пришли к выводу, что при поддержании актуальности такой таблицы неизбежно возникало бы множество ошибок. В результате мы остановились на таком алгоритме:
1. По заданным идентификатору и порядковому номеру выбранного
сеанса (значения V$SESSION.SID и V$SESSION.SERIAL#) определить системный идентификатор (SPID) соответствующего серверного процесса. Этот идентификатор содержится в поле V$PROCESS.SPID, соответствующем выбранному сеансу, и может быть получен при помощи соединения, аналогичного приведенному в примере 6.3.
Рис. 6.1. В простых клиент-серверных конфигурациях сеансу соответствует один серверный процесс и, следовательно, один трассировочный файл
Найти, в каком каталоге располагаются файлы трассировки. Этот каталог определяется значением параметра USERDUMPDEST, если V$SESSION.TYPE='USER', или параметра BACKGROUNDDUMPDEST, если V$SESSION.TYPE='BACKGROUND'.
Отсортировать содержимое каталога по убыванию даты изменения файла (например, командой ls -lt в UNIX). Имейте в виду, что время изменения файла (атрибут mtime) обычно указывается с точностью до секунды. Поэтому, если несколько файлов были созданы в течение одной секунды, сравнение значений mtime не даст ответа на вопрос, какой из них был создан последним.
Для каждого файла из полученного списка, значение mtime которого превышает время начала сбора данных (можно задать и более точное условие, но сравнение времени изменения со временем начала сбора данных - это более консервативный подход):
Найти в файле последнюю преамбулу. В особенности это касается платформ Microsoft Windows, где ядро Oracle часто стремится повторно использовать трассировочные файлы, дописывая новые данные к уже существующим. (Поэтому в одном файле может быть несколько преамбул.)
Найти в преамбуле строку, содержащую подстроку «pid» (для Unix и OpenVMS) или «thread id» (для Windows). Преамбулу составляют все строки вплоть до той, которая начинается с подстроки «***».
Если число, следующее за подстрокой «pid» или «thread id», совпадает с идентификатором SPID выбранного сеанса, нужный файл найден, и поиск заканчивается.
Если в файлах из выбранного списка отсутствует подходящий идентификатор процесса, поиск также заканчивается: искомые файлы отсутствуют.
Для проекта Sparky, о котором можно прочитать на сайте http:// www.hotsos.com, мною был написан переносимый код на Perl, выполняющий действия, аналогичные описанным.
Такой метод просмотра содержимого файлов может показаться не очень элегантным, особенно если в данной организации используется только одна или две операционные системы. Однако достоинство приведенного алгоритма в его надежности для различных платформ и различных версий программного обеспечения Oracle. Алгоритм хорошо масштабируется в зависимости от количества файлов трассировки, находящихся в каталоге. Несколько хуже он масштабируется в случае, когда файлы трассировки имеют очень большие размеры и содержат по несколько преамбул.
Параллельное выполнение (Oracle PX)
При параллельном выполнении Oracle (Oracle Parallel eXecution - PX) серверный процесс Oracle порождает два или более дочерних процесса (называемых подчиненными процессами PX) для выполнения параллельного чтения и параллельной сортировки. Подчиненные процессы PX наследуют атрибуты трассировки от координатора запроса. Следовательно, включение расширенной трассировки SQL для сеанса, который использует функциональность PX, приведет к формированию нескольких файлов трассировки. Задача заключается в том, чтобы опознать и проанализировать все нужные файлы. Обычно она решается достаточно просто - необходимо оценить время изменения файлов трассировки, сформированных последними. Для запросов, использующих степень параллелизма p, количество n соответствующих файлов трассировки будет находиться в диапазоне 1 < n < 2p +1 для каждого вовлеченного экземпляра.
Многопоточный сервер Oracle
Применение многопоточного сервера Oracle (MTS) несколько усложняет поиск данных трассировки. MTS делает возможным использование коммутируемых соединений, что приводит к созданию отношения «один-ко-многим» между сеансом и серверными процессами Oracle, которые обслуживают вызовы базы данных, выполненные сеансом (рис. 6.2). Соответственно, данные трассировки для одного сеанса могут оказаться разбросанным по двум или более трассировочным файлам. Ядро Oracle предоставляет полные сведения по идентификации сеанса и временные метки каждый раз, когда сеанс мигрирует в новый серверный процесс (а следовательно, и в новый файл трассировки). Создать логический эквивалент единого файла трассировки для конкретного сеанса несложно. Рассмотренный ранее способ поиска файлов трассировки претерпевает следующие изменения:
Рис. 6.2. Многопоточный сервер Oracle использует отношение один-ко-многим для клиентского и серверных процессов, поэтому данные о сеансе могут направляться в несколько файлов трассировки
В зависимости от версии Oracle, совместно используемые серверные файлы трассировки могут храниться в параметре BACKGROUND_DUMP_DEST (мы с коллегами видели это на некоторых платформах для версий 7 и 8) или же в USERDUMPDEST (наблюдается в версии 9).
Вместо того чтобы завершать поиск, обнаружив один файл трассировки с нужной информацией, идентифицирующей сеанс, необходимо продолжить просмотр всех файлов трассировки с подходящим временем изменения.
Определив все файлы, которые содержат нужные данные трассировки, необходимо отбросить данные, относящиеся не к вашему сеансу, а затем объединить оставшиеся. Сначала избавляемся от сегментов данных трассировки, относящихся к сеансам, отличным от исследуемого. Чтобы определить, какие секции следует сохранить, достаточно просто просмотреть строки идентификации сеансов, которые начинаются с символов ***. Затем объединяем оставшиеся участки данных трассировки по возрастанию времени. Это тоже несложно, т. к. строки *** содержат и значения времени. В результате получаем «виртуальный файл трассировки», содержащий сведения только для исследуемого сеанса. Эту операцию можно выполнить вручную в многооконном текстовом редакторе, а можно приобрести специальное средство, которое все сделает за вас. Наша команда на hotsos.com создала подобный продукт и предлагает его на коммерческой основе.
Пул соединений
Как я уже говорил, организация пула соединений - это замечательная возможность, призванная уменьшить количество вызовов подключения к базе данных и отключения от нее. Степень сложности диагностики приложений, работающих с пулами соединений, полностью определяется реализованными в них возможностями. Если приложение позволяет идентифицировать вызовы базы данных, сделанные от имени пользовательской операции, то работа по сбору данных будет простой. К сожалению, многие приложения, работающие с пулами соединений, не обеспечивают такой возможности. Надеюсь, Oracle версии 10 упростит оснащение приложений такими средствами на несколько следующих лет.
Проблемы диагностики производительности для пулов соединений возникают тогда, когда сервер приложений «утаивает» личность конечного пользователя от базы данных. Один сеанс разделяют между собой несколько пользователей, из-за чего невозможно по одному лишь файлу трассировки определить, чьи действия вызвали появление некоторой строки в трассировочных данных (рис. 6.3).
Лучшим общим решением проблемы диагностики приложений, работающих с пулом соединений, является такая архитектура приложения, которая делает возможным включение расширенной трассировки SQL для действий каждого отдельного пользователя.
Если приложение ничем не может помочь в трассировке команд SQL отдельного пользователя, не отчаивайтесь. Конечно же, существуют идругие пути, ведущие к успеху. Рассмотрим такой пример: пользо-
Рис. 6.3. Архитектура, основанная на пуле соединений. Если среднее звено не отслеживает соответствие конечных пользователей вызовам базы данных, то нельзя определить, какой из пользователей вызвал появление той или иной строки данных трассировки
ватель Нэнси, имеющая IP-адрес 150.121.1.102, сообщила об ухудшении производительности приложения ввода заказов, основанного на пуле соединений (архитектура приложения приведена на рис. 6.3). Приложение никак не способствует выделению данных расширенной трассировки SQL для Нэнси.
Есть простой способ: временно запретить работу с системой всем пользователям, кроме Нэнси. Включить расширенную трассировку процесса, обслуживающего Нэнси, и позволить ей выполнить ее медленные операции. Когда Нэнси сделает все, что нужно, отключить трассировку и разрешить всем пользователям вернуться в систему. Этот способ весьма эффективен в отдельных случаях, но надо сказать, что в дополнение к очевидному вмешательству в ход процессов бизнеса, он имеет и серьезный диагностический недостаток. Если ухудшение производительности, о котором сообщила Нэнси, было вызвано конкуренцией с другими сеансами, то данные, собранные предложенным способом, никак не будут указывать на основной источник неприятностей.
Более эффективный обходной маневр - временное изменение архитектуры, которое бы изолировало сеанс Нэнси. Один из способов реализации такого изменения изображен на рис. 6.4, где изоляция сеанса Нэнси обеспечена за счет предоставления ей собственного процесса на сервере приложений и отдельного выделенного серверного процесса Oracle. Для того чтобы реализовать такой переход, можно, например, назначить Нэнси специальный «идентификатор службы» (аналог специального псевдонима TNS для уровня служб приложения), который
Рис. 6.4. Если изолировать действия пользователя так, чтобы в назначенный ему файл трассировки не попадали данные об операциях других пользователей, то сбор диагностических данных становится таким же простым, как в случае простого клиент-серверного приложения обеспечивает соединение со специальным диагностическим процессом сервера приложений.
Противники этого метода обычно отмечают, что изменение архитектуры может оказать влияние на производительность исследуемого сеанса Нэнси. Однако эти изменения имеют более локальный характер, чем в первом случае, т. к. мы не изменяем нагрузку, конкурирующую с действиями Нэнси. Конечно же, необходимо будет изучить сделанные изменения, особенно если окажется, что перемены в архитектуре повлияли на производительность. Например, если измененная архитектура, представленная на рис. 6.4, демонстрирует значительно более высокую производительность, чем архитектура на рис. 6.3, то следует задуматься, не является ли виновником низкой производительности процесс сервера приложений httpdO.
Последний предлагаемый способ возможен лишь в том случае, если все, кто совместно с Нэнси использует один или несколько серверных процессов, выполняют приблизительно те же операции, что и Нэнси. Если все соединения, которые задействуют серверные процессы, выполняют однотипные операции, то каждая из строк результирующего файла трассировки достаточно показательна для изучения действий Нэнси (рис. 6.5).
Конечно же, утверждение о том, что невозможно восстановить составляющие из усредненного значения, остается истинным. И поэтому рискованно рассматривать общий файл трассировки, стремясь полу-