Организация и методы резервирования данных в СУБД Oracle

МИНИСТЕРСТВО ПРОСВЕЩЕНИЯ

ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ МОЛДОВЫ

ФИЗИЧЕСКИЙ ФАКУЛЬТЕТ

КАФЕДРА ПРИКЛАДНОЙ ФИЗИКИ И ИНФОРМАТИКИ

ДИПЛОМНАЯ РАБОТА

Организация и методы резервирования данных в СУБД ORACLE

Мастеранд 2 курса

сп. информац. технологии

Научный руководитель:

Старший преподаватель

Чобу Виктор

Кишинёв - 2013

ОГЛАВЛЕНИЕ

Введение

Глава 1. Резервные данные. Схемы Ротации

.1 Резервное копирование

.2 Архивирование

.3 Схемы ротации

.4 Копирование СУБД и пользовательских файлов

Глава 2. Oracle Data Guard

.1 Резервные базы данных под управлением Oracle Data Guard

.2 Резервная база данных

.3 Создание физической резервной базы

.4 Передача журнальных записей

.5 Процессы Oracle Data Guard

.6 Логическая резервная база

Глава 3. Защита резервных копий баз данных и базы данных разработчиков

3.1 Защита баз данных Oracle

.2 Резервные копии на ленте

.3 Резервные копии на диске

.4 Базы данных для работы в непредвиденных обстоятельствах

Глава 4. Клонирование БД на локальном и удаленном компьютере с использованием пользовательской резервной копии

4.1 Создание резервной копии методом “холодного” копирования

.2 Восстановление базы данных на удаленной машине

.2.1 С сохранением структуры каталогов

.2.2 В измененной структуре каталогов

.2.3 Восстановление при отсутствии части необходимых файлов

.3 Восстановление базы данных на локальной машине

.4 Создание резервной копии методом “горячего” копирования

.5 Восстановление базы данных из «горячей» копии

Глава 5. Резервирование и восстановление

.1 Планирование восстановления экземпляра

.2 Планирование восстановления носителя

.2.1 Стратегия резервирования

.2.2 Стратегия восстановления

Глава 6. Практическая часть

ЗАКЛЮЧЕНИЕ

Литература

ВВЕДЕНИЕ

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

Несмотря на такие особенности, тема резервного копирования и архивирования всегда вызывала и вызывает повышенный интерес. Многие прекрасно понимают, что рано или поздно этими вопросами все равно придется заниматься всерьез.

Огромное число организаций сталкивается с годовым ростом данных, превышающим 50%. Около 70% конечных пользователей хранят свою информацию на файловых серверах, и эта информация занимает от 50% до 70% емкости в более чем 40% организаций. С такими потребностями в хранении, что могут сделать ИТ администраторы?

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

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

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

Глава 1. Резервные данные. Схемы ротации

1.1 Резервное копирование

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

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

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

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

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

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

.2 Архивирование

Под архивным копированием обычно понимают процесс создания копий файлов, предназначенных для бессрочного или долговременного хранения. Это процесс получения "слепка" файлов и каталогов в том виде, в котором они располагаются на первичном носителе (обычно диске) в данный момент времени. Носители, на которые переносятся данные, называют архивными. Периодическое проведение архивного копирования позволит иметь копии нескольких разных версий одних и тех же файлов. Впрочем, особо важные файлы иногда помещают в архив независимо от времени их последней модификации. Обычно считается, что для надежности хранения нужно иметь 2-3 архивные копии всех редакций файлов, подлежащих архивированию.

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

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

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

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

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

1.3 Схемы ротации

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

Схема "дед-отец-сын" имеет иерархическую структуру и предполагает использование комплекта из трех наборов носителей. Раз в неделю делается полная копия дисков компьютера, ежедневно же проводится инкрементальное (или дифференциальное) копирование. Дополнительно раз в месяц проводится еще одно полное копирование. Набор для ежедневного инкрементального копирования называется "сыном", для еженедельного - "отцом", для ежемесячного - "дедом". Состав ежедневного и еженедельного набора постоянен. В ежедневном наборе свой носитель (их может быть несколько, если объем информации превышает объем одного носителя) закреплен за каждым рабочим днем (кроме пятницы), а в случае еженедельного набора - за каждой неделей месяца по порядку (т. е. данный набор должен содержать не менее четырех носителей). Ежемесячные носители обычно заново не используются и откладываются в архив. Таким образом, по сравнению с простой ротацией в архиве содержатся только ежемесячные копии плюс последние еженедельные и ежедневные копии. Недостаток данной схемы состоит в том, что в архив попадают только данные, имевшиеся на конец месяца. Как и при схеме простой ротации, носители для ежедневных копий подвергаются значительному износу, в то время как нагрузка на еженедельные копии сравнительно невелика.

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

Еще одна схема ротации называется "10 наборов" и, как следует из названия, рассчитана на десять наборов носителей. Период из сорока недель делится на десять циклов. В течение цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла номер набора сдвигается на один день. Иными словами, если в первом цикле за понедельник отвечал набор номер 1, а за вторник - номер 2, то во втором цикле за понедельник отвечает набор номер 2, а за вторник - номер 3. Такая схема позволяет равномерно распределить нагрузку, а следовательно, и износ между всеми носителями.

Таблица 1. Схема ротации "Ханойская башня".

1.4 Копирование СУБД и пользовательских файлов

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

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

. одну или несколько баз данных;

. систему управления базами данных (СУБД);

. персонал, обеспечивающий работу банка данных.

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

Проблемы могут возникнуть и при резервировании и архивировании баз данных. Резервирование базы данных лучше всего проводить в "холодном" виде, когда перед резервированием БД закрывается. Такое резервирование лучше всего выполнять в ночное время, когда пользователей можно отключать от базы. Однако во многих случаях этот вариант неприемлем. Во-первых, базы данных сейчас нередко достигают в объеме сотен и тысяч гигабайт, поэтому их копирование требует слишком много времени, и даже ночи для этого не хватит. Блокировать же доступ к базе на длительное время могут позволить себе немногие. Во-вторых, нередко СУБД работают в режиме on-line (например, на серверах Internet), и отключение их в принципе невозможно.

