Сегмент отката oracle это

Обновлено: 05.07.2024

Теперь, рассмотрим сегмент ИНДЕКС таблиц БД. Индексы необходимы для ускорения поиска данных в таблицах. В индексе хранятся значения одного или нескольких столбцов, а так же столбец ROWID для каждого из хранимых значений. При поиске в таблице используется значение ROWID конкретной записи, и она возвращается непосредственно. В БД Oracle используется несколько типов индексов. Один из них называется B*-Tree-Index (двоичный древовидный индекс). Индексы такого типа формируются командой CREATE INDEX. Показывать как это делается я пока не буду, к этому мы подойдем позже, а пока просто разберем типы этих сегментов БД. Существует так же "кластерный индекс", он используется при построении такого типа данных как "кластеры таблиц". Существуют так же bitmap индексы, которые формируются по битовой маске столбцов таблиц. Но в основном вам предстоит работать с B*-Tree-Index-ми, которых для начала вполне хватит. Добавлю, что данные обо всех индексах БД, а так же индексируемых столбцах БД можно найти в представлениях DBA_INDEXES, DBA_IND_COLUMNS. К стати введите в SQL*Plus команду DESC DBA_INDEXES, DESC DBA_IND_COLUMNS. Могу вас уверить, получите много полезной информации из столбца Comments описания! :) К стати очень полезная команда!

Следующий сегмент БД называется СЕГМЕНТ ОТКАТА. У него даже название подходящее, само собой напрашивается. Что это такое? Сегмент отката, это если выразиться правильным языком, "элементы информационной структуры БД", которые сохраняют информацию о том, что было в блоках данных до того как их начали изменять. Или говоря другими словами, стартовала транзакция. Это значит, что данные в БД начали изменяться. Как только этот процесс начинается, все, что было ранее, скажем в таблице, записывается, в сегмент отката (rollback segments). Далее транзакция начинает свое черное дело, и вдруг ей понадобились данные, которые сейчас находятся в сегменте отката, они оттуда легко извлекаются! Такая операция носит название "плотное чтение" (consistent read). После того, как вы подтвердили транзакцию, введя оператор COMMIT, все данные в сегменте отката помечаются как не действительные, и как говорится, "Шура, пилите гирю! - Она золотая. ". Если нужно все вернуть на круги своя, оборвав действия текущей транзакции, введите оператор ROLLBACK. Все останется как было! Кстати, при работе сегмент отката присоединяет как минимум два расширения, и как следствие нужно сделать так, чтобы ему хватило текущих расширений для работы. Иначе, он потребует еще и вся операция может затянуться или привести к аварийному откату транзакции, если места в текущем табличном пространстве не хватит для работы сегмента отката! Понятно, что я здесь излагаю. Это нужно хорошо представлять, иначе можно лишить себя любимого важных данных! А правильная настройка сегментов отката и табличных пространств поможет вам избежать неприятных моментов!

  1. X$- таблиц, внутренние таблицы БД.
  2. $- Таблицы словаря данных
  3. V$- таблиц представления текущей активности.
  4. Представления словаря.
  1. ALL_
  2. DBA_
  3. USER_

В них соответственно можно найти информацию. В ALL_ обо всех объектах БД и пользователей, DBA_ принадлежит администратору и используется им. USER_ все объекты конкретной схемы пользователя. Вот кратенько о сегментах "словари данных". Но, я так же советую дать такой запрос, войдя в БД пользователем SYSTEM:

Например, я получил 817(!) сток! Здесь, можно найти краткое описание каждого словаря данных! Вот вам кусочек, запроса для примера:

Достаточно хорошо видно, что можно найти как имя нужного словаря, так и то, что он содержит, если еще подкрепить это все командой DESC, то я думаю, что скоро родится еще 10, а может 20 администраторов БД! :) Естественно, желательно немного знать English. И дело я думаю, пойдет!

