Профессионалу администратору

Аруп Нанда

Oracle Database 10g:
20 наиболее привлекательных для АБД возможностей
(Oracle Database 10g: The Top 20 Features for DBAs
by Arup Nanda)
Часть IV

Источник: журнал Oracle Magazine,
OTN Technical Articles ( http://www.oracle.com/oramag/webcolumns/windex.html),
http://otn.oracle.com/pub/articles/10gdba/index.html

В течение 20 недель Arup Nanda, “Лучший АБД 2003 года” по версии журнала Oracle Magazine, расскажет о наиболее, по его мнению, привлекательных для администраторов баз данных возможностях Oracle Database 10g.

[От редакции OM/RE: мы продолжаем публикацию переводов этих заметно окрашенных индивидуальной авторской интонацией небольших по объему заметок, но удивительно емких по содержаниею и точных по существу рассматриваемых вопроcов. В каждом выпуске журнала предполагается по две-четыре “недели” от Arup Nanda. В этот раз мы предлагаем вниманию читателей "Неделю 8" и "Неделю 9".]

План публикаций

Week 1	Flashback Versions Query	Ретроспективные версии запроса
Week 2	Rollback Monitoring	Мониторинг отката
Week 3	Tablespace Management	Управление табличными пространствами
Week 4	Oracle Data Pump	Утилита Oracle Data Pump
Week 5	Flashback Table	Ретроспективная таблица
Week 6	Automatic Workload Repository	Автоматизированный репозиторий рабочей нагрузки
Week 7	SQL*Plus Rel 10.1	Утилита SQL*Plus выпуска 10.1
Week 8	Automatic Storage Management	Автоматическое управление памятью хранения
Week 9	RMAN	Утилита RMAN
Week 10	Auditing	Аудит
Week 11	Wait Interface	Интерфейс ожидания
Week 12	Materialized Views	Материализованные представления
Week 13	Enterprise Manager 10g	Утилита Enterprise Manager 10g
Week 14	Virtual Private Database	Виртуальная частная база данных
Week 15	Automatic Segment Management	Автоматическое управление сегментами
Week 16	Transportable Tablespaces	Транспортабельные табличные простанства
Week 17	Automatic Shared Memory Management	Автоматическое управление разделяемой памятью
Week 18	SQL Advisor and ADDM	SQL-консультант и ADDM
Week 19	Scheduler	Планировщик
Week 20	Best of the Rest	Лучшее напоследок

Неделя 8

Автоматическое управление памятью хранения
(Automatic Storage Management)

Оригинал: http://otn.oracle.com/pub/articles/10gdba/week8_10gdba.html

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

Вот Вы получили совершенно для новой базы данных Oracle новый сервер и подсистему памяти хранения. Что доселе, кроме конфигурации операционной системы, являлось наиболее важной задачей до создания базы данных? Очевидно, что это - распределение памяти хранения, или более конкретно, определение уровня защиты и затем построение требуемых RAID-наборов (Redundant Array of Inexpensive Disks - массив независимых дисковых накопителей с избыточностью).

Распределение памяти хранения занимает существенное время в большинстве инсталляций баз данных. Установка на нуль (zeroing - обнуление) в определенной (из множества возможностей) дисковой конфигурации требует тщательного планирования и анализа, и, самое важное, хорошего знания технологии памяти хранения (storage technology), менеджеров томов (volume managers) и файловых систем. Задачи конфигурирования на этой стадии могут быть в самом общем виде сформулированы следующим образом (замечу, что этот список – просто список типовых задач, которые будут уточняться в процессе конфигурации):

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

Заметим, однако, что все эти задачи - располосование (striping), зеркалирование (mirroring), логическое формирование файловой системы (logical filesystem building) – выполняются для обслуживания только одного типа сервера, нашей Oracle Database. Поэтому может быть для Oracle имеет смысл предложить какие-нибудь собственные методы, чтобы упростить и усовершенствовать этот процесс?

Oracle Database 10g именно это и делает. Новый, весьма впечатляющий механизм ASM (Automatic Storage Management - Автоматическое управление памятью хранения) позволяет АБД выполнять многие из вышеупомянутых задач полностью в пределах структуры Oracle. При использовании ASM можно трансформировать группу (bunch) дисков в высоко масштабированное (поставим ударение на слово “масштабирование”) и высоко производительное устройство управления файловой системой/томом (filesystem/volume manager), которое использует поставляемое с Oracle Database 10g программное обеспечение без дополнительной платы. И поэтому Вам не нужны познания экспертного уровня по дискам менеджерам томов или в управлении файловыми системами.

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

Что такое ASM?

Предположим, что имеется 10 дисков, которые используются с базой данных. При использовании ASM ничего не нужно создавать на стороне ОС; этот механизм группирует набор физических дисков в логический объект, известный как diskgroup (дисковая группа). Дисковая группа (diskgroup) по аналогии с файловой системой располосовывается (и, возможно, зеркалируется), но с существенными различиями: она не является универсальной файловой системой для сохранения файлов пользователей, и не буферизируется (not buffered). В силу последнего дисковая группа предлагает преимущество прямого доступа к своему пространству (как к “сырое” (raw device – неформатизированное) устройство), обеспечивая при этом удобство и гибкость файловой системы.

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

Напротив, ASM использует специальный экземпляр Oracle (Oracle Instance), который отображает карту файловых экстентов (extent - участок) на физические дисковые блоки. Эта конструкция, быстрая в локализации экстентов файлов, помогает при добавлении или удалении дисков, потому что не требуется координировать местоположение экстентов файлов. Этот специальный экземпляр ASM, что аналогично и для других файловых систем, должен функционировать для обеспечения ASM и не может изменяться пользователем. Один экземпляр ASM может обслуживать несколько экземпляров баз данных Oracle на одном и том же сервере.

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

Итак, кратко, что является преимуществами ASM?

• Disk Addition (Добавление дисков) - добавление дисков становится очень простым. Не возникает времени простоя, участки файлов перераспределяются автоматически.
• I/O Distribution (Дистрибутивный ввод/ вывод) – ввод/вывод автоматически разбрасывается по всем доступным дискам, без ручного вмешательства, сокращая события горячих точек (hot spot).
• Stripe Width (Ширина располосования) - располосование может быть как мелко гранулировано (grained - детализировано) для журнальных файлов (Redo Log Files) – по 128К для более быстрой скорости передачи, так и более крупно - для файлов данных - по 1М для одновременного перемещения большого количества блоков).
• Buffering (Буферизация) - файловая система ASM не буферизирована, реализуя прямой ввод/вывод в соответствии с конструкцией.
• Kernelized Asynch I/O (Асинхронный ввод/вывод на уровне ядра) - не существует каких-либо специальных установок для допущения асинхронного ввода/вывода на уровне ядра, без использования “сырых” (raw) [устройств] и сторонних файловых систем типа Veritas Quick I/O.
• Mirroring (Зеркалирование) - может быть легко установлено зеркалирование программного обеспечения, если не доступно зеркалирование на уровне аппаратных средств.