Чтобы нивелировать проблемы копирования баз данных, производители систем резервирования поставляют специальные агенты для конкретных СУБД. Большинство агентов рассчитано на поддержку таких СУБД, как Oracle, Informix, Sybase. В свою очередь разработчики мощных СУБД снабжают свои продукты программными интерфейсами резервирования или даже отдельными утилитами резервирования. К сожалению, распространенные системы резервирования поддерживают ограниченное количество основных СУБД ввиду экзотичности остальных (в смысле узости рынка). К сожалению, сами производители СУБД не очень-то стремятся восполнить данный пробел. К тому же огромное количество сетевых приложений опирается на собственные базы данных, найти для них агенты резервирования также может оказаться непросто.

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

Глава 2. ORACLE DATA GUARD

.1 Резервные базы данных под управлением Oracle Data Guard

После того, как база данных наполнена информацией, у администраторов баз данных (DBA) возникает естественное желание защитить данные от потери, даже если это не предусматривалось изначально при построении информационной системы. Самый простой способ - периодически копировать файлы базы или выгружать данные из таблиц программными средствами. Эти методы относятся к "холодному" и логическому резервированию. Холодным оно называется, так как пользователи при этом не работают с базой данных и службы, через которые они работают, "погашены". Если резервирование нужно выполнять так, чтобы не создавалось препятствий работе пользователей, такой тип резервирования называется горячим. Для логического резервирования обычно используют утилиту экспорта информации, которая поставляется, например, в составе ПО компании Oracle (#"700633.files/image001.jpg">

2.2 Резервная база данных

Термин резервная база данных появился в ПО 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). Независимо от скорости сети, которая связывает оба компьютера, или сетевой задержки, накопленная информация будет передана.

2.4 Передача журнальных записей

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

Рис. 3. Архитектура передачи журналов.

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

2.5 Процессы Oracle Data Guard

Решение об активации резервной базы данных принимает администратор базы. Для облегчения процедуры активации или ее автоматизации, начиная с версии Oracle9i, в Data Guard можно использовать дополнительные процессы, называемые Data Guard Broker (dgbroker) и Data Guard Monitor (DMON). Они запускаются на экземплярах рабочей и резервных баз и автоматизируют процессы активации резервной базы, передачи недостающих журналов и перезапуска экземпляров, где произошел сбой. Эти процессы могут быть запущены на любом из экземпляров, обслуживающих базы данных. Архитектура работы этих процессов схожа с менеджером процессов OPMN и DMON, которые используются в сервере приложений Oracle9i AS. Процесс DMON использует собственный файл, где сохраняет полезную для себя информацию, которую нежелательно терять при остановке экземпляра (например, сведения о том, какие базы в сети основные, а какие - резервные). Например, в случае остановки основной базы и последующего монтирования процессы автоматически откроют основную базу. Если администратор предполагает выполнить какие-то действия в режиме монтирования, они скорее всего будут выполняться на открытой базе. Положительная черта этих процессов в том, что их можно безбоязненно отключить в любой момент даже без остановки экземпляра. Оболочки администрирования Data Guard требуют их работы и при необходимости запускают процессы.

Администраторы часто сталкиваются с тем, что в базу внесены ошибочные изменения и необходимо восстановить данные на определенный момент времени в прошлом. В СУБД Oracle предусмотрена возможность указать в запросе время, на которое требуются данные. Эта возможность появилась в версии 9i и называется Oracle Flashback. Однако если таблица с данными удалена полностью, то воспользоваться этой возможностью нельзя. Для таких случаев администратор может указать для одной из резервных баз данных задержку, с которой нужно вносить в нее изменения из полученных журналов (рис. 4).

Рис. 4. Резервная база с отставанием по времени.

2.6 Логическая резервная база

В процессе работы резервная база данных не может обслуживать пользователей. Однако желание включить ее в повседневную работу остается. Резервная база может обслуживать запросы пользователей в те моменты, когда она не вносит в свои файлы изменений. При этом журнальные файлы будут накапливаться на компьютере с резервной базой, и их можно будет ввести в файлы позже. Например, днем резервная база может быть открыта для чтения и обслуживать запросы, для которых актуальность информации не важна. Это могут быть приложения, обрабатывающие данные за прошлые дни, - например, системы поддержки принятия решений (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), нужно сохранять значение первичного или уникального ключа. Из-за этого объем журнальной информации возрастает. Если у основной базы каналы записи в файлы журналов загружены, производительность ее снизится. Логическая резервная база может использоваться, если объемы изменений основной базы невелики или если переключение пользователей, которые не вносят изменения, на работу с резервной базой сможет разгрузить основную базу.

Технология восстановления SQL-команд из журнала изменений легла в основу Oracle Streams, новой технологии перемещения изменений между базами (репликации). Изменения можно вносить только в часть таблиц, а резервная база слабо связана с основной. Можно настроить репликацию изменений, сделанных в основной базе, в любые другие. Эта идея была реализована начиная с версии 9i как альтернатива существовавшим ранее методам репликации. Преимущество Oracle Streams в том, что нагрузка на основную базу данных существенно ниже, чем при репликации другими методами, которые доступны в базах Oracle. В архитектуре Oracle Streams предусмотрена возможность выбирать информацию из журналов как основной базы, так и любой другой. Выборка данных из основной базы имеет то преимущество, что не требуется передавать большие объемы журнальной информации на удаленные компьютеры, загружая сеть.

В новой версии Oracle10g (рис. 5), которая вышла в начале этого года, в архитектуру резервных баз были внесены небольшие улучшения, в основном связанные со снятием ограничений на использование резервных баз и удобством их использования. Например, в 10g сброс последовательности нумерации журнальных файлов (resetlogs) не требует пересоздания резервных баз данных. Основные изменения коснулись оболочки администрирования - в частности, в 10g для управления базами данных используется Web-интерфейс.

Рис. 5. Data Guard Manager 10g.

Глава 3. Защита резервных копий баз данных и базы данных разработчиков

.1 Защита баз данных Oracle

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

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

Типы резервных копий Oracle

Существует три основных вида резервирования Oracle:

·        Экспорт: инструментальное средство Oracle exp используется для извлечения данных из базы данных в файл операционной системы. Формат файла нестандартный, понятный самой СУБД. Инструментальное средство Oracle imp вставляет данные назад в ту же самую или другую базу данных. Можно выполнять частичный или полный экспорт всей базы данных. В полный экспорт включаются хешированные пароли. Если целью является кража данных, то достаточно выполнить экспорт схемы владельца приложения.

·        Холодное резервирование может выполняться различными способами и с помощью инструментальных средств.Он может выполняться также на диск или ленту. Во время холодного резервирования база данных должна быть полностью остановлена.

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

Для проверки, включен ли режим ARCHIVELOG, можно в sqlplus выдать следующий запрос:

SQL> sho useris "DBSNMP"> select log_mode

from v$database;_MODE

-----------

NOARCHIVELOG

SQL>

Для проверки, выполняется ли в базе данных горячие или холодное резервирование, нужно провести небольшое исследование. Можно поискать в машине командные файлы резервирования, содержащие слова ALTER TABLESPACE [TABLESPACE NAME] BEGIN BACKUP. Проверить задания cron, дневные листинги процессов: не запускалось ли программное обеспечение, которое могло выполнять резервирование. Проверить протокольные файлы. Выяснить, программное обеспечение для резервирования установлено на машине, используя для этого pkginfo -l. Можно проверить статус табличных пространств, не переключались ли они в режим “OFFLINE”, что может быть хорошим признаком выполнения в данное время горячего резервирования.

SQL> select tablespace_name,status

from dba_tablespaces;_NAME STATUS

----------------------------- ---------ONLINEONLINEONLINEONLINE_REPOSITORY ONLINEONLINE_IND_1 OFFLINE_DATA_1 ONLINE

6 rows selected.

SQL>

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

3.2 Резервные копии на ленте

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

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

3.3 Резервные копии на диске

резервный база данные восстановление

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

Во многих случаях базы данных разработчиков и тестовые базы данных имеют копии всех промышленных данных, поскольку они требуются для системного тестирования и настройки производительности. Если требуются эти данные, очень часто достаточно одного дня для их извлечения из этих баз данных. Если необходимо найти базу данных разработчиков или тестовую базу данных: ее не загружают в ту же машину, в которой работает промышленная база данных. Необходимо выяснить в файлах tnsnames.ora и listener.ora SID базы данных, который похож на SID промышленной базы данных. Посмотреть в директории admin инсталляции Oracle файлы init.ora. Они имеют имена init[ORACLE_SID].ora.

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

3.4 Базы данных для работы в непредвиденных обстоятельствах

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

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

Глава 4. Клонирование БД на локальном и удаленном компьютере с использованием пользователльской резервной копии

.1       Создание резервной копии методом "холодного" копирования

Холодное (автономное) резервное копирование базы данных выполняется на уровне операционной системы при остановленной базе данных - резервируются файлы, составляющие базу данных Oracle: файлы данных, управляющие файлы, файл параметров. Если остановка базы данных была выполнена в режимах normal\immediate\transactional, то включать в резервную копию файлы оперативных журналов необязательно.

·        До начала процесса копирования следует выяснить основные параметры базы данных

database name>select name from v$database;name>select instance_name from v$instance;

В общем случае database name = instance name, но при создании клона базы данных на той же машине, что и исходная база, параметры instance name для исходной и клонированной баз должны быть различны.

версия> select banner from V$version

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

·        Файлы базы данных

файлы данных

SQL>select name,status from v$datafile_header;

темп-файлы> select v$tempfile.name, v$tablespace.name from v$tempfile ,$tablespace where v$tempfile.ts#= v$tablespace.ts#

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

журнальные файлы>select v$logfile.group#, v$logfile.member, v$log.status from v$logfile,$log where v$logfile.group#=v$log.group#;

Резервирование журнальных файлов при создании холодной копии необходимо в двух случаях: перед копированием файлов база данных была остановлена в несогласованном состоянии и ее открытие требует восстановление экземпляра; для клонированной базы не желателен сброс последовательности журнальных файлов.

архивные журнальные файлы

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

управляющий файл>select name from v$controlfile;

Резервирование управляющего файла можно проводить двумя способами: холодным копированием определенных запросом файлов или созданием резервной копии управляющего файла командой alter database backup controlfile - в последнем случае клонированная база данных потребует восстановление с дальнейшим сбросом последовательности журнальных файлов.

Резервирование управляющего файла в двоичный файл осуществляется командой

SQL>alter database backup controlfile to <имя файла-копии>;

SQL>alter database backup controlfile to trace;

Файл трассировки формируется в каталоге, указанном в параметре инициализации user_dump_dest (или при установке значения по умолчанию в - rdbms/trace)

файл параметров>select * from v$parameter2 where name in ('spfile', 'ifile');

Начиная с 9 версии Oracle в качестве файла параметров может использовать как текстовой файл, так и бинарный. По умолчанию, используемый файл расположен в директории <$oracle_home>\database (Windows) или <$oracle_home>/dbs ( linux) и имеет вид init<SID>.ora (текстовой) или spfile<SID>.ora (бинарный)

При использовании spfile для сохранения и редактирования списка параметров для клонированной базы удобно создать текстовой файл командой

SQL>create pfile=<имя файла> from spfile;

файл паролей.

При клонировании базы данных файл паролей следует пересоздать.
файлы net8.

Дополнительно имеет смысл сохранить директорию <$oracle_home> \network\admin, если предполагается создание клона на удаленной машине.

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

При установки базы данных с использованием Database Configuration Assistant автоматически генерируемая структура каталогов имеет вид

<$Oracle_base>\

admin\<$Oracle_sid>

oradata\<$Oracle_sid>

flash_recovery_area\<$Oracle_sid>

В этом случае удобнее резервировать не отдельные файлы, а полностью директории admin и oradata с их содержимым.

4.2     Восстановление базы данных на удаленной машине

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

4.2.1 С сохранением структуры каталогов

При инсталляции ПО параметр Oracle_home и пути к домашней директории Оракла должны соответствовать определенным на исходной машине.

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

·        background_dump_dest

·        core_dump_dest

·        user_dump_dest

·        audit_file_dest

·        log_archive_dest_<n>

·        log_archive_dest\log_archive_duplex_dest

·        db_recovery_file_dest

Предоставить права на эти каталоги пользователю, под учетной записью которого работает Оракл.

Далее следует разместить сохраненные файлы следующим образом: файлы данных, управляющие и журнальные файлы раскладываются по их изначальному местоположению на исходной машине. Файл параметров при необходимости переименовываем в init<SID>.ora и помещаем в директорию <$oracle_home>\database (<$oracle_home>/dbs).

Следующая последовательность действий зависит от используемой операционной системы

Windows

. устанавливаем переменную окружения oracle_sid

set oracle_sid=<SID>

где <SID> =< instance_name >

. создаем службу

<$oracle_home>\bin\oradim.exe -new -sid <SID> -intpwd <пароль пользователя sys\internal> -startmode manual

в результате в сервисах появится и стартует служба с именем OracleService<SID>, а в директории

<$oracle_home>/database сформируется файл паролей с именем pwd<SID>.ora

