Команда oracle для сохранения изменений

Обновлено: 01.07.2024

Владимир Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface Ltd.

Введение

Программа RMAN появилась в версии 8 СУБД Oracle как единое для всех платформ средство организации резервного копирования и восстановления данных на физическом уровне. По отношению к традиционным базовым возможностям резервирования и восстановления в Oracle, у программы RMAN есть некоторые преимущества, делающие ее в некоторых ситуациях (например, при больших объемах данных) практически незаменимой. К сожалению, наличие этих преимуществ не лишает RMAN и ряда существенных недостатков: собственной системы понятий, собственного командного языка и интерфейса общения с администратором. И то, и другое, и третье выполнено в плохих традициях разработчиков Oracle – не вполне логично, запутано и непоследовательно, – что затрудняет освоение этой программы. Назначение этой статьи – помочь перешагнуть через эти недостатки ради выгод, которые можно извлечь из RMAN.

Возможности RMAN

Возможности RMAN включают следующее:

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

Уровни выполнения резервного копирования/восстановления с помощью RMAN:

база данных
табличные пространства
файлы табличных пространств
служебные файлы БД (контрольные, архивные)

В число основных понятий RMAN входят следующие:

-	Канал (channel). Серверный процесс, возникающий при установлении связи с устройством ввода/вывода (диск или магнитная лента) для записи или чтения файлов резервирования
-	Целевая БД (target database). БД, для которой снимается резервная копия, или которая восстанавливается по ранее снятой копии
-	Каталог (recovery catalog). Отдельная схема в БД (чаще в отдельной БД), которую можно заводить для хранения служебная информации о целевых базах, снятых копиях и процедурах восстановления. Альтернативой каталогу является индивидуальная работа с каждой целевой БД, когда служебная информация помещается в контрольный файл этой БД.
-	Копия (RMAN backup). Резервная копия какого-нибудь элемента БД, получаемая командой RMAN backup.
-	Резервный набор (backup set). Логически именует набор файлов, сформированных во время резервного копирования.
-	Резервный файл (backup piece). Двоичный файл с резервной информацией.

Синтаксис командного языка RMAN в версии 9 имеет определенные отличия от версии 8, но все основные конструкции сохранены. Кроме этого, в RMAN для версии 9 допускается целый ряд упрощений записи команд.

Возможность работы с RMAN включена также в последние версии OEM без необходимости знания командного языка.

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

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

Простейший пример снятия резервной копии (холодное копирование – вся БД – работа без каталога) иллюстрируется следующей последовательностью команд (здесь команда CONNECT TARGET соединяет RMAN с СУБД версии 8):

RMAN NOCATALOG
RMAN> CONNECT TARGET internal/oracle
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> RUN 2> ALLOCATE CHANNEL d1 TYPE DISK;
3> BACKUP FULL FORMAT 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus'
4> DATABASE;
4> >
RMAN>

В каталоге D:\ORACLE\ORADATA\TEACHER\RMAN-BACKUP появился файл RMAN_ TEACHER _02DGA6F0_1_1.BUS (реальное имя может варьироваться). Теперь можно удалить файлы с табличными пространствами и выполнить восстановление:

RMAN> RUN 2> ALLOCATE CHANNEL d1 TYPE DISK;
3> RESTORE DATABASE;
4> RECOVER DATABASE;
5> ALTER DATABASE OPEN;
6> >

База восстановлена и открыта.

Упрощения в версии 9

В версии RMAN для версии 9 описанное выше резервирование можно было бы выполнить так:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';

а восстановление так:

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

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

Кроме этого в версии 9 появилась команда CONFIGURE, с помощью которой (помимо прочего) можно связать с каналом направление и маску имени файлов для резервного набора:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';

В этом случае команда снятия резервной копии может выглядеть еще проще:

RMAN> BACKUP DATABASE;

Резервирование файлов базы данных

Горячее полное резервирование БД

