26814

Модели систем. Алгоритм разрешения имен в службе DNS

Шпаргалка

Информатика, кибернетика и программирование

Журнализация и буферизация Журнализация изменений тесно связана не только с управлением транзакциями но и с буферизацией страниц базы данных в оперативной памяти. Если бы запись об изменении базы данных которая должна поступить в журнал при выполнении любой операции модификации базы данных реально немедленно записывалась бы во внешнюю память это привело бы к существенному замедлению работы системы. Проблема состоит в выработке некоторой общей политики выталкивания которая обеспечивала бы возможность восстановления состояния базы данных...

Русский

2013-08-18

73.86 KB

11 чел.

Билет 23

2. Модели систем.

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

модель (лат. modulus — мера) — это объект-заместитель объекта-оригинала, обеспечивающий изучение некоторых свойств оригинала

Можно классифицировать модели системы следующим образом:

· по характеру отображаемого моделью объекта – технические, биологические и др.;

· по используемому аппарату научного описания – математические, физические, химические и др.;

· по виду формализованного аппарата представления системы – детерминированные и стохастические;

· по сложности структуры и поведения – простые и сложные; и т.д.

Для изучения систем применяют также качественные и количественные модели (методы описания систем).

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

Феноменологические модели используются для качественного описания физических или иных процессов, когда точные соотношения неизвестны или слишком сложны для применения. Такие приближенные или осредненные модели обычно обоснованы физически и содержат входные данные, полученные из эксперимента или более фундаментальных теорий. Феноменологическая модель основывается на качественном понимании физической ситуации.

    В настоящее время к числу задач, решаемых теорией систем, относятся:

· определение общей структуры системы;

· организация взаимодействия между подсистемами и элементами;

· учет влияния внешней среды;

· выбор оптимальной структуры системы;

· выбор оптимальных алгоритмов функционирования системы.

3.

4.Алгоритм разрешения имен в службе DNS. (8)

Служба доменных имен работает как распределенная база, данные которой распределены по DNS-серверам.

Сервис DNS строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера DNS-сервер.  

Например, когда мы хотим обратиться к серверу ipm.kstu.ru, ваш браузер, используя resolver, поступает следующим образом:

  1. ищет запись ipm.kstu.ru в файле hosts, если не находит, то,
  2. посылает запрос на известный DNS-кэширующий сервер (как правило, локальный), если на этом сервере  запись не найдена, то,
  3. сервер DNS-кэширующий обращается к DNS-ROOT серверу с запросом адреса DNS сервера отвечающего за домен первого уровня ru, если получает адрес, то,
  4. сервер DNS-кэширующий обращается к DNS серверу, отвечающего за домен первого уровня ru, с запросом адреса DNS сервера отвечающего за домен второго уровня kstu.ru, если получает адрес, то,
  5. сервер DNS-кэширующий посылает запрос на DNS сервер, отвечающий за домен второго уровня kstu.ru, если получает адрес, то,
  6. сервер DNS-кэширующий адрес кэширует и передает клиенту
  7. клиент обращается по IP адресу - 195.208.44.20

На схеме это выглядит так:

Алгоритм разрешения имен.

5. Структурно-функциональное моделирование (назначение, методология SADT , графически язык, IDEF 0 - базовые принципы).

1) Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Основное назначение функциональной модели, реализуемой с помощью ПО BPWin (IDEF0, SADT):

· описания существующих бизнес процессов на предприятии (так называемая модель AS-IS);

· и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE)

· проектирование информационных систем предприятий ( Erwin ).

2) Методология SADT разработана Дугласом Россом более 20 лет назад ( Structured Analysis and Design Technique ). На ее основе разработана, в частности, известная методология IDEF0 (ICAM Definition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

Книга Дэвида А.Марка и Клемента МакГоуэна "Методология структурного анализа и проектирования SADT ", издательство Мета Технология, 1993

3) Графический язык IDEF0 удивительно прост и гармоничен. В его основе лежат два основных понятия:

Первым из них является понятие функционального блока ( Activity Box ). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.

· Верхняя сторона имеет значение “Управление” ( Control ); (стрелки сверху, - данные на основании чего выполняется данный процесс - законы, стандарты, приказы и т.д.);

· Левая сторона имеет значение “Вход” ( Input ); (стрелки слева, - данные или объекты, потребляемые или изменяемые процессом);

