Пятнадцать вещей об Oracle, от которых должны отучиться АБД

Администраторы базы данных, как и большинство профессионалов, имеют тенденцию продолжать делать те вещи, которые хорошо работали в прошлом. В течение долгого времени эти действия жили собственной жизнью, передаваясь от АБД к АБД, как фольклор. Но программные продукты не стоят на месте, к ним добавляются новые особенности, и база данных Oracle также не является исключением из этого правила. В версиях 8i, 9i и 10g были введены крупные новые возможности, которые требуют пересмотра всего того, что “каждый знает” о Oracle. Давайте взглянем на 15 заветных убеждений, которых придерживаются АБД Oracle, и выясним, почему эти убеждения, возможно, перестали быть справедливыми.

Убеждение №1: размер блока зафиксирован

Фундаментальной единицей хранения в Oracle является блок – наименьшее количество данных, которое Oracle может прочитать или записать за один раз. Размер блока – 2, 4, 8, 16 или 32 Кбайт – выбирается при первоначальном создании базы данных и используется как для физического дискового пространства, так и для буферов в оперативной памяти. Большинство АБД полагает, что после того, как размер блока был выбран, он не может быть изменен без перезагрузки базы данных, и что это применимо ко всем табличным пространствам в базе данных. Так вот, начиная с Oracle 9i, ни одно из этих убеждений не является истинным.

Каждое табличное пространство может теперь использовать различные размеры блока. Это можно сделать, например, таким образом:

CREATE TABLESPACE book_data
BLOCKSIZE 8K
DATAFILE '/u3/oradata/prod/bookdata01.dbf' SIZE 100M;

Вы можете проверить, какие размеры блока используются в настоящее время, используя новый столбец BLOCK_SIZE в представлениях V$DATAFILE и DBA_TABLESPACES.

Если Вы используете размер блока, отличный от значения по умолчанию размера блока для базы данных, Вы должны установить для него кэш памяти, использующий файл параметров инициализации. Определены шесть новых параметров. db_cache_size заменяет db_block_buffers, чтобы указать размер буферного кэша для блоков, размер которых устанавливается по умолчанию. db_2k_cache_size указывает размер буферного кэша для блоков по 2 Кбайт, если такие блоки нестандартны для базы данных. Также имеются версии на 4 Кбайт, 8 Кбайт, 16 Кбайт и на 32 Кбайт. В отличие от их предшественника – параметра db_block_buffers – все эти параметры измеряются в байтах, а не количеством выделяемых буферов.

Убеждение №2: таблицы с одним экстентом быстрее

Фольклор АБД Oracle гласит, что лучшая производительность ввода/вывода (I/O) достигается, когда все блоки таблицы находятся в единственном смежном экстенте. Это правда – иногда. Но не по той причине, которой Вы могли бы ожидать.

В официальном документе, который называется "Как прекратить заниматься дефрагментацией и начать жить” (для знакомства с ним достаточно бесплатной регистрации), Бхаскар Химатсингка (Bhaskar Himatsingka) и Хуан Лоайза (Juan Loaiza ) из корпорации Oracle утверждают, что состоящие из нескольких экстентов таблицы вовсе не обязательно работают хуже, чем таблицы с единственным экстентом. Что важно на самом деле, утверждают они, так это размер экстентов. При достаточно большом размере экстента механизм Oracle может организовать эффективное предварительное считывание даже из множества экстентов.

Для лучшего использования этого понимания авторы рекомендуют, чтобы АБД сделал стандартными для себя три размера экстентов и использовал во всех таблицах только их: 128 Кбайт для маленьких таблиц, 4 Мбайт для средних таблиц и 128 Мбайт только для самых больших таблиц. Использование экстента размером 128 Кбайт может показаться напрасной тратой пространства, но стоимость этого потраченного впустую пространства тривиальна по сравнению со стоимостью времени, которое теряет АБД, трясущийся над каждым индивидуальным распределением памяти. Эти принципы были встроены в новую возможность Oracle 8i, так называемые локально управляемые табличные пространства (Locally Managed Tablespaces).

