Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Механика Restore/Recovery  [new]
Александр Соколов
Member

Откуда: Протвино
Сообщений: 1419
bar
Типы восстановления в СУБД Oracle
В этом разделе рассматриваются следующие темы:
■ Восстановление экземпляра и восстановление после сбоя
■ Восстановление носителя
Восстановление экземпляра и восстановление после сбоя
Восстановление после сбоя (crash recovery) применяется для восстановления
базы данных, управляемой одним экземпляром, а также для восстановления
базы данных после сбоя всех экземпляров в среде Oracle Real Application
Clusters. Восстановлением экземпляра (instance recovery) называют случай,
когда в среде Oracle Real Application Clusters сохранившиеся экземпляры
восстанавливают экземпляр, в котором произошел сбой.
Цель восстановления после сбоя и восстановления экземпляра – восстановить
изменения в блоках данных, хранившихся в кеше недействующего экземп-
ляра, и закрыть журнальный поток, который был оставлен открытым.
Восстановление после сбоя и восстановление экземпляра применяют только
оперативные журнальные файлы и только к файлам данных, которые на-
ходятся в оперативном состоянии в момент восстановления. Oracle восста-
навливает журнальные потоки недействующих экземпляров одновременно.
Восстановление после сбоя и восстановление экземпляра обладают
следующими одинаковыми характеристиками:
■ они повторно выполняют изменения в оперативных файлах данных
(оставшихся в состоянии на момент непосредственно после сбоя или
выполнения команды SHUTDOWN ABORT);
■ они используют только оперативные журнальные файлы (и никогда не
используют архивные журнальные файлы);
■ время, требующееся для восстановления, зависит от количества
недействующих экземпляров, объема журнальной информации,
сгенерированной в каждом журнальном потоке недействующих
экземпляров с момента последней контрольной точки, а также
пользовательских настроек (таких как количество и размер жур-
нальных файлов, частота контрольных точек и выбранный режим
параллельного восстановления).
Восстановление носителя на уровне файла данных
Восстановление носителя на уровне файла данных используется для
восстановления в случае утраты или повреждения текущего файла данных
или управляющего файла. Оно также используется для восстановления
изменений, потерянных при переводе табличного пространства в авто-
номный режим без опции OFFLINE NORMAL. Как восстановление носителя
для файлов данных, так и восстановление экземпляра предназначено для
восстановления целостности базы данных. Однако восстановление носителя
имеет дополнительные особенности. В частности:
■ Использует восстановленные резервные копии поврежденных файлов
данных для применения необходимых изменений.
■ Может использовать не только оперативные, но и архивные журнальные
файлы.
■ Должно быть явном вызвано пользователем.
■ Не обнаруживает сбой носителя (то есть необходимость восстановления
резервной копии) автоматически. Однако после того, как резервная копия
была восстановлена, необходимость проведения восстановления носителя
определяется автоматически.
■ Время восстановления зависит только от пользовательских настроек
(например, частоты создания резервных копий, параметров парал-
лельного восстановления), а не от внутренних механизмов Oracle.
База данных не может быть открыта, если для какого-либо оперативного
файла данных требуется восстановление носителя. Кроме того, файл данных,
который нуждается в восстановлении носителя, не может быть переведен в
оперативный режим до выполнения восстановления носителя.
15 июн 06, 15:31    [2775335]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
DВА
Member

Откуда:
Сообщений: 5439
YAP
Александр Соколов
YAP
собственно вопрос: применяются ли незакоммиченные транзакции? если применяются то как регенерятся андо-сегменты, которые применяются для отката незакоммиченных транзакций?
Или в общем - каким образом получаем датафайл с блоками, в которых нет незакоммиченных данных?
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...


не совсем понятен этот момент.
undo датафайлы соответствуют текущему состоянии базы, датафайл1 после ресторе соотвествует некоторому моменту времени назад, когда делался бекап.
данные повтора применяются к датафайлу1 (тут все ясно), а к чему в датафайлах undo применяются в этом случае данные повтора? Я представлял себе что есть некий образ блока из прошлого, к нему применили данные повтора, получили образ блока в настоящем, а undo у нас не поврежден, там образы блоков относятся к настоящему, к чему же тогда применяется redo?

