Как развернуть бэкап oracle

Обновлено: 06.07.2024

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

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

Требования к организации периодического резервного копирования (резервирование данных) не уникально для СУБД Oracle. Однако внутри СУБД возможно несколько различных вариантов организации резервирования. Рассмотрим возможности:

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

Основной способ создания резервных копий для БД, находящихся в промышленной эксплуатации - "горячее" резервирование без простоя сервиса, которое может быть реализовано двумя штатными для СУБД Oracle методами. Первым методом является использованием специального режима резервирования, в который могут переводиться табличные пространства (команды ALTER TABLESPACE . BEGIN|END BACKUP) с копированием файлов данных средствами ОС, и созданием копии контрольного файла (например, командой ALTER DATABASE BACKUP CONTROLFILE TO TRACE). Этот метод описан в расширенном руководстве по резервированию БД от производителя для версии 9, но работает и в последующих версиях. И этот метод позволяет создавать простые и ясные решения по резервированию БД

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

Для режима ". BEGIN|END BACKUP . " существует ещё одна особенность - движок пишет в оперативные, а значит и архивные, журналы расширенную информацию. Если в обычном режиме в оперативные журналы заносится только информация об изменениях в блоках данных, но не блок целиком, то при переводе в режим бэкапирования информация о каждом блоке с момента включения режима сохраняется несколько иначе. При первом журналировании модификаций блок записывается целиком, а далее пишутся только изменения. Такая особенность нужна для обеспечения защиты от изменения блока в процессе копирования файлов данных средствами операционной системы

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

Вторым методом является использование специально поставляемой в составе движка утилиты RMAN, призванной несколько упростить процесс создания резервных копий и восстановления БД. Этот метод является рекомендованным производителем и описываемом в штатной документации. Однако он имеет и плюсы, и минусы

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

Кроме того RMAN использует контрольный файл или специально созданную БД для учёта всех сделанных копий, и существенно упрощает процедуру восстановления БД, а также интеграцию с механизмом создания "тёплого" резерва сервиса с помошью штатного для редакции EE (enterprise edition) механизма Data Guard. Ещё одним плюсом является возможность интеграции в RMAN драйверов ленточных библиотек, что позволяет делать резерв данных непосредственно на ленту и восстановление с ленты

Однако RMAN является дополнительной надстройкой и по опыту коллег автора может преподнести сюрпризы в процессе восстановления, вплоть до невозможности восстановления. А при создании "тёплого" резерва сервиса (стэндбая) для редакции SE (standart edition) СУБД возможны взаимные накладки с механизмом скриптового стэндбая

Ещё одним способом создания резерва является использование утилит выгрузки и загрузки дампа данных Export/Import. Строго говоря бэкапом использование таких утилит считать нельзя. Связано это с тем, что в процессе создания даже полного дампа базы данные выгружаются не все - а именно не экспортируется схема SYS, содержащая словарь данных, и являющаяся уникальной для каждой БД. Поэтому объекты в схеме SYS не охватываются экспортом/импортом и говорить о полном бэкапе базы не приходится. Основное назначение этих утилит - перенос данных из базы в базу между разными платформами и версиями, когда нельзя подложить файлы данных напрямую. Однако автор видел вариант организации бэкапа с помощью экспортных утилит, восстановление в этом случае предполагало ручное накатывание информации в схему SYS с последующим восстановлением экспортного дампа. Это затратный и не рекомендованный способ, и им лучше не пользоваться

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

Бэкап базы Oracle с помощью RMAN

Необходимо обеспечить наличие (бэкап) следующей вспомогательной информации:

- начального init файла (в случае использования не spfile, а не pfile необязательно)
- trace копии контрольного файла (необязательно)
- журнала работы RMAN (необязательно, для определения sequence архивных журналов, можно вытащить и из контрольного файла или выделенного каталога)

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

В принципе это все. Любые ручные процедуры типа ALTER TABLESPACE BACKUP START/STOP при использовании RMAN не требуются. Еще - грамотно также обеспечить резервирование созданного в предидущем пункте резервного набора на внешний носитель

backup scripts for Oracle RDBMS - по этой ссылке можно скачать разработанную мной скриптовую обвязку для организации типового бэкапа БД через RMAN

Восстановление из бэкапа с помощью RMAN

Вариант восстановление базы «с нуля» на другой хост под Windows (UNIX):

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

- создать initSID.ora и orapwdSID файлы для загрузки экземпляра. Если init из внешнего backup и отредактировать его для соответствия желаемому имен описанных файлов и каталогов
- создать требуемые каталоги (bd, arc, logs как минимум, а также наличие информации об экземпляре в oratab - файле)
- с помощью oradim (для Windows) создать экземпляр командами:
oradim -NEW -SID ; oradim -EDIT -SID -STARTUPMODE a -PFILE имя_pfile -SHUTMODE i -SHUTTYPE inst
и стартовать сервис Windows

- сконфигурировать и запустить listener, с помощью tnsping и lsnrctl->status проверить работу listener

- запустить экземпляр в режиме nomount, для чего:
подключиться sqlplus и сказать startup nomount
ри необходимости вначале сказать . oraenv
или export ORACLE_SID=. ; export ORACLE_HOME=. ; export ORACLE_NLS_LANG=. ; с корректными значениями вместо .

восстановить файлы БД, для чего:
смонтировать базу командой: alter database mount ;
при необходимости вывести данные о созданных бэкапах, сказать в RMAN команду list backup, при необходимости - сменить местоположение БД указать новое местоположение, восстановить файлы данных и изменить указатели на местоположение в контролфайле командным блоком RMAN, например:
run <
set newname for datafile 'e:\oradata\my_oracle_db\system01.dbf' to 'c:\my_oracle_db\system01.dbf' ;
set newname for datafile 'e:\oradata\my_oracle_db\undotbs01.dbf' to 'c:\my_oracle_db\undotbs01.dbf' ;
set newname for datafile 'e:\oradata\my_oracle_db\users01.dbf' to 'c:\my_oracle_db\users01.dbf' ;
set newname for datafile 'e:\oradata\my_oracle_db\my_oracle_db.ora' to 'c:\my_oracle_db\my_oracle_db.ora' ;
restore database ;
switch datafile all ;
>

восстановить и накатить архивные журналы ДБ, для чего:
определить последний номер архивного журнала, сделанного сразу после создания backup_set (т.к. данные для команды list backup выводится не будут, необходимо воспользоваться текстовым журналом работы RMAN)
восстановить архивные журналы, при необходимости указав новое местоположение командным блоком RMAN, например:
run <
set archivelog destination to 'c:\my_oracle_db\archive' ;
restore archivelog sequence ;
>
сказать в RMAN: recover database until sequence

открыть БД, для чего:
изменить полный путь к оперативным журналам при необходимости (если меняется место расположения оперативных журналов) командой: alter database rename file 'прежнее имя файла' to 'новое имя файла'. Имена файлов оперативных журналов можно увидеть в v$logfiles, изменить на корректные для каждого файла
сказать: alter database open resetlogs ;
создать временные табличные пространства, например посмотрев параметры из ручного trace_бэкапа controlfile
создать копии контрольного файла (тушим базу, делаем физическую копию, корректируем файл инициализации)

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

Клонирование (2006) базы с помощью RMAN

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

Примем, что исходный сервер содержит базу, которую предстоит сдублировать (target db в терминологии RMAN), а на целевой сервер предстоит сдублировать базу (auxiliary db в терминологии RMAN)

Для подготовки к дублированию необходимо:

