Способ восстановления данных в системе управления базами данных

Способ восстановления данных в системе управления базами данных

Иллюстрации

Показать все

Реферат

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

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

Транзакция - это групповая операция, т.е. набор действий с БД, самым существенным для этих действий является правило: либо все, либо ничего. Если во время выполнения данного набора действий, на каком-то этапе невозможно произвести очередное действие, то нужно выполнить возврат БД к начальному состоянию (произвести откат транзакции). Таким образом, при правильном планировании транзакций обеспечивается логическая и физическая целостность БД ([1] Управление транзакциями - сайт - форум (http://citforum.ru/programming/32less/les310.shtml).

Рестарт - это перезагрузка СУБД после программного или аппаратного сбоя, процесс, при котором СУБД восстанавливает последнее перед сбоем согласованное состояние БД и возобновляет свою работу заново.

На восстановление данных в СУБД направлено известное техническое решение - изобретение по патенту [2] US 5,966,706 «Local logging in a distributed database management computer system», Int. Cl. G06F 11/14, в котором распределенная база данных компьютерной системы управления включает в себя множество узлов и множество страниц базы данных. Когда первый узел в компьютерной системе обновляет первую страницу базы данных, первый узел генерирует запись в журнале. Первый узел определяет, будет ли он управлять первой страницей базы данных. Если первый узел определяет, что он управляет первой страницей базы данных, первый узел пишет запись в журнале хранения на первый узел. Однако, если первый узел определяет, что он не успевает управлять первой страницей базы данных, первый узел определяет, включает ли в себя локальное хранение журнала. Если первый узел включает в себя локальное хранение журнала, первый узел пишет запись в локальное хранение журналов, даже если ему не удается управлять первой страницей базы данных. Если первый узел не включают запись в локальное хранение журнала, первый узел отправляет запись в журнал на второй узел управления первой страницей базы данных.

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

Наиболее близким техническим решением (прототипом) к заявляемому изобретению является изобретение по патенту [3] US 6,173,292 «Data recovery in a transactional database using write-ahead logging and file caching», Int. Cl.: G06F 11/14 (2006.01.); G06F 012/00, которое описывает способ и систему восстановления данных в транзакционной БД с помощью упреждающей регистрации и кэширования файлов. СУБД управляет одной или несколькими БД, в каждой из которых содержится один или несколько объектов. СУБД поддерживает кэш-файл для этих БД. Система управления транзакциями записывает транзакции в одну или несколько записей, хранящихся в файле журнала, каждой из записи присваивается уникальный номер транзакции в журнале (LSN), LSN выбирается из состава группы (groupcomprised) из (1) страницы (PageLSN), которая идентифицирует версию объекта, (2) запись (RecLSN), которая идентифицирует восстановление версии объекта, (3) минимальная запись (MinRecLSN), которая является минимальным значением всех записей RecLSNs из буферного пула общих объектов памяти и грязном столе объектов, (4) кэш (FCacheLSN) является минимальным значением для записей RecLSNs всех объектов, которые, как предполагается, находятся в файле кэша, и (5) переделать (ReDoLSN), который идентифицирует запись RecLSN в лог-файл, где перезагрузка восстановления БД должна начаться.

Несмотря на то, что способ-прототип по патенту [3] US 6,173,292 является на данный момент наиболее прогрессивным по сравнению с другими техническими решениями в известном уровне техники для восстановления данных в СУБД, ему присущ ряд существенных недостатков, а именно:

во-первых, прототип использует громоздкую структуру БД, где каждая БД представляет собой отдельный файл, использует сложный алгоритм ведения журнала транзакций с большим количеством вычисляемых LSNS: PageLSNs, RecLSNs, TempFCacheLSNs, ReDoLSNs;

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

Все эти недостатки существенно снижают эффективность восстановления данных в БД СУБД после сбоя.

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

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

Поставленная техническая задача решается заявляемым способом восстановления данных в системе управления базами данных - СУБД, при котором:

базы данных - БД сформированы в виде реляционных таблиц, каждая из которых описывается метаданными и содержит данные, сформированные в строки одинаковой структуры, где каждая строка идентифицирована уникальным номером и представлена набором полей с заданными типами данных, а совокупность значений одного и того же поля в разных строках образует столбец значений данных, каждый из которых имеет свой тип данных;

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

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

отличающимся согласно изобретению тем, что

формируют журнал, единый для транзакций и рестарта, состоящий из определяемого пользователем числа файлов журнала заданного размера, содержащий множество журнальных записей различного типа, среди которых формируют в том числе записи, каждая из которых описывает redo-обновление только на одной странице одной из таблиц БД и предназначена для доката обновления в БД, которое не было записано во внешнюю память;

в структуру записи redo-обновления включают:

поле TSN - time sequence number - синтетическое время СУБД, представляющее уникальную последовательно возрастающую числовую комбинацию,

обновление и его длину,

адрес обновления - номер страницы файла таблицы и смещение в ней,

поле обратной ссылки - журнальный адрес предыдущей записи транзакции для выполнения откатов транзакций, причем значение поля ссылки содержит номер файла журнала и смещение в нем;

при рестарте накатывают на физическом уровне все зарегистрированные в журнале обновления, которые не попали в БД, после чего выполняют откаты всех незавершенных транзакций на логическом уровне, при этом рестарт выполняют в три прохода:

первый - аналитический проход, в котором определяют адрес последней, предназначенной к накату, журнальной записи и адрес размещения служебной записи слежения, оценивают состояние тех страниц БД, которые предназначены к накату пропущенных обновлений, и информацию о которых извлекают при проходе по журналу из записей, описывающих redo-обновления, и определяют состояние всех транзакций;

второй - redo-проход, при котором выполняют накат пропущенных обновлений и для каждой неоконченной транзакции в записи о ее начале выставляют соответствующий признак;

третий - undo-проход, при котором выполняют откат всех незавершенных транзакций, которые не были закоммичены или не до конца осуществили откат;

причем в аналитическом проходе:

заполняют массив состояний транзакций, хранимый в оперативной памяти и логически состоящий из поля идентификатора ID транзакции и поля битовых флагов, который используют в undo-проходе, при этом поле битовых флагов включает значения:

транзакция не была закоммичена,

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

транзакция представляет собой операцию над метаданными,

транзакция содержит последнюю незаконченную журнальную операцию и требует отката на физическом уровне;

в redo-проходе:

перед записью измененной страницы во внешнюю память БД изменяют во внешней памяти журнала поля TSN всех redo-обновлений, касающихся измененной страницы,

используют служебную запись слежения, сохраненную в соответствующем файле журнала до начала redo-прохода, для отслеживания адреса и поля TSN текущего накатываемого redo-обновления,

служебную запись и redo-обновления журнала сбрасывают во внешнюю память журнала каждый раз, когда измененные данные БД готовят к записи в БД,

при этом структура служебной записи содержит поля:

cpFlag - флаги состояния рестарта в redo-проходе или undo-проходе,

startTSN - значение синтетического времени СУБД перед первым восстановлением по журналу,

specAddr - адрес в журнале текущей записи redo-обновления, которое будет накатываться в БД,

specTSN - TSN текущей журнальной записи redo-обновления, которое будет накатываться в базу данных;

предназначенные к накату в БД обновления в redo-проходе определяют путем сравнения полей TSN каждой журнальной записи redo-обновления и полей TSN заголовка соответствующей страницы БД, на которой выполняют обновление, при этом

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

в противном случае сравнение полей TSN продолжают с использованием значений полей из служебной записи слежения,

если по результатам сравнения полей TSN выявлено, что обновление необходимо для наката, поле TSN в записи этого обновления в пуле журнала изменяют в соответствии с текущим синтетическим временем СУБД, а само обновление вносят в поле соответствующей страницы БД;

по окончании redo-прохода сохраняют все обновления в БД, накатившиеся к моменту ее старта посредством сброса всех обновленных страниц оперативной памяти во внешнюю память, при этом в служебную запись слежения ставят признак окончания redo-прохода;

обновленное поле TSN записывают и впоследствии используют как основу для сравнения полей TSN в случае повторного восстановления данных в БД из-за возможных отказов СУБД в процессе рестарта, повторное восстановление данных начинают с начала журнала;

если в аналитическом проходе выявлены незакоммиченные транзакции, то они откатываются на логическом уровне в undo-проходе рестарта, при этом redo-журнал сканируют по записям от конца к началу;

все изменения данных в БД, вызываемые откатами, протоколируют в журнале, формируя файлы записей отката в undo-журнале;

поле ссылки в записях отката в undo-журнале, содержащее адрес журнальной записи из redo-журнала, откат которой она описывает, используют для корреляции адресов в читаемом redo-журнале и растущем undo-журнале;

протоколирование откатов в undo-проходе обеспечивают посредством существующего кольца файлов redo-журнала и двух резервных файлов, имеющих размер файла redo-журнала, которые предварительно резервируют;

в начале undo-прохода первый резервный файл переименовывают и включают в кольцо файлов redo-журнала последним файлом, в который переносят служебную запись слежения, выполняют протоколирование откатов незакоммиченных транзакций до тех пор, пока пространство этого резервного файла будет заполнено, включают в кольцо файлов undo-журнала второй резервный файл;

в процессе undo-прохода из массива состояний транзакций последовательно исключают полностью откатившиеся незаконченные транзакции, при этом в undo-журнал каждый раз поступает соответствующая запись об изменении состояния массива транзакций;

в случае повторного рестарта, если отказ системы произошел на стадии undo-прохода, рестарт в три прохода используют только для undo-журнала, при этом массив состояний транзакций предварительно заполняют в ходе просмотра redo-журнала в соответствии с записями, описывающими начало транзакций, и при сканировании в аналитическом проходе корректируют в соответствии с журнальными записями об изменении состояния этого массива, по содержимому поля ссылки в последней записи undo-журнала определяют адрес последней откатившейся записи redo-обновления в redo-журнале; в redo-проходе по undo-журналу все пропущенные откатные обновления накатывают в БД;

используя сканирование файлов записей в redo-журнале от конца к началу, смену номера читаемого файла на предыдущий номер отражают в undo-журнале в содержимом поля ссылки очередной записи, как только очередной файл записей redo-журнала полностью прочитан, содержимое файлов записей undo-журнала, включая последнюю запись, принудительно сбрасывают во внешнюю память, а полностью прочитанный файл записей redo-журнала переименовывают в следующий файл записей кольца файлов undo-журнала, если этого требует наличие транзакций, предназначенных к откату;

когда транзакций, предназначенных к откату, не обнаруживают, все откатные обновления сбрасывают в БД и ставят в запись слежения признак окончания undo-прохода;

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

При этом столбец значений данных и метаданных имеет свой тип данных, например, текстовый или числовой, или тип даты, или BLOB - Binary Large Object, представляющий собой специальный тип данных, предназначенный для хранения изображений, аудио и видео, а также компилированного программного кода.

Журнал формируют, используя протокол ahead logging, при котором журнальные записи, отображающие изменения данных, сохраняют во внешней памяти прежде, чем эти измененные данные будут сохранены в реальной БД.

При сравнении полей TSN с использованием значений полей из служебной записи слежения учитывают расположение текущей записи журнала относительно адреса последней накатившейся в БД записи redo-обновления из служебной записи слежения specAddr, до или после, или точно по этому адресу, при этом для сравнения поля TSN используют поля:

logTSN - TSN текущей журнальной записи redo-обновления,

logPtr - адрес текущей журнальной записи redo-обновления,

dbTSN - TSN из заголовка страницы БД, соответствующей накатываемому redo-обновлению,

startTSN - значение синтетического времени СУБД TSN, отсеченное перед началом самого первого восстановления рестарта,

resTSN - значение синтетического времени СУБД TSN, отсеченное перед началом текущего восстановления рестарта,

specPtr - адрес последней накатившейся в БД записи redo-обновления из служебной записи слежения,

specTSN - TSN последней накатившейся в БД записи redo-обновления из служебной записи слежения.

Таким образом, заявляемый способ восстановления данных в СУБД позволяет после программного или аппаратного сбоя максимально точно восстановить данные в БД до последнего по времени согласованного состояния БД, что достигается за счет того, что:

- формируют единый журнал, состоящий из заданного числа файлов определенного размера, при этом число и размер файлов задаются пользователем, при этом модель журнала может быть использована в процессе рестарта системы без увеличения размера;

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

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

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

Далее описание изобретения поясняется примерами выполнения со ссылкой на чертежи (иллюстрирующие материалы).

На фиг.1 показан пример расположения двумерного массива данных в виде реляционной таблицы.

На фиг.2 в виде структурной схемы показан пример взаимодействия устройств оперативной памяти и внешней памяти для осуществления заявляемого изобретения.

Фиг.3 в общем виде иллюстрирует алгоритм восстановления данных в СУБД согласно заявляемому изобретению, где показано:

1 - текущая redo-запись, предназначенная для переноса в БД;

2 - чтение текущей redo-записи;

3 - перенос текущей redo-записи в соответствующую страницу БД;

4 - перезапись текущей redo-записи с обновленным полем TSN в журнал; инициируется п.6;

5 - запись адреса и обновленного поля TSN текущей redo-записи в запись слежения; инициируется п.6;

6 - запись страницы БД во внешнюю память.

На фиг.4 показана схема сравнения поля TSN в redo-проходе теплого рестарта, где

7 - обновление накатывают в БД;

8 - обновление не накатывают в БД.

Фиг.5 иллюстрирует включение переименованных резервных файлов в кольцо журнала в undo-проходе теплого рестарта.

Фиг.6 иллюстрирует восстановление размеров кольца журнала и количества резервных файлов по окончании undo-прохода теплого рестарта.

Осуществляют изобретение следующим образом.

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

БД сформированы в виде реляционных таблиц, каждая из которых описывается метаданными и содержит данные, сформированные в строки одинаковой структуры, где каждая строка идентифицирована уникальным номером и представлена набором полей с заданными типами данных, а совокупность значений одного и того же поля в разных строках образует столбец значений данных (как показано на фиг.1), каждый из которых имеет свой тип данных: текстовый или числовой, или тип даты, или BLOB - Binary Large Object, представляющий собой специальный тип данных, предназначенный, например, для хранения изображений, аудио и видео, а также компилированного программного кода, и пронумерованы по строкам таким образом, что каждая строка получает уникальный номер.

СУБД в процессе рестарта системы восстанавливают БД, целью восстановления являются:

1) приведение данных в состояние физической и логической непротиворечивости;

2) гарантия сохранности в БД результатов законченных транзакций.

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

