2 В.

Как и обещал, даю более точные координаты: Глава 2 (Архитектура), Процессы, Фоновые (Background) процессы, DBWn - запись блоков базы данных, самое последнее предложение перед "LGWR - запись журнала" (что в англ. варианте выглядит примерно как "LGWR - redo log writer"):

Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск.

Очень хотелось бы, если не затруднит, увидеть оригинальный текст Кайта.
Спасибо.

Спасибо за ответ.
Мне кажется, что Кайт здесь ошибается.

Запись в online redo существенно необходима для обеспечения возможности восстановления как при сбое экземпляра (shutdown abort, сбой по питанию и т.п.), так и при сбое носителя. Поэтому отсутствие записи зафиксированных изменений и/или commit-маркера в online redo при последующем сбое носителя и отсутствии бэкапа табличного пространства (или, если быть точнее, конкретного датафайла(ов)) сделает невозможным восстановление базы даных без потерь информации. Именно поэтому после выполнения операций в режиме NOLOGGING (когда нет записи об операции в online redo, или она минимальна) Oracle настоятельно рекомендует выполнить backup соответствующего табл. пространства/пространств. Кроме того, если во время длительной транзакции, которая завершалась бы операцией ROLLBACK, грязные блоки записывались бы на диск (что в действительности и может происходить и обычно происходит), а соответствующая redo-информация не записывалась бы при этом в журналы (а в журнал попадает в том числе информация об изменениях в сегментах отката), то в случае сбоя экземпляра в файлы данных попали бы незафиксированные изменения , которые Oracle при очередном crash recovery не смог бы откатить (нет соотв. redo).

Более того, Oracle никогда не записывает грязные блоки на диск до тех пор, пока redo-entries, "защищающие" эти блоки, не будут сброшены на диск в online redo процессом LGWR. Если мне не верите, вот ссылка:
http://www.ixora.com.au/notes/rba.htm

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

Таким образом, фраза Кайта "...the writes to the online redo log could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead." на мой взгляд, ошибочна, либо он имел ввиду нечто другое. На перевод в данном случае, как мне кажется, грешить нельзя.

igor2222Ага! Возникло подозрение, что Кайт в электронном виде таки существует :-)))))))
На чем оно основано?

В.Маркеленкову и "Новичку"

А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит.
Лично я не против, Виталий (newbie), думаю, тоже будет не против. Кстати, чайником он только прикидывается, если Вы еще не заметили. Про утилиту exp тоже можно было бы спросить, но про возможность сослаться на Фунтика надо у него же и спрашивать.

Правда, попутно возникает два вопроса:

1. Умеет ли он читать по-русски? Или Вы ему переведете нас? ;-)
2. Неужели никто на asktom его об этом до сих пор не спрашивал? Ведь книга в английском варианте вышла гораздо раньше, да и англоговорящих спецов по Oracle гораздо больше. Кстати, я заметил, что многие просто боятся спорить с Кайтом.

Пока не появился "злой Фунтик", чуть уточню
Oracle newbie1. блок данных изменился и был записан в log buffer
Правильнее было бы сказать "и вектор его изменений был записан в log buffer".

2 В., all

Можно еще добавить, что кроме ситуации с checkpoint (переключение журналов, alter system checkpoint, события FAST_START..., log_checkpoint_interval/time,...) DBWR может попросить LGWR сбросить log buffer в current redo еще, например, в случаях, когда:

- серверный процесс после просмотра _db_block_max_scan_pct % LRU-списка не может получить free block и просит DBWR сбросить грязные блоки на диск
- когда число грязных блоков в LRU-списке достигает _db_large_dirty_queue
- выполняется команда alter tablespace xxx begin backup
- выполняется shutdown (кроме shutdown abort)
- по-моему, еще в случае, когда оптимизатор распараллеливает операции чтения над сегментом, все его грязные блоки должны быть тоже сброшены на диск
- наверняка есть еще ситуации, которые я сейчас не вспомнил, но это не суть важно.

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

К сожалению, мне уже некогда, есть дела, которые надо сделать перед отъездом. Жена уже пилит, гонит от компа... Поэтому без меня. А я с удовольствием потом почитаю ответы Тома, если он ответит и Вы дадите ссылочку.

B.Uvazhaemyi Markelenkov (esli vi eshe ne v otpuske) ,

Zdes' ya ne soglasna. Vi govorite:

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

Tom skazal, cho bloki mogut zapisivat'sa na disk minua redo log tol'ko esli COMMIT.
Сегодня я пока еще дома, но развернуто отвечать не буду. Готов и сейчас на 100% подписаться под этим своим высказыванием. Можно только более подробно расшифровать фразу "(нет соотв. redo)":

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

Кроме того, в случае, если бы действительно "...the writes to the online redo log could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead.", то в базе данных могли бы оказаться несогласованные (no consistent) данные, т.е. только часть изменений в блоках могла бы попасть на диск, а часть (из тех грязных блоков, которые DBWR еще не успел записать на диски) - пропасть. Причем все вышесказанное может случиться и в случае завершения транзакции операцией COMMIT.

Еще один, немного смешной "довод": как процесс LGWR может узнать, записал(и) ли процесс(ы) DBWn все грязные блоки, связанные с транзакцией, на диск, чтобы не записывать redo-информацию в журналы? Потребуется или изобретать для этого или способ общения LGWR с процессами DBWn, или LGWR должен будет сам (один) копаться в списках LRU (обычно в нескольких). В обоих случаях - это огромный объем кода и неимоверные тормоза в производительности.

Кроме всего, несколько удивляет фраза Тома "during a commit". Как процитировала выше Violina, Oracle использует алгоритм так называемого fast commit, который, в принципе, используя алгоритм delayed commit clearnout, может во время выполнения commit совсем не производить окончательных модификаций в измененных ранее текущей транзакцией блоках данных. В этом случае серверный процесс помещает в redo-блок в log buffer только маркер COMMIT и выдает сигнал клиентскому приложению, что транзакция завершена. Другими словами, обычно выполнение самой операции COMMIT занимает ничтожно малое время, поэтому, на мой взгляд , фраза "during a commit" выглядит несколько странно.

Ну вот, ответ получился все-таки достатчно развернутый :-)

P.S. Не хочется верить, что такой специалист, гуру, как Том Кайт, не понимает таких основ. Наверняка он хотел той своей фразой в книге сказать что-то другое. Вот и интересно выяснить - что же?

Ха-ха-ха!!! Писал ответ, нажал кнопку предварительного просмотра и увидел Ваш последний пост, Вера. Действительно, смешно! Вся наша дискуссия показала необходимость особой точности формулировок. Если бы в тексте присутствовала фраза "theoretically", "hypothetically", то все изначально было бы понятно., т.к. даже в английском варианте фраза трактуется совсем не так, как имел ввиду Том. Неудивительно, что перевод окончательно исказил весь смысл. Пусть Том пометит себе, что это место в книге следует уточнить.

Ну а на счет утилиты exp тоже было бы интересно разобраться. Спасибо за ссылку, может быть успею сегодня почитать.

2 В.

Все, прочитал внизу ветки
http://asktom.oracle.com/pls/ask/f?p=4950:8:383290::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:8145042756282

В этом разрезе вся моя критика по поводу "during commit" тоже лишена смысла.

Если бы в книге была бы фраза именно в виде ".... the writes to the online redo log (in theory) could be skipped if, during a
commit, Oracle physically wrote the modified blocks out to disk instead. (but
since it doesn't work that way, that is just a hypothetical)", то все было бы сразу ясно.

Спасибо за информацию.