Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы

^ Внутренняя организация реляционных СУБД


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

Соответственно появляются последующие разновидности объектов во наружной памяти базы данных:

Мы рассматривали на примерах System Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы R и Ingres два других подхода к организации реляционной СУБД с точки разделения функций меж разными компонентами. Напомним, что в СУБД System R была встроенная подсистема управления данными, транзакциями и журнализацией, в Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы то время как в Ingres управление данными, было отделено от управления транзакциями и журнализацией.

У обоих этих подходов имеются свои достоинства и недочеты. Подход System R позволяет использовать более действенные способы Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы за счет совместного решения заморочек физической и логической синхронизации, использовании общих протоколов при управлении буферами и журнализации и т.д. Но при всем этом в неком смысле подсистема нижнего уровня становится монолитом; при самой успешной Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы ее структуризации составляющие остаются связанными общими протоколами взаимодействия. Необмысленные локальные конфигурации 1-го компонента могут привести к фатальным последствиям для всей системы. Подход Ingres позволяет упростить структуру системы и сделать ее более гибкой Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, но это может быть только за счет огрубления алгоритмов: внедрения более грубых способов управления транзакциями; жестких протоколов журнализации и т.д.

В конечном счете неважно какая определенная система основывается Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы на определенном всеохватывающем решении. Мы рассматриваем тут куски таких решений (наброски).

^ 9.1. Хранение отношений
Есть два принципных подхода к физическому хранению отношений. Более всераспространенным является покортежное хранение отношений (кортеж является единицей физического хранения). Естественно, это Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы обеспечивает резвый доступ к целому кортежу, но при всем этом во наружной памяти дублируются общие значения различных кортежей 1-го дела и, вообщем говоря, могут потребоваться излишние обмены с наружной памятью Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, если нужна часть кортежа.

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

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



К главным чертам этой организации можно отнести последующие:

Что все-таки касается хранения дела по столбцам, то основная мысль Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы состоит в совместном хранении всех значений 1-го (либо нескольких) столбцов. Для каждого кортежа дела хранится кортеж той же степени, состоящий из ссылок на места расположения соответственных значений столбцов. В последней лекции мы будем Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы рассматривать особенности организации распределенных реляционных СУБД. Одним из приемов является так называемое вертикальное разделение отношений, когда в различных узлах сети хранятся различные проекции данного дела. Хранение дела по столбцам в неком смысле Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы является предельным случаем вертикального разделения отношений.

9.2. Индексы
Вроде бы не были организованы индексы в определенной СУБД, их основное предназначение состоит в обеспечении действенного прямого доступа к кортежу дела по ключу Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы. Обычно индекс определяется для 1-го дела, и ключом является значение атрибута (может быть, составного). Если ключом индекса является вероятный ключ дела, то индекс должен владеть свойством уникальности, т.е. не содержать дубликатов Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы ключа. На практике ситуация смотрится обычно обратно: при объявлении первичного ключа дела автоматом заводится уникальный индекс, а единственным методом объявления вероятного ключа, хорошего от первичного, является очевидное создание уникального индекса. Это связано Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы с тем, что для проверки сохранения характеристики уникальности вероятного ключа так либо по другому требуется индексная поддержка.

Так как при выполнении многих операций языкового уровня требуется сортировка отношений в согласовании со значениями неких атрибутов Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, полезным свойством индекса является обеспечение поочередного просмотра кортежей дела в спектре значений ключа в порядке возрастания либо убывания значений ключа.

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

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

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

В типовом случае структура внутренней странички смотрится последующим образом:



При всем этом выдерживаются последующие характеристики:

Листовая страничка обычно имеет последующую структуру:



Листовая страничка обладает последующими качествами:

Поиск в B-дереве - это прохождение от корня к листу в согласовании с данным значением ключа. Заметим, что так как деревья очень ветвистые и равновесные, то для выполнения поиска Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы по хоть какому значению ключа будет нужно одно и то же (и обычно маленькое) число обменов с наружной памятью. Более точно, в равновесном дереве, где длины всех путей от корня к листу Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы одни и те же, если во внутренней страничке помещается n ключей, то при хранении m записей требуется дерево глубиной logn(m), где logn вычисляет логарифм по основанию n. Если n довольно Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы велико (обыденный случай), то глубина дерева невелика, и делается резвый поиск.

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

