Какой бы длинной ни стала строка, пока она не удалена, ее ROWID останется неизменным!

--таблица CHAINED_ROWS к этому моменту уже существует, собираем статистику

SQL> analyze table test1 LIST CHAINED ROWS INTO CHAINED_ROWS;

Table analyzed.

--сколько же строк не помещаются теперь в один блок? В данном случае вследствие миграции.

SQL> select count(*) from chained_rows

2 where table_name = 'TEST1';

COUNT(*)

----------

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

SQL> CREATE TABLE test1_hist

2 AS SELECT * FROM test1

3 WHERE ROWID IN

4 (SELECT HEAD_ROWID

5 FROM CHAINED_ROWS

6 WHERE TABLE_NAME = 'TEST1');

Table created.

--далее удалим эти строки из тестовой таблицы

SQL> DELETE FROM test1

2 WHERE ROWID IN

3 (SELECT HEAD_ROWID

4 FROM CHAINED_ROWS

5 WHERE TABLE_NAME = 'TEST1')

6 /

6361 rows deleted.

--и вставим их обратно из временной таблицы, ROWID строк изменится.

SQL> insert into test1 select * from test1_hist;

6361 rows created.

SQL> commit;

Commit complete.

SQL> drop table test1_hist;

Table dropped.

--очистим статистические данные о тестовой таблице в chained_rows:

SQL> delete from chained_rows where table_name = 'TEST1';

6361 rows deleted.

--снова соберем статистику

SQL> analyze table test1 list chained rows into chained_rows;

Table analyzed.

SQL> select count(*) from chained_rows where table_name = 'TEST1';

COUNT(*)

----------

--больше нет ни одной сцепленной либо мигрировавшей строки!

--число экстентов после такой операции не должно уменьшиться

SQL> column segment_name format a24

SQL>

SQL> select segment_name, blocks, bytes, extents

2 from dba_segments

3 where segment_name ='TEST1';

SEGMENT_NAME BLOCKS BYTES EXTENTS

------------------------ ---------- ---------- ----------

TEST1 110 901120 22

--а вот и «пропавшие» блоки

SQL> SELECT SUBSTR(ROWID, 10, 6) insert_test1, count(*) from test1

2 group by ROLLUP(SUBSTR(ROWID, 10, 6))

3 /

INSERT COUNT(*)

------ ----------

AAAAA+ 82

AAAAA/ 82

AAAAA0 82

AAAAA1 82

AAAAA3 82

AAAAA4 82

AAAAA5 82

AAAAA6 82

AAAAA7 82

…

AAAABo 74

AAAABx 82

AAAABz 119

92 rows selected.

Фрагментация внутри ТП

Большие объекты БД могут состоять из большого количества экстентов, расположение которых внутри ТП может быть далеко не последовательным. Чаще всего такое случается со временем, когда из ТП удалялись объекты и суммарное свободное место в ТП складывается из свободных фрагментов, разбросанных по всему ТП. Например, в ТП есть 100 свободных фрагментов по 1Мб, но вставить экстент размером в 2Мб не получится, ибо в таком случае необходимо иметь непрерывный участок размером в 2Мб, которого нет. Хотя свободного места – 100Мб. Тогда говорят о логической фрагментации на уровне ТП.

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

- Используйте локально управляемые табличные пространства.

- Используйте автоматическое управление распределением пространства в ТП.

- Используйте унифицированный размер экстента в ТП.

- Старайтесь использовать параметры хранения уровня ТП для всех объектов, хранящихся в нем.

- Размещайте объекты одного размерного порядка в соответствующих ТП. Например, в БД существуют небольшие таблицы (до 10Мб), средние (10-500 Мб) и большие (500Мб и выше). Будет логичным создать для каждого из этих типов таблиц 3 табличных пространства, с унифицированным размером экстента, например, в 64-128Кб, 1-5Мб, 20-100Мб для каждого из типов таблиц. Эти значения примерны.

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

- Храните таблицы и индексы в различных ТП.

- Для объектов с числом экстентов больше 1024 проводите реорганизацию.