-	может выполняться в состоянии СУБД OPEN
-	может выполняться только при включенном режиме архивирования журналов

Если выполнено и то, и другое, сами действия по резервированию выглядят как обычно. Пример в синтаксисе версии 9.0:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование табличного пространства

Пример в синтаксисе версии 9.0:

RMAN> BACKUP TABLESPACE system, users FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование отдельных файлов табличного пространства

Пример в синтаксисе версии 9.0:

RMAN> BACKUP DATAFILE 1, 2;

RMAN> BACKUP FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus'
3> 'd:\oracle\oradata\teacher\system01.dbf’,
4> 'd:\oracle\oradata\teacher\users01.dbf’;

Резервирование временного табличного пространства

Если временное табличное пространство локально управляемо, оно автоматически не резервируется. Восстанавливать (воссоздавать) при необходимости его придется самостоятельно.

Резервирование контрольного файла

Обычное резервирование контрольного файла приходится выполнять отдельно. Пример явного резервирования в синтаксисе версии 9.0:

RMAN> BACKUP CURRENT CONTROLFILE;

В версии 9 можно, однако, перевести RMAN в режим, когда копии контрольного файла будут сниматься автоматически при всякой выдаче команд BACKUP или COPY:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Резервирование оперативных файлов журнала

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

а) копировать отдельно, либо
б) перед полным резервированием БД отправлять в архив.

Резервирование архивных копий журнала

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

RMAN> BACKUP ARCHIVELOG ALL;

Пример того, как в версии 9.0 архивные файлы можно включить в состав резервного набора БД:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%U.bus' PLUS ARCHIVELOG;

Резервирование изменений (неполное резервирование)

Для резервирования изменений в Oracle используется традиционная многоуровневая модель с конкретным числом уровней копии 5 (от 0 до 4). Точкой отсчета для копирования изменений обязана стать снятая ранее полная копия БД уровня 0.

Пример резервирования блоков, изменившихся со времени резервирования на уровнях 3, 2, 1 и 0 (разностное, «дифференциального» резервирование) в синтаксисе версии 9:

RMAN> BACKUP INCREMENTAL LEVEL 3 DATABASE;

Пример резервирования блоков, изменившихся со времени последнего резервирования на уровнях 2, 1 и 0 (разностно-накопительное, «кумулятивное» резервирование) с пропуском табличных пространств, закрытых для записи (синтаксис версии 9):

RMAN> BACKUP INCREMENTAL LEVEL 3 CUMULATIVE DATABASE
2> SKIP READONLY;

Разностно-накопительное (кумулятивное) резервирование уровня N отличается от разностного (дифференциального) тем, что резервирует изменения произошедшие после выполнения резервирования всех уровней < N, в то время как просто разностное – изменения, произошедшие после резервирования уровней <= N.

Выдача справочной информации

Выполняется специальными командами LIST и REPORT, а также разновидностью команды RESTORE. Примеры приводятся ниже.

Выдача подробного списка всех снятых копий:

RMAN> LIST BACKUP;

Выдача списка резервных наборов, содержащих табличное пространство SYSTEM:

RMAN> LIST BACKUP OF TABLESPACE system;

Вариант выдачи того же самого, но в обобщенном виде (версия 9):

RMAN> LIST BACKUP OF TABLESPACE system SUMMARY;

Выдача информации о копиях, снятых с архивов журналов:

RMAN> LIST BACKUP OF ARCHIVELOG ALL;

Выдача резервных копий, оказавшихся устаревшими:

RMAN> REPORT OBSOLETE;

Выдача файлов с данными БД, для восстановления которых потребуются архивы журналов 2-х дневной давности и более:

RMAN> REPORT NEED BACKUP DAYS 2 DATABASE;

Те же сведения, но только для пространства SYSTEM:

RMAN> REPORT NEED BACKUP DAYS 2 TABLESPACE system;

