Как сделать копию базы oracle

Путеводитель по резервному копированию баз данных

– О, никакое убежище не выдержит попадания метеорита. Но ведь у вас, как и у каждого, есть резерв, так что можете не беспокоиться.

Станислав Лем, «Звёздные дневники Ийона Тихого»

Резервным копированием называется сохранение копии данных где-то вне основного места их хранения.

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

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

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

Наконец, третья задача, решение которой требует наличия резервной копии, – это клонирование базы, например, для целей тестирования.

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

Выгрузка данных

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

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

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

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

«Холодное» сохранение файлов БД

Очевидная идея – остановить базу данных и скопировать все её файлы. Такая резервная копия называется «холодной». Способ крайне надёжный и простой, но у него есть два очевидных недостатка:

«Горячее» сохранение файлов

Большинство резервных копий современных баз данных выполняется путём копирования файлов базы данных без остановки базы. Здесь видны несколько проблем:

Вот как выглядит подготовка к резервному копированию в СУБД с изменяемыми дисковыми структурами, т. е. во всех традиционных дисковых реляционных системах:

По окончании резервного копирования нужно перевести базу данных обратно в обычное состояние. В Oracle это делается командой ALTER DATABASE/TABLESPACE END BACKUP, в PostgreSQL – вызовом функции pg_stop_backup(), а в других базах – внутренними подпрограммами соответствующих команд или внешних сервисов.

Вот как выглядит временнáя диаграмма процесса резервного копирования:

Восстановление на точку

Резервная копия позволяет восстановить состояние базы данных на момент, когда завершилась команда возврата из режима резервного копирования. Однако авария, после которой потребуется восстановление, может произойти в любой момент. Задача восстановления состояния БД на произвольный момент называется «восстановлением на точку» (point-in-time recovery).

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

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

Инкрементальное резервное копирование

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

Решение задачи – инкрементальное резервное копирование, то есть копирование только тех страниц данных, которые изменились с момента предыдущего резервного копирования.
Инкрементальное резервное копирование имеет смысл только для СУБД, использующих изменяемые структуры данных.

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

К сожалению, единой терминологии не существует, и разные производители используют разные термины:

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

Есть три способа создания инкрементальной копии:

Второй и третий способ отличаются механизмом определения списка изменённых страниц. Разбор журналов более ресурсоёмкий, плюс для его реализации необходимо знать структуру журнальных файлов. Спросить у самой базы, какие именно страницы изменились, проще всего, но для этого ядро СУБД должно иметь функциональность отслеживания изменённых блоков (block change tracking).

Впервые функциональность инкрементального резервного копирования была создана в ПО Oracle Recovery Manager (RMAN), появившемся в релизе Oracle 8i. Oracle сразу реализовал отслеживание изменённых блоков, поэтому необходимости в разборе журналов нет.

PostgreSQL не отслеживает изменённые блоки, поэтому утилита pg_probackup, разработанная российской компанией Postgres Professional, определяет изменённые страница путём анализа журнала. Однако компания поставляет и СУБД PostgresPro, которая включает расширение ptrack, отслеживающее изменение страниц. При использовании pg_probackup с СУБД PostgresPro утилита запрашивает изменённые страницы у самой базы – точно так же, как и RMAN.

Microsoft SQL Server так же, как и Oracle, отслеживает изменённые страницы, но команда BACKUP позволяет делать только полные и кумулятивные резервные копии.

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

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

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

Наилучшей на сегодня реализацией идеи инкрементального резервного копирования является программно-аппаратный комплекс (в терминологии Oracle – engineered system) Zero Data Loss Recovery Appliance – специализированное решение Oracle для резервного копирования собственной БД. Комплекс представляет собой кластер серверов с большим объёмом дисков, на которые установлена модифицированная версия ПО Recovery Manager и может работать как с другими программно-аппаратными комплексами Oracle (Database Appliance, Exadata, SPARC Supercluster), так и с базами Oracle на традиционной инфраструктуре. В отличие от «обычного» RMAN, в ZDLRA реализована концепция «вечного инкремента» (incremental forever). Система единственный раз создаёт полную копию базы данных, а потом делает только инкрементальные копии. Дополнительные модули RMAN позволяют объединять копии, создавая новые полные копии из инкрементальных.

К чести российских разработчиков нужно заметить, что и pg_probackup умеет объединять инкрементальные копии.

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

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

Источник

Как клонировать базу данных в Oracle

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

Шаг 1

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

SET LINES 100 PAGES 999