При занесение новейшей Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы записи производится:

При удалении записи производятся последующие деяния:

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

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

Следует увидеть, что при организации мультидоступа к B-деревьям, соответствующего при их использовании в СУБД, приходится решать ряд нетривиальных заморочек Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы. Естественно, грубые решения явны, к примеру монопольный захват B-дерева на все выполнение операции модификации. Но есть и поболее тонкие решения, рассмотрение которых выходит за границы нашего курса.

И последнее замечание относительно Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы B-деревьев. В литературе вид рассмотренных нами деревьев принято именовать B* либо B+-деревьями.

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

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

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

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

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

Журнальчик обычно представляет собой чисто поочередный файл с записями переменного размера, которые можно просматривать Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы в прямом либо оборотном порядке. Обмены выполняются стандартными порциями (страничками) с внедрением буфера оперативки. В хорошо организованных системах структура (и тем паче, смысл) журнальных записей известна только компонентам СУБД, ответственным за Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы журнализацию и восстановление. Так как содержимое журнальчика является критическим при восстановлении базы данных после сбоев, к ведению файла журнальчика предъявляются особенные требования по части надежности. А именно, обычно стремятся поддерживать две схожие Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы копии журнальчика на различных устройствах наружной памяти.

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

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

Под транзакцией понимается неразделимая исходя из убеждений воздействия на БД последовательность операторов манипулирования Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы данными (чтения, удаления, вставки, модификации) такая, что или результаты всех операторов, входящих в транзакцию, показываются в БД, или воздействие всех этих операторов на сто процентов отсутствует. Девиз транзакции - "Все либо Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы ничего": при окончании транзакции оператором COMMIT результаты гарантированно фиксируются во наружной памяти (смысл слова commit - "зафиксировать" результаты транзакции); при окончании транзакции оператором ROLLBACK результаты гарантированно отсутствуют во наружной памяти (смысл слова rollback Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы - устранить результаты транзакции).

^ 10.1. Транзакции и целостность баз данных
Понятие транзакции имеет конкретную связь с понятием целостности БД. Очень нередко БД может владеть такими ограничениями целостности, которые просто нереально не нарушить, выполняя только Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы один оператор конфигурации БД. К примеру, в базе данных СОТРУДНИКИ-ОТДЕЛЫ естественным ограничением целостности является совпадения значения атрибута ОТД_РАЗМЕР в кортеже дела ОТДЕЛЫ, описывающем данный отдел (к примеру, отдел 320), с числом Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы кортежей дела СОТРУДНИКИ таких, что значение атрибута СОТР_ОТД_НОМЕР равно 320. Как в данном случае принять на работу в отдел 320 нового сотрудника? Независимо от того, какая операция будет выполнена первой, вставка нового кортежа в отношение Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы СОТРУДНИКИ либо модификация имеющегося кортежа в отношении ОТДЕЛЫ, после выполнения операции база данных окажется в нецелостном состоянии.

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

Если быть мало более четким, различаются два вида ограничений целостности: немедля проверяемые и откладываемые. К немедля проверяемым ограничениям целостности относятся Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы такие ограничения, проверку которых глупо либо даже нереально откладывать. Примером ограничения, проверку которого откладывать глупо, являются ограничения домена (возраст сотрудника не может превосходить 150 лет). Более сложным ограничением, проверку которого нереально отложить, является последующее: заработная плата Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы сотрудника не может быть увеличена за одну операцию более, чем на 100,000 рублей. Немедля проверяемые ограничения целостности соответствуют уровню отдельных операторов языкового уровня СУБД. При их нарушениях не делается откат транзакции, а Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы только отвергается соответственный оператор.

Откладываемые ограничения целостности - это ограничения на базу данных, а не на какие-либо отдельные операции. По дефлоту такие ограничения проверяются при конце транзакции, и их нарушение вызывает Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы автоматическую подмену оператора COMMIT на оператор ROLLBACK. Но в неких системах поддерживается особый оператор насильной проверки ограничений целостности снутри транзакции. Если после выполнения такового оператора находится, что условия целостности не выполнены, юзер может сам Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы выполнить оператор ROLLBACK либо попытаться убрать предпосылки нецелостного состояния базы данных снутри транзакции (видимо, это осмысленно только при использовании интерактивного режима работы).

И очередное замечание. Исходя из убеждений наружного представления в Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы момент окончания транзакции проверяются все откладываемые ограничения целостности, определенные в этой базе данных. Но при реализации стремятся при выполнении транзакции динамически выделить те ограничения целостности, которые вправду могли бы быть Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы нарушены. К примеру, если при выполнении транзакции над базой данных СОТРУДНИКИ-ОТДЕЛЫ в ней не производились операторы вставки либо удаления кортежей из дела СОТРУДНИКИ, то инспектировать упоминавшееся выше ограничение целостности не требуется (а проверка схожих Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы ограничений вызывает довольно огромную работу).

^ 10.2. Изолированность юзеров
Во многопользовательских системах с одной базой данных сразу могут работать несколько юзеров либо прикладных программ. Предельной задачей системы является обеспечение изолированности юзеров, т.е. создание Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы достоверной и надежной иллюзии того, что любой из юзеров работает с БД в одиночку.

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

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

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

К более узким дилеммам изолированности транзакций относится так именуемая неувязка кортежей-"фантомов", вызывающая ситуации, которые также Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы противоречат изолированности юзеров. Разглядим последующий сценарий. Транзакция 1 делает оператор A подборки кортежей дела R с условием подборки S (т.е. выбирается часть кортежей дела R, удовлетворяющих условию S). До Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы окончания транзакции 1 транзакция 2 вставляет в отношение R новый кортеж r, удовлетворяющий условию S, и удачно заканчивается. Транзакция 1 повторно делает оператор A, и в итоге возникает кортеж, который отсутствовал при первом выполнении оператора. Естественно Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, такая ситуация противоречит идее изолированности транзакций и может появиться даже на 3-ем уровне изолированности транзакций. Чтоб избежать возникновения кортежей-фантомов, требуется более высочайший "логический" уровень синхронизации транзакций. Идеи таковой синхронизации (предикатные Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы синхронизационные захваты) известны издавна, но в большинстве систем не реализованы.

^ 10.3. Сериализация транзакций
Понятно, что для того, чтоб достигнуть изолированности транзакций, в СУБД должны употребляться какие-либо способы регулирования совместного выполнения транзакций.

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

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

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

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

Практические способы сериализации транзакций основывается на учете этих конфликтов.


^ Лекция 11. Способы сериализации транзакций
Есть два базисных подхода к Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы сериализации транзакций - основанный на синхронизационных захватах объектов базы данных и на использовании временных меток. Сущность обоих подходов состоит в обнаружении конфликтов транзакций и их устранении. Ниже мы разглядим эти подходы сравнимо Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы тщательно.

За ранее заметим, что для каждого из подходов имеются две разновидности - пессимистическая и жизнеутверждающая. При применении пессимистических способов, нацеленных на ситуации, когда конфликты появляются нередко, конфликты распознаются и разрешаются немедля Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы при их появлении. Жизнеутверждающие способы основываются на том, что результаты всех операций модификации базы данных сохраняются в рабочей памяти транзакций. Настоящая модификация базы данных делается лишь на стадии фиксации транзакции. Тогда же Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы проверяется, не появляются ли конфликты с другими транзакциями.

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

^ 11.1. Синхронизационные захваты
Более всераспространенным в Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы централизованных СУБД (включающих системы, основанные на архитектуре "клиент-сервер") является подход, основанный на соблюдении двухфазного протокола синхронизационных захватов объектов БД. В общих чертах протокол заключается в том, что перед выполнением Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы хоть какой операции в транзакции T над объектом базы данных r от имени транзакции T запрашивается синхронизационный захват объекта r в соответственном режиме (зависимо от вида операции).

Основными режимами синхронизационных захватов являются Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы:

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



X

S

-

да

да

X

нет

нет

S

нет

да