Создание базы данных с ASM. Шаг за шагом

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

1. Установить экземпляр ASM (ASM Instance)

Экземпляр ASM создается Database Creation Assistant, когда определен следующий параметр инициализации:

INSTANCE_TYPE = ASM

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

Для обычных баз данных по умолчанию значение этого параметра - RDBMS.

2. Установить Дисковую Группу

После старта экземпляра ASM надо создать дисковую группу на доступных дисках.

CREATE DISKGROUP dskgrp1
EXTERNAL REDUNDANCY
DISK
'/dev/d1',
'/dev/d2',
'/dev/d3',
'/dev/d4',
... и так далее для всех специфицированных дисков...
;

В команде выше мы приказали базе данных создавать дисковую группу, названную dksgrp1, включающую физические диски, названные /dev/d1, /dev/d2 и так далее. Вместо того чтобы перечислять диски отдельно, в предложении DISK можно также определить имена дисков с использованием групповых символов (wildcards) следующим образом:

DISK '/dev/d*'

В команде выше мы определили фразу EXTERNAL REDUNDANCY, которая указывает, что сбой диска сломает дисковую группу. Это обычно имеет место, когда избыточность обеспечена аппаратными средствами, типа зеркалирования. Если нет аппаратных средств, обеспечивающих избыточность, ASM может быть установлен так, чтобы создать специальный набор дисков, названных failgroup (отказоустойчивая группа) в дисковой группе (diskgroup), чтобы обеспечить нужную избыточность.

CREATE DISKGROUP dskgrp1
NORMAL REDUNDANCY
FAILGROUP failgrp1 DISK
'/dev/d1',
'/dev/d2',
FAILGROUP failgrp2 DISK
'/dev/d3',
'/dev/d4';

Хотя так может показаться, d3 и d4 - не зеркала d1 и d2. Скорее, ASM использует все диски, чтобы создать отказоустойчивую систему. Например, некий файл в дисковой группе мог бы быть создан в d1 с копией, поддерживаемой на d4. Другой файл может быть создан на d3 с копией на d2 и так далее. Отказ определенного диска позволяет использовать копию на другом диске так, чтобы операция могла продолжиться. Например, если отказал контроллер обоих дисков d1 и d2, то ASM будет использовать зеркальные копии экстентов отказавшей группы, чтобы поддержать целостность данных.