- Используйте секционирование для больших объектов.

- Не используйте опцию COMPRESS=Y в утилите exp.

О тех самых сырых устройствах

«Сырые» устройства (raw devices) представляют собой неформатированную, не содержащую файловой системы область на диске, в которой может храниться один файл. Отсутствие файловой системы позволяет избежать дополнительной буферизации при обращении к устройству, что может ускорить операции чтения/записи в этом устройстве.

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

В СУБД Oracle 10g обращение к файлам данных, расположенным на «сырых» устройствах, не отличается от обращения к файлам на файловых системах, т.е. прозрачно. Обращении к этим устройствам осуществляется в последовательном режиме, поэтому больше всего их использование подходит для активных жураналов повтора.

В Linux сырые устройства создаются следующим образом:

- создаются разделы необходимого размера с помощью fdisk, тип файловой системы – 0 (empty).

- С помощью команды raw происходит связывание и монтирование устройства в выбранную точку монтирования. Обычно это /dev/raw/raw1, raw2 … и т.д. Пакет orarun создает 255 подобных точек монтирования с именами /dev/raw/raw1...raw255. При монтировании устройству выдаются major и minor идентификаторы. Для автоматического подключения «сырых» устройств при старте ОС Linux необходимо прописать в файле /etc/raw эти идентификаторы.

Далее сервер Oracle может создавать файлы БД, обращаясь непосредственно к смонтированному устройству.

При принятии решения об использовании «сырых» устройств в системе, необходимо четко продумать изменения в стратегии резервного копирования и восстановления. Осуществление холодной коппии с «сырого» устройство должно проводиться гарантированными методами. Для полной уверенности необходимо проконсультироваться с системным администратором.

Резервное копирование и восстановление (РКВ)

Как правило, резервное копирование и восстановление подразумевает методы и процедуры защиты вашей БД от потери данных.

АБД должен иметь ответы, а главное, четкие алгоритмы действий, на следующие вопросы:

§ Как будет осуществляться восстановление при сбое диска, содержащего набор файлов БД? Восстанавливать ли БД целиком или отдельными файлами?

§ При удалении таблицы по ошибке пользователя как будет восстанавливаться эта таблицы, с помощью утилиты импорта, восстановлением БД на момент времени или восстановлением ТП на момент времени.

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

Некоторые термины:

Physical backup – физическая копия файлов БД, в самом простом случае включающая в себя файлы ТП и управляющие (контрольные) файлы. Если БД функционирует в режиме ARCHIVELOG, в физическую копию также включаются и архивированные журналы повтора. Активные журналы повтора также могут включаться в физическую копию БД. Но здесь есть некоторые тонкости (см. далее «Как не потерять активные журналы повтора»).

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

Instance recovery – восстановление после сбоя одного экземпляра в среде RAC, когда общая кластерная БД остается в рабочем состоянии за счет оставшихся работоспобными экземпляров.

Crash recovery – восстановление после сбоя экземпляра в среде с одним экземпляром, либо восстановление после сбоя всех экземпляров в среде RAC (кластерная БД «упала»).

Два этих типа восстановления автоматически используют только активные журналы повтора и не используют архивные журналы для восстановления. Вмешательство пользователя не требуется. Происходит повторное применение изменений (rolling forward) из активных журналов, тех изменений, что не были записаны на диск в момент сбоя (блоки таблиц, индексов и сегментов отмены), а потом с помощью сегментов отмены(отката) осуществляется «откат» (rolling back) для тех данных, которые не были зафиксированы на момент сбоя. Зафиксированные же данные восстанавливаются корректно.

Media (datafile) recovery – чаще всего подразумевается восстановление поврежденных файлов данных (файлов ТП или контрольных файлов). Необходимо существование резервных копий файлов данных, может использовать (и часто использует) архивные журналы. От АБД требуется явное участие в процессе восстановления.