сконфигурировать SQLNet для исходного сервера и целевого серверов
обеспечить на целевом сервере всю структуру каталогов для создаваемой базы (db, arc, logs)
обеспечить на целевом сервере initDBNAME.ora и orapwdDBNAME файлы для создаваемой базы
обеспечить на целевом структуру каталогов для размещения бэкапа RMAN, аналогичную структуре бэкапа RMAN на исходном сервере
обеспечить наличие на целевом сервере (в правильной структуре каталогов) RMAN бэкапа текущей инкарнации дублируемой базы
обеспечить на целевом структуру каталогов для размещения архивных журналов, аналогичную структуре архивных журналов на исходном сервере
обеспечить наличие на целевом сервере (в правильной структуре каталогов) наличия архивных журналов, сделаных после бэкапа, используемого для клонирования

В общем случае дублирование производится подключением RMAN к target и auxiliary базам и инициализацией дублирования командой duplicate:

connect target target TRG_SYS_USER/TRG_SYS_PASS@TRG_SQLNET_ALIAS
connect auxiliary AUX_SYS_USER/AUX_SYS_PASS@AUX_SQLNET_ALIAS
duplicate target database to AUX_DB_NAME nofilenamecheck
как вариант, коннект можно проводить сразу в командной строке
rman target TRG_SYS_USER/TRG_SYS_PASS@TRG_SQLNET_ALIAS \
auxiliary AUX_SYS_USER/AUX_SYS_PASS@AUX_SQLNET_ALIAS

Клонирование (дуплицирование 2017) базы с помощью RMAN

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

Для подготовки к дублированию необходимо реализовать немного меньший набор требований, чем ранее:

Далее проводится сама процедура дупликации через командный файл, содержащий RMAN скрипт дупликации

Проследить объём дуплицированного для ASM можно следующим запросом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Файл паролей (*.ora).

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

Итак, для сохранения, архивирования или бэкапа базы данных 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 (backup) можно сделать двумя способами:

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

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

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

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

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

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

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

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

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

Укажите тип экспорта: рабочее пространство полностью или одну из его составляющих

Установите формат файла для экспорта данных и нажмите кнопку Export Workspace (справа)

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

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

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

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

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

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

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

Запустите Hetman Partition Recovery и проанализируйте с её помощью диск на котором находилась база данных

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

Замените файлы базы Oracle Database на восстановленные.

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

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

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

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

Запустите файл Backup.bat в папке

или выберите Backup Database среди приложений в меню Пуск

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

В результате в папке с названием даты создания резервной копии базы будет создан файл бэкапа с расширением *.BKP

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

Запустите файл Restore.bat в папке

или выберите Restore Database среди приложений в меню Пуск

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

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

Нашел данную статейку на просторах интернета. Решил поделиться с коллективом нашего дружного сообщества , так сказать! ;-)

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

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

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

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

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

C:\oraclexe\app\oracle\product\11.2.0\server\dbs

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

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

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

SELECT member FROM v$logfile;

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

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

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

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

Путь: C:\oraclexe\app\oracle\product\11.2.0\server\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 с помощью RMAN

Необходимо обеспечить наличие (бэкап) следующей вспомогательной информации:

Восстановление из бэкапа с помощью RMAN

Вариант восстановление базы «с нуля» на другой хост под Windows (UNIX):

- сконфигурировать и запустить listener, с помощью tnsping и lsnrctl->status проверить работу listener

Клонирование (2006) базы с помощью RMAN

Для подготовки к дублированию необходимо:

сконфигурировать SQLNet для исходного сервера и целевого серверов
обеспечить на целевом сервере всю структуру каталогов для создаваемой базы (db, arc, logs)
обеспечить на целевом сервере initDBNAME.ora и orapwdDBNAME файлы для создаваемой базы
обеспечить на целевом структуру каталогов для размещения бэкапа RMAN, аналогичную структуре бэкапа RMAN на исходном сервере
обеспечить наличие на целевом сервере (в правильной структуре каталогов) RMAN бэкапа текущей инкарнации дублируемой базы
обеспечить на целевом структуру каталогов для размещения архивных журналов, аналогичную структуре архивных журналов на исходном сервере
обеспечить наличие на целевом сервере (в правильной структуре каталогов) наличия архивных журналов, сделаных после бэкапа, используемого для клонирования

