|
|
|
Вопрос по концепту: 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 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 Violina Вот тут-то Вы и попались. DDL идет как обычный DML над таблицами словаря. Он так и виден LogMiner'ом. И команды drop database не существует... 2 ppp Команды в журнал и откат не пишутся в виде SQL'а. Они пишутся в виде внутренних команд. Поэтому не надо все понимать буквально, что копируются блоки. Индексы ведь тоже обновляются... А многострочные DML пишутся пять-таки в виде кучи элементарных операций. Поэтому в LogMiner не видно одной большок команды вроде delete from t. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 18:06 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al Ну что ж! Насчет DML таблиц словаря логично. Но ведь я была права, что DDL изменения прописываются в дата файлы сразу и не откатываются. Например, если я делаю DROP TABLE, то коммит происходит сразу же и я не могу эту операцию откатить. Не сбрасывает же он при этом все данные таблицы в сегменты отката, это зачастую просто не может быть возможным, если таблица большая или например партиционирована. До использования LogMiner'а пока не дошла, так что проверить сама пока не могу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 18:21 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
А системный сегмент отката для чего нужен? Попробуйте прервать drop user bill cascade для пользователя с большим количеством объектов, увидите последовательное убиение объектов, но сам пользователь будет жив! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 18:43 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al Ja poigrajusj malenko s Log Minerom , togda navernoe okonchatelno projasnitsa v kakom vide informacija ob izmenenii rollback pishetsa v redo log, a to vse taki ne jasno, kak iz takih malenkih redo log ,Oracle mozet vosstanovitj rollback v sluchae naprimer dlinnoj operacii update ( kogda sam rollback dovolno bolshoj ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 20:50 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al Как это нет DROP DATABASE? А как же тогда базу дропнуть если нужно, ручками? И файлы потом ручками вычищать? Ну а в общем, являются ли мои предположения по поводу DDL операций правильными, что они сразу прописываются в дата файлы? С drop user вроде понятно, что Оракл сначала ссылающиеся обьекты удаляет и лишь потом самого юзера - чтобы ни в коем случае не возникла неконсистентность. А вот интересно, если такую операцию прервать имитируя сбой (напримел отстрелив процесс Оракла), ее потом можно будет повторить или откатить? А системный сегмент отката для чего нужен? Системный сегмент отката нужен скорее всего для операций со словарем данных. to ppp Я вижу вы экспериментируете в LogMiner'ом. Не могли бы вы попробовать создать таблицу, залить туда достаточно много данных а потом дропнуть ее. Любопытно посмотреть, что произошло с реду и сегментами отката. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 09:57 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 Violina Чтобы убить базу, надо удалить все файлы, входящие в нее. А drop database все-таки не существует... По поводу убиваемого юзера. Проще сделать "следственный эксперимент". DDL действительно пишется в виде довольно сложных транзакций, заканчивающихся коммитом. 2 ppp logminer дает не внутренний вид команд, а читабельный, поэтому с ним надо держать ухо востро. Это все-таки инструмент для восстановления данных. По поводу маленьких журналов - посмотрите еще раз мой постинг о чекпойнтах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 10:10 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al Мои следственные эсперименты по грубому прерыванию пока что не удавались - слишком быстро все происходит не успеваю их прервать. Как же наплодить столько объектов, чтобы их удаление заняло какое то время? И как прерывать процесс - в таск менеджере (win2000, SQL Navigator)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 10:20 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
>Ну а в общем, являются ли мои предположения по поводу DDL операций правильными, что они сразу прописываются в дата файлы? В этом смысле они отрабатывают также как и другие операции. Неявный коммит вас не должен смущать, поскольку запись измененных блоков данных на диск и коммит напрямую между собой не связаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 10:41 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to killed Согласна, неявный коммит скорее не причина а следствие особенности DDL операций. Я просто предположила, что этот подход преждевременного или отложенного прописывания изменений в дата файлы в целях повышения эффективности имеет место только для DML операций. Поэтому и настолько важна роль реду ога и сегментов отката, чтобы обеспечить консистентность в случае сбоя. Для DDL операций такой подход скорее всего не адекватен, потому что DDL операции достаточно критичны. Поэтому изменения сразу прописываются где надо и сразу коммитятся. Какой смысл откладывать такие операции как DROP TABLE, CREATE TABLE, изменения размеров сегментов и других параметров - никакого! Ждем результатов экспериментов ррр... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 11:05 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
>Для DDL операций такой подход скорее всего не адекватен, потому что DDL операции достаточно критичны. Поэтому изменения сразу прописываются где надо и сразу коммитятся. Какой смысл откладывать такие операции как DROP TABLE, CREATE TABLE, изменения размеров сегментов и других параметров - никакого! Я ничего не понял :-) Если не против небольшого освежения беседы, такая ситуация: 1. В сессии А: select * from табла; (допустим, 1000000 записей) - осуществляется вывод. 2. Пока в А выводятся результаты запроса, в сессии Б: drop table табла; Ваши комментарии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 11:40 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Angel писал: Для DDL операций такой подход скорее всего не адекватен, потому что DDL операции достаточно критичны. Поэтому изменения сразу прописываются где надо и сразу коммитятся. Какой смысл откладывать такие операции как DROP TABLE, CREATE TABLE, изменения размеров сегментов и других параметров - никакого! Сожалею что пока не всегда могу ясно выражаться. Попробую перефразировать. Под подходом я имела ввиду, преждевременное или наоборот отложенное прописывание DML изменений в дата файлы, который и обуславливает нагрузку на реду лог и сегмента отката. Я пытаюсь выяснить свое предположение которое заключается в том, что в случае DDL операций, реду лог и сегмент отката нагружаются минимально, так как изменения DDL сразу отражаются в дата файлах, контрол файлах, словаре итп . PS: В использовании всяких средств я пока не сльна (изучаю концепт), поэтому мои возможности в экспериментах пока ограничены:-) По вашему вопросу: Пока выполняется SELECT, будет установлен LOCK (какой точно не знаю), так что DROP TABLE будет ждать окончания операции SELECT или будет выдана ошибка, что не может быть получен exclusive lock на таблицу в данный момент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 12:08 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Violina, При выполнении операций над словарем сегменты отката и журналы задействуются всегда на всю катушку, поскольку при некоторых обычных DML можно выключить журналирование (nologging) или откат (discrete transactions), а для словаря - нельзя. Другое дело, что изменения в словаре не затрагивают большого количества строк, поэтому выполняются быстро. Например, drop table - это вычеркивание строки таблицы, нескольких строк столбцов и нескольких строк занятого пространства + инвалидация зависимых объектов. Чем больше столбцов и экстентов, тем дольше будет работать удаление таблицы. Оракловская система чекпойнтов, записи журналов и отката не меняется для операций над словарем. Не забудьте о том, что словарь хранится в оптимальных для запросов и DML структурах данных (много кластеров). Чтобы посмотреть на них - гляньте на sql.bsq. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 12:40 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al Ну вот, опять неясно выразилась:-( Под нагрузкой я имела ввиду запись большого количества данных в реду и сегменты отката. И так, в свете этого, мое предположение звучит так: в случае DDL операций, в реду лог и сегмент отката пишеться небольшое количество данных, так как изменения DDL сразу отражаются в дата файлах, контрол файлах, словаре итп. Выяснив этот вопрос, я думаю эту тему можно закрыть. И так, ждем ответа ррр и комментариев желающих. Позже, я сама попробую поэкспериментирвоать. За ответы DDL идет как обычный DML над таблицами словаря. Другое дело, что изменения в словаре не затрагивают большого количества строк, поэтому выполняются быстро. большое спасибо, они очень помгли мне в понимании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 12:53 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Violina, Ваше предположение неверно. Запись в system мало отличается от других разделов (всегда проверяются контрольные суммы блоков). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 13:59 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al Хорошо, конкретизируем вопрос. Есть таблица TEST с большим количеством записей. При выполнении DML команды DELETE FROM TEST должно записаться очень много данных в сегменты отката, чтобы иметь возможность откатить эту операцию если понадобится. Однако DDL команда DROP TABLE TEST запишет туда только изменения в словаре данных и откатить ее будет нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 14:28 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Верно. Но измененные блоки словаря запишутся dbwr в датафайлы системного раздела на общих основаниях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 14:49 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
to Al To estj vosstanavlivaetsa tolko nebolshaj chastj rollback segmenta posle poslednego chekpointa ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 16:41 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 ppp Именно так! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 16:44 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
2 AI >Можно я отвечу про insert? В откат пишется операция delete from ttt where >rowid='rrrrrrr'. Эта команда много места не занимает, поэтому нагрузка на >сегменты отката при вставках минимальна, но максимальна журнальная >информация. При удалениях обратная ситуация - максимальная нагрузка на >сегменты отката и минимальная - на журналы. ммм... не совсем так. Насчет минимальной нагрузки на при вставках и максимальной при удалениях на сегменты отката согласен, а вот насчет минимальной нагрузки на журналы при удалениях - этого не может быть по определению, т.к. нужно записать в журналы также все изменения в блоках сегментов отката (на которые как вы правильно заметили - нагрузка максимальна). Поэтому объем журнальной информации при удалениях все равно будет намного больше (где-то в 3 раза), чем при вставках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 19:58 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
To Al perechital vse postingi , tormozil ja konechno strahno ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 21:31 |
|
||
|
Вопрос по концепту: redo log, roll back segments
|
|||
|---|---|---|---|
|
#18+
Вот яки гарьни хлопьци и дивчины здесь собравлися... як побачивь я этот форум... и захотел вопрос задавать... Вопрос исключительно прикладной... почему наша БД всегда такая глючная и падучая... что делать ? пнуть dba не предлагати... ;) повесить его (или себя??) тоже... вобщем ваши 5TOP советов по повышению работоспособности сей СУБД оракл 8.1.x.x ...что имеет честь стоять у нас в контори... Респект... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 06:54 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1990979]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
95ms |
get tp. blocked users: |
2ms |
| others: | 210ms |
| total: | 412ms |

| 0 / 0 |
