Журнализация изменений бд

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

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

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

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

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

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

• Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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

3.32 МОВА ЗАПИТІВ SQL. КОМАНДА SELECT І СТРУКТУРА ЗАПИТІВ НА ВИБІРКУ.

Язык SQL – Structured Query Language – был разработан в 1974 г. в ходе работы над System R. В период становления технологий баз данных SQL был не единственным и, возможно, не самым лучшим языком запросов реляционных баз данных, но со временем стал стандартом в этой области. Такая "победа" языка SQL обусловлена, во-первых, ориентацией на него первых и ведущих производителей коммерческих СУБД, во-вторых, тем, что уже в своей версии для System R он был достаточно хорошо развит не только как язык запросов, но и обеспечивал в полном объеме описание и управление данными. Коммерческие продукты далеко не сразу обеспечили свойства исходной версии SQL в полном объеме.

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

Разработкой стандартов языка SQL занимается Американский национальный комитет по стандартизации (ANSI) при поддержке Международной Организации Стандартов (ISO). Стандарты SQL принимались в 1987 г. (уточнен в 1989 г.), в 1992 г и в 1999 г. Однако даже ведущие СУБД сертифицированы только на уровень "Entry" стандарта SQL-92. В реальных СУБД применяются "диалекты" SQL. Процесс стандартизации динамичный и трудный – то, что сегодня является диалектом одной СУБД, завтра может стать стандартом. Язык SQL состоит из трех подмножеств:

• языка определения данных;

• языка манипулирования данными;

• языка управления данными.

Различия в диалектах разных СУБД для этих подмножеств незначительны. Язык управления данными более подвержен диалектным различиям.

Предложение SELECT

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

Предложение SELECT может использоваться как:

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

• элемент WHERE- или HAVING-условия ("вложенный запрос");

• фраза выбора в командах CREAT VIEW, DECLARE CURSOR или INSERT;

• средство присвоения глобальным переменным значений из строк сформированной таблицы (INTO-фраза).

Здесь будут рассмотрены только две первые функции предложения SELECT.

Предложение SELECT (выбрать) имеет следующий формат:

подзапрос [UNION [ALL] подзапрос] ...

[ORDER BY {[таблица.]столбец | номер_элемента_SELECT} [[ASC] | DESC]

[,{[таблица.]столбец | номер_элемента_SELECT} [[ASC] | DESC]] ...;

и позволяет объединить (UNION) а затем упорядочить (ORDER BY) результаты выбора данных, полученных с помощью нескольких "подзапросов". При этом упорядочение можно производить в порядке возрастания - ASC или убывания - DESC

Подзапрос позволяет указать условия для выбора нужных данных и (если требуется) их обработки

• SELECT(выбрать) данные из указанных столбцов и (если необходимо) выполнить перед выводом их преобразование в соответствии с указанными выражениями и (или) функциями

• FROM(из) перечисленных таблиц, в которых расположены эти столбцы

• WHERE(где) строки из указанных таблиц должны удовлетворять указанному перечню условий отбора строк

• GROUP BY(группируя по) указанному перечню столбцов с тем, чтобы получить для каждой группы единственное агрегированное значение, используя во фразе SELECT SQL-функции SUM(сумма), COUNT(количество), MIN(минимальное значение), MAX(максимальное значение) или AVG(среднее значение)

• HAVING(имея) в результате лишь те группы, которые удовлетворяют указанному перечню условий отбора групп

Подзапрос имеет формат

SELECT [ DISTINCT]{ * | элемент_SELECT [,элемент_SELECT] ...}

FROM {базовая_таблица | представление} [псевдоним]

[,{базовая_таблица | представление} [псевдоним]] ...

[WHERE фраза]

[GROUP BY фраза [HAVING фраза]];

Синтаксис выражений имеет вид

( {[ [+] | - ] {значение | функция_СУБД} [ + | - | * | ** ]}... )

а синтаксис SQL_функций - одна из следующих конструкций:

{SUM|AVG|MIN|MAX|COUNT} ( [[ALL]|DISTINCT][таблица.]столбец )

{SUM|AVG|MIN|MAX|COUNT} ( [ALL] выражение )

COUNT(*)

Фраза WHERE включает набор условий для отбора строк:

WHERE [NOT] WHERE_условие [[AND|OR][NOT] WHERE_условие]...

где WHERE_условие - одна из следующих конструкций:

значение { = | | | >= } { значение | ( подзапрос ) }

значение_1 [NOT] BETWEEN значение_2 AND значение_3

значение [NOT] IN { ( константа [,константа]... ) | ( подзапрос ) }

значение IS [NOT] NULL

[таблица.]столбец [NOT] LIKE 'строка_символов' [ESCAPE 'символ']

EXISTS ( подзапрос )

Нетрадиционные условия отбора: BETWEEN (между), LIKE (похоже на), IN (принадлежит), IS NULL (не определено) и EXISTS (существует). В условиях могут употребляться логические операции: NOT, AND, OR.

Cинтаксис фразы GROUP BY имеет вид

GROUP BY [таблица.]столбец [,[таблица.]столбец] ...

[HAVING фраза]

GROUP BY инициирует перекомпоновку формируемой таблицы по группам, каждая из которых имеет одинаковое значение в столбцах, включенных в перечень GROUP BY. Далее к этим группам применяются агрегирующие функции, указанные во фразе SELECT. С помощью фразы HAVING, синтаксис которой:

HAVING _условие [[AND|OR][NOT] HAVING_условие]...

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

3.33 МОВА ЗАПИТІВ SQL. РОБОТА З ЗАПИСАМИ І ТАБЛИЦЯМИ. ДОДАВАННЯ, ВИДАЛЕННЯ, МОДИФІКАЦІЯ.

Мова запитів SQL. Робота з записами і таблицями. Додавання, видалення, модифікація.

Язык SQL – Structured Query Language – был разработан в 1974 г.

Додавання, видалення, модифікація.

Модификация данных может выполняться с помощью предложений DELETE (удалить), INSERT (вставить) и UPDATE (обновить). Подобно предложению SELECT они могут оперировать как базовыми таблицами, так и представлениями.

Предложение DELETE имеет формат

DELETE

FROM базовая таблица | представление

[WHERE фраза];

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

Предложение INSERT имеет один из следующих форматов:

INSERT

INTO {базовая таблица | представление} [(столбец [,столбец] ...)]

VALUES ({константа | переменная} [,{константа | переменная}] ...);

или

INSERT

INTO {базовая таблица | представление} [(столбец [,столбец] ...)]

подзапрос;

Предложение UPDATE также имеет два формата. Первый из них:

UPDATE (базовая таблица | представление}

SET столбец = значение [, столбец = значение] ...

[WHERE фраза]

где значение - это

столбец | выражение | константа | переменная

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

UPDATE {базовая таблица | представление}

SET столбец = значение [, столбец = значение] ...

FROM {базовая таблица | представление} [псевдоним],

{базовая таблица | представление} [псевдоним]

[,{базовая таблица | представление} [псевдоним]] ...

[WHERE фраза]

3.34. АРХІТЕКТУРИ ПОБУДОВИ СИСТЕМ КЛІЄНТ-СЕРВЕР. ВАРІАНТИ ПОБУДОВИ СЕРВЕРНИХ ПРИКЛАДЕНЬ. ВАРІАНТИ ПОБУДОВИ КЛІЄНТСЬКИХ ПРИКЛАДЕНЬ.

В архитектуре "клиент/сервер" функции приложения распределены между двумя (или более) компьютерами. В соответствии с тем, каким образом это сделано, выделяются три модели архитектуры "клиент/сервер":

1. Модель доступа к удаленным данным (Remote Data Access - RDA);

2. Модель сервера базы данных (DataBase Server - DBS);

3. Модель сервера приложений (Application Server - AS).

RDA-модель

В RDA-модели (рис. 2) коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и прикладные функции ("толстый" клиент).

Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (например, SQL) или вызовами функций специальной библиотеки (если имеется соответствующий API). Запросы к информационным ресурсам направляются по сети удаленному компьютеру-серверу базы данных. Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных. Говоря об архитектуре "клиент/сервер", в большинстве случаев имеют в виду именно эту модель.

DBS-модель

В DBS-модели (рис. 3) процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления ("тонкий" клиент), а прикладные функции реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами базы данных. Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных, где функционирует и компонент, управляющий доступом к данным, то есть ядро СУБД.

AS-модель

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

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

Большинство конфигураций клиент-сервер использует двухзвенную модель, состоящую из клиента, который обращается к услугам сервера. Для эффективной реализации такой схемы часто применяют неоднородную сеть. Как минимум, предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Далее возможно разместить компоненты управления данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте - сх. 3 в таблице 1). Типовое определение архитектуры клиент-сервер - приложение на клиенте, СУБД - на сервере - использует эту схему.

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

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

3.35. ДРАЙВЕРИ. ПРИЗНАЧЕННЯ, СТРУКТУРА. МЕХАНІЗМ РОБОТИ ДРАЙВЕРА. ПРИКЛАДИ ДРАЙВЕРІВ.

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

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

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

Для принятия решений о доступности устройств ОС поддерживает таблицы дескрипторов, отражающие состояние станций траффика (три таблицы - по числу типов станций). Для канала дескриптор включает в себя: идентификатор канала; состояние (занят/свободен); список

контроллеров, подключенных к каналу; список запросов к каналу. Для контроллера: идентификатор контроллера; состояние; список каналов, к которым подключен контроллер; список устройств, подключенных к контроллеру; список запросов к контроллеру. Для устройства: идентификатор устройства; состояние; список контроллеров, к которым подключено устройство; список запросов к устройству.

Логически являясь частью ОС, драйверы, тем не менее оформляются как отдельные модули. Поскольку каждый драйвер однозначно связан с устройством определенного типа (а возможно, и данной модификации), то и состав набора драйверов зависит от конфигурации аппаратных средств. Кроме того, обязательно должна быть обеспечена возможность подключения к системе новых внешних устройств без внесения изменений в ОС. При модульности драйверов это достигается простым добавлением нового драйвера к системному программному обеспечению. Драйверы загружаются в память либо при загрузке системы, либо (реже) - динамически, при возникновении потребности в них. Выбор драйверов для загрузки выполняется либо по явным указаниям в процедуре инициализации ОС (OS/2), либо неявно - по имеющимся таблицам конфигурации системы (VM/ESA, MVS/ESA) либо полностью автоматически - путем опроса при загрузке всех установленных устройств, опознания их и подключения соответствующих драйверов. Последний принцип получил название plug and play (включил и играй).

Примеры драйверов устройств:

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

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

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

Драйвер линейного таймера осуществляет только обработку его прерываний и в типовом случае может выполнять следующие действия по каждому прерыванию:

- модифицировать системные структуры данных службы времени и даты;

- увеличивать счетчик виртуального времени активного процесса;

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

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

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

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

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

- чтение кода клавиши и перевод его в код символа;

- запоминание кодов символов в своем буфере;

- распознавание специальных клавиш и комбинаций клавиш (например, Ctrl+Break) и вызов специальных их обработчиков;

- обработку специальных клавиш редактирования содержимого буфера (например, BackSpace).

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

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

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

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

этап: он требует механического перемещения головок к требуемой дорожки; время этого перемещения зависит от расстояния перемещения. Выбор сектора на дорожке требует ожидания момента, когда требуемый сектор окажется под головкой (за счет вращения диска), время выбора сектора много меньше времени выбора дорожки. Драйвер упорядочивает очередь запросов таким образом, чтобы минимизировать среднее время поиска дорожки. Обсуждение стратегий

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

драйвера и значительным механическим нагрузкам на дисковод.

3.36. КЕРУВАННЯ ПРОЦЕСОРНИМ ЧАСОМ. МОДЕЛЬ ПЛАНУВАЛЬНИКА ТА ДИСПЕТЧЕРА ПРОЦЕСОРНОГО ЧАСУ. ПРІОРИТЕТИ ПРОЦЕСІВ.

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

- выполнение процесса завершилось;

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

какого-либо другого ресурса;

- выполнение прервано системой.

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

стратегию планирования. Для оценки эффективности функционирования данной СМО могут

быть применены количественные показатели. Обозначим через t - процессорное время, необходимое процессу для выполнения, мы будем его называть длительностью процесса. Обозначим через T - общее время пребывания процесса в системе. Эту величину также называют

иногда временем реакции процесса - интервал между моментом вводом процесса в систему и моментом получения результатов. Наряду с временем реакции могут быть полезны также и другие показатели. Потерянное время: M = T - t;

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