При подобном восстановлении информации к файлам данных из резервной копии применяются активные и архивные журналы, и также проиcходит «накат» (rolling forward). Но в этом случае он может продолжаться долгое время, т.к. количество изменений, сохраненных в архивных журналах и требуемых для восстановления может быть большим.

Восстановление файлов может быть полным или неполным.

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

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

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

- Потеря части или всех активных журналов повтора;

- Ошибка пользователя, приведшая к потере данных;

- Невозможность выполнить полное восстановление по причине повреждения архивыных журналов;

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

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

Методы выполнения РКВ

В СУБД Oracle 10gсуществует два основных метода осуществления РКВ:

· С использованием утилиты RMAN:

· Настраиваемое пользователем РКВ.

RMAN – утилита, входящая в набор стандартных утилит СУБД Oracle 10g. Она позволяет выполнять РКВ для БД Oracle версий 8 и выше. RMAN имеет свой собственный синтаксис и может быть использован как из командной строки, так и с помощью интерфейса OEM. RMAN поставляется с библиотеками API для работы с продуктами третьих фирм. Как правило, это касается механизмов управления различными типами накопителей для РКВ (например, ленточными).

Одно из принципиальных преимуществ RMAN – использование метаданных о проводимых операциях РКВ в управляющем файле БД. Можно также использовать независимый каталог восстановления, представляющий собой набор таблиц и представлений, содержащих импортированные из управляющего файла метаданные. Для большей надежности сохранения метаданных их можно помещать в отдельную БД, расположенную на другом физическом сервере. Сохранение метаданных о создании резервных копий, архивированных журналов повтора и т.д. позволяют значительно упростить восстановление.

Альтернативный метод выполнения РКВ – использование команд ОС для периодического создания физических копий файлов БД, и, при необходимости, восстановления с использованием SQL*Plus. Этот метод, настраиваемый пользователем, также может быть использован в работе с БД Oracle.

Когда для обеспечения стратегии управления РКВ используются RMAN или пользовательский вариант РКВ, создающие копии физических файлов, составляющих БД, то дополнительно можно создавать логические копии данных с помощью стандартной утилиты экспорта Exp. С ее помощью можно сохранять в двоичном файле ОС данные из БД, которые позже можно восстановить в БД с помощью утилиты импорта Imp.

Виды резервных копий

- Резервная копия всей БД;

- Резервные копии табличных пространств;

- Резервные копии файлов данных;

- Резервные копии управляющих файлов.

Резервная копия всей БД представляет собой копию хотя бы одного управляющего файла и всех файлов БД. Это – наиболее общий и простой вид резервного копирования.

Резервная копия всей БД может быть согласованной (consistent), либо нет (inconsistent). Согласованность определяется тем, нужно ли при открытии БД из этой копии применять журналы повтора. Согласованная копия БД – копия файлов БД после ее корректного закрытия с помощью команды SHUTDOWN NORMAL, IMMEDIATE или TRANSACTIONAL.

При открытии БД или при проведении операции восстановления заголовки файлов данных сравниваются с аналогичной информацией в управляющих файлах (это касается номеров зафиксированных транзакций - SCN). В процессе работы СУБД Oracle 10gпроводит согласование содержимого управляющих файлов и файлов данных во время выполнение контрольных точек.

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

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

Если к БД предъявлены требования функционирования в режиме 24Х7 (24 часа в сутки, 7 дней в неделю), то у АБД практически нет возможности создать согласованную копию файлов БД, ибо копии файлов делаются в открытой БД, а за время копирования отдельного файла в другие могут быть внесены изменения. Поэтому такой режим резервирования файлов БД осуществляется только в режиме ARCHIVELOG, где все изменения, внесенные в БД, могут быть восстановлены из журналов повтора.

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

Если ваша БД была закрыта в режиме SHUTDOWN ABORT, либо произошел сбой экземпляра, то вы получите несогласованные файлы данных. Но, если БД функционирует в режиме ARCHIVELOG, то подобная ситуация легко приводится к согласованному виду с помощью активных и архивных журналов повтора. Если же БД работает в режиме NOARCHIVELOG, то подобная ситуация может привести к безвозвратной потере данных.

