Ћекции.ќрг


ѕоиск:




 атегории:

јстрономи€
Ѕиологи€
√еографи€
ƒругие €зыки
»нтернет
»нформатика
»стори€
 ультура
Ћитература
Ћогика
ћатематика
ћедицина
ћеханика
ќхрана труда
ѕедагогика
ѕолитика
ѕраво
ѕсихологи€
–елиги€
–иторика
—оциологи€
—порт
—троительство
“ехнологи€
“ранспорт
‘изика
‘илософи€
‘инансы
’ими€
Ёкологи€
Ёкономика
Ёлектроника

 

 

 

 


Ќепосредственное управление данными во внешней пам€ти




‘ункци€ непосредственного управлени€ данными во внешней пам€ти включает обеспечение необходимых структур внешней пам€ти (посто€нных запоминающих устройств Ч как правило, магнитных дисков) как дл€ хранени€ данных, непосредственно вход€щих в базу данных, так и дл€ служебных целей, например дл€ ускорени€ доступа к данным в некоторых случа€х (обычно дл€ этого используютс€ индексы). ѕричем пользовател€м базы данных в общем случае не нужно знать, использует ли —”Ѕƒ файловую систему и если использует, то как организованы файлы. ќбычно —”Ѕƒ поддерживает собственную систему именовани€ объектов Ѕƒ. ¬ зависимости от способа реализации —”Ѕƒ может либо использовать возможности существующих файловых систем, либо работать с устройствами внешней пам€ти на низком уровне.

 

 

”правление буферами оперативной пам€ти

ќбъЄм информации, хран€щейс€ в базе данных, с которой работает —”Ѕƒ, обычно достаточно велик и практически всегда превышает доступный объем оперативной пам€ти. ѕри этом врем€ доступа к данным, хран€щимс€ в оперативной пам€ти, существенно меньше, чем к данным, хран€щимс€ на устройствах внешней пам€ти. ќчевидно, что если при обращении к любому элементу данных будет производитс€ обмен с внешней пам€тью, то вс€ система будет работать со скоростью устройства внешней пам€ти.

”величени€ скорости обмена данными ћожно достичь, использу€ буферизацию данных в оперативной пам€ти. ѕри этом, даже если операционна€ система производит общесистемную буферизацию (как в случае ќ— UNIX), этого недостаточно дл€ целей —”Ѕƒ, котора€ располагает гораздо большей информацией о полезности буферизации той или иной части базы данных. ѕоэтому в —”Ѕƒ обычно поддерживаетс€ собственный набор буферов оперативной пам€ти с собственным механизмом замены буферов.

примечание

следует отметить, что существует направление развити€ —”Ѕƒ, ориентированное на посто€нное присутствие в оперативной пам€ти всей информации из базы данных. это направление основываетс€ на предположении, что в будущем объем оперативной пам€ти компьютеров будет настолько велик, что буферизаци€ станет не нужна. если исходить из темпов снижени€ цен на оперативную пам€ть, то такие —”Ѕƒ действительно могут стать актуальными в достаточно недалеком будущем.

”правление транзакци€ми

“ранзакцией называетс€ последовательность операций над базой данных, рассматриваемых —”Ѕƒ как единое целое. ≈сли все операции успешно выполнены, то транзакци€ также считаетс€ успешно выполненной и —”Ѕƒ фиксирует (COMMIT) все изменени€ данных, произведенные этой транзакцией (то есть заносит изменени€ во внешнюю пам€ть). ≈сли же хот€ бы одна операци€ транзакции заканчиваетс€ неудачей, то транзакци€ считаетс€ невыполненной и производитс€ откат (ROLLBACK) Ч отмена всех изменений данных, произведенных в ходе выполнени€ транзакции, и возврат базы данных к состо€нию до начала выполнени€ транзакции. ”правление транзакци€ми необходимо дл€ поддержани€ логической целостности базы данных. ѕоддержка механизма транзакций €вл€етс€ об€зательным условием даже однопользовательских, а тем более дл€ многопользовательских —”Ѕƒ. “о свойство, что кажда€ транзакци€ начинаетс€ при целостном состо€нии базы данных и оставл€ет это состо€ние целостным после своего завершени€, делает очень удобным использование пон€ти€ транзакции как единицы активности пользовател€ по отношению к базе данных. ѕри соответствующем управлении параллельно выполн€ющимис€ транзакци€ми со стороны —”Ѕƒ каждый из пользователей может, в принципе, ощущать себ€ единственным пользователем —”Ѕƒ.

— управлением транзакци€ми в многопользовательской —”Ѕƒ св€заны важные пон€ти€ сериализации транзакций и сериального плана выполнени€ смеси транзакций. ѕод сериализаци€ми параллельно выполн€ющихс€ транзакций понимаетс€ такое планирование их работы, при котором суммарный результат смеси транзакций эквивалентен результату их некоторого последовательного выполнени€. —ериальный план выполнени€ смеси транзакций - это такой план, который приводит к сериализации транзакций. ѕоп€тно, что если удаетс€ добитьс€ действительно сериального выполнени€ смеси транзакций, то дл€ каждого пользовател€, по инициативе которого образована транзакци€, присутствие других транзакций будет незаметно (если не считать некоторого замедлени€ работы по сравнению с однопользовательским режимом).

—уществует несколько базовых алгоритмов сериализации транзакций. ¬ централизованных —”Ѕƒ наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов базы данных. ѕри использовании любого алгоритма сериализации возможны конфликты между несколькими транзакци€ми по доступу к объектам базы данных, ¬ этом случае дл€ поддержани€ сериализации необходимо выполнить откат одной или нескольких транзакций. Ёто один из случаев, когда пользователь многопользовательской —”Ѕƒ может реально (и достаточно непри€тно) ощутить присутствие в системе транзакций других пользователей.

 

