Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование I

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 24.09.2009, 15:14
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию 09 Управление информацией отмены

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 24.09.2009, 15:15
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Рассматриваемые вопросы

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #3  
Старый 24.09.2009, 15:16
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Манипулирование данными



Манипулирование данными

Класс команд DML языка SQL включает команды INSERT, UPDATE, DELETE и MERGE, с помощью которых производится обработка или манипулирование данными. Эти команды выполняются как часть транзакции, начинающейся первой успешно отработавшей командой DML и заканчивающейся либо командой COMMIT, либо ROLLBACK. Транзакция или полностью фиксируется, или полностью откатывается.

Откат может также произойти в случае сбоя процесса или системы. Примечание. Команда MERGE производит операции вставки и изменения для объединения данных одной таблицы, переносимых в другую таблицу. Эта команда рассматривалась в уроке "Сопровождение данных и одновременный доступ".
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #4  
Старый 24.09.2009, 15:18
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Информация отмены



Информация отмены

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

Выполнение запросов может начинаться до изменения данных и заканчиваться после их изменения. Целостность чтения (read-consistent), гарантируемая Oracle, означает, что запросы возвращают данные, согласованные с моментом начала запросов. Для успешного выполнения целостных по чтению запросов необходимо, чтобы первоначальные данные в виде информации отмены были еще доступны. Пока информация отмены удерживается, Oracle может реконструировать данные, необходимые целостным по чтению запросам (read-consistent queries).

Запросы прошлых данных (flashback queries) используют копию данных, соответствующую некоторому моменту в прошлом. Такие запросу могут быть успешно завершены, пока информация отмены прошлых данных все еще существует.

Информация отмены (undo data) также используется для восстановления после аварийно завершившейся транзакции. Это происходит, когда сеанс пользователя завершается ненормально (возможно из-за сетевой ошибки или ошибки на клиентской машине) до того, как пользователь решит зафиксировать (commit) или откатить (roll back ) транзакцию. Аварийно завершившиеся транзакции могут появиться и по причине отказа экземпляра. Во всех таких случаях Oracle выбирает наиболее безопасный путь: отменяет все сделанные пользователем изменения, восстанавливая первоначальные данные.

Информация отмены удерживается для всех транзакций, по крайней мере, пока транзакция не завершится после того, как:

пользователь поменяет свое решение и выполнит откат (rollback);
пользователь завершит транзакцию и зафиксирует изменения данных
(commit);
сеанс пользователя завершится ненормально и выполнится откат (rollback);
пользователь нормально выйдет и его сеанс завершится (commit).

Информация отмены может удерживаться и дольше. Это зависит от интенсивности выполняемых операций и конфигурации базы данных.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #5  
Старый 24.09.2009, 15:19
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Транзакции и данные отмены



Транзакции и данные отмены

Когда транзакция начинается, ей назначается сегмент отмены (undo segment). Во время жизни транзакции перед любыми выполняемыми ею изменениями первоначальные значения данных копируются в сегмент отмены. Каким транзакциям какие сегменты отмены назначены, можно выяснить, запросив информацию из динамического представления производительности v$transaction.

Сегменты отмены автоматически создаются экземпляром по мере необходимости для поддержки транзакций. Это специальные сегменты, но подобно другим видам сегментов они состоят из экстентов, содержащих блоки данных. Сегменты отмены автоматически растут и сжимаются (shrink), когда это необходимо. Они предоставляют буферное пространство, заполняемое 'по кругу' соответствующими транзакциями.

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

Примечание: Параллельные операции DML могут сопровождаться ситуацией, когда одна транзакция использует несколько сегментов отмены. Дополнительные сведения о параллельном выполнении команд DML см. в документе Oracle Database Administrator's Guide 10g.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #6  
Старый 24.09.2009, 15:20
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Хранение информации отмены



Хранение информации отмены

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

У сегментов отмены тип "TYPE2 UNDO" и они всегда принадлежат пользователю SYS. Поскольку сегменты отмены выступают в качестве циклических буферов, каждый сегмент отмены должен иметь, по крайней мере, два экстента. Хотя по умолчанию максимальное число экстентов зависит от размера блока базы данных, оно очень высокое (32765 для блока размером 8 К).

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

Вопросы восстановления табличных пространств отмены будут рассмотрены в главе "Восстановление базы данных".
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #7  
Старый 24.09.2009, 15:22
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Сравнение информации отмены и данных повторного выполнения



Сравнение информации отмены и данных повторного выполнения

Информация отмены (undo data) и данные повторного выполнения (redo data) кажутся на первый взгляд похожими, но цели, которым они служат разные. Информация отмены требуется в ситуации, когда необходимо отменить изменение при откате или для обеспечения целостности чтения (создается старый образ блока с выбираемыми данными). Журнальные данные (redo data) требуются, когда необходимо снова повторить изменения после потери данных, произошедшей по какой-либо причине.

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


Отключение подачи электроэнергии, если оно происходит как раз перед занесением измененных данных в файлы данных, не вызывает проблемы, так как транзакция была зафиксирована. Когда система снова запускается, она может накатить вперед по журнальным записям операции, результаты которых не были еще отражены в файлах данных в момент отключения подачи электроэнергии.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #8  
Старый 24.09.2009, 15:23
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Мониторинг отмен



Мониторинг отмен

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

недостаточно свободного пространства для данных отмены;
пользователи получают сообщения об ошибке ORA-01555 snapshot too old.

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

Представьте ситуацию, когда удаляются все строки из таблицы, размером 50 GB:

Код:
SQL> DELETE FROM имя_действительно_большой_таблицы;
В табличном пространстве типа undo потребуется место для 50 GB первоначальной информации, поскольку пользователь может захотеть откатить изменения. Когда в табличном пространстве нет места для данных отмены, пользователь получает сообщение об ошибке :

ORA-01650: unable to extend rollback segment

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

Перед администратором может возникнуть и другая проблема, когда запросу потребуются данные, переписанные новой информацией отмены. Это может произойти, если запрос долго выполняется или в нем выбираются старые данные (flashback query). Когда запросу потребуется "моментальный снимок" ("snapshot") на какой-то момент в прошлом и информация отмены для его восстановления больше не существует, будет выдана следующая ошибка:

ORA-01555: snapshot too old

Такое может произойти, потому что база данных Oracle предоставляет пользователю целостный образ данных на момент начала выполнения запроса. Если же при выполнении запроса в таблице обнаруживаются незафиксированные данные, Oracle производит чтение информации отмены, чтобы предоставить зафиксированные данные. Это целостное чтение (read consistency). Когда запрос выполняется так долго, что успевает произойти фиксация изменений, после которой уже не блокируемая системой информация переписывается новыми данными, тогда нельзя предоставить целостный образ данных на момент начала выполнения этого долго выполняющегося запроса. Поэтому следует конфигурировать время удержания таким образом, чтобы оно соответствовало запросу с наибольшим временем выполнения.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #9  
Старый 24.09.2009, 15:25
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Сопровождение информации отмены



Сопровождение информации отмены

В базе данных Oracle 10g рекомендуется использовать автоматическое управление информацией отмены (automatic undo management), конфигурируемое путем задания значения AUTO для параметра инициализации UNDO_MANAGEMENT. Ручной метод управления (manual undo management) поддерживается для обратной совместимости с версией Oracle 8i и более ранними версиями. Однако он требует большего вмешательства АБД.

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

При ручном методе управления АБД должен также:

задавать размеры сегментов отмены, определяя для этого максимальное число экстентов и размер экстента;
выявлять и устранять блокирующие транзакции;
создавать достаточное количество сегментов отката (в ручном режиме сегменты отмены называют сегментами отката) для обработки транзакций;
выбирать табличное пространство для хранения сегментов отката (табличное пространство типа undo используется только при автоматическом методе).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #10  
Старый 24.09.2009, 15:26
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Конфигурирование удержания информации отмены



Конфигурирование удержания информации отмены

Параметр UNDO_RETENTION задает (в секундах) нижнее пороговое значение времени удержания информации отмены.

Для табличных пространств с возможностью автоматического расширения (AUTOEXTEND) система удерживает данные отмены, по крайней мере, в течение времени, определяемого параметром UNDO_RETENTION, и автоматически настраивает период удержания так, чтобы он соответствовал наиболее длительно выполняемым запросам.

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

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


Информация отмены делится на три категории:

Незафиксированная информация отмены (uncommitted undo information).
Необходима текущим транзакциям для выполнения отката по команде пользователя или при сбое транзакции. Незафиксированная информация отмены никогда не может быть переписана.

Зафиксированная информация отмены (committed undo information). Не нужна для поддержки текущих транзакций, но все еще нужна для обеспечения удержания информации отмены в заданном интервале времени. Также называется "неустаревшей " ("unexpired'') информацией отмены. Зафиксированная информация отмены удерживается, если это не вызывает ошибки активной транзакции, связанной с нехваткой пространства.

Устаревшая информация отмены (expired undo information). Не нужна для поддержки текущих транзакций. Переписывается, когда активной транзакции требуется пространство.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 06:55. Часовой пояс GMT +3.


Powered by vBulletin®