connect target target TRG_SYS_USER/TRG_SYS_PASS@TRG_SQLNET_ALIAS
connect auxiliary AUX_SYS_USER/AUX_SYS_PASS@AUX_SQLNET_ALIAS
duplicate target database to AUX_DB_NAME nofilenamecheck
как вариант, коннект можно проводить сразу в командной строке
rman target TRG_SYS_USER/TRG_SYS_PASS@TRG_SQLNET_ALIAS \
auxiliary AUX_SYS_USER/AUX_SYS_PASS@AUX_SQLNET_ALIAS

Клонирование (дуплицирование 2017) базы с помощью RMAN

Для подготовки к дублированию необходимо реализовать немного меньший набор требований, чем ранее:

Далее проводится сама процедура дупликации через командный файл, содержащий RMAN скрипт дупликации

Проследить объём дуплицированного для ASM можно следующим запросом

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

Добрый день, участники сообщества!
По многочисленным просьбам сегодня я расскажу как можно создать и поднять бэкап Terrasoft на СУБД Oracle.
Сделать это очень просто, все делается автоматически -- нужно лишь запустить командный файл и ввести названия базы данных.

Создание бэкапа

Распаковываем содержимое архива Backup.zip на сервер, где установлен сервер Oracle.
Запускаем BackupDatabase.cmd.
Указываем: название схемы, ее пароль (схемы-пользователя) и название файла дампа базы.
В результате получаем два файла: Grant.sql -- скрипт по созданию розданных прав и собственно сам дамп базы Oracle.

Поднятие бэкапа

Распаковываем содержимое архива Restore.zip на сервер, где установлен сервер Oracle.
Сюда же обязательно подкладываем два файла (Grant.sql и дамп), которые были созданы при создании бэкапа.
Запускаем RestoreDatabase.cmd.
Указываем: пароль пользователя SYS, название файла дампа базы (backup db file name), старое название схемы с которой делался дамп (old user schema), название новой схемы (new user schema) и пароль пользователя новой схемы (new user password).
Дальше все выполнится автоматически: создастся новая схема, раздадутся нужные права, создадутся нужные типы, подымется бэкап базы под указанной схемой, заменятся завязки объектов в системных таблицах Terrasoft на новые, раздадутся нужные права ролям на таблицы и представления.

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

Описал коротко, только самое нужное. Если будут вопросы - с удовольствием отвечу.

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

Ключевым моментом при создании бекапа является скрипт Grant.sql (см. Backup.zip), который создает "слепок" розданных прав для модели, которая применена в Terrasoft CRM.

UPD: Спасибо Саше Котенко за найденный недочет в файле BackupDatabase.cmd. Исправил.

Большое спасибо, Саша.

Саша, спасибо за удобный инструмент! С твоего позволения беру в эксплуатацию!
И да +1 :wink:

Саша, огромное спасибо! Данная инструкция и материал очень помогут всем, кто сталкивается с Oracle-версией продукта.

Указывайте пожалуйста требования к использованию скриптов.
Здесь:
1. скрипт для Windows (чаще для поддержки Oracle используются другие ОС),
2. вне скрипта определена переменная среды ORACLE_SID.
Согласно документации рекомендованно:
1. формат авторизации sqlplus из командной строки (например BackupDatabase.cmd строка 12) определяется как sqlplus login/password@sid, а в Вашем случае (без указания сида) получим ERROR: ORA-12560: TNS:ошибка адаптера протокола
2. Использование команды без логирования тоже не лучший вариант.

ihmo статья скорее вредна, очень удивили оставленные комментарии :(

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

Здравствуйте.У меня возник вопрос.Мне предстоит установить сервер Terrasoft и интегрировать террасофт в существующую структуру.но никогда не работал с базой даннх оракл.
Как я понимаю пункт 1 надо делать, если существует старая база данных?Или как? В руководстве описано по другому.Но в руководстве как я понял предполагается что сервер базы данных оракл и сервер террасофт это один физический компьютер.А мне надо разнести их по разным ролям.в руководстве написано:
Для восстановления БД на сервере необходимо:
1. Запустить файл RestoreDatabase.cmd, который находится в
директории \DB>, нажав
на клавишу [Enter].
Какой сервер иммется ввиду?Наверно сервер баз данных оракл?Но там этого пути не будет если сам софт будет стоять отдельно!Помогите разобраться пожалуйста!

Такого понятия как "сервер Террасофт" - не существует. Вы устанавливаете БД Oracle на машине, которую назначите в роли сервера БД. Далее Вы устанвливаете клиентские приложения Террасофт и соединение с БД соглагласно руководству.

Terrasoft Support Team.

Есть ли изменения в инструкции(по созданию/поднятию бекапа) для версий 3.4.0+ ?

Немного подкорректировал скрипт SysGrants.sql из инструментария восстановления бекапа версии 3.3.2.

Ранее там было указано:

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

Исправленный restore_3_3_2.zip обновлен.

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

Попытаюсь ответить на эти вопросы.

Тип объекта "SCHEMA_NAME"."t_FieldInfo" уже существует с другим идентификатором

В нашей системе используются объектные типы БД Oracle, OBJECT TYPE.

Дело в том, что Oracle жестко связывает объектные типы с их идентификаторами, OID.

При этом если на сервере был однажды восстановлен бекап схемы Terrasoft, там создадутся все используемые типы ("t_GetLoginInfo", "tbl_GetLoginInfo" и др.).
Но из-за жесткой привязки к OID, эти типы создадутся с OID, который прописан в дампе.

Первый раз все будет нормально. Но при поднятии того же, либо другого бекапа схемы Terrasoft на том же сервере, он опять будет создавать типы с теми же OID – в результате возникнет ошибка: объект с таким OID уже существует. В результате после поднятия бекапа ни один из типов не создастся.

Из-за этой особенности Oracle, мы сделали в скриптах поднятия наших схем обходное решение:

Перед поднятием бекапа скриптом CreateTypes.sql явно создаются все необходимые типы, при создании Oracle сгенерирует им новые OID.
При поднятии Oracle пытается создать типы из бекапа c их старыми OID, при этом выдается ошибка IMP-00061: Внимание: Тип объекта "Схема"."Тип" уже существует с другим идентификатором

При возникновении такой ошибки, создание типа пропускается.

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

После поднятия бекапа некоторые объекты невалидны

Это также не является ошибкой, а просто предупреждением.

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

Если в одном из триггеров используется вызов какой-либо хранимой процедуры - после импорта он будет невалидным.

Переходим от теории к практике. В нашей системе у многих таблиц есть строчный триггер BEFORE INSERT OR UPDATE, например такой:

Как видим по коду, этот триггер вызывает функцию fn_CreateGUID, которой на момент переноса триггера просто нет. Она создастся позже, со всеми остальными ХП. Из-за этого триггер остается невалидным.

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

Система администрирования Oracle в версии 341 существенно изменилась. В связи с этим, изменился также и механизм создания и восстановления резервных копий.

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

Появилась возможность указывать инстанс Oracle для разворачивания бекапа
Можно указать отдельное табличное пространство для разворачивания схемы
Исправлена ситуация с экспортом пустых таблиц (Oracle 11)

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

Опция № 0 - Перепривязать пользователей в новую схему (по умолчанию)

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

Опция № 1 - Создать пользователей с перименованием

Этот вариант предполагает, что все пользователи Terrasoft будут созданы как новые пользователи Oracle c префиксами 'U' и им будет розданы все соответствующие права. Например в старой схеме был пользователь User1, после поднятия резервной копии новый пользователь будет User1U. Таким образом старый пользователь User1 будет продолжать нормально работать со старой схемой, а новый будет иметь все те же права в отношении новой схемы на одном инстансе. Этот вариант удобен при поднятии тестовой схемы на том же инстансе, где уже работает боевая схема. При этом пользователи будут абсолютно независимы.

Опция № 2 - Не создавать пользователей

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

Читайте также: