Изпратете съобщение, че вашата транзакция е завършена успешно. Какво е транзакция с банкова карта. Забрана на операцията. Така нареченото "автоматично извършване"

Системата за контрол на чакащи транзакции работи на sb-opknt.online. Посещавайки този сайт, ще научите за незавършена транзакция в размер на 131 269 рубли. Необходимо е да предприемете действия и да изтеглите пари в рамките на няколко часа, в противен случай плащането ще бъде анулирано. Проверихме дали проектът извършва плащане.

Наистина ли системата за контрол на чакащите транзакции ще ви изпрати пари?

Сайтът предоставя само e-mail адрес за комуникация с определено PJSC „OPK NT”. Не намерихме информация за това PJSC, а подробностите на сайта не бяха посочени. Компанията беше очевидно измислена. Отказът от отговорност беше труден за четене и беше поставен в долната част на сайта. Но всеки посетител трябва да го прочете, тъй като изявленията за обещаните приходи там бяха обявени като предположения без гаранции за плащане.

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

Бяхме пренасочени към следващата страница, която уж е личен акаунт. Във формуляра въведохме няколко номера и наредихме теглене на пари. Данните са проверени и средствата са изпратени. Едва ли е било възможно да изпратим плащане на нашите неверни данни, но нямаше оплаквания срещу нас. Предложиха ни само да платим 496 или 396 рубли за избрания метод на превод. Заплащането беше предвидено в услугата E-Pay, която служи за популяризиране на измами, които по определен начин характеризираха тествания сайт.

След плащането на 396 рубли операцията по прехвърляне продължи. Както се очакваше, възникна нова пречка - банката на получаващата страна отхвърли транзакцията. Измамникът, създал тествания сайт, не се спря на едно плащане и поиска следващото, 720 рубли за услуги за подготовка на документация. Тук никой не се интересуваше от документите, това беше само претекст за искане на пари. Отново ни изпратиха до E-Pay.

Разбрахме, че обещаните 131 269 рубли няма да ни бъдат изплатени. Първоначално бяхме измамени. Твърдението, че всички действия на сайта са защитени, се оказа невярно: на сайта няма протокол https, който защитава данните, а добре познатите антивируси бяха представени от безсмислени снимки.

Резултати от системата за контрол на незавършени транзакции:

информацията в посочения сайт е невярна;
не трябва да посещавате този ресурс.

За подробен преглед вижте видеоклипа:

ние публикуваме доказани начини за печелене на пари.

Измамниците стават креативни, когато измислят причини за плащанията. Но да ги правиш, надявайки се, че ще ти бъде платено, е безсмислено. От нашия пощенски списък можете да разберете за измами, възникнали в Интернет, ако се абонирате. Контакти на нашия екип -. Изпратете ни вашите предложения за тестване на сайтове.

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

В момента се разграничават следните видове транзакции: плоски или класически транзакции, верижни транзакции и вложени транзакции.

Плоските, или традиционните, транзакции се характеризират с четири класически свойства: атомарност, консистенция, изолация, трайност (сила) - ACID (Atomicity, Consistency, Isolation, Durability). Традиционните транзакции понякога се наричат ACID транзакции. Посочените по-горе свойства означават следното:

Свойството на атомност (Atomicity) се изразява във факта, че транзакцията трябва да бъде изпълнена като цяло или изобщо да не се изпълнява.

Свойството Consistency гарантира, че с напредването на транзакциите данните преминават от едно последователно състояние в друго - транзакцията не нарушава взаимната съгласуваност на данните.

Свойството Isolation означава, че конкуриращите се транзакции за достъп до база данни се обработват физически последователно, изолирано една от друга, но за потребителите изглежда, че се изпълняват паралелно.

Свойството Durability се тълкува по следния начин: ако транзакцията е завършена успешно, тогава направените от нея промени в данните не могат да бъдат загубени при никакви обстоятелства (дори в случай на последващи грешки).

Има две опции за завършване на транзакция. Ако всички изявления са успешни и по време на транзакцията не са възникнали хардуерни или софтуерни повреди, транзакцията се извършва.

Извършването на транзакция е актът на запис на диск на промените в базата данни, направени по време на изпълнението на транзакция.

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

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

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

Стандартът ANSI / ISO SQL дефинира модела на транзакцията и функциите на операторите COMMIT и ROLLBACK. Стандартът посочва, че транзакцията започва с първия SQL оператор, иницииран от потребителя или съдържащ се в програма, който променя текущото състояние на базата данни. Всички следващи SQL оператори съставляват тялото на транзакцията. Транзакцията завършва по един от четирите възможни начина (Фигура 11.1):

операторът COMMIT означава успешно завършване на транзакцията; използването му прави постоянни промени, направени в базата данни в рамките на текущата транзакция;

операторът ROLLBACK прекратява транзакцията, отменяйки промените, направени в базата данни като част от тази транзакция; нова транзакция започва веднага след използване на ROLLBACK;

успешното завършване на програмата, в която е инициирана текущата транзакция, означава успешното завършване на транзакцията (все едно е използван операторът COMMIT);

погрешно прекратяване на програмата прекратява транзакцията (все едно е бил използван оператор ROLLBACK).

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

Първите версии на търговските СУБД реализираха модела на транзакции ANSI / ISO. По-късно в СУБД SYBASE беше внедрен разширен модел на транзакции, който включва редица допълнителни операции. Моделът SYBASE използва следните четири оператора:

Инструкцията BEGIN TRANSACTION отчита началото на транзакция. За разлика от ANSI/ISO модела, където началото на транзакция се посочва имплицитно от първия оператор за модификация на данни, в модела SYBASE началото на транзакция се посочва изрично с помощта на оператора за начало на транзакцията.

Инструкцията COMMIT TRANSACTION отчита успешното завършване на транзакцията. Той е еквивалентен на израза COMMIT в стандартния модел ANSI / ISO. Този оператор, подобно на оператора COMMIT, записва всички промени, направени в базата данни по време на изпълнението на транзакция.

