Организация и методы резервирования данных в СУБД Oracle. Дипломная (ВКР). Информационное обеспечение, программирование.
⚡ 👉🏻👉🏻👉🏻 ИНФОРМАЦИЯ ДОСТУПНА ЗДЕСЬ ЖМИТЕ 👈🏻👈🏻👈🏻
Информационное обеспечение, программирование
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!
Похожие работы на - Организация и методы резервирования данных в СУБД Oracle
Нужна качественная работа без плагиата?
Не нашел материал для своей работы?
Поможем написать качественную работу Без плагиата!
КАФЕДРА
ПРИКЛАДНОЙ ФИЗИКИ И ИНФОРМАТИКИ
Организация и
методы резервирования данных в СУБД ORACLE
Глава 1. Резервные данные. Схемы Ротации
.4 Копирование СУБД и пользовательских файлов
.1 Резервные базы данных под управлением Oracle Data Guard
.3 Создание физической резервной базы
Глава 3. Защита резервных копий баз данных и базы данных
разработчиков
.4 Базы данных для работы в непредвиденных обстоятельствах
Глава 4. Клонирование БД на локальном и удаленном компьютере
с использованием пользовательской резервной копии
4.1 Создание резервной копии методом “холодного” копирования
.2 Восстановление базы данных на удаленной машине
.2.1 С сохранением структуры каталогов
.2.2 В измененной структуре каталогов
.2.3 Восстановление при отсутствии части
необходимых файлов
.3 Восстановление
базы данных на локальной машине
.4 Создание
резервной копии методом “горячего” копирования
.5 Восстановление
базы данных из «горячей» копии
Глава 5. Резервирование и восстановление
.1 Планирование восстановления экземпляра
.2 Планирование восстановления носителя
Большинство руководителей предприятий не отдают себе отчета в важности
резервного копирования и архивирования данных. Более того, они не хотят
прислушиваться к доводам специалистов. Поэтому остальные вынуждены использовать
самое простое (и, соответственно, самое неудобное) обеспечение, из-за чего у
администратора возникает множество дополнительных забот, таких, например, как
ежедневное составление расписания резервного копирования, организации
надлежащей схемы резервного копирования и архивирования данных.
Несмотря на такие особенности, тема резервного копирования и
архивирования всегда вызывала и вызывает повышенный интерес. Многие прекрасно
понимают, что рано или поздно этими вопросами все равно придется заниматься
всерьез.
Огромное число организаций сталкивается с годовым ростом данных,
превышающим 50%. Около 70% конечных пользователей хранят свою информацию на
файловых серверах, и эта информация занимает от 50% до 70% емкости в более чем
40% организаций. С такими потребностями в хранении, что могут сделать ИТ
администраторы?
Эксперты в области ИТ и главные менеджеры по информации постоянно ломают
голову над тем, как улучшить управление жизненно важной для компании
информацией, а также над методами совершенствования систем управления хранением
данных. Основная проблема, с которой они сталкиваются, - это постоянное
балансирование трех фундаментальных факторов: роста данных, сохранности
информации и инвестиций в технологию, время и персонал. Только очень хорошо
продуманная стратегия хранения данных может предложить решение.
Многие компании не видят повода для беспокойства, поскольку они регулярно
резервируют свои данные и полностью убеждены в эффективности резервного
копирования на диск и данных, хранящихся на серверах. Но является ли это
единственной подходящей и эффективной стратегией хранения?
Оптимальное решение заключается не только в хранении данных, но также и в
максимально эффективном их использовании. Это очень важно, поэтому, на мой
взгляд, данная тема является очень важной в сегодняшнее время.
Под резервным копированием обычно понимают создание копий файлов с целью
быстрого восстановления работоспособности системы в случае возникновения
аварийной ситуации. Эти копии хранятся на носителях (которые нередко называют
резервными) определенный срок и затем перезаписываются. Таким образом, с ростом
объема информации число резервных носителей увеличивается относительно
медленно. Резервному копированию, как правило, подлежат данные, часто
требующиеся пользователям. Эти данные можно определить по тому, какой период времени
прошел со дня последнего обращения к их файлам. Для надежной защиты данных
рекомендуется иметь по три резервные копии последних редакций файлов.
Резервное копирование может быть полным, инкрементальным и
дифференциальным. При полном копировании создается копия всех данных,
подлежащих резервированию. Недостаток этой процедуры - она требует много
времени и ведет к большому расходу магнитной ленты, а достоинство - самая
высокая надежность и относительно быстрое восстановление информации из одной
полной копии (поскольку для этого достаточно только одного записанного образа).
Полное копирование служит отправной точкой для других методов.
При инкрементальном копировании дублируются лишь те файлы, которые были
созданы или изменены после последнего полного, дифференциального или
инкрементального копирования. Иными словами, при использовании инкрементального
копирования первая запись на ленту - это полная копия. При второй записи на
ленту помещаются только те файлы, которые были изменены со времени первой
записи. На третьем этапе копируются файлы, модифицированные со времен второго
этапа, и т. д. Это самый быстрый метод копирования, требующий минимального
расхода магнитной ленты. Однако восстановление информации при инкрементальном
копировании самое длительное: информацию необходимо сначала восстановить с
полной копии, а затем последовательно со всех последующих. Тем не менее, это
самый популярный метод резервного копирования, поскольку полное восстановление
информации - все-таки достаточно редкая процедура в нормально работающей
системе.
При дифференциальном копировании дублируются только файлы, созданные или
измененные со времени проведения последнего полного копирования. И чем больше
это время, тем дольше будет осуществляться дифференциальное копирование. Иными
словами, первая запись на ленту - это опять-таки полная копия. На последующих
этапах копируются только файлы, которые изменились со времени проведения
полного копирования. Само копирование в этом случае занимает больше времени,
чем инкрементальное копирование. В случае краха системы администратору для
восстановления данных придется задействовать последние полную и
дифференциальную копии.
Обычно для достижения компромисса между продолжительностью резервного
копирования данных и временем их восстановления выбирается схема, согласно
которой раз в неделю проводится полное копирование и ежедневно -
инкрементальное. Главная проблема при инкрементальном и дифференциальном
копировании - это выбор критерия для проверки факта изменения файла. К
сожалению, ни один из известных критериев не может полностью гарантировать это
условие.
Самый распространенный способ - использование архивного атрибута файлов (archive). При создании или модифицировании
файла прикладные программы автоматически выставляют данный атрибут. При резервном
копировании он принимает прежнее значение. Поэтому теоретически система
резервного копирования может таким образом определить, что файл еще не
копировался на ленту. Но ряд прикладных программ принудительно восстанавливают
этот атрибут при работе с файлами. Таким образом, система резервного
копирования будет считать, что у файла есть копия на ленте, хотя это и не так.
В результате может получиться, что файлы останутся вообще без резервных копий.
В некоторых случаях можно сравнивать время последнего обращения к файлу или
время его модификации с каким-то эталонным временем, например, временем
предыдущего копирования. К сожалению, и этот критерий не идеален, хотя, как
правило, он более эффективен, чем контроль за архивным атрибутом. Проверка
размера файла используется еще реже, у этого способа еще больше недостатков,
чем у других критериев. Конечно, лучшим вариантом был бы одновременный учет
нескольких или всех названных критериев. Но такой подход могут предложить
только самые мощные системы резервного копирования.
Под архивным копированием обычно понимают процесс создания копий файлов,
предназначенных для бессрочного или долговременного хранения. Это процесс
получения "слепка" файлов и каталогов в том виде, в котором они
располагаются на первичном носителе (обычно диске) в данный момент времени.
Носители, на которые переносятся данные, называют архивными. Периодическое
проведение архивного копирования позволит иметь копии нескольких разных версий
одних и тех же файлов. Впрочем, особо важные файлы иногда помещают в архив
независимо от времени их последней модификации. Обычно считается, что для
надежности хранения нужно иметь 2-3 архивные копии всех редакций файлов,
подлежащих архивированию.
В принципе архивное копирование тоже может быть полным, инкрементальным и
дифференциальным, однако процесс архивирования обычно организован так, что
делаются только полные копии, к которым, как правило, через определенное время
добавляют инкрементальные. Дифференциальное архивное копирование обычно не встречается.
Как показывает практика, количество архивных носителей на предприятии довольно
быстро растет.
Набором носителей информации называется группа резервных или архивных
носителей, периодически используемая в процессе копирования. Для повышения
надежности хранения информации не следует помещать более одной копии одного и
того же файла на один носитель или набор носителей. Таким образом, чтобы иметь,
например, три копии, нужно задействовать три разных набора носителей. При этом
для защиты данных от всевозможных катастроф и стихийных бедствий один из
наборов следует хранить в удаленном месте.
В отличие от резервного копирования архивирование обычно выполняется над
данными, ассоциированными с конкретным проектом, а не с системой в целом.
Для архивов характерен очень большой объем хранимой информации, поэтому
система архивирования должна обеспечивать быстрый и удобный поиск файлов по
версиям и времени создания, а также поддерживать автоматическое удаление файлов
по прошествии заданного времени. Здесь поддержка автоматических библиотек еще
более важна, чем в случае резервного копирования.
Как правило, резервное копирование и архивирование лучше всего выполнять
ночью и в нерабочие дни. Это позволяет максимально ускорить процесс копирования
и не накладывает на пользователей специфических ограничений. Дело в том, что,
хотя многие серьезные программы резервирования могут обрабатывать открытые
файлы, их резервное копирование значительно замедляет весь процесс. Кроме того,
резервное копирование сильно загружает процессоры серверов, заметно снижая
производительность сети.
Хотя резервное копирование и архивирование опираются на одни и те же
принципы и, более того, любой программный продукт позволяет выполнять как
функции резервного копирования, так и архивирования, тем не менее, оба эти
процесса имеют свои особенности. Если цель резервного копирования - сохранить
текущее состояние системы, то при архивировании задача состоит в долгосрочном
хранении информации, чтобы данные можно было извлечь, даже если они созданы и
месяц, и год назад. Нередко архивирование предполагает перенос всех данных по
завершении какого-то проекта на внешние носители, чтобы освободить место на
винчестерах. Поэтому при страховом копировании важно выработать надлежащую
схему ротации носителей информации с тем, чтобы можно было не только быстро
сохранить данные или восстановить информацию, но и чтобы носители на каждом
временном этапе содержали полный архив данных.
Схема "дед-отец-сын" имеет иерархическую структуру и
предполагает использование комплекта из трех наборов носителей. Раз в неделю делается
полная копия дисков компьютера, ежедневно же проводится инкрементальное (или
дифференциальное) копирование. Дополнительно раз в месяц проводится еще одно
полное копирование. Набор для ежедневного инкрементального копирования
называется "сыном", для еженедельного - "отцом", для
ежемесячного - "дедом". Состав ежедневного и еженедельного набора
постоянен. В ежедневном наборе свой носитель (их может быть несколько, если
объем информации превышает объем одного носителя) закреплен за каждым рабочим
днем (кроме пятницы), а в случае еженедельного набора - за каждой неделей
месяца по порядку (т. е. данный набор должен содержать не менее четырех
носителей). Ежемесячные носители обычно заново не используются и откладываются
в архив. Таким образом, по сравнению с простой ротацией в архиве содержатся
только ежемесячные копии плюс последние еженедельные и ежедневные копии.
Недостаток данной схемы состоит в том, что в архив попадают только данные,
имевшиеся на конец месяца. Как и при схеме простой ротации, носители для
ежедневных копий подвергаются значительному износу, в то время как нагрузка на
еженедельные копии сравнительно невелика.
Схема "ханойская башня" призвана устранить некоторые из
перечисленных недостатков, но, правда, имеет свои собственные. Схема построена
на применении нескольких наборов носителей, их количество не регламентируется,
хотя обычно ограничивается пятью-шестью. Каждый набор предназначен для
недельного копирования, как в схеме простой ротации, но без изъятия полных
копий. Иными словами, отдельный набор включает носитель с полной недельной
копией и носители с ежедневными инкрементальными (дифференциальными) копиями.
Специфическая проблема схемы "ханойская башня" - ее излишняя
сложность.
Еще одна схема ротации называется "10 наборов" и, как следует
из названия, рассчитана на десять наборов носителей. Период из сорока недель
делится на десять циклов. В течение цикла за каждым набором закреплен один день
недели. По прошествии четырехнедельного цикла номер набора сдвигается на один
день. Иными словами, если в первом цикле за понедельник отвечал набор номер 1,
а за вторник - номер 2, то во втором цикле за понедельник отвечает набор номер
2, а за вторник - номер 3. Такая схема позволяет равномерно распределить
нагрузку, а следовательно, и износ между всеми носителями.
Таблица 1. Схема ротации "Ханойская башня".
Банк данных - это информационная система коллективного пользования,
обеспечивающая централизованное хранение данных, их обновление и выдачу по
запросам пользователей. Это комплекс аппаратного и программного обеспечения
банка данных и персонала, обслуживающего его. Банк данных включает:
. систему управления базами данных (СУБД);
. персонал, обеспечивающий работу банка данных.
База данных - это совокупность определенным образом организованных
данных, хранящихся в запоминающих устройствах ЭВМ. Обычно данные хранятся на
жестком диске сервера организации.
Проблемы могут возникнуть и при резервировании и архивировании баз
данных. Резервирование базы данных лучше всего проводить в "холодном"
виде, когда перед резервированием БД закрывается. Такое резервирование лучше
всего выполнять в ночное время, когда пользователей можно отключать от базы.
Однако во многих случаях этот вариант неприемлем. Во-первых, базы данных сейчас
нередко достигают в объеме сотен и тысяч гигабайт, поэтому их копирование
требует слишком много времени, и даже ночи для этого не хватит. Блокировать же
доступ к базе на длительное время могут позволить себе немногие. Во-вторых,
нередко СУБД работают в режиме on-line (например, на серверах Internet), и отключение их в принципе
невозможно.
Чтобы нивелировать проблемы копирования баз данных, производители систем
резервирования поставляют специальные агенты для конкретных СУБД. Большинство
агентов рассчитано на поддержку таких СУБД, как Oracle, Informix, Sybase. В свою очередь разработчики мощных
СУБД снабжают свои продукты программными интерфейсами резервирования или даже
отдельными утилитами резервирования. К сожалению, распространенные системы
резервирования поддерживают ограниченное количество основных СУБД ввиду
экзотичности остальных (в смысле узости рынка). К сожалению, сами производители
СУБД не очень-то стремятся восполнить данный пробел. К тому же огромное
количество сетевых приложений опирается на собственные базы данных, найти для
них агенты резервирования также может оказаться непросто.
Наиболее популярный подход к резервированию активных БД заключается в
том, что в определенный момент создается полная копия базы. Все последующие
обращения к базе (в момент резервирования) либо кэшируются, либо заносятся на
диск с помощью переадресации. После завершения копирования эти обновления
вносятся в БД. Иногда кэшируются не обновления, а старые данные. Очевидно,
чтобы сохранить целостность данных, БД должна устойчиво функционировать в
момент резервирования. Определенные проблемы может доставить резервное
копирование обычных пользовательских файлов, если в момент резервирования они
блокированы (открыты для записи). Большинство систем резервирования нижнего
уровня не могут обрабатывать их и пропускают эти файлы. Однако в настоящее
время многие системы среднего и старшего уровня имеют модули, с помощью которых
они могут копировать открытые файлы. Технология резервирования открытых файлов
аналогична тому, как это реализовано для СУБД, т. е. за счет кэширования старых
данных или обновлений.
После того, как база данных наполнена информацией, у администраторов баз
данных (DBA) возникает естественное желание
защитить данные от потери, даже если это не предусматривалось изначально при
построении информационной системы. Самый простой способ - периодически
копировать файлы базы или выгружать данные из таблиц программными средствами.
Эти методы относятся к "холодному" и логическому резервированию.
Холодным оно называется, так как пользователи при этом не работают с базой
данных и службы, через которые они работают, "погашены". Если
резервирование нужно выполнять так, чтобы не создавалось препятствий работе
пользователей, такой тип резервирования называется горячим. Для логического
резервирования обычно используют утилиту экспорта информации, которая
поставляется, например, в составе ПО компании Oracle (#"700633.files/image001.jpg">
Термин резервная база данных появился в ПО Oracle в 1995 г., начиная с версии 7.3. В то время объемы
жестких дисков были невелики, а стоили они довольно дорого, и для
резервирования даже небольших баз данных предпочитали использовать ленточные
устройства. Процедуры упрощения работы с резервными базами данных стали
развиваться с версии Oracle8i, когда жесткие диски начали
дешеветь, а их объемы быстро расти. Новые технологии в производстве аппаратных
средств дали толчок к развитию новой архитектуры резервирования баз данных.
Для создания резервной базы данных нужно скопировать на резервный
компьютер рабочие файлы данных и настроить автоматическую передачу журналов
изменений. На резервном компьютере нужно запустить процессы, которые будут
принимать информацию из журналов и при возникновении сбоя рабочей базы данных
сделают резервную доступной для работы пользователей, "активируют" ее
с минимальной задержкой по времени и гарантированным отсутствием потерь данных.
Схема довольно простая; интересны здесь возможности, которые дают процедуры
автоматизации. Даже опытный администратор в случае сбоя может допустить ошибку;
иными словами, в критической ситуации слабым звеном становится человек. Но ПО
должно выполнять рутинные процедуры безошибочно и с минимальным вмешательством
администратора. Задача же администратора сводится к настройке ПО.
Автоматизированные процедуры поддержки резервных баз носят в системе Oracle название Data Guard. Эти процедуры встроены в ПО Oracle. В их число входят графическая оболочка управления
резервными базами, утилита командной строки (dgmgrl) и дополнительные процессы, которые выполняют часто
встречающиеся действия, предназначенные для поддержки конфигурации
взаимодействия основной и резервных баз данных.
Графический интерфейс Oracle Data Guard Manager (рис. 2) можно использовать для автоматического
создания резервной базы. Он включен в стандартную оболочку ПО управления Oracle Enterprise Manager, начиная с версии Oracle9i.
Администратору достаточно указать, на каком из компьютеров с установленным ПО Oracle нужно создать резервную базу данных.
Оболочка сама выполнит резервирование файлов данных, перенесет их на резервный
компьютер и изменит параметры конфигурации основной базы данных, чтобы она
могла передавать журнальную информацию на компьютер с резервной базой.
Рис. 2. Oracle Data Guard Manager - графическая оболочка управления.
2.3 Создание физической резервной базы
Сначала создается управляющий файл - служебный файл небольшого размера,
содержащий названия всех файлов данных и их параметры. Служебный файл вместе с
копией файлов данных переносится на удаленный компьютер. На этом компьютере
должно быть установлено стандартное ПО Oracle для управления базами данных. Основное неудобство в
том, что программная архитектура основной и резервных баз данных должна быть
одинакова. Например, невозможно создать резервную базу на платформе Linux, если основная работает под Windows. Это ограничение связано с тем, что
в ОС различаются низкоуровневые программные интерфейсы (API) для работы с файлами, а
следовательно, структуры файлов базы данных также имеют отличия. Версии ОС в
пределах семейства и платформы могут быть любыми, главное, чтобы на них могло
работать ПО Oracle.
Далее программно запускается служба, которая будет принимать журнальную
информацию от основной базы данных и обслуживать пользователей в случае
активации резервной базы данных. Эта служба называется экземпляром Oracle. Служба состоит из нескольких
процессов ОС, каждый из которых выполняет набор действий, определенный
программистами Oracle. Несколько
процессов нужны, чтобы возложить задачу распределения процессорного времени для
одновременного выполнения разных задач на планировщик ОС.
После запуска экземпляра, обслуживающего резервную базу, нужно указать
экземпляру основной базы, куда посылать журнальную информацию. Она может
передаваться немедленно, практически без задержек, по мере наполнения буфера
журнальной информации или по мере генерации нового журнального файла (это
устанавливается администратором). Пересылка данных по мере генерации файлов
совершенно необременительна для рабочей базы, так как этим будет заниматься
отдельный процесс-архиватор (ARCn).
Независимо от скорости сети, которая связывает оба компьютера, или сетевой
задержки, накопленная информация будет передана.
Если возникнет долговременный сбой сети или компьютера с резервной базой
данных, то журналы, которые не были переданы, будут запрошены резервной базой
данных позже. В любом случае архиватор сохраняет всю журнальную информацию в
каталоге на компьютере с рабочей базой данных в виде файлов - ведет архив
журналов. Администратор обычно удаляет архив, когда в нем отпала необходимость.
Именно из этого архива и будут браться файлы, которые не удалось передать в
резервную базу. Для их передачи экземпляр резервной базы создает процесс FAL-клиент, который обращается к
экземпляру рабочей базы. На нем создается процесс, называемый FAL-сервер, который и передает требуемую
информацию (рис. 3). В промышленных системах, где нагрузка на рабочие базы
данных велика, файлы можно запрашивать у других резервных баз, которые успели
вовремя получить журналы. Традиционно ПО Oracle дает администраторам возможность настроить систему
управления базами данных так, чтобы удовлетворить любые запросы. Пользоваться
всеми возможностями сразу обычно не требуется. Достаточно знать, что такие
возможности есть и, если возникнет необходимость, их можно использовать.
Рис. 3. Архитектура передачи журналов.
При конфигурировании процесса передачи журналов администратор также
должен указать, необходимо ли основной базе данных приостанавливать
обслуживание пользователей до тех пор, пока все изменения не будут переданы в
резервную базу. Если обслуживание не приостанавливать, то данные будут переданы
процессами FAL с задержкой, когда восстановится
сетевое соединение. При неблагоприятном стечении обстоятельств: отказе сети и
последующем отказе рабочей базы администратору нужно будет дождаться передачи
недостающих журналов и только тогда активировать резервную базу. Он может
активировать резервную базу данных и немедленно, но тогда часть изменений будет
потеряна. Их нужно будет вносить позже на логическом уровне. В зависимости от
важности хранимых данных администратор принимает решение об уровне их защиты.
Решение об активации резервной базы данных принимает администратор базы.
Для облегчения процедуры активации или ее автоматизации, начиная с версии Oracle9i, в Data Guard можно
использовать дополнительные процессы, называемые Data Guard Broker (dgbroker) и Data Guard Monitor (DMON).
Они запускаются на экземплярах рабочей и резервных баз и автоматизируют процессы
активации резервной базы, передачи недостающих журналов и перезапуска
экземпляров, где произошел сбой. Эти процессы могут быть запущены на любом из
экземпляров, обслуживающих базы данных. Архитектура работы этих процессов схожа
с менеджером процессов OPMN и
DMON, которые используются в сервере
приложений Oracle9i AS. Процесс DMON
использует собственный файл, где сохраняет полезную для себя информацию,
которую нежелательно терять при остановке экземпляра (например, сведения о том,
какие базы в сети основные, а какие - резервные). Например, в случае остановки
основной базы и последующего монтирования процессы автоматически откроют
основную базу. Если администратор предполагает выполнить какие-то действия в
режиме монтирования, они скорее всего будут выполняться на открытой базе.
Положительная черта этих процессов в том, что их можно безбоязненно отключить в
любой момент даже без остановки экземпляра. Оболочки администрирования Data Guard требуют их работы и при необходимости запускают
процессы.
Администраторы часто сталкиваются с тем, что в базу внесены ошибочные
изменения и необходимо восстановить данные на определенный момент времени в
прошлом. В СУБД Oracle
предусмотрена возможность указать в запросе время, на которое требуются данные.
Эта возможность появилась в версии 9i и называется Oracle Flashback. Однако если таблица с данными
удалена полностью, то воспользоваться этой возможностью нельзя. Для таких
случаев администратор может указать для одной из резервных баз данных задержку,
с которой нужно вносить в нее изменения из полученных журналов (рис. 4).
Рис. 4. Резервная база с отставанием по времени.
В процессе работы резервная база данных не может обслуживать
пользователей. Однако желание включить ее в повседневную работу остается.
Резервная база может обслуживать запросы пользователей в те моменты, когда она
не вносит в свои файлы изменений. При этом журнальные файлы будут накапливаться
на компьютере с резервной базой, и их можно будет ввести в файлы позже.
Например, днем резервная база может быть открыта для чтения и обслуживать
запросы, для которых актуальность информации не важна. Это могут быть
приложения, обрабатывающие данные за прошлые дни, - например, системы поддержки
принятия решений (decision
support system), которые создают большую нагрузку на рабочую базу
данных. При этом резервная база данных будет принимать все журналы,
сгенерированные рабочей базой в течение дня. На ночь же администратор может
перевести резервную базу данных в режим внесения накопленных изменений.
В качестве альтернативы можно использовать логическую резервную базу
данных. Такая возможность появилась в версии Oracle 9.2, и ее можно использовать одновременно с
традиционными физическими резервными базами. Администратор сам выбирает,
сколько и каких резервных баз должно быть. Журнальная информация содержит все
сведения о том, какие изменения были внесены в рабочую базу данных. В версии 8i появилась возможность анализировать
журнальные файлы и воссоздавать часть команд, которые выполнялись
пользователями при работе с основной базой данных. Доработав эту технологию и
добившись восстановления большей части команд, компания Oracle смогла предложить новую технику
логического резервирования. Если в физической резервной базе из журнальных
данных выбирается информация об изменениях, внесенных напрямую в файлы данных -
на физическом уровне, то в логической резервной базе реконструируются команды SQL, при помощи которых эти изменения
были внесены (команды, которые выдавали пользователи при операциях с рабочей
базой). Восстановив поток команд, можно повторно ввести их уже в резервную
базу. Изменения вносятся не на физическом уровне, а на логическом - на уровне
таблиц. При этом физическая структура файлов резервной базы может отличаться от
той, что существует в рабочей базе. Достаточно лишь, чтобы существовали объекты
с теми же именами, которые есть в рабочей базе.
Выдавать команды SQL,
восстановленные из журналов, можно из базы, открытой для работы пользователей.
Необходимо только позаботиться о том, чтобы пользователи не конфликтовали с
процессами, вносящими изменения. Самое простое решение - не давать возможности
пользователям, работающим с резервной базой, менять в ней данные. Таким
образом, пользователи могут работать с логической резервной базой в режиме
чтения.
Используя логические резервные базы данных, нужно иметь в виду
особенности их работы. Восстановление команд SQL и внесение изменений в базу требуют дополнительных
процессорных ресурсов. Эти процессы некоторым образом повторяют все транзакции,
прошедшие на рабочей базе. Чтобы ускорить внесение изменений, на резервной базе
создается пул процессов, которые вносят изменения. Он называется Log Apply Services и состоит из процессов LSPn - координаторов и PX (parallel execution), которые восстанавливают команды SQL и вносят изменения. Эти процессы не
восстанавливают команд, не меняющих данные (например, SELECT), так как в журнал изменений они не записываются.
Обычно именно команды SELECT
создают основную нагрузку на процессор компьютера с основной базой.
Вторая особенность работы логической резервной базы в том, что по
журналам сложно восстановить логические команды, которые вносили изменения в
основную базу. Для того, чтобы резервная база могла это делать, нужно, чтобы в
журнал изменений добавлялась дополнительная информация. Для команд, меняющих
данные в таблицах (INSERT, UPDATE, DELETE, MERGE),
нужно сохранять значение первичного или уникального ключа. Из-за этого объем
журнальной информации возрастает. Если у основной базы каналы записи в файлы
журналов загружены, производительность ее снизится. Логическая резервная база
может использоваться, если объемы изменений основной базы невелики или
ВВЕДЕНИЕ Дипломная (ВКР). Информационное обеспечение, программирование.
Контрольная работа: Научно-технические средства, применяемые при производстве следственных действий. Скачать бесплатно и без регистрации
Контрольная Работа Деление На Однозначное Число
Реферат по теме Психодиагностика профессионально важных свойств и деловых качеств
Итоги Регионального Этапа Конкурса Сочинений 2022
Реферат по теме Закон безусловной условности знания
Реферат по теме Маркировка товаров
Реферат по теме Угрозы психологической безопасности субъекта образовательного процесса
Курсовая работа по теме Защита от средств слежения за автомобилями
Реферат: Международное разделение труда материальная основа развития мирового хозяйства начала 21 века 2
Заказать Отчет По Преддипломной Практике Туито
Реферат по теме Новые гипотезы о романских бронзовых воротах Софийского кафедрального собора в Новгороде
Реферат На Тему Математика И Медицина
Реферат: Особенности развития бытовой химии лакокрасочной промышленности Красноярского края. Скачать бесплатно и без регистрации
Дипломная работа по теме Техническая характеристика оборудования на Марганецком ГОКе
Реферат по теме О роли эксперимента в разработке научных гипотез происхождения жизни
Влияние Автомобильного Транспорта На Окружающую Среду Реферат
Описание Сочинения Рожь
Основные Этапы Истории Развития Анатомии Животных Реферат
Курсовая работа по теме Современные подходы к организации работы СМИ
Реферат Воинские Звания Военнослужащих Вооруженных Сил Рф
Шпаргалка: 38 вопросов по философии
Реферат: Mortal Pursuit Essay Research Paper Trish Robinson
Похожие работы на - Планирование и финансирование мероприятий по охране труда