В первом Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы столбце приведены вероятные состояния объекта исходя из убеждений синхронизационных захватов. При всем этом "-" соответствует состоянию объекта, для которого не установлен никакой захват. Транзакция, запросившая синхронизационный захват объекта БД, уже оккупированный другой транзакцией Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы в несопоставимым режиме, блокируется до того времени, пока захват с этого объекта не будет снят.

Заметим, что слово "нет" в нашей таблице соответствует описанным ранее вероятным случаям конфликтов транзакций по доступу Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы к объектам базы данных (WW, RW, WR). Сопоставимость S-захватов соответствует тому, что конфликт RR не существует.

Для обеспечения сериализации транзакций (третьего уровня изолированности) синхронизационные захваты объектов, произведенные по инициативе Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы транзакции, можно снимать только при ее окончании. Это требование порождает двухфазный протокол синхронизационных захватов - 2PL. В согласовании с этим протоколом выполнение транзакции разбивается на две фазы:

Довольно просто убедиться, что при соблюдении двухфазного протокола синхронизационных захватов вправду обеспечивается сериализация транзакций на 3-ем уровне изолированности. Основная неувязка заключается в том, что следует считать объектом для синхронизационного Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы захвата?

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

По сути, когда мы говорим про операции над Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы объектами базы данных, то неважно какая операция над кортежем, практически, является и операцией над страничкой, в какой этот кортеж хранится, и над подходящим отношением, и над файлом, содержащем отношение. Потому вправду имеется выбор Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы уровня объекта захвата.

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

Но вся неудача в том, что при использовании для захватов больших объектов увеличивается возможность конфликтов транзакций и тем миниатюризируется допускаемая степень их параллельного выполнения Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы. Практически, при укрупнении объекта синхронизационного захвата мы специально огрубляем ситуацию и лицезреем конфликты в тех ситуациях, когда по сути конфликтов нет.

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

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

^ 11.1.1. Гранулированные синхронизационные захваты
Подобные рассуждения привели к разработки аппарата гранулированных синхронизационных захватов. При применении этого подхода синхронизационные захваты могут Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы запрашиваться по отношению к объектам различного уровня: файлам, отношениям и кортежам. Требуемый уровень объекта определяется тем, какая операция производится (к примеру, для выполнения операции поражения дела объектом синхронизационного захвата должно быть все Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы отношение, а для выполнения операции удаления кортежа - этот кортеж). Объект хоть какого уровня может быть захвачен в режиме S либо X.

Сейчас более принципиальное отличие, на котором, фактически, держится соответствие захватов различного уровня Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы. Вводится особые протокол гранулированных захватов и новые типы захватов: перед захватом объекта в режиме S либо X соответственный объект более верхнего уровня должен быть захвачен в режиме IS, IX либо SIX. Что все-таки Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы из себя представляют эти режимы захватов?

IS (Intented for Shared lock) по отношению к некому составному объекту O значит намерение захватить некий входящий в O объект в совместном режиме. К примеру Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, при намерении читать кортежи из дела R это отношение должно быть захвачено в режиме IS (а ранее в таком же режиме должен быть захвачен файл).

IX (Intented for eXclusive lock Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы) по отношению к некому составному объекту O значит намерение захватить некий входящий в O объект в монопольном режиме. К примеру, при намерении удалять кортежи из дела R это отношение должно быть захвачено в режиме IX Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы (а ранее в таком же режиме должен быть захвачен файл).

SIX (Shared, Intented for eXclusive lock) по отношению к некому составному объекту O значит кооперативный захват всего этого объекта с намерением потом Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы захватывать какие-либо входящие в него объекты в монопольном режиме. К примеру, если производится длинноватая операция просмотра дела с возможностью удаления неких просматриваемых кортежей, то экономичнее всего захватить это отношение Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы в режиме SIX (а ранее захватить файл в режиме IS).

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



X

S

IX

IS Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы

SIX

-

да

да

да

да

да

X

нет

нет

нет

нет

нет

S

нет

да

нет

да

нет

IX

нет

нет

да

да

нет

IS

нет

да

да

да

да

SIX

нет Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы

нет

нет

да

нет



