Интегрированная база данных
Другие функции базы данных
DB2/400 поддерживает и несколько дополнительных функций. Некоторые из них расширяют возможности применения AS/400 в клиент/серверных системах и средах распределенных баз данных, другие призваны повысить производительность базы данных. В этом разделе мы затронем только самые важные.
Хранимые процедуры
Один из самых действенных способов повысить производительность клиент/серверных приложений для AS/400 — хранимые процедуры. Оператор CALL в SQL позволяет приложению вызывать хранимую процедуру, которая исполняется на сервере AS/400. Таким образом, в результате одного обращения к серверу выполняется целая транзакция. Без хранимых процедур для этого потребовалось бы множество таких обращений. В качестве хранимой процедуры может использоваться, за небольшими исключениями, любая программа AS/400, в том числе написанная на ЯВУ и даже содержащая операторы SQL. Доступ к хранимым процедурам возможен только через интерфейс SQL с использованием оператора CALL.
Поддержка национальных языков
Первый шаг в реализации Unicode на AS/400 был сделан в V3R1, где с его помощью кодировались имена объектов некоторых компонентов интегрированной файловой системы. Unicode поддерживает одновременное использование множества наборов символов (национальных алфавитов) в одной кодировке.
В RISC-моделях эта поддержка была расширена, чтобы обеспечить хранение в файлах базы данных в Unicode (UCS2, уровень 1). Например, в одном файле базы данных может находиться информация на французском, немецком, английском, иврите, китайском, русском и других языках. SQL поддерживает преобразование в Unicode и обратно, что делает возможным работу старых приложений с данными в этой кодировке. Кроме того, имеется поддержка локализации (locale) — стандарт X/Open, дающий программистам возможность создавать приложения, самостоятельно адаптирующиеся к различным национальным особенностям (символ денежной единицы, формат даты и времени, формат чисел, порядок сортировки, преобразование регистров символов и др.).
Предсказывающий регулятор запросов
В большинстве реляционных баз данных присутствует регулятор запросов (query governor) гарантирующий, что единичный запрос не будет выполняться слишком долго. По истечении заданного времени такой регулятор останавливает выполнение запроса.
DB2/400 же экономит системные ресурсы, используя предсказывающий регулятор запросов: если, выполнение запроса потребует столь много времени, что все равно будет прервано, то оно просто не начинается. Оптимизатор запросов предварительно анализирует способ, который будет применен при выполнении запроса для доступа к базе, и необходимое для этого время. Предсказанное время сравнивается с предельным временем запроса для данного пользователя. Если предсказанное время превосходит предельное, то пользователю посылается сообщение и тот может либо прекратить выполнение запроса, либо всетаки выдать запрос, отдавая себе отчет в том, что лимит будет исчерпан.
Повышение производительности базы данных
Для увеличения производительности различных операций в базе данных DB2/400 есть несколько механизмов. Например, команда "Explain" применяется для предсказания или просмотра характеристик исполнения запроса. Эта функция собирает информацию о том, как SQL используется в программе. Затем пользователь на основе полученной информации может вносить повышающие производительность изменения, как в базу данных, так и в сам запрос. Другие функции позволяют осуществлять операции выборки и вставки поблочно, то есть манипулировать массивами данных одной командой.
Кроме того, существуют и расширенные механизмы кэширования. Пользователи могут активизировать экспертный кэш, размер которого в памяти автоматически увеличивается или уменьшается на основании текущей загрузки, предсказанной активности базы данных и выделенных ресурсов. Экспертный кэш использует этого алгоритмы искусственного интеллекта. Пользователь может также назначить статический кэш, чтобы поместить в резидентную область памяти целую таблицу или ее часть.
Распределенные базы данных
AS/400 позволяет прикладной программе работать с базой данных как на локальной, так и на удаленной системе; местоположение данных для приложения прозрачно. Это означает, что приложению доступна обработка файла базы данных без информации о том, где он находится. Кроме того, части базы данных могут быть перенесены на другую систему без изменения прикладных программ.
Возможность доступа к базе данных на удаленной системе и доступа удаленных систем к данным AS/400 достигается благодаря реализации двух ключевых архитектур: DRDA (Distributed Relational Database Architecture) и DDM (Distributed Data Management).
Для доступа к удаленным данным интерфейс SQL использует DRDA. Сначала устанавливается связь с удаленной базой при помощи оператора SQL CONNECT, в котором указывается имя базы. Для поиска имени удаленной базы данных и определения системы, на которой она расположена, используется справочник на локальной системе. После установки соединения между двумя системами возможна посылка запросов SQL к удаленной базе данных. Менеджер базы данных на удаленной системе отвечает на запрос и возвращает ответ на локальную систему.
"Родной" интерфейс базы данных AS/400 использует архитектуру DDМ. Файл DDМ задает имя файла на удаленной системе и имя самой этой системы. Когда прикладной программе требуются удаленные данные, файл DDМ связывается с удаленной системой, после чего прикладная программа может работать с удаленным файлом. В отличие от DRDA, где обработка выполняется удаленной системой, использование DDМ означает, что обработка будет вестись на локальной системе. DDМ пересылает с удаленной системы на локальную все записи файла, тогда как DRDA — только результат уже выполненного запроса. Потенциально DRDA может обеспечить лучшую производительность приложений за счет меньших расходов на обслуживание коммуникаций.
Шлюзы к другим базам данных
AS/400 работает с базами данных, поддерживающими описанные архитектуры DRDA и DDМ, а также предоставляет интегрированный подход для доступа к другим базам данных. Это позволяет ей работать непосредственно с базой данных любого производителя на другом компьютере в сети. В дополнение к каталогу распределенной базы данных (Distributed Database Directory) в OS/400 присутствует менеджер драйверов (Distributed Database Driver Manager). Он работает с драйверами для других баз данных или файловых систем. Драйверы для баз данных Unix и ПК позволяют приложению AS/400 работать с этими базами так же, как и с любой базой DRDA.
Трансформация данных с помощью DataPropagator
Ранее, при обсуждении хранилищ данных мы упоминали о средствах трансформации данных, использующихся для их перемещения данных из оперативной базы в информационную. DataPropagator — одно из таких средств. Его можно использовать не только для хранилищ данных, но и для связи между любыми базами данных типа DB2.
В распределенной среде на разных компьютерах могут существовать множественные копии одного и того же файла базы данных. Изменение одной копии не отражается на другой немедленно, поэтому один и тот же файл на разных системах может быть в разной степени актуален. DataPropagator предоставляет механизм репликации изменений файла на все системы через некоторый, определяемый пользователем, интервал времени. Так как при этом используется технология репликации IBM, то изменения могут реплицироваться в сети на любую базу данных семейства DB2.
Соединение при помощи OptiConnect
Если компьютер работает не в сети, и сами данные, и средства их обработки располагаются на нем самом. Одиночная система AS/400 поддерживает очень большие, в том числе многопроцессорные, конфигурации, что вполне удовлетворяет нужды большинства крупных заказчиков. Однако, среди наших заказчиков есть такие, чьи требования к производительности и объемам данных превосходят возможности одиночной AS/400. Даже при работе компьютеров в сети накладные расходы на передачу данных ограничивают прирост производительности, который достигается путем распределения приложения между несколькими компьютерами. В этом случае может помочь OptiConnect. В "Система ввода-вывода" и "Версия 4" мы рассмотрим новейшие высокоскоростное межсистемное соединение — SAN. Но SAN поддерживается только линией AS/400е, так что OptiConnect еще будет какоето время использоваться для объединения AS/400.
OptiConnect — это продукт, позволяющий соединять друг с другом компьютеры AS/400 с помощью волоконной оптики для большей скорости обработки транзакций. Часто, крупные заказчики AS/400 отделяют обработку баз данных от обработки при ложений и размещают базу данных на серверной модели AS/400. В этом случае разные системы объединяются в кластер, в котором некоторые машины выделяются для обработки базы данных, а другие — для приложений.
OptiConnect использует DDM, но здесь важно отметить следующее. DDM на сети применяет коммуникационные протоколы на линиях связи (ЛВС). При таком способе связи обычны сильные шумы, и коммуникационный протокол вставляет в передачу слои избыточности и проверок, что приводит к замедлению передачи. Оптическая шина обеспечивает соединение, достаточно чистое, чтобы устранить большую часть избыточности, в результате производительность существенно возрастает. При использовании OptiConnect время, необходимое для доступа к базе на удаленной системе увеличивается лишь на 3 миллисекунды по сравнению с временем доступа к локальной базе данных, то есть удаленные диски работают почти со скоростью локальных.
Рост производительности в результате разделения приложений и базы данных зависит от множества факторов, например, от степени использования базы данных. Однако то, что кластер OptiConnect может объединять до 32 машин, позволяет уверенно говорить, что с помощью этого соединения реально создание очень больших конфигураций.
OptiConnect применяется не только для наращивания. Система на волоконно-оптических линиях может заменить существующие ЛВС, использующие DDM, что сделает сетевые соединения более быстрыми и надежными. Соединение с помощью OptiConnect дублированных систем позволяет создавать конфигурации с высоким уровнем доступности и возможностей восстановления важнейших приложений и данных.
А теперь пришла пора спуститься на уровень ниже и рассмотреть, как функционирует база данных "изнутри". Затем мы поговорим об использовании машинного индекса для поддержки уже рассмотренных нами операций.