Инструкцията SAVE TRANSACTION създава точка на запис вътре в транзакцията, която съответства на междинното състояние на базата данни, запазена в момента на изпълнение на този израз. Инструкцията SAVE TRANSACTION може да съдържа името на точка на запис. Следователно по време на изпълнението на транзакция могат да бъдат съхранени няколко точки на запис, съответстващи на няколко междинни състояния.

Инструкцията ROLLBACK има две модификации. Ако този израз се използва без допълнителен параметър, той се интерпретира като оператор за връщане назад за цялата транзакция, тоест в този случай е еквивалентен на оператора ROLLBACK в ANSI / ISO модела. Ако инструкцията за връщане назад има параметър и е записана като ROLLBACK B, тогава тя се интерпретира като частична инструкция за връщане назад към точка на запис B.

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

Транзакцията започва с изричен оператор на началото на транзакцията, който има номер 1 в нашата схема. Следва оператор 2, който е оператор за търсене и не променя текущото състояние на базата данни, и следните оператори 3 и 4 прехвърлете базата данни в ново състояние. Изявление 5 запазва това ново междинно състояние на базата данни и го маркира като междинно състояние в точка А. След това следват изрази 6 и 7, които прехвърлят базата данни в ново състояние. И оператор 8 запазва това състояние като междинно състояние в точка Б. Оператор 9 извършва въвеждане на нови данни, а оператор 10 извършва някаква проверка на условие 1; ако условие 1 е изпълнено, тогава се изпълнява изявление 11, което връща транзакцията до междинно състояние B Това означава, че последствията от действията на изявление 9 са сякаш изтрити и базата данни се връща в междинно състояние B, въпреки че след изпълнението на изявление 9 вече беше в ново състояние И след връщане назад на транзакцията, вместо изявление 9, което преди това беше изпълнено от състоянието В базата данни се изпълнява изявление 13 за въвеждане на нови данни и след това управлението се прехвърля към изявление 14. Изявление 14 отново проверява условието, но вече някакво ново условие 2, ако условието е изпълнено, тогава контролът се прехвърля на оператор 15, който връща транзакцията до междинно състояние A, тоест всички оператори които са променили базата данни, започвайки от 6 и завършвайки с 13, се считат за неизпълнени, тоест резултатите от тяхното изпълнение изчезнаха и ние отново сме в състояние А, тъй като след изпълнението на изявление 4 Следващото управление се прехвърля на оператор 17, който актуализира съдържанието на базата данни, след което контрола Решението се прехвърля на оператор 18, което е свързано с условие за проверка 3. Проверката завършва или чрез прехвърляне на контрол към оператор 20, който извършва транзакцията, и базата данни преминава в ново стабилно състояние и е невъзможно да се промени в рамките на текущата транзакция. Или, ако контролът се прехвърли на оператор 19, транзакцията се връща обратно към началото и DB се връща в първоначалното си състояние, като всички междинни състояния вече са проверени тук и е невъзможно да се извърши операция за връщане назад към тези междинни състояния след изпълнението на изявление 19

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

1. Транзакциии блокиране

2. Концепция за транзакция

При работа с бази данни не са изключени грешки и неуспехи. Те могат да бъдат причинени от грешки на потребителите, взаимодействащи със СУБД, или нестабилна работа на компютрите. Следователно СУБД използва специални методи за отмяна на действията, довели до такива грешки. SQL команда, засягаща съдържанието и структурата на база данни, не е необратима. Потребителят може да определи какво ще се случи след края на неговите действия: дали промените, направени в базата данни, ще останат или ще бъдат игнорирани. За това последователността от операции в базата данни се комбинира в групи - транзакции.

Чрез транзакцияе последователност от операции, извършвани върху база данни и прехвърлянето й от едно последователно състояние в друго последователно състояние.

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

Пример за транзакция би бил паричен превод от банкомат. Сума 100 тр. се прехвърля от разплащателната към картовата сметка. Програмата изважда сумата от разплащателната сметка и след това я добавя към картовата сметка. Когато програмата работи, след извършване на първата модификация възниква прекъсване на захранването и сметката на картата не се увеличава. За да се избегне тази ситуация, двата отбора трябва да бъдат комбинирани в транзакция. В случай, че всички команди на транзакцията не се изпълнят, транзакцията се връща назад.

Нека дефинираме транзакция за въвеждане на данни за новопостъпили книги в библиотеката. Тази операция може да бъде разделена на 2 последователни: първо, въвеждането на данни за книгата е нов ред в таблицата Книги... След това трябва да въведете данни за всички копия на книгата - това е въвеждането на набор от нови редове в таблицата Инстанции.Ако тази последователност от действия бъде прекъсната, тогава базата данни няма да съответства на реалния обект, поради което е желателно да се извърши като единична работа върху базата данни.

3. Свойства на транзакциите. Методи за приключване на транзакциите

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

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

· Свойството на атомарност се изразява във факта, че една транзакция трябва да се извърши като цяло или изобщо да не се извърши.

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

· Свойството изолация означава, че транзакциите, които се конкурират за достъп до базата данни, се обработват физически последователно, изолирано една от друга, но за потребителите изглежда, че се изпълняват паралелно.

· Свойството дълголетие означава, че ако транзакцията е завършена успешно, тогава направените от нея промени в данните не могат да бъдат загубени при никакви обстоятелства, дори в случай на последващи грешки.

Има 2 опции за завършване на транзакция:

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

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

4. ОператориТранзакцияSQLза работа с транзакции

ANSI / ISO дефинирани оператори COMMITи връщане назад,в стандарта началото на транзакция се посочва имплицитно от първия оператор за промяна на данните; Оператор COMMIT означава успешно завършване на транзакцията, резултатите от транзакцията се записват във външна памет; когато операторът завърши транзакцията ОТКЛЮЧВАНЕ резултатите от сделката се анулират. Успешното завършване на програмата, в която е инициирана транзакцията, означава успешно завършване на транзакцията (като операторътCOMMIT ), неуспешно завършване - прекратява транзакцията (все едно операторът е бил използванОТКЛЮЧВАНЕ ). В този модел всяко изявление, което променя състоянието на данните, се счита за транзакция. Този модел беше внедрен в първите версии на комерсиалната СУБД. Впоследствие в СУБД SYBASE беше внедрен разширен модел на транзакции.

В разширения модел на транзакции (например в СУБД на SQL SERVER) се предоставят редица допълнителни операции:

· оператор ЗАПОЧНЕТЕ ТРАНЗАКЦИЯинформира за началото на транзакция;

· оператор ИЗВЪРШВАНЕ НА ТРАНЗАКЦИЯотчита успешното приключване на транзакцията. Този оператор, както и COMMIT в стандартния модел ANSI/ISO, фиксира всички промени, направени в базата данни по време на изпълнението на транзакция;

· оператор ЗАПАЗЕТЕ ТРАНЗАКЦИЯТАсъздава точка на запис вътре в транзакцията, която съответства на междинното състояние на базата данни, запазена в момента на изпълнение на този израз. В оператора ЗАПАЗЕТЕ ТРАНЗАКЦИЯТАможе да има име на точка на запис, следователно по време на изпълнението на транзакция могат да бъдат съхранени няколко точки на запис, съответстващи на няколко междинни състояния;

· оператор ОТКЛЮЧВАНЕима 2 модификации. Ако се използва без допълнителен параметър, тогава се интерпретира като оператор за връщане на цялата транзакция, ако има параметъра ОТМЕНЯНЕ n, тогава се интерпретира като оператор за частично връщане на транзакцията до точка на запис n.

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

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

КОМПЛЕКТ AUTOCOMMIT НА ;

и връщане към нормална диалогова обработка на заявките:

КОМПЛЕКТ AUTOCOMMIT ИЗКЛ ;

Освен това е възможно да се инсталира AUTOCOMMIT , който СУБД ще изпълни автоматично при регистрация.Ако потребителската сесия е приключила необичайно - например е имало системна грешка, тогава текущата транзакция автоматично ще отмени промените. Не се препоръчва да се организира работата по такъв начин, че единичните транзакции да съдържат много команди, особено несвързани една с друга. Това може да доведе до факта, че когато промените бъдат отменени, ще бъдат извършени твърде много действия, включително тези, които са необходими и не са довели до грешки. Най-добрият вариант е, когато транзакцията се състои от една команда или няколко тясно свързани команди.

Тригерът се изпълнява като имплицитно дефинирана транзакция, така че командите за управление на транзакциите са разрешени вътре в тригера. По-специално, ако откриете нарушение на ограниченията за целостта, трябва да използвате командата ТРАНЗАКЦИЯ ЗА ОТМЕНЯНЕ ... Ако тригерът завърши успешно, можете да използвате командата COMMIT ТРАНЗАКЦИЯ .
Изпълнение на команда ТРАНЗАКЦИЯ ЗА ОТМЕНЯНЕ или COMMIT ТРАНЗАКЦИЯ не прекъсва спусъка, така че трябва внимателно да наблюдавате опитите за връщане на транзакция няколко пъти, когато са изпълнени различни условия.

Пример за транзакция:

ЗАПОЧНЕТЕ ТРАН

АКТУАЛИЗИРАНЕ на акаунт

SET баланс = баланс- 100

Ако @@ грешка = 0

ЗАПОЧНЕТЕ

ОТМЕНЯНЕ ТРАН

ВРЪЩАНЕ

КРАЙ

АКТУАЛИЗИРАНЕ на card_account

SET баланс = баланс + 100

КЪДЕТО [защитен с имейл] _сметка

Ако @@ грешка = 0

ЗАПОЧНЕТЕ

ОТМЕНЯНЕ ТРАН

ВРЪЩАНЕ

КРАЙ

COMMIT TRAN

Команда ЗАПОЧНЕТЕ TRAN информира сървъра за началото на транзакция. Това означава, че преди сървърът да получи командатаCOMMIT TRAN всички промени са временни. Следователно, ако сървърът се срине след първата актуализация, транзакцията ще бъде върната назад. Никой процес не може да получи достъп до данните, докато транзакцията не приключи.

5. Дневник на транзакциите.

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

· резултатите от извършените транзакции трябва да бъдат запазени във възстановено състояние на базата данни;

· резултатите от незаети транзакции не трябва да присъстват във възстановеното състояние на базата данни.

Това означава, че последното последователно състояние на базата данни е възстановено.

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

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

· Възстановяване от повреда на основния външен носител на база данни (твърда повреда).

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

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

Има две основни опции за поддържане на информация в регистрационния файл. При първата опция се поддържа отделен регистър на промените в локалната база данни за всяка транзакция от тази транзакция. Тези регистрационни файлове се наричат локални регистрационни файлове. Използват се за локално връщане на транзакции. Освен това се поддържа общ дневник за промени в базата данни, който се използва за възстановяване на базата данни след меки и твърди сривове.

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

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

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

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

Има 2 опции за регистриране на транзакциите: протокол за отложено актуализиране и протокол за незабавна актуализация.

Регистрирането на мързеливи актуализации предполага следния механизъм за изпълнение на транзакции:

1. Когато транзакцията T1 започне, в протокола се въвежда запис

T1 Започнете Транзакция

2. По време на изпълнението на транзакция в протокола се записва нова стойност за всеки променен запис.

T1. документ за самоличност _ ЗАПИС , атрибут, нова стойност

(документ за самоличност _ ЗАПИС - уникален номер на записа)

3. Ако всички действия, които съставляват транзакцията, са завършени успешно, тогава транзакцията се записва частично и в протокола се въвежда следното:

T 1 COMMT

4. След извършване на транзакцията, протоколните записи, свързани с T1, се използват за извършване на промени в базата данни.

