- •Содержание
- •1. Общее представление об корпоративной информационной системе
- •2. Общая классификация архитектур информационных приложений
- •3. Средства и методологии проектирования, разработки и сопровождения файл-серверных приложений
- •4. Средства и методологии проектирования, разработки и сопровождения клиент-серверных приложений
- •5. Средства и методологии проектирования, разработки и сопровождения Intranet-приложений
- •6. Информационные приложения, основанные на использовании "складов данных" (DataWarehousing)
- •7. Глобально распределенные кис
- •Введение
- •1. Общее представление об информационной системе
- •1.1. Специфика информационных программных систем
- •1.2. Этапы развития кис
- •1.3. Задачи информационных систем
- •1.4. Проблемы построения кис
- •1.5. Требования к техническим средствам, поддерживающим кис
- •2. Общая классификация архитектур информационных приложений
- •2.1. Файл-серверные приложения
- •2.2. Клиент-серверные приложения
- •2.3. Intranet-приложения
- •2.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных
- •2.5. Интегрированные распределенные приложения
- •3. Средства и методологии проектирования, разработки и сопровождения файл-серверных приложений
- •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. Рекомендации по использованию инструментальных средств разработки файл-серверных приложений
- •4. Средства и методологии проектирования, разработки и сопровождения клиент-серверных приложений
- •4.1. Базовые средства построения ис в архитектуре "клиент-сервер"
- •4.1.1. Вызовы удаленных процедур
- •4.1.1.1. Протокол rpc и его реализации
- •4.1.1.2. Протокол xdr
- •4.1.2. Стек протоколов tcp/ip как основа rpc
- •Семейство протоколов tcp/ip
- •4.2. Серверы баз данных как базовая системная поддержка информационной системы в архитектуре "клиент-сервер"
- •4.2.1. Понятие сервера баз данных
- •4.2.2. Базовая архитектура сервера баз данных
- •4.2.2.1. Непосредственное управление данными во внешней памяти
- •4.2.2.2. Управление буферами оперативной памяти
- •4.2.2.3. Управление транзакциями
- •4.2.2.4. Журнализация
- •4.2.2.5. Языки бд
- •4.2.3. Основные производители серверов баз данных и характеристика их продуктов
- •4.2.3.1. История и серверные продукты компании Oracle
- •4.2.3.2. История и серверные продукты компании Informix
- •4.2.3.3. Серверные продукты компании Sybase
- •4.2.3.4. Линия серверных продуктов ca-OpenIngres компании Computer Associates
- •4.2.3.5. Серверные продукты линии db2 компании ibm
- •5. Средства и методологии проектирования, разработки и сопровождения Intranet-приложений
- •5.1. Основные понятия Intranet
- •5.2. Языки и протоколы
- •5.2.1. Html
- •5.2.2. Http
- •5.2.2.1. Форма запроса клиента
- •5.2.2.2. Методы доступа
- •5.2.2.3. Ответ сервера
- •5.2.2.4. Защита сервера от несанкционированного доступа
- •5.3. Серверы Intranet
- •5.3.1.1. Типы информационных ресурсов
- •5.3.1.2. Протокол ftp
- •5.3.1.3. Сервер протокола - программа ftpd
- •5.3.2.1. Структура базы данных сервера www
- •5.3.3. Поисковые серверы
- •5.3.3.1. Архитектура современных информационно-поисковых систем World Wide Web
- •5.3.3.2. Информационные ресурсы и их представление в информационно-поисковой системе
- •5.4. Язык программирования Java
- •5.4.1. Мобильность Java
- •5.4.2. Безопасность, Java и Intranet
- •5.4.3. Миграция от средства программирования интерфейсов электронных устройств
- •5.5. Возможные архитектуры Intranet-приложений
- •5.5.1. Решения, ориентированные на клиентскую часть системы
- •5.5.2. Трехзвенные архитектуры (Web-ориентированные)
- •5.5.3. Решения, основанные на использовании языка Java
- •6. Информационные приложения, основанные на использовании "складов данных" (DataWarehousing)
- •6.1. Проблема интеграции данных
- •6.2. Подходы и имеющиеся решения
- •6.2.1. Компания ibm
- •6.2.2. Oracle
- •6.2.3. Hewlett Packard
- •6.2.4. Sybase
- •6.2.5. Informix Software
- •6.2.7. Sas Institute
- •6.2.8. Software ag
- •7. Глобально распределенные кис
- •7.1. Проблема "унаследованных систем" (Legacy Systems)
- •7.2. Объектный подход
- •7.3. Предложения omg и odmg
- •7.4. Промышленный стандарт corba
4.2.2.4. Журнализация
Одним из основных требований к СУБД является надежное хранение данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежного хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал- это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда запись в журнале соответствует минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций.
Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.