Бэкап БД Oracle с помощью RMAN Backup Database. Резервное копирование Oracle. Бэкап базы Oracle с Bacula Enterprise

08.06.2019

Windows 7

Читайте, с помощью каких инструментов можно создать бэкап или восстановить утерянную базу 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 должен выполняться эффективно и быстро, так как серверы БД Oracle обычно применяются в наиболее нагруженных операциях в коммерческом сегменте. Handy Backup организует резервирование бэкапов Oracle через стандартную утилиту Oracle backup RMAN.

Преимущества использования Oracle RMAN Backup с Handy Backup

Специализированный плагин бэкапа Oracle в Handy Backup выступает как графическая надстройка (GUI) над стандартной программой Backup RMAN, с сохранением всех функций и возможностей, предоставляемых утилитой RMAN Backup Oracle.

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

Различные техники резервирования и восстановления Oracle из бэкапа

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

Хранилища для бэкапа базы Oracle

С помощью Handy Backup можно настроить для утилиты RMAN резервирование бэкапов на разнообразные хранилища данных, включая такие современные носители информации, как:

Локальные диски, устройства хранения данных на USB, прикреплённые сетевые диски;
Общие сетевые папки, устройства NAS, серверы FTP, SFTP, FTPS, частные облака;
Облачные сервисы Яндекс Диск, Google Диск, Amazon S3, Dropbox, OneDrive и другие;
Специализированное надёжное хранилище HBDrive, подходящее для бэкапов БД Oracle.

На заметку: серверные решения Handy Backup Office Expert и Handy Backup Server Network содержат "из коробки" все доступные плагины хранилищ информации, позволяя организовать бэкап базы Oracle в наиболее удобное и надёжное хранилище данных для конкретной задачи.

Почему удобно использовать бэкап RMAN через Handy Backup?

Интерфейс и набор функций Handy Backup позволяют использовать утилиту RMAN backup как один из плагинов программы под управлением единого интерфейса. Вы можете не только с лёгкостью создавать или изменять задачи бэкапа БД Oracle, но и управлять ими:

Запускайте другие приложения до и после задачи, эффективно заменяя типичный Oracle PL SQL скрипт бэкапа удобным визуализированным решением.

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

Пользуйтесь сетевыми решениями Handy Backup для бэкапа Oracle на удалённых машинах с центральной административной панели.

Как сделать бэкап Oracle с помощью Handy Backup

Здесь вы найдёте краткую инструкцию по созданию бэкапа базы данных Oracle через Handy Backup. Программа берёт на себя всю работу по взаимодействию с утилитой бэкапа RMAN, позволяя выполнить бэкап БД Oracle и восстановление базы данных из бэкапа автоматически.

для работы с функциями резервного копирования.
Создайте новую задачу в Handy Backup с помощью меню или кнопки "Новая задача".
На Шаге 1 выберите задачу резервного копирования. Нажмите "Далее".
На Шаге 2 выберите плагин Oracle в группе Database на левой панели.

Дважды щёлкните на названии плагина или нажмите ">>".
Откроется диалог выбора данных. Отметьте "галочками" базы данных для бэкапа Oracle.

Нажмите ОК и вернитесь к Шагу 2. Продолжайте БД:

Выберите подходящее хранилище на Шаге 3.
Выберите создание полного/инкрементального бэкапа Oracle на Шаге 4.

Настройте сжатие и/или шифрование на Шаге 5.
Задайте расписание работы по времени или по событию на Шаге 6.
Запускайте другие программы, команды или пакеты до и/или после задачи на Шаге 7.
На Шаге 8 дайте имя вашей задаче и завершите работу мастера новых задач.

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

Восстановление Oracle из бэкапа

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

Выберите на Шаге 1 задачу восстановления. Перейдите к Шагу 2.
Откройте хранилище данных, найдите каталог бэкапа БД Oracle, а в нём файл backup.hbi.

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

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

Попробуйте плагин бэкапа Oracle RMAN в работе, скачав и установив прямо сейчас Handy Backup со всеми доступными функциями и плагинами на 30-дневный бесплатный пробный период!

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

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

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

Резервное копирование баз данных 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 можно разделить на три вида:

1. Логическое резервное копирование - производится при помощи входящей в состав Oracle утилиты ехр, которая позволяет экспортировать всю базу, заданные схемы или таблицы. В случае экспорта всей базы выполняется так называемый полный экспорт (при этом экспортируются все таблицы базы данных) или инкрементный (выгружаются таблицы, изменившиеся с момента последнего экспорта). Для Oracle 10g ХЕ, в котором объем базы не превышает 4 Гбайт, можно пользоваться полным экспортом.

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

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

Для небольших учебных баз данных наиболее простым и надежным является полное логическое резервное копирование и физическое резервное копирование. Логическое резервное копирование выполняется при помощи утилиты ехр.ехе, размещенной в папке oraclexe\app\oracle\product\10.2.0\server\BIN\. Утилита является консольным приложением, получающим параметры через командную строку. Поскольку параметров обычно бывает много (5-10 штук), удобно создать профиль с параметрами и затем передать его утилите экспорта при помощи параметра parfile.

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

USERID = имя/пароль
LOG = oralOstud.log FILE = oralOstud.dmp 0WNER= STUDENT

Затем произведем экспорт, выполнив команду ехр parfile=exp_stud.prm, в результате чего будет создан файл ora10stud.dmp, содержащий резервную копию схемы STUDENT. Этот файл имеет бинарный формат и очень хорошо сжимается любым архиватором, поэтому для автоматизации процедуры резервного копирования удобно создать ВАТ- файл, содержащий команду экспорта и вызов архиватора для сжатия полученного дампа.

В нашем случае параметр USERID содержит имя и пароль для доступа к базе данных, параметр LOG задает имя файла, в который записывается протокол работы, параметр FILE задает имя файла резервной копии, OWNER - одна или несколько экспортируемых схем (если указывается несколько схем, то они перечисляются через запятую).

Для выполнения полного экспорта профиль немного изменится:

USERID = имя/пароль
LOG = oralOfull.log FILE = oralOfull.dmp FULL = Y

Важным моментом является то, что экспорт конкретной схемы можно выполнять от имени ее владельца, но для полного экспорта необходимо обладать ролью DBA, в противном случае попытка полного экспорта завершится ошибкой ЕХР-00023 с сообщением «Must be a DBA to do Full Database or Tablespace export». Размер дампа в случае полного экспорта пустой базы Oracle 10g ХЕ составляет 43 Мбайт (9 Мбайт после сжатия WinRar). Настоятельно рекомендуется выполнять периодическое резервное копирование даже на учебной базе - известны десятки и сотни случаев, когда в ходе изучения Oracle происходит повреждение базы, удаление пользователя или иная операция, приводящая к потере созданных объектов.

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

USERID = student/student LOG = oralOstudimp.log FILE = oralOstud.dmp
ROWS = Y
GRANTS = Y
INDEXES = Y
FR0MUSER= STUDENT
T0USER= STUDENT

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

Параметры ROWS (строки таблиц), GRANTS (полномочия на объекты), INDEXES (индексы) указывают, какие типы объектов импортируются.

Рассмотрим несколько типичных ситуаций, встречающихся на практике:

необходимо импортировать объекты учетной записи STUDENT в учетную запись STUDENT1. В этом случае следует задать параметры FROMUSER=STUDENT и TOUSER= STUDENT1;

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

У IMP есть одна интересная функция - вместо выполнения команд в базе данных эта утилита выводит их в протокол, генерируя тем самым скрипты, содержащие DML-операторы. Для включения этой функции необходимо указать параметр SHOW=Y.

Oracle Database хранит все файлы созданной базы в файлах данных. Несмотря на то, что все данные логически содержатся в табличных пространствах, фактически они являются содержимым файлов на жестком диске компьютера. Так, каждая таблица базы данных хранится в виде строк конкретного файла данных. Часто, для восстановления данных определённой базы, достаточно восстановить её файлы данных и импортировать их в Oracle Database.

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

Файлы данных и табличных пространств (*.DBF) .

Название файлов данных и табличных пространств, а также пути к ним можно посмотреть с помощью SQL Plus если выполнить следующий запрос:

SELECT t.name “Tablespace”, f.name “Datafile” FROM v$tablespace t, v$datafile f WHERE t.ts# = f.ts# ORDER BY t.name;

Файлы конфигурации базы данных (*.ora) .

Конфигурационные файлы базы данных Oracle имеют расширение *.ora и расположены в папке:

Управляющие файлы базы данных (*.DBF) .

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

Также, чтобы определить названия и пути к управляющим файлам в SQL*Plus необходимо выполнить запрос:

SELECT value FROM v$parameter WHERE name = ‘control_files’;

Файлы журналов транзакций (*.LOG) .

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

SELECT member FROM v$logfile;

В результате работы этого запроса получится подобный отчет:

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

SELECT destination FROM v$archive_dest where status=’VALID’;

В результате работы этого запроса получится отчет:

Файл паролей (*.ora) .
Как правило, это файлы с расширением *.ora, имя которых начинается с символов PWD.
Например: PWDXE.ora

*.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 (backup) можно сделать двумя способами:

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

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

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

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