3. Создать Табличное пространство

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

CREATE TABLESPACE USER_DATA DATAFILE '+dskgrp1/user_data_01' 
SIZE 1024M
/

И это все! Процесс установки закончен.

Обратите внимание, как дисковая группа используется как виртуальная файловая система. Такое решение полезно не только для файлов данных, но и для других типах файлов Oracle. Например, можно создать оперативные файлы журнала (online redo log files), как

LOGFILE GROUP 1 (
    '+dskgrp1/redo/group_1.258.3',
    '+dskgrp2/redo/group_1.258.3'
  ) SIZE 50M,
...

Даже адресаты файлов архивированного журнала могут быть определены в дисковой группе. В значительной степени все связанное с базой данных Oracle может быть создано в дисковых группах, поддерживаемых ASM. Например, резервирование – еще одно значительное использование ASM. Можно установить группу недорогих дисков, чтобы создать область восстановления базы данных, которая будет использоваться RMAN для создания резервных файлов данных и архивированных журналов. (В следующей статье о RMAN в Database 10g, Вы подробно узнаете, как использовать эту возможность в ваших интересах.)

Однако, пожалуйста, имейте в виду, что ASM поддерживает файлы, исключительно созданные для Oracle Database и обрабатываемые только Oracle Database; этот механизм - не замена универсальной файловой системы и не может хранить наборы бинарных и/или плоских файлов.

Дополнительные Ресурсы Как было сказано ранее, эта статья не предназначена, чтобы узнать все, что нужно знать о возможностях ASM и сделать Вас экспертом. Просто слишком велик объем соответствующей информации. Однако, не впадайте отчаяние; существует множество источников, ныне доступных Oracle Technology Network: "Storage on Automatic," by Lannes Morris-Murphy – это превосходное введение в ASM. ASMLib - библиотека возможностей ASM для Linux, расширяет функциональные возможности ASM. На этой странице есть ссылки на технические справочники и исходные тексты для библиотечных модулей. Chapter 12 of the Oracle Database Administrator's Guide 10g Release 1 (10.1) полностью объясняет концепции ASM.

Обслуживание

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

alter diskgroup dskgrp1 add disk '/dev/d5';

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

select * from v$asm_disk;

Эта команда показывает все диски, управляемые экземпляром ASM, для всех клиентских баз данных. Удаление диска из этого множества решается как:

alter diskgroup dskgrp1 drop disk diskb23;

Заключение

Это введение ASM дает главное понимание, что с ASM намного проще управлять файлами базы данных Oracle. Используя совокупность возможностей, Вы легко сможете создать высоко масштабирование и производительные решения по памяти хранения из набора дисков. Любая динамическая среда базы данных требует добавления, перемещения и удаления дисков, и ASM обеспечивает необходимый комплект инструментальных средств, освобождая АБД от этих рутинных задач.

Неделя 9

RMAN

Оригинал: http://otn.oracle.com/pub/articles/10gdba/week9_10gdba.html

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

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

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

Инкрементальное Резервирование Возвращается

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

Эта опция приказывает инструменту копировать только те блоки, которые изменились со времени последнего инкрементального резервирования того же самого уровня или ниже. Например, полное резервирование (level_0) выполняется в 1-й день (day 1), а два инкрементальных (level_1) резервирования выполняются на 2-й (day 2) и 3-й (day 3) дни. Последние два [действия] просто копирует измененные блоки между днями 1 и 2 и днями 2 и 3, а не за все время резерва. Такая стратегия уменьшает размер резерва, требует меньшего количества места и сужает окно резервирования, сокращая количество данных, перемещаемых по сети.

Наиболее важная причина для того, чтобы [регулярно] делать инкрементальные копии, связана особенностями среды хранилищ данных, где много операций выполняются в режиме NOLOGGING, и поэтому изменения данных не сохраняются в архивированных журналах. Следовательно, никакое восстановление (media recovery) не возможно. Принимая во внимание громадные размеры сегодняшних хранилищ данных и тот факт, что большинство данных в них не изменяется, проведение полных резервирований ни желательно, ни практично. Скорее, идеальной альтернативой является выполнение инкрементальных резервирований посредством RMAN.

Так почему же многие АБД делают инкрементальные резервирования сравнительно редко? Одна причина состоит в том, что в Oracle9i и ниже, RMAN просматривает все блоки данных, чтобы определить кандидатов на резервирование. Этот процесс вводит систему в такое большое напряжение, что выполнение инкрементов становится непрактичным.

