Главная страница

Физическая организация данных


Скачать 487.44 Kb.
НазваниеФизическая организация данных
Дата23.02.2018
Размер487.44 Kb.
Формат файлаdocx
Имя файлаdb.docx
ТипДокументы
#37060
страница4 из 16
1   2   3   4   5   6   7   8   9   ...   16

Поставки

Восход


м


20 Zoom А4


1100


Партия



20 SO

Поо


Комус


Zoom


I lap 111Я


Партия


10 Восход А4

Товары - Поставки

Рис.4.8. Некластеризованные (а) и кластеризованные (б) данные

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

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

Если все данные, относящиеся к одному значению кластерного ключа, не помещаются в одном блоке, то выделяется новый блок памяти и предыдущий блок хранит ссылку на него. Но если система позволяет из-менять размер блока (в частности, СУБД Oracle), при создании кластера желательно установить размер блока исходя из оценки среднего объёма записей с одинаковыми значениями кластерного ключа. Если же записи с одинаковым значением КК занимают только часть блока (например, в среднем 1К при размере блока 4К), то при создании таблицы кластера можно указать количество значений КК на один блок.

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

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

  • Уменьшается время соединения таблиц по значению кластерного ключа.

  • Каждое значение кластерного ключа хранится только один раз, за счёт чего достигается экономия памяти.

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

        1. Использование кластеризации

Кластер создаётся с помощью команды CREATE CLUSTER:

create cluster <имя_кластера> (<имя_поля1> <тип_поля1> [,<имя_поля2> <тип_поля2> ,...] );

Здесь в скобках перечисляются поля кластерного ключа. Затем создаются таблицы в кластере: create table <имя_таблицы> (<список полей таблицы>) cluster <имя_кластера> (<список полей КК>) ;

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

create index <имя_индекса> on cluster <имя_кластера>;

Поля для индексирования не указываются, потому что кластерный индекс создаётся по полям кластерного ключа. В отличие от обычного индекса в кластерном индексе null-значения индексируются.

Кластеры обычно строятся для таблиц, часто используемых в соеди-нении друг с другом, например, связанных отношением "один-ко-многим". Не стоит создавать кластер в следующих случаях:

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

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

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

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

Обратите внимание:

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

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

"Кто хочет работать - ищет средства, кто не хочет - причины".

С.П. Королёв, советский ученый и

конструктор в области космонавтики

  1. МНОГОПОЛЬЗОВАТЕЛЬСКИЙ ДОСТУП К ДАННЫМ

Данные в БД являются разделяемым ресурсом. Многопользовательский доступ к данным подразумевает одновременное выполнение двух и более запросов к одним и тем же объектам данных (таблицам, блокам и т.п.). Для организации одновременного доступа не обязательно наличие многопроцессорной системы. На однопроцессорной ЭВМ запросы выполняются не одновременно, а параллельно. Для каждого запроса выделяется некоторое количество процессорного времени (квант времени), по истечении которого выполнение запроса приостанавливается, он ставится в очередь запросов, а на выполнение запускается следующий по очереди запрос. Т.о., процессорное время делится между запросами, и создаётся иллюзия, что запросы выполняются одновременно.

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

    1. Механизм транзакций

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

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

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

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

запоминания части изменений, произведённых транзакцией. До тех пор, пока транзакция не завершена, её можно "откатить", т.е. отменить все сделанные командами транзакции изменения. Успешное выполнение

транзакции (фиксация) означает, что все команды транзакции проанализированы, интерпретированы как правильные и безошибочно исполнены.

  1. Согласованность (Consistency): транзакция начинается на согласованном множестве данных и после её завершения множество данных согласовано. Состояние БД является согласованным, если данные удовлетворяют всем установленным ограничениям целостности и относятся к одному моменту в состоянии предметной области.

  2. Изолированность (Isolation), т.е. отсутствие влияния транзакций друг на друга. (На самом деле это влияние существует и регламентируется стандартом: см. раздел 5.3. "Уровни изоляции транзакций”).

  3. Устойчивость (Durability): результаты завершённой транзакции не могут быть потеряны. Возврат БД в предыдущее состояние может быть достигнут только путём запуска компенсирующей транзакции.

Транзакции, удовлетворяющие этим свойствам, называют ACID-транзакциями (по первым буквам названий свойств).

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

  • фиксация транзакции (запоминание изменений): COMMIT [WORK];

  • откат транзакции (отмена изменений): ROLLBACK [WORK];

  • создание точки сохранения: SAVEPOINT <имя_точки_сохранения>;

(Ключевое слово WORK необязательно). Для фиксации или отката транзакции система создаёт неявные точки фиксации и отката (рис. 5.1).



Рис.5.1. Неявные точки фиксации и отката транзакции




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

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

Сегмент отката (rollback segment, RBS) - это специальная область памяти на диске, в которую записывается информация обо всех текущих (незавершённых) изменениях. Обычно записывается "старое" и "новое" содержимое изменённых записей, чтобы можно было восстановить прежнее состояние БД при откате транзакции (по команде rollback) или при откате текущей операции (в случае возникновения ошибки). Данные в RBS хранятся до тех пор, пока транзакция, изменяющая эти данные, не будет завершена. Потом они могут быть перезаписаны данными более поздних транзакций.

Команда savepoint запоминает промежуточную "текущую копию" состояния базы данных для того, чтобы при необходимости можно было вернуться к состоянию БД в точке сохранения: откатить работу от текущего момента до точки сохранения (rollback to <имя_точки>) или зафиксировать работу от начала транзакции до точки сохранения (commit to <имя_точки>). На одну транзакцию может быть несколько точек сохранения (ограничение на их количество зависит от СУБД).

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

  • номер транзакции (номера присваиваются автоматически по возрастанию);

  • состояние транзакции (завершена фиксацией или откатом, не завершена, находится в состоянии ожидания);

  • точки сохранения (явные и неявные);

  • команды, составляющие транзакцию, и проч.

Начало транзакции соответствует появлению первого исполняемого SQL- оператора. При этом в журнале появляется запись об этой транзакции.

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

  • Поступила команда commit (результаты транзакции фиксируются).

  • Поступила команда rollback (результаты транзакции откатываются).

  • Успешно завершена программа (exit, quit), в рамках которой выполнялась транзакция. В этом случае транзакция фиксируется автоматически.

  • Программа, выполняющая транзакцию, завершена аварийно (abort). При этом транзакция автоматически откатывается.

Примечания:

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

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

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

  • при поступлении команды commit,

  • при переполнении буфера данных,

  • в момент заполнения очередного файла журнала транзакций,

  • через три секунды со времени последней записи на диск.

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

Таким образом, при использовании протокола WAL измененные данные почти сразу попадают в базу данных, ещё по поступления команды commit. Поэтому фиксация транзакции чаще всего заключается в следующем:

  1. Изменения, внесённые транзакцией, помечаются как постоянные.

  2. Уничтожаются все точки сохранения для данной транзакции.

  3. Если выполнение транзакций осуществляется с помощью блокировок, то освобождаются объекты, заблокированные транзакцией (см. раздел 5.5).
  4. 1   2   3   4   5   6   7   8   9   ...   16


написать администратору сайта