Интегрированная база данных
Защита данных
Итак, логические файлы позволяют защищать данные на уровне записей и полей. Мы увидели на примере, что поля можно защитить, просто не включая их в описание логического файла. Рассмотренные нами примеры просты, и в них не показана возможность выборки записей. Достичь защиты на уровне поля можно с помощью выборки и пропуска на уровне логического файла. В результате, пользователи получат доступ только к данным, удовлетворяющим критериям выборки.
Если у пользователя нет доступа к какомулибо файлу, то данный файл защищен. Если пользователь, не имеющий прав на доступ, например, к общему доходу, попробует запустить программу, использующую данный путь, то программа не будет работать. Все логические и физические файлы AS/400 — это системные объекты, и для доступа к ним необходимы соответствующие права. Защита данных обеспечивается путем комбинации логических файлов и компонента управления доступом операционной системы.
Мы можем предоставить конкретному пользователю следующие виды доступа к какому-либо физическому файлу:
- доступ ко всему файлу (с помощью средств управления доступом);
- разрешить некоторые типы операций с файлом, например, чтение, но не обновление (с помощью средств управления доступом);
- доступ к некоторым полям (с помощью логического файла);
- доступ к некоторым записям (с помощью логического файла).
Целостность и восстановление данных
Целостность данных, хранящихся в базе крайне важна. Между тем, при одновременном чтении и изменении данных многими пользователями существует вероятность их разрушения. База данных AS/400 предоставляет надежные средства обеспечения целостности данных.
Средства восстановления данных необходимы на тот случай, если данные все же разрушатся или станут недоступными. Часто полагают, что такое может произойти лишь вследствие аппаратных сбоев. В AS/400 есть даже несколько средств предотвращения порчи данных при аппаратном сбое — это так называемые средства обеспечения доступности (availability). Но хотя аппаратный сбой — наиболее распространенная причина порчи данных, программы также могут содержать ошибки, после которых требуется восстановление данных.
Подробное обсуждение целостности данных и их последующего восстановления потребовало бы отдельной книги. А мы сможем лишь кратко описать средства, предоставляемые базой данных AS/400, а также то, как некоторые из этих средств реализованы аппаратно.
Журнал
Журнал — это хронологическая запись изменений данных, предназначенная для восстановления предыдущей версии набора данных. В AS/400 поддерживаются журналы различных типов, в том числе журнал базы данных. При внесении изменения в запись журналируемого файла базы данных, в журнал помещается копия записи вместе с информацией, описывающей причину изменения.
Ведение записей поддерживается двумя объектами OS/400: журналом и приемником журнала. Журнал идентифицирует журналируемые объекты, а приемник содержит записи журнала. Для гарантии сохранения информации приемники журнала могут немедленно записываться на диск.
Помимо прочего, запись журнала содержит следующую информацию: имена файла, библиотеки и программы, относительный номер записи, дату и время изменения; а также идентификацию задания, пользователя и рабочей станции. Вместе с этой информацией в приемник журнала записывается копия измененной записи. AS/400 может также записать в журнал копию записи перед выполнением изменения.
Журналы базы данных используются для восстановления, как при сбоях системы, так и в случаях ошибок в программах. При аварийной остановке системы из-за аппаратного или программного сбоя файлы базы данных, для которых велся журнал, автоматически восстанавливаются при перезагрузке и будут обновлены в соответствии с информацией, записанной в приемниках журнала. Если программа ввела в файл, для которого ведется журнал, ошибочные данные, то AS/400 может восстановить такой файл как прямым, так и обратным способом. В первом случае сначала восстанавливается резервная версия файла, затем к нему применяются записи журнала, сделанные до того момента времени, когда произошел сбой. При обратном восстановлении ошибочные изменения удаляются из файла, но для этого в журнале должны быть копии записей как до, так и после изменения.
Системная защита пути доступа SMAPP
В прошлом пользователи AS/400 были вынуждены мириться с долгим временем перезагрузки после аварийной остановки: пути доступа9Те читатели, у которых понятие "пути доступа" вызывает затруднения, могут (с известной натяжкой) считать, что это примерно то же самое, что и индекс. — Прим. консультанта., открытые для обновления файла, должны были быть построены заново. Вспомните, что в "Объекты" мы упомянули возможность отложенной коррекции логического файла. Вследствие этого целостность логического файла при аварийной остановке может нарушиться. В зависимости от числа и размера открытых путей доступа по ключу, временной промежуток, требуемый для их восстановления, может быть значительным, для больших систем — несколько часов.
Как мы только что говорили, в AS/400 имеются средства журналирования, в том числе и для логических файлов. Если пользователь задействует ведение журнала для путей доступа, то время перезагрузки системы может быть значительно сокращено. Потенциальная трудность состоит в том, что пользователь должен сначала определить, для каких файлов следует вести журнал, оценить размер приемников журнала и дать команду активизации журналирования. Некоторые так и поступают, но, увы, таких пользователей меньшинство.
Для автоматического ведения журнала IBM разработала SMAPP (System-Managed Access Path Protection). Система сама вычисляет максимальное время, требуемое на восстановление путей доступа после сбоя и соответственно определяет необходимый объем журналирования путей доступа. Пользователь всегда может увеличить или уменьшить вычисленное системой время. Чем время меньше, тем больше системных ресурсов потребуется для ведения журнала. Таким образом, ведение журнала предполагает выбор между системными ресурсами, предназначенными для нормальной работы, и мерами предосторожности на случай аварийной перезагрузки.
После вычисления или задания пользователем максимально допустимого времени, система просматривает все пути доступа по ключу, существующие в базе данных; затем вычисляет общее время, требуемое для восстановления всех этих путей. Если время превышает максимально допустимое, то система автоматически начинает ведение журнала для отдельных путей доступа, чтобы гарантировать минимизацию времени на восстановление.
SMAPP использует специальную область ведения журнала, не требующую действий со стороны пользователя. Эта область — циклическая, то есть по достижении конца запись продолжается с начала. Система всегда поддерживает в этой области достаточное число записей.
Управление транзакциями
Иногда целостность данных может быть нарушена, особенно, если с записями физического файла работают несколько пользователей. Предположим, что один пользователь считывает запись, собираясь обновить какоето ее поле. Что произойдет, если то же самое поле записи одновременно обновляет и другой пользователь? Если второй пользователь изменит поле после того, как значение поля считано первым пользователем, нарушится ли целостность данных? К счастью, этого не произойдет, так как база данных обеспечивает защиту от параллельного обновления. Однако, при более сложных вариантах одновременного изменения нескольких записей, система не гарантирует автоматической защиты.
Допустим, что необходимо одновременно изменить несколько взаимосвязанных записей. Часто, для описания такой ситуации используется пример с банкоматом. Пользователь банковского терминала запускает транзакцию: вставляет в машину кредитную карту, вводит идентификационный код и выбирает тип транзакции. В результате этого клиентская запись считывается из базы данных центрального компьютера, который может располагаться на другом конце города или земного шара. Если клиент запрашивает выдачу наличности, то по содержимому записи проверяется, достаточен ли остаток денег на счете. Затем остаток уменьшается на затребованную величину и банкомату посылается команда на выдачу денег. Что если случилась поломка, и банкомат не может выдать наличность? Прежде чем эта неудавшаяся транзакция завершится, следует отменить изменение остатка на счете клиента. Средство, используемое для этого в AS/400, — управление транзакциями (commitment control).
Так как все изменения невозможно выполнить одновременно, система обязана защитить группу взаимосвязанных записей и не освобождать ее до тех пор, пока все изменения не будут внесены. Команда "Commit" позволяет изменить группу записей так, чтобы она выглядела как одна операция. Если нельзя выполнить какое-либо изменение, то вся группа изменений может быть отменена по команде "Rollback". Для этих операций управление транзакциями использует журналирование.
Триггеры
Триггер — действие, выполняемое автоматически всякий раз, когда содержимое физического файла изменяется — удобный способ связать одну операцию с другой. Триггеры — разновидность пользовательского средства обеспечения целостности базы данных, встроенная в определение файла. Часто изменение базы данных, например, добавление или удаление записи, требует некоторых дополнительных действий. В этих случаях триггер может запустить соответствующую программу. В других случаях, при изменении записи может требоваться запустить программу проверки нового значения поля записи: например, если при обновлении данных в файле инвентарной описи число учитываемых предметов упадет ниже допустимого уровня. Триггер для такого файла может при каждом обновлении запускать программу, проверяющую значение и отправляющее поставщику в случае необходимости дополнительный заказ.
При добавлении к физическому файлу триггера необходимо определить три атрибута. Первый — событие, приводящее к запуску триггера: вставка, обновление или удаление записи из файла. Второй атрибут задает, когда следует запустить триггер — до или после события. Наконец, третий атрибут задает программу запуска триггера. Обычно это пользовательская программа, написанная на любом ЯВУ, поддерживаемом AS/400.
Таким образом, для каждого физического файла можно назначить до шести триггеров: по два триггера для обновления, вставки и удаления записей, так чтобы один триггер запускался до события, второй — после. Триггеры добавляют командой "ADDPFTRG" (Add Physical File Trigger), а удаляют командой "RMVPFTRG" (Remove Physical File Trigger).
Ссылочная целостность
На практике данные одного физического файла часто зависят от данных другого. Если программа обновляет один файл независимо от другого, то целостность данных может быть нарушена. Часто ответственность за поддержку таких зависимостей ложится на прикладную программу. Ссылочная целостность — это средство, встроенное в базу данных AS/400 и позволяющее снять эту ответственность с прикладных программ.
Ссылочная целостность обеспечивает непротиворечивость данных двух физических файлов. Она определяет правила или ограничения, гарантирующие, что каждой записи в одном файле будет соответствовать запись в другом. Программа не сможет изменить запись, если такое изменение нарушит заданные правила.
В качестве простого примера предположим, что у нас имеется главный файл, содержащий запись для каждого клиента. В качестве ключа в этом файле используется ID клиента. Внутри базы данных имеются также другие файлы, использующие в качестве ключа ID клиента. В подобных случаях целесообразно, используя ссылочную целостность, ввести такое ограничение для каждого из зависимых файлов, которое не позволит прикладным программам добавлять в файлы ID клиента, если такого ID нет в главном файле. Очевидно, что могут быть и гораздо более сложные сценарии реализации ссылочной целостности.
Дисковые системы высокой доступности
Диски — это механические устройства, а механические устройства могут ломаться. Стандартная форма защиты для любой вычислительной системы — периодическое сохранение данных с дисков на другой носитель, обычно, ленту. Эта резервная копия содержит слепок базы данных или некоторой ее части на определенный момент времени. Если с данными на диске чтото произошло, то копия данных на ленте поможет восстановить потерянную информацию.
Ранее мы рассматривали прямое восстановление базы данных с помощью журнала. Первым шагом этого процесса было восстановление резервной копии данных. Затем к этой копии применяются записи журнала, сделанные с момента ее создания, до тех пор, пока база данных не будет восстановлена.
У AS/400 мощные средства сохранения/восстановления. Но иногда для восстановления данных при сбое диска требуется неприемлемо большое время. Обычно, в процессе восстановления система недоступна пользователям. Это может доставить большие затруднения, особенно, если необходимо физически заменить диск перед восстановлением данных. Альтернатива такой процедуры — дисковая подсистема, которая может так переносить сбои диска, чтобы система не становилась недоступной. AS/400 поддерживает два типа защиты дисков для обеспечения высокой доступности: зеркалирование дисков и дисковые массивы.
Зеркалирование требует чтобы у каждого диска был "напарник". Всякий раз по команде записи на диск все данные дублируются на оба парных диска. Если один из дисков сломается, то доступ к данным со второго диска даст системе возможность продолжать работать. Для еще большей надежности диски в паре могут быть подключены к разным дисковым контроллерам, на разных процессорах ввода-вывода и на разных шинах. Путем подключения зеркальных дисков к оптической шине ввода вывода их можно разместить даже в другом помещении (cтруктура и взаимодействие компонентов вводавывода AS/400 описаны в "Система ввода-вывода" ). Зеркалирование обеспечивает наивысший уровень надежности, но дороговата, поскольку требует полного дублирования дисков.
Другой подход — использование дисковых массивов. В этом случае диски объединяются в наборы, и данные записываются на все диски набора. Сектор — это фиксированный блок данных на диске. Страница памяти обычно хранится в нескольких секторах диска, и операция записи распределяет сектора по всем дискам набора.
Добавление к массиву избыточного диска позволяет обнаруживать место сбоя и автоматически восстанавливать потерянную информацию. При этом используется операция "исключающего или" (XOR) над данными всех секторов набора — любой из операндов может быть восстановлен путем выполнения операции XOR над результатом и другим операндом. Данная технология известна как RAID (redundant arrays of inexpensive disks).
Пример операции XOR показан на рисунке 6.3. Результат операции — "истина" (то есть, 1) — достигается тогда и только тогда, когда один из операндов "истина" (1), а другой — "ложь" (0). В противном случае, если оба операнда являются "истиной" или оба "ложью", значением операции является "ложь" (то есть 0).
Операция XOR выполняется с данными соответствующих секторов на всех дисках, а ее результат операции сохраняется в секторе на избыточном диске. В случае сбоя диска, данные испорченного сектора восстанавливаются путем операции XOR над данными соответствующих секторов всех исправных дисков набора. Чтобы избежать перегрузки одного из дисков, контрольная информация (результаты операций XOR) распределяется на несколько дисков входящих в массив. Таким образом, любой диск содержит часть данных базы и часть результатов XOR.
Целостность данных, восстановление и надежность — важнейшие характеристики любой вычислительной системы. В этом разделе мы рассмотрели лишь основные аспекты этой поддержки.