|
|
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
При чтении концепта по теме сегменты, возникла некоторая несность. Проясните плиз или исправьте неточности понимания! Преабула: При работе с базой изменения пишуться из redo log buffer в redo log files. Сами данные хранятся и меняются в database files. При сбое, используя redo log files, осуществляется rolling forward а потом, используя данные в roll back segments, откатываются операции незакоммиченных транзакций к моменту сбоя. В свете этого, roll back segments мне представляются как области памяти (возможно при необходимости выгружаемая на диск) для храняния старых значений, которые используются для отката или для обеспечения консистентности запросов по моменту времени. Теперь вопрос: В концепте сказано: Rollback entries change data blocks in the rollback segments, and Oracle records all changes to data blocks, including rollback entries, in the redo log. Зачем писать еще и rollback entries в redo log, если в него уже и так пишуться изменения? Допустим произошел сбой. Осуществили rolling forward. Это создало rollback entries в rollback segment. Закоммитили операции закоммиченных до сбоя транзакций. Откатили, используя созданные rollback entries в rollback segments, операции незакоммиченных до сбоя транзакций. Зачем было сохранять еще и rollback entries в redo log??? Буду очень признательна за разъяснения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2003, 17:43 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Во первых: журнал транзакций redo log ( и сегменты отката rollback segments - это принципиально разные вещи! В redo log хранятся сами транзакции - например инсерты, апдейты и делиты. То есть по сути дела это последовательность всех изменений базы в том порядке, в каком они происходили. На диске это несколько файлов с именем например redoORCL<цифра>.log или что то в этом духе. По мере заполнения эти файлы могут архивироваться, что очень полезно на случай сбоя! Каким образом происходит восстановление при сбое? Предполагается что есть копии всех файлов данных на какой то момент времени t1, и их надо просто восстановить с этого момента до того момента t2, когда произошел сбой (t1<t2). Также предполагается, что есть архивные redo logs которые содержат все изменения, произошедшие с базой с момента t1. Запускается восстановление - пишется что то вроде recover automatic database until cancel и вот тут происходит этот самый Rolling Forward. То есть все изменения, записаные в архивные redo logs применяются снова. Rollback segments тут не при чем! А что такое Rollback segments? Во-первых - это никакие не области памяти сегмент вообще - это часть физической структуры хранения данных: табличное пространство->сегмент->экстент->блок. Примеры сегментов: таблица, сегмент отката. Под сегменты отката выделяют отдельное табличное пространство или несколько, называют их типа rbs<цифра>.dbf. Хранятся в них блоки данных. Когда какая либо транзакция изменяет таблицу, старая версия измененного блока таблицы записывается в сегмент отката. Тот отрывок из концепта, что ты цитируешь видимо относится к резервному копированию, поскольку только в время него блоки данных пишутся в redo log. А пишутся они туда потому что блок, пока его копируют может измениться, например пока копировался заголовок изменился сам блок, в результате заголовок не соответствует содержимому блока. Надеюсь что достаточно полно ответил на твои вопросы )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2003, 19:42 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Было бы интересно, почитать побольше комментариев. Насколько понимаю я. В целом ситуация: База открыта. Началась транзакция, измененные ею блоки данных пишутся в буфера и, возможно, по необходимости скидываются в файлы данных; примерно тоже происходит с блоками данных сегментов отката. В это время в логи пишутся не измененные блоки полностью (за исключением, указанным Сиквелом), а только сами изменения. Происходит сбой (не связанный со сбоем дисков - все файлы БД не повреждены). Измененные блоки данных, находившиеся в буферах частично/полностью утеряны, в файлах данных возможно имеются блоки измененные незавершенными транзакциями. При открытии базы происходит восстановление экземпляра. Осуществляется откат вперед по редологам, все изменения в блоках данных восстановлены на момент сбоя, остается откатить незавершенные транзакции, используя роллбэки (чего не удалось бы осуществить, не сделав перед этим rolling forward). Мне сдается, что так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 06:02 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Комментариев море вот туту http://www.books.ru/shop/books/9428 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 08:08 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Сиквел Большое спасибо за разъяснения. Получается, что я все совсем не так поняла. Такой вопрос: Сиквел писал: В redo log хранятся сами транзакции - например инсерты, апдейты и делиты. То есть по сути дела это последовательность всех изменений базы в том порядке, в каком они происходили. А как они хранятся - просто как команды на изменения или в таком виде, чтобы их можно было отменить и восстановить состояние до их выполнения? Вот полный абзац из главы Data Blocks, Extents, and Segments - Rollback Segments: The first step of recovery is to roll forward, that is, reapply to the datafiles all of the changes recorded in the redo log. Rolling forward proceeds through as many redo log files as necessary to bring the datafiles forward to the required time. The roll forward is only half of recovery. After the roll forward, any changes that were not committed must be undone. After the redo log files have been applied, then the rollback segments are used to identify and undo transactions that were never committed, yet were recorded in the redo log. This process is called rolling back. Rollback entries change data blocks in the rollback segment, and Oracle records all changes to data blocks, including rollback entries, in the redo log. This second recording of the rollback information is very important for active transactions (not yet committed or rolled back) at the time of a system crash. If a system crash occurs, Oracle automatically restores the rollback segment information, including the rollback entries for active transactions, as part of instance or media recovery. Once the recovery is complete, Oracle performs the actual rollbacks of transactions that had been neither committed nor rolled back at the time of the system crash. То есть записи в сугменты отката для Оракл по сути аналогичны записям в обычные сегменты данным и поэтому тоже прописываются в redo log? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 10:00 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Tak chto ze dejstvitelno pishetsa v Redo log ??? Ja delaju isert 100 000 zapisej , a potom delaju ih update. Imeju 3 Redo log fajla po 500kb kazdij . Operacija zakanchivaetsa - objem vstavlennih dannih - 50mb , rollback segment virastaet bolshe 50 mb , chto sobstvenno ponjatno , t.k tam hranitsa 100 000 zapisej (before image ) vo vremja moego update. No vod redo log kak bili po 500kb , tak i ostalisj. Kakim obrazom tuda vlezla informacija ob izmenenii 100 000 zapisej ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 16:53 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Редулоги не растут, группы используются циклически, при необходимости при этом архивируясь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 16:55 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Ja ponimaju chto ciklicheski , no kak v takom sluchae proishodit otkat esli dannie o trasakcii uuze perepisani v redo loge ? Iz roollbackov chto li ? Tak tam toze posle commita dannie uze mogut bitj prerpisani. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 17:53 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Немоного старовато, но Журнал повторения Журнал повторения, существующий в каждой инстанции базы данных ORACLE, регистрирует все изменения, которые проводятся в базе данных. Журнал повторения инстанции состоит как минимум из двух файлов журнала повторения, отдельных от файлов данных (которые содержат действительные данные базы данных). Как часть восстановления базы данных от сбоя инстанции или сбоя носителя, соответствующие изменения из журнала повторения применяются к (восстановленным) файлам данных, обновляя данные базы данных к состоянию на момент сбоя. Журнал повторения базы данных может состоять из двух частей: онлайнового журнала повторения и архивированного журнала повторения, которые обсуждаются ниже. Онлайновый журнал повторения Каждая работающая база данных ORACLE имеет ассоциированный онлайновый журнал повторения. Этот журнал работает совместно с фоновым процессом ORACLE LGWR для немедленной регистрации всех изменений, выполняемых ассоциированной инстанцией. Онлайновый журнал повторения состоит из двух или более заранее распределенных файлов, которые используются циклически для записи текущих изменений в базе данных; для более подробной информации см. страницу 23-7. Архивированный (офлайновый) журнал повторения Если желательно, инстанция базы данных ORACLE может работать в режиме архивирования файлов онлайнового журнала повторения по мере их заполнения. Архивируемые файлы журнала повторения уникально идентифицируются и формируют архивированный журнал повторения. Путем архивирования заполненных онлайновых файлов журнала повторения можно сохранять старую информацию журнала повторения для более широких операций восстановления базы данных, в то время как заранее распределенные онлайновые файлы журнала повторения продолжают повторно использоваться для регистрации текущих изменений базы данных; для более подробной информации см. страницу 23-15. Сегменты отката Сегменты отката используются для многих функций в процессе работы базы данных ORACLE. В общем, сегменты отката базы данных хранят старые значения данных, измененных текущими (еще не подтвержденными) транзакциями. Среди прочих задач, информация в сегменте отката используется во время восстановления базы данных для "отмены" любых "неподтвержденных" изменений, примененных из журнала повторения к файлам данных. Поэтому, когда проводится восстановление базы данных, после использования сегментов отката для удаления всех неподтвержденных изменений из файлов данных данные остаются в согласованном состоянии; для более подробной информации см. страницу 3-16. Управляющие файлы В общем, управляющие файлы базы данных хранят состояние физической структуры базы данных. Часть этой информации состояния (например, идентификация текущего онлайнового файла журнала повторения, имена файлов данных и т.д.) используется ORACLE во время восстановления инстанции или носителя; для более подробной информации см. страницу 23-20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 18:18 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Журнал повторения, существующий в каждой инстанции базы данных ORACLE, регистрирует все изменения, которые проводятся в базе данных. Как часть восстановления базы данных от сбоя инстанции или сбоя носителя, соответствующие изменения из журнала повторения применяются к (восстановленным) файлам данных, обновляя данные базы данных к состоянию на момент сбоя. Vse eto ja chitsal ,otsjuda i vopros o tom kak ze informacija ob izmenenija/dobavlenija 50 mb dannih vlezaet v 3x500 kb redo log ??? Oni dolzni bit togda toze kak min 50 mb ? A esli cekliceski perepishutsa , kak togda vosstanovjatsa posle sboja ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 18:37 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2Violina В redo log хранятся только команды на изменения. Иначе, представь себе только что у тебя огромная таблица - где нибудь на гигабайт размером, и ты применяешь команду update без условий - она меняет все строки! Для того чтобы была возможность восстановить таблицу надо было бы всю ее переписать в redo log. Что касается записи изменений сегмента отката в redo log, то видимо так оно и есть...раз уж в концепте так сказано )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 18:38 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Esli tolko komandi , to togda vrode jasno chego one ne rastut ) Eto u menja navernoe MS SQL v bashke zasel , tam v log vse pishut, vot on i raset. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 19:01 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 Violina (только как резюме отличных ответов Сиквела и небольшого дополнения) В начале своей жизни любая транзакция определяется сегментом отката. При восстановлении оракул смотрит на заголовок сегмента и определяет, имеется ли у транзакции SCN (system commit number). Если есть - транзакция не откатывается, если нет - делается откат. Понятно, что при такой постановке вопроса информация о сегментах отката жизненно важна для оракула. Значит, любое изменение в сегменте отката должно попасть в журнал. Иначе просто не откуда будет делать накат на данные и сегменты отката. В сами журналы пишется информация во внутреннем представлении оракула (коды операции и данные) за исключением ситуации горячего бэкапа. Эту информацию можно затем преобразовать в вид команд DML утилитой log miner. Есть еще одна операция, о которой частенько забывают. Это чекпойнт. Он возникает, в частности, при переключении журналов. Задача его - привести базу данных в синхронизованное состояние на определенный номер SCN. То есть, при возникновении чекпойнта, все изменения до этого номера в обязательном порядке сбрасываются в датафайлы. Значит, в случае сбоя, надо будет накатить не все журнальные записи, которые могут быть потеряны при циклических переписываниях журналов, а только те, которые не были записаны с SCN последнего чекпойнта. Такой механизм позволяет с использованием небольших журнальных файлов хранить транзакции произвольной длины пока сегмент отката не дойдет до максимума или не заполнится датафайл/диск - тогда транзакция упадет и откатится... 2 ppp. Мне понравилось вот это: Ja ponimaju chto ciklicheski , no kak v takom sluchae proishodit otkat esli dannie o trasakcii uuze perepisani v redo loge ? Iz roollbackov chto li ? Tak tam toze posle commita dannie uze mogut bitj prerpisani После коммита данные уже и не смогут откатиться. И вот это: Esli tolko komandi , to togda vrode jasno chego one ne rastut ) Eto u menja navernoe MS SQL v bashke zasel , tam v log vse pishut, vot on i raset. Не растут, потому что переписывается циклически, как уже и объяснялось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 13:02 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
К моему вопросу нашла поясняющую информацию в концепте (может кому интересно) Committing Transactions Before a transaction that modifies data is committed, the following has occurred: Oracle has generated rollback segment records in rollback segment buffers of the system global area (SGA). The rollback information contains the old data values changed by the SQL statements of the transaction. Oracle has generated redo log entries in the redo log buffer of the SGA. The redo log record contains the change to the data block and the change to the rollback block. These changes may go to disk before a transaction is committed. The changes have been made to the database buffers of the SGA. These changes may go to disk before a transaction actually is committed. When a transaction is committed, the following occurs: The internal transaction table for the associated rollback segment records that the transaction has committed, and the corresponding unique system change number (SCN) of the transaction is assigned and recorded in the table. The log writer process (LGWR) writes redo log entries in the SGA's redo log buffers to the online redo log file; it also writes the transaction's SCN to the online redo log file. This atomic event constitutes the commit of the transaction. Oracle releases locks held on rows and tables. Oracle marks the transaction complete. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 14:01 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
To Al Spasibo za pojasnenija , edinstvennoe chto eshe ostalosj neponjatnim - v kakom vide hrtanitsa informacija ob iznmenenijah v rollback segmentah - toze v vvide kakih to kommand ? ps v MS SQL toze mozno sdelatj log ciklicheskim , no razmer u nego vse ravno budet gorazdo bolshe , potomu kak rollback segmentov netu i before image nuzno pisatj v log. Tak chto pri dlinnoj tranzakcii on raspuhnet. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 16:55 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 ppp Разумеется. Сбрасывается команда, обратная основной, но тоже в виде оп-кодов и данных. Например, основная insert, обратная - delete и т.д. А архитектура у оракла немного отличается от MS, поэтому можно обойтись без распухания журналов, но с распуханием rbs-разделов базы. Закон сохранения он работает везде... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 17:11 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
[quote Al] После коммита данные уже и не смогут откатиться. [/quote] То есть блоки данных перед изменением сваливаются в сегменты отката, чтобы можно было откатить незакоммиченную тразакцию после сбоя? Если же транзакция закоммичена, то данные уже и не смогут откатиться . Поэтому и можно использовать данные области сегментов отката уже для других операций. to ppp А вот с INSERT интересно, что пишется при этом в редо лог, по идее должны писаться все INSERTы чтобы их можно было повторить в случае сбоя (транзакция не закоммиченна на момент сбоя)? Но судя по вашему примеру записи 50000 INSERTов в редолог не произошло. Как же их можно было бы повторить, если бы произошел сбой? Наверное просто новые данные сразу писались в data files а не висели в памяти (хотя и транзакция еще не коммитилась), так что в повторении вставки большинства из них после сбоя не было бы необходимости. Ну а для отката после сбоя, использовался бы сегмент отката. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 17:29 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Violina pri inserte kak ja poninaju ( posle vseh objasnenij ) prosto v redo log pishetsa sama komanda insert,samih dannih tam netu , a dlja etogo mnogo mesta ne nuznu. poetomu redo log i ne viros. V Redo log toze bolshih dannih net t.k. ja ne menjaju dannie , a delaju insert , stalo bitj "before image" dannih do opercii insert kak bi pustoj. Pri sboe , esli on proizoshel do commit , budet vipolnena obratnaja komanda ( delete vseh zapisej do sboja ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 18:20 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Opechatka ," V Redo log toze bolshih dannih net t.k. ja ne menjaju dannie " sleduet chitatj kak " v rollback segment bolshih dannih net t.k. ja ne menjaju dannie ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 18:22 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 Violina Можно я отвечу про insert? В откат пишется операция delete from ttt where rowid='rrrrrrr'. Эта команда много места не занимает, поэтому нагрузка на сегменты отката при вставках минимальна, но максимальна журнальная информация. При удалениях обратная ситуация - максимальная нагрузка на сегменты отката и минимальная - на журналы. Вы не спросили еще вот что - как пишется в журнал (и в откат операции типа DDL или многострочные вставки/обновления/удаления). Подумайте над этим, а я еду в командировку и не обещаю скорых ответов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 18:31 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
a kakaja raznica v nagruzke na roll back i redo log pri vstavke ? В откат пишется операция delete from ttt where rowid='rrrrrrr'. Stalo bitj v redo log pishetsa tot samij inset ***. Vrode kak nagruzka odinakovaja ? Vo vremja delete vse ponjatno. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 18:54 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Во-первых redo log не раздуваются, но тем не менее позволяют восстановить базу данных с какого-угодно момента в прошлом просто потому, что они записываются циклически и архивируются. Если база данных работает в режиме archivelog, включено автоматическое архивирование (параметр ARCHIVE_LOG_START установлен в true в init.ora), то после заполнения очередного redolog-файла, фоновый процесс arch копирует его в архивный файл журнала транзакций Во-вторых в сегменты отката команды НЕ ПИШУТСЯ. Туда пишутся сами данные в виде блоков. Поэтому нагрузка на сегменты отката в результате любых операций изменения данных максимальна. И в-третих: Том Кайт пишет, что команда delete для удаления одной строки попадает в редо лог с параметрами: идентификатор файла данных, идентификатор блока, идентификатор самой строки. (Могу предположить что туда пишется всего лишь Rowid, поскольку в нем есть вся эта информация). А вот в каком виде туда попадает запрос на удаление всех строк таблицы - загадка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2003, 08:12 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Сиквел & All Во первых спасибо за ответы, У меня все же остались непонятки ) В лог фаилы пишутся все операции над данными и информация об изменении роллбаков.После аварии накативаются все изменения с момента последнего чекпоинта, затем незаконченные транзакции откатываются из роллбаковб которые содержат данные до изменения (именно данные , в связи с чем, при модификации или удалении данных больших обьемов данных в внутри одной транзакции сегменты отката могут рости довольно сильно ). Как уже написал ALL : информация о сегментах отката жизненно важна для оракула. Значит, любое изменение в сегменте отката должно попасть в журнал. Иначе просто не откуда будет делать накат на данные и сегменты отката. Что это за информация об изменении роллбаков, в каком виде ? Я так понимаю благодаря этой информации осуществляется восстановление роллбаков которие затем используются для отката, я только не понимаю зачем это нужно, ведь before image активных незаконченных транзакций по любому записан в роллбак до начала транзакции и до ее коммита потерян или переписан быть не может ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2003, 23:30 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 ppp Совсем не факт что "before image активных незаконченных транзакций по любому записан в роллбак до начала транзакции и до ее коммита потерян или переписан быть не может" Все измененные блоки пишутся не сразу в сегменты отката, а сначала кэшируются на диске. То есть сегменты отката в этом отношении ничем не отличаются от таблиц. Если произойдет сбой, данные отката, которые не успели сброситься из кэша на диск будут потеряны. Именно поэтому они дублируются в журнале транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2003, 10:55 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al (и всем интересующимся) Насчет DDL команд вопрос интересный. Ведь эти команнды автоматически осуществляют коммит, поэтому, я думаю, комманды такого рода не нагружают редулог и сегменты отката, а сразу прописываются в дата файлы. Поддерживать историю с возможностью отката для таких комманд очень накладно и очень сложно. Я думаю, поэтому такие комманды автоматически осуществляют коммит транзакции. Интересно бы было откатывать такую операцию, как DROP DATABASE ... Insert может писаться и в уже используемые блоки, не обязательно в новые, поэтому он тоже должен нагружать сегменты отката. В них ведь пишутся не операции, а оригинальные копии тех блоков, которые во время транзакции были изменены. Вообще весь этот механизм с сегментами отката и редулогом, является таковым, прежде всего потому, что Оракл не всегда сразу прописывает изменения в дата файлы или наоборот делает это преждевременно - изменения еще не закоммиченной транзакции могут быть уже сохранены в дата файлах и наоборот, закоммиченные данные могут быть лишь некоторое время спустя записаться в дата файлы. Поэтому, сегмент отката используется когда данные еще не закомиченной транзакции были прописаны в дата файлы до сбоя, чтобы их откатить при рикавери. А реду лог используется, чтобы повторить изменения транзакции котороя была закоммичена до сбоя, но изменения не успели прописаться в дата файлы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 10:12 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32137223&tid=1990979]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
171ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 485ms |

| 0 / 0 |