Убеждение №3: экспорт и импорт – единственные способы реорганизации таблиц

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

Использование в команде ALTER TABLE новой фразы MOVE позволяет Вам изменить параметры табличного пространства и/или хранения таблицы Oracle, не используя EXPORT и IMPORT. Выглядит это следующим образом:

ALTER TABLE author MOVE
TABLESPACE book_data
STORAGE (INITIAL 128K NEXT 128K PCTINCREASE 0);

В этом случае, фраза TABLESPACE говорит Oracle о том, что необходимо переместить таблицу AUTHOR из ее текущего табличного пространства в табличное пространство book_data. Фраза STORAGE работает точно так же для команды CREATE TABLE, указывая, насколько большой экстент необходимо выделить, и свойства его (экстента) роста. Любая из опций TABLESPACE или STORAGE является необязательной, что дает Вам возможность переместить таблицу, не реорганизуя ее, и наоборот. Предостережение: в версии 8i таблица будет блокирована на все время выполнения команды ALTER TABLE, таким образом, лучше всего делать такую работу в период невысокой нагрузки. В версии 9i это ограничение снято. Когда Вы добавляете к синтаксису ключевое слово ONLINE, таблица может быть перемещена, даже в то время как пользователи обновляют ее.

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

Убеждение №4: столбцы не могут быть удалены

АБД Oracle привыкли к факту, что после того как для таблицы был определен столбец, он не может быть переименован или удален. Чтобы избавиться от него, Вы должны были создать новую таблицу без этого столбца, и затем загрузить эту таблицу данными из первоначальной таблицы. И, наконец, Вы должны были восстановить для новой таблицы все разрешения, индексы, триггеры, и т.д., которые имелись для первоначальной таблицы. Не больше, и не меньше. Начиная с Oracle 9i R1, Вы можете удалить столбец и добавить вместо него правильный. Для этого используются фразы SET UNUSED и DROP команды ALTER TABLE. Ниже приводится пример:

ALTER TABLE author
DROP (birthplace, birthyear);
ALTER TABLE author
SET UNUSED (birthhospital);

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

Предостережение: Если столбец отмечен как неиспользуемый или удаленный, все данные, содержавшиеся в столбце, оказываются безвозвратно потерянными. Эти команды являются командами языка определения данных (DDL), так что для них нет никакого оператора ROLLBACK. Будьте внимательны и имейте хорошие резервные копии!

Убеждение № 5: хранимые процедуры всегда выполняются с правами владельца

Когда пользователю Oracle дают разрешение выполнить хранимую процедуру, ему (или ей) неявно дают разрешение сделать нечто, что делает эта хранимая процедура. Независимо от того, сколько таблиц обновляет процедура, или как она обновляет их (даже удаляя строки), пользователи могут сделать все это. Другими словами, выполняя процедуру, пользователь получает все права владельца. Однако, начиная с Oracle 8i, хранимая процедура может быть создана или с правами владельца или с правами выполняющего ее человека. Для этого можно использовать фразу AUTHID команды CREATE PROCEDURE. Например:

CREATE PROCEDURE count_authors
(num_books OUT NUMBER)
AUTHID CURRENT_USER
IS
SELECT COUNT(*) INTO num_books
FROM author;
END;

Хранимая процедура, определенная как AUTHID CURRENT_USER разрешит доступ к таблице, только в том случае, если пользователь владеет таблицей или получил разрешение использовать ее. Кроме того, ссылки на неквалифицированные имена таблиц, например, на таблицу author в приведенном выше примере, будут относиться к пользовательской копии author, а не к таблице первоначального владельца. Для разрешения ссылок используется схема или список объектов зарегистрированного в настоящее время пользователя.

Убеждение № 6: только АБД может восстановить данные

