Основы AS/400
Шрифт:
Ссылочная целостность
На практике данные одного физического файла часто зависят от данных другого. Если программа обновляет один файл независимо от другого, то целостность данных может быть нарушена. Часто ответственность за поддержку таких зависимостей ложится на прикладную программу. Ссылочная целостность — это средство, встроенное в базу данных AS/400 и позволяющее снять эту ответственность с прикладных программ.
Ссылочная целостность обеспечивает непротиворечивость данных двух физических файлов. Она определяет правила или ограничения, гарантирующие, что каждой записи в одном файле будет соответствовать запись в другом.
В качестве простого примера предположим, что у нас имеется главный файл, содержащий запись для каждого клиента. В качестве ключа в этом файле используется ID клиента. Внутри базы данных имеются также другие файлы, использующие в качестве ключа ID клиента. В подобных случаях целесообразно, используя ссылочную целостность, ввести такое ограничение для каждого из зависимых файлов, которое не позволит прикладным программам добавлять в файлы ID клиента, если такого ID нет в главном файле. Очевидно, что могут быть и гораздо более сложные сценарии реализации ссылочной целостности.
Дисковые системы высокой доступности
Диски — это механические устройства, а механические устройства могут ломаться. Стандартная форма защиты для любой вычислительной системы — периодическое сохранение данных с дисков на другой носитель, обычно, ленту. Эта резервная копия содержит слепок базы данных или некоторой ее части на определенный момент времени. Если с данными на диске что-то произошло, то копия данных на ленте поможет восстановить потерянную информацию.
Ранее мы рассматривали прямое восстановление базы данных с помощью журнала. Первым шагом этого процесса было восстановление резервной копии данных. Затем к этой копии применяются записи журнала, сделанные с момента ее создания, до тех пор, пока база данных не будет восстановлена.
У AS/400 мощные средства сохранения/восстановления. Но иногда для восстановления данных при сбое диска требуется неприемлемо большое время. Обычно, в процессе восстановления система недоступна пользователям. Это может доставить большие затруднения, особенно, если необходимо физически заменить диск перед восстановлением данных. Альтернатива такой процедуры — дисковая подсистема, которая может так переносить сбои диска, чтобы система не становилась недоступной. AS/400 поддерживает два типа защиты дисков для обеспечения высокой доступности: зеркалирование дисков и дисковые массивы.
Зеркалирование требует чтобы у каждого диска был «напарник». Всякий раз по команде записи на диск все данные дублируются на оба парных диска. Если один из дисков сломается, то доступ к данным со второго диска даст системе возможность продолжать работать. Для еще большей надежности диски в паре могут быть подключены к разным дисковым контроллерам, на разных процессорах ввода-вывода и на разных шинах. Путем подключения зеркальных дисков к оптической шине ввода-вывода их можно разместить даже в другом помещении (структура и взаимодействие компонентов ввода-вывода AS/400 описаны в главе 10). Зеркалирование обеспечивает наивысший уровень надежности, но дороговата, поскольку требует полного дублирования дисков.
Другой подход — использование дисковых массивов. В этом случае диски объединяются в наборы, и данные записываются на все диски набора. Сектор — это фиксированный блок данных на диске. Страница памяти обычно хранится в нескольких екторах диска, и операция записи распределяет сектора по всем дискам набора.
Добавление к массиву избыточного диска позволяет обнаруживать место сбоя и втоматически восстанавливать потерянную информацию. При этом используется перация <исключающего или> (XOR) над данными всех секторов набора . любой з операндов может быть восстановлен путем выполнения операции XOR
Пример операции 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, дающий программистам возможность создавать приложения, самостоятельно адаптирующиеся к различным национальным особенностям (символ денежной единицы, формат даты и времени, формат чисел, порядок сортировки, преобразование регистров символов и др.).