рефераты бесплатно
 

МЕНЮ


Система управления базой данных объектов гражданской обороны для принятия решений в чрезвычайной ситуации (Диплом)

поддержка стандартов управления сетью SNMP.

Конечно, ни одна из существующих сетевых ОС не отвечает в полном

объеме перечисленным требованиям, поэтому выбор сетевой ОС, как правило,

осуществляется с учетом производственной ситуации и опыта. В таблице 2.1.

приведены основные характеристики популярных и доступных в настоящее время

сетевых ОС.

Таблица. 2.1. Основные характеристики сетевых ОС

|Novell |Специализированная операционная система, |

|NetWare |оптимизированная для работы в качестве файлового |

|4.1 |сервера и принт-сервера |

| |Ограниченные средства для использования в качестве |

| |сервера приложений: не имеет средств виртуальной |

| |памяти и вытесняющей многозадачности, а поддержка |

| |симметричного мультипроцесcирования отсутствовала до |

| |самого недавнего времени. Отсутствуют API основных |

| |операционных сред, используемых для разработки |

| |приложений, - UNIX, Windows, OS/2 |

| |Серверные платформы: компьютеры на основе процессоров|

| |Intel, рабочие станции RS/6000 компании IBM под |

| |управлением операционной системы AIX с помощью |

| |продукта NetWare for UNIX |

| |Поставляется с оболочкой для клиентов: DOS, |

| |Macintosh, OS/2, UNIX, Windows (оболочка для Windows |

| |NT разрабатывается компанией Novell в настоящее |

| |время, хотя Microsoft уже реализовала клиентскую |

| |часть NetWare в Windows NT) |

| |Организация одноранговых связей возможна с помощью ОС|

| |PersonalWare |

| |Имеет справочную службу NetWare Directory Services |

| |(NDS), поддерживающую централизованное управление, |

| |распределенную, полностью реплицируемую, |

| |автоматически синхронизируемую и обладающую отличной |

| |масштабируемостью |

| |Поставляется с мощной службой обработки сообщений |

| |Message Handling Service (MHS), полностью |

| |интегрированную (начиная с версии 4.1) со справочной |

| |службой |

| |Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, |

| |NetBIOS, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, frame relay, X.25 - с|

| |помощью продукта NetWare Connect (поставляется |

| |отдельно) |

| |Безопасность: аутентификация с помощью открытых |

| |ключей метода шифрования RSA; сертифицирована по |

| |уровню C2 |

| |Хороший сервер коммуникаций |

| |Встроенная функция компрессии диска |

| |Сложное обслуживание |

|Banyan |Серверные платформы: |

|VINES 6.0 |ENS for UNIX: работает на RISC-компьютерах под |

|и ENS |управлением SCO UNIX, HP-UX, Solaris, AIX ENS for |

|(Enterpris|NetWare: работает на Intel-платформах под управлением|

|e |NetWare 2.x, 3.x, 4.x |

|Network |VINES работает на Intel-платформах |

|Services) |Клиентские платформы: DOS, Macintosh, OS/2, UNIX, |

|6.0 |Windows for Workgroups, Windows NT |

| |Хороший сервер приложений: поддерживаются вытесняющая|

| |многозадачность, виртуальная память и симметричное |

| |мультипроцессирование в версии VINES и в ENS-версиях |

| |для UNIX. Поддерживаются прикладные среды UNIX, OS/2,|

| |Windows |

| |Поддержка одноранговых связей - отсутствует |

| |Справочная служба - Streettalk III, наиболее |

| |отработанная из имеющихся на рынке, с |

| |централизованным управлением, полностью |

| |интегрированная с другими сетевыми службами, |

| |распределенная, реплицируемая и автоматически |

| |синхронизируемая, отлично масштабируемая |

| |Согласованность работы с другими сетевыми ОС: |

| |хорошая; серверная оболочка работает в средах NetWare|

| |и UNIX; пользователи NetWare, Windows NT и LAN Server|