Люди, которые непосредственно работают на языке SQL – АБД и консультанты IT – могут разрушить или потерять данные из-за одной набранной с ошибкой команды. Фактически, по данным Oracle, именно ошибка пользователя является самой часто встречающейся причиной простоев баз данных. Таблица, удаленная из промышленной базы данных вместо базы данных разработки, может принести к внезапному останову приложения и всех его пользователей. Даже ненадлежащее обновление может привести к искажению результатов отчетов по базе данных. Восстановление после таких ошибок обычно была отнимающей много времени работой, которую мог выполнить только АБД. Но, начиная с Oracle 9i, пользователи могут исправить много таких ошибок непосредственно через команды SQL. Механизмом для этого стала новая возможность 9i, получившая название Flashback Query.

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

DELETE FROM emp WHERE empno = 7934;
COMMIT;

Строка полностью пропала для дальнейших операторов SELECT, и даже команда ROLLBACK не может вернуть ее. Тем не менее, Flashback Query может отобразить содержимое (контент) таблицы, каким оно было 10 минут назад, когда удаленная строка все еще существовала:
SELECT * FROM emp
AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '10' MINUTE)
WHERE empno = 7934;

Этот оператор SELECT может быть использован как подзапрос в операторе INSERT, чтобы перезагрузить удаленные данные. Знайте, однако, что оператор INSERT будет подчинен всем ограничениям, наложенным на таблицу, и что любые триггеры INSERT для таблицы будут выполняться. Чтобы заставить весь сеанс возвратиться в прошлое к конкретному моменту времени, используйте пакет DBMS_FLASHBACK:

EXEC DBMS_FLASHBACK.ENABLE_AT_TIME(TIMESTAMP ‘yyyy-mm-ddhh:mi:ss’);

Данные, к которым обращаются в течение сеанса ретроспекции, не могут быть изменены, они доступны только для чтения. Это похоже на научно-фантастические рассказы, рассказывающие о путешествиях во времени: Вы можете посетить прошлое, но Вы не можете изменить его! Чтобы возвратить сеанс в настоящее время, наберите:

EXEC DBMS_FLASHBACK.DISABLE;

Для того чтобы опция Flashback Query могла работать, база данных должна использовать опцию автоматического управления пространством отката (Automatic Undo Management – AUM) и должно быть создано табличное пространство отмены. Время, на которое пользователь может возвратиться в прошлое, ограничено значением параметра инициализации undo_retention и размером табличного пространства отката. Хотя эту опцию можно назвать подарком небес для консультантов IT, намерение Oracle заключались в том, чтобы любой пользователь, который непосредственно набирает операторы SQL, был в состоянии восстановиться после своих собственных ошибок. Ретроспекция представляет собой объектную привилегию, так что ее можно предоставлять для индивидуальных таблиц или для всех таблиц, используя системную привилегию

FLASHBACK ANY TABLE

Но подождите: все становится лучше! В версии 9i, возможности Flashback ограничены командами языка манипулирования данными (DML), типа SELECT, INSERT, UPDATE и DELETE. Но в Oracle 10g, посредством Flashback может быть восстановлена даже удаленная таблица.

Убеждение № 7: Oracle не может хранить доли секунд

В типе данных DATE Oracle всегда хранил время с округлением до полных секунд. Разработчики, нуждающиеся в более точных измерениях времени, могли вместо DATE использовать тип данных NUMBER. Подобная практика приводит к тому, что вычисление интервалов времени становится трудным делом.

Начиная с версии 9i, в Oracle включен усовершенствованный тип данных даты/времени, совместимый со стандартом SQL 1999 года. Чтобы объявить такой столбец, используйте тип данных TIMESTAMP и укажите желательное количество цифр дробной части (значение количества цифр по умолчанию – 6):

CREATE TABLE event_ts (
event_id NUMBER(6)
,event_name VARCHAR2(40)
,start_time TIMESTAMP(2)
,elapsed_time TIMESTAMP(2)
);