Когда вы меняете данные в БД, то ваши изменения сначала идут в кэш, а потом асинхронно в нескольких потоках (число можно сконфигурировать) пишутся на диск. Синхронно же пишется специальных лог (оперативный журнальный файл), чтобы была возможность восстановить данные после сбоя, если они еще не успели с кэша сброситься на диск. Данный подход позволяет выиграть в скорости, так как в этом случае на диск все пишется последовательно в один файл, причем можно настроить так, чтобы писалось параллельно на два или больше дисков, тем самым увеличивая надежность защиты от потери изменений. Описанных файлов должно быть несколько, и они используются по кругу: как только все данные защищенные одним из лог файлов были записаны фоновым процессом в блоки данных на диск, то данный лог файл может быть переиспользован. Таким образом в какой-то мере это позволяет еще и сэкономить, имея ультрабыстрые диски небольшого размера только для небольших журнальных файлов используемых по кругу.

Обычно я рассказываю об этом, когда мне предлагают что-то сохранять просто в файл на диске, так как это будет «быстрее» за счет того, что мы будет писать все данные последовательно и головке жесткого диска не надо будет бегать и искать рэндомные блоки. Я все же настаиваю, что мы тут ничего не выиграем, так как будем писать на медленный диск, который скоро всего активно используется множеством других процессов для записи огромного количества различных логов, а Oracle синхронно тоже пишет у себя на диск только последовательно, как я описал выше.

Механизм восстановления данных

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

Stand by копия

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

Подвисание некоторых запросов на запись

При зависании некоторых ваших запросов в произвольный момент времени стоит заглянуть в alert.log на предмет наличия incomplete checkpoint. Это говорит о том, что ваши оперативные журнальные файлы слишком большие или их слишком мало, таким образом, защищаемые ими данные не успевают сбрасываться из кэша на диск, а СУБД заполнила уже все доступные оперативные журнальные файлы и хочет использовать их по кругу повторно, чего делать ни в коем случае нельзя, вот и появляется пауза. Хотя если ваше приложение работает на java, то в первую очередь я бы загляну на наличия Full GC в логах.

Неблокирующее чтение и сегмент отката

Одной из наиболее замечательных особенностей СУБД Oracle является неблокирующее чтение, которое достигается за счет сегмента отката. Запросы к Oracle на чтение никогда не блокируются, так как данные почти всегда могут быть прочитаны из сегмента отката.

Сегмент отката дает еще одну плюшку: из него можно попытаться считать немного устаревшие данные для какой-нибудь таблицы, которые были в ней на определенный момент. Называется данная фича — flashback.

Однако иногда сегмент отката может подложить свинью: если у вас есть большой job для bulk удаления данных (удаление генерирует всех больше данных в сегменте отката), то вы можете получить ORA-01555: snapshot too old. Главное что в этом случае надо помнить — это то, что не надо переписывать ваш job, чтобы он коммитил через каждые N операций, а нужно использовать отдельный специально созданный сегмент отката для таких операций.

Уровни изоляции транзакций

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

Вообще, в Oracle явно доступно всего два уровня изоляции: по умолчанию используется READ_COMMITTED, но при желании вы можете установить SERIALIZABLE.

Однако на уровне операторов (SELECT, UPDATE и т.д.) у вас по умолчанию уже есть REPEATABLE_READ, т.е. в рамках одного оператора вы всегда получаете согласованное чтение, что достигается конечно же за счет сегмента отката. Мне всегда очень нравился пример приводимый Томом Кайтом для описания того, что это дает. Допустим у вас есть очень большая таблица со счетами и вы выполняете SELECT на получение суммы. В Oracle, в отличие от многих других БД, даже если в середине вашего запроса другая транзакция переведет некоторую суммы с первого счета на последний, вы в итоге все равно получите данные актуальные на начало вашего запроса, так как дойдя до последний строчки ваш SELECT увидит, что строчка была изменена, пойдет в сегмент отката и прочитает данные, которые были в этой ячейке на момент начала выполнения запроса. Во многих других базах данных, вы получите ответ в виде суммы, никогда не существующей в вашей таблице. Однако в Oracle в данном случае есть опасность получить ORA-01555: snapshot too old.

В дополнение к стандартным уровням изоляции в Oracle еще есть так называемые READ_ONLY транзакции, которые дают REPEATABLE_READ в рамках всей транзакции, а не только в рамках одного оператора. Но как следует из названия, в такой транзакции вы можете выполнять только чтение.