Резервная копия табличных пространств представляет собой копии файлов, их составляющих. Подобная резервная копия является годной только в случае функционирования БД в режиме ARCHIVELOG. В этом случае необходимы журналы повтора для приведения табличных пространсвт из копии в согласованное состояние с другими ТП в БД. Если же БД функционирует в режиме NOARCHIVELOG, то можно получить валидную резервную копию ТП только в случае, если ТП на момент создания копии было либо в режиме «только для чтения», либо в отключенном, «off-line» состоянии. В этом случает при восстановлении ТП не потребуется применения журналов повтора.

Резервные копии отдельных файлов данных имеют смысл, в основном, только в режиме ARCHIVELOG.

Резервные копии управляющих файлов – один из ключевых аспектов стратегии РКВ. Без доступа к управляющему файлу невозможно смонтировать и открыть БД. Копии управляющих файлов, помимо физического копирования, можно делать с помощью команды ALTER DATABASE BACKUP CONTROLFILE (создается двоичная копия управляющего файла), либо команды ALTER DATABASE BACKUP CONTROLFILE TO TRACE (создается скрипт, из которого может быть создан аналогичный управляющий файл, правда, без записей об архивных журналах повтора и некоторой другой информации). Двоичная копия, как правило, предпочтительней.

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

Особенности настройки режима ARCHIVELOG

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

LOG_ARCHIVE_START=TRUE – включает режим автоматического архивирования заполненных журналов повтора.

LOG_ARCHIVE_DEST – указывает основное местоположение на диске, куда будут записываться архивированные журналы повтора. Не имеет силы, если указываются параметры вида LOG_ARCHIVE_DEST_ n.

LOG_ARCHIVE_DUPLEX_DEST – указывает дополнительное, второе расположение на диске, куда будут дублироваться архивные журналы повтора. Не имеет силы, если указываются параметры вида LOG_ARCHIVE_DEST_ n.

LOG_ARCHIVE_MIN_SUCCED_DEST – минимальное число число местоположений для записи архивированных журналов повтора, в которое должна состояться запись заполненного журнала, после чего он может снова стать текущим активным журналом повтора. Если используются параметры LOG_ARCHIVE_DEST и LOG_ARCHIVE_MIN_SUCCED_DEST, значение этого параметра может быть 1 или 2. При значении 1 архивирование журнала должно успешно осуществиться в LOG_ARCHIVE_DEST, при значении 2 – в оба местоположения.

Получение списка файлов для включения в резервную копию

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

spool filelist_for_backup

SELECT DECODE(f.name, null,

RTRIM(t.NAME)||' - '||'!! for the temporary datafiles look up in V$TEMPFILE!! ',

RTRIM(t.NAME)||' - '||RTRIM(f.NAME)) " Tablespace + Datafiles"

FROM V$TABLESPACE t, V$DATAFILE f

WHERE t.TS# = f.TS#(+)

ORDER BY t.NAME

/

SELECT NAME " Temporary datafiles" from V$TEMPFILE;

SELECT MEMBER " Redo logs" FROM V$LOGFILE;

SELECT NAME " Control files" FROM V$CONTROLFILE;

spool off

Теперь в файле filelist_for_backup будет содержаться список файлов, подлежащих копированию средствами ОС.

Пример восстановления одного файла данных:

Представьте, что в БД поврежден файл /oracle/dbs/users1.dbf, принадлежащий ТП USERS. Существует резервная копия /dsk2/backup/users1.dbf на другом носителе, и она в полной сохранности. Выяснено, что проблема в этом файле. Теперь необходимо перевести ТП в состояние off-line.

Естественно, такая методика использует режим ARCHIVELOG.

Дублирование контрольных файлов, активных журналов, архивных журналов.

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

§ Как минимум две копии контрольных файлов на различных дисковых устройствах. СУБД Oracle 10gпредлагает разделять их на этапе создания БД.

§ Две или более копий активных журналов также на разных дисковых устройствах.

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

Как не потерять активные журналы повтора

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