На фиг.3 иллюстративно выполнен алгоритм восстановления данных в СУБД согласно заявляемому изобретению, где показано:

1 - текущая redo-запись, предназначенная для переноса в БД;

2 - чтение текущей redo-записи;

3 - перенос текущей redo-записи в соответствующую страницу БД;

4 - перезапись текущей redo-записи с обновленным TSN в журнал; инициируется п.6;

5 - запись адреса и обновленного TSN текущей redo-записи в запись слежения; инициируется п.6;

6 - запись страницы БД во внешнюю память.

Формируют журнал, состоящий из определяемого пользователем числа файлов журнала заданного размера, содержащий множество журнальных записей различного типа, среди которых формируют в том числе записи, каждая из которых описывает redo-обновление только на одной странице одной из таблиц БД и предназначена для доката обновления в БД, которое не было записано во внешнюю память (могло быть потеряно в случае аппаратного или программного сбоя).

В структуру записи redo-обновления включают:

- поле TSN - time sequence number - синтетическое время СУБД, представленное уникальной последовательно возрастающей числовой комбинацией;

- обновление и его длину,

- адрес обновления - номер страницы файла таблицы и смещение в ней,

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

Поддерживаемый протокол журнализации транзакций write-ahead logging [4] (http://en.wikipedia.org/wiki/Write-ahead_logging) или используемый в описании патента [3] US 6,173,292 подразумевает, что записи журнала, отображающие изменения каких-либо данных, должны успешно сохраниться во внешней памяти прежде, чем эти измененные данные начнут сохраняться во внешней памяти БД.

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

Необходим также принудительный сброс журнальных обновлений в файл(ы) по окончании фиксации транзакции.

В период рестарта также поддерживают протокол write-ahead logging: прежде чем пропущенное обновление, накатываемое в страницу БД, сохранится на запоминающем устройстве, соответствующая этому обновлению запись журнала с обновленным полем, TSN должна уже быть сохранена в файле журнала.

При рестарте накатывают сначала на физическом уровне (переносят в БД) все зарегистрированные в журнале обновления, которые не попали в БД. Затем выполняют откаты всех незавершенных транзакций на логическом уровне.

Такой порядок работы имеет принципиальное значение.

Рестарт при этом выполняют в три прохода:

первый - аналитический проход, в котором определяют адрес последней, предназначенной к накату (переносу в БД), журнальной записи и адрес размещения служебной записи слежения, оценивают состояние тех страниц в БД, которые потенциально предназначены к накату пропущенных обновлений (переносу в БД невыполненных обновлений), и информацию о которых извлекают при проходе по журналу из записей, описывающих redo-обновления, и определяют состояние всех транзакций;

второй - redo-проход, при котором выполняют накат пропущенных обновлений (перенос в БД невыполненных обновлений) и для каждой неоконченной транзакции в записи о ее начале выставляют соответствующий признак;

третий - undo-проход, при котором выполняют откат всех незавершенных транзакций, а именно тех, которые не были закоммичены (зафиксированы) или не до конца осуществили откат.

Причем в аналитическом проходе:

заполняют массив состояний транзакций, хранимый в оперативной памяти и логически состоящий из двух полей: поля идентификатора (ID) транзакции и поля битовых флагов;

массив заполняют в аналитическом проходе, а затем используют в undo-проходе;

поле битовых флагов включает следующие значения:

транзакция не была закоммичена,

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

транзакция представляет собой операцию над метаданными,

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

В redo-проходе:

перед записью измененной страницы во внешнюю память БД изменяют во внешней памяти журнала поля TSN всех redo-обновлений, касающихся этой измененной страницы;

используют служебную запись слежения, сохраненную в соответствующем файле в конце журнала до начала redo-прохода, для отслеживания адреса и поля TSN текущего накатываемого redo-обновления; запись слежения имеет небольшую длину и предназначена для отслеживания журнального адреса текущего redo-обновления, предназначенного к переносу в БД;

служебную запись слежения и redo-обновления журнала сбрасывают во внешнюю память журнала (вместе с несохраненными обновлениями в журнале) каждый раз, когда измененные данные БД готовят к записи в БД;

при этом структура служебной записи содержит поля:

cpFlag - флаги состояния рестарта в redo-проходе или undo-проходе (проход аналитический, redo-/undo-проход) и существования/отсутствия контрольной точки, выставленной по окончании redo-прохода (см. ниже);

startTSN - значение синтетического времени СУБД перед первым восстановлением по журналу;

specAddr - адрес в журнале текущей записи redo-обновления, которое будет накатываться в базу данных (предназначено к переносу в БД);

specTSN - TSN текущей журнальной записи redo-обновления, которое будет накатываться в БД (предназначено к переносу в БД).

Предназначенные к накату в БД (переносу в БД) обновления в redo-проходе определяют путем сравнением полей TSN каждой журнальной записи redo-обновления и поля TSN заголовка соответствующей страницы БД, на которой выполняют обновление. При этом, если поле TSN журнальной записи больше поля TSN заголовка страницы, обновление считают необходимым для наката (переноса в страницу). В противном случае сравнение полей TSN продолжают с использованием значений полей из служебной записи слежения.

Алгоритм сравнения в этом случае различается в зависимости от того, расположена ли запись до или после адреса текущей записи specAddr из служебной записи слежения, или точно по этому адресу.

Формула сравнения полей TSN содержит следующие поля:

logTSN - TSN текущей журнальной записи redo-обновления;

logPtr - адрес текущей журнальной записи redo-обновления;

dbTSN - TSN из заголовка страницы БД, соответствующей накатываемому redo-обновлению (переносимому в базу redo-обновлению);

startTSN - значение синтетического времени СУБД TSN, отсеченное перед началом самого первого восстановления рестарта (на начало самого первого восстановления рестарта, - этот TSN необходим, чтобы определить страницы БД, ушедшие во внешнюю память уже в процессе восстановления по журналу);

resTSN - значение синтетического времени СУБД TSN, отсеченное перед началом текущего восстановления рестарта (на начало текущего восстановления рестарта; используется для определения страниц БД, ушедших во внешнюю память в процессе текущего восстановления по журналу, в случае первого восстановления, например, это значение совпадает со startTSN);

specPtr - адрес последней накатившейся в БД записи redo-обновления из служебной записи слежения (перенесенной в страницу БД записи redo-обновления из служебной записи слежения);

specTSN - TSN последней накатившейся в БД записи redo-обновления из служебной записи слежения (перенесенной в страницу БД записи redo-обновления из служебной записи слежения).

Если по результатам сравнения полей TSN выявлено, что обновление необходимо для наката (переноса), поле TSN в записи этого обновления в пуле журнала (оперативной памяти) изменяют в соответствии с текущим синтетическим временем СУБД, а само обновление вносят в поле соответствующей страницы БД.

Обновленное поле TSN впоследствии служит основой для сравнения полей TSN по той же формуле для случая повторного (и т.д.) восстановления из-за возможных прерываний процесса рестарта, например, по причине сбоя оборудования или операционной системы.

Повторное восстановление при этом может начинаться с контрольной точки, выставленной в redo-проходе прерванного рестарта в некоторый момент времени. Под контрольной точкой мы понимаем принудительное сохранение во внешней памяти всех обновлений, уже перенесенных в БД к моменту ее старта.

По окончании redo-прохода сохраняют все обновления в БД, накатившиеся к моменту ее старта посредством сброса всех обновленных страниц оперативной памяти во внешнюю память, при этом в служебную запись слежения ставят признак окончания redo-прохода.

Пример сравнения полей TSN в redo-проходе теплого рестарта показан на фиг.4.

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

Если в аналитическом проходе выявлены незакоммиченные (незавершенные) транзакции, то они откатываются на логическом уровне в undo-проходе рестарта. При этом redo-журнал сканируют по записям от конца к началу. Откат данных на физическом уровне применяют только для незаконченных в журнале операций, записанных последними, для поддержания физической непротиворечивости БД.

Все изменения данных в БД, вызываемые откатами, протоколируют в журнале, как любые действия по модификации БД, формируя файлы записей отката в undo-журнале. Эти изменения начинаются в первом резервном файле и формируют часть журнала, назовем ее undo-журналом. Поле ссылки в записях отката в undo-журнале, содержащее адрес журнальной записи из redo-журнала, откат которой она описывает, используют для корреляции адресов в читаемом redo-журнале и растущем undo-журнале.

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

В начале undo-прохода первый резервный файл переименовывают и включают в кольцо файлов redo-журнала последним файлом, в который переносят служебную запись слежения, а затем выполняют протоколирование откатов незакоммиченных транзакций (незавершенных транзакций) до тех пор, пока пространство этого резервного файла будет заполнено, после чего включают в кольцо файлов undo-журнала второй резервный файл.

Включение переименованных резервных файлов в кольцо журнала в undo-проходе теплого рестарта показано на фиг.5.

Поясним, исходя из чего выбрано количество резервных файлов. Поскольку наименьшей единицей блокирования в заявляемом способе является кортеж, а не более крупный объект БД (например, страница), undo-действия могут не быть точной инверсией первичных действий транзакции из-за параллельных действий других транзакций. Поэтому первый резервный файл отводится под протоколирование отката транзакций из последнего файла redo-журнала, а второй - на протоколирование возможных дополнительных действий, совершаемых при этом в базе данных - расширение файла на N страниц, изменение битовой карты и т.д. Причем объем протоколирования этих возможных дополнительных действий незначителен по сравнению с объемом протокола операции, вызвавшей эти действия. Целый дополнительный файл выделяется, исходя из избыточного предположения, что все операции откатываемых транзакций могли привести к таким дополнительным действиям.

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

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

В случае повторного рестарта (из-за возможных прерываний процесса рестарта, например, по причине сбоя оборудования или операционной системы), если отказ системы произошел на стадии undo-прохода, рестарт в три прохода используют только для undo-журнала. При этом массив состояний транзакций предварительно заполняют в ходе просмотра redo-журнала в соответствии с записями, описывающими начало транзакций, и при сканировании в аналитическом проходе undo-журнала корректируют в соответствии с журнальными записями об изменении состояния этого массива. Также в аналитическом проходе по содержимому поля ссылки в последней записи undo-журнала определяют адрес последней откатившейся записи redo-обновления в redo-журнале. В redo-проходе по undo-журналу все пропущенные откатные обновления накатывают в БД (переносят в БД).

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

Когда транзакций, предназначенных к откату, больше не обнаруживают, все откатные обновления сбрасывают в БД и ставят в запись слежения признак окончания undo-прохода.

Номер файла в redo-журнале LastRedoFile, в котором содержится последняя откатившаяся запись, известен из содержимого ссылки последней записи в undo-журнале. Считая этот файл последним в redo-журнале, проверяют наличие предыдущих файлов в redo-журнале, начиная с LastRedoFile - 1. Если их количество, включая последний файл, меньше размера кольца файлов, добавляют недостающие файлы, переименовав последовательно файлы undo-журнала, начиная с номера LastRedoFile + 1. Файл с таким номером может отсутствовать, т.к. переименование файлов redo-журнале в undo-проходе могло породить пропуски в нумерации. Тогда переименовывают в следующий файл, и т.д. Когда размер кольца файлов восстановлен до требуемого размера, оставшиеся файлы переименовывают в два резервных файла. На фиг.6 показано восстановление размеров кольца журнала и количества резервных файлов по окончании undo-прохода теплого рестарта.

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