Unix

1.       устанавливаем переменную ORACLE_SID

ORACLE_SID=<SID>

export ORACLE_SID

.создаем файл паролей

<$oracle_home>/bin/orapwd file=<$oracle_home>/dbs/orapw<SID> password=<пароль пользователя sys\internal>

На этом этапе система готова к открытию базы данных.

Дальнейшие действия отличаются для разных версий Oracle.

Для версии 8 открытие базы осуществляется из командной строки программы <$oracle_home>\bin\svrmgrl

SVRMGRL> connect internal: <пароль пользователя internal>.>startupinstance started.

…mounted.opened.

Для 9-10 версии используется SQLPLUS- <$oracle_home>\bin\sqlplususer-name: sys as sysdba password: <пароль пользователя sys>

connected.> startup pfile='<$oracle_home>/dbs/init<SID>.ora';instance started.

…mounted. opened.

После открытия базы данных при наличии временных пространств, использующих tempfiles необходимо их создать командой

SQL>alter tablespace <ТП> add tempfile <путь и имя файла> size 500M

Последний этап - обеспечить пользовательский доступ к базе данных средствами Net8. Корректируются файлы tnsnames.ora и listener.ora из сохраненной директории <$oracle_home>/network/admin - в них необходимо изменить параметр host и после этого стартовать процесс прослушиватель : <$Oracle_home>\bin\lsnrctl

LSNRCTL>start

4.2.2 
В измененной структуре каталогов

·        Изменение каталога для файлов трассировки процессов и расположения архивных журналов осуществляется путем корректировки параметров файла init<SID>.ora

background_dump_dest_dump_dest_dump_dest_file_dest_archive_dest_<n>_archive_dest\log_archive_duplex_dest_recovery_file_dest

·        Изменение каталога расположения управляющих файлов осуществляется путем корректировки параметра файла init<SID>.ora control_files

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

- база данных монтируется, но не открывается

SQL>startup mount ;

- файлы данных и журнальные файлы средствами ОП раскладываются

- по новому местоположению и для каждого из них выполняется команда

SQL>alter database rename file <путь и имя файла> to <новый путь и имя файла>;

-- например: alter database rename file ‘d:\dbs\redo01.log‘ to ‘c:\oracle\redo01.log‘;

-- база открывается для общего доступа

SQL>alter database open;

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

·        Отсутствует файл параметров инициализации. Минимальный набор параметров для старта базы данных

control_files _name _block_size

в некоторых случаях необходимо указывать параметр compatible .

Значение остальных параметров берутся по умолчанию и в дальнейшем при необходимости могут быть скорректированы. Если значения параметров db_name и db_block_size не известны, можно поставить произвольные значения - при попытке старта Оракл обнаружит несоответствия этих параметров с указанными в управляющем файле и выдаст ошибку (на консоль или в alert.log) с указанием их истинных значений.

·        Отсутствуют журнальные файлы.

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

Последовательность команд, обеспечивающая открытие базы данных в режиме сброса журналов>startup mount;

…> recover database until cancel using backup controlfile;: change 4657702 generated at 11/26/2005 17:04:52 needed for thread 1: suggestion : D:\ORA9\RDBMS\ARC00008.001: change 4657702 for thread 1 is in sequence #8log: {<RET>=suggested | filename | AUTO | CANCEL}-- на предложение ввести командуrecovery cancelled.> alter database open resetlogs;altered.

·        Отсутствуют управляющие файлы.

В случае мультиплексирования журнальных файлов отсутствующий файл можно заменить любым из сохранившихся или удалить упоминания о нем из параметра инициализации control_files. Если же не сохранилась ни одна из текущих копий файла, можно использовать: backup-копию + последовательность команд из предыдущего пункта, ведущая к открытию в режиме resetlogs, либо применить скриптовое создание управляющего файла на основе скрипта, сгенерированного командой alter database backup controlfile to trace на исходной базе.

Общая структура SQL-конструкции для создания управляющего файла:

CREATE CONTROLFILE SET DATABASE TEST RESETLOGS NOARCHIVELOG50510012261 'Q:\REDO01.LOG' SIZE 100M,2 'Q:\REDO02.LOG' SIZE 100M,3 'Q:\REDO03.LOG' SIZE 100M

'Q:\SYSTEM01.DBF',

'Q:\UNDO1.DBF' SET CL8MSWIN1251;

Создание управляющего файла осуществляется в режиме nomount. В случае использования сгенерированного скрипта следует:

поменять параметр reuse на set в первой строке CREATE CONTROLFILE REUSE DATABASE

установить параметр resetlogs\noresetlogs в зависимости от того, присутствуют ли в резервной копии журнальные файлы и требуется ли сохранить последовательность их нумерации

тут же можно изменить местоположение файлов и удалить упоминания об отсутствующих файлах данных

В результате выполнения сценария CREATE CONTROLFILE заново создадутся управляющие файлы базы данных и сама база перейдет в состояние mount.

Далее, база данных открывается фразой

SQL>alter database open ;

или>alter database open resetlogs;

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

·        Отсутствует часть файлов данных, не принадлежащих табличному пространству system (sysaux)

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

SQL>startup mount;

…>alter database datafile 'путь и имя файла' offline drop;> alter database оpen;

4.3 Восстановление базы данных на локальной машине

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

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

SERVICE_NAME=<NEW_SID>_NAME=<NEW_SID>_NAME_SPACE =<NEW_SID>.

. устанавливаем переменную окружения oracle_sid

set oracle_sid=<NEW_SID>

. создаем службу

<$oracle_home>\bin\oradim.exe -new -sid <NEW_SID> -intpwd <пароль sys\internal> - startmode manual

в результате в сервисах появится и стартует служба с именем OracleService<NEW_SID>, а в директории <$oracle_home>/database сформируется файл паролей с именем pwd<NEW_SID>.ora

Unix.

. устанавливаем переменную ORACLE_SID_SID=<NEW_SID>ORACLE_SID

.создаем файл паролей

<$oracle_home>/bin/orapwd file=<$oracle_home>/dbs/orapw<NEW_SID> password=<пароль пользователя\internal>

·        Стартуем базу данных в режиме mount и осуществляем переименование файлов.

·        При необходимости создаем темп-файлы и открываем базу.

·        Добавляем в tnsnames.ora псевдоним для созданной базы. В случае необходимости корректируем файл listener.ora и перезапускаем процесс прослушивания: <$Oracle_home>\bin\lsnrctl

LSNRCTL>stop

