лекция 10

2. потребители изолация.

3. сериализация сделки

1. транзакции и цялост на базите данни.

Поддържането механизъм сделка - индикатор за нивото на развитие на базата данни. Правилната поддръжка на сделката в същото време е в основата на целостта на бази данни (и следователно сделката е съвсем уместно в един потребител лична база данни), както и в основата на изолация на потребителя в системи с много потребители. Често тези два аспекта се разглеждат отделно, но в действителност те са взаимосвързани, тъй като ще бъдат показани в тази глава.

Имайте предвид, че въпреки че от гледна точка на целостта на механизма за сделка на база данни трябва да се поддържа в личния базата данни, на практика това обикновено не се извършва. Ето защо, по време на прехода от лична до много потребители СУБД потребители са изправени пред необходимостта от ясна представа за естеството на сделката.

Съгласно сделката означава неделим от гледна точка на въздействие върху последователността на база данни за манипулиране на данни отчети (четене, изтриване, вмъкване, обновяване) такава, че или на резултатите от всички оператори, участващи в сделката, се показват в базата данни, или на въздействието на всички тези твърдения е напълно отсъства. Лозунгът на сделката - "Всичко или нищо": при сключване на сделка, COMMIT изявление на гарантиран фиксиран от външната памет (смисъл на извършване - "поправяне" на резултатите от сделката); при завършване на оператора на сделка резултати ROLLBACK гарантиращи липсата на външна памет (значението на думата намаление на цените - да се елиминират резултатите от сделката).

1. транзакциите и целостта на базата данни

Концепцията за сделка е пряко свързано с концепцията за целостта на базата данни. Много често, базата данни може да има такава цялост ограничения, което е просто невъзможно да не се скъсат, се изпълняват само една промяна в базата данни на оператора. Например, в целостта на служителите на базата данни отдел данни е естествено рестрикционни OTD_RAZMER стойностите на съвпадение в отдел кортеж атрибут отношения, описващ разделени (например отделена 320), с броя на кортежи на служителите на връзки с такава, че стойността на атрибута е SOTR_OTD_NOMER 320. Както и в този случай да се да работи в отдела на 320 нов служител? Без значение каква работа ще се извършва на първо място, поставяне на нова кортеж срещу членове или модифициране на съществуващите кортеж във връзка разделени, след извършване на базата данни е в състояние на непълноти.

Следователно, за да се придържат към тези ограничения за интегритет допускат нарушаването им в рамките на сделка, с уговорката, че при приключване на условията за почтеност сделка са изпълнени. При системи с модерни средства за контрол и наблюдение на целостта на всяка транзакция започва в последователно състояние и базата данни трябва да напусне този държавен интегритет след приключването му. Неспазването на това изискване води до факта, че вместо да определи резултатите от сделката настъпва отвали (т. Е. Вместо COMMIT конструкцията се изпълнява оператор ROLLBACK) и базата данни все още е в състоянието, в което е имало в началото на сделката, т.е.. Д. В последователно състояние ,

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

Deferrable цялост ограничение - то е ограничено до базата данни, а не на всяка отделна сделка. По подразбиране, тези ограничения се проверяват в края на сделката, както и нарушаването им е автоматична подмяна на COMMIT изявление в отчета за ROLLBACK. Въпреки това, в някои системи, тя поддържа специален оператор насилствено проверка на целостта ограничения в рамките на една сделка. Ако след като операторът се установи, че целостта на условията не са изпълнени, потребителят може да извърши намаление на цените, или да се опита да премахне причините за непълнота състояние на база данни в рамките на една транзакция (очевидно, това е смислено само когато използвате интерактивен режим).

И още един забележка. От гледна точка на външното представителство при приключване на сделка, проверява всички deferrable ограничения за интегритет, определени в базата данни. Въпреки това, когато прилагането потърси по време на сделката динамично разпределяне на тези ограничения за интегритет, които наистина ще бъдат разбити. Например, когато в него не извършващи транзакции на база данни, тийм-РАЗДЕЛИ извършени вмъкване оператори или изтриване на кортежи на отношения СЛУЖИТЕЛИ, проверката за цялост не се изисква ограничение цитирани по-горе (и проверката на тези ограничения да причини доста много работа).

2. Потребителите на изолация

В системи с много потребители с една и съща база данни в същото време могат да се справят множество потребители или приложения. Крайната цел на системата е да се гарантира, изолацията на потребителите, т.е.. Д. Създаването на надеждна и достоверна илюзия, че всеки потребител работи само с базата данни.

Във връзка с имуществото на запазване целостта на сделките, за бази данни са подходящи за употреба изолатори. В действителност, ако всяка сесия със свързаните с база данни за сделката, всеки потребител започва с последователен състояние на базата данни, т.е.. Д. С състоянието, в което на базата данни може да бъде, дори ако потребителят работи с нея насаме.

При спазване на задължителното условие, за да се запази целостта на базата данни, на следните нива на изолация сделка:

Имайте предвид, че е възможно да се осигури различни нива на изолация за различни сделки, работещи в системата на база данни (по-специално, съответните оператори са предоставени в стандартен SQL 2). Както вече писахме, на първо ниво е достатъчно, за да се запази целостта. Има редица приложения, за които на първо ниво е достатъчно (например, приложения или системни статистика полезност за които неточност индивидуални данни е от значение). По този начин е възможно да се намали значително въздушната и подобряване на цялостната ефективност на база данни.

За по-фините проблемите на изолацията сделка е т.нар проблема kortezhey- "фантоми", което води до ситуация, в която е и в противоречие с изолацията на потребителя. Да разгледаме следния сценарий. 1 изпълнява операция проба кортежи на връзка с вземане на проби състояние R S на (т. Е. част от избраните кортежи на връзка R, отговарящи S). Преди приключване на сделката за транзакции 1 2 вложки ново съотношение кортеж R К, отговаря на условието S, както и успешно завършено. Транзакция 1 повторно изпълнява оператор А, и резултатът е кортеж, което отсъства в първото изпълнение на оператора. Разбира се, това положение е в противоречие с идеята за изолация сделка, а дори може да се случи на третото ниво на изолация сделка. За да се избегне кортежи фантом, това изисква по-висок "логично" сделка синхронизация ниво. Идеи като синхронизация (синхронизация предикат улавя) са познати отдавна, но не се изпълняват в повечето системи.

3. сериализация сделки

Ясно е, че за да се постигне изолация транзакции в базата данни трябва да се използват всякакви методи за регулиране на споделянето на сделка.

План (метод) изпълнява набор от сделки се нарича сериали, ако резултатът от съвместното изпълнение на сделката е еквивалентно на резултат от последователното прилагане на една и съща сделка.

Сериализирането на сделката - това е механизмът на тяхното изпълнение от някои издания план. Предоставянето на такъв механизъм е основната функция на компонента на база данни за управление на сделка. Системата, която подкрепя сериализация на изолацията на сделката дава реални потребители.

Основният проблем е реализуема при избора на метод за сериализиране набор от операции, което не е твърде ще ограничи тяхната паралелизъм. Идва на ум тривиално решение, е наистина на последователното изпълнение на сделката. Но има ситуации, в които операторите могат да изпълняват различни операции в произволен ред запазване seriality. Примери могат да бъдат прочетени само от сделките, както и сделки, които не противоречат на обекти в базата данни.

Между сделки може да има следните видове конфликти:

Практически методи Сериализирането сделки се основава на сметката на тези конфликти.