Информационные технологии, интернет, веб программирование, IT, Hi-Tech, …

Читайте, с помощью каких инструментов можно создать бэкап или восстановить утерянную базу Oracle Database . Рассмотрим как встроенные в базу инструменты так и сторонние приложения. Oracle Database хранит все файлы созданной базы в файлах данных. Часто, для восстановления данных определённой базы , достаточно восстановить её файлы данных и импортировать их в Oracle Database.

Структура базы данных Oracle Database

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

Итак, для сохранения, архивирования или бэкапа базы данных Oracle Database, копии именно указанных групп файлов следует создавать, а это:

• *.DBF – файлы данных, табличных пространств и управляющие файлы базы данных. Расположены:
  C:\oraclexe\app\oracle\oradata\XE
• *.ora – файлы конфигурации базы данных и файлы паролей.
  Файлы конфигурации:
  C:\oraclexe\app\oracle\product\11.2.0\server\dbs
  Файлы паролей (PW…ora):
  C:\oraclexe\app\oracle\product\11.2.0\server\database
• *.LOG – файлы журналов транзакций:
  C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG

где, ХЕ – это название базы данных в нашем случае.

Резервная копия базы данных Oracle Database

Резервную копию базы данных Oracle Database можно создать двумя способами:

• Архивации средствами операционной системы.
• Используя встроенные инструменты Oracle Application Express – Import / Export.

Архивация средствами операционной системы

Архивация средствами операционной системы подразумевает «ручное» копирование всех рабочих файлов базы данных, таких как:

• Файлы табличных пространств.
• Управляющие файлы.
• Файлы журналов транзакций.
• Файлы конфигурации.

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

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

Архивация и восстановление при помощи инструментов Export / Import

Архивацию и восстановление базы данных Oracle Database можно производить с помощью стандартных механизмов Экспорта и Импорта в Oracle. Для повышения надежности сохранности данных необходимо периодически, в зависимости от интенсивности работы с базой, производить полный экспорт. При достаточно интенсивном внесении изменений в данные, необходимо делать экспорт один раз в неделю.

Для этого:

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

Откройте Oracle Application Express и выберите меню Application Builder / Import

Выберите файл для импорта и укажите его тип



• Установите импортированную базу данных

  
  

Восстановление утерянной базы данных Oracle Database

В случае удаления или утери по какой-то из причин базы данных Oracle Database, её можно восстановить, восстановив файлы с помощью Hetman Partition Recovery и восстановить их способом, описанном в разделе «Архивация средствами операционной системы» .

Для этого:




Для примера, восстановления файлов базы данных описан процесс восстановления файлов *.DBF. Но учтите, что для восстановления всех данных работоспособной базы, также необходимо восстановить соответствующие *.ORA и *.LOG файлы.

Резервирование и восстановление базы данных с помощью Oracle Recovery Manager (RMAN)

Oracle Recovery Manager (RMAN) – это ещё один инструмент создания резервной копии базы данных Oracle Database. Отличается он от других инструментов тем, что с его помощью создаётся полная копия всей базы данных, а не только данных из неё. А также, что немаловажно, Oracle Recovery Manager совмещает в себе функциональность SQL Command Line одновременно освобождая пользователя от полной зависимости от её команд. Устанавливается данный инструмент на компьютер одновременно и вместе с установкой Oracle Database.

Чтобы создать резервную копию базы с помощью Oracle Recovery Manager (RMAN):




Чтобы восстановить базу данных из резервной копии базы с помощью Oracle Recovery Manager (RMAN):




К слову, в случае утери или удаления файла бэкапа базы данных Oracle Database, *.BKP файл бэкапа можно также восстановить с помощью Hetman Partition Recovery , после чего восстановить описанным выше способом в базе данных используя Oracle Recovery Manager (RMAN).

Здравствуйте, уважаемые читатели блога сайт! Представляю вашему вниманию статью о бэкапе и воссатновлении бд Oracle. Думаю, этот материал будет полезен для админов, выполняющих бэкапы и восстановление на сервере Оракл посредством Менеджера Восстановления (RMAN).

Бэкап и Восстановление

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

• Концепции реляционных баз данных и основы администрирования.
• Среда ОС, под которой запущена база Оракл.

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

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

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

Физические и Логические Бэкапы

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

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

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

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