Литерал TIMESTAMP, как и литерал DATE, должен быть заключен в одиночные кавычки. Однако, в отличие от дат, требуется также и слово TIMESTAMP. Следующий литерал представляет 23 марта 2004, спустя полсекунды после полночи:

TIMESTAMP ‘2004-03-23 00:00:00.50’

Хотя в стандартный литерал типа DATE время не включается, в стандартном формате для литерала TIMESTAMP наличие времени является обязательным. Параметр сеанса NLS_TIMESTAMP_FORMAT управляет форматом таким же образом, как NLS_DATE_FORMAT устанавливает стандартный формат для DATE. Новая функция конвертирования, TO_TIMESTAMP, создает TIMESTAMP из других входных форматов, а функция TO_CHAR была расширена, чтобы можно было отображать компоненты TIMESTAMP в любом порядке.

Чтобы получить текущую дату и время в формате TIMESTAMP, используйте вместо SYSDATE функцию SYSTIMESTAMP. Например:

SELECT SYSTIMESTAMP FROM DUAL;

Убеждение № 8: разрушенный блок требует удаления объекта

Консультанты IT боятся сообщения об ошибке Oracle ORA-1578: "Oracle data block corrupted" (Блок данных Oracle разрушен). Внутренняя структура одного из блоков базы данных перестала быть правильной. Сообщение идентифицирует ошибочный блок по номеру файла и номеру блока. Для “лечения” проблемы нужно выполнить запрос типа:

SELECT owner, segment_name, segment_type
FROM dba_extents
WHERE file_id =
AND BETWEEN block_id AND block_id + blocks - 1;

где < номер_файла> и < номер_блока> являются числами из сообщения об ошибке. Этот запрос укажет, какой объект содержит разрушенный блок. После этого, в зависимости от типа объекта, восстановление является либо прямым (для индексов и временных сегментов), либо трудным (для таблиц), либо очень трудным (для активных сегментов отката и частей словаря данных).
Однако, в Oracle 9i Enterprise Edition новая команда диспетчера восстановления (RMAN) – BLOCKRECOVER – может восстановить блок на месте, не удаляя, а затем повторно создавая вовлеченный объект. После регистрации в RMAN и соединения с целевой базой данных наберите:
BLOCKRECOVER DATAFILE BLOCK ;

При выполнении резервного копирования в RMAN обновляется новое представление, V$DATABASE_BLOCK_CORRUPTION, и блок должен быть внесен в список, как испорченный, для последующего выполнения BLOCKRECOVER. Чтобы восстановить все блоки, которые были отмечены как испорченные, может быть использована следующая последовательность RMAN:

BACKUP VALIDATE DATABASE;
BLOCKRECOVER CORRUPTION LIST;

Этот подход эффективен, если в восстановлении нуждаются только несколько блоков. При крупномасштабном разрушении (повреждении) более эффективно восстановить (restore) предшествующее “изображение” файла данных, и затем восстановить (recover) весь файл данных в его первоначальном (перед разрушением) состоянии. Как и для любой новой возможности, тщательно проверьте ее перед использованием для промышленной базы данных.

Убеждение № 9: столбцы не могут быть переименованы или реорганизованы

Переименование столбца таблицы или изменение его типа данных обычно означало создание новой таблицы и копирование в нее старых данных. Столбцы вообще не могли быть переименованы, а типы данных могли быть изменены, только если в них не имелось никаких данных (содержались только значения NULL).

В Oracle 9i появилась не одна, а целых две возможности для преодоления этих ограничений. Команда ALTER TABLE может теперь непосредственно переименовывать столбцы:

ALTER TABLE books RENAME COLUMN tiitle TO title;

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

Поставляемый пакет PL/SQL по имени DBMS_REDEFINITION позволяет АБД изменить структуру столбца таблицы, причем во время этого изменения таблица остается в оперативном состоянии и является доступной для пользователей. Это довольно сложная процедура, но, в общем, выполняются следующие шаги:

