CC BY
10Решетнеескцие чтения. 2015
УДК 681.3.07
ОРГАНИЗАЦИЯ ЖУРНАЛА ОПЕРАЦИЙ С БАЗОЙ ДАННЫХ В ИНФОРМАЦИОННОЙ СИСТЕМЕ ООО «РУСПРОМКОМ»
А. А. Таскаева
Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31
E-mail: 79232951316@yandex.ru
Предлагается подход к организации журнала операций с базой данных. Основная идея используемой технологии заключается в создании журнальной таблицы для каждой рабочей таблицы базы данных, а также в создании трех правил (CREATERULE): для операций вставки, обновления и удаления записей из рабочих таблиц. При выполнении операций с рабочей таблицей копии вставляемой, обновляемой или удаляемой записи вставляются в журнальную таблицу.
Ключевые слова: организация журнала операций с базой данных, создание журнальной таблицы, рабочая таблица, операция вставки.
ORGANIZING LOG OF DATABASE OPERATIONS IN THE INFORMATION SYSTEM AT "ROSPROMECO" LTD
A. A. Taskaeva
Reshetnev Siberian State Aerospace University 31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation E-mail: 79232951316@yandex.ru
We propose an approach to organize database operations. The basic idea of the technology is used to create a specific log table for each of the working tables of the database, as well as three rules (CREATERULE: operation inserting, updating and deleting records from a worksheet. When operations are performed with the working tables, copies of inserted, updated or deleted records are inserted into that specific table.
Keywords: organize database operations, creating a log table, operation inserting, working table,
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Это означает, что СУБД должна суметь восстановить последнее согласованное состояние базы данных (БД) после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: «мягкие сбои» - внезапная остановка работы компьютера (например, аварийное выключение питания), и «жесткие сбои», характеризуемые потерей информации на носителях внешней памяти.
В любом случае для восстановления БД нужно иметь дополнительную информацию. Поддержание надёжности хранения данных в БД требует избыточности хранения данных. При этом особо надёжно должны храниться данные, используемые для восстановления. Распространённым методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это поддерживаемая с особой тщательностью часть БД, недоступная пользователям СУБД. В неё поступают записи обо всех изменениях основной части БД. Иногда поддерживают две копии журнала, размещая их на разных физических дисках.
Во всех случаях придерживаются стратегии «упреждающей» записи в журнал. Это означает, что запись об изменении любого объекта БД должна по-
пасть во внешнюю память журнала раньше, чем измененный объект попадёт во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL (WriteAheadLog), то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для этого сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия - это полная копия БД к моменту начала заполнения журнала. Для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. К сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что,
Программные средства и информационные технологии
исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления.
При эксплуатации информационных систем возможны не только сбои в работе оборудования, но также и ошибки оператора. В первом случае может потребоваться выполнить восстановление БД с ее резервной копии. Для этого используются стандартные утилиты, входящие в комплект системы управления базами данных (СУБД). Такие утилиты имеются и в составе СУБД PostgreSQL. В случае же ошибок оператора, особенно если они обнаружены с опозданием, выполнение восстановления базы данных посредством системной утилиты приведет к тому, что будут утрачены и корректные изменения базы данных, выполненные после проведения последнего резервного копирования. Таким образом, даже небольшая ошибка оператора может привести к необходимости повторного выполнения ввода или корректировки значительного объема данных.
Если бы в базе данных сохранялась вся история изменений каждой реляционной таблицы, то администратор имел бы возможность выполнять восстановление не только всей таблицы целиком, но и каждой конкретной строки в таблице.
В докладе предлагается организовать такую систему учета изменений базы данных, которая была бы построена на основе системы правил (rules) СУБД PostgreSQL.
Основные принципы и правила ее построения следующие.
1. В каждую таблицу базы данных вводятся следующие атрибуты, содержащие служебную информацию:
who_chgtext DEFAULT USER - кем добавлена (изменена) запись;
when_chg timestamp;
DEFAULTCURRENT_TIMESTAMP - когда добавлена (изменена) запись.
2. Для каждой таблицы базы данных, которые назовем рабочими таблицами, должна быть создана таблица, которую будем называть журнальной. Эта таблица содержит все атрибуты рабочей таблицы и дополнительно еще три атрибута:
db_operationtext - операция над БД;
who_addtextDEFAULTUSER - кем добавлена запись;
when_addtimestampDEFAULTCURRENT_TIMEST AMP - когда добавлена запись.
3. Журнальные таблицы создаются без каких-либо ограничений целостности. Ограничения целостности не нужны, поскольку записи в журнальные таблицы добавляются только из рабочих таблиц, а в рабочих таблицах ограничения целостности присутствуют, поэтому данные в них согласованные.
4. Для каждой рабочей таблицы создается три так называемых правила (CREATERULE). Это расширение языка SQL, поддерживаемое СУБД PostgreSQL.
Правила позволяют с каждой операцией, выполняемой над таблицей базы данных, связать некоторые дополнительные операции, выполняемые, возможно, над другими таблицами. В нашей технологии правила создаются для операций вставки записей в таблицу (INSERT), обновления записи в таблице (UPDATE) и удаления записей из таблицы (DELETE).
Правило для операции вставки записей выглядит так:
CREATE RULE Langs_rule_1 AS ON INSERT TO sost_zayvki DO INSERT INTO sost_zayvki_2 (id,id_zayavki,naimenovanie,sechenie, kol-vo, m2, stoim, itogo, skidka,who_chg,when_chg,db_operation )VALUES(
NEW.id,NEW.id_zayavki,NEW.naimenovanie,NEW.sec henie,NEW.kol-vo,NEW.m2, NEW.stoim, NEW.itogo,NEW.skidka, NEW.who_chg, NEW.when_chg, 'INSERT' );
В этой команде таблица sost_zayvki - это основная таблица, а sost_zayvki_2 - журнальная таблица. Атрибут db_operation будет содержать значение 'INSERT', атрибут who_add - значение по умолчанию, т. е. имя пользователя, добавившего запись в рабочую таблицу, атрибут when_add - значение по умолчанию, т. е. временную отметку выполнения операции.
Правило для операции обновления записей выглядит так:
CREATE RULE Langs_rule_2 AS
ON UPDATE TO sost_zayvki
DO INSERT INTO sost_zayvki_2 (id, id_zayavki, naimenovanie, sechenie, kol-vo, m2, stoim, itogo, skidka,who_chg, when_chg, db_operation )VALUES (NEW.id,NEW .id_zayavki,NEW. naimenovanie,NEW.sec henie,NEW.kol-vo,NEW. m2, NEW.stoim, NEW.itogo,NEW.skidka,NEW.who_chg, NEW.when_chg, 'UPDATE' );
Правило для операции удаления записей выглядит так:
CREATE RULE Langs_rule_3 AS
ON DELETE TO sost_zayvki
DO INSERT INTO sost_zayvki_2 (id, id_zayavki, naimenovanie, sechenie, kol-vo, m2, stoim, itogo, skidka,who_chg, when_chg, db_operation )VALUES (OLD.id,OLD.id_zayavki,OLD. naimenovanie,OLD.seche nie,OLD.kol-vo,OLD. m2, OLD.stoim, OLD.itogo,OLD .skidkaOLD .who_chg, OLD.when_chg, 'DELETE' );
5. В журнальные таблицы записи только добавляются, но не обновляются и не удаляются из них. Поэтому сохраняется вся история изменения каждой записи из рабочей таблицы.
Предложенный подход позволит повысить безопасность выполнения операций с базой данных. В случае ошибки оператора администратор базы данных сможет отыскать запись в журнальной таблице и восстановить то состояние конкретной записи в рабочей таблице, которое требуется.
© Таскаева А. А., 2015