Выдача информации о том, годны ли файлы резервного набора для восстановления:

Удаление резервных копий

Выполняется командой DELETE. В простейшем варианте удаление устаревших копий может выглядеть так:

RMAN> DELETE OBSOLETE;

Обратите внимание, что RMAN удалил ненужные файлы резервных наборов. Вам не нужно автоматизировать удаление старых файлов, как раньше!

Файлы резервных наборов могут оказаться испорченными или поврежденными. Это можно отметить в справочнике (в контрольном файле или в каталоге RMAN) с помощью команды CROSSCHECK, в результате чего они будут помечены там как EXPIRED. Последующая команда DELETE EXPIRED удалит ставшие ненужными из-за этого файлы:

RMAN> CROSSCHECK BACKUP;
…
RMAN> DELETE EXPIRED BACKUP OF DATABASE;
…
RMAN> DELETE BACKUP OF DATABASE;

Более сложный пример удаления устаревших резервных копий:

RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 14 DAYS;

Восстановление данных

NOMOUNT: для восстановления контрольных файлов БД (фактически – СУБД)

MOUNT: для восстановления БД целиком или табличного пространства SYSTEM

OPEN: для восстановление табличных пространств, помимо SYSTEM (в этом случае перед процедурой восстановления само табличное пространство потребуется перевести в состояние OFFLINE).

Восстановление до момента сбоя («последнего момента»)

Некоторые примеры восстановления:

RMAN> RECOVER DATABASE;

RMAN> RECOVER TABLESPACE users;

RMAN> RECOVER DATAFILE 'd:\oracle\oradata\teacher\users01.dbf’;

RMAN> RESTORE CONTROLFILE;

RMAN> RUN 2> SET ARCHIVELOG DESTINATION TO ‘d:\oracle\oradata\archive’;
3> RESTORE ARCHIVELOG ALL; >

Восстановление пространств, закрытых на запись:

RMAN> SQL "ALTER TABLESPACE lookup_data OFFLINE";
RMAN> RECOVER TABLESPACE lookup_data;
RMAN> SQL "ALTER TABLESPACE lookup_data ONLINE";

Восстановление до указанного момента в прошлом

БД, работающую в режиме архивирования журнала, можно восстанавливать до определенного указанного момента с помощью фраз UNTIL . Пример:

Восстановление БД (вторая и третья строчки выше) можно выполнить и в SQL*Plus:

SQL > RECOVER DATABASE UNTIL CANCEL;
SQL> ALTER DATABASE OPEN RESETLOGS;

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

Автоматизация задач

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

Пусть в файле listbackup.rcm находятся строки:

CONNECT TARGET /
LIST BACKUP;
EXIT

Тогда следующие два эквивалентные по результату обращения в ОС приведут ко входу в RMAN, выполнению этого сценария и выходу:

RMAN CMDFILE=listback.rcm NOCATALOG

RMAN @listback.rcm NOCATALOG

При использовании каталога RMAN возможно к тому же использование хранимого сценария:

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

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

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

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

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

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

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

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

Выборка данных с последующим сохранением в произвольном формате;
Снимок состояния файлов БД и сохранение журналов.

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

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

Двоичный формат	Текстовый формат
Oracle	DataPump Export/DataPump Import Export/Import	SQLPlus/SQLLoader
PostgreSQL	pg_dump, pg_dumpall/pg_restore	pg_dump, pg_dumpall/psql
Microsoft SQL Server	bcp	bcp
DB2	unload/load	unload/load
MySQL	mysqldump, mysqlpump/mysql, mysqlimport
MongoDB	mongodump/mongorestore	mongoexport/mongoimport
Cassandra	nodetool snapshot/sstableloader	cqlsh

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

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