LSNRCTL>start

4.4     Создание резервной копии методом «горячего» копирования

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

Если производственные потребности не позволяют прервать работу базы данных, то используется механизм выполнения резервирования базы данных в ходе ее использования - горячее резервное копирование (online backup). Метод «горячего» резервного копирования применяется только для баз данных, функционирующих в режиме archivelog. Копировать БД рекомендуется в период ее наименьшей нагрузки.

Перед началом резервирования следует определить табличные пространства базы данных и соответствующие им файлы.

SQL>select v$tablespace.name, v$datafile.name from v$tablespace, v$datafilev$tablespace.ts#=v$datafile.TS#;

Определенные таким образом табличные пространства на момент осуществления физического копирования их файлов данных должны быть переведены в режим «backup» командой

SQL> alter tablespace <tablespace> begin backup;

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

SQL> alter tablespace <tablespace> end backup;

При этом переводить табличный пространства в backup-режим можно как последовательно, так и одновременно.

Резервирование табличных пространств, находящихся в режиме offline и read only осуществляется без перевода их в режим «backup». Статус табличного пространства можно определить из представления dba_tablespaces.

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

SQL> alter database backup controlfile to <tarce\file_name>

и> alter system archive log current;

Для восстановления базы данных будут затребованы все архивные журнальные файлы, сформированные с момента перевода первого табличного пространства в режим «backup».

4.5     Восстановление базы данных из «горячей» копии

Процесс восстановления базы данных из «горячей» копии отличается тем, что перед открытием базы необходимо осуществить восстановление носителя c использованием резервной копии управляющего файла. Перед этим рекомендуется поместить необходимые архивные журнальные файлы в директорию log_archive_dest \log_archive_dest_1\db_recovery_file_dest

SQL> startup mount;> recover database until cancel using backup controlfile;

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

SQL> alter database open resetlogs;

Глава 5. Резервирование и восстановление

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

У любого бизнеса должна быть стратегия восстановления после катастроф, которые приводят к потере данных. В настоящее время только 45% компаний из списка крупнейших компаний мира имеют формальные стратегии для своей защиты от бедственной потери данных. Только 12% из этих стратегий рассматриваются на корпоративном уровне ("Calculating the Cost of Downtime" (вычисление стоимости времени простоя)). При разработке формальной стратегии АБД должны планировать потерю данных из-за неожиданных отказов, причинами которых могут быть аппаратные или программные сбои, человеческие ошибки, природные явления и т.д. Для каждого из таких возможных событий АБД должны иметь план действий. В некоторых случаях может потребоваться восстановление носителя, в других будет достаточно восстановления экземпляра. Для обеих этих ситуаций АБД должны иметь планы действий. Мы рассмотрим их в этом разделе ниже. В конце концов, администратор базы данных и системный администратор должны документировать среду базы данных и стратегии восстановления, чтобы при возникновении сбоя АБД мог диагностировать проблему и немедленно заняться ее решением.

5.1     Планирование восстановления экземпляра

Если в параметре FAST_START_MTTR_TARGET установлено слишком низкое значение, сервер базы данных будет писать на диск очень часто, и это может привести к снижению скорости работы системы. Поэтому этот параметр необходимо настраивать так, чтобы сервер не выполнял чрезмерное количество контрольных точек, но при этом время восстановления оставалось бы в приемлемых пределах. С этой целью в СУБД Oracle9i Release 2 введена новая консультативная справка по MTTR (MTTR Advisory). Эта справка позволяет экземпляру оценивать (в процентах) изменение количества записей на диск, которое могло бы произойти при других значениях в параметре FAST_START_MTTR_TARGET. Используя оценку, полученную при типичной рабочей нагрузке на экземпляр, вы можете определить влияние повышения или понижения значения в данном параметре. Значения консультативной справки по MTTR содержатся в представлении V$MTTR_TARGET_ADVICE. Это представление имеет пять строк, которые показывают предполагаемую дисковую активность при различных значениях в параметре FAST_START_MTTR_TARGET: текущее значение; приблизительно десятая часть текущего значения; приблизительно половина текущего значения; приблизительно полтора текущего значения и приблизительно двойное текущее значение. В Enterprise Manager можно получить графическое представление консультативной справки по MTTR (см. рис. 6).

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

Рис. 6. Консультативная справка по MTTR.

5.2     Планирование восстановления носителя

.2.1    Стратегия резервирования

Восстановление носителя требуется всегда, когда теряются данные. Наиболее общие причины потери данных: сбои носителя и человеческие ошибки. Для того чтобы можно было восстанавливать носитель, сервер базы данных должен функционировать в режиме ARCHIVELOG (архивирование журнала). Его легко включить с помощью оператора ALTER DATABASE. Затем АБД должны выбрать метод резервирования. В прошлом АБД писали свои собственные скрипты для резервирования базы данных. Сейчас делать это уже нецелесообразно, так как утилита Recovery Manager (диспетчер восстановления) лучше оснащена для управления резервированием. Утилита Recovery Manager имеет вариант с интерфейсом командной стоки, а также вариант с графическим интерфейсом, встроенным в Enterprise Manager. Утилита Recovery Manager позволяет пользователям специфицировать все их требования резервирования, например, полное оперативное резервирование базы данных на ленту, автономное резервирование всей базы данных на диск и т.п. Более того, использование средств планирования в Enterprise Manager позволяет запускать задания создания резервных копий в заданное время, как регулярно, так и по потребности. Хорошая практическая рекомендация: вместе с резервными копиями файлов данных базы данных создавать резервную копию управляющего файла. Резервную копию управляющего файла, как минимум, необходимо создавать при изменении структуры базы данных.