Далее термин “бэкап” в данной статье о бэкапе и восстановлении будет означать прежде всего именно физические бэкапы (если не конкретизировано, о каких бэкапах идет речь), и сделать бэкап части или всей бд будет означать – сделать один из видов физического бэкапа. Акцент в статье делается в основном на физических бэкапах.

Ошибки и Сбои, требующие Восстановление из Бэкапа

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

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

Ошибки пользователей

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

Выход из строя носителей информации

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

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

Решения Oracle для Бэкапа и Восстановления: RMAN и Пользовательские Бэкапы

Для выполнения бэкапа и восстановления, основанных на физическом резервном копировании, в вашем распоряжении есть два решения:

• Менеджер Восстановления – инструмент (работает из командной строки, либо из графического интерфейса Enterprise Manager), который интегрируется с сессиями, запущенными на сервере Oracle для выполнения ряда действий, связанных с бэкапом и восстановлением, а также для поддержания хранения истории о ваших бэкапах
• Традиционный пользовательский бэкап и восстановление (т.е. осуществляемый и контролируемый самим пользователем), когда Вы напрямую управляете файлами, составляющими вашу бд, используя при этом команды ОС и возможности SQL*Plus, связанные с бэкапом и восстановлением

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

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

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

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

Бла, бла, бла. Всегда нужно делать бекапы, иначе будет как на картинке “Он дропнул базу и не делал бэкапы”.

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

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

Резервное копирование баз данных Oracle подразумевает создание резервных копий файлов данных, управляющих файлов и файлов архивных журналов. Вдобавок в состав запасного набора могут включать файлы spfile, init.ora, listener.ora и tnsnames.ora

Резервное копирование выполняеся:

• Средствами операционной системы.
• Средствами RMAN (Recovery Manager).

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

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

Режимы ARCHIVELOG и NOARCHIVELOG

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

• Режим архивирования журналов (ARCHIVELOG). В этом режиме Oracle сохраняет (архивирует) заполненные журналы повторного выполнения. Следовательно, на сколько давно бы не выполнялось резервное копирование, если используется режим ARCHIVELOG, базу данных всегда можно будет восстановить до любой точки во времени с помощью архивных журналов.
• Режим без архивирования журналов (NOARCHIVELOG). В этом режиме заполненные журналы повторного выполнения перезаписываются, а не сохраняются. Это, следовательно, означает, что в случае использования режима NOARCHIVELOG выполнять восстановление можно будет только из резервной копии и что все остальные изменения, которые были внесены в базу данных после выполнения резервного копирования, будут утрачиваться. Этот режим обеспечивает возможность выполнения восстановления только после отказа экземляра базы данных. В случае возникновения неполадок с носителем (например, потеря диска), функционирующую в режиме NOARCHIVELOG базу данных можно будет восстановить только из резервной копии и, естественно, с потерей всех изменений, которые были внесены в нее после создания этой резервной копии.

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

Резервное копирование всей или части базы данных

Подвергать резервному копированию можно как всю базу данных так и только ее часть, вроде входящего в ее состав табличного пространства или файла данных. Обратите внимание, что в случае, когда база данных функционирует в режиме NOARCHIVELOG, осуществлять резервное копирование лишь части базы данных, также называемое частичным резервным копированием (partial database backup), нельзя, если только все те табличные пространства и файлы, которые подлежат резервному копированию, не явлются доступными только для чтения. Выполнять резервное копирование всей базы данных, также называемое полным резервным копированием (whole database backup), можно как в режиме ARCHIVELOG, так и в режиме NOARCHIVELOG.

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

Согласованное (consistent) и несогласованное (inconsistent) резервное копирование

Согласованное резервное копирование (consistent backup) приводит к созданию согласованных резервных копий и не требует проводить процесс восстановления. При применении резервной копии для восстановления базы данных или ее части (например, табличного пространства или файла данных), сначала обычно требуется проветси восстановление данных из резервной копии (т.е. процедуру RESOTRE), а затем – восстановление работоспособности базы данных (т.е. процедуру RECOVER). В случае согласованного резервного копирования ни один из этих восстановительных шагов выполнять не требуется. В случае несогласованного резервного копирования (inconsistent backup) выполнение этих восстановительных шагов всегда является обязательным.