1. Используйте DBMS_REDEFINITION.CAN_REDEF_TABLE, чтобы проверить, что таблица может быть квалифицирована для онлайнового переопределения, и специфицировать, будет ли переопределение вестись по первичному ключу (рекомендуется) или по идентификаторам строк (ROWID).
2. Создайте в той же самой схеме пустую таблицу, но с желательным форматом. Опустите столбцы, которые Вы хотите удалить; включите новые столбцы, которые Вы хотели бы создать.
3. Используйте DBMS_REDEFINITION.START_REDEF_TABLE, чтобы начать процесс переопределения. Параметры для этой процедуры указывают старую таблицу, новую таблицу и то, как отобразить существующие столбцы на столбцы новой таблицы.
4. Создайте все (заблокированные) ограничения, триггеры, индексы и предоставления, желательные для новой таблицы.
5. Используйте DBMS_REDEFINITION.FINISH_REDEF_TABLE, чтобы закончить процесс. Первоначальная таблица блокируется на довольно короткий промежуток времени, независимо от ее размера – на то время, пока производится замена определений между этими двумя таблицами.
6. Удалите временную таблицу, используемую в переопределении; так она более не нужна.

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

Убеждение № 10: только владелец таблицы может предоставить разрешение на ее использование

Когда я объяснял организацию безопасности Oracle в предыдущих версиях, клиенты не могли поверить, что АБД не мог предоставить разрешение на таблицу, если владелец таблицы сначала не предоставит его АБД. Тем не менее, исторически это действительно имело место. Ограничение было частью дизайна Oracle, но это делало администрирование трудным. В Oracle 9i новая системная привилегия изменяет такое положение вещей.

Теперь роль АБД имеет системную привилегию по имени GRANT ANY OBJECT PRIVILEGE. В прошлом оператор типа

GRANT SELECT ON scott.emp TO giselle;

завершился бы неудачей, если SCOTT не предоставил сначала АБД привилегию SELECT WITH GRANT OPTION на его таблицы. Теперь, тот же самый оператор будет работать. Эта привилегия может также использоваться ведущими разработчиками, чтобы предоставить разрешение на объекты схемы, не имея необходимости регистрироваться, как владелец этой схемы.

Убеждение № 11: единственными подстановочными знаками в SQL являются % и _

Делая запросы на соответствие шаблону с оператором LIKE, как АБД, так и разработчики учились мириться с наличием в их распоряжении всего двух групповых символов: процента (%), который соответствует чему угодно, и символу подчеркивания (_), который соответствует одному любому символу. Для обеспечения более сложного соответствия им приходилось писать на PL/SQL.

Начиная с Oracle 10g, подобное дополнительное кодирование перестало быть необходимым. Полный набор синтаксиса регулярных выражений, типа того, что используется в UNIX для создания сценариев, теперь доступен непосредственно в SQL. Oracle поддерживает полный набор расширенных регулярных выражений (Extended Regular Expressions – ERE) стандарта POSIX. Перечень этих выражений можно найти в Приложении C к документу Oracle 10g SQL Reference.

Оператор REGEXP_LIKE заменяет LIKE, и регулярное выражение должно быть заключено в круглые скобки и в одиночные кавычки. Например, следующая фраза WHERE ищет A1, A2, или A3, встречающиеся только в начале номера детали:

WHERE REGEXP_LIKE (partno, ‘^A[123]’)

Обратите внимание, что в конце регулярного выражения не требуется групповой символ *. В отличие от групповых символов, используемых с оператором LIKE, регулярные выражения предполагают частичное соответствие, если Вы не установите в принудительном порядке полного соответствия. Таким образом, вышеупомянутому выражению будет соответствовать “A1” и “A3”, но также и “A234”. Чтобы вызвать точное соответствие, используйте знак $, чтобы указать конец строки:

WHERE REGEXP_LIKE (partno, ‘^A[123]$’)

