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

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


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

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

  1. Временные отметки

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

Временная отметка - это уникальный идентификатор, который СУБД создаёт для обозначения относительного момента запуска транзакции. Временная отметка может быть создана с помощью системных часов или путём присвоения каждой следующей транзакции очередного номера (SCN - system change number). Каждая транзакция Ti имеет временную отметку ti, и каждый элемент данных в БД (запись или блок) имеет две отметки: tread(x) - временная отметка транзакции, которая последней считала элемент х, и twrite(x) - временная отметка транзакции, которая последней записала элемент х.

При выполнении транзакции Ti система сравнивает отметку ti и отметки tread(x) и Шгив(х)элемента x для обнаружения конфликтов:

  1. для читающей транзакции Ti: если ti <twrite(x), то элемент

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

  1. для пишущей транзакции:

  • если ti< tread(x), то элемент данных х считан более поздней транзакцией. Если транзакция Тизменит значение элемента х, то в другой транзакции может возникнуть ошибка.

  • если ti< twrite(x), то элемент х перезаписан более поздней транзакцией, и транзакция Тпытается поместить в БД устаревшее значение элемента х.

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

  1. Многовариантность

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

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

При использовании алгоритма многовариантности каждый блок данных хранит номер последней транзакции, которая модифицировала данные, хранящиеся в этом блоке (SCN - system change number). И каждая транзакция имеет свой SCN. При чтении данных СУБД сравнивает номер транзакции и номер считываемого блока данных:

  • если блок данных не модифицировался с момента начала чтения, то данные считываются из этого блока;

  • если данные успели измениться, то система обратится к сегменту отката и считает оттуда значения данных, относящиеся к моменту начала чтения.

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

"Стыдно не уметь защищать себя рукою, но ещё более стыдно не уметь защищать себя словом". Аристотель, древнегреческий философ

  1. ЗАЩИТА ДАННЫХ В БАЗАХ ДАННЫХ

Защита данных - это организационные, программные и технические методы и средства, направленные на удовлетворение ограничений, установленных для типов данных или экземпляров типов данных в СОД [6].

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

  • контроль достоверности данных с помощью ограничений целостности;

  • обеспечение безопасности данных (физической целостности данных);

  • обеспечение секретности данных.

  1. Обеспечение целостности данных

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

Рассмотрим различные типы ограничений целостности в языке SQL:

  1. Уникальность значения первичного ключа (PRIMARY KEY).

  2. Уникальность ключевого поля или комбинации значений ключевых полей:

UNIQUE(A),

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

(1,2 - явные структурные ограничения целостности.)

  1. Обязательность/необязательность значения (NOT NULL/NULL).

  2. Задание диапазона значений атрибута Field:

CHECK(field BETWEEN min_value AND max_value)

  1. Задание взаимоотношений между значениями атрибутов Fieldl и Field2:

CHECK (fieldl @ field2), где @ - оператор отношения (например, знак ">") .

  1. Задание списка возможных значений (констант) для атрибута Field:

CHECK (field IN (valuel, value2,.., valueN)) .

  1. Определение формата атрибута Field (даты, числа и др.). Например:

CHECK (field LIKE '_ _ _-_ _-_ _') — формат телефонного номера

  1. Определение домена атрибута на основе значений другого атри Определение формата атрибута Field (даты, числа и др.). Например:

  2. бута: множество значений некоторого атрибута отношения является подмножеством значений другого атрибута этого или другого отношения (внешний ключ, FOREIGN KEY)./li>

(3.-8. - явные ограничения целостности на значения данных.)

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

  2. Ограничения на параллельное выполнение операций (механизм транзакций) и проверка ограничений целостности после окончания внесения взаимосвязанных изменений.

Реализация ограничений целостности возлагается на СУБД или выполняется с помощью специальных программных модулей.

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

  1. Обеспечение безопасности данных

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

  1. Виды сбоев

В СУБД предусмотрены специальные механизмы, призванные нивелировать последствия сбоев в работе базы данных. Рассмотрим наиболее типичные сбои и способы защиты от них:

  1. Сбой предложения.

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

  1. Сбой пользовательского процесса.

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

  1. Сбой процесса сервера.

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

  1. Сбой носителя (диска).

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

  1. Ошибка пользователя.

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

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

  1. Средства физической защиты данных

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

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

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

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

Периодичность резервного копирования определяется администратором системы и зависит от многих факторов: объём БД, интенсивность запросов к БД, интенсивность обновления данных и др. Как правило, технология проведения резервного копирования такова:

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

  1. Восстановление базы данных

В том случае, если нельзя восстановить БД после сбоя автоматически, восстановление БД выполняется в два этапа:

  1. перенос на рабочий диск резервной копии базы данных (или той её части, которая была повреждена);

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

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

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

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


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