Позвольте Oracle кэшировать ваши данные эффективно

В Oracle все данные читаются-пишутся не прямо на диск, а через кэш. По умолчанию кэш основан на LRU алгоритме, так что если вы читаете какую-нибудь очень большую табличку по идентификатору в больших количествах, запрашивая в каждый раз новую строчку, то такие запросы могут вытеснять из кэша небольшую статическую табличку, которой бы самое милое дело постоянно находиться в кэше. Для таких целей при создании таблицы вы можете указать специальный вид кэша, куда будут ходить запросы к вашим таблицам. Так для первой таблицы в вышеописанном примере подойдет кэш RECYCLE, который по сути не хранит никакие данные, а сразу их выбрасывает из кэша. А для второй таблицы подойдет кэш KEEP, который позволить хранить в кэше небольшие статические таблице и запросы ко всем остальным таблицам не будут вытеснять данные статических таблиц из кэша.

Пустые строки

В оракл есть одна очень интересная особенность, от которой они теперь уже никогда не смогут избавиться. Дело в том, что если вы кладете в БД пустую строку, то она сохраниться как NULL. Таким образом при последующем чтении вы никогда не получите пустой строки, а только NULL. Имейте так же в виду, что по этой же причине пустые строки не попадают в индекс, так что если вы будете делать запросы, план выполнения которых, будет использовать индекс, то ваше пустые (вернее NULL) строки вы никогда не получите, но об этом чуть позже.

Индексы

Кроме всем известных индексов в виде B-деревьев в Oracle еще есть так называемые битовые индексы, которые показывают очень высокую производительность на запросах к таблицам в которых есть колонки с очень разреженными значениями. Особенно эффективно в этом случае будут работать запросы (по сравнению с обычными индексами) в которых присутствуют сложные комбинации OR и AND к разряженным столбцам. Данный индекс храниться не в B-дереве, а в битовых картах, что и дает возможность быстрого выполнения описанных запросов. Вопрос в количестве уникальных значений в таблице при которых данный индекс еще будет более предпочтителен весьма сложен: это может быть как 10 уникальных значений, так и 10 000. Здесь надо создавать индекс на конкретной таблице и смотреть что получается. Главное не пытайтесь использовать данный индекс на таблицах с большим количеством вставок и обновлений индексируемой колонки, так как такие операции будут блокировать довольно большие участки в индексируемой таблице и ваша система может встать колом или даже поймаете deadlock.

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

Еще одно интересное свойство индексов, о котором необходимо знать, это то, что в индексе не хранятся значения NULL. Таким образом если вы будете делать запросы с условием <, > или <> по индексируемой колонке, то в ответ строчек со значением NULL в индексируемой колонке вы обратно не получите. С другой стороны данное свойство можно очень эффективно использовать дня некоторых специфичных случаев. Например, у вас есть очень большая табличка в которой хранятся ордера, которая никогда не чистится. И существует фоновый процесс, который обязан все ордера отсылать в какую-нибудь backoffice систему. Первое решение, которое напрашивается — это завести еще одну колонку с флагом is_sent, где изначально стоит 0 и при отсылке мы будем проставлять 1. Т.е. фоновый процесс при каждом запуске будет делать запрос к таблице с условием is_sent=0. Битовый индекс вы здесь использовать не можете, так как табличка очень активно пополняется. Обычный индекс на основе В-дерева будет занимать очень много места, так как нужно хранить ссылки на огромное количество строчек. Но если мы слегка поменяем нашу логику и в качестве пометки отсылки, и в колонку is_sent будем класть NULL вместо 1, то индекс у нас будет крошечный, так как в любой момент в нем будут храниться только не NULL значения, а их будет очень мало.

Таблицы бывают разные

Кроме обычных таблиц в oracle как и во многих других БД есть так называемые индекс-таблицы, когда данные таблицы непосредственно лежат в индекс-дереве первичного ключа. Таким образом достигается сразу две вещи: во первых для чтения данных по первичному ключу вы имеете на одно чтение меньше, во вторых данные в таблице получаются упорядоченными по первичному ключу, так что операция ORDER BY PK будет выполняться без дополнительной сортировки. К недостаткам можно отнести тот факт, что отличить логирование в оперативные журнальные файлы данного индекса вы уже не сможете.