Функции REGEXP_INSTR, REGEXP_SUBSTR и REGEXP_REPLACE расширяют функции INSTR, SUBSTR и REPLACE, чтобы использовать регулярные выражения в параметре соответствия. И снова, описание этого можно найти в документе Oracle 10g SQL Reference.

Убеждение № 12: вы должны перестроить таблицу, чтобы сбросить ее маркер максимального заполнения

Конечные пользователи часто задаются вопросом, почему поиск в таблице с небольшим количеством строк может отнять довольно много времени. АБД знает, что, если в таблице когда-то было большое количество строк, поиск может замедлиться, потому что Oracle должен просмотреть каждый блок, в котором когда-либо содержались данные – вплоть до маркера максимального заполнения таблицы (High Water Mark – HWM). Кроме того, они могут также полагать, что единственный способ сбросить значение HWM состоит в том, чтобы повторно создать таблицу, либо посредством экспорта/удаления/импорта, либо с помощью команды ALTER TABLE MOVE.

В 10g это больше не является необходимым. Новая опция, названная Online Segment Shrink (оперативное сжатие сегмента), может возвратить свободное пространство в таблице, а также скорректировать вниз HWM. Синтаксис опции:

ALTER TABLE имя_таблицы SHRINK SPACE [COMPACT] [CASCADE];

Задание этой команды без опций приводит к дефрагментации таблицы и уплотнению ее строк. Затем HWM корректируется к новой высокой позиции и освобождает высвободившееся пространство.

Опция COMPACT проводит дефрагментацию, но не корректирует HWM, и не освобождает высвободившееся пространство. Опция CASCADE сжимает не только названную таблицу, но и любые зависимые объекты, например, индексы.

А теперь то, о чем обычно говорится “мелким шрифтом”. Табличное пространство, в котором хранится таблица, должно быть установлено для автоматического управления пространством в сегментах (Automatic Segment Space Management), а для самой таблицы должно быть активировано перемещение строк. Поскольку перемещенные строки будут иметь новый ROWID, Вы должны отключить любые триггеры, которые срабатывают на основании ROWID, или они будут выполнены повторно. Имеются также и другие ограничения: проконсультируйтесь в документации.

Убеждение № 13: неполные восстановления требуют восстановления старых файлов данных

АБД Oracle знают, что Oracle полностью восстанавливает себя (recovers) после отказа экземпляра при последующем запуске, а от физических отказов, типа отказов носителя, с помощью команды RECOVER в RMAN или в SQL*Plus. Однако, они полагают, что когда происходит логическое повреждение, то единственным способом помочь может быть восстановление файлов базы данных с резервных копий, снятых до того, как произошла проблема, и “накат вперед” (roll forward) к требующемуся времени через журналы.

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

Опция Flashback, введенная в Oracle 9i, была поразительно расширена в 10g путем введения опции FLASHBACK DATABASE (доступной и как команда в RMAN, и как оператор в SQL*Plus). При надлежащей настройке Вы можете теперь восстановить базу данных, прокручивая ее назад от ее текущего состояния, вместо того, чтобы прокручивать ее вперед от старой копии-отображения. Это может быть намного быстрее, поскольку работа ведется с существующими файлами данных. Не требуется восстановления никаких старых версий.

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

1. Отведите для области группового восстановления (flash recovery area) на диске достаточно большой экстент, чтобы хранить в нем журналы Flashback и другие резервные копии RMAN, типа управляющих файлов. Задайте параметры DB _RECOVERY_FILE_DEST и DB_RECOVERY_FILE_SIZE, чтобы указать экземпляру, где ее можно найти.
2. . Установите параметр DB_FLASHBACK_RETENTION_TARGET равным максимальному числу минут, на которое Вы хотели бы быть в состоянии возвратиться в прошлое.
3. Активируйте опцию Flashback, когда база данных будет в режиме монтирования (MOUNT), используя команду ALTER DATABASE FLASHBACK ON. После этого переведите (ALTER) базу данных в режим OPEN. База данных начнет автоматически копировать измененные блоки на регулярной основе в область ретроспективного восстановления. Думайте об этом, как о непрерывном инкрементальном резервировании на уровне блоков.