Отношение реактивности: R = t / T;

показывает долю процессорного времени (времени выполнения) или долю потерянного времени в общем времени реакции. Штрафное отношение: P = T / t;

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

Различают приоритеты:

- внешние - назначаемые администратором системы или пользователем в соответствии с классом пользователя и/или произведенной пользователем оплатой;

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

- динамические - перевычисляемые планировщиком периодически или/и при событиях, влияющих на планирование процессов;

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

К ОС, обеспечивающим режим клиент/сервер, применяют дисциплины, отдающие предпочтение обменным процессам. Для таких ОС достаточно типичной можно считать такую макросхему определения приоритетов процессов в очереди к ЦП. Наивысший абсолютный приоритет имеют

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

мер, OS/2) включает в себя три класса:

- с высоким приоритетом - процессы реального времени;

- с нормальным приоритетом - интерактивные процессы;

- с низким приоритетом - счетные (пакетные) процессы.

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

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

- приоритет процесса, долгое время находящегося в состоянии ожидания, повышается;

- приоритет процесса, часто выполняющего операции ввода-вывода, повышается;

- приоритет процесса, чаще получающего внешние сообщения и прерывания, повышается;

- если приоритет процесса не повышается, он убывает.

3.37. КЕРУВАННЯ ПРОЦЕСОРНИМ ЧАСОМ. ВИТІСНЯЮЧІ ТА НЕВИТІСНЯЮЧІ ДИСЦИПЛІНИ ПЛАНУВАННЯ ПРОЦЕСОРНОГО ЧАСУ.

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

- выполнение процесса завершилось;

- процесс запросил выполнение операции, требующей ожидания какого-либо другого ресурса;

- выполнение прервано системой.

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

С точки зрения реализации дисциплины планирования подразделяются прежде всего на дисциплины вытесняющие (preemptive) и невытесняющие (non-preemptive) или кооперативные (cooperative). Для первых возможно прерывание активного процесса и лишение его ресурса ЦП по инициативе планировщика, для вторых - нет. Дисциплины с вытеснением выполняют более частые переключения процессов, следовательно, имеют большие накладные расходы. Но в большинстве случаев только дисциплины с вытеснением могут обеспечить требуемые показатели справедливости обслуживания. Классификация дисциплин также определяется способом определения приоритетов процессов. Различают приоритеты:

- внешние - назначаемые администратором системы или пользователем в соответствии с классом пользователя и/или произведенной пользователем оплатой;

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

- динамические - перевычисляемые планировщиком периодически или/и при событиях, влияющих на планирование процессов;

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

FCFS (first come - first serve - первым пришел - первым обслуживается) - простейшая дисциплина, работа которой понятна из ее названия. Это дисциплина без вытеснения, то есть, процесс, выбранный для выполнения на ЦП не прерывается, пока не завершится (или не перейдет в состояние ожидания по собственной инициативе).

RR (round robin - карусель) - простейшая дисциплина с вытеснением. Процесс получает в свое распоряжение ЦП на некоторый квант времени Q (в простейшем случае - размер кванта фиксирован). Если за время Q процесс не завершился, он вытесняется с ЦП и направляется в конец очереди готовых процессов, где ждет выделения ему следующего кванта, и т.д.

SJN (shortest job next - самая короткая работа - следующая) - невытесняющая дисциплина, в которой наивысший приоритет имеет самый короткий процесс.

PSJN (preemptive SJN - SJN с вытеснением) - текущий активный процесс прерывается, если его оставшееся время выполнения больше, чем у новоприбывшего процесса.

SRR (selfish RR - эгоистичный RR) - метод с вытеснением, дающий дополнительные преимущества выполняемым процессам, что позволяет повысить пропускную способность.

FB (foregroun-background - передний-задний планы) - очередь готовых процессов расщепляется на две подочереди - очередь переднего плана и очередь заднего плана.

2-19. Елементи формату сектору, що забезпечують бітову та байтову синхронізацію під час зчитування інформації з гнучких дисків.

Елементи формату сектору, що забезпечують бітову та байтову синхронізацію під час зчитування інформації з гнучких дисків можна представити у вигляді наступного рисунка:

Налагодження синхронізації можна представити наступним чином:

203