∆урнализаци€

ќдним из основных требований к —”Ѕƒ €вл€етс€ надежность хранени€ данных во внешней пам€ти. ѕод надежностью хранени€ понимаетс€ то, что —”Ѕƒ должна быть в состо€нии восстановить последнее согласованное состо€ние Ѕƒ после любого аппаратного или программного сбо€. јппаратные сбои обычно подраздел€ютс€ на два вида:

м€гкие сбои св€заны с внезапной остановкой работы компьютера. ќбычно €вл€ютс€ следствием внезапного выключени€ питани€ или "зависани€" операционной системы (что особенно характерно дл€ операционных систем Windows);

жесткие сбои характеризуютс€ потерей информации на носител€х внешней пам€ти.

ѕрограммные сбои обычно возникают вследствие ошибок в программах. ѕричем эти ошибки могут быть как в самой —”Ѕƒ, что может привести к аварийному завершению ее работы, так и в пользовательской программе. ѕервый случай можно рассматривать как разновидность м€гкого аппаратного сбо€. ¬о втором случае незавершенной остаетс€ только одна транзакци€.

¬ любом случае дл€ восстановлени€ информации в базе данных необходимо иметь некоторую дополнительную информацию. “аким образом, дл€ поддержани€ надежности хранени€ данных требуетс€ избыточность данных. ѕричем та часть информации, котора€ используетс€ дл€ восстановлени€, должна хранитьс€ особо надежно. Ќаиболее распространенным методом поддержани€ такой избыточной информации €вл€етс€ ведение журнала изменений базы данных. ∆урнал представл€ет собой особую часть базы данных, недоступную пользовател€м —”Ѕƒ и поддерживаемую с особой тщательностью (иногда используютс€ две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменени€х основной части базы данных. ¬ разных —”Ѕƒ изменени€ базы данных журнализируютс€ на разных уровн€х: иногда запись в журнале соответствует некоторой логической операции изменени€ базы данных, иногда Ч минимальной внутренней операции модификации страницы внешней пам€ти. ћогут также использоватьс€ одновременно оба подхода. ¬о всех случа€х придерживаютс€ стратегии Ђупреждающейї записи в журнал (так называемого протокола Write Ahead Log Ч WAL). Ќесколько утрированно можно сказать, что эта стратеги€ заключаетс€ в том, что запись об изменении любого объекта базы данных должна быть занесена в журнал до того, как будет выполнено и зафиксировано изменение этого объекта. ≈сли в —”Ѕƒ корректно соблюдаетс€ протокол WAL, то с помощью журнала можно решить все проблемы восстановле≠ни€ базы данных после любого сбо€.

—ама€ проста€ ситуаци€ восстановлени€ Ч индивидуальный откат транзакции. —трого говор€, дл€ этого не требуетс€ общесистемный журнал изменений базы данных. ƒостаточно дл€ каждой транзакции поддерживать локальный журнал операций модификации базы данных, выполненных в этой транзакции, и производить откат транзакции путем выполнени€ обратных операций, следу€' от конца локального журнала. ¬ некоторых —”Ѕƒ так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполн€ют по общесистемному журналу, дл€ чего все записи, относ€щиес€ к одной транзакции, св€зывают обратным списком (от конца к началу). ѕри м€гком сбое во внешней пам€ти основной части базы данных могут находитьс€ объекты, модифицированные транзакци€ми, не закончившимис€ к моменту сбо€, и могут отсутствовать объекты, модифицированные транзакци€ми, которые к моменту сбо€ успешно завершились (по причине использовани€ буферов оперативной пам€ти, содержимое которых при м€гком сбое пропадает). ѕри соблюдении протокола WAL во внешней пам€ти журнала должны гарантированно находитьс€ записи, относ€щиес€ к операци€м модификации обоих видов объектов. ÷елью процесса восстановлени€ после м€гкого сбо€ €вл€етс€ приведение внешней пам€ти основной части базы данных в такое состо€ние, которое возникло бы при фиксации во внешней пам€ти изменений всех завершившихс€ транзакций и которое не содержало бы никаких следов незаконченных транзакций. ƒл€ того чтобы этого добитьс€, сначала производ€т откат незавершенных транзакций, а потом повторно воспроизвод€т те операции завершенных транзакций, результаты которых не отображены во внешней пам€ти.

ƒл€ восстановлени€ базы данных после жесткого сбо€ используют журнал и архивную копию базы данных. јрхивна€ копи€ Ч это полна€ копи€ базы данных к моменту начала заполнени€ журнала (хот€ имеетс€ много вариантов трактовки смысла архивной копии). ƒл€ нормального восстановлени€ базы данных после жесткого сбо€, естественно, необходимо, чтобы журнал не пропал. “огда восстановление базы данных состоит в том, что, исход€ из архивной копии, по журналу воспроизводитс€ работа всех транзакций, которые закончились к моменту сбо€. ¬ принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершени€ восстановлени€. ќднако в реальных системах это обычно не делаетс€, поскольку процесс восстановлени€ после жесткого сбо€ €вл€етс€ достаточно длительным.

 





ѕоделитьс€ с друзь€ми:


ƒата добавлени€: 2015-11-05; ћы поможем в написании ваших работ!; просмотров: 723 | Ќарушение авторских прав


ѕоиск на сайте:

Ћучшие изречени€:

¬ моем словаре нет слова Ђневозможної. © Ќаполеон Ѕонапарт
==> читать все изречени€...

1218 - | 1194 -


© 2015-2024 lektsii.org -  онтакты - ѕоследнее добавление

√ен: 0.012 с.