COL NAME FORMAT A50

FROM (SELECT NAME, BYTES FROM V$DATAFILE

SELECT NAME, BYTES FROM V$TEMPFILE

SELECT LF.MEMBER «NAME», L.BYTES

FROM V$LOGFILE LF, V$LOG L

WHERE LF.GROUP# = L.GROUP#) USED,

(SELECT SUM (BYTES) AS POO FROM DBA_FREE_SPACE) FREE

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

Остановите исходную базу данных, выполнив:

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

Запустите исходную базу данных:

Шаг 2

Создание spfile для новой базы данных. Этот шаг предполагает, что вы используете spfile, если нет, то скопируйте существующий.
Для создания, выполните в sqlplus:

create pfile=’init_ новый _SID.ora’ from spfile;

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

Шаг 3

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

alter database backup controlfile to trace as’/home/oracle/cr_новый_SID.sql’

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

Ниже приведен пример, как примерно должен выглядеть полученный файл, база данных не в режиме ARCHIVELOG и называется TEST:

STARTUP NOMOUNT
CREATE CONTROLFILE SET DATABASE «TEST» RESETLOGS FORCE LOGGING NOARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 ‘/u03/oradata/test/redo01.log’ SIZE 100M,
GROUP 2 ‘/u03/oradata/test/redo02.log’ SIZE 100M,
GROUP 3 ‘/u03/oradata/test/redo03.log’ SIZE 100M
DATAFILE
‘/u03/oradata/test/system01.dbf’,
‘/u03/oradata/test/undotbs01.dbf’,
‘/u03/oradata/test/cwmlite01.dbf’,
‘/u03/oradata/test/drsys01.dbf’,
‘/u03/oradata/test/example01.dbf’,
‘/u03/oradata/test/indx01.dbf’,
‘/u03/oradata/test/odm01.dbf’,
‘/u03/oradata/test/tools01.dbf’,
‘/u03/oradata/test/users01.dbf’,
‘/u03/oradata/test/xdb01.dbf’,
‘/u03/oradata/test/andy01.dbf’,
‘/u03/oradata/test/psstats01.dbf’,
‘/u03/oradata/test/planner01.dbf’
CHARACTER SET CL8MSWIN1251
;
ALTER DATABASE OPEN RESETLOGS;
ALTER TABLESPACE TEMP ADD TEMPFILE ‘/u03/oradata/test/temp01.dbf’
SIZE 104857600 REUSE AUTOEXTEND OFF;

Шаг 4

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

Шаг 5

Создаем новый файл паролей и управляющие файлы. Для создания файла паролей выполните команду:

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

sqlplus «/ as sysdba»

@/home/oracle/cr_ новый _SID

На этом этапе легко можно столкнуться с ошибками. Приведу наиболее частые и пути их решения:

ORA-01113: file 1 needs media recovery

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

ORA-01503: CREATE CONTROLFILE failed
ORA-00200: controlfile could not be created
ORA-00202: controlfile: ‘/u03/oradata/test/control01.ctl’
ORA-27038: skgfrcre: file exists

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

Шаг 6

Выполним ряд проверок.

Выполните проверку, открыт ло экземпляр базы данных. Для этого выполните:

SELECT STATUS FROM V$INSTANCE;

Статус базы данных должен быть OPEN

Проверяем файлы данных, статусы у всех должны быть ONLINE и SYSTEM:

SELECT DISTINCT STATUS FROM V$DATAFILE;

Просмотрите alert.log на наличие ошибок.

Шаг 7

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

ALTER DATABASE RENAME GLOBAL_NAME TO новый _SID

Шаг 8

Создадим spfile, выполнив в sqlplus:

CREATE SPFILE FROM PFILE;

Шаг 9

На этом шаге предстоит изменить ID базы данных, который необходим, например, при использовании RMAN. Если же RMAN использовать не планируется, то все равно лучше сменить, это будет наиболее правильно, да и лишний опыт не повредит.
Из sqlplus выполняете:

Из командной строки UNIX выполните:

NID спросит, действительно ли вы хотите изменить ID, ответить – Y (да). После того, как отработает, снова запустите базу, выполнив из sqlplus:

Источник

Как сделать копию базы oracle

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

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

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

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

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

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

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

Режимы ARCHIVELOG и NOARCHIVELOG

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

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

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

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

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

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

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

Для создания согласованной резервной копии базы данных необходимо либо закрывать (обычной командой 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:

Tags: Oracle DataBase, backups, резервное копирование

Источник