Oracle присваивает каждой транзакции уникальный системный номер изменения (System Change Number - SCN). Каждая фиксация, к примеру, будет проводить к увеличению этого номера. Всякий раз, когда Oracle устанавливает контрольную точку, все изменившиеся данные в оперативных файла данных записываются на диск. И всякий раз, когда это происходит. Oracle выполняет обновление контрольной точки потока (thread checkpoint) в управляющем файле. Во время этого обновления Orale делает так, чтобы все доступные для чтения и записи файлы данных и управляющие файлы согласовались с одним и тем же SCN-номером. База данных считается согласованной тогда, когда SCN-номера, хранимые в заголовках всех файлов данных, являются идентичными и совпадают с информацией о заголовках файлов данных, которая содержится в управляющих файлах. Главное запомнить, что один и тот же SCN-номер должен обязательно присутствовать во всех файлах данных и управляющем файле (или файлах). Пристутствие идентичного SCN- номера, означает, что в файлах данных содержатся данные за один и тот же промежуток времени. Если данные являются согласованными, никакие шаги по восстановлению после возврата (или копирования) набора фалов резервных копий на прежнее место не понадобятся.

Для создания согласованной резервной копии базы данных необходимо либо закрывать (обычной командой SHUTDOWN или SHUTDOWN TRANSACTIONAL, но не командой SHUTDOWN ABORT), либо останавливать (с помощью команды аккуратного завершения работы) и запускать снова в режиме монтирования.

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

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

Резервное копирование открытой и закрытой базы данных

Резервное копировние открытой базы данных (open backup), также называемое оперативным (online backup) или горячим резервным копировние (hot/warm backup), подразумевает создание резервных копий при открытой и доступной для пользователей базе данных. Выполнять оперативное резервное копирование всей базы данных (равно как и только принадлежащего ей табличного пространства или файла данных) можно только в том случае, если база данных функционирует в режиме ARCHIVELOG. Проводить его, когда база данных функционирует в режиме NOARCHIVELOG, нельзя.

Резервное копирование закрытой базы данных (closed backup), также называемое холодным резервным копированием (cold backup), подразумевает создание резервных копий при закрытой (остановленной) базе данных. Такое резервное копирование всегда приводит к созданию согласованных резервных копий, если только база данных не была остановлена командой SHUTDOWN ABORT.

Физическое и логическое резервное копирование

С технической точки зрения процедуры резервного копирования Oracle можно поделить на логические и физические. Под логическим резервным копированием (logical backup) подразумевается создание резервных копий с помощью утилиты Data Pump Export, которые содержат логические объекты наподобие таблиц и процедур. Эти резервные копии сохраняются в особом двоичном формате, и данные из них могу извлекаться только посредством утилиты Data Pump Import.

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

Уровни резервного копирования

Ниже перечислены уровни, на которых допускается выполнять резервное копирование баз данных Oracle:

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

Создать резервную копию данных базы oracle можно двумя способами:

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

У каждого из этих способов есть преимущества и недостатки. В случае создания резервной копии средствами операционной системы необходимо, что бы на всём протяжении процесса создания резервной копии экземпляр был остановлен во избежание рассогласования данных, что недопустимо в случае необходимости функционирования системы в режиме 24/7. Второй основной недостаток это сложность администрирования большого количества резервных и трудоёмкость их проверки на ошибки.

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

Встроенные утилиты базы данных для создания резервных копий – это прежде всего exp и expdp, позволяющие создавать логическую резервную копию (то есть копию объекта базы данных). Такой способ создания резервной копии прост, а основной его недостаток это время восстановления из копии в случае необходимости переустановки экземпляра и возможность восстановить объект только на конкретный момент осуществления бэкапа.

Самой же мощной, созданной компанией oracle специально для создания резервных копий баз данных, является утилита RMAN. Которая позволяет создавать полную копию базы данных без остановки экземпляра и восстанавливать её на любой момент в прошлом, сама следит за устаревшими копиями и удаляет их при необходимости, а так же проверяет их на наличие ошибок. Но при этом имеет серьёзный недостаток сложна в настройке и администрировании. Познакомимся поближе с настройкой и администрированием этой утилиты.

Утилита RMAN появилась в версии 8g и совершенствовалась в последующих. Настроим эту утилиту для регулярного создания резервных копий нашей базы данных.

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

• табличные пространства;
• управляющие файлы;
• журналы повторного выполнения;
• файлы данных (init.ora, spfile, tnsnames.ora, listener.ora, orapwd);

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

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

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

Select log_mode from v$database; от любого пользователя с правами sysdba. Если запрос вернул archivelog то всё в порядке переходим к следующему пункту, если noarchivelog то нужно перезапустить базу в режиме archivelog. Для этого нужно перезапустить базу в режиме mount командой:
startup mount immediate и выполнить команду
alter database archivelog; она активирует режим archivelog, после этого остаётся только открыть базу данных командой:
alter database open;

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

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

Select name, value from v$parameter where name like "db_recovery_file_dest%"; если не заданы то задаём командами:
alter system set db_recovery_file_dest_size=50G scope=both; задаёт максимальный размер области пакетного восстановления и
alter system set db_recovery_file_dest="/storage/recovery_area" scope=both; задаёт расположение области пакетного восстановления в файловой системе. Создание области пакетного восстановления необходимо для того что бы rman мог самостоятельно удалять устаревшие копии, а так же отслеживать оставшееся свободное дисковое пространство и предупреждать если его остаётся мало.

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

Rman connect target user/pass@sid выполняем команду
show all;

первым делом конфигурируем параметры сохранности резервных копий это делается либо параметром CONFIGURE RETENTION POLICY либо устанавливается количество копий которые одновременно хранятся, либо указывается период в который копия считается актуальной. Установим параметр recovery window равный 7 дням командой:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; включим автобэкап контрл файла при каждом создании резервной копии будет создаваться копия контрл файла:
CONFIGURE CONTROLFILE AUTOBACKUP ON; активируем оптимизацию что бы rman не создавал копии файлов уже существуют резервные копии идентичные существующей:
CONFIGURE BACKUP OPTIMIZATION ON; и распараллелим на 2 канала процесс создания резервной копии:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2; Параметры устройства на которое сохраняется информация, шифрования, сжатия, формат автобэкапа контрл файла и максимальный размер файла копии мы менять не будем.

После этой настройки остаётся только создать в операционной системе файлы выполнения для rman и добавить их в планировщик задач.

Для воскресения:

#!/bin/bash export ORACLE_HOME=/u01/11g/ export NLS_LANG=american_america.AL32UTF8 export ORACLE_SID=kagu1251 rman connect target user/pass BACKUP INCREMENTAL LEVEL 0 DATABASE; BACKUP DATAFILE "/oradata/db/admin/kagu/pfile/ init.ora.6302012163819"; BACKUP DATAFILE "/u01/11g/network/admin/ listener.ora"; BACKUP DATAFILE "/u01/11g/network/admin/ tnsnames.ora"; BACKUP DATAFILE "/u01/11g/dbs/spfilekagu.ora"; BACKUP DATAFILE "/u01/11g/dbs/orapwkagu1251";

Для остальных дней:

#!/bin/bash export ORACLE_HOME=/u01/11g/ export NLS_LANG=american_america.AL32UTF8 export ORACLE_SID=kagu1251 rman connect target user/pass BACKUP INCREMENTAL LEVEL 1 DATABASE; BACKUP DATAFILE "/oradata/db/admin/kagu/pfile/ init.ora.6302012163819"; BACKUP DATAFILE "/u01/11g/network/admin/ listener.ora"; BACKUP DATAFILE "/u01/11g/network/admin/ tnsnames.ora"; BACKUP DATAFILE "/u01/11g/dbs/spfilekagu.ora"; BACKUP DATAFILE "/u01/11g/dbs/orapwkagu1251";

Для восстановления всей базы данных после полного их изчезновения применяется команда RESTORE DATABASE, после её выполнения необходимо синхронизировать данные с помощью архивных журналов командой RECOVER DATABASE, восстановление происходит в режиме mount.

Для восстановления конкретного табличного пространства необходимо сначало перевести его в режим OFFLINE командой:

ALTER TABLESPACE user OFFLINE;

После этого выполнить его восстановление и синхронизацию:

RESTORE TABLESPACE user; RECOVER TABLESPACE user; По завершении перевести его в режим online командой:
ALTER TABLESPACE user ONLINE;

Так же можно откатить базу данных на определённым момент времени назад для этого выполняется команда:

SET UNTIL TIME "Jan 29 2013 20:00:00";

Это восстановление нужно делать когда база данных находится в режиме mount, а при открытии указать опцию RESETLOGS, что бы не выполнялись изменения сохранённые в журналах повторного выполнения созданные после точки восстановления.

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