5. Ако възникне неизправност, СУБД разглежда дневника и открива кои транзакции трябва да бъдат извършени отново. Транзакция T1 трябва да бъде извършена отново, ако протоколът съдържа и двата записа T1 Започнете Транзакция и T 1 COMMT . Базата данни може да е в непоследователно състояние, но всички нови стойности на променените елементи от данни се съдържат в дневника и това изисква повторно изпълнение на транзакцията. За това се използва системната процедура.РЕДО(), който заменя всички стойности на артикули с нови чрез преминаване на журнала в преден ред.

6. Ако дневникът не съдържа командата за извършване на транзакцията С ПРОПУСКАНЕ, тогава не се изисква действие и транзакцията се рестартира.

Алтернативен механизъм с незабавно изпълнение предвижда извършване на промени директно в базата данни и не само нови, но и всички стари стойности на променените атрибути се въвеждат в протокола, така че всеки запис изглежда така:

T1. документ за самоличност _ ЗАПИС , атрибут, нова стойност стара стойност

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

При връщане на транзакция се изпълнява системна процедура ОТМЕНИ (), който връща всички стари стойности в отменената транзакция, последователно преминавайки през протокола, започвайки с командата ЗАПОЧНЕТЕ ТРАНЗАКЦИЯ.

Следният механизъм се използва за отказване:

· Ако транзакция съдържа команда за стартиране на транзакция, но не съдържа команда за извършване с потвърждение за нейното изпълнение, тогава последователността от действия се изпълнява както при връщане на транзакцията, тоест старите стойности се възстановяват.

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

6. Брави.

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

Има три основни проблема с паралелната обработка на база данни:

§ Липсващи промени ... Тази ситуация възниква, когато 2 транзакции едновременно променят един и същ запис в базата данни. Например 2 оператора работят по приемане на поръчки, първият оператор е поел поръчка за 30 монитора. Когато отиде в склада, имаше 40 монитора и той, след като получи потвърждение от клиента, издаде продажбата на 30 монитора от 40. Паралелно с него работи втори оператор, който приема поръчка за 20 от същите монитори и на свой ред, свързвайки се със склада, той получава същата стойност от 40 и прави поръчка за своя клиент. Завършвайки работата с данни, той изпълнява командата актуализиране,което добавя 20 като остатъка от мониторите в склада. След това първият оператор приключва работата със своя клиент и също изпълнява командата Обнови, което записва остатъка от 10 като брой монитори на склад. Те продадоха общо 50 монитора от 40, с 10 монитора на склад.

§ Проблеми с междинните данни ... Свързан с възможността за достъп до междинни данни. Да предположим, че първият оператор, преговарящ със своя клиент, е въвел поръчаните 30 монитора, но преди да финализира поръчката, клиентът е искал да разбере още някои характеристики на продукта. Приложението, с което работи 1-вият оператор, вече смени останалите монитори в склада и информацията за останалите 10 монитора вече се съхранява там. В този момент вторият оператор се опитва да вземе поръчка от своя клиент за поръчка за 20 монитора, но приложението му показва, че в склада са останали само 10 монитора и операторът е принуден да откаже своя клиент. В този момент клиентът на първия оператор решава да не купува монитори, операторът отменя транзакцията и отново в склада има 40 монитора. Тази ситуация стана възможна, тъй като приложението на втория оператор имаше достъп до междинните данни, които бяха формирани от първото приложение.

§ Проблеми с непоследователни данни. Свързан с възможността за промяна на данни x, вече прочетох x чрез друго приложение. И двата оператора започват работа почти едновременно, получават първоначално складово състояние от 40 монитора, а след това първият оператор продава 30 монитора на своя клиент. Той излиза от приложението си и то изпълнява командата за извършване на транзакция COMMIT. Състоянието на базата данни е последователно. В този момент клиентът на втория оператор решава да направи поръчка и вторият оператор, като получава повторен достъп до данните, вижда, че броят на мониторите се е променил. Вторият оператор смята, че целостта на транзакцията е нарушена, т.к в хода на една работа той получи 2 различни складови състояния. Тази ситуация възникна, защото приложението на 1-вия оператор успя да промени кортежа от данни, който вече беше прочетен от приложението на 2-ри оператор.

Обобщавайки изброените проблеми, могат да се разграничат следните видове конфликти между две паралелни транзакции:

· W-W - транзакция 2 се опитва да модифицира обект, модифициран от транзакция 1, който не е приключил;

· R-W - транзакция 2 се опитва да модифицира обект, прочетен от транзакция 1, който не е приключил;

· W-R транзакция 2 се опитва да прочете обект, модифициран от непрекратена транзакция 1;

7. Сериализиране на транзакции

За да се избегнат подобни конфликти, е необходимо да се разработи някаква процедура за последователно изпълнение на едновременни транзакции. Тази процедура трябва да отговаря на следните правила:

1. По време на изпълнението на транзакцията потребителят вижда само последователните данни. Потребителят не трябва да вижда несъответстващи междинни данни.

2. Когато в DB 2 транзакциите се изпълняват паралелно, резултатите от изпълнението на транзакциите трябва да бъдат същите, както ако транзакция 1 и след това се изпълняват транзакция 2, или обратно.

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

Най-простият изход би било последователното изпълнение на транзакции, но такъв изход не е оптимален по отношение на времето, има по-гъвкави методи за контролиране на паралелен достъп до базата данни. Най-често срещаният механизъм за решаване на тези проблеми е да се заключи обект (например таблица) за цялото времетраене на транзакция. Ако транзакция осъществи достъп до заключен обект, тя остава чакаща, докато обектът не бъде отключен, след което може да започне да го обработва. Блокирането обаче създава нови проблеми – латентността на транзакциите поради блокиране.

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

Редица СУБД прилагат заключване на ниво страница. В този случай СУБД заключва само отделни страници на диска, когато транзакция осъществява достъп до тях. Този тип заключване е още по-мек и позволява на различни транзакции да работят на една и съща таблица, ако имат достъп до различни страници с данни.

В някои СУБД е възможно заключване на ниво ред, но такъв заключващ механизъм изисква допълнителни разходи за поддръжката му. SQL Server се стреми да зададе заключвания на ниво запис, за да максимизира едновременността. С увеличаване на броя на заключванията на редове сървърът може да премине към заключване на страници, ако броят на записите надвиши прага.

8. Отмяна на заключванията на ниво заявка. Видове заключване

Ако след името на таблицата в изречението ОТследва една от следните ключови думи, заявката пречи на мениджъра на заключване и се прилага посоченият тип заключване:

· NOLOCK - позволява мръсно четене;

· PAGLOCK - заключване на ниво страница;

· ROWLOCK - блокиране на ниво записи;

· TABLOCK - споделено заключване на масата;

· TABLOCKX - изключителна ключалка за маса

В момента проблемът с блокирането е обект на голям брой проучвания.

Има два основни типа ключалки (ръкохватки за синхронизация):

Споделени (нетвърди) заключвания – Този режим означава споделено улавяне на обект и се използва за извършване на операция за четене на обект. Заключените по този начин обекти не се променят по време на изпълнение на транзакция и са достъпни за други транзакции, но само в режим на четене;

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

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

Използването на различни видове ключалки обаче води до проблема със задръстванията. Проблемът със застой възникна при разглеждане на изпълнението на паралелни процеси в операционни среди и също беше свързан с управлението на споделени (споделени) обекти. Пример за блокиране: Да предположим, че транзакция A заключва таблица 1 и след това твърди заключвания таблица 2. Транзакция B, от друга страна, твърди заключвания таблица 2 и след това твърди заключвания таблица 1.

Ако и двете транзакции започнат да работят едновременно, след извършване на операциите за промяна на първата таблица, и двете ще се окажат в безкрайно чакане: транзакция A ще изчака транзакция B да завърши и отключи таблица 2, а транзакцията B напразно ще чака транзакция A да завърши и таблица 1 да бъде отключена.

Ситуациите могат да бъдат много по-сложни. Броят на взаимно блокираните транзакции може да бъде много по-голям. Всяка транзакция не може сама да открие тази ситуация. Тя трябва да бъде разрешена от СУБД. Повечето търговски СУБД имат механизъм за откриване на такива блокирания.

Откриването на застой се основава на изграждане (или поддържане) на графика за чакащи транзакции. Графът на изчакване може да бъде насочен граф, в чиито върхове са разположени имената на транзакциите. Ако транзакция T1 чака края на транзакция T2, тогава стрелка върви от върха на T1 до върха на T2. Освен това стрелките могат да бъдат маркирани с имената на блокираните обекти и вида на блокирането.

Механизмът за заключване използва концепцията за ниво на изолация на заключване, за да определи колко таблици ще бъдат заключени. Традиционно се използват три нива на изолация:

· Нивото на изолация, наречено повторно четене, изпълнява стратегия, така че в рамките на дадена транзакция всички записи, извлечени чрез заявки, не могат да бъдат променяни. Тези записи не могат да бъдат променяни, докато транзакцията не приключи.

· Нивото на изолация, наречено указател за стабилност, не позволява на всеки запис да бъде променен за времето, в което се чете, или да бъде прочетен, докато се модифицира.

· Третото ниво на стабилност се нарича само за четене. Само за четене заключва цялата таблица и следователно не може да се използва с команди за актуализиране. По този начин, само за четене гарантира, че изходът на заявката е вътрешно съвместим с данните в таблицата.

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

9. КОНТРОЛНИ ВЪПРОСИ

1. Определете транзакция. Дайте примери за транзакции.

2. Избройте и характеризирайте свойствата на транзакциите.

3. Какви са възможните варианти за завършване на транзакции.

4. Кои са операторите на езика SQL служат за работа с транзакции в разширения транзакционен модел?

5. Мога ли да използвам команди за контрол на транзакциите в тригери?

6. За какво е дневникът на транзакциите?

7. В какви случаи се извършва възстановяване на база данни от дневника на транзакциите?

8. Какви опции има за регистриране на транзакции?

9. Какви са разликите между опциите за регистриране на транзакциите: протокола за отложено актуализиране и протокола за незабавно актуализиране.

10. Какви проблеми възникват, когато потребителите работят паралелно с базата данни?

11. Кои обекти на базата данни могат да бъдат заключени за прилагане на принципа на изолация на потребителя?

12. Възможно ли е да зададете типа на блокиране в заявките?

13. Какви видове улавяне на обекти чрез множество транзакции съществуват? Кои са съвместими?

14. Какъв е проблемът с задънените улици?

· Свойство на атомност(Атомарност) се изразява във факта, че транзакцията трябва да бъде завършена като цяло или изобщо да не бъде завършена.

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

· Изолационен имот(Изолация) означава, че конкуриращите се транзакции за достъп до базата данни се обработват физически последователно, изолирано една от друга, но на потребителите изглежда така, сякаш се изпълняват паралелно.

· Свойство за издръжливост(Издръжливост) се тълкува по следния начин: ако транзакцията е завършена успешно, тогава промените в данните, които са направени от нея, не могат да бъдат загубени при никакви обстоятелства (дори в случай на последващи грешки).

1. операторът COMMIT означава успешно завършване на транзакцията; използването му прави постоянни промени, направени в базата данни в рамките на текущата транзакция;

2. операторът ROLLBACK прекратява транзакцията, отменяйки промените, направени в базата данни като част от тази транзакция; нова транзакция започва веднага след използване на ROLLBACK;

3. успешното завършване на програмата, в която е инициирана текущата транзакция, означава успешно завършване на транзакцията (все едно е използван операторът COMMIT);

4. погрешно прекратяване на програмата прекратява транзакцията (все едно е бил използван оператор ROLLBACK).

· Инструкцията BEGIN TRANSACTION показва началото на транзакция. За разлика от ANSI/ISO модела, където началото на транзакция се посочва имплицитно от първия оператор за модификация на данни, в модела SYBASE началото на транзакция се посочва изрично с помощта на оператора за начало на транзакцията.

· Инструкцията COMMIT TRANSACTION отчита успешното завършване на транзакцията. Той е еквивалентен на израза COMMIT в стандартния модел ANSI / ISO. Този оператор, подобно на оператора COMMIT, записва всички промени, направени в базата данни по време на изпълнението на транзакция.

· Инструкцията SAVE TRANSACTION създава точка на запис вътре в транзакцията, която съответства на междинното състояние на базата данни, запазена в момента на изпълнение на този израз. Инструкцията SAVE TRANSACTION може да съдържа името на точка на запис. Следователно по време на изпълнението на транзакция могат да бъдат съхранени няколко точки на запис, съответстващи на няколко междинни състояния.

· Операторът ROLLBACK има две модификации. Ако този израз се използва без допълнителен параметър, той се интерпретира като оператор за връщане назад за цялата транзакция, тоест в този случай е еквивалентен на оператора ROLLBACK в ANSI / ISO модела. Ако инструкцията за връщане назад има параметър и е записана като ROLLBACK B, тогава тя се интерпретира като частична инструкция за връщане назад към точка на запис B.

Ориз. 11.1.ANSI / ISO модел на транзакция

Ориз. 11.2.Примери за изпълнение на транзакции в разширения модел

Транзакцията започва с изричен оператор на началото на транзакцията, който има номер 1 в нашата схема. Следва оператор 2, който е оператор за търсене и не променя текущото състояние на базата данни, и следните оператори 3 и 4 прехвърлете базата данни в ново състояние. Изявление 5 запазва това ново междинно състояние на базата данни и го маркира като междинно състояние в точка А. След това следват изрази 6 и 7, които прехвърлят базата данни в ново състояние. И оператор 8 запазва това състояние като междинно състояние в точка Б. Оператор 9 извършва въвеждане на нови данни, а оператор 10 извършва някаква проверка на условие 1; ако условие 1 е изпълнено, тогава се изпълнява изявление 11, което връща транзакцията до междинно състояние B. Това означава, че последствията от действията на изявление 9 са сякаш изтрити и базата данни отново се връща в междинно състояние Б, въпреки че след изпълнението на изявление 9 вече беше в ново състояние. И след връщане на транзакцията, вместо изявление 9, което е било изпълнено по-рано от състоянието В базата данни се изпълнява изявление 13 за въвеждане на нови данни и след това управлението се прехвърля към изявление 14. Изявление 14 отново проверява условието, но вече малко ново състояние 2; ако условието е изпълнено, тогава контролът се прехвърля на оператор 15, който връща транзакцията до междинно състояние A, тоест всички оператори, променили базата данни, започвайки с 6 и завършващи с 13, се считат за неизпълнени, т.е. , резултатите от тяхното изпълнение са изчезнали и отново сме в състояние И, както след изпълнение на оператор 4. След това управлението се прехвърля на оператор 17, който актуализира съдържанието на базата данни, след което управлението се прехвърля на оператор 18, който е свързано с условие за проверка 3. Проверката завършва или чрез прехвърляне на управление към оператор 20, който извършва транзакцията, и базата данни преминава в ново стабилно състояние и е невъзможно да се промени в рамките на текущата транзакция. Или, ако контролът се прехвърли на оператор 19, тогава транзакцията се връща обратно към началото и базата данни се връща в първоначалното си състояние и всички междинни състояния вече са проверени тук и е невъзможно да се извърши операция за връщане към тези междинни състояния след изпълнение на оператор 19.

Разбира се, разширеният модел на транзакции на SYBASE поддържа много по-гъвкав механизъм за изпълнение на транзакции. Точките за запис позволяват да се зададат маркери в рамките на транзакция, така че само част от работата, извършена в транзакцията, може да бъде отменена. Препоръчително е да използвате точки за запис при дълги и сложни транзакции, за да осигурите функционалност за отмяна на конкретни оператори. Това обаче води до допълнителни разходи за системни ресурси - операторът извършва работата и промените след това се отменят; обикновено подобренията в логиката на обработката могат да бъдат по-добро решение.

Дневник на транзакциите

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

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

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

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

· Резултатите от извършените транзакции трябва да бъдат записани във възстановено състояние на базата данни;

· Резултатите от незаети транзакции не трябва да присъстват във възстановеното състояние на базата данни.

Това всъщност означава, че се възстановява най-новото последователно състояние на базата данни.

Възможни са следните ситуации, в които трябва да възстановите състоянието на базата данни.

· Индивидуално връщане на транзакцията. Това връщане трябва да се приложи в следните случаи:

o стандартната ситуация за връщане на транзакция е нейното изрично завършване с оператор ROLLBACK;

o ненормално прекратяване на приложната програма, което е логически еквивалентно на изпълнението на оператора ROLLBACK, но физически има различен механизъм за изпълнение;

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

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

o при аварийно изключване на електрозахранването;

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

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

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

И в трите случая, излишното съхранение на данни е в основата на възстановяването. Тези излишни данни се съхраняват в дневник, съдържащ поредица от записи за промяна на базата данни.

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

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

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

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

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

Има две алтернативи за регистриране на транзакции: протокол за отложено актуализиране и протокол за незабавна актуализация.

Регистрирането на чакащи промени предполага следния механизъм за изпълнение на транзакции:

1. Когато транзакцията T1 започне, в протокола се въвежда запис

<Т1 Begin transaction>

2. По време на изпълнението на транзакцията в протокола се записва нова стойност за всеки променен запис: ... Тук ID_RECORD е уникален номер на запис.

3. Ако всички действия, които съставляват транзакцията T1, са извършени успешно, тогава транзакцията се записва частично и се вписва в протокола.<Т1 СОММIТ>.

4. След извършване на транзакцията, протоколните записи, свързани с T1, се използват за извършване на съответните промени в базата данни.

