Фрэнк Солтис - Основы AS/400

Другой подход — использование дисковых массивов. В этом случае диски объединяются в наборы, и данные записываются на все диски набора. Сектор — это фиксированный блок данных на диске. Страница памяти обычно хранится в нескольких екторах диска, и операция записи распределяет сектора по всем дискам набора.

Добавление к массиву избыточного диска позволяет обнаруживать место сбоя и втоматически восстанавливать потерянную информацию. При этом используется перация <���исключающего или> (XOR) над данными всех секторов набора . любой з операндов может быть восстановлен путем выполнения операции XOR над результатом и другим операндом. Данная технология известна как RAID (redundant arrays of nexpensive disks).

Пример операции XOR показан на рисунке 6.3. Результат операции . <���истина> то есть, 1) . достигается тогда и только тогда, когда один из операндов <���истина> (1), другой . <���ложь> (0). В противном случае, если оба операнда являются <���истиной> ли оба <���ложью>, значением операции является <���ложь> (то есть 0).

Рисунок 6.3. Пример операции исключающее ИЛИ

Операция XOR выполняется с данными соответствующих секторов на всех дисках, а ее результат операции сохраняется в секторе на избыточном диске. В случае сбоя диска, данные испорченного сектора восстанавливаются путем операции XOR над данными соответствующих секторов всех исправных дисков набора. Чтобы избежать перегрузки одного из дисков, контрольная информация (результаты операций XOR) распределяется на несколько дисков входящих в массив. Таким образом, любой диск содержит часть данных базы и часть результатов XOR.

Целостность данных, восстановление и надежность — важнейшие характеристики любой вычислительной системы. В этом разделе мы рассмотрели лишь основные аспекты этой поддержки.

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 же экономит системные ресурсы, используя предсказывающий регулятор запросов: если, выполнение запроса потребует столь много времени, что все равно будет прервано, то оно просто не начинается. Оптимизатор запросов предварительно анализирует способ, который будет применен при выполнении запроса для доступа к базе, и необходимое для этого время. Предсказанное время сравнивается с предельным временем запроса для данного пользователя. Если предсказанное время превосходит предельное, то пользователю посылается сообщение и тот может либо прекратить выполнение запроса, либо все-таки выдать запрос, отдавая себе отчет в том, что лимит будет исчерпан.