Для тех администраторов, которым требуются также файлы систем резервирования, корпорация Oracle инициировала, совместно с поставщиками систем управления носителями, программу решения проблем резервирования (Backup Solution Program,http://otn.oracle.com/deploy/availability). Участники этой программы - сторонние поставщики, инструментальные средства которых обеспечивают комплексное решение вопросов резервирования как системных файлов, так и файлов базы данных Oracle. Это лучше использования для управления резервированием двух отдельных инструментов, Recovery Manager или Enterprise Manager для файлов базы данных Oracle и отдельного инструмента для системных файлов.

Как обсуждалось ранее, журнальные файлы следует мультиплексировать. Это означает, что каждая журнальная группа будет иметь два журнальных файла или элемента. Настоятельно рекомендуется, чтобы задание создания резервных копий резервировало по крайней мере два элемента каждой журнальной группы. Это подчеркивает важность журнальных файлов, поскольку если во время восстановления возникнут проблемы с архивными журнальными файлами из-за их физического повреждения или человеческой ошибки, то полное восстановление базы данных будет невозможным, и это приведет к потере некоторых данных. Вероятность такого происшествия существенно уменьшается, если есть запасная резервная копия. Заметим, АБД не должны создавать резервную копию журнального файла, а затем резервировать ее еще один раз. Вместо этого они должны резервировать два зеркальных журнальных файла по отдельности, так чтобы в случае повреждения одного из них для восстановления был доступен второй журнальный файл. Если обе копии являются копиями одного и того же архивного журнального файла, то мы не защищаем себя от повреждений журнала.

5.2.2  Стратегия восстановления

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

·        Сбой носителя.

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

·        Человеческая ошибка.

Пользователи могут непредумышленно удалять данные или уничтожать таблицы. Хороший способ минимизации последствий таких ситуаций - предоставлять пользователям только такие привилегии базы данных, которые им безусловно необходимы. Но человеческие ошибки будут по-прежнему возникать и АБД должны быть готовы к работе над ними. Создание логических резервных копий или экспорт таблиц - хороший способ справляться со случайными уничтожениями таблиц. Ретроспективный запрос (Flashback Query), новое средство, введенное в СУБД Oracle9i, очень хорошо подходит для восстановления после случайных удалений или вставок. Последним средством, к которому можно прибегнуть, является копирование из резервной копии и восстановление всего табличного пространства, содержащее объекты, на которые подействовала человеческая ошибка. Существуют различные методы восстановления после человеческих ошибок, и все они должны быть протестированы.

·        Повреждение блоков данных.

Неисправная аппаратура или ошибка операционной системы могут быть причиной повреждения блоков данных, в результате которого их формат не будет распознаваться СУБД Oracle или их содержимое будет внутренне несогласованным. В СУБД Oracle имеется средство восстановления носителя на уровне блоков (Block Media Recovery), которое копирует и восстанавливает только поврежденные блоки, и не требует восстановления всего файла данных. Это уменьшает среднее время восстановления (MTTR, Mean Time to Recovery), так как копируются и восстанавливаются только те блоки, которые требуется восстановить, а испорченные файлы данных остаются в оперативном режиме.

·        Стихийные бедствия.

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

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

Глава 6. Практическая часть

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

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

1.       создание специального скрипт-файла, при запуске которого будет создаваться файл-архив содержащий:

·        копию рабочей схемы базы данных (объект базы данных содержащий данные пользователя);

·        резервную копию программного кода базы данных из всех задействованных схем;

·        копию всех шаблонов печатных форм и отчетов;

2.       Включение в рабочий режим функций базы Oracle по созданию журналов всех транзакций (операций с данными) для обеспечения возможности восстановления состояния данных на любой момент времени, а не только на момент создания резервной копии (т.н. Archive Logs).

3.       Настройку Планировщика Заданий Windows (или другой аналогичной программы) на автоматическое выполнение скрипт-файла, по определенному расписанию.

В процессе выполнения мною дипломной работы было выполнено следующее - установлена и настроена СУБД Oracle версии 10g. Создана точная копия тестового сервера и проверена на работоспособность (здесь включен импорт всех необходимых схем), была настроена ее архивация несколькими методами, которые дальше будут продемонстрированы.

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

1)      Метод ведения архивации с помощью встроенных функций в СУБД ORACLE. Команды exp и imp (что есть «export» и «import»)

В следующем примере формируется файл, с расширением *.dmp.

Файл archive_db.bat содержит следующий скрипт:

chcp 1251

rem удаление *.log файлов

del *.log

rem логин/пароль@сервер скрипт очистки ZTEMP

sqlplusw schema_name/schemas_name@name_db @clearztemp логин/пароль@сервер         название схемы лог файл *.dmp файл экспорта

exp 'sys/sys@name_db as sysdba' owner=schema log=log_name.log file=file_name.dmpОбязательные схем'sys/sys@name_db as sysdba' owner=un4pack log=un4pack.log file=exp_un4pack.dmp'sys/sys@name_db as sysdba' owner=un4public log=un4public.log file=exp_un4public.dmp                    путь сохранения архивов все *.dmp файлы все лог файлы путь к templates

rar a -agddmmyy_HHMM D:\archiv_db\Back_up\schema_name_ *.dmp *.log D:\Share\templates.oraудаление *.dmp файлов*.dmp

Дополнительно, в папку с этим файлом можно поместить ДОСовский rar (архиватор) и указать в скрипте все файлы для сжатия и помещения их в архив, для экономии места на дисках.

Импорт данных выполняется в несколько этапов.

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

·        Скрипт на создание схемы.

create_script_user.bat Создает скрипт для генерации юзера (схемы) user.sql,

rem и вклеивает в него само имя юзера (схемы).

del user.sqlTRUNCATE TABLE %1.tparams DROP STORAGE; >> user.sqlDROP USER %1 CASCADE ; >> user.sqlCREATE USER %1 IDENTIFIED BY "%1" >> user.sqlDEFAULT TABLESPACE TBSun4_TABLES >> user.sqlTEMPORARY TABLESPACE TBSun4_TEMP >> user.sqlPROFILE DEFAULT; >> user.sqlGRANT ALTER ANY INDEX TO %1; >> user.sqlGRANT CREATE ANY TABLE TO %1 WITH ADMIN OPTION; >> user.sqlGRANT drop ANY TABLE TO %1 WITH ADMIN OPTION; >> user.sqlGRANT EXECUTE ANY PROCEDURE TO %1 WITH ADMIN OPTION; >> user.sqlGRANT EXECUTE ANY TYPE TO %1 WITH ADMIN OPTION; >> user.sqlGRANT QUERY REWRITE TO %1 WITH ADMIN OPTION; >> user.sqlGRANT UNLIMITED TABLESPACE TO %1 WITH ADMIN OPTION; >> user.sqlGRANT CONNECT TO %1 WITH ADMIN OPTION; >> user.sqlGRANT RESOURCE TO %1 WITH ADMIN OPTION; >> user.sqlALTER USER %1 DEFAULT ROLE CONNECT, >> user.sqlRESOURCE; >> user.sqlGRANT SELECT ON SYS.V_$SESSION TO %1; >> user.sqlGRANT SELECT ON SYS.V_$TRANSACTION TO %1; >> user.sqlGRANT SELECT ON DBA_OBJECTS TO %1; >> user.sqlGRANT SELECT ON DBA_policies TO %1; >> user.sqlstasGRANT CREATE ANY VIEW TO UN4PUBLIC; >> user.sqlGRANT DROP ANY VIEW TO UN4PUBLIC; >> user.sqlend stasGRANT EXECUTE ON SYS.DBMS_ALERT TO %1; >> user.sqlGRANT EXECUTE ON SYS.dbms_rls TO %1; >> user.sqlGRANT SELECT ON SYS.V_$LOCK TO %1; >> user.sqlGRANT ALTER SYSTEM TO %1; >> user.sqlrem GRANT SELECT ANY table TO %1 ; >> user.sqlGRANT EXP_FULL_DATABASE TO %1 ; >> user.sqlGRANT IMP_FULL_DATABASE TO %1 ; >> user.sqlGRANT EXECUTE ON SYS.DBMS_PIPE TO %1 ; >> user.sqlALTER TABLESPACE TBSun4_TABLES coalesce; >> user.sqlALTER TABLESPACE TBSun4_TEMP coalesce; >> user.sqlALTER TABLESPACE TBSun4_SYSTABLES coalesce; >> user.sqlALTER TABLESPACE TBSun4_IND coalesce; >> user.sqlALTER TABLESPACE TBSun4_cm coalesce; >> user.sqlALTER TABLESPACE system coalesce; >> user.sqlecho ALTER TABLESPACE indx coalesce; >> user.sqlecho ALTER TABLESPACE rbs coalesce; >> user.sqlexit ; >> user.sql

