Теория и практика построения баз данных (1088289), страница 81
Текст из файла (страница 81)
Поэтому администратор базы ;шпных должен быть готов к тому, что базу данных придется восстанавливать, и должен иметь достаточное количество информации для диагностики и устранения проблемы, вызвавшей сбой. База данных наиболее подвержена сбоям после внесения изменений в ее структуру. Документирование В обязанности администратора по управлению структурой базы данных входит 1акже ведение документации.
Исключительно важно знать, какие модификации были произведены, когда и каким образом. Изменение в структуре базы данных может повлечь за собой о1пибку, которая не будет проявляться в течение шести месяцев; при отсутствии должного документирования изменений диагностика такой проблемы становится почти невозможной. Могут потребоваться десятки повторных прогонов, чтобы выявить момент, когда начали появляться первые < и митомы, и по этой причине важно также вести запись тестовых процедур и прогонов, сделанных для проверки произведенной модификации. Если используютгя стандартизированные тестовые процедуры, тестовые формы и методы ведения :енисей, запись тестовых результатов не должна занимать много времени.
Хотя ведение документации — процесс утомительный и бесконечный, затраченные на него усилия окупаются, когда приходит беда и документация оказывается тем, без чего невозможно решить серьезную 1и дорогостоящую) проблему. В настоящее время появляется много продуктов, облегчающих бремя ведения документации.
Многие САЯЕ-средства, например, можно использовать для документирования логической структуры базы данных, Для отслеживания изменений можно использовать программы контроля версий. Словари данных обеспечивают составление отчетов и применение других средств для чтения и интерпретации структуры информации в оазе данных.
Другая причина для тщательного документирования изменений в структуре базы данных состоит в том, чтобы должным образом использовать исторические данные. Если, например, маркетологи захотят проанализировать данные о продажах трехлетней давности, находившиеся в архивах в течение двух лет, им необходимо будет знать, какова была структура базы данных перед тем, как данные были отправлены в архив.
В ответе на этот вопрос могут помочь записи, отражающие изменения в структуре базы данных, Аналогичная ситуация возникает, когда для восстановления поврежденной базы данных приходится использовать резервную копию шестимесячной давности (хотя такого происходить не должно, пшогда это случается). Резервную копию можно использовать для реконструкции базы данных до того состояния, в котором она находилась на момент снятия этой копии. Затем можно в хронологическом порядке выполнить транзакции и произвести структурные изменения, чтобы восстановить базу данных до ее текущего состоянти.
В списке приведен перечень обязанностей администратора по управлению структурой базы данных. Участие в разработке базы данных и приложений + Помощь на стадии определения требований и оценки альтернатив. + Активная роль в проектировании и создании базы данных. 382 Глава 11, Многопользовательские базы данных управление параллельной обработкой 383 Помощь в изменении структуры базы данных + Поиск решений во взаимодействии с пользователями. + Оценка того, как планируемое изменение отразится на каждом пользователе. + Организация форума по вопросам конфигурирования. + Готовность к устранению проблем, возникающих после внесения изменений.
+ Ведение документации. Управление параллельной обработкой Меры по управленик> параллельной обработкой нацелены ва предотвращение непредусмотренного влияния действий одного пользователя на действия другого. Иногда цель состоит в том, чтобы в условиях параллельной обработки пользователь получил тот же результат, как и в случае, если бы он был единственным пользователем. В других случаях подразумевается, что действия различных пользователей будут влиять друг на друга, ио ожидаемым образом.
Например, пользователь, который ввел свой заказ в компьютерную систему, должен получить один и тот же результат независимо от того, сколько еше есть пользователей кроме него — ни одного или сотни. С другой стороны, пользователь, запрашивающий отчет о состоянии склада на самый последний момент, возможно, захочет получить информацию о незавершенных изменениях, начатых другими пользователями, даже если существует риск, что эти изменения впоследствии будут отменены. 1< сожалению, не существует способа управления параллельной обработкой, который бы одинаково хорошо подходил для всех ситуаций. Все эти способы предполагают некоторый компромисс.
Например, пользователь может весьма жестко управлять параллельной обработкой, заблокировав всю базу данных, но пока будут обрабатываться данные для этого пользователя, ни один другой пользователь не сможет ничего сделать. Такая защита надежна, но дорога. Как вы увидите, существуют и другие меры, которые труднее запрограммировать или реализовать, зато они повышают производительность. Есть также меры, максимизируюшие производительность прп низком уровне управления параллельной обработкой. При проектировании многопользовательских баз данных вам придется делать выбор среди этих компромиссов.
Необходимость в атомарных транзакциях В большинстве приложений баз данных работа пользователей организована в форме трги>закций (ггапзасг>опз), известных также как логические единицы работы (1оя>са! ип>гз о1 л ог)г, Ш%). Транзакция — это последовательность действий с базой данных, в которой либо все действия выполняются успешно, либо не выполняется ни одно нз них (в последнем случае база данных остается без изменений). Такая транзакция иногда называется агло чарной (ато>п>с), поскольку она выполняется как единое целое.
Рассмотрим следуюшу>о последовательность действий с базой данных, которые могут потребоваться прн регистрации нового заказа. 1. Изменить запись данного покупателя, увеличив сумму к оплате. 2. Изменить запись продавца, увеличив сумму комиссионных. 3. Вставить в базу данных запись о новом заказе. Предположим, что на последнем шаге нас постигла неудача — например, из:и недостатка файлового пространства.
Представьте себе недоразумение, когорое возникло бы, если бы выполнены были только первые два действия, но ис третье. Покупателю был бы выставлен счет за заказ, который он не получал, :> продавец получил бы комиссионные за товар, который он не отправлял покупателю, Ясно, что эти три действия должны выполняться как единое целое: либо все сразу, либо ни одного. На рис.
11.2 п 11.3 приведено сравнение результатов этих действий в виде по< лсдовательности независимых шагов (рис. 11.2) и в виде атомарной транзакции (рис. 11.3). Обратите внимание, что когда терпит неудачу одно из действий, составляющих атомарную транзакцию, то изменений в базе данных не производится. Также обратите внимание, что для указания рамок транзакции прикладная программа должна дать команды на начало транзакции (5(а>г Тгапзас(>оп), сохранение транзакции (Сотпп( Тгаозасйоп) и откат транзакции (ко11Ьас1> ТгапзасГ>оп). Конкретная форма этих команд различается в разных СУБД. Параллельная обработка транзакций К>и да в одно и то же время происходит обработка двух транзакций с базой данных, .>ти транзакции называются парвллельпыии тра»зокцияни (сопсиггепт ггапзасг>опз), Хотя у пользователей может создаваться впечатление, что их транзакции обрабатываются одновременно, это не может быть так, пбо процессор машины, обрабатывающей базу данных, способен выполнять только одну инструкцию в каждый момент времени.
Обычно транзакции выполняются попеременно, то есть операционная система переключает процессор между несколькими задачами, так что за заданный промежуток времени выполняется некоторая часть каждой из них. 1)то перекл>оченне между задачами происходит столь быстро, что два человека, сидящие бок о бок перед двумя компьютерами, обрабатывающими одну и ту же базу данных, могут подумать, что их транзакции выполняются одновременно; и реальности же их транзакции перемежаются. На рнс.
11А показаны две параллельные транзакции. Транзакция пользователя А считывает элемент 100, изменяет его и записывает обратно в базу данных. Транзакция пользователя В выполняет те же самые дсйствия, но с элементом 200. 11роцессор обрабатывает транзакцию пользователя А, пока не произойдет прерывание ввода-вывода или какая-либо иная задержка пользователя А. Тогда процессор переключается на пользователя В и обрабатывает его транзакцию до прихода преръ>вания, после чего операционная система передает управление обратно транзакции первого пользователя. Пользователям обработка кажется одновременной, но на самом деле она попеременная, или параллельная. ш о Ф 2 с Ф с Я а с а П Ф О й о о о с Хо ш Я Ыл й" й о д сс о ай с а 3 Ф ~ олой с аз с оса с ай а Шо сл йа Г> ю% е.
С~ с о о с О с л й Ф о с э Ф с о Ъ Ь о с о о Ю СЧ \а с о о л с л с, о Ф ,с ок о Ю а с л с ~~ ФФ Я $ 8 Ф с с й о с о 5 о О. с =Г О ш $ О. Е с о ш о О. Х с ш к х ш Х с ш Х х ш Х с ая о ~а о Ю Ю о о с ш ш л Х ай ш Фс с Ф ц о Д аа ~Хай о ш и. ш Х ай ш Ф с й Ф $ хц о о о о о о <Ч о Ю о о о о ю о ю о й о о о о о о о о л о о о о ю о Г4 4'Ъ Ф 3 Фх сс цш а ФХ сй~ <-Ф.~л с», с1о ла Ф Б с й й с Ф о с а с с о Х х Ф О.
с с О с Ф с о л с о Ф с Ф с ° ° ° Ф ш 3с~ссМ аалФлФло лсйссйс йололол ХС1ФС1ФССФ Д аа < х"- о о с й с о 5 п 5 й с о Ф $' о с о о с з х й и х Пользователь В Пользователь А Попьзоватепь А Пользователь В Порядок обработки иа сервере базы данных Порядок обработки иа сервере базы данных Обратите внимание: изменение и запись иа шагах 3 и 4 оказываются потерянными Рис.
11.5. Проблема потерянного обновления 386 Глава 1!.Многопользовательские базы данных Проблема потерянного обновления Параллельная обработка, изображенная на рпс. 11.4, не вызывает проблем, поскольку пользователи обрабатывают различные данные. Но предположим, что оба пользователя хотят обратиться к влез|ситу 100. Например, пользователь А хочет заказать пять единиц товара 100, а пользователь  — три елпнпцы этого же товара, Рио.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