процесс выгрузки создаёт значительную нагрузку на систему-источник;
выгрузка занимает много времени – к моменту окончания выгрузки она станет уже неактуальной;
сделать согласованную выгрузку всей базы данных при высокой нагрузке практически невозможно, поскольку СУБД вынуждена хранить снимок своего состояния на момент начала выгрузки. Чем больше транзакций совершено с момента начала выгрузки, тем больше объём снимка (неактуальных копий данных в PostgreSQL, пространства undo в Oracle, tempdb в Microsoft SQL Server и т. п.);
выгрузка сохраняет логическую структуру данных, но не сохраняет их физическую структуру – параметры физического хранения таблиц, индексы и др.; восстановление индексов при загрузке может занимать значительное время.

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

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

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

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

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

«холодная» копия иногда должна включать в себя и журналы. Методы определения журналов, которые должны попасть в «холодную» копию, индивидуальны для каждой СУБД. Например, в Oracle необходимо скопировать так называемые online redo, то есть фиксированное количество журнальных файлов в специальном каталоге, причём даже тогда, когда база остановлена корректно. В PostgreSQL нужно сохранить все журналы начиная с журнала, содержащего последнюю контрольную точку, информация о которой содержится в управляющем файле.
каталог базы данных может содержать достаточно большие файлы временных табличных пространств, которые не обязательно включать в резервную копию. Кстати, это замечание верно и для «горячего» резервного копирования.

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

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

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

в Oracle это отдельная команда ALTER DATABASE/TABLESPACE BEGIN BACKUP;
в PostgreSQL – функция pg_start_backup();
в Microsoft SQL Server и DB2 подготовка к резервному копированию выполняется неявно в процессе выполнения команды BACKUP DATABASE;
в MySQL Enterprise, Percoba Server, Cassandra и MongoDB подготовка неявно выполняется внешней утилитой – mysqlbackup, Percona XtraBackup, OpsCenter и Ops Manager соответственно.

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

Запоминается момент начала резервного копирования; резервная копия должна будет содержать журналы базы данных начиная с этого момента.
Выполняется контрольная точка, то есть все изменения, которые произошли в страницах данных до запомненного момента, сбрасываются на диск. Это гарантирует, что журналы до момента начала резервного копирования при восстановлении не потребуются.
Включается особый режим журналирования: если страница данных изменилась в первый раз после загрузки с диска, то вместо того, чтобы записывать в журнал изменения страницы, база запишет туда страницу целиком. При выполнении подготовительной процедуры все страницы вытесняются на диск, и поэтому при первом изменении блок всегда будет записан в журнал целиком. Но если в процессе резервного копирования страница снова будет вытеснена на диск, то следующее её изменение также приведёт к появлению в журнале полной копии страницы. Это гарантирует, что если вдруг при копировании файла с данными страница получится некорректной, применение журнала сделает его корректной вновь.
Блокируется изменение заголовков файлов данных, то есть той его части, изменения которой не отражаются в журналах. Это гарантирует, что заголовок будет скопирован корректно, а потом к файлу данных корректно будут применены журналы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Дифференциальная	Кумулятивная
Oracle	Differential	Cumulative
PostgresPro	Incremental	—
Microsoft SQL Server	—	Differential
IBM DB2	Delta	Incremental
MySQL Enterprise	Incremental	Differential
Percona Server	Incremental

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

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

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

создание полной копии и вычисление разницы с предыдущей полной копией;
разбор журналов, создание списка изменённых страниц и резервирование страниц, включённых в список;
запрос изменённых страниц в базе данных.