· Правая сторона имеет значение “Выход” ( Output ); (стрелки справа, - основные результаты деятельности процесса, конечные продукты);

· Нижняя сторона имеет значение “Механизм” ( Mechanism ); (стрелки снизу, означающие, посредством чего или с помощью кого реализуется данный процесс - материальные и/или кадровые ресурсы, необходимые для процесса).

· Вызов - специальная стрелка, указывающая на другую модель работы.

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги ( Arrow ). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, (какие дуги?) одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.

4) В IDEF0 реализованы три базовых принципа моделирования процессов:

· принцип контекста ;

· принцип функциональной декомпозиции;

· принцип ограничения сложности.

Принцип контекстной диаграммы. На первом этапе проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма). На этой диаграмме отображается только один блок с интерфейсными дугами, простирающимися за пределы рассматриваемой области - главная бизнес функция моделируемой системы. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции . Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Принцип ограничения сложности. При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести (кроме первой). Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.

6. Журнализация и буферизация

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

Если бы запись об изменении базы данных, которая должна поступить в журнал при выполнении любой операции модификации базы данных, реально немедленно записывалась бы во внешнюю память, это привело бы к существенному замедлению работы системы. Поэтому записи в журнале тоже буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями.

Проблема состоит в выработке некоторой общей политики выталкивания, которая обеспечивала бы возможность восстановления состояния базы данных после сбоев.

Проблема не возникает при индивидуальных откатах транзакций, поскольку в этих случаях содержимое оперативной памяти не утрачено и можно пользоваться содержимым как буфера журнала, так и буферов страниц базы данных. Но если произошел мягкий сбой и содержимое буферов утрачено, для проведения восстановления базы данных необходимо иметь некоторое согласованное состояние журнала и базы данных во внешней памяти.

Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) — «пиши сначала в журнал» и состоит в том, что если требуется записать во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать запись во внешнюю память журнала транзакций записи о его изменении.

Другими словами, если во внешней памяти базы данных находится некоторый объект базы данных, по отношению к которому выполнена операция модификации, то во внешней памяти журнала обязательно находится запись, соответствующая этой операции. Обратное неверно, то есть если во внешней памяти журнале содержится запись о некоторой операции изменения объекта базы данных, то сам измененный объект может отсутствовать во внешней памяти базы данных.

Дополнительное условие на выталкивание буферов накладывается тем требованием, что каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти. Какой бы сбой не произошел, система должна быть в состоянии восстановить состояние базы данных, содержащее результаты всех зафиксированных к моменту сбоя транзакций.

Простым решением было бы выталкивание буфера журнала, за которым следует массовое выталкивание буферов страниц базы данных, изменявшихся данной транзакцией. Довольно часто так и делают, но это вызывает существенные накладные расходы при выполнении операции фиксации транзакции.

Оказывается, что минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией. При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце транзакции.

Рассмотрим теперь, как можно выполнять операции восстановления базы данных в различных ситуациях, если в системе поддерживается общий для всех транзакций журнал с общей буферизацией записей, поддерживаемый в соответствии с протоколом WAL.

Индивидуальный откат транзакции

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

Итак, индивидуальный откат транзакции (еще раз подчеркнем, что это возможно только для незакончившихся транзакций) выполняется следующим образом:

Выбирается очередная запись из списка данной транзакции.

Выполняется противоположная по смыслу операция: вместо операции INSERT выполняется соответствующая операция DELETE, вместо операции DELETE вы полняется INSERT и вместо прямой операции UPDATE обратная операция UPDATE, восстанавливающая предыдущее состояние объекта базы данных.

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

При успешном завершении отката в журнал заносится запись о конце транзакции. С точки зрения журнала такая транзакция является зафиксированной.

Восстановление после мягкого сбоя

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

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

Будем считать, что в журнале отмечаются точки физической согласованности базы данных — моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Немного позже мы рассмотрим, как можно достичь физической согласованности. Назовем такие точки tpc (time of physical consistency) — точками физического согласования.

Тогда к моменту мягкого сбоя возможны следующие состояния транзакций:

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

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

транзакция получила и выполнила команду отката ROLLBACK;

транзакция не завершена.

Физическая согласованность базы данных

Каким же образом можно обеспечить наличие точек физической согласованности базы данных, то есть как восстановить состояние базы данных в момент tpc? Для этого используются два основных подхода: подход, основанный на использовании теневого механизма, и подход, в котором применяется журналиаация постраничных изменений базы данных.

При открытии файла таблица отображения номеров его логических блоков в адреса физических блоков внешней памяти считывается в оперативную память. При модификации любого блока файла во внешней памяти выделяется новый блок. При этом текущая таблица отображения (в оперативной памяти) изменяется, а теневая — сохраняется неизменной. Если во время работы с открытым файлом происходит сбой, во внешней памяти автоматически сохраняется состояние файла до его открытия. Для явного восстановления файла достаточно повторно считать в оперативную память теневую таблицу отображения.

Общая идея теневого механизма показана на рис. 11.4.

 

Рис. 11.4. Использование теневых таблиц отображения информации

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

Восстановление к tpc происходит мгновенно: текущая таблица отображения заменяется на теневую (при восстановлении просто считывается теневая таблица отображения). Все проблемы восстановления решаются, но за счет слишком большого перерасхода внешней памяти. В пределе может потребоваться вдвое больше внешней памяти, чем реально нужно для хранения базы данных. Теневой механизм — это надежное, но слишком грубое средство. Обеспечивается согласованное состояние внешней памяти в один общий для всех объектов момент времени. На самом деле достаточно иметь совокупность согласованных наборов страниц, каждому из которых может соответствовать свои временные отсчеты.

Для выполнения такого более слабого требования наряду с логической журнализацией операций изменения базы данных производится журнализация постраничных изменений. Первый этап восстановления после мягкого сбоя состоит в постраничном откате незакончившихся логических операций. Подобно тому как это делается с логическими записями по отношению к транзакциям, последней записью о постраничных изменениях от одной логической операции является запись о конце операции.

В этом подходе имеются два метода решения проблемы. При использовании первого метода поддерживается общий журнал логических и страничных операций. Естественно, наличие двух видов записей, интерпретируемых абсолютно по-разному, усложняет структуру журнала. Кроме того, записи о постраничных изменениях, актуальность которых носит локальный характер, существенно (и не очень осмысленно) увеличивают журнал.

Поэтому все более популярным становится поддержание отдельного (короткого) журнала постраничных изменений. Такая техника применяется, например, в известном продукте Informix Online.

Предположим, что некоторым способом удалось восстановить внешнюю память базы данных к состоянию на момент времени tpc (как это можно сделать — немного позже). Тогда:

Для транзакции Т1 никаких действий производить не требуется. Она закончилась до момента tpc, и все ее результаты отражены во внешней памяти базы данных.

Для транзакции Т2 нужно повторно выполнить оставшуюся часть операций (redo). Действительно, во внешней памяти полностью отсутствуют следы операций, которые выполнялись в транзакции Т2 после момента tpc. Следовательно, повторная прямая интерпретация операций Т2 корректна и приведет к логически согласованному состоянию базы данных (поскольку транзакция Т2 успешно завершилась до момента мягкого сбоя, в журнале содержатся записи обо всех изменениях, произведенных этой транзакцией).

Для транзакции ТЗ нужно выполнить в обратном направлении первую часть операций (undo). Действительно, во внешней памяти базы данных полностью отсутствуют результаты операций ТЗ, которые были выполнены после момента tpc. С другой стороны, во внешней памяти гарантированно присутствуют результаты операций ТЗ, которые были выполнены до момента tpc. Следовательно, обратная интерпретация операций ТЗ корректна и приведет к согласованному состоянию базы данных (поскольку транзакция ТЗ не завершилась к моменту мягкого сбоя, при восстановлении необходимо усхранить все последствия ее выполнения).

Для транзакции Т4, которая успела начаться после момента tpc и закончиться до момента мягкого сбоя, нужно выполнить полную повторную прямую интерпретацию операций (redo).

Наконец, для начавшейся после момента tpc и не успевшей завершиться к моменту мягкого сбоя транзакции Т5 никаких действий предпринимать не требуется. Результаты операций этой транзакции полностью отсутствуют во внешней памяти базы данных.

Восстановление после жесткого сбоя

Понятно, что для восстановления последнего согласованного состояния базы данных после жесткого сбоя журнала изменений базы данных явно недостаточно. Основой восстановления в этом случае являются журнал и архивная копия базы данных.

Восстановление начинается с обратного копирования базы данных из архивной копии. Затем для всех закончившихся транзакций выполняется redo, то есть операции повторно выполняются в прямом порядке.