RMAN в Oracle Database 10g осуществляет инкрементальные резервирования способом, который избавлен от этого недостатка. Он использует файл, аналогичный журналам в файловых системах, чтобы отслеживать блоки, которые изменились с момента последнего резервирования. RMAN читает этот файл и определяет, какие блоки должны быть зарезервированы.

Вы можете запустить в работу этот механизм отслеживания, выполнив следующую команду:

SQL> alter database enable block change tracking using file '/rman_bkups/change.log';

Эта команда создает двоичный файл, названный /rman_bkups/change.log, для целей слежения. И, наоборот, можно отключить прослеживание командой

SQL> alter database disable block change tracking;

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

SQL> select filename, status from v$block_change_tracking;

Ретроспективная (Flash) Область Восстановления

Ретроспективные запросы, введенные в Oracle9i, зависят от табличного пространства отката (undo tablespace), к возврату предыдущей версии. Таким образом, ограничивается способность уходить далеко в прошлое.

Ретроспективное восстановление обеспечивает альтернативное решение, создавая ретроспективные журналы, которые подобны журналам (redo logs), применяются для восстановления базы данных к предшествующему состоянию. Суммируя, Вы создаете ретроспективную область восстановления (flash recovery area)для базы данных, определяете ее размер, и переводите базу данных в режим ретроспективного восстановления следующими SQL-командами:

alter system set db_recovery_file_dest = '/ora_flash_area';
alter system set db_recovery_file_dest_size = 2g;
alter system set db_flashback_retention_target = 1440;
alter database flashback on; 

База данных должна быть в режиме архивирования (rchive log mode) с поддержкой возможности ретроспективности. Этот процесс создает Oracle Managed Files в директории / ora_flash_area общим объемом до 2GB. Изменения базы данных записываются в эти файлы и могут быть использованы, чтобы быстро возвратить базу данных к какой-то точке в прошлом.

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

Ретроспективная область восстановления не должна быть файловой системой или же директорией. Однако, в качестве альтернативы, она может быть дисковой группой (diskgroup) ASM (Automatic Storage Management - Автоматическое Управление Памятью Хранения). В этом случае ретроспективная область восстановления определяется следующим образом:

alter system set db_recovery_file_dest = '+dskgrp1';

Следовательно, используя ASM и RMAN в комбинации, можно сформировать высоко масштабируемую отказоустойчивую систему памяти хранения с использованием дешевых дисков типа Serial ATA или дисков SCSI без дополнительного требуемого программного обеспечения. (Для большего количества подробностей об ASMЕ, см. Неделю 8 .) Это решение не только делает процесс резервирования намного быстрее, но также и достаточно дешевым, чтобы конкурировать с хранением на магнитной ленте.

Дополнительная выгода - защита от ошибок пользователей. Поскольку ASM-файлы не являются истинными файловыми системы, они с меньшей вероятностью будут случайно разрушены АБД и сисадминами (sysadmins).

Инкрементальное Слияние (Merge)

Предположим, имеется следующий график резервирования:

Sunday - Level 0 (full), with tag level_0>
Monday - Level 1 (incremental) with tag level_1_mon>
Tuesday - Level 1 (incremental) with tag level_1_tue 

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

инкрементальных резервирований.

RMAN в Oracle Database 10g радикально изменяет это положение. Теперь ваша команда инкрементального резервирования выглядит следующим образом:

RMAN> backup incremental level_1 for recover of copy with tag level_0 database;

Этим мы приказали RMAN выполнить инкрементальное резервирование level_1 и слить его с полной резервной копией, имеющей метку (тег)

level_0. После выполнения этой команды, level_0 становится полной резервной копией на текущий день.

Итак, во вторник резервная копия с тэгом level_0, объединенная с инкрементальной резервной копией level_1, становится полной резервной копии вторника с идентичной меткой. Точно так же инкремент, полученный в субботу, когда производилось резервирование на диск, будет эквивалентен полной level_0 резервной копии для субботы. Теперь, если база данных аварийно сбоит в субботу, от Вас требуется только восстановить резервную копию level_0 плюс применить несколько файлов архивированного журнала, чтобы принести базу данных в согласованное (consistent) состояние. Нет никакой нужды применять дополнительные инкременталы. Такой подход драматически сокращает время восстановления, скорость резервирования и устраняет потребность в выполнении полного резервирования базы данных.

[Прим. ред. – естественно, до поры до времени, пока слитая инкрементальная копия не станет сравнима по размерам с полной копией.]