к тому, что вы восстанавливаете, если один файл - то только к нему, если всю базу - то ко всем.
15 июн 06, 15:40    [2775379]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
DВА
YAP
Александр Соколов
YAP
собственно вопрос: применяются ли незакоммиченные транзакции? если применяются то как регенерятся андо-сегменты, которые применяются для отката незакоммиченных транзакций?
Или в общем - каким образом получаем датафайл с блоками, в которых нет незакоммиченных данных?
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...


не совсем понятен этот момент.
undo датафайлы соответствуют текущему состоянии базы, датафайл1 после ресторе соотвествует некоторому моменту времени назад, когда делался бекап.
данные повтора применяются к датафайлу1 (тут все ясно), а к чему в датафайлах undo применяются в этом случае данные повтора? Я представлял себе что есть некий образ блока из прошлого, к нему применили данные повтора, получили образ блока в настоящем, а undo у нас не поврежден, там образы блоков относятся к настоящему, к чему же тогда применяется redo?

к тому, что вы восстанавливаете, если один файл - то только к нему, если всю базу - то ко всем.


я не понял в этом контексте фразу
Александр Соколов
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...
15 июн 06, 16:03    [2775550]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Александр Соколов
Member

Откуда: Протвино
Сообщений: 1419
YAP
я не понял в этом контексте фразу
Александр Соколов
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...

В этом контексте см. выше: "База данных не может быть открыта, если для какого-либо оперативного файла данных требуется восстановление носителя"
15 июн 06, 16:11    [2775598]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
Александр Соколов
YAP
я не понял в этом контексте фразу
Александр Соколов
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...

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


В описаном мною случае восстановления носителя требует только датафайл1, но не undo.
К чему применяется redo в таком случае, применяются ли закоммиченные и не закоммиченные транзакции, если применяются незакоммиченные, то как отменяются их изменения в датафайле1?
15 июн 06, 16:26    [2775707]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Vadim Lejnin
Member

Откуда:
Сообщений: 7134
В двух словах:
recover - ФИЗИЧЕСКОЕ ВОССТАНОВЛЕНИЕ данных (на уровне блоков). Объектов БД еще нет! База еще не открыта и эта информация просто не доступна.
rollback/commit - ЛОГИЧЕСКАЯ ОБРАБОТКА ДАННЫХ (На уровне обьектов БД) ПОСЛЕ того как отроется база.

Поэтому при восстановлении БД:
1) Часть 1 Завершение обработки физической записи БЛОКОВ в файлы данных (Используя информацию из REDO) и выравнивание файлов для получения согласованного набора файлов, на какой то заданный момент времени. Используя сохраненные REDO (ARCHIVE LOG).

2) Часть 2, ОТкрытие БД и завершение ЛОГИЧСКОЙ Обработки обьектов СУБД.
(Откат незавершенных транзакций, используя информацию ROLLBACK/UNDO)
15 июн 06, 16:28    [2775727]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
DВА
Member

Откуда:
Сообщений: 5439
YAP
Александр Соколов
YAP
я не понял в этом контексте фразу
Александр Соколов
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...

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


В описаном мною случае восстановления носителя требует только датафайл1, но не undo.
К чему применяется redo в таком случае, применяются ли закоммиченные и не закоммиченные транзакции, если применяются незакоммиченные, то как отменяются их изменения в датафайле1?

что значет закомиченные\незакомиченные транзакции?
применяются ВСЕ изменения блоков, восстанавливаемого файла.
любая незакомиченная транзакция в процессе media recovery выглядит как закомиченная - сначала блок изменяется в соответствии с операциями, проведенными транзакцией, потом возвращается его исходное состояние. undo-данные тут не нужны, поскольку все есть в редулогах. Если же к моменту завершения media recovery еще не известно, закомичена или нет транзакция, значит все необходимые данные гарантировано находятся в текущем редулоге и андосегментах. именно поэтому при "классическом" восстановлении отдельный файл базы данных не поддерживает режим неполного восстановления.
15 июн 06, 16:35    [2775804]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
DВА
YAP
Александр Соколов
YAP
я не понял в этом контексте фразу
Александр Соколов
применяются ВСЕ журнальные данные, в том числе и к undo-сегментам...

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


В описаном мною случае восстановления носителя требует только датафайл1, но не undo.
К чему применяется redo в таком случае, применяются ли закоммиченные и не закоммиченные транзакции, если применяются незакоммиченные, то как отменяются их изменения в датафайле1?

что значет закомиченные\незакомиченные транзакции?
применяются ВСЕ изменения блоков, восстанавливаемого файла.
любая незакомиченная транзакция в процессе media recovery выглядит как закомиченная - сначала блок изменяется в соответствии с операциями, проведенными транзакцией, потом возвращается его исходное состояние. undo-данные тут не нужны, поскольку все есть в редулогах. Если же к моменту завершения media recovery еще не известно, закомичена или нет транзакция, значит все необходимые данные гарантировано находятся в текущем редулоге и андосегментах. именно поэтому при "классическом" восстановлении отдельный файл базы данных не поддерживает режим неполного восстановления.


что значет закомиченные\незакомиченные транзакции

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

undo-данные тут не нужны, поскольку все есть в редулогах


вот как бы об этом и речь (видимо подзабылось уже мною) - в каком виде есть эта информация? Можно ли попоробнее
15 июн 06, 16:44    [2775897]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Просто так
Guest
YAP, почитайте про "deffered rollback segment" в Концепциях. Используется он, когда в оффлайн ушло табличное пространство с незавершенной по нему транзакцией. Если такая транзакция впоследствии будет откатана, то в сегмент "отложенного" отката покладут старые значения. Вот они и будут воткнуты в блоки назад сразу, как только табличное пространство вновь появится в состоянии онлайн. Всё это может сочетаться с предварительным восстановлением этого пространства, которое, как известно, делается в оффлайне.
15 июн 06, 17:41    [2776355]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Как так
Guest
Просто так
YAP, почитайте про "deffered rollback segment" в Концепциях. Используется он, когда в оффлайн ушло табличное пространство с незавершенной по нему транзакцией. Если такая транзакция впоследствии будет откатана, то в сегмент "отложенного" отката покладут старые значения. Вот они и будут воткнуты в блоки назад сразу, как только табличное пространство вновь появится в состоянии онлайн. Всё это может сочетаться с предварительным восстановлением этого пространства, которое, как известно, делается в оффлайне.


В данном случае табличное пространство в оффлайн не уходит ( архивируется RMAN'ом ) значит и косвенный сегмент отката не создается ?
15 июн 06, 18:09    [2776510]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
DВА
Member

Откуда:
Сообщений: 5439
данные в редулогах для незакомиченной транзакции приблизительно пишутся так
0. начало транзакции
1. записать андо
2. изменить data-блоки
3. восстановить data-блоки (rollback)
4. конец транзакции
когда восстанавливаете один файл, то пункт 1 будет пропущен, т.к. undo восстанавливать не нужно, а данные необходимые для отката уже записаны в редулоги при выполнении пункта 3
15 июн 06, 18:09    [2776511]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Feech
Member

Откуда:
Сообщений: 443
DВА, а где про такие подробности можно почитать?
15 июн 06, 18:18    [2776539]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
DВА
данные в редулогах для незакомиченной транзакции приблизительно пишутся так
0. начало транзакции
1. записать андо
2. изменить data-блоки
3. восстановить data-блоки (rollback)
4. конец транзакции
когда восстанавливаете один файл, то пункт 1 будет пропущен, т.к. undo восстанавливать не нужно, а данные необходимые для отката уже записаны в редулоги при выполнении пункта 3


Правильно ли я понял п. 3, что когда откатывается транзакция (в обычном штатном режиме работы), то измененные блоки данных откатываются соотв. undo-данными и эта операция отката блока логируется в журнал повтора?
15 июн 06, 18:20    [2776548]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
Feech
DВА, а где про такие подробности можно почитать?


Прошерстил доку на предмет термина "deffered rollback segment", не повезло, ничего не нашел :(, что-то конечно нагуглилось, но почему в официальной доке об этом ни слова?
15 июн 06, 18:34    [2776604]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
DВА
Member

Откуда:
Сообщений: 5439
YAP
DВА
данные в редулогах для незакомиченной транзакции приблизительно пишутся так
0. начало транзакции
1. записать андо
2. изменить data-блоки
3. восстановить data-блоки (rollback)
4. конец транзакции
когда восстанавливаете один файл, то пункт 1 будет пропущен, т.к. undo восстанавливать не нужно, а данные необходимые для отката уже записаны в редулоги при выполнении пункта 3


Правильно ли я понял п. 3, что когда откатывается транзакция (в обычном штатном режиме работы), то измененные блоки данных откатываются соотв. undo-данными и эта операция отката блока логируется в журнал повтора?

если упощенно, то да :)
http://julian.dyke.users.btopenworld.com/com/Presentations/Presentations.html
15 июн 06, 18:46    [2776644]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
YAP
Feech
DВА, а где про такие подробности можно почитать?


Прошерстил доку на предмет термина "deffered rollback segment", не повезло, ничего не нашел :(, что-то конечно нагуглилось, но почему в официальной доке об этом ни слова?


Пардон, у меня оказывается дока не индексирована, так что поиндексируется, да поисчу еще.
15 июн 06, 18:53    [2776667]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Feech
Member

Откуда:
Сообщений: 443
YAP
Feech
DВА, а где про такие подробности можно почитать?


Прошерстил доку на предмет термина "deffered rollback segment", не повезло, ничего не нашел :(, что-то конечно нагуглилось, но почему в официальной доке об этом ни слова?


Угу, такая же фигня.

Кстати, в чем отличие п.п. 1 и 3?
15 июн 06, 18:55    [2776672]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
DВА
Member

Откуда:
Сообщений: 5439
YAP
Feech
DВА, а где про такие подробности можно почитать?


Прошерстил доку на предмет термина "deffered rollback segment", не повезло, ничего не нашел :(, что-то конечно нагуглилось, но почему в официальной доке об этом ни слова?

https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=232348&pg=2#2040525
15 июн 06, 18:59    [2776688]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
DВА

http://julian.dyke.users.btopenworld.com/com/Presentations/Presentations.html


а что именно здесь по обсуждаемому вопросу? а то по названиями пока не очевидно, а скорость доступа крайне неудовлетворительна.
15 июн 06, 19:04    [2776701]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
DВА
Member

Откуда:
Сообщений: 5439
Redo Internals
15 июн 06, 19:40    [2776781]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
MacDuck
Member

Откуда: Москва-Подольск
Сообщений: 6387
Feech

3. откат неподтвержденных транзакции с помощью UNDO сегментов.


А именно откат назад незакоммиченных транзакций и есть вторая стадия recovery. Так и есть.
15 июн 06, 21:41    [2777008]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
MacDuck
Member

Откуда: Москва-Подольск
Сообщений: 6387
andrey_anonymous

DBA меня поправят ежели совру, но ключ к пониманию процесса - тот факт, что UNDO тоже защищен посредством REDO...


Не поправят, но подтвердят твою правоту.
15 июн 06, 21:43    [2777018]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
Просто так
deffered rollback segment


такой термин не найти, пока орф. ошибки не исправить.
А найдено в "Information on Deprecated Features" для 9i, есть правда и в других местах, но насколько оно там уместно...
16 июн 06, 11:07    [2778215]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
softy
Member

Откуда: from Russia
Сообщений: 5911
Feech
Последнее время изучаю тему Backup and Recovery.
С бэкапом вроде разобрался, настроил автобэкапы, вроде пока работает.

С Recovery ситуация посложнее, даже в теории.
Вот, например, вопрос про Media recovery:
В разных источниках, типа официальной документации, неокторых книг, asktom и т.п.,
процедура восстановления, например, файлов с данными, схематично выглядит так:
1. restore: восстановление файлов из бэкапа
2. recovery: накат изменений на файл с использованием (в т.ч. архивных) журналов наката (Redo logs)

И типа все. Но где же тут UNDO? Ведь в журналах наката хранятся и не подтвердженные транзакции,
и после полного наката надо бы неподтвержденные
откатить. Ведь речь идет о файлах данных, в которых, по-моему, неподтвержденным транзакциям
не место. Скорее всего, должен присутствовать и пункт
3. откат неподтвержденных транзакции с помощью UNDO сегментов.

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

Буду признателен за комментарии.


1. Я считаю слово "restore" на русский лучше переводить как "извлечь", а "recovery" именно как восстановить
2. Неподтверждённые транзакции, как и подтверждённые сначала накатываются вперёд(forward), а потом откатываются назад (back)
3. Зачём вам UNDO, вы же накатываете на копию БД, сделанную до тех изменений которые будут откачены назад при восстановлении.
16 июн 06, 11:16    [2778309]     Ответить | Цитировать Сообщить модератору
 Re: Механика Restore/Recovery  [new]
Feech
Member

Откуда:
Сообщений: 443
softbuilder@inbox.ru

3. Зачём вам UNDO, вы же накатываете на копию БД, сделанную до тех изменений которые будут откачены назад при восстановлении.


В тот момент в базе уже могли были неподтвержденные данные. И они в частности, могли попасть в архивные логи. Так что почему обызательно "до"?
16 июн 06, 11:23    [2778369]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Oracle Ответить