Второй и третий способ отличаются механизмом определения списка изменённых страниц. Разбор журналов более ресурсоёмкий, плюс для его реализации необходимо знать структуру журнальных файлов. Спросить у самой базы, какие именно страницы изменились, проще всего, но для этого ядро СУБД должно иметь функциональность отслеживания изменённых блоков (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 поддерживает очень мощную и надежную модель транзакций. Код приложения определяет логическую последовательность выполняемых операций, результаты которой должны быть либо сохранены командой COMMIT , либо отменены командой ROLLBACK.

Транзакция начинается неявно с первой команды SQL , выполняемой после команды COMMIT или ROLLBACK (или с начала сеанса) или же после команды ROLLBACK TO SAVEPOINT . Для управления транзакциями PL/SQL предоставляет набор команд:

COMMIT — сохраняет (фиксирует) все изменения, внесенные со времени выполнения последней команды COMMIT или ROLLBACK , и снимает все блокировки.
ROLLBACK — отменяет (откатывает) все изменения, внесенные со времени выполнения последней команды COMMIT или ROLLBACK , и снимает все блокировки.
ROLLBACK TO SAVEPOINT — отменяет все изменения со времени установки последней точки сохранения и снимает все блокировки, установленные в этой части кода.
SAVEPOINT — устанавливает точку сохранения, после чего становится возможным частичный откат транзакции.
SET TRANSACTION — позволяет начать сеанс чтения или чтения-записи, установить уровень изоляции или связать текущую транзакцию с заданным сегментом отката.
LOCK TABLE — позволяет заблокировать всю таблицу в указанном режиме. (По умолчанию к таблице обычно применяется блокировка на уровне строк.)

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

Команда COMMIT

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

Ключевое слово WORK не обязательно — оно только упрощает чтение кода.

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

Обратите внимание: команда COMMIT снимает все блокировки таблиц, установленные во время текущего сеанса (например, для команды SELECT FOR UPDATE ). Кроме того, она удаляет все точки сохранения, установленные после выполнения последней команды COMMIT или ROLLBACK .

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

Все команды в следующем фрагменте являются допустимыми применениями COMMIT :

Команда ROLLBACK

Команда ROLLBACK отменяет (полностью или частично) изменения, внесенные в базу данных в текущей транзакции. Для чего это может потребоваться? Например, для исправления ошибок:

«Нет, Нет! Я хотел удалить только те заказы, которые были сделаны до мая 2005 года!» Нет проблем — достаточно выполнить команду ROLLBACK. Что касается программирования приложений, в случае возникновения проблем откат позволяет вернуться к исходному состоянию.

Синтаксис команды ROLLBACK :

Существует две основные разновидности ROLLBACK : без параметров и с секцией TO, указывающей, до какой точки сохранения следует произвести откат. Первая отменяет все изменения, выполненные в ходе текущей транзакции, а вторая отменяет все изменения и снимает все блокировки, установленные после заданной точки сохранения. (О том, как установить в приложении точку сохранения, рассказано в следующем разделе.) Имя точки сохранения представляет собой необъявленный идентификатор Oracle . Это не может быть литерал (заключенный в кавычки) или имя переменной.

Все команды ROLLBACK в следующем фрагменте действительны :

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

Непосредственно перед выполнением команды INSERT , UPDATE , MERGE или DELETE PL/SQL автоматически устанавливает неявную точку сохранения, и если команда завершается ошибкой, выполняется автоматический откат до этой точки. Если в дальнейшем в ходе выполнения команды DML происходит сбой, выполняется автоматический откат до этой точки. Подобным образом отменяется только последняя команда DML .

Команда SAVEPOINT

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

Область действия точки сохранения не ограничивается блоком PL/SQL, в котором она установлена. Если в ходе транзакции имя точки сохранения используется повторно, эта точка просто «перемещается» в новую позицию, причем независимо от процедуры, функции или анонимного блока, в котором выполняется команда SAVEPOINT . Если точка сохранения устанавливается в рекурсивной программе, на самом деле на каждом уровне рекурсии она задается заново, но откат может быть возможен только к одной точке — той, что установлена последней.

Команда SET TRANSACTION

Команда SET TRANSACTION позволяет начать сеанс чтения или чтения-записи, установить уровень изоляции или связать текущую транзакцию с заданным сегментом отката. Эта команда должна быть первой командой SQL транзакции и дважды использоваться в ходе одной транзакции не может. У нее имеются четыре разновидности.

SET TRANSACTION READ ONLY — определяет текущую транзакцию доступной «только для чтения». В транзакциях этого типа всем запросам доступны лишь те изменения, которые были зафиксированы до начала транзакции. Они применяются, в частности, в медленно формируемых отчетах со множеством запросов, благодаря чему в них часто используются строго согласованные данные.
SET TRANSACTION READ WRITE — определяет текущую транзакцию как операцию чтения и записи данных в таблицу.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE | READ COMMITTED — определяет способ выполнения транзакции, модифицирующей базу данных. С ее помощью можно задать один из двух уровней изоляции транзакции: SERIALIZABLE или READ COMMITTED . В первом случае команде DML , пытающейся модифицировать таблицу, которая уже изменена незафиксированной транзакцией, будет отказано в этой операции. Для выполнения этой команды в инициализационном параметре COMPATIBLE базы данных должна быть задана версия 7.3.0 и выше.При установке уровня READ COMMITED команда DML , которой требуется доступ к строке, заблокированной другой транзакцией, будет ждать снятия этой блокировки.
SET TRANSACTION USE ROLLBACK SEGMENT имя сегмента — назначает текущей транзакции заданный сегмент отката и определяет ей доступ «только для чтения». Не может использоваться совместно с командой SET TRANSACTION READ ONLY .

Механизм сегментов отката считается устаревшим; вместо него следует использовать средства автоматического управления отменой, введенные в Oracle9i.

Команда LOCK TABLE

Команда блокирует всю таблицу базы данных в указанном режиме. Блокировка запрещает или разрешает модификацию данных таблицы со стороны других транзакций на то время, пока вы с ней работаете. Синтаксис команды LOCK TABLE :

LOCK TABLE список_таблиц IN режим_блокировки MODE [NOWAIT];

Здесь список таблиц — список из одной или нескольких таблиц (локальных таблиц/пред- ставлений или доступных через удаленное подключение), а режим блокировки — один из шести режимов: ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE.

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

Примеры допустимых команд LOCK TABLE :

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

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

Обязательные файлы:

Необязательные файлы:

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

Файлы данных (Data Files)

Все данные в базе данных Oracle сохраняются в файлах данных. Все таблицы, индексы, триггеры, последовательности, программы на PL/SQL, представления - все это находится в файлах данных. И хотя эти и другие объекты базы данных логически содержатся в табличных пространствах, в действительности они сохраняются в файлах на жестком диске компьютера.

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

У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.

Данные в файлы вносятся исключительно средствами Oracle.

Следующий запрос, покажет, где находятся файлы данных.

Оперативные файлы журналов повтора (Online Redo Log Files)

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

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

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

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

Управляющие файлы (Control Files)

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

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

Файлы параметров pfile, spfie (Parameter Files)

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

spfile - бинарный файл, который используется сервером Oracle при старте.
pfile - текстовый файл с параметрами, будет использоваться при старте, если не будет найден spfile.

При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.

Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.

Как я могу узнать, что моя база данных использует PFILE или SPFILE?

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

Архивные файлы журналов повтора (Archive Log Files)

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

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

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

Alert log и трассировочные файлы (trace file)

При работе базы данных события и ошибки регистрируются в текстовых файлах на сервере базы данных. Файл журнала предупреждений (alert log) нужен администратору базы данных для отслеживания важнейших действий с базой данных - наподобие открытия и закрытия базы данных, установления параметров загрузки базы данных и переключения оперативных журналов повтора. Также в эти файлы записываются многие ошибки базы данных для последующего расследования их причин. Любые структурные изменения базы данных также регистрируются в файле журнала предупреждений.

Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.

Файлы паролей (Password File)

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

Tags: Oracle Database, Файлы базы данных Oracle,

Oracle DBA

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

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

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