| |могут быть объектами справочной службы Streettalk III|

| | |

| |Служба сообщений - Intelligent Messaging, |

| |интегрирована с другими службами |

| |Поддерживаемые сетевые протоколы: VINES IP, TCP/IP, |

| |IPX/SPX, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, X.25 |

| |Служба безопасности: поддерживает электронную подпись|

| |(собственный алгоритм), избирательные права доступа, |

| |шифрацию; не сертифицирована |

| |Простое обслуживание |

| |Хорошо масштабируется |

| |Отличная производительность обмена данными между |

| |серверами, хуже - при обмене сервер-ПК |

|Microsoft |Серверные платформы: компьютеры на базе процессоров |

|Windows NT|Intel, |

|Server |PowerPC, DEC Alpha, MIPS |

|3.51 и 4.0|Клиентские платформы: DOS, OS/2, Windows, Windows for|

| |Workgroups, Macintosh |

| |Организация одноранговой сети возможна с помощью |

| |Windows NT Workstation и Windows for Workgroups |

| |Windows NT Server представляет собой отличный сервер |

| |приложений: он поддерживает вытесняющую |

| |многозадачность, виртуальную память и симметричное |

| |мультипроцессирование, а также прикладные среды DOS, |

| |Windows, OS/2, POSIX |

| |Справочные службы: доменная для управления учетной |

| |информацией пользователей (Windows NT Domain |

| |Directory service), справочные службы имен WINS и DNS|

| | |

| |Хорошая поддержка совместной работы с сетями NetWare:|

| |поставляется клиентская часть (редиректор) для |

| |сервера NetWare (версий 3.х и 4.х в режиме эмуляции |

| |3.х, справочная служба NDS поддерживается, начиная с |

| |версии 4.0), выполненная в виде шлюза в Windows NT |

| |Server или как отдельная компонента для Windows NT |

| |Workstation; недавно Microsoft объявила о выпуске |

| |серверной части NetWare как оболочки для Windows NT |

| |Server |

| |Служба обработки сообщений - Microsoft Mail |

| |NT - Microsoft Message Exchange, интегрированная с |

| |остальными службами Windows NT Server |

| |Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, |

| |NetBEUI, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, frame relay, X.25 - с|

| |помощью встроенной подсистемы Remote Access Server |

| |(RAS) |

| |Служба безопасности: мощная, использует избирательные|

| |права доступа и доверительные отношения между |

| |доменами; узлы сети, основанные на Windows NT Server,|

| |сертифицированы по уровню C2 |

| |Простота установки и обслуживания |

| |Отличная масштабируемость |

|IBM LAN |Серверные платформы: операционные системы MVS и VM |

|Server 4.0|для мейнфреймов; AS/400 с OS/400, рабочие станции |

| |RS/6000 с AIX, серверы Intel 486 или Pentium под OS/2|

| | |

| |Поставляется с оболочками для клиентов: DOS, |

| |Macintosh, OS/2, Windows, Windows NT, Windows for |

| |Workgroups |

| |Серверы приложений могут быть организованы с помощью |

| |LAN Server 4.0 в операционных средах MVS, VM, AIX, |

| |OS/2, OS/400. В среде OS/2 поддерживаются: |

| |вытесняющая многозадачность, виртуальная память и |

| |симметричное мультипроцессирование |

| |Организация одноранговых связей возможна с помощью ОС|

| |Warp Connect |

| |Справочная служба - LAN Server Domain, то есть основа|

| |на доменном подходе |

| |Поддерживаемые сетевые протоколы: TCP/IP, NetBIOS, |

| |Appletalk |

| |Безопасность - избирательные права доступа, система |

| |не сертифицирована |

| |Служба обработки сообщений - отсутствует |

| |Высокая производительность |

| |Недостаточная масштабируемость |

3. ВЫБОР БАЗЫ ДАННЫХ

3.1. Определение СУБД

Традиционных возможностей файловых систем недостаточно для построения

даже простых информационных систем из-за возникающих потребностей, которые

не покрываются возможностями систем управления файлами:

. поддержание логически согласованного набора файлов;

. обеспечение языка манипулирования данными;

. восстановление информации после разного рода сбоев;

. реально параллельная работа нескольких пользователей.

Можно считать, что если прикладная информационная система опирается на

некоторую систему управления данными, обладающую этими свойствами, то эта

система управления данными является системой управления базами данных

(СУБД).

3.2. Основные функции СУБД

Более точно, к числу функций СУБД принято относить следующие:

3.2.1. Непосредственное управление данными во внешней памяти

Эта функция включает обеспечение необходимых структур внешней памяти

как для хранения данных, непосредственно входящих в БД, так и для служебных

целей, например, для убыстрения доступа к данным в некоторых случаях

(обычно для этого используются индексы). В некоторых реализациях СУБД

активно используются возможности существующих файловых систем, в других

работа производится вплоть до уровня устройств внешней памяти. В развитых

СУБД пользователи в любом случае не обязаны знать, использует ли СУБД

файловую систему, и если использует, то как организованы файлы. В

частности, СУБД поддерживает собственную систему именования объектов БД.

3.2.2. Управление буферами оперативной памяти

СУБД обычно работают с БД значительного размера; по крайней мере этот

размер обычно существенно больше доступного объема оперативной памяти.

Понятно, что если при обращении к любому элементу данных будет

производиться обмен с внешней памятью, то вся система будет работать со

скоростью устройства внешней памяти. Практически единственным способом

реального увеличения этой скорости является буферизация данных в

оперативной памяти. При этом, даже если операционная система производит

общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для

целей СУБД, которая располагает гораздо большей информацией о полезности

буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается

собственный набор буферов оперативной памяти с собственной дисциплиной

замены буферов.

3.2.3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых

СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД

фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней

памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

Понятие транзакции необходимо для поддержания логической целостности БД.

Таким образом, поддержание механизма транзакций является обязательным

условием даже однопользовательских СУБД (если, конечно, такая система

заслуживает названия СУБД). Но понятие транзакции гораздо более важно в

многопользовательских СУБД.

То свойство, что каждая транзакция начинается при целостном состоянии

БД и оставляет это состояние целостным после своего завершения, делает

очень удобным использование понятия транзакции как единицы активности

пользователя по отношению к БД. При соответствующем управлении параллельно

выполняющимися транзакциями со стороны СУБД каждый из пользователей может в

принципе ощущать себя единственным пользователем СУБД (на самом деле, это

несколько идеализированное представление, поскольку в некоторых случаях

пользователи многопользовательских СУБД могут ощутить присутствие своих

коллег).

С управлением транзакциями в многопользовательской СУБД связаны важные

понятия сериализации транзакций и сериального плана выполнения смеси

транзакций. Под сериализаций параллельно выполняющихся транзакций

понимается такой порядок планирования их работы, при котором суммарный

эффект смеси транзакций эквивалентен эффекту их некоторого

последовательного выполнения. Сериальный план выполнения смеси транзакций -

это такой план, который приводит к сериализации транзакций. Понятно, что

если удается добиться действительно сериального выполнения смеси

транзакций, то для каждого пользователя, по инициативе которого образована

транзакция, присутствие других транзакций будет незаметно (если не считать

некоторого замедления работы по сравнению с однопользовательским режимом).

Существует несколько базовых алгоритмов сериализации транзакций. В

централизованных СУБД наиболее распространены алгоритмы, основанные на

синхронизационных захватах объектов БД. При использовании любого алгоритма

сериализации возможны ситуации конфликтов между двумя или более

транзакциями по доступу к объектам БД. В этом случае для поддержания

сериализации необходимо выполнить откат (ликвидировать все изменения,

произведенные в БД) одной или более транзакций. Это один из случаев, когда

пользователь многопользовательской СУБД может реально (и достаточно

неприятно) ощутить присутствие в системе транзакций других пользователей.

3.2.4. Журнализация

Одним из основных требований к СУБД является надежность хранения

данных во внешней памяти. Под надежностью хранения понимается то, что СУБД

должна быть в состоянии восстановить последнее согласованное состояние БД

после любого аппаратного или программного сбоя. Обычно рассматриваются два

возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно

трактовать как внезапную остановку работы компьютера (например, аварийное

выключение питания), и жесткие сбои, характеризуемые потерей информации на

носителях внешней памяти. Примерами программных сбоев могут быть: аварийное

завершение работы СУБД (по причине ошибки в программе или в результате

некоторого аппаратного сбоя) или аварийное завершение пользовательской

программы, в результате чего некоторая транзакция остается незавершенной.

Первую ситуацию можно рассматривать как особый вид мягкого аппаратного

сбоя; при возникновении последней требуется ликвидировать последствия

только одной транзакции.

Понятно, что в любом случае для восстановления БД нужно располагать

некоторой дополнительной информацией. Другими словами, поддержание

надежности хранения данных в БД требует избыточности хранения данных,

причем та часть данных, которая используется для восстановления, должна

храниться особо надежно. Наиболее распространенным методом поддержания

такой избыточной информации является ведение журнала изменений БД.

Журнал - это особая часть БД, недоступная пользователям СУБД и

поддерживаемая с особой тщательностью (иногда поддерживаются две копии

журнала, располагаемые на разных физических дисках), в которую поступают

записи обо всех изменениях основной части БД. В разных СУБД изменения БД

журнализуются на разных уровнях: иногда запись в журнале соответствует

некоторой логической операции изменения БД (например, операции удаления

строки из таблицы реляционной БД), иногда - минимальной внутренней операции

модификации страницы внешней памяти; в некоторых системах одновременно

используются оба подхода.

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал

(так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта

стратегия заключается в том, что запись об изменении любого объекта БД

должна попасть во внешнюю память журнала раньше, чем измененный объект

попадет во внешнюю память основной части БД. Известно, что если в СУБД

корректно соблюдается протокол WAL, то с помощью журнала можно решить все

проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат

транзакции. Строго говоря, для этого не требуется общесистемный журнал

изменений БД. Достаточно для каждой транзакции поддерживать локальный

журнал операций модификации БД, выполненных в этой транзакции, и

производить откат транзакции путем выполнения обратных операций, следуя от

конца локального журнала. В некоторых СУБД так и делают, но в большинстве

систем локальные журналы не поддерживают, а индивидуальный откат транзакции

выполняют по общесистемному журналу, для чего все записи от одной

транзакции связывают обратным списком (от конца к началу).

При мягком сбое во внешней памяти основной части БД могут находиться

объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и

могут отсутствовать объекты, модифицированные транзакциями, которые к

моменту сбоя успешно завершились (по причине использования буферов

оперативной памяти, содержимое которых при мягком сбое пропадает). При

соблюдении протокола WAL во внешней памяти журнала должны гарантированно

находиться записи, относящиеся к операциям модификации обоих видов

объектов. Целью процесса восстановления после мягкого сбоя является

состояние внешней памяти основной части БД, которое возникло бы при

фиксации во внешней памяти изменений всех завершившихся транзакций и

которое не содержало бы никаких следов незаконченных транзакций. Для того,

чтобы этого добиться, сначала производят откат незавершенных транзакций

(undo), а потом повторно воспроизводят (redo) те операции завершенных

транзакций, результаты которых не отображены во внешней памяти.

Для восстановления БД после жесткого сбоя используют журнал и архивную

копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту

начала заполнения журнала (имеется много вариантов более гибкой трактовки

смысла архивной копии). Конечно, для нормального восстановления БД после

жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к

сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12


ИНТЕРЕСНОЕ



© 2009 Все права защищены.