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

Аруп Нанда

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

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

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

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

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

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	Лучшее напоследок

Неделя 3.
Оригинал: http://otn.oracle.com/pub/articles/10gdba/week3_10gdba.html

Что в имени? Развитие управления табличными пространствами
(What's in a Name?: Improved Tablespace Management)

Совершенствование управления табличными пространствами происходит вследствие возможности:

• перераспределения объектов из SYSTEM,
• определения табличного пространства по умолчанию для пользователей,
• новому [системному] табличному пространству SYSAUX,
• и, наконец, переименованию табличных пространств.

Сколько раз вы рвали на себе волосы в бессилии создать в табличном пространстве SYSTEM сегмент, непринадлежащий пользователям SYS и/или SYSTEM?

До Oracle9i Database, если DEFAULT TABLESPACE (табличное пространство по умолчанию) не было определено в момент создания пользователя, то по умолчанию оно принималось как SYSTEM. [И поэтому] если пользователь конкретно не называл имя табличного пространства в команде создания сегмента, сегмент создавался в SYSTEM, но только в том случае, если в SYSTEM этому пользователю была предоставлена квота посредством явного гранта или через системную привилегию UNLIMITED TABLESPACE. Oracle9i снял эту проблему, разрешав АБД специфицировать имя временного табличного пространства по умолчанию для всех пользователей, которые создаются без явно прописанной фразы временного табличного пространства.

В Oracle Database 10g вы можете похожим способом специфицировать имя табличного пространства по умолчанию для всех пользователей. При создании базы данных, команда CREATE DATABASE может содержать фразу DEFAULT TABLESPACE <tsname>. После создания вы можете сделать имя табличного пространства значением по умолчанию, выполнив запрос

ALTER DATABASE DEFAULT TABLESPACE <tsname>;

Все пользователи, созданные без фразы DEFAULT TABLESPACE, будут иметь <tsname> как значение по умолчанию. Вы можете изменить имя табличного пространства по умолчанию в любое время с помощью этой команды ALTER, которая позволяет вам специфицировать различные табличные пространства как значения по умолчанию в разных точках [и в разное время].

Важное замечание: при этом для всех пользователей со старым табличным пространством имя табличного пространства по умолчанию меняется на <tsname>, даже если для кого-то из пользователей какое-то другое имя было явно опредлено. Например, предположим, что у пользователей USER1 и USER2 значения табличного пространства по умолчанию - TS1 и TS2, соответственно. Эти имена были явно специфицированы при их создании. Текущее имя табличного пространства по умолчанию для базы данных - TS2, но позже значение по умолчанию табличного пространства для базы данных изменится на TS1. Таким образом, имя табличного пространства по умолчанию для USER2, специфицированное как TS2, изменится на TS1. Остерегайтесь этого эффекта!

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

SELECT PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'DEFAULT_PERMANENT_TABLESPACE';

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

Табличное пространство по умолчанию для вспомогательных (nonessential)схем

Некоторые схемы, например, DBSNMP (пользователь (intelligent agent) анализ-агент), ODM (пользователь (data mining) вычленение данных), напрямую не предназначены для операций конечных пользователей, но они важны для целостности базы данных. Некоторые из этих схем используют табличное пространство SYSTEM, как пространство по умолчанию. И это – еще одна причина быстого увеличения числа объектов внутри этого специального табличного пространства.

Oracle Database 10g представляет новое табличное пространство, названное SYSAUX, которое содержит объекты этих схем. Это табличное пространство создается автоматически при создании базы данных и управляется локально. Единственно что позволено в процессе – это изменение имени файла.

Такой подход гарантирует восстановление, когда повреждение SYSTEM требует полного восстановления базы данных. Объекты в SYSAUX могут быть восстановлены как любые нормальные пользовательские объекты, а база данных сама по себе остается работающей.

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

Вам, как АБД, важно знать правильную процедуру перемещения этих специальных объектов. К счастью, Oracle Database 10g содержит новое представление, избавляющее нас от догадок. Это представление V$SYSAUX_OCCUPANTS, которое предоставляет список имен схем в табличном пространстве SYSAUX, их описания, объем используемого в настоящий момент пространства и способ их перемещения. (см. Таблица 1)

Поясним, [что из представления видно,] что приложение LogMiner занимает 7,488 KB. Оно принадлежит схеме SYSTEM, и для перемещения объектов вам нужно осуществить комплексную процедуру SYS.DBMS_LOGMNR_D.SET_TABLESPACE. Для объектов STATSPACK представление обычно рекомендует метод импорта/экспорта, а для Streams нет перемещающей процедуры. И поэтому это приложение вы не сможете легко переместить из табличного пространства SYSAUX. Столбец MOVE_PROCEDURE показывает корректные перемещающие процедуры по умолчанию для всех инструментарных средств, резидентных в SYSAUX. Перемещающие процедуры могут быть также использованы в обратном направления для возврата объектов назад в табличное пространство SYSAUX.

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

Эти общие для всех хранилищ данных условия, типичны для архитектуры витрин данных (data mart), для транспортировки табличных областей между базами данных. Но принимающая и исходная базы данных не должны иметь табличные области с одинаковыми именами. Если существуют две табличные области с одним и тем же именем, сегменты из принимающего табличного пространства должны быть перемещены в какое-нибудь другое, и табличное пространство должно быть создано заново – эта задача кажется легче, чем на самом деле.

Oracle Database 10g выдвигает удобное решение: вы просто можете переименовать, временно или постоянно, существующее табличное пространство (за исключением SYSTEM и SYSAUX), используя следующую команду:

ALTER TABLESPACE <oldname> RENAME TO <newname>;

Эта особенность может пригодиться во время архивации. Допустим, что у вас для сохранения архива продаж есть разделенная на секции (range-partitioned) таблица, и секции для каждого месяца размещаются в табличных пространствах, названный по именам месяцев. Например, январская секция называется JAN и находится в табличном пространстве с названием JAN. Общая последовательность событий будет примерно такова:

1. Создание самостоятельной (stand alone) таблицы JAN03 из секции JAN, используя команду ALTER TABLE EXCHANGE PARTITION
2. Переименование табличного пространства в JAN03
3. Создание транспортабельного набора для табличного пространства JAN03
4. Переименование табличного пространства JAN03 обратно в JAN
5. Возврат пустой секции обратно в таблицу.

Шаги 1, 2, 4 и 5 простые и не сильно затрачивают такие ресурсы, как undo- и redo- объемы. Шаг 3 просто копирует файл и экспортирует информацию словаря данных для JAN03, что обычно очень простое действие. Если потребуется восстановить ранее заархивированную секцию, эта процедура также проста как повторение того же самого процесса.

Oracle Database 10g весьма интеллектуален при манипулирование переименованиями. Если вы переименовываете табличное пространство, используемое как UNDO, или временное табличное пространство по умолчанию, может возникнуть замешательство. Но база данных автоматически подкорректирует необходимые записи для отражения изменений. Например, изменяя имя табличного пространства по умолчания с USERS на USER_DATA, автоматически изменяется представление DATABASE_PROPERTIES. Перед изменениями запрос:

select property_value from database_properties
where property_name = 'DEFAULT_PERMANENT_TABLESPACE';

возвращает USERS. После этого выполняется

alter tablespace users rename to user_data;

и предыдущий запрос возвращает USER_DATA, так как все ссылки на USERS были изменены на USER_DATA.

Именение имени временного табличного пространства, используемого по умолчанию, происходит также. А изменение табличного пространства UNDO имен производит замену в файле параметров SPFILE, как показано ниже:

SQL> select value from v$spparameter where name = 'undo_tablespace';

VALUE 
--------
UNDOTBS1

SQL> alter tablespace undotbs1 rename to undotbs;

Tablespace altered.

SQL> select value from v$spparameter where name = 'undo_tablespace';

VALUE
--------
UNDOTBS

Заключение

Управление объектами за последние несколько версий Oracle заметно улучшилось. Oracle8i представил возможность перемещения таблиц из одного табличного пространства в другое, Oracle9i Database R2 разрешил переименования столбцов, а теперь – последний рубеж – возможно переименование табличных пространств. Эти усовершенствования значительно упростили задачи, стоящие перед АБД, особенно в средах хранилищ и витрин данных.

Неделя 4
Оригинал: http://otn.oracle.com/pub/articles/10gdba/week4_10gdba.html

Неудержимый экспорт/импорт: утилита Oracle Data Pump
(Export/Import on Steroids: Oracle Data Pump)

Задача перемещения данных получило ощутимую ускорение в виде утилит Oracle Database 10g

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

А теперь откроем Oracle Data Pump [букв. – насос данных от Oracle], новейший и быстрейший наследник экспорт/импорт-инструментария в Oracle Database 10g, разработанный для увеличения скорости процесса во много раз.

Data Pump являет собой полную реконструкцию процесса экспорта/импорт. В отличии от использования обычных команд SQL, Data Pump предоставляет собственный API для на много более быстрой загрузки и дозагрузки данных. В моих тестах я наблюдал рост в 10-15 раз для экспорта в режиме прямого (direct) чтения и в 5 раз для импорта. Кроме того, в отличие от утилиты экспорта, с Data Pump можно извлечь только определенные типы объектов, например, хранимые процедуры.

Экспорт в Data Pump

Новая утилита известна под названием expdp, чтобы отличить ее от exp - изначального экспорта. В примере ниже мы будем использовать Data Pump для экспорта большой таблицы CASES размером около 3GB. Data Pump производит файловые манипуляции на стороне сервера, чтобы создать и прочитать файлы; таким образом, директории используются локально. Поэтому мы используем файловую систему /u02/dpdata1 для управления dump-файлами.

create directory dpdata1 as '/u02/dpdata1';

grant read, write on directory dpdata1 to ananda;

Далее мы экспортируем данные:

Expdp ananda/abc123 tables=CASES directory=DPDATA1

dumpfile=expCASES.dmp job_name=CASES_EXPORT

Давайте проанализируем различные части этой команды. Параметры “userid/password”, “tables” и “dumpfile” самоочевидны. В отличие от изначального экспорта, файл создается на сервере (а не на клиенте). Его расположение определяется с помощью параметра “directory”, принявшего значение DPDATA1, что указывает на директорию /u02/dpdata1, созданную ранее. Этот процесс создает log-файл, который размещается опять же на сервере там, где указывает специфицированный параметр “directory”. По умолчанию используется директория с именем DPUMP_DIR; так что она может быть создана независимо от DPDATA1.

Отметим, что приведенный выше параметр job_name – новый, он не встречается в первоначальном экспорте. Любой запуск (work) Data Pump реализуется как работа (job). Работы (jobs) Data Pump, в отличие от работ (jobs) DBMS, являются просто серверными процессами, которые обрабатывают данные по поручению основного процесса. Этот основной (main) процесс, известный как управляющий мастер-процесс (a master control process), координирует все действия, используя механизм Advanced Queuing (“Расширенное Управление Очередями”). Это происходит с помощью специальной таблицы, созданной в процессе запуска и известной как мастер-таблица. В нашем примере, если вы проверите схему пользователя ANANDA в то время, когда работает expdp, то заметите наличие таблицы CASES_EXPORT, соответствующей параметру job_name . Эта таблица удаляется, когда expdp заканчивает работу.

Instead, it will display the DPE prompt as shown below. The process is now said to be in "interactive" mode:

Мониторинг экспорта

Во время выполнения Data Pump Export (DPE) нажмите Control+C; это остановит вывод сообщений на экране но не остановит сам процесс экспорта. Взамен, как показано далее, немедленно будет выведено DPE-приглашение. Процесс теперь находится в интерактивном режиме:

Export>

Такая возможность позволяет вводить несколько команд при работе DPE. Для того, чтобы получить сводную информацию, в приглашении используется команда STATUS:

Export> status
Job: CASES_EXPORT
  Operation: EXPORT                         
  Mode: TABLE                          
  State: EXECUTING                      
  Degree: 1
  Job Error Count: 0
  Dump file:  /u02/dpdata1/expCASES.dmp 
      bytes written =  2048

Worker 1 Status:
  State: EXECUTING                      
  Object Schema: DWOWNER
  Object Name: CASES
  Object Type: TABLE_EXPORT/TBL_TABLE_DATA/TABLE/TABLE_DATA
  Completed Objects: 1
  Total Objects: 1
  Completed Rows: 4687818

Напомним, что это только отображение [текущей] статистики. Экспорт работает во втором плане. Для продолжения просмотра сообщений на экране используется команда CONTINUE_CLIENT в предложении Export> prompt

Параллельная операция

С помощью параметра PARALLEL можно значительно ускорить работы, использовав более одной нити (thread) экспорта,. Каждая из нитей создает отделенный dumpfile (файл экспорта), так что [список файлов в] параметре dumpfile должен иметь столько элементов, каков уровень заданной параллельности. Правда, вместо того, чтобы каждый раз явно вводить все элементы списка, можно применить групповые символы в качестве имен файлов:

expdp ananda/abc123 tables=CASES directory=DPDATA1 
  dumpfile=expCASES_%U.dmp parallel=4 job_name=Cases_Export

Как видите, параметр dumpfile имеет специальный символ %U, определяющий, что имена файлов, создаваемых по необходимости, будут иметь формат “expCASES_nn.dmp”, где nn - от 01 и завершения работы.

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

Важно разделить I/O каналы для доступа к файлам базы данных и к dumpfile в директориях файловых систем. Иначе, наложение [операций], связанное с управлением работами Data Pump, может перевесить выгоды от использования параллельных нитей и, следовательно, ухудшить производительность. Параллельность будет эффективна, только если число [экспортируемых] таблиц больше уровня параллельности, а сами эти таблицы большие.

Мониторинг баз данных

Вы можете также получить больше информации о работах функционирующего Data Pump из представлений базы данных. Главное представление для мониторинга работы - это DBA_DATAPUMP_JOBS, которое показывает, как много функционирующих процессов (столбец DEGREE) занято в работе. Другое важное представление - DBA_DATAPUMP_SESSIONS, которое вместе с предыдущим представлением и V$SESSION дает SID сессии основного процесса переднего плана.

select sid, serial#
from v$session s, dba_datapump_sessions d
where s.saddr = d.saddr;

Эта команда показывает сессию процесса переднего плана. Больше полезной информации можно получить из журнала alert log. Когда стартует процесс, MCP (master control process) и работающие процессы показываются в журнале alert log примерно следующим образом:

kupprdp: master process DM00 started with pid=23, OS id=20530 to execute - 
 SYS.KUPM$MCP.MAIN('CASES_EXPORT', 'ANANDA');
kupprdp: worker process DW01 started with worker id=1, pid=24, OS id=20532 to execute - 
 SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');
kupprdp: worker process DW03 started with worker id=2, pid=25, OS id=20534 to execute - 
 SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');

Это показывает PID сессии начатой для Data Pump операции. Вы можете найти фактический SID, используя запрос:

select sid, program from v$session where paddr in 
 (select addr from v$process where pid in (23,24,25));

Столбец PROGRAM показывает DM-процесс (для мастер-процесса) или DW (для рабочего процесса), соответственно именам из файла журнала alert log. Если параллельный запрос используется рабочим процессом, скажем для SID 23, вы можете применить представление V$PX_SESSION для того, чтобы его найти. Оно покажет все действующие сессии параллельных запросов для рабочего процесса с SID 23:

select sid from v$px_session where qcsid = 23;

Для прогнозирования времени затрачиваемого на работу дополнительная информация может быть получена из представления V$SESSION_LONGOPS:

select sid, serial#, sofar, totalwork
from v$session_longops
where opname = 'CASES_EXPORT'
and sofar != totalwork;

Столбец “totalwork” показывает общий счетчик работ, из которых счетчик “sofar” показывает, что было сделано до настоящего момента. Это можно использовать для оценки, как долго все это может продолжаться.

Импорт в Data Pump

Импорт данных, производимый Data Pump, действительно, производит впечатление. Для импортирования ранее экспортированных данных используем:

impdp ananda/abc123 directory=dpdata1 dumpfile=expCASES.dmp 
job_name=cases_import

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

Также как в случае Data Pump Export, нажав Control-C в ходе процесса импорта, происходит переход в интеративный режим Date Pump Import (DPI) с подсказкой Import>.

Оперирование на специальных объектах

Постоянно возникает необходимость экспортировать некоторые [хранимые] процедуры какого=либо пользователя, чтобы переправить их в другую базу данных или другому пользователю. В отличие от традиционной утилиты экспорта Data Pump позволяет вам экспортировать только выбранные типы объектов. Например, следующая команда позволяет вам экспортировать только процедуры, и ничего другого: ни таблицы, ни представления, или даже ни функции:

expdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp include=PROCEDURE

Для экспортирования только некоторых выбранных объектов, скажем, функции FUNC1 и процедуры PROC1, вы можете использовать

expdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp 
  include=PROCEDURE:\"=\'PROC1\'\",FUNCTION:\"=\'FUNC1\'\"

Полученный экспортный файл является резервом ресурсов. Вы сможете его использовать позже для создания DDL-скриптов. Специальный параметр SQLFILE позволяет создание DDL скрипт-файла.

impdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp sqlfile=procs.sql

Эта команда в директории, специфицированной DPDATA1, создает файл procs.sql, содержащий скрипты объектов из экспортного файла. Такой подход помогает вам быстро создать исходные объекты в другой схеме.

Используя параметр INCLUDE, можно определять в экспортном файле конкретные включаемые или пропускаемые при импорте объекты. Вы можете использовать оператор INCLUDE=TABLE: “NOT LIKE ‘TAB%’”, чтобы пропустить все таблицы, начинающиеся с TAB. В качестве альтернативы, можно использовать параметр EXCLUDE для пропуска специфических объектов.

Утилита Data Pump может также быть использована для транспортировки табличных пространств используя внешние таблицы; это достаточно мощное средство для переопределения параллельности “на лету”, прикрепления большего числа таблиц к имеющемуся процессу и так далее (для получения большей информации смотрите Oracle Database Utilities 10g Release 1 10.1). Следующая команда выводит список всех доступных параметров экспортной опции Data Pump:

expdp help=y

Аналогично impdp help=y будет показывать все параметры DPI.

Пока работает Data Pump, вы можете приостановить их, написав STOP_JOB в приглашении DPE или DPI, а затем запустить их снова с помощью START_JOB. Эта функциональность очень полезна, если вы сбились во время работы и хотели бы внести коррекцию перед ее продолжением.

Неделя 5.
Оригинал: http://otn.oracle.com/pub/articles/10gdba/week5_10gdba.html

Ретроспективная (Flashback) таблица
(Flashback Table)

Восстановление случайно утраченных таблиц - это несложное использование опции Flashback Table в Oracle Database 10g.

Далее сценарий, который происходит чаще, чем должен: пользователь, конечно же, случайно удаляет очень важную таблицу, и требуется как можно скорее ее восстановить. (В некоторых случаях этим пользователем-неудачником можете оказаться и вы – АБД!)

Oracle9i Database представил концепцию опции Flashback Query для возврата данных “из прошлого”, но это не может вернуть такие DDL-операции, как удаление (dropping) таблиц. В различных базах данных может помочь только обращение к механизму восстановления по времени (point-in-time) табличного пространства, а затем создание заново таблицы в текущей базе данных, используя экспорт/импорт или какой-то другой метод. Эта процедура требует значительных усилий АБД, также как и драгоценного его времени, не говоря об использовании различных базах данных для клонирования.

Примените функцию Flashback Table в Oracle Database 10g, которая делает восстановление утраченной таблицы таким же легким делом, как и выполнение нескольких операторов. Давайте посмотрим как работает эта функция.

А ну-ка удалим таблицу!

Сначала давайте просмотрим таблицы в представленной схеме.

SQL> select * from tab;

TNAME                    TABTYPE  CLUSTERID
------------------------ ------- ----------
RECYCLETEST              TABLE

Теперь мы “случайно” удаляем таблицу:

SQL> drop table recycletest;

Table dropped.

Теперь проверяем статус таблицы.

SQL> select * from tab;

TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
BIN$04LhcpndanfgMAAAAAANPw==$0 TABLE

Таблица RECYCLETEST отсутствует, но отметим наличие новой таблицы BIN$04LhcpndanfgMAAAAAANPw==$0. Произошло следующее: удаленная таблица RECYCLETEST (вместо полного исчезновения) была переименована и получила системное имя. Она остается в том же табличном пространстве, с той же структурой, как и у оригинала. Если у нее были индексы и триггеры, определенные на таблице, они также переименовываются, используя ту же конверсию, что и при переименовании таблицы. Любые зависимые ресурсы такие, как процедуры, становятся инвалидными; триггеры и индексы исходной таблицы переходят к переименованной таблице BIN$04LhcpndanfgMAAAAAANPw==$0,тем самым, сохраняется полная структура удаленной таблицы.

Таблица и ее компоненты помешаются в логический контейнер, известный как “recycle bin”, который аналогичен “корзине” на вашем ПК. Однако, объекты не перемещаются из табличного пространства, где они были ранее, они до поры до времени занимают место там же. “Recycle bin” - это логическая структура, которая заносит в каталог все удаленные объекты. Используйте следующую команду в среде SQL*Plus, чтобы увидеть содержимое этой логическая структура (чтобы сделать это, вам потребуется SQL*Plus 10.1):

SQL> show recyclebin

ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
---------------- ------------------------------ ------------ ------------------
RECYCLETEST      BIN$04LhcpndanfgMAAAAAANPw==$0 TABLE        2004-02-16:21:13:31

Запрос показывает оригинальное имя таблицы RECYCLETEST, так же как и новое имя в recycle bin, которое аналогично имени, созданному нами ранее после удаления. (Замечание: точное имя [в столбце RECYCLEBIN_NAME] может различаться в зависимости от платформы.) Все, что от вас требуется для восстановления таблицы, это использовать команду Flashback Table:

SQL> FLASHBACK TABLE RECYCLETEST TO BEFORE DROP;

FLASHBACK COMPLETE.

SQL> SELECT * FROM TAB;

TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
RECYCLETEST                    TABLE

Voila! Таблица восстановлена без каких-либо усилий. Теперь, если вы поверить recycle bin, он окажется пустым.

Напомним: размещение таблиц в recycle bin не освобождает место в исходном табличном пространстве. Чтобы освободить пространство, вы должны очистить recycle bin, используя:

PURGE RECYCLEBIN;

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

DROP TABLE RECYCLETEST PURGE;

Эта команда не будет переименовывать таблицу в имя recycle bin, она будут окончательно удалена, как было в версиях Oracle до 10g.

Управление Recycle Bin

Если таблицы не были полностью утеряны, если даже не было освобождено табличное пространство, то что произойдет, когда удаленные объекты займут все пространство?

Ответ прост – такая ситуация никогда не произойдет. Когда все табличное пространство заполнено данными из recycle bin так, что файлам данных приходится расширять свои объемы, чтобы вместить еще больше данных, табличное пространство сообщает, что находится в состоянии "space pressure" (“пространственное давление”). При таком развитии событий объекты будут автоматически удаляться по принципу first-in-first-out (“первым пришел, первым уйдет”). Зависимые объекты (например, индексы) удаляются до того, как будет удалена таблица.

Точно так же ситуация space pressure (пространственное давление) может возникнуть, когда превышаются квоты пользователей, определеные для конкретных табличных пространств. Табличное пространство может иметь достаточно свободного объема, но пользователь может исчерпывать отведенную ему часть. В таком случае Oracle автоматически зачищает объекты, принадлежащие этому пользователю в этом табличном пространстве.

Кроме того, есть несколько способов для “ручного” контроля recycle bin. Чтобы выкинуть из “корзины” (recycle bin) некую таблицу с именем TEST до ее удаления, то можете воспользоваться командой:

PURGE TABLE TEST;

или воспользуйтесь ее именем в “корзине”:

PURGE TABLE "BIN$04LhcpndanfgMAAAAAANPw==$0";

Эта команда удалит таблицу TEST и все зависимые от нее объекты, такие как индексы, ограничения и так далее, из recycle bin, освобождая некоторое пространство. Если вы хотите полностью удалить из recycle bin индекс, это можно сделать, используя:

purge index in_test1_01;

что удалит только индекс, оставив в recycle bin копию таблицы.

Иногда полезно осуществить очистку на верхнем уровне. Например, вы хотите вычистить все объекты в recycle bin, относящиеся к табличному пространству USERS. Это делается так:

PURGE TABLESPACE USERS;

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

PURGE TABLESPACE USERS USER SCOTT;

Пользователь же SCOTT будет вычищать свой recycle bin с помощью

PURGE RECYCLEBIN;

Вы, как АБД, можете вычистить все объекты в любом табличном пространстве, используя

PURGE DBA_RECYCLEBIN;

Как вы уже заметили, управлять “корзиной” можно по-разному в зависимости от ваших потребностей.

Версии таблиц и Flashback

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

CREATE TABLE TEST (COL1 NUMBER);
INSERT INTO TEST VALUES (1);
COMMIT;
DROP TABLE TEST;
CREATE TABLE TEST (COL1 NUMBER);
INSERT INTO TEST VALUES (2);
COMMIT;
DROP TABLE TEST;
CREATE TABLE TEST (COL1 NUMBER);
INSERT INTO TEST VALUES (3);
COMMIT;
DROP TABLE TEST;

В таком случае, если вы хотите применить откат к таблице TEST, какое значение будет у столбца COL1? На первый взгляд может показаться, что первая версия таблицы будет восстановлена из recycle bin, где значение столбца COL1 было 1. На самом же деле восстанавливается третья версия таблицы, а не первая. Таким образом, столбец COL1 будет иметь значение 3, а не 1.

В то же время вам надо восстановить другие версии удаленной таблицы. Однако, наличие таблицы TEST не позволит этому произойти. У вас есть два варианта:

• Использовать опцию переименования:
  • FLASHBACK TABLE TEST TO BEFORE DROP RENAME TO TEST2;
  • FLASHBACK TABLE TEST TO BEFORE DROP RENAME TO TEST1;

которая восстановит первую версию таблицы до TEST1 а вторую версию до TEST2. Значения столбца COL1 в TEST1 и TEST2 будет 1 и 2 соответственно. Или:

• Использовать для восстановления специальные имена таблиц в “корзине”. Чтобы это сделать сначала идентифицируйте табличные имена в recycle bin, а затем примените:
  • FLASHBACK TABLE "BIN$04LhcpnoanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST2;
  • FLASHBACK TABLE "BIN$04LhcpnqanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST1;

Это восстановит две версии удаленной таблицы.

Будь предупрежден…

Функция un-drop возвращает таблице ее оригинальное имя, но не ассоциированным объектам - индексам и триггерам, которые остаются под своими “корзинными” именами. Такие объекты, как представления и процедуры, определяемые на таблице, не перекомпилируютя и остаются в инвалидном статусе. Нужно вручную отыскать их старые имена должны быть переделаны и затем применить к восстановленной (flashed-back) таблице.

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

SELECT OBJECT_NAME, ORIGINAL_NAME, TYPE
FROM USER_RECYCLEBIN
WHERE BASE_OBJECT = (SELECT BASE_OBJECT FROM USER_RECYCLEBIN
WHERE ORIGINAL_NAME = 'RECYCLETEST')
AND ORIGINAL_NAME != 'RECYCLETEST';

OBJECT_NAME                    ORIGINAL_N TYPE
------------------------------ ---------- --------
BIN$04LhcpnianfgMAAAAAANPw==$0 IN_RT_01   INDEX
BIN$04LhcpnganfgMAAAAAANPw==$0 TR_RT      TRIGGER

После применения отката к таблице индексы и триггеры в таблице RECYCLETEST будут названы как показано в столбце OBJECT_NAME. Из предыдущего запроса вы можете использовать оригинальные имена для переименования объектов, как показано далее

ALTER INDEX "BIN$04LhcpnianfgMAAAAAANPw==$0" RENAME TO IN_RT_01;
ALTER TRIGGER "BIN$04LhcpnganfgMAAAAAANPw==$0" RENAME TO TR_RT;

Одно исключение - это двоичные (bitmap) индексы. При удалении (drop) они не помешаются в recycle bin и, следовательно, не восстанавливаются. Имена ограничений целостности (constraint – констрейнт) так же не определяемы из этого представления. Они должны быть переименованы из других ресурсов.

Другое применение Flashback-таблиц

Механизм Flashback Drop Table не ограничивается только восстановлением удаленных таблиц. Подобно flashback-запросам, вы можете использовать его для просмотра таблицы в различные моменты времени [в прошлом], переставляя текущую таблицу с ее предыдущими версиями. Например, следующая запись восстанавливает таблицу к SCN 2202666520 (System Change Number - Системный Номер Изменения).

FLASHBACK TABLE RECYCLETEST TO SCN 2202666520;

Опция использует технологию Oracle Data Pump для создания различных таблиц, использует откат для заполнения таблицы версиями данных, соответствующих выбранному SCN, а затем меняет местами оригинальную таблицу с новой. Для того, чтобы узнать, на сколько можно откатить таблицу, следут использовать опцию верификации [Flashback Versions Query] Oracle Database 10g. (См. “Неделя 1” этой серии статей.) Конечно же, возможно специфицировать временную метку отдельно от SCN в операторе отката.

Об опции Flashback Table feature подробнее и больше можно прочитать в Oracle Database Administrator's Guide 10g Release 1 (10.1).