Виртуальное адресное пространство каждого процесса делится на части одинакового, фиксированного для данной системы размера, называемые виртуальными страницами. Вся оперативная память машины также делится на части такого же размера, называемые физическими страницами (или блоками).
Размер страницы обычно выбирается равным степени двойки: 512, 1024 и т.д., это позволяет упростить механизм преобразования адресов.
При загрузке процесса часть его виртуальных страниц помещается в оперативную память, а остальные - на диск. Смежные виртуальные страницы не обязательно располагаются в смежных физических страницах. При загрузке операционная система создает для каждого процесса информационную структуру - таблицу страниц, в которой устанавливается соответствие между номерами виртуальных и физических страниц для страниц, загруженных в оперативную память, или делается отметка о том, что виртуальная страница выгружена на диск. Кроме того, в таблице страниц содержится управляющая информация, такая как признак модификации страницы, признак невыгружаемости (выгрузка некоторых страниц может быть запрещена), признак обращения к странице (используется для подсчета числа обращений за определенный период времени) и другие данные, формируемые и используемые механизмом виртуальной памяти.
3.5. Вопросы и литература
1. Сколько процессов (программ) может считаться одновременно загруженными в память?
2. Что такое «фрагментация»?
3. Какова фрагментация при страничном распределении памяти?
4. Когда возникают страничные прерывания?
5. Чем определяется размер виртуальной таблицы?
6. Когда принимается решение о вытеснении страницы?
7. Что такое «свопинг»?
8. Что означает «грязная страница»?
| Учебник / Учебное пособие | Раздел | Страницы |
| Таненбаум Э. Современные операционные системы. 3-е изд. - СПб.: Питер, 2010. - 1120 е.: ил. | 3.1-3.5,4.1.1-4.1.6, 4.2.1-4.2.4, 4.3.4-4.3.7 | 217-275, 308-316 , 320-325, 336-345 |
4. Файловая система
4.1. Цель практического занятия
Целью практического занятия является более подробное ознакомление с построением и функциями файловой системы.
4.2. План занятия
4.3. Используемые технологии
Для лучшего усвоения материала желательно проведение занятия с использованием компьютера.
4.4. Примеры для анализа
Понятие файл используется для того, чтобы абстрагироваться от носителей и устройств, предназначенных для постоянного или временного хранения данных, и от данных.
Файловая система (ФС) является собой часть ОС, которая отвечает за преобразование «файла» от абстрактного представления файла до конкретного физического, которое характеризуется конкретным физическим адресом и форматом внутреннего (двоичного) представления. В самом общем виде такое отображение на физический уровень выглядит следующим образом:
Логическая организация файлов обеспечивает API, предназначенный для доступа к файлам на логическом уровне. Обычно выделяют: байт-ориентированную и запись-ориентированную логическую организацию файла.
Логическая ФС трактует файл как единицу хранения. Эта единица имеет имя, и ее описание находится в системном справочнике (каталоге, или директории). Правила именования могут быть разными в различных ОС.
Каталоги могут быть одноуровневыми - описания файлов сведены в одну таблицу.
Косвенным файлом (indirect file) или символьной связью (symbolic link), или мягкой связью (soft link) называется элемент каталога, который ссылается на другой элемент каталога. Ссылка производится обычно путем указания полного символьного имени каталога. Физически символьные связи представляются файлами специального типа, содержащими ссылки. Могут обеспечиваться и многоуровневые символьные связи. Подобно косвенным файлам, могут быть и косвенные каталоги. Принципиальное отличие косвенных файлов от алиасов - в том, что имена косвенных файлов имеют неравные права с основным именем. Только один элемент каталога (основной) ссылается на физический файл, остальные же - на элемент каталога. Поэтому удаление физического файла возможно только по основному имени, удаления же по косвенным именам удаляют только элементы каталогов. Если файл удален по основному имени, то косвенные ссылки на него, как правило, остаются в каталогах и обращения по косвенным именам приведут к ошибкам. Задача чистки каталогов от неактуальных косвенных имен может возлагаться либо на пользователей - владельцев каталогов, либо на администратора системы, в распоряжении которого должны быть соответствующие утилиты.
На программном уровне обычно определяется примерно следующий состав атрибутов файла данных:
| Атрибут | Значение |
| Защита | Кто и каким образом может получить доступ к файлу |
| Пароль | Пароль для получения доступа к файлу |
| Создатель | Идентификатор создателя файла |
| Владелец | Текущий владелец |
| Флаг «только для чтения» | 0 — для чтения-записи; 1 — только для чтения |
| Флаг «скрытый» | 0 — обычный; 1 — не предназначенный для отображения в перечне файлов |
| Флаг «системный» | 0 — обычный; 1 — системный |
| Флаг «архивный» | 0 — прошедший резервное копирование; 1 — нуждающийся в резервном копировании |
| Флаг ASCII-двоичный | 0 —ASCII; 1 — двоичный |
| Флаг произвольного доступа | 0 — только последовательный доступ; 1 — произвольный до ступ |
| Флаг «временный» | 0 — обычный; 1 — удаляемый по окончании работы процесса |
| Флаги блокировки | 0 — незаблокированный; ненулевое значение — заблокиро ванный |
| Длина записи | Количество байтов в записи |
| Позиция ключа | Смещение ключа внутри каждой записи |
| Длина ключа | Количество байтов в поле ключа |
| Время создания | Дата и время создания файла |
| Время последнего доступа | Дата и время последнего доступа к файлу |
| Время последних изменений | Дата и время внесения в файл последних изменений |
| Текущий размер | Количество байтов в файле |
| Максимальный размер | Количество байтов, до которого файл может увеличиваться |
Для конкретизации в качестве логического представления данных рассматривается класс CFile из библиотеки MFC:
Конструктор
CFile::CFile - Создание объекта CFile по указанию дескриптора пути или файла.
Открытые методы
CFile::Open - Открытие файла.
CFile::Close - Закрытие файла и удаление объекта.
CFile::Abort - Закрытие файла, игнорируя все предупреждения и ошибки.
Методы для действий над данными
CFile::Read - Считывание (небуферизованных) данных из файла в текущей позиции файла.
CFile::Write - Запись (небуферизованных) данных в текущей позиции файла.
CFile::Flush – Сброс содержимого из файловых буферов.
CFile::LockRange - Блокирует диапазон байтов в файле.
CFile::UnlockRange - Разблокирует диапазон байтов в файле.
Методы для действий с указателем
CFile::Seek - Позиционирование указателя файла.
CFile::SeekToBegin - Позиционирует указатель текущего файла на начало файла.
CFile::SeekToEnd - Позиционирует указатель текущего файла на конец файла.
Свойства объекта
CFile::GetFileName - Получение имени.
CFile::GetFilePath - Получение полного пути
CFile::GetLength - Получение размера в байтах.
CFile::GetPosition – Получение текущей позиции указателя файла.
CFile::GetStatus - Получение состояния открытия файла.
CFile::SetFilePath - Задание полного пути к файлу.
CFile::SetLength - Изменение размера файла.
CFile::SetStatus - Установка состояния указанного файла (статического виртуальная функция).
Переменные класса
CFile::m_hFile - дескриптор файла.
CFile::m_pTM - Указатель на объект CAtlTransactionManager.
С целью обсуждения рассматриваются функции управления каталогами:
| CreateDirectory | Creates a new directory. |
| CreateDirectoryEx | Creates a new directory with the attributes of a specified template directory. |
| CreateFile | Creates or opens a file object. |
| DeleteFile | Deletes an existing file. |
| FindCloseChangeNotification | Stops change notification handle monitoring. |
| FindFirstChangeNotification | Creates a change notification handle. |
| FindFirstFile | Searches a directory for a file or subdirectory whose name matches the specified name. |
| FindNextChangeNotification | Requests that the operating system signal a change notification handle the next time it detects an appropriate change. |
| FindNextFile | Continues a file search. |
| GetCurrentDirectory | Retrieves the current directory for the current process. |
| MoveFile | Moves an existing file or a directory. |
| ReadDirectoryChangesW | Retrieves information describing the changes occurring within a directory. |
| RemoveDirectory | Deletes an existing empty directory. |
| SetCurrentDirectory | Changes the current directory for the current process. |
4.5. Вопросы и литература
1. Какие системные вызовы для работы с файлами вам известны?
2. Какую информацию содержит дескриптор диска?
3. Каково назначение каталога файлов?
4. Приведите пример атрибутов файла.
5. Каково назначение атрибутов «защита» и «пароль»?
| Учебник / Учебное пособие | Раздел | Страницы |
| Таненбаум Э. Современные операционные системы. 3-е изд. - СПб.: Питер, 2010. - 1120 е.: ил. | 3.1-3.5, 3.8 4.1.1-4.1.6, 4.2.1-4.2.4, 4.3.4-4.3.7 | 217-275, 308-316, 320-325, 336-345 |
5. Основы проектирование данных. Отношения
5.1. Цель практического занятия
Целью практического занятия является рассмотрение на учебном примере вопросов проектирования базы данных согласно конкретным требованиям к ее функциональности.
5.2. План занятия
План и содержание занятия соответствуют этапам проектирования баз данных:
· Определение таблиц базы данных в соответствии с назначением базы данных и требованиям к ее функциональности;
· Определение для каждой таблицы необходимых полей и их свойств;
· Определение ограничений на значения полей при необходимости;
· Определение связей между таблицами и атрибутов связей;
· Проверка спроектированной схемы данных на соответствие нормальным формам.
5.3. Используемые технологии
Для лучшего усвоения материала желательно проведение занятия с использованием компьютера.
5.4. Примеры для анализа
Занятие строится на рассмотрении 2-х учебных примеров проектирования базы данных:
· Первый пример показывает решение условной задачи поддержания «продаж автомобилей» от ее постановки и до получения схемы данных;
· Второй пример показывает схему данных. Здесь от студентов требуется решить «обратную» задачу - определить бизнес-правила и ограничения, на основе которых была разработана схеме данных.
Первый пример
Решение задачи начинается с ее постановки, т.е., формулирования требований к функциональности будущей базы данных.
Пусть возможна продажа автомобилей базовой комплектации и автомобилей в расширенной комплектации, причем возможные расширенные комплектации определены и идентифицированы.
Пусть автомобили различаются по нескольким условно идентифицированным «моделям» и могут иметь один из нескольких заданных типов кузова автомобиля, а также один из нескольких стандартизованных цветов.
Сформулируем «бизнес-правила» для задачи.
Пусть требуется вести данные о покупателях и о совершенных ими покупках.
Определим возможные операции покупателя:
· покупатель может делать несколько покупок в один день;
· покупатель может выбирать модель, тип кузова и цвет автомобиля;
· покупатель может заказывать для покупаемого автомобиля дополнительную комплектацию произвольным количеством отдельных единиц, но без повторений.
Стоимость автомобиля конкретной модели в базовой комплектации зависит от типа кузова.
Конкретный экземпляр автомобиль имеет уникальную характеристику vin, представляющую собой строку символов.
С учетом «бизнес-правил» для решения задачи схема данных должна содержать следующие таблицы («сущности»):
а) «customer» – содержит информацию о покупателе;
б) «models» – содержит информацию о моделях автомобилей;
в) bodywork» – содержит информацию об исполнениях кузова;
г) «colors» – номенклатура цветов;
д) «sets» – номенклатура единиц комплектации;
е) «automobile» – экземпляры автомобилей;
ж) «equipment» – оснащение конкретного экземпляра единицами комплектации;
з) «customer_automobile» – покупка автомобиля покупателем;
Схема данных содержит описанные выше таблицы (сущности), связи между которыми конкретно задаются установкой свойств полей (атрибутов), служащих для связи.
Нужно отметить, что в спроектированных сущностях нет неключевых атрибутов, зависящих от других неключевых атрибутов.
Схема данных показана на Рис. 5.1:
Рис. 5.1: Схема данных для задачи «покупка автомобиля»
Второй пример
Приведенная на Рис. 5.2: схема данных разработана для решения задачи назначения студентов на места практики. Требуется на основе анализа сущностей, атрибутов и связей восстановить постановку задачи, сформулировать бизнес-правила и описать функциональность, которую можно получить при эксплуатации базы данных.
Рис. 5.2: Схема данных для задачи «назначение студентов на практику»
5.5. Вопросы и литература
1. Чем характеризуется реляционная модель данных.
2. Что определяет домен?
3. Поясните понятие отношения.
4. Что означает схема отношения.
5. На основе каких теоретико-множественных операций строится язык запросов к базе данных.
6. Какие разновидности операции соединения (JOIN) существуют.
7. С какой целью осуществляют декомпозицию базы данных.
8. Каким образом проявляется функциональная зависимость данных.
| Учебник / Учебное пособие | Раздел | Страницы |
| 1. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. | Главы 3,4 | 31-65 |
| 2. Хомоненко А.Д, Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / под ред. проф. Хомоненко А.Д., 6-ое изд. – М.:Бином-Пресс; СПб.:Корона-Век, 2007.-736с. | Гл.2, 3 | 29- 34, 49-107 |
6. Синхронизация процессов и доступа к ресурсам. Транзакции в ОС и СУБД
6.1. Цель практического занятия
Целью практического занятия является более подробное ознакомление с понятием транзакций и организации их поддержки в СУБД.
6.2. План занятия
В рамках занятия рассматриваются следующие вопросы:
· Журнализация операций над данными.
· Фиксация транзакции.
· Откат и восстановление БД.
· Синтаксис некоторых операторов SQL
6.3. Используемые технологии
Для лучшего усвоения материала желательно проведение занятия с использованием компьютера.
6.4. Примеры для анализа
Журнализацией называют процесс сохранения всех изменений, внесенных транзакцией в базу данных. Журнализация осуществляется для восстановления впоследствии согласованного состояния базы данных после сбоя Сценарий восстановления является процессом, который восстанавливает данные из одной или нескольких резервных копий, а при восстановлении последней резервной копии восстанавливает базу данных.
Восстановление может происходить на уровне:
базы данных, при этом база данных возвращается в предшествующее согласованное состояние и восстанавливается.
файла данных, при этом файл данных или набор файлов данных возвращается в исходное состояние и восстанавливается.
Полное восстановление базы данных может быть
· простым восстановлением из полной резервной копии;
· восстановлением на основе полной резервной копии базы данных с ее последующим обновлением по журналу.
В журнале транзакций фиксируются все изменения данных, произведенные в каждой транзакции. Журнал транзакций нельзя ни удалять, ни изменять произвольно.
Журнал транзакций поддерживает следующие операции:
· восстановление отдельных транзакций;
· восстановление всех незавершенных транзакций при запуске;
· повтор изменений в прямом направлении («накат», redo) по журналу восстановленной базы данных до момента сбоя.
Последовательность операций восстановления обычно возвращает в исходное состояние содержимое базы данных (стадия копирования данных), выполняет повтор зафиксированных транзакций (стадия повтора) и «откатывает» нефиксированные транзакции (стадия отката). Откатом называют отмену изменений. Откат транзакции может быть откатом до последней точки сохранения или до начала транзакции.
Если приложение выполняет инструкцию ROLLBACK или обнаружена ошибка или сбой, записи журнала используются для отката изменений, сделанных незавершенной транзакцией.
Если на сервере происходит сбой, базы данных могут остаться в таком состоянии, что часть изменений не была переписана из буферного кэша в файлы данных, и иметься изменения в файлах данных, совершенные незавершенными транзакциями. При повторном запуске сервера будет выполнен повтор каждого записанного в журнал изменения, которое, возможно, не было переписано в файл данных, и откат каждой незавершенной транзакции из журнала транзакций.
Логически журнал транзакций работает так, как если бы он являлся последовательностью записей в журнале. Каждая запись журнала идентифицируется регистрационным номером транзакции (номер LSN). Каждая новая запись добавляется в логический конец журнала с номером LSN, который больше номера LSN предыдущей записи.
Записи журнала хранятся в той последовательности, в которой они были созданы. Каждая запись журнала содержит идентификатор транзакции, к которой она относится. Записи журнала для изменения данных содержат либо выполненную логическую операцию, либо исходный и результирующий образ измененных данных. Исходным образом записи является копия данных до выполнения операции, а результирующим образом - копия данных после ее выполнения.
Если в журнал записывается логическая операция, то для повтора логической операции выполняется эта операция, а для отката логической операции выполняется логическая операция, обратная записанной.
Если в журнал записываются исходный и результирующий образы записи, то для повтора операции применяется результирующий образ, а для отката операции применяется исходный образ.
В журнал транзакций записываются:
· начало и конец каждой транзакции;
· изменения данных (вставка, обновление или удаление), включая изменения в любой таблице (в том числе и в системных таблицах);
· любое выделение и освобождение страниц и экстентов;
· создание и удаление таблиц и индексов.
Кроме того, регистрируются операции отката. Каждая транзакция резервирует в журнале транзакций место, чтобы при выполнении оператора отката или возникновения ошибки в журнале было достаточно места для регистрации отката. Объем резервируемого пространства зависит от выполняемых в транзакции операций, но обычно он равен объему, необходимому для регистрации каждой из операций. Все это пространство после завершения транзакции освобождается.
Журнал транзакций ведется с упреждением: Метод протоколирования транзакций, при котором записи в журнал всегда заносятся до записи данных