Глава 7 - Свойства транзакций и системы (ACID)   

Содержание:

7.1.Свойства ACID
7.2.Требования атомарности
7.3 Требования Последовательности
7.4 Требования изоляции
7.5 Требования устойчивости


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

Записи в таблицах BROKER и TRADE должны соблюдать отношение:
B_NUM_TRADES = count(*)

для каждого брокера, определяемому следующим:

(B_ID = CA_B_ID) и (CA_ID = T_CA_ID) и (T_ST_ID = «CMPT’).

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.
Примечание: T2 может выполнить дополнительные операции базы данных, основывающиестя на состоянии, в котором она оставила элементы R, создавая потеенциальную проблему последовательности данных.
  •  P1 («Грязное чтение») – Транзакция T2 изменяет (или вводит) элементы данных R. Затем, прежде чем T2 выполняет COMMIT, начинается Транзакция T1, считывает элементы данных R и способна получить состояние элементов данных таким, каким оно стало послед изменения T2. В дальнейшем, T2 может выполнить операцию ROLLBACK.
Примечание: T1 может выполнить дополнительные операции базы данных, основанные на состоянии элементов данных R, которое было откачено и считается никогда не существовавшим, создавая потенциальную проблему последовательности данных.
  •  P2 («Неповторяемое чтение») – Транзакция T1 осуществляет чтение элементов данных R. Затем, перед выполнением COMMIT Транзакцией Т1, начинается Транзакция T2, которая изменяет (или удаляет) элементы данных R и выполняет COMMIT. Затем T1 повторяет чтение элементов данных R и может получить состояние элементов данных после изменения Транзакцией T2.
Примечание: Перед обнаружением измененного (или удаленного) состояния элементов данных R T1 могла выполнить дополнительные операции базы данных, основанные на состоянии элементов данных R, которые более не считаются корректными, создавая потенциальную проблему последовательности данных.
  •  P3 («Фантомное чтение») - Транзакция T1 осуществляет чтение набора элементов данных, которые соответствуют некому <критерию поиска>. Далее, перед тем, как Транзакция T1 выполнит операцию COMMIT, начинается Транзакция T2, которая вносит или удаляет один или более элементов данных, соответствующих <критерию поиска>, используемому T1. Затем 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.

Используя четыре Сессии от S1 до S4, в соответствующем порядке выполняются следующие этапы:

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 было откачено.
Прецедент B, в случае, если S4 завершается (возможно, после остановки) и S3 откатывается:
6B. Проверьте, что S4 завершает выполнение Фрейма 2 и оставшихся Фреймов.
7B. Проверьте, что S3 была откачена.
Прецедент C, если S4 останавливается во Фрейме 1 (некорректно):
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 Множественные экземпляры Операционной системы

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.

Пример: Если Избыточность Уровня 1 достигнута путем реализации защиты RAID-5 в дисковом , то Избыточность Уровня 2 будет тестироваться при помощи сбоя в оборудовании, используемом для реализации защиты RAID-5.

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

Если контроллер, реализующий RAID-5 располагается отдельно от enclosure, содержающего диски, и контроллер не используется в качестве Постоянного носителя (например, зеркалированный кэш записей), то является достаточным оборвать соединения между контроллером и дисковой конструкцией.

  • Избыточность Уровня 3 (Полная избыточность): Включает Избыточность Уровня 2 и гарантирует доступ к данным на Постоянных носителях, когда происходит одиночный сбой в системе Постоянных носителей, включая связи между Уровнем B и системой Постоянных носителей.
Примечание 1: система Постоянных носителей содержит в себе все компоненты необходимые для соблюдения требований устойчивости, описанных выше. Сюда не входит система Уровня В или системная шина, но входит адаптер на системной шине и все компоненты, располагающиеся «ниже» адаптера.

Примечание 2: задачей данного пункта является протестировать способности системы Уровня В выдерживать сбои ее компонент и продолжать обработку Транзакций.

Примечание: компоненты, тестируемые в этом пункте, считаются быстро заменяемыми модулями. Задачей этого пункта не является поставить Организатору задачу протестировать устойчивость соединительной платы в хранилище Постоянных носителей или подобных незаменяемых компонент. В то же время в задачи тестирования входит проверка свойств устойчивости ко сбоям контроллеров хранилищ, включая зеркалированный кэш на контроллере, и соответствующее программное обеспечение.

7.5.5.5 Процедура тестирования Устойчивости в целях Доступности данных

1. Определите текущее количество завершенных торгов в базе данных, выполнив запрос:
select count(*) as count1 from SETTLEMENT
 

2. Начните отправлять на обработку Транзакции и наращивать производительность до уровня Требований оценки Устойчивости (как описано в пункте 7.5.3) и придерживайтесь на этом уровне по меньшей мере 5 минут.

Примечание: Как только Требования оценки Устойчивости будут соблюдены:

  •  запрещены любые изменения в конфигурации Драйвера до завершения этапа 5
  •  запрещены любые изменения в конфигурации SUT за исключением тех, которые необходимы для выполнения этапов 3 и 4.
3. Выполните сбой, необходимый для проверки демонстрируемого уровня избыточности.

4. Начните необходимые процедуры восстановления.

5. Продолжайте работу Драйвера в течение 20 минут.

6. Корректно завершите выполнение из Драйвера.

7. Получите новое количество завершенных торгов в базе данных, выполнив:

select count(*) as count2 from SETTLEMENT

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
  •  Должна использоваться размерность масштаба графика, равная 1 минуте.
Примечание: целью является демонстрация влияния процедуры восстановления на производительность.

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, в случае, если между окончанием Восстановления базы данных и началом Восстановления приложения наличествует любой промежуток времени, этот промежуток должен быть проигнорирован и два этих периода должны быть отображены на графике примыкающими друг к другу.