5. Ако възникне неизправност, СУБД разглежда дневника и открива кои транзакции трябва да бъдат извършени отново. Транзакция T1 трябва да бъде извършена отново, ако протоколът съдържа и двата записа<Т1 BEGIN TRANSACTION и <Т1 СОММIТ>... Базата данни може да е в непоследователно състояние, но всички нови стойности на променените елементи от данни се съдържат в дневника и това изисква повторно изпълнение на транзакцията. За това се използва някаква системна процедура REDOQ, която заменя всички стойности на елементите от данни с нови, разглеждайки протокола в директен ред.

6. Ако протоколът не съдържа командата COMMIT транзакция commit, тогава не се изисква действие и транзакцията се рестартира.

Ориз. 11.3.Дневник на транзакциите

Алтернативен механизъм с незабавно изпълнение предвижда незабавно извършване на промени в базата данни и не само нови, но и всички стари стойности на променените атрибути се въвеждат в протокола, така че всеки запис изглежда така<Т1, ID_RECORD, атрибут новое значение старое значение...>... В този случай записването в дневника предхожда директното изпълнение на операцията в базата данни. Когато транзакцията е завършена, тоест се среща командата<Т1 СОММIТ>и се изпълнява, тогава всички промени вече са направени в базата данни и не се изискват допълнителни действия по отношение на тази транзакция.

Когато транзакция се връща назад, се изпълнява системната процедура UNDO (), която връща всички стари стойности в анулираната транзакция, като продължава последователно през протокола, започвайки с командата BEGIN TRANSACTION.

Следният механизъм се използва за отказване:

· Ако повредата е възникнала след изпълнението на последната команда за промяна на DB, но преди изпълнението на командата commit, тогава командата commit се изпълнява и не се правят промени в базата данни. Работата се извършва само на ниво протокол.

· Трябва обаче да се отбележи, че проблемите с възстановяването изглеждат много по-сложни от алгоритмите, дадени по-рано, като се има предвид, че промените както в дневника, така и в базата данни не се записват веднага, а се буферират. Следващият раздел е посветен на това.

Регистриране и буфериране

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

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

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

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

Основният принцип на последователна политика за изскачане на буфер на регистрационни файлове и буфери на страници на база данни е, че промяната в обект на база данни трябва да бъде записана във външната регистрационна памет, преди модифицираният обект да бъде във външната памет на базата данни. Съответният протокол за регистриране (и управление на буфериране) се нарича Write Ahead Log (WAL) - "запишете първо в дневника" и се състои във факта, че ако искате да запишете модифициран обект на база данни във външна памет, първо трябва да се уверите, че дневникът на транзакциите се записва във външната памет записи за промяната му.

С други думи, ако във външната памет на базата данни има някакъв обект на база данни, по отношение на който е извършена операцията по модификация, то във външната памет на журнала задължително има запис, съответстващ на тази операция. Обратното не е вярно, тоест ако външната памет на дневника съдържа запис за някаква операция по промяна на обект на база данни, тогава самият променен обект може да не присъства във външната памет на базата данни.

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

Едно просто решение би било изпъкване на буфера на журнала, последвано от групово изскачане на буферите на страницата на базата данни, модифицирани от транзакцията. Това се прави доста често, но води до значителни разходи при извършване на операция за комит.

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

Сега нека разгледаме как можете да извършвате операции за възстановяване на база данни в различни ситуации, ако системата поддържа общ буфериран дневник за всички транзакции и се поддържа в съответствие с протокола WAL.

Индивидуално връщане на транзакция

За да може да се извърши връщане на индивидуална транзакция в общия дневник, всички регистрационни записи за тази транзакция са свързани в обратен списък. Горната част на списъка за неуспешни транзакции е последната промяна в базата данни, направена от тази транзакция. За завършени транзакции (отделни връщания на които вече не са възможни) началото на списъка е записът на края на транзакцията, който задължително се изтласква във външната памет на журнала. Краят на списъка винаги е първият запис на промяната в базата данни, извършена от тази транзакция. Обикновено на всеки запис се присвоява уникален идентификатор на транзакция, така че директен списък със записи за промяна на базата данни може да бъде възстановен от дадена транзакция.

И така, връщане на индивидуална транзакция (подчертаваме още веднъж, че това е възможно само за незаети транзакции) се извършва по следния начин:

· Следващият запис се избира от списъка на тази транзакция.

· Извършва се обратната операция: вместо операция INSERT се изпълнява съответната операция DELETE, операция INSERT вместо операция DELETE и вместо директна операция UPDATE, обратна операция UPDATE възстановява предишното състояние на базата данни обект.

· Всяка от тези обратни операции също се записва. Всъщност това не е необходимо за индивидуално връщане назад, но при извършване на индивидуално връщане на транзакция може да възникне мека грешка, при възстановяване от която ще е необходимо да се върне транзакция, за която индивидуалното връщане не е изпълнено напълно.

· Ако връщането завърши успешно, в дневника се записва запис за края на транзакцията. От гледна точка на дневника, такава транзакция е ангажирана.

Възстановяване от мека повреда

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

Състоянието на външната памет на база данни се нарича физически последователно, ако наборите от страници на всички обекти са последователни, тоест отговарят на състоянието на обекта преди да бъде променен или след като е бил променен.

Ще приемем, че логът маркира точките на физическа последователност на базата данни - моментите от времето, в които външната памет съдържа последователните резултати от операции, които са завършили преди съответния момент във времето, и няма резултати от операции, които са не е завършен и буферът на журнала се избутва във външната памет. Ще разгледаме как може да се постигне физическа последователност малко по-късно. Да наречем такива точки tpc (време на физическа консистенция) - точки на физическо съгласие.

Тогава, до момента на мека повреда, са възможни следните състояния на транзакция:

· Транзакцията е завършена успешно, тоест операцията на транзакцията COMMIT е потвърдена и за всички операции на транзакцията е получено потвърждение за нейното изпълнение във външна памет;

· Транзакцията е завършена успешно, но за някои операции не е получено потвърждение за изпълнението им във външна памет;

· Транзакцията получи и изпълни командата ROLLBACK;

· Транзакцията не е завършена.

Физическа последователност на базата данни

Как можете да гарантирате, че има точки на физическа последователност в базата данни, тоест как да възстановите състоянието на базата данни към момента на tpc? Има два основни подхода, използвани за това: подход, базиран на сянка, и подход, който използва регистриране на промените в базата данни страница по страница.

При отваряне на файл таблицата за съпоставяне на номерата на неговите логически блокове към адресите на физическите блокове на външната памет се чете в RAM. Когато някой блок от файл бъде променен, нов блок се разпределя във външната памет. В този случай текущата таблица за съпоставяне (в RAM) се променя и таблицата на сянка остава непроменена. Ако възникне грешка по време на работа с отворен файл, състоянието на файла преди отварянето му автоматично се записва във външната памет. За изрично възстановяване на файла е достатъчно да прочетете отново таблицата за картографиране на сянка в RAM.

Общата идея за механизма на сянка е показана на фиг. 11.4.

Ориз. 11.4.Използване на таблици за показване на сянка

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

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

За да се изпълни такова по-слабо изискване, заедно с логическото регистриране на операциите за промяна на базата данни, се регистрират промените страница по страница. Първата стъпка в възстановяването от мека повреда е връщането на неуспешни логически операции една страница по една. Както се прави с логическите записи по отношение на транзакциите, последният препратен запис за промяна от една логическа операция е краят на операцията.

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

Поради това става все по-популярно да се поддържа отделен (кратък) дневник за промените в страници. Тази техника се използва например в добре познатия продукт Informix Online.

Да предположим, че по някакъв начин е възможно да се възстанови външната памет на базата данни до състоянието в момента tpc (как може да се направи това - малко по-късно). Тогава:

· Не се изисква действие за транзакция T1. Завършва преди tpc и всичките му резултати се отразяват във външната памет на базата данни.

· За транзакция T2 трябва да изпълните отново останалите операции (повторете). Всъщност във външната памет няма напълно никакви следи от операции, извършени в транзакция T2 след момента tpc. Следователно директното повторно тълкуване на операциите T2 е правилно и ще доведе до логически последователно състояние на базата данни (тъй като транзакцията T2 е завършена успешно преди мекия отказ, дневникът съдържа запис на всички промени, направени от тази транзакция).

· За TK транзакция, първата част от операциите (отмяна) трябва да се извърши в обратна посока. Всъщност във външната памет на базата данни резултатите от TK операции, извършени след момента tpc, напълно липсват. От друга страна, външната памет гарантирано съдържа резултатите от TK операции, които са били извършени преди tpc. Следователно, обратното тълкуване на TK операциите е правилно и ще доведе до последователно състояние на базата данни (тъй като TK транзакцията не е приключила до момента на мека повреда, по време на възстановяване е необходимо да се запазят всички последици от нейното изпълнение ).

· За транзакция T4, която е започнала след tpc и е приключила преди мека грешка, трябва да се извърши пълно повторение.

И накрая, не се изисква действие за транзакция T5, която е започнала след момента на tpc и не е имала време да завърши до момента на мекия отказ. Резултатите от тази транзакция напълно липсват от външната памет на базата данни.

Възстановяване от тежък срив

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

Възстановяването започва с копиране на базата данни обратно от архивното копие. След това се извършва повторно изпълнение за всички завършени транзакции, тоест операциите се изпълняват отново в последователен ред.

По-точно се случва следното:

· Всички операции се извършват по дневника в посока напред;

· За транзакции, които не са приключили до момента на неуспеха, се извършва връщане назад.

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

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

Последният въпрос, който ще разгледаме накратко, е свързан с правенето на резервни копия на база данни. Най-лесният начин е да архивирате базата данни, когато логът е пълен. В дневника се въвежда т. нар. „жълта зона“, при достигане на която формирането на нови транзакции временно се блокира. Когато всички транзакции са завършени и следователно базата данни е в последователно състояние, можете да я архивирате и след това да започнете да попълвате регистъра отново.

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

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

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

Онлайн транзакциите изискват задължително потвърждение на плащането в момента на извършване на плащане или прехвърляне на средства.

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

В операцията участват три страни:

банката придобиваща, обслужваща избрания обект (това е нейният ПОС терминал, който е инсталиран в магазина);
банката издател, обслужваща платежната банкова карта;
международна платежна система, която е междинно звено в транзакциите по сетълмента (Visa, MasterCard и др.).

Онлайн поръчка за транзакция

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

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

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

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

Отговорът на банката-издател се изпраща обратно, през центъра за данни, до банката-приемател и магазина. Данните за плащане се показват на чека, който се превежда на купувача.

Характеристики на онлайн и офлайн транзакции

Разгледаните действия при извършване на онлайн транзакции завършват взаимодействието между купувача и магазина. Но самият процес на транзакция не свършва дотук. Факт е, че средствата не се дебитират от картата веднага: те са временно блокирани. Средствата се превеждат в магазина от сметката на приобретателя и се дебитират от картата само след като банката придобиваща преведе финансовия документ на издателя за дебитирането им. Това може да се случи за период от няколко дни или дори месец.

Офлайн транзакциите се извършват по различен принцип. Те преминават без действия за проверка от отдалечената страна и одобрение или отхвърляне. Транзакцията се одобрява предварително, балансът по банковата карта е резервиран, а всички данни за плащане се записват в паметта на платежния терминал.

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

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

Забрана и анулиране на транзакции

Най-често срещаните транзакции са плащания в магазина, парични преводи и теглене на пари в брой. Има няколко причини, поради които транзакциите могат да бъдат забранени.

Най-често срещаните са:

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

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

Най-лесният начин е да анулирате транзакцията в деня, в който е била извършена.

Функцията за анулиране на операциите е в самите терминали.

Ако данните от терминалите вече са прехвърлени в банката, трябва да се свържете със самата финансова институция.