Транзакциите (компютър)

В този план, има и други приложения, вижте. Транзакциите (пояснение).

Транзакциите (Engl сделка.) - група от последователни операции в базата данни. който е логическа единица работа с данните. Сделката може да се извърши или изцяло и успешно поддържане на целостта на данните и каквито и други сделки, паралелно или не се извършва на всички, а след това не трябва да повлияе. Операциите, обработени системи по транзакцията. в процеса на което се създава историята на транзакциите.

Разграничаване последователни (нормален), паралелна и разпределена транзакция. Разпределени транзакции включват използването на повече от една система сделка и изискват много по-сложна логика (например, двуфазов протокол - двуфазен протокол за записване на транзакция). Също така в някои системи изпълняват самостоятелно сделка, или под-сделки, които са самостоятелна част от сделката родител.

Пример: необходимо е да се прехвърли към профила номер банка 5 поради броя 7 в размер на 10 парични единици. Това може да се постигне, например, намалява последователност от действия:

Прочетете остатъка от номера на сметката 5.
Намаляване на баланса на 10 парични единици.
Запазване на новия баланс на номера на сметката 5.
Прочетете остатъка от номера на сметката 7.
Увеличаване на баланса на 10 парични единици.
Запазване на новия баланс на номера на сметката 7.

Тези стъпки представляват логическа единица работа "паричен превод между сметки", и по този начин са транзакция. Ако анулирате тази транзакция, например, в средата, а не за да отмените всички промени, то е лесно да се оставят на броя на титуляра на сметката 5 без 10 единици, а на собственика на номера на сметката, 7, няма да ги вземем.

Един от най-общ набор от изисквания към системата за сделка и транзакция е набор от киселина (валентност, последователност, изолация, Дълготрайност). изисквания киселина се формулира най-вече в края на 1970-те, Джим Грей [1]. Все пак, има специализирани системи с отслабена транзакции свойства [2].

нива на изолация на транзакция

В идеалния случай, сделка, различни потребители трябва да се извършва така, че да се създаде илюзията, че потребителят на сегашната сделка - само. В действителност, обаче, от съображения за ефективност и за извършване на някои специфични задачи, осигуряват данни за различни нива на изолация сделка.

Нивата са описани, за да увеличи изолацията на сделката и, съответно, на надеждността на данните.

0 - Четене на непризнати данни (мръсна прочитания) (Прочетена Uncommitted, Dirty Read) - четене неангажирани промени, както в своите сделки и едновременни операции. Няма гаранция, че данните, променени от други сделки, няма да бъдат променяни по всяко време, в резултат на намаление на цените, така че това четене е потенциален източник на грешка. Промените не могат да бъдат загубени (загубили промени) може да чете и неповторимо фантоми.
1 - четене проверени данни (Прочетена Ангажиран) - четете всички промени своята сделка и едновременни операции, записани промени. Loose промени и мръсни четения не са позволени, може да има неповторимо чете и призраци.
2 - при повторно четене (при повторно четене, Snapshot) - четене на всички промени своята сделка, всички промени, направени паралелни транзакции след началото му, не е в наличност. Loose промяна, мръсни и неповторимо четене е невъзможно, възможни фантоми.
3 - Serializable (Serializable) - Serializable сделки. В резултат на паралелно изпълнение Serializable сделка с други сделки следва да бъде логически еквивалентни на резултатите от всички да се изпълняват последователно. синхронизационни проблеми не възникват.

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

Нивото на изолация транзакция база данни може да бъде избран за всички транзакции, едновременно и за конкретна сделка. По подразбиране повечето бази данни, използвани от нивото 1 (Прочетена Ангажирани). Ниво 0 се използва основно за проследяване на промените дълги сделки или прочетете рядко променящите се данни. Нива 2 и 3 се използват за взискателни изолация сделка.

Пълното прилагане на Нива на изолация ACID свойства и не е тривиална задача. Обработка на входящите данни води в голям брой малки промени, включително актуализиране на двете таблици и индекси. Тези промени имат потенциала да се провали: свободно място на диска, операцията отнема твърде много време (изчакване) и т.н. Системата трябва да бъде в случай на повреда правилно да се върне в базата данни за състоянието преди сделката ...

Първите търговски бази данни (например, IBM DB2), използвани изключително от ключалката на достъп до данни за КИСЕЛИНА свойства. Но голям брой брави, което води до значително намаляване на производителността. Има два популярната фамилия решения на този проблем, което намалява броя на брави:

По-нататъшното развитие на технологиите за управление на база данни е довело до появата на заключване без технологии. Идеята за контролиране на едновременен достъп чрез клеймото (клеймото базирани контрол конкурентност) е разработен и доведе до появата на мулти-версия MVCC архитектура. Тези технологии не изискват никакви промени в сеч, никакви страници сянка. Архитектура, приложена в Oracle 7.x и по-високи записи стари версии на страници в специално намаление на цените сегмент, но те все още са на разположение за справка. Ако показанията се пада на страницата на сделката, датата и часа е по-нова от началото на четенето, данните са взети от сегмента на намаление на цените (т.е., "стара" версия). В подкрепа на тази работа се извършва регистър на транзакциите, но за разлика от "превантивна сеч", тя не съдържа данни. Работата с него е съставена от три логически стъпки:

Запис намерение да направи някои операции
За изпълнение на задача чрез копиране на оригиналните променливи страници в сегмента на намаление на цените
Напиши, че всичко е направено правилно

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

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