Если Вы должны возвратить базу данных к более раннему времени:

1. Переведите экземпляр в режим MOUNT
2. Соединитесь с экземпляром в RMAN и используйте команду FLASHBACK DATABASE. Эта команда определяет местонахождение самых свежих изображений блока, предшествующих запрашиваемому Вами времени ретроспекции, и восстанавливает их. После этого она использует журнальные файлы, чтобы выполнить накат вперед к точному времени ретроспекции. Поскольку блоки копируются достаточно часто, потребуется выполнить намного меньше работы, чтобы сделать этот блок актуальным. Плюс к этому, удается избежать потерь времени на восстановление файлов данных.

Эта методика подходит не для каждого экземпляра, но, как и с любым страховым полисом, Вы регулярно выплачиваете небольшие суммы, чтобы избежать намного больших выплат в случае, если проблема все-таки произойдет. Для получения дополнительной информации обратитесь к документу Oracle Database Backup and Recovery Advanced User’s Guide, Глава 9 (“Flashback Technology: Recovering from Logical Corruptions”).

Убеждение № 14: табличные пространства могут транспортироваться только на ту же самую платформу

Опция переносимого табличного пространства, введенная в Oracle 8i, позволяет непосредственно копировать файлы данных из одного экземпляра в другой. Поскольку различные операционные системы используют для хранения данных различный порядок байтов (“endianness”), многие АБД полагают, что Вы не можете транспортировать табличные пространства в экземпляр с другим размером блока или на другую аппаратную платформу.

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

Для этого используется команда RMAN CONVERT. Например:

CONVERT TABLESPACE example TO PLATFORM ‘HP-UX (64-bit)’;

Представление V$TRANSPORTABLE_PLATFORMS содержит информацию, о том, какие платформы являются совместимыми, а для каких требуется использовать команду CONVERT.

В главе 8 (“Управление табличными пространствами”) документа Database Administrator’s Guide можно найти дополнительные детали относительно транспортировки табличных пространств.

Убеждение № 15: роли CONNECT, RESOURCE и DBA – это удобный способ создания пользователей

Многие АБД все еще используют роли CONNECT, RESOURCE и DBA для создания новых учетных записей пользователей, как в автоматизированных сценариях, так и при работе вручную, просто по привычке. Иногда вещи, от которых мы должны отвыкнуть – это такие простые и удобные вещи, как старая трикотажная рубашка или пара старых, давно износившихся ботинок. Эти доставшиеся нам в наследство роли были введены еще в Oracle 7 – да-да, уже три основные версии назад – как мост между простой моделью защиты Oracle 6 и более детальной, которую мы получили с тех пор. Но это – все, что у них есть: временное удобство.

Принцип наименьшего количества привилегий в компьютерной безопасности утверждает, что пользователи должны иметь только минимальные привилегии, необходимые для выполнения поручаемых им заданий. Роль CONNECT, например, включает системные разрешения, типа CREATE TABLE и CREATE SEQUENCE, вещи, в которых вряд ли будет нуждаться большинство конечных пользователей. Роль RESOURCE содержит мощную привилегию UNLIMITED TABLESPACE, которая отменяет систему квот табличного пространства.

Более эффективно было бы проанализировать требования различных ролей заданий и в соответствии с этими требованиями создать заказные роли. Предоставьте этим ролям необходимые системные и объектные привилегии, а затем предоставьте роли пользователям. Предоставьте пользователям квоты для табличных пространств только в тех случаях, если они будут создавать в этих табличных пространствах объекты. (Хотя квоты должны быть установлены непосредственно для пользователей, а не для ролей, Вы можете упростить процесс в Enterprise Manager путем использования команды "Create like", чтобы клонировать существующую учетную запись пользователя.)

Практические результаты

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