Сжатие файлов

Даже применяя хранящиеся на диске резервные копии в ретроспективной области восстановления, все еще имеется существенное ограничение: дисковое пространство. Особенно при перемещениях по сети. В обычных ситуациях всегда желательно создать насколько возможно малый резервный набор. В RMAN от Oracle Database 10g можно заказать сжатие файлов непосредственно в команде резервирования:

RMAN> backup as compressed backupset incremental level 1 database;

Обратите внимание на использование фразы COMPRESSED. Она сжимает файлы резервной копии, применяя важное свойство: при восстановлении RMAN может читать файлы без распаковки.

Чтобы подтверждать сжатие, надо проверить следующее сообщение в выводе:

channel ORA_DISK_1: starting compressed incremental level 1 datafile backupset

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

RMAN> list output;

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3       Incr 1  2M         DISK        00:00:00     26-FEB-04      
        BP Key: 3   Status: AVAILABLE  Compressed: YES  Tag: TAG20040226T100154
        Piece Name: /ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_03w2m3lr_.bkp
  Controlfile Included: Ckp SCN: 318556       Ckp time: 26-FEB-04
  SPFILE Included: Modification time: 26-FEB-04

Как и в любом процессе сжатия, это решение требует дополнительных затрат от центральных процессоров. В качестве компромисса (tradeoff), можно хранить на диске большинство резервных копий RMAN, которые доступны для операций restore-and-recover (возвращения-и-восстанавления). Альтернативно, можно сделать RMAN-резервирования в Physical Standby Database (база данных физического резервирования), которая может быть использована для восстановления первичной базы данных. Такой подход разгрузит ресурсы резервирования (backup resourses) другого хоста.

Перед Прыжком: Предварительный просмотр Восстановления

RMAN в Oracle Database 10g ушел еще один шаг вперед, обеспечивав возможность предварительного просмотра резервных копий, требуемых к исполнению в операциях восстановления.

RMAN> restore database preview;

Листинг 1 показывает выход этой операции. Вы также можете предварительно просмотреть специфические операции восстановления; например:

restore tablespace users preview;

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

Resetlogs и Восстановление

Давайте представим, что потерян текущий поток оперативных журнальных файлов (online redo log files) и Вы должны выполнить неполное восстановление базы данных – довольно редкая, но не невозможная ситуация. Самая большая проблема – resetlogs (переустановка журнальных файлов); после неполного восстановления Вы должны открыть базу данных с фразой resetlogs, которая устанавливает с 1 порядковые номера журнальных файлов, что делает устаревшими в RMAN все более ранние резервные копии, и делая операцию восстановления более сомнительной (challenge).

В Oracle9i и ранее, при восстановлении базы данных к состоянию до resetlogs, нужно было восстанавливать различные воплощения (different incarnation). В Oracle Database 10g не нужно этого делать. Благодаря дополнительной инфраструктуре в управляющем файле, RMAN может теперь быстро использовать все резервные копии, как до, так и после операции resetlogs, чтобы восстановить базу данных Oracle. Нет никакой нужды останавливать (shut down) базу данных, чтобы делать резервную копию. Эта новая возможность означает, что база данных может быть немедленно повторно открыта для пользователей после resetlogs операции.

RMAN - готовность к работе

Усовершенствования RMAN в Oracle Database 10g делают его еще более совершенным инструментом, применяемым в стратегии резервирования. Удобство процесса инкрементального резервирования исключают возможность игнорирования RMAN.

Для получения более подробной информации о RMAN в 10g, см. Главу 4 руководства “Oracle Database Backup and Recovery Basics 10g Release 1 (10.1)”

Листинг 1

Starting restore at 26-FEB-04
using channel ORA_DISK_1

List of Datafile Copies
Key     File S Completion Time Ckp SCN    Ckp Time     Name
------- ---- - --------------- ---------- ------------ ------------------------------------------
1       1    A 26-FEB-04       318556     26-FEB-04    /ora_flash_area/SMILEY10/datafile/o1_mf_system_03w1zyhx_.dbf
2       2    A 26-FEB-04       318556     26-FEB-04    /ora_flash_area/SMILEY10/datafile/o1_mf_undotbs1_03w20qqc_.dbf
3       3    A 26-FEB-04       318556     26-FEB-04    /ora_flash_area/SMILEY10/datafile/o1_mf_sysaux_03w216xl_.dbf
4       4    A 26-FEB-04       318556     26-FEB-04    /ora_flash_area/SMILEY10/datafile/o1_mf_users_03w21p4n_.dbf
Finished restore at 26-FEB-04