VI. Надежность системы

A. Системный журнал

Основой надежности работы СУБД ЛИНТЕР с данными является системный журнал или журнал транзакций. В файле журнала отображаются все изменения, производимые над данными всеми пользователями системы.

Переход к многоверсионности данных, позволил “накрыть” все уровни изолированности, описанные в стандарте SQL92 Entry - Entry Level спецификация Международной Организации по Стандартизации (ISO) 9075-1992 языка баз данных SQL или сокращённо SQL92E.

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

При исправлении последних изменений СУБД может столкнуться с тем, что часть из них достигла дискового пространства файлов полностью, некоторые изменения лишь частично записались на диск, а некоторые так и остались в буферах ядра системы, не затронув собственно файлы базы данных.

Итак, ЛИНТЕР при исправлении неполных/неверных данных может либо вернуть их в то состояние, в котором они находились до изменений (откат изменений), либо продолжить модификацию данных, следуя журналу транзакций (прокрутка вперёд).

При этом работает следующее простое правило: если пользователь получил “уведомление” о том, что его изменения перенесены в базу, то при следующем запуске системы новые данные обязаны находиться в базе.

1. Режимы транзакций СУБД ЛИНТЕР

В ЛИНТЕР реализованы три основных стратегии (или режима) работы транзакций.
• Оптимистичная (Optimistic Concurrency Control).

Модификации данных, сделанные внутри одной транзакции, не поступают в базу, однако, поступают в системный журнал вместе со старым образом данных. При фиксации изменений транзакции система начинает перенос изменений из журнала в базу данных.

При переносе очередного изменения ЛИНТЕР сравнивает старый образ модифицируемых данных из журнала и из базы. Если образы совпадают (данные никто не менял), то это очередное изменение попадает в базу, в противном случае (кто-то уже успел раньше изменить и зафиксировать данные) откатывается вся транзакция, а приложению возвращается соответствующее сообщение.

Этот режим работы транзакций при всех его недостатках обладает существенным достоинством - скоростью. Данные не блокируются, каждая задача работает исходя из оптимистичного предположения о том, что кроме неё с базой не работает никто, и никто никого не ждёт. А при возникшей коллизии транзакцию можно и повторить. Что очень удобно особенно в системах массового обслуживания.

• Пессимистичная (Pessimistic).

Это классический режим работы транзакций. Все изменения поступают сразу в базу данных, а также в системный журнал. Однако эти изменения не видны другим транзакциям до тех пор, пока не пройдет её фиксация. До тех пор работает аппарат блокировок, запрещающий модификацию читаемых или чтение модифицируемых данных.

• Стратегия read-only.

Удобный режим транзакций, которые не делают никаких изменений в базе данных, их функция – только чтение (например, отчёты за день, сведение данных для анализа и т.п.). Обычно такие транзакции вовлекают в свою работу большие объёмы данных, так что блокировка всех используемых данных может привести к длительной задержке прочих транзакций.

В ЛИНТЕР транзакция read-only не блокирует данные. Но при её появлении, все другие транзакции, изменяя данные, оставляют (для неё и ей подобных) тот образ, который имели данные, когда транзакция read-only стартовала.

Таким образом, транзакция read-only получает базу данных именно на момент её старта, то есть как бы моментальный «снимок» базы данных.

В ЛИНТЕР 6.1 реализовано четыре уровня изоляции транзакций: READ UNCOMMITTED(1), READ COMMITTED(2), SERIALIZABLE(3), OPTIMISTIC(4) (OPTIMISTIC оставлен для совместимости с предыдущими версиями СУБД). Следует отметить, что в отличие от предыдущих версий, выборка стабильна при любых уровнях изолированности транзакций.

READ_UNCOMMITTED

При работе в этом режиме транзакция видит все свои изменения и изменения, сделанные транзакциями уровней 1-3 (фиксированные и нефиксированные). Транзакция не видит нефиксированных изменений, внесенных OPTIMISTIC транзакцией. Выборка стабильна.

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

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

При попытке сделать ссылку на нефиксированные данные (FK) запрос будет ждать завершения конкурирующей транзакции или завершится ошибкой.

READ_COMMITTED

Транзакция видит все свои изменения и фиксированные изменения, сделанные транзакциями уровней 1-4. Выборка стабильна.

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

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

SERIALIZABLE

Транзакция видит все свои изменения и фиксированные изменения, сделанные транзакциями уровней 1-4, которые завершились до ее старта. Выборка стабильна.

Транзакция не может менять данные, измененные и не фиксированные другими транзакциями. При попытке сделать это запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение об ошибке.

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

При попытке модифицировать данные, которые были модифицированы (удалены), причем эти изменения были фиксированы после ее старта, запрос завершится ошибкой НЕСЕРИЙНЫЙ ДОСТУП К ДАННЫМ (8102).

Одновременно может существовать ограниченное число соединений с режимом SERIALIZABLE (100). Попытка создать большее число соединений с режимом SERIALIZABLE приведет к сообщению об ошибке "НЕТ СВОБОДНОЙ ТОЧКИ ВХОДА В ТАБЛИЦЕ СЕРИЙНЫХ ТРАНЗАКЦИЙ (8107)".

2. Иерархия транзакций в СУБД ЛИНТЕР

В СУБД ЛИНТЕР каждое приложение может использовать как обычные плоские транзакции, так и иерархические.

Классические плоские транзакции представляют собой последовательность запросов, завершающуюся оператором фиксации/отката Commit/Rollback. Причём необходимость отката транзакции может возникнуть и в середине транзакции. При этом из базы данных будет удалены все изменения, которые успела сделать транзакция. Приложение не может откатить лишь отдельные изменения, ему разрешено руководствоваться только одним принципом - “или всё, или ничего”.

Несомненно, это слишком категоричный и, следовательно, не всегда приемлемый принцип. Особенно в системах с нечёткой логикой.

Например, приложению (см. следующий рисунок) нужно произвести три действия A, B и D в одной транзакции. Причём действия A и D являются необходимыми, а вот для действия B есть “запасной вариант” - действие C. Так что приложение после выполнения действия А пытается в первую очередь выполнить действие B, и только если по какой-либо причине результаты отработки B “не устраивают” или возникла ошибка, то изменения, сделанные B, откатываются, и приложение предпринимает резервное действие C.

Такую логику транзакции не удастся реализовать при помощи линейных транзакций. Для использования подобных транзакций СУБД ЛИНТЕР предоставляет пользователю возможность иерархии транзакций.

При этом действуют следующие правила.
1. Подчинённые (вложенные) транзакции действуют по линейному принципу. И могут работают независимо друг от друга в любом из режимов (от оптимистичного до read-only).
2. Каждая из подчинённых транзакций может быть фиксирована/откачена независимо от других подчинённых транзакций.
3. Подчинённые транзакции “видят” изменения, сделанные прочими подчинёнными транзакциями (имеющими общего предка). Полностью изолированы только транзакции различных иерархий.
4. Фиксация/откат головной транзакции приведёт к фиксации/откату всех подчинённых транзакций.

Подобный подход к системе использования транзакций гораздо более гибкий.

Кроме того, в СУБД ЛИНТЕР дополнительно введён аппарат контрольных точек (SAVE POINTS). При помощи этого аппарата можно будет откатить все изменения (даже фиксированные) до указанной контрольной точки.

B. Архивирование таблиц (базы данных)

Утилита архивирования ЛИНТЕР - lhb позволяет сохранять (со сжатием) базы данных целиком/выборочно.

При этом, работа lhb не останавливает работу других пользователей СУБД. lhb делает просто “сжатый снимок” базы данных на какой-то момент времени.

Таким образом, поврежденная база данных может быть всегда восстановлена из последнего lhb-архива.

lhb - мощная программа, обладающая возможностями, которые облегчат пользователю организацию необходимого алгоритма архивирования.

Здесь искушенный пользователь обнаружит следующие возможности:
• ведение архива (системы архивов) на магнитной ленте;
• нарастающее (инкрементное) архивирование;
• установка системы и расписания (графика) архивирования базы данных;
• развитая система реакций на временные события;
• возможность написания скриптов на языке архиватора BSL (Backup Script Language);
• мощная система для селекции архивируемых объектов базы данных;
• тестирование архива;
• шифрация данных архива и авторизация доступа к нему.

Особый интерес, конечно же, представляет определение графика или сценария архивирования с помощью языка BSL, наиболее важными возможностями которого являются:
• отслеживание интервалов времени для запуска lhb или других программ в нужный момент,
• достаточно развитая система управления работы программы (операторы типа if, else, while, …),
• система обработки ошибок, возникающих при запуске программ,
• функции для управления файлами (копирование, перенос, удаление и пр.),
• набор операций со строковыми переменными.