^ 11.1.2. Предикатные синхронизационные захваты
Невзирая на привлекательность способа гранулированных синхронизационных захватов, необходимо подчеркнуть что он не решает делему фантомов (если, естественно, не ограничиться внедрением захватов отношений в режимах S Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы и X). Издавна понятно, что для решения этой задачи нужно перейти от захватов личных объектов базы данных, к захвату критерий (предикатов), которым удовлетворяют эти объекты. Неувязка фантомов не появляется при Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы использовании для синхронизации уровня отношений конкретно поэтому, что отношение как логический объект представляет собой неявное условие для входящих в него кортежей. Захват дела - это обычный и личный случай предикатного захвата.

Так как неважно Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы какая операция над реляционной базой данных задается неким условием (т.е. в ней указывается не определенный набор объектов базы данных, над которыми необходимо выполнить операцию, а условие, которому должны удовлетворять объекты этого Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы набора), безупречным выбором было бы добиваться синхронизационный захват в режиме S либо X конкретно этого условия. Но если поглядеть на вид критерий, допускаемых, к примеру, в языке SQL, то становится полностью неясно, как найти Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы сопоставимость 2-ух предикатных захватов. Ясно, что без этого использовать предикатные захваты для синхронизации транзакций нереально, а в общей форме неувязка неразрешима.

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

имя-атрибута { = > < } значение

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

Для обычных критерий сопоставимость предикатных захватов просто определяется на базе последующей геометрической интерпретации. Пусть R отношение Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы с атрибутами a1, a2, ..., an, а m1, m2, ..., mn - огромного количества допустимых значений a1, a2, ..., an соответственно (все эти огромного количества - конечные). Тогда можно сравнить R конечное n-мерное Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы место вероятных значений кортежей R. Хоть какое обычное условие "вырезает" m-мерный прямоугольник в этом пространстве (m <= n).

Тогда S-X, X-S, X-X предикатные захваты от различных транзакций совместимы, если Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы надлежащие прямоугольники не пересекаются.

Это иллюстрируется последующим примером, показывающим, что в каких бы режимах не добивалась транзакция 1 захвата условия (1<=a<=4) & (b=5), а транзакция 2 - условия (1<=a<=5) & (1<=b<=3), эти захваты всегда совместимы.

Пример: (n = 2)



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

^ 11.1.3. Тупики, определение и разрушение
Одним из более чувствительных недочетов способа сериализации транзакций на базе синхронизационных захватов является возможность появление тупиков (deadlocks) меж транзакциями Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы. Тупики вероятны при применении хоть какого из рассмотренных нами вариантов.

Вот обычной пример появления тупика меж транзакциями T1 и T2:

Так как тупики вероятны, и никакого естественного выхода из тупиковой ситуации не существует, то эти ситуации нужно обнаруживать и искусственно устранять.

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

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

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

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

Представим, что нам удалось отыскать цикл в графе ожидания транзакций Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы. Что делать сейчас? Необходимо каким-то образом обеспечить возможность продолжения работы хотя бы для части транзакций, попавших в тупик. Разрушение тупика начинается с выбора в цикле транзакций так именуемой транзакции-жертвы, т.е. транзакции Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, которой решено пожертвовать, чтоб обеспечить возможность продолжения работы других транзакций.

Грубо говоря, аспектом выбора является цена транзакции; жертвой выбирается самая доступная транзакция. Цена транзакции определяется на базе многофакторная оценка Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы, в которую с различными весами входят время выполнения, число скопленных захватов, ценность.

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

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

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

Очередное замечание. Чтоб минимизировать Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы число конфликтов меж транзакциями, в неких СУБД (к примеру, в Oracle) употребляется последующее развитие подхода. Монопольный захват объекта перекрывает только изменяющие транзакции. После выполнении операции модификации предшествующая версия объекта остается доступной для чтения Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы в других транзакциях. Краткосрочная блокировка чтения требуется лишь на период фиксации изменяющей транзакции, когда освеженные объекты становятся текущими.

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

Основная мысль способа (у которого существует огромное количество разновидностей) состоит в последующем: если транзакция T1 началась ранее транзакции T Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы2, то система обеспечивает таковой режим выполнения, как если б T1 была полностью выполнена до начала T2.

