Oracle перенести индекс в другое табличное пространство
После Google не могу найти простой способ вернуть свободное место после удаления таблицы.
Я нашел много объяснений, рассказывающих, как файл данных становится фрагментированным, большой стек скучных запросов, которые вам нужно выполнить, чтобы переместить «пустое пространство» в конец файла данных (таблица за таблицей . даже когда вы есть 200 столов!?).
Затем вам нужно уменьшить размер файла данных, «угадав», насколько вы можете его уменьшить, или вы должны точно знать, каков ваш «размер блока» . И, наконец, вы не должны забывать «перестраивать индексы».
Существует ли простая процедура PL / SQL, которая, учитывая имя табличного пространства или имя файла данных, будет выполнять эту работу? Или любой подобный инструмент Oracle?
Краткий ответ - нет . К сожалению, способ сделать это в Oracle требует «большого количества скучных запросов». Статьи, на которые вы ссылаетесь, являются одними из лучших на эту тему. Файл данных действительно фрагментируется, поэтому даже если свободное пространство находится ниже самого высокого сегмента, Oracle не будет автоматически консолидировать его, когда RESIZE будет выполнено a .
Чтобы «дефрагментировать» табличное пространство, вам нужно переместить эти сегменты в начало файла данных, а не в конец. Для таблиц это автономный процесс, то есть таблица будет недоступна во время перемещения. Индексы можно перемещать либо в автономном режиме, либо с помощью Enterprise Edition их можно перемещать в режиме онлайн. Поскольку у вас есть окно отключения, я рекомендую вам выполнить следующие шаги.
A. Сжатие файлов данных со свободным пространством за отметкой максимальной воды. Это можно сделать следующим образом (запрос аналогичен процедуре Frosty Z):
Б. После того, как вы сузили положение выше верхней отметки, выясните, какие табличные пространства все еще выиграют от перемещения сегментов.
C. Для каждого из этих табличных пространств определите, какие сегменты необходимо переместить. (Замените USERS именем вашего табличного пространства или присоедините его к предыдущему запросу)
D. Переместите каждую таблицу и перестройте индексы и статистику.
E. повторите шаг A.
Я только что построил большинство этих запросов, так что вы захотите тщательно протестировать их перед использованием. Я полагаю, вы могли бы создать процедуру, которая использовалась бы EXECUTE IMMEDIATE для создания фактических операторов для динамического выполнения, но поскольку запросы будут получать ORA-08103: объект больше не существует, пока выполняется перемещение, я думаю, что лучше контролировать этот процесс вручную, даже если если это действительно означает немного больше времени / усилий.
В данном материале рассмотрим вопрос перемещения страницы в другое табличное пространство с использованием SQL запроса (команды) alter table xxx move tablespace zzz . В приводимом ниже примере перемещения применялся сервер Oracle 9.2i .
В результате перемещения таблицы в другое табличное пространство достигается очевидная цель - освободить место в разросшемся табличном пространстве. В ответе на вопрос на странице http://www.dba-oracle.com/t_alter_table_move_shrink_space.htm Donald Burleson утверждает, что метод move в отличии от использования запроса alter table mytable shrink space ( не доступен в Oracle 9) не позволяет уменьшить суммарный размер выделенных под таблицу экстентов памяти. Так вот - это не так. Если из таблицы удалено много строк, экстенты с блоками, выше HWM (High Water Mark - номер последнего использованного блока экстентов таблицы при последовательном их рассмотрении) - удаляются. И , кроме того, при перемещении таблицы удается избавиться от так называемых сцепленных и перемещенных строк. Как правило сцепление снижает производительность запроса, поскольку ORACLE вынужден искать одну строку в несколько приемов. Помимо сцепления строк ORACLE может перемещать их. Если строка превышает доступное в блоке место она может быть включена в другой блок. Процесс перемещения строки из одного блока в другой называется "миграцией" строк. . В ходе самого процесса ORACLE динамически управляет местом в нескольких блоках, а так же обращается к списку свободных для вставки данных блоков (free list). По своей сути перемещенная строка не является сцепленной, но перемещение влияет на производительность транзакции в целом!
Команду alter table xxx move tablespace zzz имеет смысл выполнять, когда в таблице много не используемых блоков ниже HWM, и когда таблица имеет сцепленные строки. Для этого достаточно выполнить два запроса
Последний запрос показывает количество обнаруженных в таблице сцепленных или перемещенные строк, а также оценку HWM (поле blocks). Если же нужна детальная информация о таких строках, то воспользуемся следующим способом.
Создадим таблицу CHAINED_ROWS с использованием утилиты rdbms/admin/utlchain.sql , которая содержит следующий код
После создания таблицы запрос analyze table xxx LIST CHAINED ROWS занесет в таблицу chained_rows информацию о всех сцепленных и перемещенных строках таблицы ххх . Если на первичный ключ таблицы не ссылаются другие таблицы, то для устранения сцепления и перемещения строк можно воспользоваться следующим способом.
- Изменим, при необходимости, параметры хранения таблицы ххх .
- Выполним запрос
- Удалим перемещенные и сцепленные строки их таблицы ххх
- Восстановим удаленные строки
- Удалим промежуточную таблицу xxx_tmp и соответствующие ей записи из таблицы chained_rows .
Все достаточно просто, но с таблицей обычно связаны внешние ключи других таблиц, и если этот ключ создан с опцией каскадного удаления, то мы потеряем записи в других таблицах.
Например , если мы обратимся к БД АСР "Фастком" с запросом select Cc.Table_Name,Cc.Column_Name, c.* from Dba_Constraints c,Dba_Cons_Columns cc where c.R_Owner='FASTCOM25P'
and C.r_Constraint_Name(+)=Cc.Constraint_Name
and cC.Table_Name='CT_T_CONTRACT'
order by C.Constraint_Name, то получим
Сразу видно, что удалить строку договора не удастся. Но и применять команду move к такой таблице без проверки не следует. Только в тестовой БД.
Перемещение таблицы можно выполнять без указания табличного пространства. В этом случае будет создан новый сегмент в том же табличном пространстве. На время перемещения таблица блокируется. Опция online применима только для индекс-ориентированных таблиц. Для обычных таблиц она не имеет смысла. Но перемещение происходит очень быстро.
Перемещение происходит успешно, перестроились все индексы, определенные на таблице. Индексы не имеет смысла перестраивать с опцией online, так как они не валидны. Теперь можно убедиться, что HWM не возрос и исчезли сцепленные и перемещенные строки. Об этом говорилось выше.
Для проверки использовались следующие коды.
Создадим тестовую таблицу и заполним ее данными
Конечно, таблица не содержит сцепленных строк. Так создадим их
Посмотрим экстенты таблицы
Удалим строки и переместим таблицу. Посмотрим экстенты и наличие сцепленных строк.
Общий размер экстентов уменьшился на 512 блоков, HWM уменьшился и в таблице не осталось сцепленных строк. Индексов мы на таблице не создавали, значит и перестраивать нечего.
Эта статья посвящена сравнению эффективности различных способов переноса таблицы в другое табличное пространство. По мотивам ответа Тома Кайта на вопрос, первоначально заданный еще в апреле 2001 года.
Как выполняется alter table . move tablespace?
Не Мог бы ты разъяснить, как реализован оператор alter table t_name move tablespace . Это можно делать в оперативном режиме (online) и без журнализации (с опцией nologging). Но как данные переностяся из одного табличного пространства в другое? Приходится ли серверу формировать операторы insert и передавать данные через буферный кэш как при обычной вставке или происходит что-то типа непосредственной вставки?
Я столкнулся со следующей проблемой, для которой хотел бы найти быстрый способ решения:
Есть таблица размером 2,5 Гбайта. Я хочу перенести ее из табличного пространства a в b . Все файлы a и b разбиты на полосы и находятся на разных дисках. Эта таблица - независима. Я имею ввиду, что для нее не заданы триггеры и ограничения целостности.
Первый способ:
Второй способ:
Будет ли второй способ работать быстрее, чем первый, за счет использования непосредственной вставки?
Какой сопособ будет работать быстрее, и почему? Допускает ли первый способ распараллеливание? Булет ли существенная разница в использовании сегмента отката и пространства для сортировки?
Ответ Тома Кайта
Действие move в оперативном режиме может выполняться ТОЛЬКО для таблицы, организованной по индексу (index organized table - IOT), но не для обычной таблицы, организованной в виде кучи.
Имеет смысл делать так:
Оператор alter table t move tablespace b nologging; перенесет таблицу (с журнализацией, если она была установлена), а затем установит атрибут nologging .
При выполнении move для переноса таблицы SQL не используется. Никакие вставки не выполняются.
Такой перенос хорош тем, что все индексы, привилегии и т.п. остаются. Необходимо только перестроить (но не пересоздать) индексы после переноса.
Второй способ может сработать быстрее, если использовать параллельные вставки (проверьте, что для задания подсказок оптимизатору используется /*+ , а не просто /* .) Но для этого вам придется больше потрудиться. Для таблицы размером 2,5 Гбайт я не уверен, что оно того стоит - может потребоваться больше времени на разработку процедуры переноса, чем на сам перенос.
Перенос табличного пространства с опцией nologging
В Oracle Enterprise Edition 8.1.7.2 я делаю следующее:
Я не знаю, работает это с журнализацией или без, но после переноса таблица в режим nologging не переводится. А в версии Oracle 8.1.6 результат другой?
Ответ Тома Кайта
Хорошо, параметр logging / nologging имеет два значения, в зависимости от контекста.
В том контексте, где вы использовали его выше, вы попросили перенос выполнять без журнализации, если объект допускает работу без журналлизации.
Если выполнить оператор " alter table t nologging ", происходит изменение атрибута logging / nologging .
Как всегда, понять это поможет пример. Мы создадим таблицу, перенесем ее и посмотрим, сколько данных повторного выполнения будет сгенерировано при использовании различных методов переноса:
Итак, есть тестовая таблица. Она первоначально создана в табличном пространстве UTILS и:
ее режим журнализации - YES (журнализация установлена). Теперь давайте посмотрим, сколько данных повторного выполнения уже сгенерировал сеанс, и сохраним это значение в подставляемой переменной V
А теперь выполним вашу команду. Эту команду можно на русском языке сформулировать так: "Перенести таблицу T в табличное пространство users, и, кстати, если можно, БЕЗ ЖУРНАЛИЗАЦИИ". В частности, эта команда НЕ говорит: "Перенести таблицу и изменить режим журнализации".
Итак, мы видим, что сгенерировано порядка 4 Мбайт данных повторного выполнения - кажется, что действие, фактически, журнализируется. Это можно подтвердить, ИЗМЕНИВ режим журнализации:
и снова перенеся эту таблицу:
Теперь мы сгенерировали всего лишь 26 Кбайт данных повторного выполнения - этого достаточно для регистрации изменений в словаре данных, но не изменений перенесенных блоков. Мы перенесли объект без журнализации всех изменений.
Фактически мы выяснили, что нельзя одновременно переносить объект и изменять его любым другим способом (эти опции взаимоисключающие - вы либо переносите объект, либо изменяете его другим образом - одновременно это делать нельзя)
Можно ли восстановить действие, если используется nologging?
Если происходит сбой базы данных и придется восстанавливать ее после использования nologging для переноса, можно ли будет восстановить это действие. А после восстановления будет ли тавблица в исходном табличном пространстве?
Ответ Тома Кайта
Это зависит от причины сбоя и других обстоятельств.
После выполнения НЕ ЖУРНАЛИЗИРУЕМОГО действия в базе данных, работающей в режиме ARCHIVELOG (в котором и должны работать практически все производственные базы данных) рекомендуется выполнить горячее резервное копирование затронутых табличных пространств. Это позволит выполнить восстановление после сбоя носителя (media recovery) для этих табличных пространств.
Если этого не сделать И произойдет сбой носителя (а не просто сбой экземпляра) после выполнения не журнализируемого действия - данные будут потеряны. Их нельзя восстановить из архива, поскольку их в архиве нет. При выполнении действий без журнализации следует быть осторожным и согласовать действия с теми, кто отвечает за резервное копирование базы данных. В противном случае, легко потерять данные.
В базе данных, работающей в режиме noarchivelog , поскольку восстанавливаться можно только на момент последней полной резервной копии, выполненной в холодном режиме, при сбое носителя этот вопрос вообще не актуален (потому и надо работать в режиме archivelog !).
Что значит "таблица, огранизованная в виде кучи"?
Ответ Тома Кайта
Вот небольшая цитата из моей книги на эту тему, подробнее - читайте книгу ( Я привожу цитату по моему переводу на русский - В.К. ):
Таблицы, организованные в виде кучи
Таблицы, организованные в виде кучи, используются приложениями в 99 (если не более) процентах случаев, хотя со временем это может измениться за счет более интенсивного использования таблиц, организованных по индексу, - ведь по таким таблицам теперь тоже можно создавать дополнительные индексы. Таблица, организованная в виде кучи, создается по умолчанию при выполнении оператора CREATE TABLE . Если необходимо создать таблицу другого типа, это надо явно указать в операторе CREATE .
"Куча" - классическая структура данных, изучаемая в курсах программирования. Это по сути большая область пространства на диске или в памяти (в случае таблицы базы данных, конечно же, на диске), используемая произвольным образом. Данные размещаются там, где для них найдется место, а не в определенном порядке. Многие полагают, что данные будут получены из таблицы в том же порядке, в каком туда записывались, но при организации в виде кучи это не гарантировано. Фактически гарантировано как раз обратное: строки будут возвращаться в абсолютно непредсказуемом порядке. Это очень легко продемонстрировать. Создадим такую таблицу, чтобы в моей базе данных в блоке помещалась одна полная строка (я использую блоки размером 8 Кбайт). Совсем не обязательно создавать пример с одной строкой в блоке. Я просто хочу продемонстрировать предсказуемую последовательность событий. Такое поведение будет наблюдаться для таблиц любых размеров и в базах данных с любым размером блока:
.
Списки свободных мест
Я перенес таблицы в новое локально управляемое табличное пространство, а затем проанализировал таблицы. Мне интересно, почему столбец NUM_FREELIST_BLOCKS=0 в dba_tables ? Во всех таблицах есть неиспользуемые блоки, а в одном блоке - лишь несколько строк.
Ответ Тома Кайта
Потому, что блоки, в которых НИКОГДА не было данных, будут выше отметки максимального уровня, а не в списках свободных мест.
В списки свободных мест блоки попадают после использования - если они никогда не использовались, то в списке свободных мест их не будет.
Сразу после пересоздания, как в вашем случае, вполне естественно, что в списке свободных мест блоков МАЛО, если вообще они там есть. Это просто означает, что все существующие блоки данных "упакованы" - в них больше нельзя вставлять строки. После изменения/удаления данных некоторые блоки окажутся в списке свободных мест.
Рассмотрим следующий пример (табличное пространство system управляется по словарю, а табличное пространство users - локально управляемое):
Плотно упакованная таблица - никаких блоков в списке свободных мест пока нет.
А теперь - есть; мы добавили блоки в списки свободных мест, удалив некоторые строки.
Теперь их снова нет - все свободные блоки находятся выше отметки максимального уровня (HWM), а не в списках свободных мест.
а вот опять появились - таблица больше не "упакована", так как при удалении часть места освободилась
Перенос таблиц в 7.3.4 Parallel Server
Мы используем Oracle 7.3.4 Parallel Server в ОС NCR SVR4 (на неформатированных дисках). Я также использовал второй подход для переноса таблиц в другие табличные пространства, поскольку в версии 7.3.4 оператор alter table move tablespace . Я делал так:
Затем я снова создал индексы по таблице orgfoo . Мне хотелось бы знать:
a) Хорошее ли это решение для версии 7.3.4? Я нашел твое решение на сайте, где рекомендуется:
- Экспортировать схему пользователя
- Удалить все объекты пользователя
- Отобрать привилегию unlimited tablspace у пользователя
- Изменить стандартное табличное пространство для пользователя
- Импортировать данные пользователя
Но я хочу перенести только одну большую таблицу, а не все таблицы. После удаления всех объектов, как мне импортировать данные в два различных табличных пространства?
b) После переименования таблицы, надо ли пересоздать все представления до запуска приложения?
c) Для таблицы orgfoo (в табличном пространстве EHISTDAT ) выделено 250 Мбайт. Эту информацию я получил из dba_data_files и dba_free_space перед удалением таблицы orgfoo .
А при запросе после создания таблицы tempfoo в EKATSDAT и удаления таблицы orgfoo , я получил следующий результат:
Количество экстентов и блоков в представлении dba_extents тоже отличается. В табличном пространстве EHISTDAT освободилось 250 Мбайт, а в табличном пространстве было выделено не 250, а всего лишь 110 Мбайт. Не могли бы это объяснить? Считаете ли вы подобные действия полезными для экономии места на диске?
Ответ Тома Кайта
Ваш метод вполне приемлем. Можно сделать экспорт отдельной ТАБЛИЦЫ, а не всей схемы - это тоже подойдет, но и ваш метод отлично подходит (если только пересоздать все ограничения, триггеры, привилегии и т.п. - все это утилита EXP делает автоматически).
После переименования таблицы ничего делать не нужно. Представления сами о себе позаботятся, как и хранимые процедуры.
Что касается различия "размеров" - вновь созданная таблица заново "упакована". В результате, она вполне может оказаться "меньше". А вот насчет "полезности для экономии места" - я так не думаю. Через пару недель/месяцев таблица снова вырастет до прежнего размера. Это как когда садятся на диету - вес немного уменьшается, но в конечном итоге он снова увеличивается до "комфортного". Регулярная реорганизация таблиц:
a) мне не кажется нужной
b) мною не рекомендуется (при этом часто приходится слышать "блин, часть данных потеряна" из-за ошибок по ходу реогранизации)
c) место на диске "экономит" на пару дней, а со временем размер снова увеличивается до прежнего стабильного уровня.
Сбой экземпляра при переносе таблицы с опцией nologging
Что произойдет при сбое экземпляра по ходу переноса таблицы с опцией nologging? Мы данные не потеряем? Это не опасно?
Ответ Тома Кайта
Нет, nologging влияет только на восстановление после сбоя НОСИТЕЛЯ, но не после сбоя экземпляра.
При переносе таблицы с опцией nologging таблица копируется из постоянного сегмента во ВРЕМЕННЫЙ сегмент. В самом конце этого действия, временный сегмент преобразуется в постоянный - вото тогда копия и становится реальной таблицей.
Если сбой экземпляра произойдет по ходу переноса, процесс SMON просто очистит временный сегмент, и все будет выглядеть так, как если бы мы вообще таблицу не трогали (постоянный сегмент остается на месте).
Если сбой экземпляра произойдет после переноса - все в порядке, поскольку данные писались непосредственно на диск и восстанавливать их при восстановлении экземпляра не нужно.
Если после переноса часть данных изменена, изменение зафиксировано и произошел сбой - тоде все в порядке, поскольку данные повторного выполнения для этих изменений доступны и их можно восстановить.
Если после переноса и ДО резервного копирования файлов, которые были затронуты действием с опцией nologging произойдет СБОЙ ДИСКА - тогда да, "у нас проблемы". Вот почему в производственной среде есть основания опцию NOLOGGING не использовать, а если уж использовать, то:
- сначала создать резервную копию объектов;
- выполнить действие без журнализации;
- снова создать резервную копию объектов.
Итак, проблем при сбое экземляра вообще не возникает!
У меня есть вопрос вдогонку: поскольку вы сказали, что по ходу переноса постоянный сегмент не трогают, это означает, что запросы продолжают читать данные из постоянной таблицы, а не из временной, не так ли? А можно ли применять к таблице операторы ЯМД? Или таблица блокируется исключительной блокировкой?
Ответ Тома Кайта
Да, по ходу выполнения alter table move данные таблицы можно читать.
Выполнять операторы ЯМД можно только если действие выполняется "online" ( alter index rebuild online , например, alter table move online - но только для таблиц, организованных по индексу).
В Oracle9i есть пакет dbms_redefinition для пересоздания в режиме online большинства объектов (что позволяет выполнять операторы ЯМД по ходу переноса).
Комментарий читателя от 4 октября 2002 года
Я видел твой пример переноса таблицы. В нем вместо 4 Мбайт данных повторного выполнения (если при переносе была включена журнализация) генерировалось всего 26 Кбайт.
Я попытался сделать то же самое, но не увидел разницы. Не мог бы ты сказать, что я делаю не так. Вот мои результаты:
Как видишь, когда таблица журнализировалась, было сгенерировано 54320 байта данных повторного выполнения, в без журнализации - 53908 байт. Даже больше на 412 байт.
Я использую Oracle 8.1.7 на Windows 2000.
Ответ Тома Кайта
Вы работаете в режиме noarchivelog .
В этом режиме для этого действия не нужно генерировать данные повторного выполнения - вот они и не генерируются, независимо от установки logging/nologging.
Распараллеливание?
Итак, если необходимо "перенести" таблицу в другое табличное пространство (например, из управляемого по словарю в локально управляемое) быстрее будет использовать INSERT /*+ APPEND*/ , перевести таблицу в режим nologging , а не использовать move (с опцией nologging )?
А как насчет распараллеливания в Oracle 8.1.6 STANDARD? Можно ли использовать нечто вроде:
Команда работает, но я не знаю, как проверить, было ли распараллеливание при выполнении.
Посоветуйте, с точки зрения только производительности, что лучше - INSERT с APPEND nologging или move nologging .
Ответ Тома Кайта
Распараллеливание возможно только в EE и PE. См. в документации
Так что, в SE распараллеливание недоступно.
Но почему вам показалось, что insert /*+ append */ должно быть лучше?
Я бы просто перевел таблицу T в режим nologging и перенес ее:
Это проще, чем insert append , при этом не теряются привилегии и индексы.
(Пороверить, что действие распараллеливается, можно выполнив запрос к v$px_processes по ходу выполнения действия)
Комментарий читателя от 12 июня 2003 года
Я протестировал оба способа, но не в среде SQL*Plus, так что прощу прощения, что не могу просто вырезать и вставить "всю правду".
Я создал два табличных пространства. Я создал таблицу на базе dba_objects и удваивал ее пока в ней не оказалось
1,8 миллиона строк.
350 Мбайт при размере блока 16 Кбайт.
Затем я перевел таблицу в режим nologging (без распараллеливания).
Тестовая машина - двухпроцессорная, с Oracle 8.1.6 EE и обычными дисками (без RAID). При тестировании каждый тест выполнялся минимум дважды:
Если надо, я повторю эти же тесты в среде SQL*Plus и скопирую результаты.
Итак, почему insert /*+ append*/ выполняется быстрее, чем move ?
Данных повторного выполнения генерировалось от 200 до 350 Kбайт.
Ответ Тома Кайта
Я бы сказал, что разница между 137 и 125 секундами (общего времени выполнения) не существенна. 12 секунд ни о чем не говорят - особенно на компьютере, выполняющем еще какие-то действия.
Но, как показывапет ваш же тест, alter table move parallel 2 работает в 2 раза быстрее (первая попытка распараллеливания могла работать медленнее из-за того, что пришлось запускать дочерние процессы PQ - а поскольку запуск 4 процессов занял так много времени, возможно, были конфликты при доступе к исходному или целевому диску).
Я бы не делал на этом основании вывода, что insert append работает быстрее. Я бы сказал, что это намного сложнее, менее удобно, и вообще неправильно.
Комментарий читателя от 18 июня 2003 года
Интересно, раз таблица была перенесена, то ее индексы стали недействительными и их надо перестраивать, - а как индекс перестраивается? По таблице с новыми значениями rowid (я так думаю) или по существующему индексу (rowid в котором больше нельзя использовать).
Порядок столбцов в операторе «Создание индекса» может повлиять на производительность запроса. Как правило, когда вы создаете композитный индекс, столбец часто использует в первом.
Если мы создадим композитный индекс для ускорения скорости запроса, такого как COL1, COL2 и COL3; затем только доступ к COL1 или только для доступа к Coll1 и COL2 будет ускорить. Но только доступ к COL2, только COL3 или запрос только COL2 и COL3 не будет использовать индексы.
Есть ли ограниченное количество кандидатов?
Стол может построить ряд индексов. Тем не менее, чем больше индексов, тем больше стоимость модификации таблицы. В частности, все индексы на таблице должны быть обновлены при вложении или удалении строк. Кроме того, при обновлении столбцов все индексы, содержащие столбец, должны быть обновлены.
Что такое индекс делеции?
- Он не ускоряет скорость запроса. Эта таблица может быть маленькой, или может быть много линий без записей индекса в таблице.
- Запрос программы не использует индексы
- Удалить оригинальный индекс до восстановления
Вы можете создать индекс, параллельный для создания индекса, используя головы
Вышеуказанные две операции - это экономия временной экономии, которые, конечно, создают параллельное создание, требует большего количества процессов, тогда требуется больше ресурсов. Огромные варианты уменьшают поколение Redo, и созданные большие показатели параллельно могут улучшить производительность.
Индекс недоступен:
Когда вы ввели много данных в таблицу, вы можете сделать индекс сначала непригодными, импортировать данные и восстановить индекс, который может повысить эффективность импорта. Вы можете создать неиспользуемый индекс, который может изменить статус индекса как нелюбимый, например, при создании неисправности индекса индекс помечен как непригодным для использования. Когда индекс разбиемого раздела помечен как неиспользуемый, индекс других разделов доступен. Индекс индекса или раздела, который нельзя использовать, должны быть восстановлены, удалены или воссозданы до того, как его можно будет использовать. Таблица усечения сделает неиспользуемый индекс, который будет доступен.
Параметр Skip_unusable_indexes установлен на true:
- Заявление о DML таблицы продолжается, но не поддерживает индекс
- Если есть недоступное ограничение, то DML бросит ошибку, чтобы остановить выполнение.
- Для неразделенных индексов оптимизатор не учитывает недоступный индекс при создании плана выполнения для оператора SELECT. Единственным исключением является явное указать индекс с использованием аннотаций INDEX ().
- Для индекса раздела, который недоступен для одного или нескольких разделов, если оптимизатор не может определить, может ли какой-либо раздел индекса можно отключить при компиляции запроса, оптимизатор не учитывает индекс. Это верно для таблиц разделов и не разделов. Единственным исключением является явное указать индекс с использованием аннотаций INDEX ().
Skip_unusable_indexes Параметры Это только false:
- Если существует недоступный индекс или раздел индекс, оператор DML этих индексов или разделов индекса будет завершен.
- Для оператора SELECT, если есть индекс или индекс раздела, который нельзя использовать, оптимизатор выполняет план без использования неиспользуемого индекса, то оператор продолжается. Однако, если оптимизатор выбирает неприятный индекс или неиспользуемый индекс раздела, оператор сообщит об ошибке для выполнения.
Индекс невидимый:
От базы данных Oracle 11G 1st вы можете создавать невидимые индексы или невидимые существующие индексы. Если вы не установите параметр инициализации OPTIONIZER_INVISIBLE_INDEXES, чтобы TRUE на сеансе или системном уровне, оптимизатор будет игнорировать невидимый индекс. В отличие от недопустимых индексов, невидимые индексы поддерживаются во время оператора DML. Хотя индекс раздела может быть установлен невидимым, видно, что другие индексы раздела можно увидеть без установки отдельного индекса раздела. С невидимым индексом вы можете сделать следующее:
- Проверьте индекс перед удалением индекса.
- Временную структуру индекса для некоторых из приложений или модулей, не влияющих на все приложение.
Взвешивание индекса или индекс реконструкции
| Индекс реконструкции | Слияние индекса |
|---|---|
| Может быстро переместить индексы в другие табличные пространства | Не может перемещать индексы в другие табличные пространства |
| Высокий накладной расход, нужно больше дискового пространства | Низкий накладной расход, нет больше дискового пространства |
| Создайте новое дерево, уменьшите глубину дерева как можно больше | Мистер Листья в той же ветке дерева |
| Возможность быстрого изменения параметров хранения и табличного пространства без необходимости удаления исходного индекса | Быстро выпустить индекс листьев для использования |
Блок индекса B дерева BLEX может быть выпущен, и эти блоки листьев объединяются с использованием следующего утверждения:
Рисунок 21-1 иллюстрирует влияние сочетания индекса ALTER для индекса VMOORE. Перед операцией первые два листа были более 50%. Следовательно, мусор может быть уменьшен и полностью заполнен первым блоком, а второй блок выделяется.
Рассмотреть расходы до отключения или удаления ограничений
Поскольку уникальные ограничения и ограничения первичных ключей имеют индекс, рассмотреть вопрос о незакреплении или удалении уникальных или первичных ключевых ограничений, рассмотрите возможность удаления и создания стоимости индекса. Если индекс уникальной кнопки или ограничения первичного ключа очень большой, вы можете сэкономить время, включив ограничения, а не удалять и воссоздать индекс. Вы также можете выбрать указать индекс, чтобы сохранить или удалить при удалении или отключении уникальных или первичных ключевых ограничений.
Давайте введем конкретный экземпляр синтаксиса SQL:
Здесь, наведенные и следующие параметры хранения указаны здесь
- Создать уникальный индекс
- Создайте индекс, связанный с ограничениями, могут быть реализованы несколько методов
- Создать отличный индекс
- Создайте большое временное пространство табличного стола, используйте его для создания индекса
- Используйте ALTER пользователь для переключения временного пространства табличного пространства
- Создать индекс
- Удалить это большое временное пространство табличного стола, переключитесь на исходное пространство временного стола, используя команду ALTER USER
- Создать индекс онлайн
- Создать индекс функции
- Создать сжатый индекс
- Создайте неверный индекс
- Создать невидимый индекс
- Индекс реконструкции
- Индекс недоступен
- Сделать индексы невидимыми
- Индекс монитора
- Контролировать использование места индекса
- Удалить индекс
- Связанный словарь данных
Взгляд головы DBA описывает информацию индекса для всех таблиц в базе данных. Взгляд всей заголовки описывает информацию индекса на всех доступных таблицах. Заголовок пользователя ограничен информацией индекса, принадлежащей пользователю. Некоторые столбцы в этих представлениях содержат статистику, сгенерированную пакетом DBMS_STATS или аналитическим утверждением.
DBA_INDEXES
ALL_INDEXES
USER_INDEXES
Следующий вид описывает информацию о перечисленных столбцах
DBA_IND_COLUMNS
ALL_IND_COLUMNS
USER_IND_COLUMNS
Таблица описания этих представлений на основе выражений индексации функций
DBA_IND_EXPRESSIONS
ALL_IND_EXPRESSIONS
USER_IND_EXPRESSIONS
Эти взгляды содержат информацию каждого индекса раздела, информацию о уровне разбиения, параметры хранения раздела и различной статистики раздела, создаваемых пакетом DBMS_STATS
DBA_IND_PARTITIONS
ALL_IND_PARTITIONS
USER_IND_PARTITIONS
Эти взгляды содержат индексированную статистику оптимизатора
DBA_IND_STATISTICS
ALL_IND_STATISTICS
USER_IND_STATISTICS
Статистика последнего анализа индекса анализа . Validate Структурное заявление
INDEX_STATS
INDEX_HISTOGRAM
Содержит информацию об использовании индекса, сгенерированную по индексу ALTE . Мониторинг использования
V$OBJECT_USAGE
Читайте также: