Поддержка Журнала базы данных. Бд журнал

Введение в базы данных | Журнал транзакций

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

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

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

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

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

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

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

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

- стандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK;

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

- принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве «жертвы» и принудительно прекращено ее выполнение ядром СУБД.

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

- при аварийном выключении электрического питания;

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

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

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

Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.

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

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

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

Каждая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет. Кроме того, для каждой транзакции в журнале фиксируется команда начала и завершения транзакции (рис. 6.7).

Рис. 6.7. Журнал транзакций

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

Имеются два альтернативных варианта ведения журнала транзакций: протокол с отложенными обновлениями и протокол с немедленными обновлениями.

Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций:

1. Когда транзакция Т1 начинается, в протокол заносится запись

2. На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: <T1,ID_RECORD, атрибут, новое значение ... >. Здесь ID_RECORD – уникальный номер записи.

3. Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится <Т1 СОММIT>.

4. После того как транзакция фиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД.

5. Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи <Т1 BEGIN TRANSACTION и <Т1 СОММIТ>. БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется некоторая системная процедура REDOQ, которая заменяет все значения элементов данных на новые, просматривая протокол в прямом порядке.

6. Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.

Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит <Т1, ID_RECORD, атрибут новое значение старое значение ...>. При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транзакция фиксируется, то есть встречается команда <Т1 СОММIТ> и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции.

При откате транзакции выполняется системная процедура UNOOO, которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION.

Для восстановления при сбое используется следующий механизм:

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

2. Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола.

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

3ys.ru

журнал базы данных - это... Что такое журнал базы данных?

 журнал базы данных

1) Information technology: database journal

2) SAP.tech. data base log, database log

Универсальный русско-английский словарь. Академик.ру. 2011.

• журнал аудита
• журнал безопасности

Смотреть что такое "журнал базы данных" в других словарях:

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

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

• Сервер базы данных — Сервер БД выполняет обслуживание и управление базой данных и отвечает за целостность и сохранность данных, а также обеспечивает операции ввода вывода при доступе клиента к информации. Архитектура клиент сервер состоит из клиентов и серверов.… …   Википедия

• Реляционные базы данных — Реляционная база данных база данных, основанная на реляционной модели данных. Слово «реляционный» происходит от англ. relation (отношение[1]). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз данных было… …   Википедия

• Культурно-историческая психология (журнал) — Культурно историческая психология Специализация: культурно историческая, деятельностная,социокультурная психоло …   Википедия

• Психологическая наука и образование (журнал) — Стиль этой статьи неэнциклопедичен или нарушает нормы русского языка. Статью следует исправить согласно стилистическим правилам Википедии …   Википедия

• Нормализация баз данных — Нормальная форма требование, предъявляемое к отношениям в теории реляционных баз данных для устранения из базы избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Содержание 1… …   Википедия

• Сервер баз данных — Сервер БД обслуживает базу данных и отвечает за целостность и сохранность данных, а также обеспечивает операции ввода вывода при доступе клиента к информации. Архитектура клиент сервер состоит из клиентов и серверов. Основная идея состоит в том,… …   Википедия

• Труд за рубежом (журнал) — «Труд за рубежом» Обложка журнала Труд за рубежом Специализация: социально трудовые отношения …   Википедия

• Советский филателист (журнал) — Обложка первого номера журнала «Советский филателист» (1922), на которой изображена стандартная марка РСФСР 1921 года …   Википедия

• Филателистический журнал — Обложки первых советских филателистических журналов Филателистический журнал  периодическое издание, знакомящее с нов …   Википедия

Книги

• Национальные интересы: приоритеты и безопасность № 39 (228) 2013, Отсутствует. Журнал освещает актуальные проблемы национальных интересов, приоритетные направления развития экономики, вопросы национальной безопасности России и регионов в различных сферах экономики,… Подробнее  Купить за 750 руб электронная книга
• Директор информационной службы № 11/2012, Открытые системы. Директор информационной службы (CIO. ru) – журнал для менеджеров, отвечающих за идеологию, стратегию и реализацию информационной поддержки бизнеса, руководителей ИТ-подразделений предприятий… Подробнее  Купить за 352 руб электронная книга
• Журнал «Хакер» № 08/2014, Отсутствует. «Хакер» – это культовый журнал для тех, кто страстно увлечен современными технологиями. Для тех, кто хочет развиваться в IT или просто быть на острие. В каждом номере: подробные HOWTO,… Подробнее  Купить за 250 руб электронная книга

Другие книги по запросу «журнал базы данных» >>

universal_ru_en.academic.ru

Поддержка Журнала базы данных

Записи журналов содержат, кроме всего прочего, копии лицензий, выданных для различных операций службы управления правами, например регистрации пользователей и назначении лицензий на использование. В наихудшей ситуации — когда каждая запись журнала является успешной регистрацией пользователя или успешной попыткой получить лицензию на использование — каждая запись добавит около 200 кБ к объему базы данных журналов.

Пусть, например, защищенное с помощью управления правами сообщение электронной почты отправлено всем сотрудникам компании, в которой работает 50 000 пользователей, и каждый пользователь открывает его. Если каждый сотрудник открыл это сообщение электронной почты в течение дня, объем базы данных журналов вырастет на 10 ГБ. Можно настроить прослушиватель не регистрировать определенные данные XrML, что уменьшит объем заносимой в журналы информации.

Обсудите возможность создания сценариев архивирования более ранней информации из базы данных журналов во вторичной базе данных. Примеры сценариев для журналов имеются в наборе инструментов для службы управления правами RMS Toolkit, который доступен для бесплатной загрузки с веб-узла корпорации Майкрософт (http://go.microsoft.com/fwlink/?LinkId=26724).

Переменные, влияющие на рост базы данных журналов

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

• Регистрация сервера службы управления правами
• Регистрация пользователя (один запрос на каждый компьютер, используемый каждым пользователем)
• Автоматические запросы пользователей на автономные сертификаты публикации

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

• Требование новой лицензии каждый раз при доступе пользователя к защищенному содержимому. Этот метод не принят по умолчанию для защищенных документов, он является дополнительным. Если выбрать выполнение этого требования, базы данных будут расти быстрее.
• Ожидаемое число защищенных сообщений электронной почты, отправленных каждому получателю за день.
• Ожидаемое число уникальных пользователей, которые прочитают эти защищенные сообщения электронной почты.
• Ожидаемое число защищенных документов Microsoft Office 2003 (Word, PowerPoint и Excel), создаваемых каждым сотрудником за день.
• Ожидаемое число получателей защищенных документов.

Начальный размер базы данных журналов будет около 1,7 МБ; в этот объем входит запрос на сертификат сервера управления правами. Каждый раз при регистрации нового пользователя он получает сертификат учетной записи управления правами (RAC) и сертификат лицензиара клиента (CLC). Эти две операции заносятся в журнал, увеличивая его объем на 0,06 МБ. Каждый раз при успешном получении пользователем лицензии на защищенное содержимое база данных увеличивается на 0,19 МБ.

Чтобы рассмотреть работу этой схемы оценивания, рассмотрим организацию, разворачивающую систему управления правами с 5 000 пользователями. У каждого пользователя один компьютер, а у организации два сервера службы управления правами. После развертывания каждый пользователь в среднем создает одно защищенное с помощью управления правами сообщение электронной почты в день, которое отправляется пяти другим пользователям. Кроме того, каждый пользователь создает один защищенный с помощью управления правами документ за день, который используется тремя другими пользователями. В приведенной ниже таблице оценено, насколько эти операции увеличивают объем базы данных журналов.

 

Операция Рост объема журнала Суммарный размер журнала

Успешная подготовка сервера управления правами	1,7 МБ	1,7 МБ
Регистрация 5000 сотрудников (5000*0,06)	300 МБ	301,7 МБ
Доступ к защищенным сообщениям электронной почты (25000*0,19)	4750 МБ	5051,7 МБ
Доступ к защищенным документам (15000*0,19)	2850 МБ	7901,7 МБ

Таким образом, после регистрации база данных имеет постоянный размер около 300 МБ. Однако рост за день в этом примере составляет 7,6 ГБ — близко к ограничению в 8 ГБ для установки по умолчанию службы очередей сообщений. Если база данных журналов станет недоступной более чем на день, записи журналов начнут теряться.

Контроль за размером базы данных журналов

В план развертывания необходимо включить метод управления размером базы данных журналов. Ниже приведены наиболее употребительные приемы.

• Удаление и архивирование

  Этот метод требует использования сценариев SQL Server для архивирования выбранной информации из базы данных журналов во вторичной базе данных после того, как записи достигнут определенного возраста. Кроме того, он требует фильтрации базы данных от посторонней информации, чтобы на нее не тратилось место.

• Ограничение информации, заносимой в журнал

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

  Включающие и отключающие записи определяют, какие поля главной таблицы заносятся в журнал службой прослушивателя на сервере управления правами. Два из этих полей (по отношению к XrML) уже установлены в 0 для отключения занесения в журнал, так как эти два поля отвечают примерно за 99% размера каждой записи о запросе лицензии.

  Другая таблица в базе данных DRMS_Config_ServerName_Port, называемая DRMS_ClusterPolicies, содержит PolicyName для параметра LoggingFiltering. Параметр LoggingFiltering по умолчанию не включен. Если изменить значение параметра LoggingFiltering на 1 и перезапустить службу прослушивателя, в приведенном выше примере дневной рост базы данных журналов уменьшится с 7,6 ГБ примерно до 160 МБ.

• Перемещение базы данных журналов

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

  1. Остановите службу прослушивателя на каждом сервере управления правами.
  2. Скопируйте базу данных на другой сервер (или создайте новую).
  3. Измените базу данных DRMS_Config_ServerName_Port службы управления правами, выбрав таблицу DRMS_ClusterPolicies и изменив значения полей LoggingDatabaseName (имя сервера базы данных) и LoggingDatabaseServer (имя базы данных).
  4. Перезапустите службу IIS, запустив IISRESET.exe из командной строки.

technet.microsoft.com

Международные базы данных (Web of Science, Scopus и др.)

Web of Science (WOS) – самая авторитетная в мире аналитическая и цитатная база данных журнальных статей.

Web of Science размещается на поисковой платформе Web of Knowledge.

Web of Knowledge – поисковая платформа, объединяющая реферативные базы данных публикаций в научных журналах и патентов, в том числе базы, учитывающие взаимное цитирование публикаций, предоставляемая компанией Clarivate Analytics.

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

Основу БД составляют:

Science Citation Index Expanded – индекс цитирования по естественным и точным наукам – естественно-научные, технические и медицинские журналы;

Social Sciences Citation Index (SSCI) – индекс цитирования по социальным наукам – журналы по экономическим и общественным наукам;

Arts&Humanities Citation Index (A&HCI) – индекс цитирования по искусству и гуманитарным наукам – журналы по археологии, архитектуре, всем видам искусства, литературе, истории, философии, религии.

Процентное соотношение между представленными в ресурсе Web of Science дисциплинами следующее: 25–27% – технические и прикладные науки, 30% – это социогуманитарные науки, 43–45% – блок естественных наук (в т.ч. 15–18% – науки о земле, биология и медицина).

Scopus

Scopus (SciVerse Scopus) (http://www.scopus.com) – крупнейшая в мире мультидисциплинарная библиографическая и реферативная база данных, созданная издательской корпорацией Elsevier. Одной из основных функций этой базы данных является встроенная в поисковую систему информация о цитировании. Scopus охватывает свыше 18 тыс. научных журналов от 5 тыс. научных издательств мира, включая около 200 российских журналов, 13 млн патентов США, Европы и Японии, материалы научных конференций. Scopus в отличие от Web of Science не включает издания по гуманитарным дисциплинам и искусству, содержит небольшую долю журналов по социальным наукам – не более 17%, и в процентном отношении гораздо шире отражает естественные науки и технику – 83%.

Agris

International Information System for the Agricultural Sciences and Technology (http://agris.fao.org/) – Международная информационная система по сельскохозяйственным наукам и технологиям. Agris представляет собой глобальную базу данных с более чем 7 млн. библиографических записей. База данных находится в ведении ФАО (Продовольственная и сельскохозяйственная организация ООН (ФАО) (англ. Food and Agriculture Organization, FAO). 79,45% записей являются цитатами из научных журналов. Список периодических изданий, расписывавшихся для БД AGRIS во 2-м полугодии 2012 г. и в 1-м полугодии 2013 г.

GeoRef

GeoRef (http://www.agiweb.org/) – библиографическая база данных, охватывающая мировую литературу по геологии и геонаукам. База данных содержат библиографическую информацию, рефераты, индексируемые термины. Поиск можно проводить по библиографическому описанию документов, рефератам, терминам индексирования, информации, полученной на конференциях, а также координатам географических карт.

Chemical Abstracts Service

Chemical Abstracts Service (http://www.cas.org/) – химическая реферативная служба – подразделение Американского химического общества (American Chemical Society), издающее реферативный журнал Chemical Abstracts. Журнал содержит информацию о публикациях во всех областях химии, биохимии, химической технологии и смежных отраслях знаний, начиная с 1907 года по настоящее время. Электронное издание дает информацию с 2005 г. по настоящее время.

Авторитет международных баз научного цитирования Scopus и Web of Science, а также специализированных баз Agris, Astrophysics, Chemical Abstracts, GeoRef и других признан научным сообществом России. Количество цитирований научных публикаций в Web of Science и Scopus входит в Примерный перечень критериев общероссийской системы оценки эффективности деятельности высших учебных заведений, который был определен Минобрнауки России 13 июля 2012 г.

www.asu.ru

---

Смотрите также

• 
  Журнал горизонтальный
• 
  Горизонтальный журнал
• 
  Анекдоты журнал
• 
  Статистические журналы
• 
  Журнал простоя
• 
  Журналы пмпк
• 
  Рационализатор журнал
• 
  Журнал языкознание
• 
  Консилиум журнал
• 
  Журнал консилиум
• 
  Журнал дара