Для этого каждой транзакции T предписывается временная метка t, соответственная времени начала T. При выполнении операции над Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы объектом r транзакция T отмечает его собственной временной меткой и типом операции (чтение либо изменение).

Перед выполнением операции над объектом r транзакция T1 делает последующие деяния:

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

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

^ Лекция 12. Журнализация конфигураций БД
Одним из главных требований к развитым СУБД является надежность хранения баз данных. Это требование подразумевает, а именно, возможность восстановления согласованного состояния базы данных Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы после хоть какого рода аппаратных и программных сбоев. Разумеется, что для выполнения восстановлений нужна некая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая лишная дополнительная информация поддерживается в виде журнальчика Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы конфигураций базы данных.

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

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

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

Во всех Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы 3-х случаях основой восстановления является лишнее хранение данных. Эти лишниие данные хранятся в журнальчике, содержащем последовательность записей об изменении базы данных.

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

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

^ 12.1. Журнализация и буферизация Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы
Журнализация конфигураций плотно сплетена не только лишь с управлением транзакциями, да и с буферизацией страничек базы данных в оперативки. По причинам беспристрастно имеющейся различия в скорости работы микропроцессоров и оперативки и устройств наружной памяти Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы (эта разница в скорости была, существует и будет существовать всегда) буферизация страничек базы данных в оперативки - единственный реальный метод заслуги удовлетворительной эффективности СУБД.

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

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

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

Главным принципом согласованной политики выталкивания буфера журнальчика и буферов страничек Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы базы данных будет то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнальчика ранее, чем модифицированный объект оказывается во наружной памяти базы данных. Соответственный протокол Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы журнализации (и управления буферизацией) именуется Write Ahead Log (WAL) - "пиши поначалу в журнальчик", и заключается в том, что если требуется вытолкнуть во внешнюю память модифицированный объект базы данных, то перед этим необходимо Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы гарантировать выталкивание во внешнюю память журнальчика записи о его изменении.

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

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

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

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

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

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

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



^ 12.3. Восстановление после мягенького сбоя
К числу главных заморочек восстановление после мягенького сбоя относится Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы то, что одна логическая операция конфигурации базы данных может изменять несколько физических блоков базы данных, к примеру, страничку данных и несколько страничек индексов. Странички базы данных буферизуются в оперативки и Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы выталкиваются независимо. Невзирая на применение протокола WAL, после мягенького сбоя набор страничек наружной памяти базы данных возможно окажется несогласованным, т.е. часть страничек наружной памяти соответствует объекту до конфигурации, часть - после конфигурации. К Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы такому состоянию объекта не применимы операции логического уровня.

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

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

Тогда Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы к моменту мягенького сбоя вероятны последующие состояния транзакций:




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



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

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

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



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

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

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

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

Потому все более пользующимся популярностью становится поддержание Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы отдельного (недлинного) журнальчика постраничных конфигураций. Такая техника применяется, к примеру, в известном продукте Informix Online.

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

Восстановление начинается с оборотного копирования базы данных из архивной копии. Потом для всех закончившихся транзакций Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы производится redo, т.е. операции повторно производятся в прямом смысле.

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

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

Хотя к ведению журнальчика предъявляются особенные требования по части надежности, в принципе вероятна и его утрата. Тогда единственным методом восстановления Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы базы данных является возврат к архивной копии. Естественно, в данном случае не получится получить последнее согласованное состояние базы данных, но это лучше, чем ничего.

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

Можно делать архивацию базы данных пореже, чем переполняется журнальчик. При переполнении журнальчика Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы и окончании всех начатых транзакций можно архивировать сам журнальчик. Так как таковой архивированный журнальчик, на самом деле дела, требуется только для воссоздания архивной копии базы данных, журнальная информация при архивации может быть значительно сжата Внутренняя организация реляционных СУБД - Лекция Базы данных и файловые системы.



vnutrennij-mir-psihicheskogo-bolnogo-chem-on-otlichaetsya-ot-vnutrennego-mira-zdorovogo-psihicheski-cheloveka.html
vnutrennij-monolog-v-zhizni-rol-i-znachenie.html
vnutrennij-pr-sposoben-reshit-kommunikativnie-problemi-v-kompanii-referat.html