·   Скрипт на создание объектов схемы.

create_dat_obj.bat

rem Создает файл параметров obj1.dat,

rem (набор параметров для утилиты IMP - чтоб не задавать в коммандной строке)

rem и вклеивает в него имена новой и старой схемы.

del obj1.datecho FILE=expancfm.dmp >> obj1.datecho LOG=imp_log.txt >> obj1.datgrants=y >> obj1.datTOUSER=%1 >> obj1.datFROMUSER=%2 >> obj1.datIGNORE=Y >> obj1.datFEEDBACK=1000 >> obj1.datanalyze=n >> obj1.datTOID_NOVALIDATE=(%1.UN$FANEX,%1.UN$PASAPORT,%1.UN$AFX$GRUPUZINT,%1.UN$CM,%1.UN$PRICE,%1.UN$SRNRDT,%1.UN$SUMA,%1.UN$SZ$CONTRACTRES,%1.UN$SZ$CONTRBRIG,%1.UN$SZ$CONTRCAMPS,%1.UN$SZ$CONTRDIST,%1.UN$SZ$SOFERS,%1.UNT$AFX$GRUPUZINT,%1.UNT$FANEX,%1.UNT$SZ$CONTRBRIG,%1.UNT$SZ$CONTRCAMPS,%1.UNT$SZ$CONTRDIST,%1.UNT$SZ$SOFERS) >> obj1.dat

·   Скрипт, содержащий настройки последовательного выполнения импорта схемы.

imp1.bat

del *.log

rem Создать скрипт для создания нового юзера (схемы) user.sql

call create_script_user.bat %2 Создать файл параметров obj1.dat.

call create_dat_obj.bat %2 %3 запустить скрипт создания нового юзера

sqlplus sys/sys@%1 as sysdba @"user.sql" запустить скрипт создания типов для данной схемы

sqlplusw %2/%2@%1 @"all_objct.sql"

rem запустить утилиту экспорта IMP

rem админ/пароль@сервер    журнал                файл архива из которого импортировать

rem IMP system/sys@%1       log=implog.log parfile=obj1.DATsystem/sys@%1          log=implog.log parfile=obj1.DAT

·   Два файла user.sql и all_objct.sql, в которых содержится скрипт на создание схемы и объектов схемы.

user.sqlTABLE Dina.tparams DROP STORAGE;USER Dina CASCADE ;USER Dina IDENTIFIED BY "Dina"TABLESPACE TBSun4_TABLESTABLESPACE TBSun4_TEMPDEFAULT;ALTER ANY INDEX TO Dina;CREATE ANY TABLE TO Dina WITH ADMIN OPTION;drop ANY TABLE TO Dina WITH ADMIN OPTION;EXECUTE ANY PROCEDURE TO Dina WITH ADMIN OPTION;EXECUTE ANY TYPE TO Dina WITH ADMIN OPTION;QUERY REWRITE TO Dina WITH ADMIN OPTION;UNLIMITED TABLESPACE TO Dina WITH ADMIN OPTION;CONNECT TO Dina WITH ADMIN OPTION;RESOURCE TO Dina WITH ADMIN OPTION;USER Dina DEFAULT ROLE CONNECT,;SELECT ON SYS.V_$SESSION TO Dina;SELECT ON SYS.V_$TRANSACTION TO Dina;SELECT ON DBA_OBJECTS TO Dina;SELECT ON DBA_policies TO Dina;CREATE ANY VIEW TO UN4PUBLIC;DROP ANY VIEW TO UN4PUBLIC;EXECUTE ON SYS.DBMS_ALERT TO Dina;EXECUTE ON SYS.dbms_rls TO Dina;SELECT ON SYS.V_$LOCK TO Dina;ALTER SYSTEM TO Dina;GRANT SELECT ANY table TO Dina ;EXP_FULL_DATABASE TO Dina ;IMP_FULL_DATABASE TO Dina ;EXECUTE ON SYS.DBMS_PIPE TO Dina ;TABLESPACE TBSun4_TABLES coalesce;TABLESPACE TBSun4_TEMP coalesce;TABLESPACE TBSun4_SYSTABLES coalesce;TABLESPACE TBSun4_IND coalesce;TABLESPACE TBSun4_cm coalesce;TABLESPACE system coalesce;;

Скрипт all_objct.sql:OR REPLACE TYPE "UN$AFX$GRUPUZINT" AS OBJECT

( GR3 NUMBER (10) ,NUMBER (1,3)

);

/OR REPLACE TYPE "UN$SUMA" AS OBJECT

);

/OR REPLACE TYPE "UN$CM" AS OBJECT (CHAR(1) ,NUMBER(4),NUMBER(4),NUMBER(10),NUMBER(10),NUMBER(10),NUMBER(15),VARCHAR2(15),NUMBER(4),NUMBER,UN$SUMA

);

/OR REPLACE TYPE "UN$FANEX" AS OBJECT (NUMBER(2),VARCHAR2(10),VARCHAR2(50),DATE

);

