Oracle Database 11g предлагает несколько средств автоматического управления пространством. Эти средства избавляют от необходимости выполнять вручную несколько традиционных рутинных задач. В этой заметке моего блога вы ознакомитесь со следующими средствами автоматического управления пространством:
- Automatic Undo Management (Автоматическое управление отменой)
- Automatic Space Allocation (Автоматическое выделение пространства)
- Automatic Online Segment Shrinking (Автоматическое онлайновое усечение сегментов)
Automatic Undo Management
Отмена (undo) обеспечивает возврат к образу данных в том виде, в каком они были на момент начала транзакции. Все параллельные транзакции, запущенные в базе данных, должны вмещаться в пространство отмены, выделенное для них, в противном случае транзакция даст сбой. Конкуренция за сегменты отката и управление пространством всегда были большой проблемой в управлении базой данных, но при использовании рекомендуемого Oracle режима Automatic Undo Management (AUM), об этих проблемах беспокоиться уже не нужно.
При ручном управлении откатом вы вручную управляете сегментами отката и должны беспокоиться о назначении больших сегментов крупным транзакциям, чтобы избежать ошибки типа “устаревший снимок”. Вдобавок нужно беспокоиться о конкуренции за сегменты отката, о правильном выборе размеров сегментов и правильном их количестве. При использовании режима AUM вы просто создаете выделенное пространство отмены, выбираете период сохранения данных отмены, а Oracle сделает остальное.
Oracle представил AUM в выпуске Oracle9i. Под управлением AUM сегменты отката создается внутренне, и называются сегментами отмены (undo segments). Oracle автоматически справляется с задачей выбора количества и размеров сегментов отката, параллельным доступом к блокам и обеспечением согласованности чтения. Когда вы создаете табличное пространство отмены при создании базы данных, Oracle создает набор сегментов отмены и автоматически увеличивает количество и размеры этих сегментов в соответствии с внутренним алгоритмом, в зависимости от загрузки базы данных.
Простое управление файлами с помощью OMF
OMF значительно упрощает обращение с файлами данных, управляющими файлами, файлами журналов повторного выполнения и файлами резервных копий RMAN. Обычно, если вы удаляете файл данных, база данных не имеет никаких ссылок на этот файл, но физический файл все еще остается на своем прежнем месте, и его потребуется удалить явно. При использовании OMF СУБД Oracle самостоятельно удалит файл, когда вы удалите его из базы данных. Согласно заявлению Oracle, файловые системы OMF больше всего подходят для баз данных, использующих Logical Volume Managers (диспетчеры логических томов), которые поддерживают RAID и расширяемые файловые системы. Больше всего от OMF выигрывают небольшие базы данных, потому что при этом сокращается объем работ по управлению файлами. Тестовые базы данных — еще одна область, где файловые системы OMF сокращают время управления.
Если нужно использовать средство OMF, потребуется иметь дело с файлами операционной системы; применять “чистые” (raw) файлы нельзя. При использовании файлов OMF в некоторой степени утрачивается контроль над размещением данных в системе хранения, но даже с учетом этих ограничений преимущества управления файлами OMF в некоторых ситуациях перевешивают.
Преимущества использования OMF
Можно создавать табличные пространства с файлами на базе OMF. Также можно указать, что файлы журналов повторного выполнения и управляющие файлы должны быть в формате OMF. Файлы OMF обеспечивают несколько преимуществ перед файлами, управляемыми пользователем.
- Oracle автоматически создает и удаляет файлы OMF.
- Не нужно беспокоиться о соблюдении соглашений по именованию файлов.
- Когда вы сами управляете файлами данных, очень легко по ошибке уничтожить некоторые из них. С файлами OMF вы никогда не рискуете нечаянно удалить файлы базы данных.
- Oracle автоматически удаляет файл, когда он больше не нужен.
- Можно иметь смесь традиционных файлов с файлами OMF в одной и той же базе данных.
В следующих разделах мы детально рассмотрим средства OMF.
Создание файлов OMF
Создать файлы OMF можно при создании базы данных или же добавить их позднее к базе данных, созданной традиционным путем. В любом случае потребуется установить некоторые параметры инициализации для разрешения создания файлов OMF.
Параметры инициализации для OMF
Чтобы разрешить использование файлов OMF, необходимо установить четыре параметра инициализации, которые можно оперативно изменять с помощью команды ALTER SYSTEM или ALTER SESSION. Эти параметры служат для указания местоположения различных типов файлов OMF.
- DB_CREATE_FILE_DEST. Этот параметр специфицирует местоположение файлов данных по умолчанию, файлов отслеживания изменений блоков и временных файлов. Если параметры DB_CREATE_ONLINE_LOG_DEST_n не применяются, то Oracle использует значение параметра DB_CREATE_FILE_DEST в качестве местоположения по умолчанию для всех управляющих файлов и онлайновых журналов повторного выполнения. При желании можно также специфицировать местоположение управляющего файла. К сожалению, параметр DB_CREATE_FILE_DEST может принимать только одно значение — имя каталога; специфицировать несколько файловых систем в этом параметре нельзя. Если назначенный для создания файлов каталог окажется заполненным, вы всегда сможете специфицировать новый каталог, потому что параметр DB_CREATE_FILE_DEST является динамическим. Это позволит разместить файлы данных Oracle в любом месте файловой системы без каких-либо ограничений.
- DB_RECOVERY_FILE_DEST_SIZE. Этот параметр специфицирует размер области пакетного восстановления.
- DB_CREATE_ONLINE_LOG_DEST_n. Этот параметр служит для спецификации местоположения по умолчанию управляющих файлов и файлов онлайновых журналов повторного выполнения. В этом параметре n задает количество файлов журналов повторного выполнения или управляющих файлов, которые вы хотите, чтобы Oracle создал (n = 1, 2, 3, 4, 5).
- DB_RECOVERY_FILE_DEST. Этот параметр определяет местоположение по умолчанию для резервных копий RMAN, ретроспективных журналов и архивированных журналов повторного выполнения. Если параметр DB_CREATE_ONLINE_LOG_DEST_n опущен, DB_RECOVERY_FILE_DEST определит местоположение файлов онлайновых журналов повторного выполнения и управляющих файлов. Местоположение каталога, который вы укажете в этом параметре, также известно как область пакетного восстановления.
Даже если не указать ни одного из этих параметров в файле init.ora или SPFILE, все равно с помощью команды ALTER SYSTEM можно динамически включить создание файлов OMF:
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = 2 '/test01/app/oracle/oradata/finance1'; System altered. SQL>
Пока специфицирован параметр DB_CREATE_FILE_DEST, можно рассчитывать на то, что Oracle будет создавать файлы OMF, и вы без проблем сможете пользоваться как управляемыми пользователем, так и файлами OMF.
Соглашения об именовании файлов
При построении имен файлов Oracle использует стандарт OFA, поэтому имена файлов уникальны и файлы данных легко идентифицируемы как относящиеся к определенному табличному пространству. В таблице 1 показаны соглашения об именовании различных видов файлов OMF с примерами для каждого типа. Обратите внимание, что буква t означает уникальное имя табличного пространства, g — группу онлайнового журнала повторного выполнения, а u — 8-символьную строку.
| Тип файла OMF | Соглашение об именовании | Пример |
| Файл данных | ora_t%_u.dbf | ora_data_Y2ZV8P00.dbf |
| Временный файл (размер по умолчанию — 100 Мбайт) | ora_%t_u.tmp | ora_temp_Y2ZWGD00.tmp |
| Онлайновый файл журнала повторного выполнения (размер по умолчанию — 100 Мбайт) | ora_%g_%u.log | ora_4_Y2ZSQK00.log |
| Управляющий файл | ora_u%.ctl | ora_Y2ZROW00.ctl |
Типы файлов OMF
OMF можно использовать для создания трех типов файлов, которые требуются базе данных Oracle: управляющих файлов, файлов журналов повторного выполнения и файлов данных. Однако существует интересное отличие в том, как OMF требует специфицировать (или не специфицировать) каждый из этих типов файлов. Далее мы покажем, как Oracle создает три разных типа файлов.
Управляющие файлы
Как вы, вероятно, уже заметили, не существует специфического параметра, который должен быть включен в файл init.ora для указания формата OMF. Если вы специфицируете параметр CONTROL_FILES, то, конечно, должны указать полное местоположение управляющих файлов и, очевидно, они не будут файлами OMF — вы самостоятельно управляете ими. Если параметр CONTROL_FILES не задан, а используется параметр DB_CREATE_FILE_DEST или DB_CREATE_ONLINE_LOG_DEST_n, то управляющие файлы будут файлами OMF.
При использовании традиционного файла init.ora, в него понадобится добавить местоположение управляющих файлов. Если же применяется SPFILE, то Oracle добавит в него информацию об управляющих файлах автоматически.
Файлы журналов повторного выполнения
Создание файлов журналов повторного выполнения OMF подобно созданию управляющих файлов. Если местоположение файлов журнала повторного выполнения не указано, но в файле init.ora установлен параметр DB_CREATE_FILE_DEST или DB_CREATE_ONLINE_LOG_DEST_n, то Oracle автоматически создаст файлы журналов повторного выполнения на основе OMF.
Файлы данных базы Oracle
Если в операторах CREATE или ALTER для обычного файла данных, временного файла для временного табличного пространства или же файла данных табличного пространства отмены местоположение файлов данных не указывается, но вместо этого специфицируется параметр DB_CREATE_FILE_DEST, то все эти файлы станут файлами OMF.
Простое создание базы данных с использованием OMF
Давайте рассмотрим простой пример, чтобы увидеть, как файлы OMF могут действительно упростить создание базы данных. При создании новой базы следует указать Oracle местоположение управляющего файла, файла журнала повторного выполнения и файлов данных. Некоторые местоположения файлов специфицируются в файле инициализации (местоположение управляющего файла), а некоторые — при создании базы данных (такие как местоположения журналов повторного выполнения). Однако если используются файлы на базе OMF, то создание базы данных становится парой пустяков, в чем вы убедитесь в следующем разделе.
Установка параметров местоположения файлов
Давайте зададим для новой базы данных на базе OMF по имени NICKO следующие параметры инициализации:
db_name=nicko DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata' DB_RECOVERY_FILE_DEST_SIZE = 1000M DB_RECOVERY_FILE_DEST = '/u04/app/oracle/oradata' LOG_ARCHIVE_DEST_1 = 'LOCATION = USE_DB_RECOVERY_FILE_DEST'
Обратите внимание, что из четырех параметров инициализации, относящихся к OMF, выбраны только DB_CREATE_FILE_DEST, DB_RECOVERY_FILE_DEST_SIZE и DB_RECOVERY_FILE_DEST. В этом примере мне использовать четвертый параметр — DB_CREATE_ONLINE_LOG_DEST_n — не нужно. Когда этот параметр опущен, Oracle создает копию файла журнала повторного выполнения в месте, указанном параметрами DB_CREATE_FILE_DEST и DB_RECOVERY_FILE_DEST. Таким образом, есть две копии управляющего файла и онлайновых файлов журнала повторного выполнения.
Установка последнего параметра — LOG_ARCHIVE_DEST_1 — сообщает Oracle о том, что архивированные журналы повторного выполнения нужно отправлять в область пакетного восстановления, указанную в параметре DB_RECOVERY_FILE_DEST.
Запуск экземпляра
Используя простой файл init.ora из предыдущего раздела, можно запустить экземпляр, как показано в листинге ниже:
$ export ORACLE_SID=nicko [nicko] $ sqlplus /nolog SQL*Plus: Release 11.1.0.6.0 - Production on Thu Apr 10 11:52:13 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. SQL> connect sys/sys_passwd as sysdba Connected to an idle instance. SQL> STARTUP NOMOUNT PFILE='initnicko.ora'; ORACLE instance started. Total System Global Area 188743680 bytes Fixed Size 1308048 bytes Variable Size 116132464 bytes Database Buffers 67108864 bytes Redo Buffers 4194304 bytes SQL>
Создание базы данных
Теперь, после успешного создания экземпляра Oracle, можно создать новую базу данных NICKO с помощью следующей простой команды:
SQL> CREATE DATABASE nicko; Database created. SQL>
Вот и все! Эти две простые строки — все, что потребуется для создания полностью функциональной базы данных с перечисленными ниже структурами.
- Табличное пространство System создается по умолчанию в файловой системе, указанной параметром DB_CREATE_FILE_DEST (/u01/app/oracle/oradata).
- Табличное пространство Sysaux создается в файловой системе по умолчанию (/u01/app/oracle/oradata).
- Две дублирующие группы журналов повторного выполнения.
- Две копии управляющего файла.
- Временное табличное пространство по умолчанию.
- Табличное пространство отмены, автоматически управляемое Oracle.
Не забудьте обновить файл параметров инициализации (initnicko.ora в рассмотренном примере) именами и местоположением копий управляющего файла, сгенерированными показанным здесь оператором CREATE DATABASE.
Где расположены файлы OMF
Увидеть различные файлы, относящиеся к базе данных, можно, заглянув в журнал предупреждений новой базы данных — alert_nicko.log, — который вы найдете в каталоги _$ORACLE_HOME/rdbms/log, поскольку мы не специфицировали в init.ora каталог BACKGROUND_DUMP_DEST. Если вы используете новый параметр Oracle Database 11g под названием DIAGNOSTIC_DEST, то найдете журнал предупреждений в каталоге <домашний_каталог>/alert.
В следующем фрагменте файла журнала предупреждений базы данных можно увидеть, как создавались разные файлы, необходимые для вновь созданной базы данных. Сначала Oracle создает управляющие файлы и помещает их в место, указанное в параметре DB_CREATE_ONLINE_LOG_DEST_n:
create database nicko default temporary tablespace temp WARNING: Default passwords for SYS and SYSTEM will be used. Please change the passwords. Created Oracle managed file /u01/app/oracle/oradata/NICKO/controlfile/o1_mf_150w . . . Completed: create database nicko default temporary tablespace MMNL started with pid=13, OS id=28939
Вот что покажет журнал предупреждений относительно создания управляющих файлов:
Created Oracle managed file /u01/app/oracle/oradata/NICKO/controlfile/o1_mf_150w h3r1_.ctl Создан управляемый Oracle файл /u01/app/oracle/oradata/NICKO/controlfile/o1_mf_150w h3r1_.ctl Created Oracle managed file /u04/app/oracle/oradata/NICKO/controlfile/o1_mf_150w h3xx_.ctl
Далее сервер Oracle создает файлы дублированных онлайновых журналов повторного выполнения. Oracle создает минимальное необходимое количество групп и дублирует их, создавая набор онлайновых файлов журналов (двух) в месте, заданном параметрами DB_CREATE_ONLINE_LOG_DEST и DB_RECOVERY_FILE_DEST:
Created Oracle managed file /u01/app/oracle/oradata/NICKO/onlinelog/o1_mf_1_150w h48m_.log Created Oracle managed file /u04/app/oracle/oradata/NICKO/onlinelog/o1_mf_1_150w hf07_.log Created Oracle managed file /u01/app/oracle/oradata/NICKO/onlinelog/o1_mf_2_150w honc_.log Created Oracle managed file /u04/app/oracle/oradata/NICKO/onlinelog/o1_mf_2_150w hwh0_.log
Затем в месте, указанном в параметре DB_CREATE_FILE_DEST, создается табличное пространство System:
create tablespace SYSTEM datafile /* OMF datafile */ default storage (initial 10K next 10K) EXTENT MANAGEMENT DICTIONARY online Created Oracle managed file /u01/app/oracle/oradata/NICKO/datafile/o1_mf_system_ 150wj4c3_.dbf Completed: create tablespace SYSTEM datafile /* OMF datafile
Далее, как показано ниже, создается табличное пространство по умолчанию Sysaux:
create tablespace SYSAUX datafile /* OMF datafile */ EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO online Created Oracle managed file /u01/app/oracle/oradata/NICKO/datafile/o1_mf_sysaux_ 150wkk9n_.dbf Completed: create tablespace SYSAUX datafile /* OMF datafile
Затем в месте, указанном в параметре DB_CREATE_FILE_DEST, создается табличное пространство отмены с именем по умолчанию SYS_UNDOTS. Временное табличное пространство по имени TEMP также создается в этом каталоге.
CREATE UNDO TABLESPACE SYS_UNDOTS DATAFILE SIZE 10M AUTOEXTEND ON Created Oracle managed file /test01/app/oracle/oradata/ora_omf/finDATA/ora_sys_undo_yj5mg123.dbf . . . Successfully onlined Undo Tablespace 1. Completed: CREATE UNDO TABLESPACE SYS_UNDOTS DATAFILE SIZE 1 CREATE TEMPORARY TABLESPACE TEMP TEMPFILE Created Oracle managed file /test01/app/oracle/oradata/ora_omf/finDATA/ora_temp_yj5mg592.tmp Completed: CREATE TEMPORARY TABLESPACE TEMP TEMPFILE
Добавление табличных пространств
Добавление новых табличных пространств и файлов данных внутри системы OMF выполняется просто. Все, что для этого нужно — вызвать команду CREATE TABLESPACE без ключевого слова DATAFILE. Oracle автоматически создаст файлы данных для табличного пространства в месте, указанном в параметре DB_CREATE_FILE_DEST. Следующий пример показывает, как создать табличное пространство:
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = 2 '/test01/app/oracle/ora_omf/finance1'; System altered. SQL> CREATE TABLESPACE omftest; Tablespace created. SQL> SELECT file_name FROM dba_data_files 2 WHERE tablespace_name='OMFTEST'; FILE_NAME ----------------------------------------------------------- /test01/app/oracle/oradata/ora_omf/ora_omftest_yj7590bm.dbf SQL>
Сравните этот оператор создания табличного пространства OMF с типичным оператором создания табличного пространства, и вы убедитесь, насколько OMF упрощает администрирование базы данных. Добавление файлов данных с OMF также просто, что видно из следующего примера:
SQL> ALTER TABLESPACE omftest ADD DATAFILE;
Как видите, файлы OMF упрощают рутинные задачи администрирования и позволяют создавать и управлять базами данных с минимальным набором параметров инициализации. Вы можете легко установить необходимое количество местоположений файлов онлайновых журналов повторного выполнения, управляющих файлов и файлов архивированных журналов, указав соответствующие значения для различных параметров OMF. Файловая система Oracle, базирующаяся на ASM, полагается на файловую систему OMF.
Онлайновое усечение сегментов и Segment Advisor
В Oracle рекомендуют применять онлайновое усечение сегментов (online segment shrinking) для сжатия сегментов, которые со временем становятся фрагментированными из-за операций обновления и удаления. Маркер максимального уровня заполнения (high-water mark — HWM) сегмента показывает наивысшую точку использования пространства, достигнутую сегментом. Если имеется неиспользуемое пространство выше HWM, это значит, что такое пространство никогда не было использовано табличным или индексным сегментом.
В блогах уже упоминалось о том, что с помощью пакета DBMS_SPACE можно узнать объем неиспользуемого пространства в сегменте. Затем это неиспользуемое пространство сегмента можно отобрать, выдав оператор ALTER TABLE (или ALTER INDEX)...DEALLOCATE..., как показано ниже:
SQL> ALTER TABLE persons DEALLOCATE UNUSED KEEP 1000M;
После выполнения этой команды Oracle возьмет все место свыше 1000 Мбайт из сегмента person и сделает его доступным для других сегментов в табличном пространстве.
Например, если при вставке строк вы использовали 80% пространства табличного сегмента, то HWM для этого сегмента составит 80%. Позднее, даже если половина строк будет удалена, HWM таблицы останется на уровне 80%. Это дает нежелательный эффект при полнотабличном сканировании, а также сканировании индексов, потому что Oracle будет постоянно сканировать таблицу вплоть до HWM, даже несмотря на то, что в данный момент в таблице находится очень мало данных.
Табличный сегмент с большим количеством удалений приведет к высокой фрагментации, оставляя множество пробелов ниже HWM. Конечно, можно вернуть место, выделенное таблице, создав новую таблицу, скопировав в нее имеющееся содержимое и уничтожив старую таблицу. В предыдущих версиях Oracle также можно было забрать неиспользуемое пространство в табличном или индексном сегментах, реорганизуя объект, что обычно подразумевает применение команды MOVE. Такие реорганизации, которые на самом деле пересоздают объект в том же или другом табличном пространстве, иногда требуют очень много времени, к тому же им нужно дополнительное пространство. В результате, в противоположность заверениям Oracle, онлайновая доступность операций DML иногда снижается.
Начиная с версии Oracle Database 10g, можно использовать возможность усечения сегментов, чтобы отобрать свободное пространство у разреженных сегментов и вернуть его родительскому табличному пространству. Можно понизить HWM, сделав данные в сегменте более компактными. Кроме того, начиная с Oracle Database 10g, можно усекать таблицы (включая индекс-таблицы), разделы и подразделы таблиц, индексов и материализованных представлений (а также журналы материализованных представлений).
На заметку! Возможность усечения сегментов считается онлайновой операцией по месту. Она онлайновая, потому что во время операции усечения пользователи по-прежнему имеют доступ к таблицам. Операция по месту означает, что при выполнении операций усечения сегментов не требуется никакого дублирующего или временного пространства в базе данных.
Внутри Oracle обрабатывает операции усечения как операции вставки/удаления. Поскольку вы лишь перемещаете данные, а не модифицируете их, при выполнении операции усечения триггеры таблиц не запускаются. После операции усечении таблицы с целью высвобождения места индексы таблицы остаются действительными.
Совет. Для того чтобы сегменты могли подвергаться операциям усечения, табличное пространство должно быть локально управляемым и использовать ASM.
Ручное усечение сегментов
Для усечения сегментов применяются простые команды SQL. Операции усечения сегментов сжимают фрагментированное пространство в сегментах и дополнительно освобождают пространство.
Перед усечением сегментов сначала для каждого такого сегмента необходимо разрешить перемещение строк. Это делается с помощью конструкции ENABLE ROW MOVEMENT в команде ALTER TABLE, как показано ниже:
SQL> ALTER TABLE test ENABLE ROW MOVEMENT;
Разумеется, если конструкция ENABLE ROW MOVEMENT была специфицирована еще во время создания таблицы, запускать эту команду перед операцией усечения сегментов не придется. По умолчанию перемещение строк на уровне сегмента отключено. Операция усечения сегментов включает в себя две фазы.
- Фаза сжатия. Во время фазы сжатия строки в таблице сжимаются и перемещаются в левую часть сегмента. Таким образом, вы делаете сегмент плотным, хотя HWM остается на прежнем уровне. Высвобожденное пространство не становится свободным немедленно. Можно продолжать выполнять операторы DML и запросы на сегменте, пока он сжимается. Oracle удерживает блокировки только на пакетах строк, участвующих в операциях DML. Если есть какие-то долго выполняющиеся запросы, то Oracle может читать все блоки, которые были технически реорганизованы во время операции усечения. Конечно, эта возможность зависит от временного интервала, который был указан в параметре сохранения данных отмены.
- Фаза настройки HWM и освобождения пространства. На второй фазе, которая требует очень небольшого периода времени, Oracle снижает уровень HWM и возвращает все свободное пространство свыше HWM родительскому табличному пространству. Oracle блокирует объект в исключительном режиме на период снижения HWM, и это значит невозможность выполнения в это время DML-операторов INSERT, UPDATE и DELETE на сегменте.
Внимание! Во время фазы сжатия объект остается в онлайновом режиме и доступен, но во время второй фазы объект становится кратковременно недоступным — из-за исключительной блокировки сегмента.
Базовый оператор усечения сегментов выполнят обе фазы этой операции последовательно (сначала собственно сжимая данные, а затем переустанавливая HWM и возвращая высвобожденное пространство). Ниже приведен пример этого оператора (имя сжимаемой таблицы — test):
SQL> ALTER TABLE test SHRINK SPACE;
При получении этой команды Oracle сначала сожмет сегмент, а затем переустановит уровень HWM и вернет освободившееся место табличному пространству.
Во время второй фазы переустановка HWM затронет операции DML, и выполнять ее, когда к базе данных подключено большое количество пользователей, может оказаться нецелесообразным. Вместо этого можно выдать следующую команду, которая лишь выполняет первую фазу, сжимая данные в сегменте:
SQL> ALTER TABLE test SHRINK SPACE COMPACT;
Таким образом, в часы пиковых нагрузок база данных просто упакует пространство в сегменте. Затем, в часы минимальных нагрузок, можно будет запустить команду ALTER TABLE имя_таблицы SHRINK SPACE, которая завершит процесс усечения, выполнив вторую его фазу.
В случае указания опции CASCADE в операции усечения сегмента все зависимые сегменты также будут усечены. Например, при усечении таблицы все зависимые индексные сегменты также будут автоматически усечены. Ниже показан пример применения опции CASCADE:
SQL> ALTER TABLE test SHRINK SPACE CASCADE;
Использование Segment Advisor для усечения сегментов
С использованием нового инструмента Segment Advisor (Советник по сегментам) легко идентифицировать сегменты, которые являются хорошими кандидатами на усечение. Советник Segment Advisor основывает свои рекомендации на степени фрагментации объекта. Он определяет, достаточно ли в объекте имеется пространства для высвобождения, принимая во внимание будущие потребности этого объекта в соответствии с хронологическими тенденциями. Помимо помощи в выборе кандидатов на усечение, Segment Advisor также полезен в определении размеров новых объектов базы данных. В следующих разделах описано применение Segment Advisor для обеих целей.
На заметку! Использовать Segment Advisor можно только в Oracle Database 10.1 и 10.2, а также в Oracle Database 11g Release 1 и последующих выпусках (12c в том числе). Для запуска Segment Advisor понадобится привилегия ADVISOR (в дополнение к привилегии CREATE ANY JOB (или CREATE JOB)).
Выбор объектов — кандидатов на усечение
Вызывать Segment Advisor можно либо на уровне индивидуального сегмента, либо на уровне табличного пространства. Запустить Segment Advisor можно со страницы Advisor Central (Центр советников) в интерфейсе Database Control (куда можно добраться из домашней страницы Database Control щелчком на ссылке Advisor Central в разделе Related Links (Связанные ссылки), а затем щелкнув на ссылке Segment Advisor (Советник по сегментам)). На рисунке ниже показана главная страница Segment Advisor.
Segment Advisor может генерировать рекомендации на трех уровнях: объекта, сегмента и табличного пространства. Рекомендация может состоять в усечении или реорганизации, в зависимости от перечисленных ниже критериев.
- Если объекты созданы в локально управляемых табличных пространствах по умолчанию с включенным ASM, то Segment Advisor рекомендует усечение сегментов.
- Если используется ручное управление пространством сегментов, или объект не подлежит операции усечения, то Segment Advisor рекомендует реорганизацию такого объекта.
Запускать Segment Advisor можно в двух режимах.
- Всесторонний анализ. Segment Advisor выполнит анализ независимо от наличия или отсутствия предварительной статистики. Если статистика отсутствует, то Segment Advisor проверит объекты перед выдачей рекомендаций. Такой анализ требует больше времени.
- Ограниченный анализ. Этот анализ базируется строго на статистике, собранной в сегменте. Если для объекта не существует никакой статистики, анализ не может быть выполнен.
AWR собирает всю статистику по использованию пространства во время регулярного сбора снимков. Segment Advisor для оценки будущих потребностей сегмента в пространстве применяет отчет о тенденциях роста, основанный на данных использования пространства AWR. Просмотреть рекомендации Segment Advisor можно через OEM, щелкнув на ссылке Segment Advisor Recommendations (Рекомендации советника по сегментам) на странице Segment Advisor.
Автоматическое задание Segment Advisor
В Oracle Database 10.2 и последующих версиях Oracle предоставляет автоматическое задание Segment Advisor по имени AUTO_SPACE_ADVISOR_JOB, которое автоматически определяет проблемы, связанные с пространством сегмента. Вот детали задания, которые можно увидеть через представление DBA_SCHEDULER_JOBS:
- JOB_NAME: AUTO_SPACE_ADVISOR_JOB
- PROGRAM_NAME: AUTO_SPACE_ADVISOR_JOB
- SCHEDULER_NAME: MAINTENANCE_WINDOW_GROUP
Задание Segment Advisor запускается автоматически во время окна обслуживания, идентифицируя кандидатов на операцию усечения сегментов в зависимости от степени фрагментации пространства внутри объекта. Просматривать рекомендации задания Segment Advisor можно точно так же, как рекомендации советника Segment Advisor, вызванного вручную, как было показано в предыдущем разделе. Если щелкнуть на ссылке Segment Advisor Recommendations на странице Segment Advisor, отобразится список рекомендаций Segment Advisor, подготовленных им при последнем запуске. Страница Segment Advisor Recommendations показана на рисунке ниже:
Автоматическая настройка контрольных точек
Oracle способен к восстановлению после неожиданного краха базы данных без потерь информации. Помните, что когда происходит крах базы, последующее восстановление предполагает две фазы.
- Фаза повторного выполнения или наката вперед. На первой фазе база данных применяет к файлам данных все изменения, как зафиксированные, так и не зафиксированные, которые еще не были проведены в части файлов данных. Эти транзакции восстанавливаются из журнала повторного выполнения.
- Фаза отмены или отката. На второй фазе отменяются все незафиксированные транзакции, которые были записаны в файлы данных на предыдущем шаге.
После краха база данных не может быть открыта без выполнения восстановления. Однако тут есть интересный момент: Oracle позволяет открыть базу данных перед завершением второй фазы. Как только прошла фаза повторного выполнения или наката, база открывается для пользователей, пока процесс SMON выполняет откат в фоновом режиме. Когда пользовательский процесс попадает в транзакцию, заблокированную для отката, он быстро откатывает транзакцию. Эти прерывистые откаты не оказывают заметного влияния на производительность пользовательских запросов. А это значит, что база данных открывается намного быстрее после краха, чем если бы пришлось ждать завершения обеих фаз восстановления.
На заметку! Время, необходимое на выполнение второй фазы (откат), зависит от того, насколько много информации отмены нужно откатить.
Начиная с версии Oracle Database 10g, можно автоматизировать настройку контрольных точек, полностью избегая установки любых параметров инициализации, относящихся к контрольным точкам, присвоив параметру FAST_START_MTTR_TARGET ненулевое значение. По умолчанию значение этого параметра равно 0. Oracle автоматически настроит формирование контрольных точек, находя компромисс между потребностями восстановления и накладными расходами пропускной способности базы данных.