Более точно, происходит следующее:

по журналу в прямом направлении выполняются все операции;

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

На самом деле, поскольку жесткий сбой не сопровождается утратой буферов оперативной памяти, можно восстановить базу данных до такого уровня, чтобы можно было продолжить даже выполнение незакончившихся транзакций. Но обычно это не делается, потому что восстановление после жесткого сбоя — это достаточно длительный процесс.

Хотя к ведению журнала предъявляются особые требования по части надежности, в принципе возможна и его утрата. Тогда единственным способом восстановления базы данных является возврат к архивной копии. Конечно, в этом случае не удастся получить последнее согласованное состояние базы данных, но это лучше, чем ничего.

Последний вопрос, который мы коротко рассмотрим, относится к производству архивных копий базы данных. Самый простой способ — архивировать базу данных при переполнении журнала. В журнале вводится так называемая «желтая зона», при достижении которой образование новых транзакций временно блокируется. Когда все транзакции закончатся и, следовательно, база данных придет в согласованное состояние, можно производить ее архивацию, после чего начинать заполнять журнал заново.

Можно выполнять архивацию базы данных реже, чем переполняется журнал. При переполнении журнала и окончании всех начатых транзакций можно архивировать сам журнал. Поскольку такой архивированный журнал, по сути дела, требуется только для воссоздания архивной копии базы данных, журнальная информация при архивации может быть существенно сжата.


 

А также другие работы, которые могут Вас заинтересовать

17474. Географические информационные системы (ГИС) 27 KB
  Лекция Географические информационные системы ГИС Важным специфическим классом АИС специализирующихся на определенном виде информации в основном графической являются географические системы ГИС. Согласно некоторым оценкам 80 всех существующих данных являю
17475. Гипертекстовые АИС 107.5 KB
  Лекция Гипертекстовые АИС Слово гипертекст hypertext буквально переводится как нелинейный текст nonlinear text. Элемент гипертекста узел дискретный объект. Узлы между которыми возможен переход считаются смежными а сама возможность перехода называется связью. Для описан...
17476. Документальный информационный поиск в сети Интернет 40.5 KB
  Лекция №9 Документальный информационный поиск в сети Интернет Информационнопоисковые системы Интернет могут быть разделены по функциональноструктурному принципу на следующие классы: полностью распределенные системы где реализуются принципы распределенных вы
17477. Конструирование системы упражнений по теме Геометрическая оптика на основе обобщения опыта работы учителя физики лицея №40 Морозовой Н.В 2.46 MB
  Педагогический опыт как результат практики является критерием истины: он либо подтверждает либо отвергает те или иные нововведения. Этот опыт как правило результат творческих поисков педагогов в нем сливаются воедино творческое новаторское и в то же время традиционное начала.
17478. Автоматизированные информационные системы (АИС), структура и классификация 127 KB
  Лекция №2 Автоматизированные информационные системы АИС структура и классификация АИС комплекс автоматизированных информационных технологий предназначенный для информационного обслуживания организованного непрерывного технологического процесса подготовк...
17479. Организационное обеспечение и пользователи АИС 36.5 KB
  Организационное обеспечение и пользователи АИС В состав организационного обеспечения АИС принято включать структурные подразделения организации осуществляющие управление технологическими процессами и поддержку работоспособности системы а также совокупность док
17480. Некоторые поисковые возможности и характеристики систем Yandex и Rambler 392.5 KB
  Некоторые поисковые возможности и характеристики систем Yandex и Rambler. Стандартный поиск Yandex. Рассмотрим общий вид стандартной поисковой формы Yandex рис. 2.20. 1. Основная поисковая форма. Главный ее элемент строка запроса. При желании можно искать только в результатах пр
17481. Структура и классификация автоматизированных информационных систем 103.5 KB
  Структура и классификация автоматизированных информационных систем Цели изучения темы: общеобразовательная прочное усвоение знаний о составе и структуре АИС; развивающая развитие логического мышления; воспитательная формирование представлений об осн...
17482. АИС. Автоматизированные информационные системы 114 KB
  Введение. Ни одно современное предприятие не обходится без систем сбора и обработки информации. Чем больше стадий производства чем оно сложнее чем больше и разнообразнее спектр производимых продаваемых изделий или предлагаемых услуг тем больше потребность в автомат...