Еще один замечательный тип таблиц — это кластерные таблицы, которые позволяют хранить данные из двух или более таблиц кластеризованные по одному значению ключа в одном блоке данных. Это может быть весьма эффективно если вы всегда используете какие-нибудь таблицы совместно.

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

Связывание переменных

Наверное об этом уже наслышан каждый программист, но я все же упомяну о такой обязательной техники, как связывание переменных. Дело в том, что для каждого уникального запроса строится план разбора и кладется в кэш. Если различных запросов очень много, как, например, весьма распространенный запрос по ID, то на каждый запрос буден генериться свой план, к тому же они будут вытеснять из кэша все другие планы, что может в разы увеличить время отклика вашей базы данных.

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

Еще пара заметок для программиста

Если у вас колонка имеет тип VARCHAR2(100), то попытка туда запихнуть строку longString.substring(0, 100) не факт, что увенчается успехом, так как ограничение 100 в определении колонки по умолчанию относится к количеству байтов, а не символов, поэтому при наличии двухбайтовых символов вы можете попасть впросак. На самом деле данное поведение можно немного сконфигурировать, подробнее можно почитать тут. Хорошо если вы еще не пытаетесь выполнить вставку в бесконечном цикле, по принципу делать пока не получиться, ведь это «получиться» в данном случае никогда не наступит.

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

Табличное пространство UNDO используется для хранения данных UNDO. При выполнении операций DML (INSERT, UPDATE и DELETE) Oracle записывает старые данные этих операций в сегмент UNDO.

До того, как oracle9i (сегмент отката) использовался для управления данными UNDO, начиная с oracle9i, для управления данными отката можно использовать не только сегмент отката, но и табличное пространство UNDO.

При 10g кажется, что сегмент отката больше не используется для управления данными UNDO, а табличное пространство UNDO используется равномерно.

1, откат транзакции

Когда для изменения данных выполняется операция DML, данные UNDO сохраняются в сегменте UNDO, а новые данные сохраняются в сегменте данных. Если возникает проблема с операцией транзакции, необходимо откатить старую транзакцию, чтобы отменить изменение транзакции.


Пользователь А выполнил заявление UPDATE emp SET sal=9999 WHERE empno=7788 Позже выяснилось, что зарплата сотрудника 7963 должна быть изменена, а не зарплата сотрудника 7788, тогда изменение транзакции можно отменить, выполнив инструкцию ROLLBACK.

Когда команда ROLLBACK выполнена, Oracle запишет обратно данные 800 UNDO сегмента UNDO в сегмент данных.

2, прочитайте последовательность

Когда пользователь извлекает данные из базы данных, Oracle всегда позволяет пользователю видеть только данные, которые были отправлены (чтение, отправка) или данные в определенный момент времени (момент времени оператора SELECT), что может обеспечить согласованность данных.

Когда пользователь A выполняет оператор UPDATE emp SET sal=1000 WHERE empno=7788 В это время запись UNDO будет сохранена в сегменте отката, а новые данные будут сохранены в сегменте EMP, предполагается, что данные не были представлены в это время, и пользователь B выполняет SELECT sal FROM emp WHERE empno=7788 В это время пользователь B получит данные UNDO 800, и эти данные будут получены в записи UNDO.

Сеанс B (здесь мы моделируем, открывая новое окно SQL), если вы продолжаете использовать сеанс A, запрос по-прежнему 1000.

3. Восстановление транзакции

Восстановление транзакций является частью обычного восстановления, оно автоматически завершается сервером Oracle.

Если во время работы базы данных происходит сбой процедуры (например, сбой питания, сбой памяти, сбой фонового процесса и т. Д.), То при перезапуске сервера оракула фоновый процесс SMON автоматически выполняет обычное восстановление, а после выполнения обычного восстановления oracl перезапускается. Сделайте все непримененные записи. Откатите незафиксированные транзакции.

4, Flashback запрос (FlashBack Query)

Flashback-запрос используется для получения данных базы данных в определенный момент времени, он 9i Недавно добавленная функция, при условии, что текущее время - 09:00, а пользователь выполняет его в 10:00. UPDATE emp SET sal= 1000 WHERE empno=7369 Сформулируйте, измените и отправьте транзакцию (начальная зарплата сотрудника составляет 800), чтобы получить зарплату сотрудника до 10:00, пользователи могут использовать функцию запроса обратной связи.

Усовершенствование функции Oracle10g Flashback Query

Запрос Flashback Oracle 9i может предоставить представление данных только в определенный момент времени и не может сказать пользователю, что такие данные прошли через несколько транзакций и как их изменить (UPDATE, INSERT, DELETE и т. Д.), И эта информация находится в сегменте отката Да, в Oracle10g Oracle дополнительно усиливает характеристики запроса на возврат, предоставляя следующие два типа запроса на возврат:

  • Flashback Versions Query
  • Flashback Transaction Query

Запрос версии Flashback позволяет новому предложению VERSIONS запрашивать версию данных между двумя точками времени или SCN. Эти версии можно различить по транзакции. Запрос версии Flashback возвращает только отправленные данные, а незафиксированные данные не отображаются.

Запрос версии флэшбэка Oracle10g может получить все операции транзакции над таблицей данных, используя предложение VERSIONS и вводя в таблицу данных серию псевдостолбцов (version_starttime и т. Д.). ), VERSIONS_XID является важной основой, представляющей идентификатор транзакции разных версий.

Посредством вышеуказанного запроса, согласно version_xid, вы можете четко различать изменения, внесенные в данные различными транзакциями в разное время.

Так как этот запрос должен получить предварительную информацию от Undo, если информация в Undo будет перезаписана, приведенный выше запрос завершится ошибкой.

Восстановление данных Каштан

Пользователь обновил или случайно удалил пакет данных (при условии большого объема данных),

Вот фрагмент данных для демонстрации: первоначальная зарплата 7369 с номером работы составляет 800, а обновленная зарплата - 1000

В это время пользователь хочет восстановить, предполагая, что момент удаления - после 2016-11-13 09:00:00, затем мы находим SCN (номер изменения системы) до 9 часов.

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

1. Получить текущий SCN

2. Извлечь данные о точке scn в таблицу emp.


Можно видеть, что данные до этого момента времени 7369 равны 800.

3. Затем вы можете выполнить операцию восстановления на основе этих данных.

С точки зрения приложения ORA-01555

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

3. Consistent = y используется при выражении exp. Этот параметр предназначен главным образом для обеспечения того, чтобы все таблицы везде были согласованы в определенный момент времени во время exp, чтобы избежать таблиц с отношениями первичного и внешнего ключей из-за разных моментов времени Несоответствие разрушает целостность данных. Эту операцию рекомендуется выполнять, когда система находится в режиме ожидания.

4. Если сегмент отката не был переработан из-за отвода сегмента отката, данные в сегменте отката не могут быть найдены. Вы можете только увеличить сегмент отката, чтобы увеличить оптимальные настройки.

Отмена Oracle имеет два способа: один - использовать отмену табличного пространства, а другой - использовать сегмент отката.

Мы проходим undo_management Параметры для управления, какой метод использовать,

Если установлено значение auto, используется табличное пространство UNDO, и в это время необходимо указать табличное пространство UNDO.

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

Отменить значение параметра конфигурации

  • UNDO_MANAGEMENT режим управления отмены, разделенный на автоматический и ручной
  • UNDO_TABLESPACE Таблица отмены, используемая в настоящее время

UNDO_RETENTION указывает, как долго данные не могут быть перезаписаны.

АВТО означает, что отмена находится в автоматическом режиме управления.

900 означает, что данные об отмене не могут быть перезаписаны в течение 900 секунд.

UNDOTBS1 - табличное пространство отмены, используемое в настоящее время

Если система не указывает undo_management, то система запускается по умолчанию в ручном режиме, даже если параметры автоматического режима установлены, эти параметры будут игнорироваться.

Использовать сегмент отката

Когда undo_management установлен в MENUAL При использовании сегмента отката системы записи об отмене записываются в сегмент SYSTEM в табличном пространстве SYSTEM.


С помощью приведенного выше утверждения мы обнаружили, что системный сегмент, используемый для отката, существует
С системным табличным пространством. По умолчанию существует только один сегмент, и он все еще относительно мал, поэтому если вы используете системный сегмент для хранения отмененных записей, это определенно повлияет на производительность базы данных. и так Oracle рекомендует использовать табличное пространство Undo для управления записями отмены.

Использовать отмену табличного пространства

Когда undo_management установлен в AUTO При использовании табличного пространства UNDO для управления сегментом отката в это время у нас будет несколько сегментов отмены, и эти сегменты будут храниться в табличном пространстве UNDO, так что производительность БД будет улучшена.


В настоящее время наша база данных имеет 58 отмененных сегментов. По умолчанию кажется 10.

В дополнение к результатам, просматриваемым через таблицу dba_segment, вы также можете использовать v r o l l s t a t с v роллстат и в Сверните два представления для просмотра информации, эти два представления будут отображать всю информацию о сегменте отката, включая сегмент системы и сегмент отмены.


Используйте следующий SQL для просмотра соотношения между простоями и без простоя в табличном пространстве отмены:


UNEXPIRED и EXPIRED - отмененные табличные пространства, которые использовались,

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

Вот параметр: UNDO_RETENTION Этот параметр используется для указания максимальной продолжительности хранения записей отмены в секундах. Это динамический параметр, который можно изменить в любое время при работе экземпляра. Обычно значение по умолчанию составляет 900 секунд, что составляет 15 минут.

undo_retention указывает только срок действия данных отмены, но это не означает, что данные отмены будут сохраняться в табличном пространстве отмены в течение 15 минут. Например, когда начинается новая транзакция, если табличное пространство отмены уже заполнено, Данные новой транзакции будут автоматически перезаписывать данные отправленной транзакции, независимо от того, истек ли срок действия данных ，

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

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

Если табличное пространство для отмены достаточно велико, а база данных не так занята, то значение параметра undo_retention не повлияет на вас, даже если вы установите его равным 1, пока нет транзакции для перезаписи данных отмены, оно будет продолжать действовать. Короче говоря, обратите внимание на размер табличного пространства отмены, чтобы убедиться, что в нем достаточно места для хранения.

Только в одном случае табличное пространство отмены может гарантировать, что данные в отмене должны быть действительными до истечения времени, указанного в undo_retention, то есть для табличного пространства отмены. Retention Guarantee После указания oracle не будет перезаписывать данные отмены в табличном пространстве отмены, срок действия которого не истек.

Запрет на отмену гарантии сохранения табличного пространства

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

В течение времени, указанного в undo_retention, все данные действительны и после истечения срока их действия будут установлены на недействительные. Статус изменится на Истек, и эти сегменты отката будут рассматриваться как свободное пространство. Но пока данные не перезаписаны, их можно использовать.

Если пространство заполнено, данные новой транзакции будут автоматически перезаписывать данные транзакции, которые были зафиксированы, даже во время отмены удержания. Если не указано удержание
Гарантийный режим, чтобы гарантировать, что он не покрыт undo_retention.

Что касается введения принципа автоматической настройки Oracle UNDO, автоматическое управление табличным пространством, функция автоматической настройки наименьшего срока хранения информации UNDO была добавлена ​​в более поздней версии Oracle 10gr2, больше не только на основе установки параметра UNDO_RETENTION, принцип настройки заключается в следующем :

1 Когда UNDO TABLESPACE имеет фиксированный размер, Oracle автоматически отрегулирует время хранения информации об отмене в соответствии с размером табличного пространства и историческим использованием, а также проигнорирует значение undo_retention, если не включена функция гарантии undo_retention.

2 Когда UNDO TABLESPACE равен AUM, Oracle динамически корректирует минимальное время хранения информации об отзыве на максимальное время запроса (MAXQUERYLEN) этого периода плюс 300 секунд или больше параметра UNDO_RETENTION, т.е. MAX ((MAXQUERYLEN + 300), UNDO_RENTION );

При включенной автоматической настройке фактическое минимальное время хранения информации об отзыве можно узнать, запросив V U N D O S T A T В виде инжир на из T U N E D U N D O R E T E N T I O N колонка Выиграть Получить 。 в в наиболее короткая Protect Сохранить Время между далеко далеко большой в Предполагать набор из U N D O R E T E N T I O N 。 в нет закон на U N D O T A B L E S P A C E делать фаза должен ремонт изменение из ситуация состояние ， Можно к через прошлое ремонт изменение скрытый формула Женьшень число ” U N D O A U T O T U N E ” за F A L S E выключи близко от шаг мелодия отлично специальный секс 。 к на Предполагать набор Здоровье эффект задний ， V Столбец TUNEDUNDORETENTION в представлении UNDOSTAT получен. Самое короткое время хранения часто намного дольше, чем установленное UNDORETENTION. Когда UNDOTABLESPACE нельзя изменить соответствующим образом, функцию автоматической настройки можно отключить для FALSE, изменив неявный параметр «UNDOAUTOTUNE». После того как вышеуказанные настройки вступят в силу, V Столбец TUNED_UNDORETENTION в представлении UNDOSTAT больше не обновляется, а минимальное время хранения информации об отмене фиксируется в значении параметра UNDO_RETENTION. Этот параметр может быть установлен динамически без перезапуска базы данных.

По умолчанию Undo_retention составляет всего 15 минут. Это значение по умолчанию, как правило, не является удовлетворительным.
Системные Требования. Общая рекомендация - изменить его на 3 часа, чтобы в случае возникновения ситуации было больше времени.

конечно, Чем больше параметр undo_retention, тем больше требуется табличное пространство для отмены , Это необходимо объединить с вашей собственной системой для установки этого параметра.

Имитация ОТМЕНА табличного пространства заполнена

Решение

Есть два метода обработки,

  • Одним из них является добавление файла данных табличного пространства отмены,
  • Вторым является переключение табличного пространства UNDO, в этом случае оно чаще всего используется, когда табличное пространство отмены уже очень велико.

Добавить файлы данных

Переключить UNDO табличное пространство

1. Создайте новое табличное пространство UNDOTBS2

2. Переключитесь на вновь созданное табличное пространство UNOD, операция выглядит следующим образом

3. Переведите исходное табличное пространство UNDO в автономный режим:

4. Удалите исходное табличное пространство UNDO:

Если это просто отбросить табличное пространство UNDO, будут удалены только записи в контрольном файле, и файл не будет удален физически.

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

Большинство случаев, когда отмена повреждена, вызваны ненормальным временем простоя. Когда об ошибке сообщают во время запуска, DB не может быть запущен.
Например: ORA-00600: внутренний код ошибки, аргументы: [4194]

Когда в журнале оповещений появляется ORA-600 + [4194], можно сделать вывод, что табличное пространство отмены повреждено. В случае отмены повреждения лучше всего использовать резервную копию для восстановления, в противном случае ее можно восстановить только некоторыми специальными методами.

Способ 1: использовать системный сегмент

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

(1) Создайте pfile с помощью spfile, а затем измените параметры:

Как создать PFILE через SPFILE?

pfile file-Linux и другие платформы в каталоге $ ORACLE_HOME / dbs,
Oralce читает при запуске экземпляра $ORACLE_HOME/dbs Следующий файл инициализации.

(2) Используйте модифицированный pfile для перезапуска БД

(3) Удалить исходное табличное пространство и создать новое табличное пространство UNDO

(4) Закройте базу данных, измените параметры pfile, а затем создайте spfile с новым pfile и запустите базу данных в обычном режиме.

Если используется значение по умолчанию, оно может быть сокращено как:

Способ 2: пропустить поврежденный сегмент

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

(1) Измените pfile и добавьте параметры:

Значения этих полей можно просмотреть через журнал предупреждений. Вы также можете просмотреть его с помощью следующей команды:

(2) Запустите БД с измененным pfile
Поскольку поврежденные сегменты были пропущены, БД может нормально запускаться.
(3) Создайте новое табличное пространство UNDO и переключитесь

Когда начинается транзакция, Oracle назначает ей один (и только один) сегмент отката. Любоая транзакция может охраняться одним и только одним сегментом отката – невозможно распределять данные отката сгенерированные одной транзакцией между несколькими сегментами отката. Это не проблема, так как сегменты отката не имеют фиксированного размера. То есть если транзакции необходимо больше места, Oracle автоматически добавит экстент для сегмента и транзакция продолжится. Несколько транзакций могут использовать один сегмент отката, но в обычной ситуации такого не должно происходить. Для rollback сегментов обычной проблемой настройки производительности была оценка сколько сегментов необходимо чтобы исключить пересечение данных транзакций внутри сегмента и не создавать слишком много чтобы не использовать место впустую. Одним из преимуществ undo является то что Oracle будет автоматически создавать новые сегменты по запросу чтобы транзакции не использовали по возможности одинаковые сегменты undo. Если Oracle обнаруживает что необходимо увеличить существующий undo сегмент или создать новый из-за высокой нагрузки, он сделает это автоматически, однако после того как эти сегменты не нужны (или им не нужно так много места) Oracle удалит ненужные сегменты и укоротит существующие.

Транзакции не могут использовать несколько undo сегментов, но один сегмент может поддерживать несколько транзакций

Так как транзакция обновляет блоки данных таблицы или индекса, информация необходимая для отмены этих изменений записывается в блоки назначенного сегмента undo. Все это происходит в буфере кэша базы данных. Oracle гарантирует атомарность: вся информация undo хранится до завершения транзакции. Если необходимо то DBWn запишет изменённые блоки undo в сегменты undo в файлах данных. По умолчанию Oracle не гарантирует согласованность теста ACID. Oracle гарантирует согласованность с таким уточнением, что если запрос выполнится успешно – результат будет содержать данные какими они были на момент начала запроса – но не гарантируется что запрос будет выполнен успешно. Это значит что undo данные можно разделить на катеогрии. Рабочие (active) данные отката – это данные которые могут потребоваться для отмены активных транзакций. Эти данные никогда не будут перезаписаны, пока транзакция не будет завершена. С другой стороны устаревшие (expired) данные это данные завершённых транзакций, которые Oracle не обязан больше хранить. Эти данные могут быть перезаписына если Oracle требуется место для записи данных другой активной транзакции. Неустаревшие (unexpired) данные – это не активные данные, но и не устаревшие: транзакция завершены, но данные undo могут требоваться для согласованного чтения, если выполняются какие-то длительные запросы. Oracle старается не перезаписывать неустаревшие данные по возможности.

Активные данные undo никогда не могут быть перезаписаны: устаревшие данные могут быть перезаписаны. Неустаревшие данные могут быть перезаписаны, но только при условии недостаточности места

Тот факт что undo данные становиятся неактивными после подтверждения транзакции означает что сегменты undo используются по-кругу. В итоге все табличное пространтсво заполнено данным undo, и когда начинается новая транзакция или активная транзакция создаёт новые данные undo, сегмент undo проверяет есть ли старые ненужные данные и они перезаписываются новыми – конечно если страные данные это не часть какой-то длинной незавершённой транзакции, в этом случае сегмент будет автоматически увеличен.

В случае использования старых rollback сегментов, которыми необходимо управлять вручную, приходилось контролировать какие транзакции используют какие сегменты. Иногда даже приходилось создавать отдельные сегменты именно для одной длинной транзакции. Автоматически управляемые сегменты undo избавляют вас от необходимости следить за всем этим, так как вы больше не должны контролировать процесс использования сегментов отката транзакциями. Oracle автоматически проконтролирует ситуацию лучше чем человек когда-либо сможет, однако если вы всё же хотите высянить какой сегмент назначен какой транзакции вы можете использовать представления V$TRANSACTION, V$SESSION и DBA_ROLLBACK_SEGS. На основании данных из этих представлений вы можете построить картину активности транзакция в вашей БД: сколько транзакций активно, кто их запустил, какие сегменты undo используются, когда транзакция начала работу и сколько блоков данных undo сгенерировано каждой транзакцией. В представление V$ROLLSTAT так же есть информация о размерах сегментов.

Читайте также: