Как сделать дамп базы oracle
Что такое дамп базы данных и как его создать
Перенос сайта с одного сервера на другой может оказаться непростой задачей для многих пользователей. Это связано с тем, что, помимо обычного перемещения файлов, необходимо также выполнить экспорт и импорт базы данных. В таких случаях используется специальный файл под названием дамп. Поговорим в сегодняшней статье, что это такое и как его сделать.
Что такое дамп базы данных
Копирование базы данных может быть полезно, когда нужно выполнить:
Помимо этого, дамп может заполнить не только пустую базу, но и заменить содержимое ранее созданной. Давайте перейдем к практической части и посмотрим на наглядном примере, как все это можно организовать.
Создаем дамп базы данных MySQL
Существует несколько способов создания дампов: через консольное окно или с помощью phpMyAdmin. Рассмотрим последовательно каждый из методов, а также попробуем восстановить БД из дампа.
Способ 1: Консольное окно MySQL
Удаленное подключение к хостингу по SSH разрешает работать с информационными хранилищами. Выбор данного протокола обусловлен его высокой безопасностью, так как вся информация передается в зашифрованном виде без возможности перехвата трафика.
Для подключения вы можете воспользоваться такими программами, как PuTTY и WinSCP – они распространяются в бесплатном доступе. Остановимся на первой утилите и посмотрим, как с ее помощью можно сделать дамп базы данных MySQL.
Обратите внимание, что если на компьютере функционирует сервер с БД, то соединение через порт 3306 будет некорректно. В таких случаях рекомендуется использовать другие значения, например, 3307, 3308 и так далее.
Теперь мы можем переходить к удаленному администрированию БД: создадим дамп базы данных MySQL. Для этого введем в консоль следующий запрос:
В целях безопасности рекомендуется вообще не использовать логин и пароль. В таком случае команда примет следующий вид:
Для понимания можете взглянуть на пример с использованием пользователя и пароля:
Таким образом будет создан файл WordPressDump.sql, содержащий в себе все нужные данные для точного копирования. Посмотрим, как этот файл импортировать в проект через консоль:
Аналогично подставляем свои данные в команду и в итоге получаем:
Также при импорте мы можем указать кодировку — для этого достаточно добавить ключ default-character-set. В итоге код преобразуется:
Вот такими несложными действиями можно сделать копирование через консольное окно. Теперь давайте «покопаемся» в phpMyAdmin и выполним в нем копирование БД.
Способ 2: Инструмент phpMyAdmin
PhpMyAdmin по умолчанию предустановлен на каждой CMS. Доступ к нему осуществляется через личный кабинет пользователя на хостинге либо через локальный веб-сервер на домашнем ПК.
Подключаемся к phpMyAdmin и экспортируем БД:
После этого нам будет предложен выбор места сохранения файла. В последующем мы сможем его использовать через вкладку «Импорт». Для этого достаточно загрузить файл и указать подходящую для него кодировку:
В заключение стоит сказать, что дамп базы данных – это незаменимый файл, без которого не обходится ни один серверный переезд. Используйте его для переноса базы на хостинге или с локальной машины, а также для создания резервных копий. Удачи!
В состав технологии Data Pump входят утилиты: Data Pump Export (expdp) и Data Pump Import (impdp).
Data Pump Export – выгружает данные в файлы операционной системы, называемые файлами дампа (dumps files), в специальном формате, который может понимать только утилита Data Pump Import.
Получить справку по утилитам можно выполнив команды:
Если необходимо выполнить экспорт схемы или ее объектов, воспользуйтесь правами данной схемы. Использовать полномочия учетных записей sys и system не рекомендуется (по той причине, что для импорта могут потребоваться права sys и system соотвестственно).
Файл параметров экспорта схемы.
dplogs и dpdumps должны ссылаться на реальные каталоги операционной системы с достаточным набором прав на запись.
Создание ссылки в базе данных на катлоги операционной системы
Посмотреть уже имеющиеся каталоги для datapump:
Мне не нравится каталог по умолчанию. Предпочитаю его удалить
Делегирую права на запись в данную директорию пользователю scott
Если необходимо предоставить возможность экспорта данных в указанные каталоги для любых схем:
Экспорт схемы с использованием файла параметров:
В некоторых случаях необходимо явно указать SID базы данных.
Экспорт можно выполнить одной командой без использования файла параметров:
Технология Data Pump состоит из трех главных компонентов:
Режимы утилиты Data Pump Export
Data Pump Export поддерживает несколько режимов для выполнения заданий.
По умолчанию для выполнения заданий Data Pump Export и Data Pump Import используется режим схем.
Параметры фильтрации экспортируемых данных.
Парамтеры ECLUDE и INCLUDE
Параметры EXCLUDE и INCLUDE – это два взаимоисключающих параметра, которые можно применять для выполнения так называемой фильтрации метаданных (metadata filtering). Фильтрация метаданных позволяет выборочно исплючать или наоборот включать определенные типы объектов во время выполнения задания Data Pump Export или Data Pump Import. В преджней утилите экспорта для указания того, требуется ли экспортировать такие объекты, применялись параметры CONSTRAINTS, GRANTS и INDEXES. За счет использования параметров EXCLUDE и INCLUDE теперь стало можно включать и исключать объекты и многих других видов помимо тех четырех, фильтарцию которых можно было осуществлять ранее. Например, если необходимо сделать так, тобы во время экспорта не экспортировались никакие пакеты, такое поведение задается с помощью параметра EXCLUDE.
Проще говоря, параметр EXCLUDE помогает пропускать определенные типы объектво базы данных во время операции экспорта или импорта, а параметр INCLUDE наоборот – включать в эти операции только определенный набор объектов. Ниже показано, как в общем случае выглядит синтаксис этих параметров:
Параметры EXCLUDE и INCLUDE являются взаимоисключащими. Поэтому во время выполенния одного и того же задания применять можно толкьо какой-то один из них; использовать тот и другой одновременно нельзя.
Как для параметра EXCLUDE, так и для параметра INCLUDE, элемент конструкцияимени является необязательным. Как известно, некоторые объекты в базе данных, например, таблицы, индексы, пакеты и процедуры, обладают именами, а некоторые, напримре, объекты GRANTS – нет. Элемент конструкцияимени в параметре EXCLUDE или INCLUDE позволяет приенять SQL-функцию для фильтрации именованных объектов.
Ниже приведен простой пример исключения всех таблиц, имя которые начинается с ECMP.
В этом примере ”LIKE ‘EMP%’” пре конструкцию имени.
Элемент конструкция_имени является необязательным в параметрах EXCLUDE и INCLUDE. Он представляет собой просто средство фильтрации, позволяющее более точно определять тип подлежащих исключению или включению объектво (индексов, таблиц и т.д.). В случае его пропуска включаться или исключаться будут все объекты указанного типа.
В следующем примере Oracle исключит из операции экспорта все индексы, потому в элементе конструкция_имени не было указано никакого значения, требующего, чтобы исключались только определенные индексы:
Вдобавок параметр EXCLUDE может применяться для исключения целой схемы, как показано в следующем примере:
Параметр INCLUDE является противоположностью параметру EXLCUDE и позволяет принудительно включать в операцию экспорта только определенный набор объектов. Как и в случае параметра EXLCUDE, для указания того, какие точно объекты требуется экспортировать, вместе с INCLUDE тоже можно использовать элемент конструкция_имени.
Ниже приведены три примера, демонстрирующие примеение элемента конструкция_имени для ограничения выбираемых объектов:
В первом примере параметр INCLUDE указывает, что в процессе экспорта должны приниать участие только две таблицы: ECMPLOYEES и DEPARTMENTS, во втором – только процедуры, а в третьем – только индексы, причем лишь те, имя у которых начинается с EMP.
В следующем примере показано, как использовать символ косой черты для отмены двойных кавычек:
При выполнении фильтрации метаданных за счет применения параметра EXCLUDE и INCLUDE нужно помнить о том, что все объекты, которые зависят от какого-то из фильтуемых объектов, будут обрабатываться тем же образом, что и сам этот фильтруемый объект. Например, в случае использвоания параметра EXCLUDE для исключения некоторой таблицы также автоматичеки будут исключаться индексы, граничения, триггеры и прочие зависящие от этой тблицы объеекты.
Существует еще множество всевозможных параметров в т.ч. и шиврование, компрессиия и д.р.
Data Pump Import
Иногда, (в моем случае при неудачном импорте) можно вытащить из файла дампа весь код DDL.
Для этого можно воспользоваться параметром SQLFILE.
Создается файл scott.sql с DDL.
Параметры фильтрации
Параметр CONTENT применяться в Data Pump Import, как и в Data Pump Export, для указания того, должны ли загружаться только строки (CONTENT=DATA_ONLY), строки и метаданные (CONTENT=ALL), либо только метаданные (CONTENT=METADATA_ONLY). Параметры EXLCUDE и INCLUDE имеют в Data Pump Import точно такое же предназначение, как и в Data Pump Export, и явялются взаимоисключающими, а в частности:
Ниже приведент простой пример использования параметра INCLUDE. В этом примере импорт ограничивается только объектами таблиц. В результате импортирована будет только таблица PERSONS.
Для импорта только тех таблиц, имя у которых начинается с букв PER, можно использоть конструкцию INCLUDE=TABLE:”LIKE ‘PER%’”. Вдобавок параметр INCLUDE можно применять и отрицательным образом, указывая то, что все объекты с оперделенным синтаксисом должны игнорироваться: INCLUDE=TABLE:”NOT LIKE ‘PER%’”
Обратите внимаение на то, что в случае установки для параметра CONTENT занчения DATA_ONLY, использовать во время импорта ни параметр EXCLUDE ни параметр INCLUDE нельзя.
Параметр TABLE_EXISTS_ACTION позволяет указывать Data Pump Import, что следует делать в случае, если таблица уже существует. Для этого параметра можно устанавливать четыре разных значения:
Параметры переопределения
Параметр REMAP_TABLE
Параметр REMAP_TABLE позволяет переименовывать таблицу при выполнении операции импорта с сипользованием метода переноса табличных пространств.
В этом примере параметр REMAP_TABLE указывает, что при выполнении операции импорта имя таблицы hr.employees должно быть изменено на hr.emp
Параметр REMAP_SCHEMA
Параметр REMAP_SCHEMA позволяет перемещать объекты из одной схемы в другую. Задается этот параметр примерно так:
В этом примере параметр REMAP_SCHEMA указывает, что при выполнении операции импорта требуется перемесить все объекты из исходной схемы HR в целевую схему OE. Утилита Data Pump Import может даже создать схему OE, если таковой в целевой базе данных не существует.
Параметр REMAP_TABLESPACE
Иногда бывает нужно, чтобы табличное пространство, в которое выполняется импорт даннных, отличалось от используемого в исходной базе данных. Параметр REMAP_TABLESPACE позволяет осуществлять во время импорта перемещение объектов из одного табличноо пространства в другое.
Параметр REMAP_DATAFILE
При перемещении баз данных между двумя различными платформами, на каждой из которых используетс свое соглашие по именованию фалов, параметр REMAP_DATAFIE приходится очень кстати, поскольку позволяет изменять формат именования файлов. Ниже приведен пример, показывающий, как с помощью этого параметра указать утилите Data Pump Import, что вместо формата фаловой системы Windows, требуется использовать формат файловой системы UNIX. После этого при обнаружении в экспортном файле дампа людой ссылки на файл с именем в формате файловой истемы Windows, утилита Data Pump Import будет автоматически изменять имя файла в соответствии с форматом файловой системы UNIX.
Параметры TRANSFORM
Предположим, что требуется импортировать таблицу из другой схемиы или даже другой азы данных и не импортироват при этом другие атрибуты хранения объектов, т.е. необходимо просто перенести содержациеся в таблице данные. Параметр TRASNSFORM позволяет указать утилите Data Pump Import не импортировать оперделенные атрибуты хранения и атрибуты других видов. За счет применения параметра TRANSFORM можно исключать из таблицы или индекса конструкции STORAGE и TABLESPACE или только конструкции STORAGE. При выполнении импорта с помощью Data Pump Oracle создает объекты с использованием DDL-операторов, которые находит в экспортных файлах дампа. Параметр TRANSFORM, по сути, указывает утилите Data Pump Import изменять приводящие к созданию объектов операторы DDL оперделенным образом.
В целом синтаксис параметра TRANSFORM выглядит так:
Ниже приведено краткое описание того, что собой представляет кадый элемент.
1) Название_трансовармации. Существуют всего четыре опции, которые могут указываться на месте этого элемента. Эти опции позволяют, соответственно, изменять четыре основных вида характеристик объекта.
2) Значение. На месте элемента значение в параметре TRANSFORM может указываться либо значение Y (да), либо значение N (нет). Как упоминалось выше, для первых трех опций, которые могут указываться на месте название_трансформации, по умолчанию устанавливается занчение Y. Это означает, что по умолчанию Data Pump предусмативает выполнение импорта как атрибутов сегмента, так и атрибутов хранения объекта. В качестве альтернативного варианта, для этих опций можно устанавивать значение N и тем самым указывать Data Pump не импортировать исходные атрибуты сегмента и/или хранения. Что касается опции PCTSPACE, то для нее на месте элемета занчение можнет задваться только какое-то число.
3) Типобъекта. На месте элемета типобъекта можно указывать утилите Data Pump Import, объекты какого типа необходимо трансформировать. Это могут быть таблицы, индексы, табличные пространсва, типы, кластеры, граничения и прочие обхекты, в зависимости от опций, указываемых на месте название_транформации. В случае не указания типа подлежащих транформаци обхектов при использовании опции SEGMENT_ATTRIBUTES и STORAGE, эти опции будут применяться ко всем таблицам и индексам, которые являются частью операции импорта.
Ниже приведен пример применения параметра TRANSFORM:
В этом примере для SEGMENT_ATTRIBUTES установлено занчение N, а в качестве типа объекта указана таблица. В такой спецификации параметр TRANSFROM указывает утилите Data Pump Import не импортировать существующие атрибуты хранения ни для каких таблиц.
Мониторинг выполнения заданий Data Pump
Наиболее важными для мониторинга за выполнением заданий Data Pump являются представления DBA_DATAPUMP_JOBS и DBA_DATAPUMP_SISSIONS.
Представление DBA_DATAPUMP_JOBS позволяет получать сводную информацию обо всех выполняющихся в текущий момент заданиях Data Pump.
Представление DBA_DATAPUMP_SESSIONS позволяет выяснять, какие пользователькие сеансы в текущий момент подключены к заданию Data Pump Export или Data Pump Import
Просмотр информации о ходе выполненния заданий Data Pump
Ниже приведен типичный сценарий, который можнро использовать для получения информаци о том, сколько времени осталось до завершения выполнения задания Data Pump:
Tags: Oracle Database, экспорт, импорт, Data Pump
Пользовательские методы резервного копирования базы данных Oracle
Компания Oracle рекомендует применять для резервного копирования и восстановления баз данных утилиту RMAN, поскольку она изначально учитывает особенности используемых в Oracle структур блоков и потому способна обеспечивать замечательную производительность; кроме того, она оснащена возможностями вроде сжатия, возобновления операций резервного копирования и восстановления, отслеживания изменений в блоках и интеграции с ПО уровня управления носителями (MML). Однако делать полностью действительные резервные копии вполне можно и самостоятельно, без помощи RMAN или Oracle Secure Backup, за счет применения предлагаемых в операционной системе команд копирования, наподобие cp и dd в UNIX и copy в Windows. При желании делать предназначенные для хранения на ленте резервные копии можно также подключаться к диспетчеру носителей. В случае такого подхода необходимо самостоятельно отслеживать все резервные копии, проверять их действительность, а также принимать решение о том, какие из них использовать во время сеанса восстановления. Именно поэтому Oracle и называет подобные методы создания резервных копий пользовательскими (user-managed backups).
При наличии простой базы данных Oracle и не слишком обременительных требований по резервному копированию, тратить время и силы на изучение утилиты RMAN может быть невыгодно. В таком случае пользовательские методы резервного копирования, пожалуй, являются идеальным решением, даже несмотря на утрату всех специальных возможностей, встроенных в RMAN.
Резервное копирование всей базы данных Oracle
Делать резервную копию всей базы данных можно как при открытой, так и при закрытой базе данных, если используется режим ARCHIVELOG. В случае режима NOARCHIVELOG делать резервную копию можно только при закрытой базе данных.
Резервное копирование всей закрытой базы данных
Для выполнения резервного копирования при закрытой базе данных, также называемого холодным резервным копированием (cold backup), нужно, чтобы база данных была закрыта аккуратным образом посредством обычной, немедленной или транзакционной остановки.
Подвергать резервному копированию необходимо все файлы, которые требуются для восстановления базы данных Oracle: файлы данных, файлы оперативных журналов повторного выполнения и управляющие файлы. С технической точки зрения, для восстановления базы данных требуется только один управляющий файл, но если файл init.ora или SPFILE ссылается на несколько управляющих файлов, может также потребоваться выполнять резервное копирование и всех мультиплексированных копий управляющих файлов. Сначала получается перечень файлов каждой категории, а потом производится их копирование в целевое место. Ниже в этом блоге более подробно рассказывается о том, как выполняется резервное копирование трех основных видов файлов в процессе резервного копирования всей закрытой базы данных.
Резервное копирование файлов данных
Получить список всех файлов данных, которые имеются в базе данных, можно посредством следующего запроса:
После этого с помощью команды cp, если дело происходит в системе UNIX (или copy, если в Windows) эти файлы данных можно скопировать в любое желаемое место. Для начала их можно копировать в файл операционной системы, а позже — переносить на ленточное устройство, чтобы иметь возможность хранить их за пределами сайта (offsite). Например, в UNIX для выполнения резервного копирования файлов данных служит такая команда:
Резервное копирование файлов оперативных журналов повторного выполнения
Получать список файлов оперативных журналов повторного выполнения можно с помощью показанного ниже запроса:
Поскольку здесь подразумевается, что выполняется резервное копирование всей закрытой базы данных, резервные копии будут иметь согласованный вид, т.е. при остановке базы данных все файлы будут иметь согласованный вид, и не будут нуждаться в выполнении восстановления при запуске. Таким образом, резервные копии оперативных журналов не особо полезны при восстановлении, потому выполнять их резервное копирование не обязательно. Тем не менее, файлы журналов повторного выполнения могут потребоваться для запуска восстановленного экземпляра, а это значит, что иногда их копирование имеет смысл.
Резервное копирование управляющих файлов
Выяснить имена управляющих файлов и место их размещения можно путем выполнения запроса к представлению V$CONTROLFILE:
Простой скрипт холодного резервного копирования
Скрипт для холодного резервного копирования выглядят довольно просто. Из-за того, что резервное копирование осуществляется при закрытой базе данных, весь процесс сводится к копированию всех необходимых файлов соответствующими утилитами операционной системы. В листинге ниже показан пример скрипта холодного резервного копирования.
Выполнение приведенных выше команд приведет к созданию файла cold_backup.ksh, который затем легко превратить в исполняемый скрипт и запланировать его на регулярное выполнение.
Резервное копирование всей открытой базы данных
Между резервным копированием закрытой и открытой базы данных (также называемым горячим резервным копированием) существует большая разница. Процедуры резервного копирования открытой базы данных не исключают вероятность внесения пользователями изменений в данные во время резервного копирования файлов, что требует применения более сложных механизмов на стороне сервера Oracle.
Для полного резервного копирования открытой базы данных необходимо делать резервные копии всех файлов данных, управляющих файлов и архивных журналов повторного выполнения. Для этого можно применять обычные поддерживаемые в операционной системе команды копирования, но из-за того, что база данных фактически находится в рабочем состоянии, помимо них требуется также использовать и дополнительные команды, чтобы резервные копии получались действительными и согласованными. Чтобы разобраться в этом, необходимо понять, что происходит внутри самой базы данных при ее резервном копировании в оперативном режиме.
При первоначальной подготовке табличного пространства к резервному копированию за счет выполнения команды BEGIN BACKUP, Oracle обращает внимание на SCN-номера в заголовках файлов данных и фиксирует (“замораживает”) их. Другими словами, SCN-номера контрольных точек в заголовках файлов данных будут оставаться со своими прежними значениями до самого завершения резервного копирования и выполнения команды END BACKUP. Oracle будет продолжать записывать все изменения в файлы данных и файлы журналов повторного выполнения, но файлы журналов повторного выполнения будут заполнятся довольно быстро в большинстве случаев, поскольку Oracle будет записывать весь блок данных, а не только изменения, которые были внесены в него в результате отдельных транзакций, как это делается во время обычного резервного копирования. При внесении пользователями изменений во время оперативного резервного копирования, создание контрольных точек и запись блоков данных на диск будет продолжать происходить обычным образом. По завершении резервного копирования всего табличного пространства Oracle будет увеличивать SCN-номер контрольной точки каждого файла до самого последнего фактического значения SCN.
Важный момент в процессе горячего резервного копирования состоит в том, чтобы в случае, если до завершения резервного копирования возникнет какая-нибудь авария, всегда можно было выполнить восстановление на основе контрольной точки, которая была зафиксирована при первоначальном переводе табличного пространства в режим резервного копирования. Номер SCN, который замораживается в заголовках файлов, размещается там сразу же после контрольной точки, что приводит к сбрасыванию всех измененных записей из буфера в файлы данных. Во время процедур горячего резервного копирования в журналах повторного выполнения наблюдается приличный объем активности, большая часть которой связана с обработкой проблемы так называемых раздробленных блоков (fractured block). На момент оперативного резервного копирования определенного блока Oracle, этот блок может находиться в процессе выполнения в него записи. А это значит, что данные в создаваемой для него резервной копии могут получаться несогласованными, из-за записывания одной их части до, а второй — уже после внесения изменения. Генерируемый подобным образом несогласованный блок и называется раздробленным. Oracle приходится копировать весь такой блок в файл журнала повторного выполнения для обеспечения возможности создания его согласованной версии позже в будущем, если окажется, что он действительно был разбит во время процесса горячего резервного копирования.
Ниже перечислены шаги типичного процесса горячего резервного копирования.
Команда END BACKUP заставляет Oracle вывести все табличные пространства из режима резервного копирования.
На заметку! Утилита RMAN не переводит табличные пространства ни в режим начала резервного копирования (BEGIN BACKUP), ни в режим завершения резервного копирования (END BACKUP). Сеанс сервера Oracle выполняет проверку заголовков и нижних колонтитулов в блоке данных для выяснения, не был ли тот раздроблен. Если был, тогда сервер RMAN просто считывает блок данных снова, чтобы получить его в согласованном виде.
При выполнении полного оперативного резервного копирования базы данных, функционирующей в режиме ARCHIVELOG, нужно обязательно делать резервную копию ее управляющего файла посредством специальной команды BACKUP CONTROLFILE TO ‘имя_файла‘, как показано ниже:
Во время восстановления следует обязательно использовать сделанную подобным образом резервную копию управляющего файла во избежание проблем, которые могут возникнуть при попытке использовать обычную копию этого файла, сгенерированную операционной системой.
Как не трудно было заметить, переводить отдельно каждое табличное пространства в режим горячего резервного копирования не требуется. Начиная с Oracle Database 10g, переводить сразу все файлы данных в режим оперативного резервного копирования можно единственной командой. При этом, однако, нужно обязательно проверять, что база данных функционирует в режиме архивации журналов (ARCHIVELOG), смонтирована и открыта.
Теперь вам известно, как работает механизм оперативного резервного копирования. В листинге ниже приведен пример скрипта полного оперативного резервного копирования, который будет динамически делать резервную копию на диске для всех табличных пространства в базе данных, которую позже, при желании, можно легко скопировать на ленту.
Генерируемый в буферном файле скрипт hot_backup.sh будет выглядеть следующим образом:
Как и скрипт холодного резервного копирования базы данных Oracle, скрипт горячего резервного копирования тоже может делаться частью скрипта оболочки и запускаться в заранее определенное время.
Частичное резервное копирование базы данных
Выполнять резервное копирование сразу всей базы данных вовсе не обязательно. Можно провести резервное копирование только какой-нибудь ее части, например, табличного пространства или вообще одного файла данных. Обычно частичное резервное копирование базы данных допускается выполнять только тогда, когда база данных функционирует в режиме ARCHIVELOG, однако существует и пара исключений из этого правила. В частности, если база данных функционирует в режиме NOARCHIVELOG и содержит какие-то доступные только для чтения или доступные обычно лишь в автономном режиме табличные пространства, разрешается выполнять резервное копирование только этих табличных пространств.
Выполнять резервное копирование табличного пространства можно как в оперативном, так и в автономном режиме, в зависимости от существующих потребностей. Для начала давайте рассмотрим пример выполнения резервного копирования табличного пространства в автономном режиме. В таком случае сначала понадобится перевести табличное пространство в автономный режим, а затем выполнить резервное копирование файлов, из которых оно состоит:
Здесь видно, что в данном примере табличному пространству USERS принадлежит только один файл данных. Следовательно, для того, чтобы выполнить резервное копирование этого табличного пространства, достаточно выполнить резервное копирование просто этого файла данных. Но сначала потребуется перевести табличное пространство в автономный режим, исключив на время резервного копирования всякую вероятность получения пользователями доступа к любому из его файлов данных:
Теперь можно спокойно использовать утилиту операционной системы наподобие cp (или copy, если дело происходит в системе Window) для выполнения резервного копирования принадлежащего табличному пространству USERS файла данных:
Закончив копировать все файлы данных, которые принадлежат табличному пространству (в данном примере имеется только один файл данных), нужно снова перевести табличное пространство в оперативный режим:
Для того чтобы выполнить резервное копирование табличного пространства без его перевода в автономный режим, сначала необходимо перевести его в режим резервного копирования, чтобы уведомить базу данных о начале процесса оперативного резервного копирования:
Далее нужно скопировать принадлежащий этому табличному пространству файл или файлы данных:
И, наконец, напоследок необходимо выполнить следующую команду, уведомив базу данных о завершении процесса оперативного резервного копирования:
Мониторинг выполнения пользовательских операций оперативного резервного копирования
Следить за выполнением операций оперативного резервного копирования и устранять возникающие в них неполадки помогают несколько динамических представлений производительности. Операции оперативного резервного копирования могут занимать приличное количество времени, в зависимости от размера базы данных. Иногда бывает так, что процесс резервного копирования останавливается или зависает до завершения. Поэтому администратору баз данных обязательно следует знать о тех шагах, которые необходимо выполнять в подобных случаях. В табл. 15.1 перечислены все наиболее важные представления V$, которые помогают проводить мониторинг и диагностику проблем в операциях резервного копирования.