Возможно вы уже слышали такой термин как транзакция . Если нет или же подзабыли, то напомним, что под транзакцией подразумевается некоторая последовательность операций (действий вставки, обновления или удаления) в базе данных, которые должны быть выполнены в рамках единого целого.
Все мы пользуемся услугами банков и проводим различные операции с денежными средствами. Как в этом случае добиться надежности? Требования к безопасности выполнения операций в таких системы повышенные. А теперь представьте, что вы выполняете перевод средств кому-то из своих знакомых. Вы хотите, чтобы средства были списаны с вашего счета и поступили на счет получателя. Но что произойдет в случае сбоя, например, электропитания или другой аварийной ситуации? Кто гарантирует вам, что вы не окажетесь в ситуации, когда деньги с вашего счета ушли, но перечисления на счет получателя не произошло. Предотвратить такие ситуации и помогают транзакции .
Фиксация и откат транзакции.
Транзакция объединяет в себе несколько операторов SQL . Если в результате выполнения хотя бы одного из запросов произошел какой-то сбой, то транзакция тут же откатывается (rollback ). Если все хорошо и все действия в рамках одной транзакции выполнились успешно, то выполняется фиксация (commit ) транзакции и только в этом случае соответствующие изменения записываются в базу данных.
А теперь давайте продемонстрируем пример использования транзакций в СУБД MySQL (в большинстве популярных СУБД этот механизм кардинально ничем не отличается):
Пусть у нас есть тестовая таблица accounts , хранящая сведения о счетах пользователей. И одно поле, которое нас интересует называется balance . При переводе с одного счета на другой должно произойти списание средств на одном счете и зачисление на другом (в целях практики вы можете самостоятельно создать небольшую базу данных).
Транзакция начинается с ключевого слова BEGIN . Два оператора UPDATE внутри транзакции являются часть одной транзакции и могут быть выполнены либо оба одновременно либо ни один из них (должен произойти откат). Команда COMMIT служит для указания окончания транзакции и о фиксации изменений. Если фиксация прошла успешна, то все изменения в исходной БД будут отображены.
Чтобы выполнить откат транзакции можно явно записать команду ROLLBACK .
Свойства ACID.
Итак, мы познакомились с понятием транзакции, фиксации и отката. Теперь давайте рассмотрим четыре очень важных свойства транзакции, о которых частенько любят спрашивать на собеседованиях. Требования ACID в конце 70-х годов сформулировал Джим Грей(лауреат Премии Тьюринга за вклад в развитие баз данных). И вот как они звучат:
- Atomicity — атомарность. То, о чем мы говорили выше. транзакция атомарна, то есть все действия, выполняемые в рамках одной транзакции, это единое целое.
- Consistency — согласованность. Каждая новая транзакция переводит базу данных из одного согласованного состояния в другое. Если ваша БД распредленная, то все ее реплики должны содержать одну и ту же версию данных для обеспечения доступности. Это правило часто нарушается многими NoSQL базами данных.
- Isolation — изолированность. Транзакции не влияют друг на друга. В случае параллельного выполнения не должно происходить частичного обновления данных.
- Durability — надежность. Вы же хотите чтобы в случае сбоев все изменения, внесенные данной транзакцией все же сохранились? Именно поэтому в данном списке есть свойство надежности.
Atomicity - Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние - со стороны будет казаться, что транзакции и не было. (Естественно, счётчики, индексы и другие внутренние структуры могут измениться, но, если СУБД запрограммирована без ошибок, это не повлияет на внешнее её поведение.)
Consistency - Согласованность
Транзакция, достигающая своего нормального завершения (EOT - end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвёртого свойства.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется . В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Isolation - Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Изолированность - требование дорогое, поэтому в реальных БД существуют режимы, не полностью изолирующие транзакцию (уровни изолированности Repeatable Read и ниже).
Durability - Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
См. также
Напишите отзыв о статье "ACID"
Литература
- P.A. Bernstein, N. Goodman, V. Hadzilacos. Concurrency Control and Recovery in Database Systems. - Addison-Wesley, 1986.
Примечания
|
||||||||||||||||||||||||||
Отрывок, характеризующий ACID
Наташа молчала, как думала Марья Дмитриевна от застенчивости, но в сущности Наташе было неприятно, что вмешивались в ее дело любви князя Андрея, которое представлялось ей таким особенным от всех людских дел, что никто, по ее понятиям, не мог понимать его. Она любила и знала одного князя Андрея, он любил ее и должен был приехать на днях и взять ее. Больше ей ничего не нужно было.– Ты видишь ли, я его давно знаю, и Машеньку, твою золовку, люблю. Золовки – колотовки, ну а уж эта мухи не обидит. Она меня просила ее с тобой свести. Ты завтра с отцом к ней поедешь, да приласкайся хорошенько: ты моложе ее. Как твой то приедет, а уж ты и с сестрой и с отцом знакома, и тебя полюбили. Так или нет? Ведь лучше будет?
– Лучше, – неохотно отвечала Наташа.
На другой день, по совету Марьи Дмитриевны, граф Илья Андреич поехал с Наташей к князю Николаю Андреичу. Граф с невеселым духом собирался на этот визит: в душе ему было страшно. Последнее свидание во время ополчения, когда граф в ответ на свое приглашение к обеду выслушал горячий выговор за недоставление людей, было памятно графу Илье Андреичу. Наташа, одевшись в свое лучшее платье, была напротив в самом веселом расположении духа. «Не может быть, чтобы они не полюбили меня, думала она: меня все всегда любили. И я так готова сделать для них всё, что они пожелают, так готова полюбить его – за то, что он отец, а ее за то, что она сестра, что не за что им не полюбить меня!»
Они подъехали к старому, мрачному дому на Вздвиженке и вошли в сени.
– Ну, Господи благослови, – проговорил граф, полу шутя, полу серьезно; но Наташа заметила, что отец ее заторопился, входя в переднюю, и робко, тихо спросил, дома ли князь и княжна. После доклада о их приезде между прислугой князя произошло смятение. Лакей, побежавший докладывать о них, был остановлен другим лакеем в зале и они шептали о чем то. В залу выбежала горничная девушка, и торопливо тоже говорила что то, упоминая о княжне. Наконец один старый, с сердитым видом лакей вышел и доложил Ростовым, что князь принять не может, а княжна просит к себе. Первая навстречу гостям вышла m lle Bourienne. Она особенно учтиво встретила отца с дочерью и проводила их к княжне. Княжна с взволнованным, испуганным и покрытым красными пятнами лицом выбежала, тяжело ступая, навстречу к гостям, и тщетно пытаясь казаться свободной и радушной. Наташа с первого взгляда не понравилась княжне Марье. Она ей показалась слишком нарядной, легкомысленно веселой и тщеславной. Княжна Марья не знала, что прежде, чем она увидала свою будущую невестку, она уже была дурно расположена к ней по невольной зависти к ее красоте, молодости и счастию и по ревности к любви своего брата. Кроме этого непреодолимого чувства антипатии к ней, княжна Марья в эту минуту была взволнована еще тем, что при докладе о приезде Ростовых, князь закричал, что ему их не нужно, что пусть княжна Марья принимает, если хочет, а чтоб к нему их не пускали. Княжна Марья решилась принять Ростовых, но всякую минуту боялась, как бы князь не сделал какую нибудь выходку, так как он казался очень взволнованным приездом Ростовых.
– Ну вот, я вам, княжна милая, привез мою певунью, – сказал граф, расшаркиваясь и беспокойно оглядываясь, как будто он боялся, не взойдет ли старый князь. – Уж как я рад, что вы познакомились… Жаль, жаль, что князь всё нездоров, – и сказав еще несколько общих фраз он встал. – Ежели позволите, княжна, на четверть часика вам прикинуть мою Наташу, я бы съездил, тут два шага, на Собачью Площадку, к Анне Семеновне, и заеду за ней.
7.1 Свойства ACID
7.1.1 Во время выполнения данного контрольного тестирования Тестируемая система должна обладать свойствами ACID
(Atomicity, Consistency, Isolation, Durability (Атомарность, Последовательность, Изоляция, Устойчивость)), являющимися ключевыми для систем обработки транзакций.
7.1.2 Целью данного разделна является неформальное описание свойств ACID
и указание серий тестов, которые необходимо исполнить для демонстрации того, что обладание этими свойствами обеспечено.
7.1.3 Ни одна конечная последовательность тестов не может доказать, что свойства ACID
поддерживаются в полной мере. Прохождение заданных тестов является необходимым, но не достаточным условием соответствия требованиям о свойствах ACID
. Однако, для чистоты составления отчетов, необходимыми будут считаться только тесты, указанные здесь, и только они должны быть представлены в Отчете по этому контрольному тестированию.
Примечание
: целью этих тестов является демонстрация того, что принципы ACID поддерживаются Тестируемой системой и применяются во время Выполнения теста. Они не созданы для того, чтобы являться тестами исчерпывающего подтверждения качества.
7.1.4 Во время Выполнения теста должна быть применена конфигурация, необходимая для обеспечения полного соблюдения свойств ACID
. Это относится как к базе данных (включая таблицы TPC-E и Определенные пользователем объекты), так и к Сессиям базы данных, используемым для проведения тестов ACID
и Выполнения контрольного теста.
Примечание 1
: понятие «конфигурация» включает в себя все свойства базы данных и характеристики, которые могут быть определены извне; оно включает в себя, не ограничиваясь только ими, файлы конфигурации и инициализации, настройки окружения, комманды и хранимые процедуры SQL, загружаемые модули и надстройки. К примеру, если SUT
основана на Журналах Отмены/Возврата, то ведение журнала должно вестись для всех Транзакций, включая те, которые не содержат возможность отката в Профиле Транзакции.
Примечание 2
: в случаях, когда это контрольное тестирование реализуется на распределенной системе, необходимо провести тесты, проверяющие, что Транзакции, обрабатываемые на двух и более узлах, соответствуют свойствам ACID
.
7.1.5 Несмотря на то, что тесты ACID
не проверяют все типы Транзакций в этом объеме работ, свойства ACID
должны быть соблюдены для всех Транзакций.
7.1.6 Организаторы, предоставляющие результаы TPC, должны выполнить тесты ACID на одной любой из систем, для которой предоставляются результат, при условии того, что они используют одинаковые программные средства реализации (например Операционную систем, СУБД, программы транзакций). Например, содержимое этого пункта будет уместно применить в случае, когда Результаты предоставляются для множества систем из одной линии продукции. Однако тесты Устойчивости, описанные в Пунктах 7.5.2.2, 7.5.2.3 и 7.5.2.4 должны быть пройдены на всех оцениваемы системах. Все FDR должны отображать системы, используемые для проверки требований ACID
, а также полное описание примененных тестов ACID
и полученных в них результатах..
7.2 Требования Атомарности
7.2.1 Определение свойства Атомарности
Тестируемая система должна гарантировать, что Транзакции базы данных атомарны; система будет либо осуществлять все отдельные операции с данными, либо обеспечивать, что ни одна из частично законченных операций н икоим образом не оказывает какого-либо эффекта на данные.
7.2.2 Тесты Атомарности
Выполните рыночную Транзакцию Trade-Order, установив значение флага roll_it_back равным 0. Проверьте, что соответствующие ряды были добавлены в таблицы TRADE и TRADE_HISTORY.
Выполните рыночную Транзакцию Trade-Order, установив значение флага roll_it_back равным 1. Проверьте, что в таблицы TRADE и TRADE_HISTORY не было добавлено каких либо рядов, связанных с Транзакцией Trade-Order.
7.3 Требования Последовательности
7.3.1 Определение свойства Последовательности
Последовательность - это свойство Приложения, которое трубет, чтобы любое выполнение Транзакции базы данных приводило к ее переход из одного состояния в другое.
7.3.1.1 База данных TPC-E, впервые заполненная при помощи EgenLoader, должна обладать свойствами последовательности.
7.3.1.2 Если производится репликация данных, как это разрешено в пункте 2.3.3.3, каждая копия должна соответствовать состояним ппоследовательность, как описано в пункте 7.3.2.
7.3.2 Состояния Последовательности
В следующих пунктах дается определение трем состояния последовательности. Для каждого из трех состояний требуется явная демонстрация того, что состояния соблюдены.
7.3.2.1 Состояние последовательности 1
B_NUM_TRADES = count(*)
для каждого брокера, определяемому следующим:
7.3.2.2 Состояние последовательности 2
Записи в таблицах BROKER и TRADE должны соблюдать отношение:
B_COMM_TOTAL = sum(T_COMM)
для каждого брокера, определяемого следующим:
(B_ID = CA_B_ID) и (CA_ID = T_CA_ID) и (T_ST_ID = «CMPT’).
7.3.2.3 Состояние последовательности 3
Записи в таблицах HOLDING_SUMMARY и HOLDING должны соблюдать отношение:
HS_QTY = sum(H_QTY)
для каждой группы активов, определяемой следующим:
(HS_CA_ID = H_CA_ID) и (HS_S_SYMB = H_S_SYMB).
7.3.3 Тесты последовательности
Необходимо выполнять тестирование трех состояний последовательности как после начального заполнения базы данных, так и после любых тестов Восстановления бизнеса.
7.4 Требования изоляции
7.4.1 Определение свойства изоляции
7.4.1.1 Рассматривая Транзакцию T1 и одновременно выполняющуюся Транзакцию T2, можно описать следующие явления (от P0 до P3), возникающие в T1.
- P0 («Грязная запись») - Транзакция T2 изменяет (или внедряет) элементы данных R. Затем, перед осуществлением действий подтверждения COMMIT транзакции T2, начинается Транзакция T1, которая может изменить (или удалить) элементы данных R и в дальшейм может выполнить COMMIT.
- P1 («Грязное чтение») - Транзакция T2 изменяет (или вводит) элементы данных R. Затем, прежде чем T2 выполняет COMMIT, начинается Транзакция T1, считывает элементы данных R и способна получить состояние элементов данных таким, каким оно стало послед изменения T2. В дальнейшем, T2 может выполнить операцию ROLLBACK.
- P2 («Неповторяемое чтение») - Транзакция T1 осуществляет чтение элементов данных R. Затем, перед выполнением COMMIT Транзакцией Т1, начинается Транзакция T2, которая изменяет (или удаляет) элементы данных R и выполняет COMMIT. Затем T1 повторяет чтение элементов данных R и может получить состояние элементов данных после изменения Транзакцией T2.
- P3 («Фантомное чтение») - Транзакция T1 осуществляет чтение набора элементов данных, которые соответствуют некому. Далее, перед тем, как Транзакция T1 выполнит операцию COMMIT, начинается Транзакция T2, которая вносит или удаляет один или более элементов данных, соответствующих, используемому T1. Затем T1 повторяет начальное чтение по тому же и может получить набор элементов данных, отличающихся от изначального.
7.4.1.2 Изоляция - это свойство Транзакции, показывающую степень на которую она изолирована от действий других выполняющихся одновременно с ней Транзакций. Таблица, представленная ниже, которая выстроена от наименьшего (L0) до наибольшего (L3) уровня ограничений, описывает четыре степени изоляции, основанных на том, какое из явлений не должно произойти
7.4.1.3 Во время Выполнения теста каждая Транзакция TPC-E должна обеспечивать степень изоляции от Произвольных транзакций не меньшую, чем степень, указанная в нижеследующей таблице:
7.4.1.4 Во время Выполнения теста SUT
должна позволять одновременное выполнение Произвольных Транзакций.
7.4.1.5 Во время Выполнения теста, данные, считываемые каждой Транзакцией TPC-E, должны быть не старше самых новых Подтвержденных данных на момент начала Транзакции.
7.4.1.6 Системы, реализующие изоляцию Транзакций при помощи методов блокирования или создания версий, должны продемонстрировать соблюдение требований изоляции путем прохождения тестов, описанных в Пункте 7.4.2.
7.4.1.7 Системам, реализующуим изоляцию Транзакций при помощи техник, отличных от блокирования или создания версий, могут понадобиться другие техники для демонстрации того, что требования изоляции соблюдены. В обязанности Организатора теста входит совместно с Аудитором определить эти техники, реализовать их, выполнить в качестве демонстрации соответствия требованиям изоляции и предоставить достаточное количество информации в FDR
для сопровождения утверждения о том, что требования изоляции были соблюдены.
7.4.2 Тесты изоляции
Нижеследующие тесты изоляции разработаны для проверки того, то конфигурация и реализация Тестируемой системы обеспечивает Транзакции необходимыми степенями изоляции, которые описаны в пункте 7.4.1.3.
7.4.2.1 Тест P3 в Чтении-Записи
Этот тест должен продемонсттрировать, что Транзакция чтения-записи Trade-Result во время выполнения одновременно с другой Транзакцией чтения-записи Trade-Result защищена от Фантомного явления P3. Вторая Транзакция Trade-Result (Сессия S4 ниже) выполняет функции Произвольной Транзакции, которая добавляет ряд в таблицу HOLDING_SUMMARY, к которой уже осуществлен доступ первой Транзакцией Trade-Result (Сессия S3 ниже).
В целях проведения этого тестирования две этих Транзакции Trade-Result должны быть подготовлены для выполнения записи hs_qty после возвращения из Фрейма 1. Помимо этого, Транзакция Trade-Result, выполненная S3, должна иметь возможность повторить выполнение Фрейма 1 и приостановить свое выполнение до начала выполнения Фрейма 2.
1. Из S1 выберите acct_id. Выполнив указанную транзакцию в режиме только для чтения, найдите величину symbol, для которой не существует соответствующего ряда в таблице HOLDING_SUMMARY по выбранному параметру acct_id и выполните подтверждение.
2. Из S1 вызовите и успешно завершите Транзакцию Trade-Order для параметров acct_id и symbol, выбранных на шаге 1. Запишите trade_id, связанный с этими торгами.
3. Из S2 запростие и успешно завершите другую Транзакцию Trade-Order для параметров acct_id и symbol, использовавшихся на шаге 2. Запишите trade_id, связанный с этими торгами.
4. Из S3 запросите trade_id из Trade-Result, использовавшийся в шаге 2. Приостановите выполнение транзакции между Фреймом 1 и Фреймом 2. Запишите hs_qty и проверьте, что он установлен равным нулю.
5. Из S4 запросите trade_id из Транзакции Trade-Result, использовавшийся в шаге 3. Проверьте, что транзакция завершает Фрейм 1 и начинает выполнение Фрейма 2. Запишите hs_qty и проверьте, что он установлен равным нулю.
Прецедент A, в случае, если S4 останавливается во Фрейме 2 и затем откатывается, в то время как S3 завершается:
6A. Из S3 повторие выполнение Фрейма 1 и приостановите вновь между Фреймом 1 и Фреймом 2. Запишите hs_qty и проверьте, что его значение установлено равным нулю.
7A. Возобновите выполнение S3 на Фрейме 2. Проверьте успешное завершение оставшихся Фреймов.
8A. Проверьте, что S4 было откачено.
6C. В случае возникновения такой ситуации, тест считается недействительным. Для того, чтобы осуществить корректное тестирование защищенности от фантомных чтений, необходимо, чтобы сессия S4 достигла момента во Фрейме 2 Транзакции Trade-Result, когда в таблицу HOLDING_SUMMARY добавляется новый ряд. Возможно, что Транзакцию Trade-Result, используемую для S4, может понадобиться модифицировать таким образом, чтобы предотвратить ее блокировку во Фрейме 1. К примеру, она может быть запущена на более низкой степени изоляции Произвольной Транзакции.
Примечание 1
: Тест P3 считается успешно пройденным, если произошел либо Прецедент A, либо B. И он считается проваленным в случае возникновения Прецедента C. Могут существовать и другие корректные варианты (например, и S3 и S4 могут не завершиться успешно), но если и S3 и S4 осуществляют запись hs_qty = 0 во время исполнения Фрейма 1, то тогда максимум одна из этих Сессий может завершиться нормально и подтвердить Транзакцию. Целью этого теста является демонстрация того, что при любых условиях в случае, когда S3 повторяет чтение таблицы HOLDING_SUMMARY после того, как S4 добавила (или попыталась добавить) новый ряд для выбранных параметров acct_id и symbol, удовлетворяющий условиям ряд все равно не будет найден в S3.
Примечание 2
: данный тест изоляции создает один или более новых активов. Последующее выполнение Теста P2 в Чтении-Записи (см. пункт 7.4.2.2) для тех же выбранных параметров acct_id и symbol может привести к к закрытию позиции, созданной во время этого теста.
7.4.2.2 Тест P2 в Чтении-Записи
Этот тест отображает, что Транзакция чтения-записи Trade-Result во время одновременного исполнения другой Транзакции чтения-записи Trade-Result защищена от явления Неповторяемого чтения P2. Вторая Транзакция Trade-Result (Сессия S4 ниже) выполняет роль Произвольной Транзакции, которая обновляет ряд в таблице HOLDING_SUMMARY, который был прочитна первой Транзакцией Trade-Result (Сессия S3 ниже).
В целях проведения этого тестирования две этих Транзакции Trade-Result должны быть подготовлены для выполнения записи hs_qty после возвращения из Фрейма 1. Помимо этого, Транзакция Trade-Result, выполненная S3, должна иметь возможность повторить выполнение Фрейма 1 и приостановить свое выполнение до начала выполнения Фрейма 2.
Используя четыре Сессии от S1 до S4, в соответствующем порядке выполняются следующие этапы.
1. Из S1 выберите acct_id. Выполнив указанную транзакцию в режим только для чтения, найдите величину symbol, для которой существует соответствующий ряд в таблице HOLDING_SUMMARY для выбранного acct_id, запишите HS_QTY для этого актива и выполните подтверждение.
2. Из S1 запросите и успешно завершите Транзакцию Trade-Order с параметрами acct_id и symbol, выбранными на этапе 1. Запишите параметр trade_id, связанный с этими торгами.
3. Из S2 запросите и успешно завершите другую Транзакцию Trade-Order с параметрами acct_id и symbol, использовавшихся на шаге 2. Запишите параметр trade_id, связанный с этими торгами.
4. Из S3 запросите Транзакцию Trade-Result с параметром trade_id, полученным на этапе 2, и приостановите выполнение между Фреймом 1 и Фреймом 2. Запишите hs_qty и проверьте, что он равен HS_QTY, полученному на этапе 1.
5. Из S4 запросите Транзакцию Trade-Result с параметром trade_id, полученным на этапе 3. Проверьте, что он завершает Фрейм 1 и начинает выполнение Фрейма 2. Запишите hs_qty и проверьте, что он равен HS_QTY, полученному на этапе 1.
Прецедент A, если S4 останавливается во Фрейме 2, затем откатывается, в то время как S3 завершается:
6A. Из S3 повторите вызов Фрейма 1 и и вновь приостановите выполнение между Фреймами 1 и 2. Запишите hs_qty и проверьте, что он равен HS_QTY, полученному на этапе 1.
7A. Возобновите выполнение S3, вызвав Фрейм 2. Проверьте успешное выполнение оставшихся Фреймов.
8A. Проверьте, что S4 была откачена.
Прецедент B, в случае, если S4 завершается (возможно, после остановки) и S3 откатывается:
6B. Проверьте, что S4 завершает выполнение Фрейма 2 и оставшихся Фреймов.
7B. Проверьте, что S3 была откачена.
Прецедент C, если S4 останавливается во Фрейме 1 (некорректно):
6C. В случае возникновения такой ситуации, тест считается недействительным. Для того, чтобы осуществить корректное тестирование защищенности от события Неповторяемого чтения Р2, необходимо, чтобы сессия S4 достигла момента во Фрейме 2 Транзакции Trade-Result, когда в таблице HOLDING_SUMMARY обновляется один из рядов. Возможно, что Транзакцию Trade-Result, используемую для S4, может понадобиться модифицировать таким образом, чтобы предотвратить ее блокировку во Фрейме 1. К примеру, она может быть запущена на более низкой степени изолт яции Произвольной Транзакции.
Примечание:
этот тест считается успешно пройденным, если произошел либо Прецедент A, либо B. И он считается проваленным в случае возникновения Прецедента C. Могут существовать и другие корректные варианты (например, и S3 и S4 могут не завершиться успешно), но если и S3 и S4 осуществляют запись одного и того же значения hs_qty во время исполнения Фрейма 1, то тогда максимум одна из этих Сессий может завершиться нормально и подтвердить Транзакцию. Целью этого теста является демонстрация того, что при любых условиях в случае, когда S3 повторяет чтение таблицы HOLDING_SUMMARY по заданным acct_id и symbol, найденный ряд и значение будут такими же, как на этапе 1.
7.4.2.3 Тест P1 в Чтении-Записи
Этот тест отображает, что Транзакция чтения-записи Trade-Result во время одновременного исполнения другой Транзакции чтения-записи Trade-Result защищена от события грязного чтения P1. В целях данного тестирования Транзакция Trade-Result должна быть сконфигурирована для выполнения записи se_amount после возврата из Фрейма 5 и должна иметь возможность приостановить выполнение во Фрейме 6 непосредственно перед подтверждением.
Используя три Сессии от S1 до S3 в соответствующем порядке выполняются следующие этапы
1. Из S1 вызовите Транзакцию Customer-Position по выбранному параметру cust_id, завершите Транзакцию и запишите набор итоговых параметров acct_id и cash_ball.
2. Из S1 вызовите и успешно завершите Транзакцию Trade-Order с параметром acct_id, выбранном из набора, записанного на этапе 1 по заданному параметру symbol и со значением type_is_margin равным 0. Запишите trade_id, назначенный этим торгам.
3. Из S1 вызовите и успешно завершите другую Транзакцию Trade-Order с тем же параметром acct_id, но отличающимся от использовавшегося на этапе 2 параметром symbol и параметром type_is_margin, установленным равным 0. Запишите trade_id, назначенный этим торгам.
4. Из S2 вызовите Транзакцию Trade-Result со входным параметром trade_id, полученным на этапе 2. Перед вызовом Фрейма 6 запишите se_amount, затем вызовите Фрейм 6 и приостановите выполнение перед подтверждением.
5. Из S3 вызовите Транзакцию Trade-Result со входным параметром trade_id, полученным на этапе 3. Транзакцияю может быть приостановлена, может не завершиться успешно или оказаться временно заблокированной от полного выполнения. Если она достигает начала Фрейма 6, запишите se_amount, затем вызовите Фрейм 6. Если она достигнет конца Фрейма 6, приостановите перед подтверждением.
6. Из S2 продолжите с подтверждения и успешного завершения Транзакции. Запишите результирующее значение параметра acct_bal.
7. Из S3 в зависимости от того, каково было поведение транзакции в конце этапа 5:
Если она достигла приостановки во Фрейме 6, позвольте ей продолжить работу и проверьте, что она была Подтверждена и успешно завершилась.
Если она оказалась заблокирована перед окончанием Фрейма 5, проверьте, что она была разблокирована завершила Фрейм 5, записала se_amount, вызвала Frame
6, была Подтверждена и успешно завершилась.
Если она не завершилась успешно и была откачена, повторите вызов Транзакции Trade-Result с тем же входным параметром trade_id. Проверьте, что Транзакция Trade-Result выполняеться полностью, записывает значение se_amount в начале Фрейма 6, подтверждается в конце Фрейма 6 и успешно завершается.
8. Из S3 запишите полученный в результате acct_bal и проверьте, что он равен значению cash_bal из этапа 1 (при использовании acct_id, выбранного на этапе 2) плюс сумме выходных данных se_amount по этим двум Транзакциям Trade-Result.
7.4.2.4 Тест P1 в Чтении-Записи
Этот тест отображает, что Транзакция чтения-записи Customer-Position во время одновременного исполнения Транзакции чтения-записи Trade-Result защищена от события грязного чтения P1. В целях данного тестирования Транзакция Trade-Result должна иметь возможность приостановить выполнение во Фрейме 6 непосредственно перед подтверждением.
Используя четыре Сессии от S1 до S4, в соответствующем порядке выполняются следующие этапы:
1. Из S1 вызовите Транзакцию Customer-Position по выбранному параметру cust_id, завершите Транзакцию и запишите набор итоговых параметров acct_id и cash_ball.
2. Из S1 вызовите и успешно завершите Транзакцию Trade-Order, в которой соответствующий входной параметр acct_id соответствует одному из параметров acct_id, записанных на этапе 1, а значение type_is_margin равно 0. Запишите trade_id, назначенный этим торгам.
3. Из S2 вызовите Транзакцию Trade-Result со входным параметром trade_id, полученным на этапе 2, и затем приостановите выполнение во Фрейме 6 перед подтверждением.
4. Из S3 вызовите Транзакцию Customer-Position со входным параметром cust_id, выбранным на этапе 1. Транзакцияю может завершиться успешно или некорректно или может быть временно заблокирована от полного выполнения.
5. Из S2 продолжите с продолжения и успешного завершения Транзакции Trade-Result. Запишите полученный в результате acct_bal.
6. Из S3, зависящего от поведения Транзакции Customer-Position в конце этапа 4:
Если она завершилась, запишите набор результирующих acct_id и cash_bal и проверьте, что значения cash_bal по acct_id, использованному на этапе 2, остались остались неизменны с первого этапа.
Если она была заблокирована, проверьте, что теперь она завершена, запишите набор результирующих acct_id и cash_bal и проверьте, что значение cash_bal для заданного acct_id, использовавшийся на этапе 2, соответствует acct_bal из этапа 5.
Если она не была исполнена, перейдите к следующему этапу.
7. Из S4 вызовите Транзакцию Customer-Position с параметром cust_id, выбранным на этапе 1, завершите Транзакцию, запишите набор результирующих параметров acct_id и cash_bal и проверьте, что cash_bal для заданного acct_id, использовавшийся на этапе 2, изменился по сравнению с этапом 1 и отражает объем торгов, выполненных на этапе 5 (путем сравнения с acct_bal из этапа 5).
7.5 Требования устойчивости
Тестируемая система должна быть сконфигурирована таким образом, чтобы удовлетворять требованиям устойчивости, приведенным в этом пункте. Тестируемая система демонстрирует свойства устойчивости в случае сохранения Подтвержденных Транзакций и поддержания структуры базы данных после сбоев, перечисленных в пункте 7.5.2. Тестирование Устойчивости осуществляется путем вызова Катастрофических и Некатастрофических сбоев компонент SUT
. Некатастрофические сбои, описанные в пункте 7.5.5, тестируют способность SUT
сохранять возможность доступа к данным. Катастрофические сбои, описанные в пункте 7.5.6 тестируют возможности SUT
по сохранению последствий Подтвержденных Транзакций. Продолжительность последствий Катастрофического сбоя описывается в Отчете о тестировании как Время восстановления деловых процессов. Ни одна из существующих систем не предоставляет абсолютную Устойчивость (т.е. Устойчивость при любых вариантах сбоев). Конкретный набор одиночных сбоев, перечисленных в Пункте 7.5.2 считается достаточно показательным для утвержденияя наличия Устойчивости в случаях таких сбоев. Однако, ограниченная суть приведенных тестов не должна быть интерпретирована как допустимость существования других невосстановимых случаев одиночных сбоев.
7.5.1 Определение понятий
Доступность
: Возможность выполнять операции базы данных с полным доступом к данным после перманентного невосстановимого краха любого одного Постоянного носителя
, содержащего таблицы базы данных, данные журнала восстановления или Метаданные базы данных
. См. Пункт 7.5.2.1.
7.5.1.1
Восстановление приложения
Катастрофического
7.5.1.2
Время восстановления
приложения: Время, прошедшее с момента начала Восстановления
приложения до конца (см. Пункт 0).
7.5.1.3
Восстановление бизнеса
: Процесс восстановления бизнес-приложения после Катастрофического
сбоя системы и достижения точки, когда бизнес достигает определенных эксплуатационных критериев.
7.5.1.4
Время Восстановления бизнеса
: Время, прошедшее с момента начала Восстановления
приложения
до конца (см. Пункт 7.5.6.8).
7.5.1.5
Катастрофический
: Тип сбоя, при котором обработка прервана без предупреждения, данного SUT
. После этого сбоя, в отношении только упавшей базы данных очищается вся память и теряется весь контекст активных приложений.
7.5.1.6
Подтвержденная
: Транзакция
является Подтвержденной
, когда ее действия (Add, Remove, Modify
) Постоянны
и видимы для других Транзакций
7.5.1.7 Примечание
: Транзакции могут быть Подтверждены без последующего получения Драйвером оповещения об этом факте, поскольку целостность сообщений не является необходимой.
7.5.1.8.Восстановление базы данных
: Процесс восстановления базы данных после Катастрофического сбоя системы.
7.5.1.9 Время Восстановления базы данных
: Длительность от начала Восстановления базы данных
до момента, когда файлы базы данных полностью восстановлены.
Требования оценки Устойчивости
: условия, которым должно удовлетворять SUT
во время всех тестов Устойчивости
(см. Пункт 7.5.3)
7.5.1.10 Устойчивое
: состояние, которое выдерживает сбои (как описано в Пункте 7.5.2) и которое имеет семантики транзакционного обновления.
7.5.1.11
Постоянный носитель
: энергонезависимое постоянное хранилище данных, такое как магнитный диск или лента.
7.5.1.12
Понятие Некатастрофичный
относится к одиночному сбою, в результате которого обработка не прерывается, но может упасть производительность и SUT
больше не может находиться в устойчивом состоянии до тех пор, пока не восстановится после сбоя.
7.5.2 Одиночные точки сбоев
Нижеследующие пункты описывают отдельные компоненты SUT, тестируемые Некатастрофическими и Катастрофическими сбоями, описанными в пунктах 7.5.5 и 7.5.6. Одиночные точки сбоев применяются к компонентам SUT, необходимым для обеспечения выполнения требований Устойчивости.
Организатор Теста может применить один тест для осуществления тестирования на соответствие требованиям устойчивости на нескольких одиночных точках сбоя (например, одиночный «тест полного отказа системы" может быть применен для трех точек сбоя, описанных в Пунктах 7.5.2.2, 7.5.2.3 и 7.5.2.4).
7.5.2.1 Постоянный невосстановимый отказ одного из Постоянных носителей.
7.5.2.2 Мгновенный обрыв
(отказ системы/зависание системы) в процессе обработки, для восстановления которого требуется перезагрузка системы.
Примечание
: здесь подразумевается также некорректное завершение работы, в случае которого требуется загрузка новой копии Операционной системы с загрузочного устройства. Оно необязательно означает потерю данных в непостоянной памяти. Примером механизма преодоления события мгновенного обрывая в обработке является Журнала Отмены/Возврата.
7.5.2.3 Сбой всего пространства памяти
(потеря содержимого).
Примечание
: это подразумевает отказ всего пространства памяти. Это может быть вызвано прекращением подачи внешнего питания или перманентной поломки платы памяти.
7.5.2.4 Прекращение внешнего питания SUT
на неопределенный период времени (сбой питания). Это должно включать в себя по меньшей мере все части SUT
, которые участвуют в этапах работ Транзакций с базой данных.
Примечание
: требования защиты от сбоя питания может быть выполнено путем использования достаточного количества ИБП для гарантирования доступности со стороны системы ко всем компонентам, попавшим в ситуацию сбоя питания, в течение 30 минут. Использование конфигурации, защищенной ИБП, не должно привносить новые одиночные точки сбоя, которые не защищены другими частями конфигурации. Это требование может быть доказано либо через измерение, либо через расчет величины потребления электроэнергии за 30 минут (в Ваттах) защищенной частью SUT
, умноженной на 1.4.
7.5.3 Требования оценки устойчивости.
Все тесты Устойчивости должны соответствовать следующим требованиям:
- во время Интервала измерения выполняться с одним и тем же количеством Сконфигурированных Пользователей и Нагрузкой Драйвера
- происходить в Стабильном состоянии
- удовлетворять ограничениям на Время отклика, установленным в пункте 6.5.1.7.
- удовлетворять требованиям к Сочетанию Транзакций, перечисленным в пункте 6.3.1.
- выполняться при значении производительности в 95% и выше от Отчетной без ошибок
- соответствовать всем настройкам конфигурации Драйвера и SUT, применявшиххся во время Интервала измерения.
7.5.4.1 В конфигурациях, в которых схожие функции контрольного тестирования выполняются более чем одним экземпляром Операционной системы, тестирования на сбои, перечисленные в пункте 7.5.2 должны быть выполнены на по меньшей мере одном из этих экземпляров.
7.5.4.2 Если множественные экземпляры Операционной системы управляют данными, обрабатываемыми как единый образ с точки зрения приложений контрольного тестирования (например, кластер базы данных), то тест Сбоя Питания также должен быть произведен одновременно на всех этих экземплярах.
Примечание : Сбой питания множества экземпляров в SUT должен произойти в течение 3 секунд для внесения различий в результатах работы процедур, выполняемых вручную, которые могут быть использованы для завершения теста.
7.5.4.3 Если более одного экземпляра Операционной системы управляют данными, которые обрабатываются в приложении контрольного тестирования как единый образ и соединены посредством физического носителя, отличающегося от встроенной шины (например, кабель расширения шины, высокоскоростная ЛВС или другой способ обеспечения связи между множеством экземпляров Операционной системы, который может быть подвержден физическому нарушению), мгновенное прерывание такой связи включается в список объектов, которые должны быть протестированы согласно пункту 7.5.2.2. Необходимо проверить обрыв только одного из экземпляров соединений, применяющих избыточность.
Примечание : в данном пункте не ставится цель установить требование об осуществлении обрыва соединения с дисковыми хранилищами или дисковыми подсистемами, обладающими избыточностью.
7.5.5 Некатастрофические Сбои
Некатастрофический сбой - это любой сбой, при котором не теряются данные, хранимые в памяти SUT
, или при которых не требуется новая загрузка Операционной системы с загрузочного устройства. Некатастрофические сбои, описанные в этом пункте, оказывают влияние на доступ к данным, хранящимся на Постоянном носителе. Эти требования также носят название требований Доступности данных.
7.5.5.1 SUT
должна поддерживать доступ к данным на Постоянном носителе во время и после сбоя, обозначенного в пункте 7.5.2.1 (перманентный невосстановимый сбой любого одного Постоянного носителя, содержащего таблицы базы данных, данные журнала восстановления или Метаданные базы данных). Организатор теста должен также восстановть окружение Постоянного носителя к состоянию, предшествующему сбою, одновременно поддерживая возможность доступа к данным на Постоянном носителе.
7.5.5.2 Постоянным носителем может быть энергозависимый или энергонезависимый носитель, сконфигурированный соответствующим образом для соответствия требованиям, приведенным в пункте 7.5.2.1. Энергонезависимые носители - это обычно магнитные диски, использующие репликацию (зеркалирование RAID-1) или иные способы защиты (RAID-5 и т.п.), гарантирующие доступ к данным во время сбоя Постоянного носителя. Энергозависимые носители, как, например, память могут быть использованы в случае, если энергозависимые носители могут обеспечить автоматическую передачу данных перед тем, как любые данные будут потеряны, на энергонезависимые носители после сбоя питания независимо от того, когда будет возобновлена подача питания.
Примечание 1
: Сконфигурированный и оцененный Источник Бесперебойного Питания (ИБП) не считается внешним источником питания.
Примечание 2
: Память может считаться Постоянным Носителем в случае, если она может сохранить данные достаточно долго, чтобы соблюсти требования, описанные выше, например, если она дополнена Источником Бесперебойного Питания, и содержимое памяти может быть перенаправлено на энергонезависимый носитель в момент сбоя. Необходимо заметить, что не делается каких либо различий между основной памятью и памятью, выполняющей подобные функции постоянного или временного хранения данных в других частях системы (например, кэше контроллера дисков). Если основная память используется в качестве Постоянного носителя, она должна рассматриваться как потенциальная отдельная точка сбоя. Примером решения проблемы отдельного сбоя Постоянного носителя является зеркалирование Постоянный носителей.
Если память является Постоянный носителем, и для обеспечения Устойчивости используется зеркалирование, то зеркалированные банки памяти должны иметь независимые источники питания.
7.5.5.3 Тесты Доступности данных (также называемые тестами Некатастрофических сбоев) должны соответствовать Требованиям оценки Устойчивости из пункт 7.5.3.
7.5.5.4 Уровни Избыточности
Уровню Избыточности обозначают степень гарантирования доступности данныхв случае одиночного сбоя в компонентах хранилищах данных. В SUT должен применяться один из следующих Уровней Избыточности:
- Избыточность Уровня 1 (Избыточность постоянных носителей): Гарантирует доступ к данным на Постоянных носителях, в случае сбоя на одном из Постоянных носителей.
Пример : Организатор теста реализовал использование RAID-1 (зеркалирование) на дисках в хранилище. В случае сбоя на одном из дисков Организатор должен обеспечить доступ к данным на всех оставшихся дисках.
- Избыточность Уровня 2 (Избыточность Контроллера постоянных носителей): Включает Избыточность Уровня 1 и гарантирует доступ к данным на Постоянных носителях, когда происходит одиночный сбой в контроллере хранилища информации, используемом для достижения уровня избыточности, или в средствах связи между контроллером хранилища данных и Постоянными носителями.
Пример : Если Избыточность Уровня 1 достигнута путем реализации защиты RAID-5 в дисковом, то Избыточность Уровня 2 будет тестироваться при помощи сбоя в оборудовании, используемом для реализации защиты RAID-5.
Если контроллер, реализующий RAID-5, содержится в дисковой конструкции (или подобном внешне подключаемом устройстве), то Организатор должен продемонстрировать, что все еще способен получить доступ к данным хранящимся внутри конструкции.
Если контроллер, реализующий RAID-5 располагается отдельно от enclosure, содержающего диски, и контроллер не используется в качестве Постоянного носителя (например, зеркалированный кэш записей), то является достаточным оборвать соединения между контроллером и дисковой конструкцией.
- Избыточность Уровня 3 (Полная избыточность): Включает Избыточность Уровня 2 и гарантирует доступ к данным на Постоянных носителях, когда происходит одиночный сбой в системе Постоянных носителей, включая связи между Уровнем B и системой Постоянных носителей.
Примечание 2 : задачей данного пункта является протестировать способности системы Уровня В выдерживать сбои ее компонент и продолжать обработку Транзакций.
Примечание : компоненты, тестируемые в этом пункте, считаются быстро заменяемыми модулями. Задачей этого пункта не является поставить Организатору задачу протестировать устойчивость соединительной платы в хранилище Постоянных носителей или подобных незаменяемых компонент. В то же время в задачи тестирования входит проверка свойств устойчивости ко сбоям контроллеров хранилищ, включая зеркалированный кэш на контроллере, и соответствующее программное обеспечение.
7.5.5.5 Процедура тестирования Устойчивости в целях Доступности данных
1. Определите текущее количество завершенных торгов в базе данных, выполнив запрос:
select count(*) as count1 from SETTLEMENT
2. Начните отправлять на обработку Транзакции и наращивать производительность до уровня Требований оценки Устойчивости (как описано в пункте 7.5.3) и придерживайтесь на этом уровне по меньшей мере 5 минут.
Примечание
: Как только Требования оценки Устойчивости будут соблюдены:
- запрещены любые изменения в конфигурации Драйвера до завершения этапа 5
- запрещены любые изменения в конфигурации SUT за исключением тех, которые необходимы для выполнения этапов 3 и 4.
4. Начните необходимые процедуры восстановления.
5. Продолжайте работу Драйвера в течение 20 минут.
6. Корректно завершите выполнение из Драйвера.
7. Получите новое количество завершенных торгов в базе данных, выполнив:
8. Сравните число выполненных Драйвером Транзакций Trade-Result с величиной
(count2 - count1). Проверьте, что (count2 - count1) равно количеству записей успешно выполненных Транзакций Trade-Result в файле журнала Драйвера.
9. Позвольте процедуре восстановления завершиться положенным образом.
7.5.6 Катастрофические сбои.
Некоторые сбои по своей сути могут быть Катастрофичны, и в таких случаях теряется доступ к данным. SUT должна иметь возможность сохранять состояние базы данных и восстанавливать доступ к данным в кратчайшие сроки.
Катастрофические сбои внезапны и непредсказуемы по своей сути, часто приводя к неожидаемой потере в обработке транзакций. Требования, приведенные в этом пункте, тестируют способности SUT сохранять последствия Подтвержденных Транзакций. Поскольку возможность обрабатывать транзакции является ключевой в среде OLTP, Организатор теста должен измерить и привести в отчете время, необходимое СУБД для восстановаления после Катастрфических сбоев. Это время восстановления носит название Времени восстановления Бизнеса.
Примечание : Катастрофические сбои являются огромной преградой для осуществления деловых процессов, следовательно для бизнеса является обязательным восстанавление от таких сбоев столь быстро, насколько это возможно. Существует множество параметров конфигурации базы данных и различных практик, которые напрямую влияют на производительность СУБД и ее время восстановления после Катастрофического сбоя. Хотя общеизвестно, что время загрузки на разных системах может варьироваться в очень большом диапазоне, параметры загрузки оказывают исчезающе малый эффект на производительность СУБД и не являются часть Времени восстановления Бизнеса.
7.5.6.1 Тесты Катастрофических сбоев должны соотвествовать Требованиям оценки Устойчивости, приведенным в Пункте 7.5.3.
7.5.6.2 Разверните образ восстановления из архивной копии базы данных (например, копии, сделанной перед выполнением), использование данных журнала Возврата/Отмены не является приемлемым в качествет механизма восстановления в случае сбоев, перечисленных в пунктах 7.5.2.2, 7.5.2.3 и 7.5.2.4. Необходимо заметить, что контрольные точки, точки проверки, точки последовательности (и им подобные) базы данных, созданные во время выполнения работы, не считаются архивными данными.
7.5.6.3 Если механизм восстановления полагается на содержимое энергозависимой памяти перед сбоем, то средства, используемые для избежания потери содержимого энергозависимой памяти (например, Источник Бесперебойного Питания) должны быть учтены при расчете стоимости системы (см. пункт 8.3.1.3).
7.5.6.4 Начало восстановления базы данных- это время, когда к файлам базы данных впервые осуществляется доступ со стороны процесса, который обладает сведениями о содержимом тех файлов, и нацелен на восстановление базы данных или выполнение Транзакций, работающих с базой данных.
Примечание : обращения к файлам процессами Операционной системы с целью проверки целостности файловой системы или томов для исправления ошибок в структурах данных не означает начало Восстановления базы данных.
7.5.6.5 Окончание Восстановления базы данных - это момент, в который файлы базы данных были восстановлены.
Примечание : обычно база данных будет указывать это время в ее файлах журналов.
7.5.6.6 Начало Восстановления Приложения - это время, когда после начала Восстановления базы данных отправляется первая Транзакция.
7.5.6.7 Окончание Восстановления Приложений - это момент, в который SUT начинает работать с производительностью большей или равной 95% от Отчетной и продолжает делать это в течение по меньшей мере 20 минут.
7.5.6.8 Процедура тестирования для случаев Катастрофических сбоев
1. Определите текущее количество завершенных торгов в базе данных, выполнив:
select count(*) as count1 from SETTLEMENT.
2. Начните выполнение Транзакций и нарастите производительность до уровня Требований оценки Устойчивости (как описано в пункте 7.5.3) и соблюдайте эти требования по меньшей мере 20 минут.
3. Осуществите один или более Катастрофических сбоев из пунктов 7.5.2.2, 7.5.2.3 или 7.5.2.4.
4. Если это соответствует тестовой конфигурации, прекратите отправлять Транзакции.
5. Если необходимо, перезапустите SUT
(что может подразумевать необходимость полной перезагрузки).
6. Отметьте время начала Восстановления базы данных (см. пункт 7.5.6.4), либо автоматически либо вручную оператором.
7. Когда заканчивается процедура Восстановления базы данных, отметьте время. Это может произойти во время следующих шагов (см. пункт 7.5.6.5).
8. Начните Выполнение Теста 2 или продолжите отправку Транзакций и отметьте этот момент как начало Восстановления Приложений (см. Пункт 7.5.6.6). Нарастите производительность до 95% от Отчетной производительности.
Примечание
: Если между окончанием Восстановления базы данных и началом Восстановления приложений присутствует временной промежуток, и если Драйверам и Транзакциям необходимо быть запущенными заново (а не просто продолжены), то в этом временном промежутке может быть запущена Транзакция Trade-Cleanup.
9. Отметьте окончание Восстановления Приложений, как описано в пункте 7.5.6.7.
10. Корректно завершите работу Драйвера.
11. Проверьте, что Драйвером не было сообщено о каких либо ошибках на этапах с 7-го по 10. Это необходимо для того, чтобы гарантировать, что конечный пользователь не станет свидетелем каких либо негативных эффектов (помимо доступности приложений и потенциально сниженной производиельности) из-за сбоя в SUT
и последующего Восстановления Бизнеса.
12. Получите новое количество завершенных торгов в базе данных, выполнив:
select count(*) as count2 from SETTLEMENT
13. Сравните количество завершенных Драйвером транзакций Trade-Result с величиной (count2 - count1). Проверьте, что (count2 - count1) больше или равно суммарному количеству записей об успешных Транзакциях Trade-Result в файле журнала Драйвера, относящихся к запусками, выполненным на этапе 2 и этапе 7.
Если имеет место быть неравенство, то таблица SETTLEMENT должна содержать дополнительные записи и разница должна быть меньше или равна максимальному количеству Транзакций, которое может одновременно находиться в процессе передачи от Драйвера к SUT
. Это количество связано с реализацией Драйвера и настройками конфигурации в момент сбоя.
Примечание
: эта разница должна существовать только вследствие Транзакций, подтвержденных в Тестируемой системе, для которых, несмотря на это, в Драйвер перед сбоем не были возвращены выходные данные.
14. Проверьте условия последовательности, как указано в Пункте 7.3.3.
15. Рассчитайте Время восстановления бизнеса как сумму Времени восстановления приложения и Времени восстановления базы данных, если эти промежутки времени не накладываются друг на друга. Если Восстановление Приложений начинается до окончания Восстановления базы данных, то Время восстановления бизнеса - это время, прошедшее между началом Восстановления базы данных и концом Восстановления Приложений.
7.5.7 Требуемая отчетность об Устойчивости.
7.5.7.1 Организатор теста должен описать Уровень избыточности и описать тест(ы), использовавшиеся для демонстрации соответствия, в Отчете.
7.5.7.2 График доступности данных
В Отчете должен быть представлен график зависимости Измеренной производительности от прошедшего времени по фрагментам выполнения тестов Доступности данных, подготовленный в соответствии со следующими договоренностями:
- По Оси Х представлено прошедшее время по прогонам тестов, описанных в Пункте 7.5.5.5, по этапам со 2 по 6
- По Оси Y представлено производительность, выраженная в tpsE
7.5.7.3 Отчетные оценки
Время восстановления бизнеса должно быть указано в Итоговом исполнительном постановлении и в Отчете. Если сбои, описанны в Пунктах 7.5.2.2, 7.5.2.3 и 7.5.2.4 не были объединены в один тест Устойчивости (обычно отключая питание Сервера базы данных во время выполнения), то тогда Время восстановления бизнеса после сбоя, описанного для внезапного мгновенного перебоя - это то Время восстановления бизнеса, которое должно быть внесено в Итоговое исполнительное постановление. Все значения Времени восстановления бизнеса по каждому тесту, нуждающемуся в Восстановлении бизнеса, должны быть приведены в Отчете.
7.5.7.4 График Времени восстановления бизнеса
В Отчете должен быть представлен график зависимости Измеренной производительности от прошедшего времени по фрагментам выполнения тестов Восстановления бизнеса, подготовленный в соответствии со следующими договоренностями:
- По оси Х откладывается максимальное из прошедших времен по двум прогонам теста, описанным в пунк7.5.6.8 для этапов 2 и 8
- По оси Y откладывается производительность, выраженная в tpsE
- Должна использоваться размерность масштаба графика, равная 1 минуте.
- Данные для оси Y должны быть приведены по обоим запускам на одном графике, с ясно обозначенными конечными моментами каждого из прогонов.
- В целях создания графика нулевая точка отсчета определяется следующим образом:
- Для прогона, описанного на этапе 2 в пункте 7.5.6.8, нулевая точка отсчета определена как момент времени, в который к базе данных применяется первая Транзакция
- Для прогона, описанного на этапе 8 в пункте 7.5.6.8, нулевая точка отсчета определена как момент времени, в который начинается Восстановление базы данных.
- В целях создания графика, окончание прогона определяется следующим образом:
- Для прогона, описанного на этапе 2 в пункте 7.5.6.8, окончание прогона это момент, в который производится сбой (см. этап 3 пункта 7.5.6.8)
- Для прогона, описанного на этапе 8 в пункте 7.5.6.8, окончание прогона это время, в которое Восстановление Приложений успешно завершилось (см. этап 8 пункта 7.5.6.8)
- Для прогона, описанного на этапе 8 в пункте 7.5.6.8, в случае, если между окончанием Восстановления базы данных и началом Восстановления приложения наличествует любой промежуток времени, этот промежуток должен быть проигнорирован и два этих периода должны быть отображены на графике примыкающими друг к другу.
Требования ACID
Atomicity - Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся в исходное состояние.
Consistency - Согласованность
Одно из самых сложных и неоднозначных свойств из четвёрки ACID. В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции. Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для реляционных СУБД : есть требования целостности типов (domain integrity), целостности ссылок (referential integrity), целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется . В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Isolation - Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Это свойство не соблюдается на уровне изолированности Read Committed и ниже.
Durability - Надежность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Литература
- P.A. Bernstein, N. Goodman, V. Hadzilacos. Concurrency Control and Recovery in Database Systems. - Addison-Wesley, 1986.
Примечания
Wikimedia Foundation . 2010 .
Смотреть что такое "ACID" в других словарях:
acid - ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Substanţă chimică, cu gust acru şi miros înţepător, care înroşeste hârtia albastră de turnesol şi care, în combinaţie cu o bază, formează o sare. 2. adj. (Adesea fig.) Care are proprietăţile unui acid (1),… … Dicționar Român
ACiD - Productions (ACiD) ist eine Scene Artgroup welche sich, 1990 gegründet, ursprünglich auf ANSI Art für Mailboxen spezialisiert hat. In den letzten Jahren fand mit dem Niedergang der Mailbox Szene ein Wechsel zu anderen Hauptaktivitäten wie… … Deutsch Wikipedia
acid - Since the 1960s, when acid was first used to mean the hallucinogenic drug LSD, the word has developed all the connotations of a subculture. Those taking drugs came to be called acid heads or acid freaks; and their way of life came to depend on… … Modern English usage
ACiD - Productions ACiD Productions (ACiD) est un groupe artistique et numérique underground. Fondé en 1990, le groupe était à l origine spécialisé dans le graphisme ANSI pour les BBS. Plus récemment, ils ont étendu leur domaine d application vers d… … Wikipédia en Français
- (англ. «кислота»): В музыке Эйсид хаус, эйсид техно музыкальные жанры. Acid японская рок группа. Acid бельгийская спид/трэш метал группа. Acid Наркотическое вещество LSD 25. В информатике Sony ACID Pro аудиоредактор ACID набор… … Википедия
acid - bitter, sour in taste acerbic, acidulous, biting, piquant, pungent, sharp, tart, vinegarish, vinegary; concept 613 Ant. bland, sweet acid having acidic, corrosive properties acerbic, acidulous, acrid, anti alkaline, biting,… … New thesaurus
Acid - Ac id, a. 1. Sour, sharp, or biting to the taste; tart; having the taste of vinegar: as, acid fruits or liquors. Also fig.: Sour tempered. He was stern and… …
Acid - Ac id, n. 1. A sour substance. 2. (Chem.) One of a class of compounds, generally but not always distinguished by their sour taste, solubility in water, and reddening of vegetable blue or violet colors. They are also characterized… … The Collaborative International Dictionary of English
«A» Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни однойNoSQL системы обычно выбирают высокую производительность не в угоду транзакционной семантике, так как её соблюдение вносит дополнительные затраты на обработку. Многие системы всё же обеспечивают гарантию на уровне ключа или строки(Google BigTable) или предоставляют api для атомарных операций(Amazon DynamoDB), при которой только один поток может модифицировать запись, если вы, к примеру, хотите иметь счётчик посещений пользователя, распределённый по кластеру. Большинство систем придерживаются неблокирующих read-modify-write циклов. Цикл состоит из трёх этапов - прочитать значение, модифицировать, записать. Как видно, в мультипоточной среде есть много вещей, которые могут пойти не так, к примеру, что если кто-то изменит запись между фазами чтения и записи. Основной механизм разрешения таких конфликтов - использование алгоритма Compare and Swap , - если кто-то изменил запись в процессе цикла - мы должны понять, что запись поменялась и повторить цикл до тех пор, пока не установится наше значение, такой алгоритм выглядит более предпочтительным перед полностью блокирующим на запись механизмом. Количество таких циклов может быть очень большим, поэтому нам необходим некий timeout на операцию, по истечению которого операция будет отклонена.
«C» Консистентность
Транзакция достигающая своего нормального завершения и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Учитывая специфику NoSQL к распределению информации по серверам - это означает - все ли реплики, содержащие копию данных всегда содержат одну и туже версию данныхВ силу специфики, современные NoSQL обязаны выбирать высокую доступность и способность к горизонтальному масштабированию кластера, - получается что система не может обеспечить полную согласованность данных и идёт на некоторые допущения в определении понятия согласованности. Различают два подхода:
Строгая консистентность
Такие системы гарантируют, что реплики всегда способны прийти к соглашению об одной версии данных, возвращаемых пользователю. Некоторые реплики не будут содержать это значение, но когда система будет обрабатывать запрос значения по ключу, машина всегда сможет решить, какое значение вернуть - просто оно будет не всегда последним. Как это работает - к примеру у нас есть N реплик одного и того же ключа. Когда приходит запрос на обновление значения ключа, система не отдаст результат пользователю, пока W реплик не ответят, что они получили обновление. Когда пользователь запрашивает значение, система возвращает ответ пользователю ответ тогда, когда хотя бы R реплик вернули одно и то же значение. Тогда мы считаем систему строго консистентной, если соблюдается условие R+W>N . Выбор значений R и W влияет на то, сколько машин должны ответить перед тем, как ответ вернётся пользователю, обычно выбирают условие R+W=N+1 - минимально необходимое условие по обеспечению строгой консистентности.Возможная консистентность
Некоторые системы(Voldemort, Cassandra, Riak ) позволяют выбрать R и W при которых R+WРазрешение этого конфликта различается на разных системах, Voldemort возвращает несколько копий значения, отдавая разрешение конфликта на откуп пользователю. Две версии пользовательской корзины на сайте могут быть слиты без потери информации, тогда как слияние двух версии одного редактируемого документа требует вмешательства пользователя. Cassandra, которая хранит timestamp каждой записи, возвращает самое последнее в случае определения конфликта, этот подход не позволяет слить две версии без потери информации, зато упрощает клиентскую часть.
Cassandra, начиная с версии 1.1 гарантирует, что если вы делаете обновление:
UPDATE Users
SET login="login" AND password="password"
WHERE key="key"
То никакое конкурентное чтение не увидит частичное обновление данных(login изменился, а password - нет), причём это справедливо только на уровне строк, которые находятся в рамках одного column family и имеющие общий ключ. Это может соответствовать уровню изоляции транзакции read uncommitted , при котором разрешаются конфликты lost update . Но Cassandra не предоставляет механизма отката на уровне кластера, к примеру, возможна ситуация, когда login и password, будут сохранены на каком-то количестве нод, но недостаточном W для того, чтобы отдать пользователю верный результат, при этом пользователь вынужден разрешать этот конфликт сам. Механизм обеспечения изоляции заключается в том, что для каждой изменяемой записи создаётся невидимая, изолированная для клиентов версия, которая впоследствии автоматически заменяет старую версию через механизмы Compare and Swap, описанные выше.
«D» Надёжность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.Самым прогнозируемым сценарием сбоя можно рассмотреть отключение питания или рестарт сервера. Полностью надёжная система в данном случае не должна вернуть ответ пользователю, пока не запишет все изменения из памяти на жёсткий диск. Запись на диск слишком долгая операция и многие NoSQL системы идут на компромиссы в угоду производительности.
Обеспечение надёжности в рамках одного сервера
Стандартный диск выдерживает 70-150 операций в секунду, что составляет пропускную способность до 150 Мб/c, ssd - 700 Мб/c, DDR - 6000 - 17000 Мб/c. Поэтому обеспечением надёжности в рамках одного сервера при обеспечении высокой производительности является сокращение числа записи со случайным доступом и увеличение последовательной записи. В идеале, система должна минимизировать число записей между вызовами fsync (синхронизации данных в памяти и на диске). Для этого применяются несколько техник.Контролирование частоты fsync
Redis предлагает несколько способов для настройки того, когда вызывать fsync . Можно настроить, чтобы он вызывался после каждого изменения записи, - что является самым медленным и безопасным выбором. Для улучшения производительности можно вызывать сброс на диск каждые N секунд, в худшем случае вы потеряете данные за N последних секунд, что может быть вполне приемлимо для некоторых пользователей. Если надёжность совсем не критична, то можно отключить fsync и полагаться на то, что система сама в какой-то момент синхронизирует память с диском.Увеличение последовательной записи через логирование
Для эффективного поиска данных NoSQL системы часто используют дополнительные структуры, например - B-деревья для построения индексов, - работа с ним вызывает множественные случайные доступы к диску. Для уменьшения этого некоторые системы (Cassandra, HBase, Riak ) добавляют операции обновления в последовательно-записываемый файл, называемый redo log . Пока некоторые структуры записываются на диск достаточно редко, лог пишется часто. После падения недостающие записи можно восстановить с помощью лога.Увеличение пропускной способности группировкой записей
Cassandra группирует несколько одновременных изменений в течение короткого окна, которые могут быть объединены в один fsync . Такой подход, называемый group commit , увеличивает время отклика для одного пользователя, т.к. он вынужден ждать несколько других транзакций для фиксирования своей. Преимущество здесь получается за счёт увеличения общей пропускной способности, т.к. несколько случайных записей могут быть объединены.Обеспечение надёжности в рамках кластера серверов
Из-за возможности непредвиденных выходов из строя дисков и серверов необходимо распределять информацию по нескольким машинам.Redis представляет собой классическую master-slave архитектуру для репликации данных. Все операции, связанные с мастером, спускаются до реплик в виде лога.
MongoDB представляет собой структуру, в которой заданное количество серверов хранит каждый документ, причём есть возможность задать количество серверов W
HBase достигает мультисерверной надёжности за счёт использования распределённой файловой системы HDFS .
В целом можно заметить некоторую тенденцию современных NoSQL-средств в сторону обеспечения большей консистентности данных. Но всё же пока SQL и NoSQL-средства могут существовать и развиваться параллельно и решать абсолютно разные задачи.