/TYPE UN$PASAPORT AS OBJECT (VARCHAR2 (30),VARCHAR2 (30),VARCHAR2 (30),_NASTERII DATE,VARCHAR2 (25),VARCHAR2 (25),DATE,VARCHAR2 (100)

);

/OR REPLACE TYPE "UN$PRICE" AS OBJECT

( ID NUMBER(10),NUMBER(3),NUMBER(3,3)

);

/OR REPLACE TYPE "UN$SRNRDT" AS OBJECT

( SERIA VARCHAR2(10),VARCHAR2(50),DATE

);

/OR REPLACE TYPE "UN$SZ$CONTRACTRES" AS OBJECT

( db DATE,DATE,VARCHAR2(7),NUMBER(15,4)

);

/OR REPLACE TYPE "UN$SZ$CONTRBRIG" AS OBJECT

( brigid VARCHAR2(10),NUMBER (15,4)

);

/OR REPLACE TYPE "UN$SZ$CONTRCAMPS" AS OBJECT

( ID VARCHAR2(10), -- cod campuluiNUMBER (15,4), -- distantaVARCHAR2(20), -- denumirea camp_ha NUMBER (15,2), -- Suprafata contractata, ha_ha NUMBER (15,2), -- Suprafata reala, ha_ha NUMBER (15,2), -- Suprafata sfeclei de zahar contractata, ha_ha NUMBER (15,2), -- Suprafata sfeclei de zahar reala, haUN$SZ$contrActRes, cp02 UN$SZ$contrActRes, cp03 UN$SZ$contrActRes, cp04 UN$SZ$contrActRes, cp05 UN$SZ$contrActRes, cp06 UN$SZ$contrActRes, cp07 UN$SZ$contrActRes, cp08 UN$SZ$contrActRes, cp09 UN$SZ$contrActRes, cp10 UN$SZ$contrActRes,UN$SZ$contrActRes, cp12 UN$SZ$contrActRes, cp13 UN$SZ$contrActRes, cp14 UN$SZ$contrActRes, cp15 UN$SZ$contrActRes, cp16 UN$SZ$contrActRes, cp17 UN$SZ$contrActRes, cp18 UN$SZ$contrActRes, cp19 UN$SZ$contrActRes, cp20 UN$SZ$contrActRes,UN$SZ$contrActRes, cp22 UN$SZ$contrActRes, cp23 UN$SZ$contrActRes, cp24 UN$SZ$contrActRes, cp25 UN$SZ$contrActRes

);

/OR REPLACE TYPE "UN$SZ$CONTRDIST"OBJECT

( diststart NUMBER(10,2),NUMBER(10,2),NUMBER (15,4)

);

/OR REPLACE TYPE "UN$SZ$SOFERS"OBJECT

( Numele VARCHAR2(20),VARCHAR2(20),UN$PASAPORT

);

/OR REPLACE TYPE "UNT$AFX$GRUPUZINT" AS TABLE OF UN$AFX$GRUPUZINT ;

/OR REPLACE TYPE "UNT$FANEX" AS TABLE OF UN$FANEX ;

/OR REPLACE TYPE "UNT$SZ$CONTRBRIG" AS TABLE OF UN$SZ$contrbrig ;

/OR REPLACE TYPE "UNT$SZ$CONTRCAMPS" AS TABLE OF UN$SZ$contrCamps ;

/OR REPLACE TYPE "UNT$SZ$CONTRDIST" AS TABLE OF UN$SZ$contrdist ;

/OR REPLACE TYPE "UNT$SZ$SOFERS" AS TABLE OF UN$SZ$SOFERs ;

/;

·   Файл запуска импорта

run.bat1251 сервер        новая схема         старая схема(expdat.dmp)

imp1 name_db     schema                schema

rem Создаются все необходимые типы - all_objct.sql.

2)      Начиная с версии Oracle 10.2, появилась возможность использования директории DATA_PUMP_DIR для резервного копирования данных. Стало возможным экспортировать не только данные, но и структуру схем, ее объекты, а также возможность сделать полный архив всей базы в один общий файл. И в дальнейшем развернуть из этого файла точную копию на новом сервере БД.

Пример:1251nls_lang=AMERICAN_RUSSIA.CL8MSWIN1251удаление *.log файлов *.dmp файлов из data_pump/Q C:\oracle\product\10.2.0\admin\cricova\dpdumpлогин/пароль@сервер скрипт очистки ZTEMPname_schema/name_schema@name_db @clearztemp логин/пароль@сервер  название схемы лог файл *.dmp файл экспорта

expdp 'sys/sys@name_db as sysdba' DIRECTORY=DATA_PUMP_DIR DUMPFILE=dmp_name.dmp LOGFILE=log_name SCHEMAS=name_schema'sys/sys@name_db as sysdba' DIRECTORY=DATA_PUMP_DIR DUMPFILE=expdat_un4pack.dmp LOGFILE=log_un4pack SCHEMAS=un4pack'sys/sys@name_db as sysdba' DIRECTORY=DATA_PUMP_DIR DUMPFILE=expdat_un4public.dmp LOGFILE=log_un4public SCHEMAS=un4public копирование *.dmp файлов откуда куда

copy C:\oracle\product\10.2.0\admin\name_db\dpdump C:\Archive_dbудаление *.log файлов *.dmp файлов из data_pump/Q C:\oracle\product\10.2.0\admin\name_db\dpdump формирование архива  путь сохранения архивов все *.dmp файлы все лог файлы путь к templates

rar a -agddmmyy_HHMM C:\Archive_db\Back_up\arhiv_ *.dmp *.log C:\Shares\templates.ora удаление *.dmp файлов *.log файлов

del *.dmp *.log

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

ЛИТЕРАТУРА

1.       Скотт Урман, “Oracle8: Программирование на языке PL/SQL”

2.       Кевин Луни, Марлен Терьо “Oracle8: Настольная книга администратора”

3.       http://www.citforum.ru/database/oracle/prz/prosto.shtml#7

.        Том Кайт «Oracle для профессионалов.»

.        Джонатан Генник «Oracle SQL*Plus.

6.       http://www.sql-ex.ru/help/select0.php?Lang=0

7.       “Oracle Database 10g: Simplify Your Job with Automatic Storage Management”https://www.oracleworld2003.com/published/40140

.        T. Bednar. Database Backup and Recovery: Strategies and Best Practices.

.        S. Kumar. Server Manageability: DBA’s Mantra for a Good Night’s Sleep.

.        http://citforum.ru/database/oracle/oracleadm/