1. Шубинский И.Б. Функциональная надежность информационных систем. Методы анализа. - Ульяновск: Областная типография «Печатный двор», 2012. 296 с., ил.
2. Технический отчет ISO/IEC TR 19760. Первое издание 2003-11-15 Проектирование систем - Руководство по применению ISO/IEC TR 15288 (Процессы жизненного цикла системы).
3. ГОСТ 24.701-86. Надежность автоматизированных систем управления. Основные положения.
4. Avizienis A., Laprie J-C. and Ranbell B. Dependability of computer systems / Fundamental concepts, terminology and examples. Technical report, LAAS-CNRS, October. 2000.
5. Rus I., Komi-Servio S., Costa P. Computer program with insurance of high reliability. Technical report, IFIP WG-10.4, 2008. March.
On the functional reliability of information systems
Garanin Alexzander I., candidate of technical Sciences, senior scientist
Federal Research Center «Computer and Control» of the Russian Academy of Sciences (FRC CSC RAS)
The article describes a number of approaches to the definition of "reliability", considered in contrast to the "structural reliability, considered the concept of functional failure.
Keywords: functional reliability, structural reliability, infallibility, functional failure
УДК 681.3.068
МОДЕЛИРОВАНИЕ СТРАТЕГИ РЕШЕНИЯ ПРОБЛЕМЫ ТУПИКОВОЙ СИТУАЦИИ В БАЗАХ ДАННЫХ
Вера Львовна Волушкова, канд. техн. наук, доц.
E-mail: [email protected] Тверской государственный университет http://university. tversu.ru
Выбор стратегии контроля конкуренций является важной задачей для интенсивных нагрузок баз данных. Традиционно проблема контроля конкуренций решается с помощью блокировок, которые неизбежно ведут к взаимоблокировкам, т.е. тупиковым ситуациям. Существует много алгоритмов для борьбы с взаимоблокировками. В данной работе представлена модель для анализа эффективности стратегий основанных на определении тупиков, стратегий, основанных на предотвращении тупиковых ситуаций и стратегий, основанных на тайм-аутах.
Ключевые слова: базы данных, взаимные блокировки, транзакция, моделирование.
Протоколы контроля конкуренций обеспечивают параллельное выполнение взаимовлияющих транзакций при сохранении целостности данных. Среди всех протоколов контроля конкуренций в системе моделирования выбран протокол
двухфазной блокировки, как наиболее часто используемый [1,3]. Протокол двухфазной блокировки заключается в следующем. Первая фаза - установление блокировок без их освобождения. Вторая фаза - освобождение блокировок. В этой фазе не могут выполняться дополнительные блокировки. Есть несколько схем осуществления такого протокола, которые гарантируют разную надежность и реактивность системы. Как правило, требования надежности и реактивности протоколов противоречат друг другу.
Тупики часто определяются с помощью графов ожидания Волушкова в.л. [4, 5]. В контексте базы данных граф ожиданий G является ориентированным графом, где каждая вершина представляет собой транзакцию; каждое ребро Ti -> T G G означает, что транзакция Ti ждет транзакции Tj (например, поскольку
7], владеет блокировкой, которую хочет 71). Было показано, что существует тупик тогда и только тогда, когда существует цикл в графе ожиданий [4, 5].
Стратегии разрешения взаимоблокировок можно разделить на три класса. Такое разделение возможно по принципу: требуется ли стратегиям явное обслуживание графа ожидания и можно ли для целей разрешения взаимоблокировок перезапустить транзакцию, которая не включена в тупик. Этими классами являются - стратегии устранения взаимоблокировок, стратегии предотвращения блокировок и стратегия тайм-аута.
Стратегии обнаружения тупика делятся на непрерывное обнаружение циклов в графе ожиданий и периодическое обнаружение циклов. При непрерывном обнаружении граф ожиданий всегда хранится без циклов, т.к. обнаруживает циклы на протяжении всего времени блокировки транзакции. При периодическом обнаружении граф ожидания периодически просматривается для обнаружения циклов, и находятся все связанные компоненты графа. Проблемой является выбор подходящего временного интервала для периодического обнаружения тупиков. В работе изучается влияние разных временных интервалов на эффективность обнаружения тупиковых ситуаций.
При выполнении стратегии обнаружения тупика возникает задача выбора транзакции для перезапуска. В работе рассмотрено 5 способов:
1) выбирается транзакция, которая только что привела к тупику (это возможно при непрерывном обнаружении).
2) выбирается случайная транзакция среди участников цикла взаимоблокировки.
3) выбирается транзакция, в которой выполняется меньше блокировок.
4) выбирается транзакция с самым последним начальным временем запуска (т.е. та, которая начала работу совсем недавно).
5) выбирается транзакция, которая потребляет наименьшее количество физических ресурсов (записей БД) с момента ее начала.
При выполнении стратегии предотвращении тупиковой ситуации неявно поддерживается граф ожиданий. Тупики предотвращаются тем, что никогда не разрешаются блокировки, которые могут привести к тупику. Рассматриваются два алгоритма предотвращения блокировки.
Если запрос блокировки от транзакции 7 приводит к конфликту с другой транзакцией 7/, разрешите конфликт следующим образом:
1) Если 7 начала работать до 7/, то рестарт 7], в противном случае блокируйте 7и
Тупики не могут произойти, так как все транзакции могут быть блокированы
только более старой транзакцией, и поэтому в графе ожиданий не могут формироваться циклы.
2) Если 7 запущена раньше 7], тогда заблокируйте 7], в противном случае перезапустите 7. Опять же, взаимоблокировки невозможны, поскольку транзакция может быть заблокирована только младшей транзакцией.
Обратите внимание на то, что при предотвращении тупиковой ситуации возобновленное действие не обязательно связано с фактическим циклом взаимоблокировки. Таким образом, политика предотвращения блокировок носит консервативный характер, т.к. требует больше рестартов с целью предотвращения возможных взаимоблокировок.
При выполнении стратегии тайм-аута для обработки взаимозависимых транзакций транзакция, запрос блокировки которой не может быть предоставлен, просто помещается в очередь на блокировку. Транзакция позже перезапускается, если ее время ожидания превышает некоторое пороговое значение. Таким образом, при этой стратегии могут перезапускаться некоторые транзакции, которые не задействованы ни в одном цикле.
Модель системы управления транзакциями построена на основе Е-сетей (модифицированных сетей Петри). Модель состоит из генератора транзакций,
контроллера транзакций и контроллера блокировок. Генератор транзакций формирует транзакции как множество операций чтения записи i-го данного. Предполагается, что ни одна транзакция не читает и не пишет одну запись БД более одного раза и представляется в виде набора операций READi(x) и WRITEi(x), обозначаемых Ri(x) и Wi(x). Любая транзакция может прекратить свое существование двумя способами: либо завершиться благополучно, т.е. зафиксироваться (COMMIT), либо завершиться аварийно, вследствие чего может возникнуть необходимость отката транзакции (ABORT). Контроллер транзакций управляет выполнением нескольких транзакций. Контроллер блокировок осуществляет строгую двухфазную блокировку и стратегии борьбы с тупиками, которые описаны выше.
Модель координатора транзакций представлена на рис. 1.
Рис.1 Модель координатора транзакций
Получив сообщение «начало транзакции» координатор транзакций выбирает первое данное для обработки и переходит в состояние чтение/запись очередного данного. Если в этой фазе наступает событие «откат транзакции», то контроллер освобождает все блокировки данной транзакции.
Для осуществления доступа к данному необходимо послать требование на блокировку этого данного к контроллеру блокировок. Если блокировка возможна, т.е. получено сообщение «подтверждение блокировки», то разрешено манипулирование этим данным. Если все данные обработаны, то наступает состояние «конец транзакции» и транзакция попадает в состояние «ожидание фиксации». Сообщение «зафиксироваться» приводит модель в состояние «запись в БД» и «снятие блокировок».
Рассмотрим модель контроллера блокировок рис. 2. Если метки блокировки данного по чтению (Я) и по записи (Ж) пусты, то контроллер блокировок данного разрешает доступ к данному и помещает в соответствующую метку сведения о блокирующей транзакции. В выходную позицию записывается разрешение на блокировку. Если метки блокировки данного не пусты, то анализируется, не является ли требование на блокировку конфликтным. Контроллер блокировок строит граф ожидания и, если в нем есть цикл, решает какую транзакцию откатить по правилам, изложенным выше. Требование отката записывается в выходную позицию.
Приведем результаты экспериментов. Количество данных при рассмотрении коллективного доступа было не очень большим - порядка 2000 записей, т. к. при большем числе данных конфликты очень редки. Размер транзакций в среднем 10 операций чтения и 15 записи данных. Общее число транзакций в системе от 100 до 200.
Рис.2 Модель контроллера блокировок.
Наш первый эксперимент изучил эффективность альтернативных критериев выбора откатываемой транзакции при непрерывном обнаружения тупиков.
При небольшой нагрузке все критерии выбора откатываемой транзакции работают эффективно. Однако по мере увеличения количества транзакций в системе выбор откатываемой транзакции по критерию 1 и критерию 2 начинают тормозить время выполнения транзакции. Критерии 3, 4 и 5, которые пытаются перезапустить наименее дорогостоящую транзакцию, начинают обеспечивать лучшую производительность по мере увеличения уровня параллелизма.
Также выяснилось, что можно сформулировать два свойства стабильности для стратегий устранения взаимоблокировок. Первое заключается в том, что в любой момент времени существует некоторая транзакция в системе, которая гарантировано не перезапускается, и второе - транзакции нельзя перезапускать много раз, т.е. предпочтительнее транзакции без повторных перезапусков.
Хотя эти свойства не гарантируют высокий параллелизм, отсутствие этих свойств может привести к тому, что система станет нестабильной в ситуациях с высоким уровнем конфликтов. Среди критериев выбора откатываемой транзакции, которые были рассмотрены, первый и второй критерии не обладают этими двумя свойствами, критерий 4 имеет оба этих свойства, а критерии 3 и 5 имеют приблизительно эти свойства стабильности. Было установлено, что 3 критерий лучше других критериев, потому что, если транзакция, которая удерживает большое количество блокировок, перезапускается, она снова должна бороться за все блокировки, увеличивая вероятность блокировки и перезапуска.
При выполнении стратегии предотвращении тупиковой ситуации алгоритм 1 имеет оба требуемых свойства стабильности. Алгоритм 2 имеет повторные перезагрузки, поэтому алгоритм 1 строго превосходит второй алгоритм.
В нашем исследовании подчеркивается сложность выбора подходящего интервала тайм-аута для стратегии тайм-аута. Было продемонстрировано, что производительность тайм-аута чувствительна к интервалу и что «правильный» тайм-аут зависит от уровня параллелизма и от характеристик рабочей нагрузки транзакции. Проводились эксперименты с адаптивной версией стратегии тайм-аута и со стратегией
простого тайм-аута с фиксированным интервалом. По результатам экспериментов можно сказать, что тайм-аут проигрывает первым двум стратегиям.
Предложенная модель параллельного выполнения транзакций позволяет оценить различные стратегии преодоления тупиковых ситуаций. Было бы полезно проверить нашу имитационную модель, повторив эксперименты в реальной системе баз данных. Такая модель может быть использована для демонстрации обучающимся механизмов поддержки параллелизма в базах данных.
Автор считает, что в данной работе новыми являются следующие положения и результаты:
1. Модель системы управления транзакциями, построенная на Е-сетях;
2. Выделение свойств стабильности для стратегий устранения взаимоблокировок;
3. Программный продукт, который позволяет осуществить моделирование параллельного выполнения транзакций.
Литература
1. Abdullah Mohammed Rashidl. Deadlock Detection and Resolution in Distributed Database // International Journal of Scientific and Research Publications, 2015. September. V. 5. Issue 9.
2. Kumar V. Performance comparison of database concurrency control mechanisms based on two-phase locking, timestamping and mixed approach // Information Sciences. V. 51. Issue 3. 1990. August. Pages 221-261
3. Saad M. Darwish, Adel A. El-Zoghabi and Marwan H. Hassan. Soft Computing for Database Deadlock Resolution // International Journal of Modeling and Optimization, Vol. 5, No. 1, February 2015
4. Holt R.C. Some deadlock properties of computer systems, ACM Computing Surveys, 1972. Sept. V. 4. N. 3. pp. 179-196.
5. Bernstein P.A., Hadzilacos V., Goodman N. Concurrency control and recovery in database systems. - Addison-Westley publishing company, 1987. 370 p.
The model of database concurrency control strategy
Vera Volushkova, Ph. D., associate Professor, Tver state University
The choice of concurrency control strategy is an important task for intensive loadings of databases. Traditionally the problem of concurrency control strategy is solved with the help of blocking which inevitably lead to deadlocks. There are many algorithms for fight against deadlocks. In this work the model for the analysis of efficiency of strategy of the deadlocks detection, strategy based on deadlocks prevention and strategy based on timeouts is presented. Keywords: database; concurrency control; deadlock; modeling; transaction processing.
УДК 658.314.7:330.115
СТРУКТУРА АВТОМАТИЗИРОВАННОГО КАТАЛОГА УСЛУГ
Владимир Алексеевич Бородин, чл.-кор. РАН, генеральный директор
E-mail: [email protected] Экспериментальный завод научного приборостроения РАН
www ezan.ru
Сергей Александрович Савушкин, канд. физ.-мат. наук, ст. науч. сотр., вед. науч.
сотр.
E-mail: [email protected] Алеся Валерьевна Лемешкова, мл. науч. сотр. E-mail: [email protected] Институт проблем транспорта им. Н. С. Соломенко РАН
www iptran.ru