Сам сценарий или график на языке BSL составляет пользователь (с правами администратора). Здесь могут быть указаны периодичность и порядок автоматических действий архиватора, например:
• архивирование базы данных;
• создание резервных копий;
• перенос архива или резервных копий на другие носители данных (в том числе и на магнитную ленту);
• удаление устаревших архивов и их копий.

Файл сценария может содержать определение периодичности действий (ежедневно + время, еженедельно + день недели + время, ежемесячно + число месяца + время), а также особенные даты, выходящие за пределы периодичности (когда требуется или, наоборот, исключено действие). Например:

Variables:
NUM = 1;
Rights:
Everyday ( time = ‘12:00’ )	{
  if ( CWEEKDAY() == “Sun” ) { 	
/* New archive on Sunday */ 
    move (FILENAME + TOSTR(NUM) + “.lhb” , “c:\arc” );
    NUM =NUM +1;
    backup ( “s –u “ +NAME +”/” +PASSWORD + “ –f “ 
	+FILENAME +TOSTR(NUM) +”.lhb –startinc” );
    }		
  else				/* Incremental backup */
    backup ( “s –u “ + NAME + ”/” + PASSWORD +“ –f “ 
	+ FILENAME + TOSTR(NUM) + ”.lhb –inc” );
  Exception: /* for ‘everyday’ */
  print(“Error=”   +TOSTR(СERROR) +“ , LinError=” 
  +TOSTR(LINERROR) +“ , SysError=” +TOSTR(SYSERROR) );
  stop;
  }
Special:
before	{			/* just after the start */
  print ( “Start backup system” );
  backup(“s –u “ + NAME + ”/” + PASSWORD +“ –f “ 
  + FILENAME + TOSTR(NUM) + ”.lhb –startinc” );
  }
after	{			/* after ‘stop’ or Ctrl-C */
  print ( “Stop backup system” );
  if ( ERROR != 0 ) logprint ( “Error present: “ 
  + TOSTR(ERROR) );
  }
iferr 	{			/* global */
  print(“Error =” + TOSTR(СERROR) +“ , LinError=” 
  +TOSTR(LINERROR) +“ , SysError=” +TOSTR(SYSERROR) );
  stop;
  }

C. Горячее резервирование

Подсистема горячего резервирования ЛИНТЕР предназначена для повышения надежности информационных систем за счет полного дублирования процесса ведения базы данных на резервном сервере базы данных.

В момент аварии одного из задублированных серверов процесс взаимодействия с базой данных переключается на второй. Горячее резервирование означает, что выход из строя одного из дублирующих серверов не будет замечен прикладными процессами, имеющими выполняющиеся запросы к базе данных, и не повлияет на результаты последующих запросов.

Процесс резервирования “прозрачен” для приложений, так как способ их доступа к базе не зависит от того, выполняется оно или нет.

Подсистема резервирования реализована в виде двух процессов. Один из них работает на узлах процессов клиентов, другой - на каждом из задублированных серверов.

Переход системы из дублирующего режима в монопольный происходит в следующих случаях:
• сервер базы данных был остановлен оператором;
• один из серверов базы данных выключился или “завис”;
• на одном из серверов базы данных произошла неисправимая системная ошибка;
• "главный" сервер базы данных обнаружил несовпадение результатов обработки запросов с резервным сервером.

Более того, система ЛИНТЕР позволит “поднять” упавший сервер, не останавливая работу всей системы. После старта резервный сервер «догонит» уже находящийся в работе, и только после этого, система снова перейдёт в режим горячего резервирования.

D. Testdb - утилита проверки физических структур базы

Утилита Testdb поможет администратору обнаружить возможные ошибки, появившиеся в базе данных в процессе работы системы.

Testdb может работать как со всей базой данных, так и выборочно обследовать указанные таблицы. При этом может быть указана ещё и глубина, а также сложность проверок базы.

Если были диагностированы ошибки, то Testdb попытается их исправить собственными силами или предложит пользователю “лечащий” пакет SQL запросов.

На данный момент Testdb – программа, которая может работать с базой только монопольно. Никакой другой процесс не может работать с файлами базы данных одновременно с ней, в том числе и ядро СУБД.

Однако зачастую требуется проверка (и, может быть, “лечение”) базы данных как раз во время работы системы (например, в непрерывных производствах). Для этого в систему введён аппарат “горячего” тестирования таблицы. Таким образом, любое приложение может подать SQL запрос на тестирование таблицы и получить информацию об ошибках, которые необходимо исправить. Тестирование может иметь самый низший приоритет и, следовательно, выполняться в фоновом режиме, т.е. только тогда, когда нет других, более приоритетных запросов.