Здравствуйте, Аноним, Вы писали:

А>кто говорит ? Мерле самый комизм ситуации что ни ты ни я в глаза этих процев не видели
Ну хоть прессрелизы-то можно почитать.

<...> юмор поскипан <...>
А> у оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc.
Ага, напихать на 50 контроллеров больше, чтобы получить выигрыш в полтора процента, и при этом утверждать, что это преимущество — это надо Ларри Элисоном быть..

Что же касается MSSQL'я то 5 лет назад, когда писали 2000, систем такого масштаба попросту не было и тестировать было не начем. И тот факт, что в этих условиях MSSQL рвал и Оракл, и DB2, до выхода их новых версий, говорит очень о многом.

А>зато у IBM работа с памятью (+200MHZ для разруливания блокировок) дала вон какой прирост производительности причем всего 32 проца (!)
На самом деле 64 — там в одном чипе 2 процессора, всего 32 чипа, итого 64 64-разрядных процессора.


А>IBM всю жизнь на 64 битах, как не крути AIX + power4 + DB2 UDB "ничего общего с новой архитектурой интела не имеют"
Если у процессоров одна и та же разрядность — это не значит, что у них одна и та же архитектура. Так что ни AIX, ни Power 4 действительно ничего нового с новым интелом не имеют.

Здравствуйте, Merle, Вы писали:
M>Что составляет полтора процента,
0.6%. Где там полтора-то???

Здравствуйте, Аноним, Вы писали:

А>кто говорит ? Мерле самый комизм ситуации что ни ты ни я в глаза этих процев не видели
>на счет IBM я вижу все на оборот — проц на 10% бысрее, а дисков не добавили — бесполезно, >блокировки не дают эфективно использовать диски, поэтому сколько их не суй толку нет. у >оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc. зато у >IBM работа с памятью (+200MHZ для разруливания блокировок) дала вон какой прирост ?>производительности причем всего 32 проца (!)

1) Почитай сначала README к IBMким фикспакам они добавляют в низ новую функциональность в DB2 (ассиметричный алгоритм сканирования индексов это одно из последних добавлений) так что разница между DB2 сейчас и три месяца назад все-таки есть.

2) Раскажи пожалуйста как блокировки мешают исполдьзовать диски??? Чем больше дисков тем меньше время сканирования (таблиц, индексов) и следовательно меньше время ожидания на юлокировке. Неувязочка у вас дорогой товарищ получается.

>>>ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, >а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы >индусы придумали. global services это не про IBM
>M>>Все это конечно весело но майнфреймы ничего общего с новой архитектурой интела не имеют, >и делиться опытом просто некому.

>А>в интеле от интела одни x86 инструкции остались, большинство это технологии DEC и риск >проца альфа. IBM всю жизнь на 64 битах, как не крути AIX + power4 + DB2 UDB "ничего общего >с новой архитектурой интела не имеют"

IBM между прочим всю жизнь была на 31-bit (тридцать один) на mainframe. И DB2 на mainframe
до сих пор 31-bit с элементами 64-bit. B это не мешает иметь DB2/390 отличную производительность на mixed worload. А 64 Bit в DB2 появились в 7 версии в 2000 году помоему

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>это что-то, которое сильно не так поправили в Юконе, уровень isolation level snapshot.
M>Ну уж всяко не для скорости, а сугубо удобства для....
M>И, кстати, там версионность реализована получше чем в Оракле... С теоретической точки зрения...

а чем получше ?

А>> у оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc.
M>Ага, напихать на 50 контроллеров больше, чтобы получить выигрыш в полтора процента, и при этом утверждать, что это преимущество — это надо Ларри Элисоном быть..

итак полтора процента — это 5 тыщ транзакций в минуту, это нагрузка для целого сервера фирмы средней паршивости. это долполнительно сотни юзеров в системе, для кого-то эти 100 юзеров будет решающим фактором, не брать мэйнфрейм, а просто напихать еще 50 контроллеров.


M>Что же касается MSSQL'я то 5 лет назад, когда писали 2000, систем такого масштаба попросту не было и тестировать было не начем. И тот факт, что в этих условиях MSSQL рвал и Оракл, и DB2, до выхода их новых версий, говорит очень о многом.

о чем ? о том что это субд способная решать задачи энтерпраиз ? 24x7 ? крутить решения лидеров SAP, Peoplesoft ? более продвинута в техническом плане ?
это были риторические вопросы, да МС хорошо развивается, но по фичам еще не дотянула до
Sybase & Posgres, Yukon большой шаг вперед, практически исчезают идеологические различия с ораклом, т.е. в результате МС пришел туда куда идет оракл — версионность и ядро java в субд. остались кластера shared nothing vs oracle RAC, кто победит тут х.з. но без оракла пока не может обойтись ни IBM до сих пор пускает тесты с ораклом, (нада показать результат лучше чем HP) ни MS Axapta (поддерживает оракл),к стате зачем ? переживают что кому то понадобятся эти полтора процента ? ведь у MS прекрасные результаты в tpc !

M>Если у процессоров одна и та же разрядность — это не значит, что у них одна и та же архитектура. Так что ни AIX, ни Power 4 действительно ничего нового с новым интелом не имеют.

что то я потерял нить — итак IBM всегда была 64бит, круче них в этой области только горы, что же им могло помешать порвать оракл как тузик грелку ? ведь "в производительности на OLTP задачах чистые версионники явно проигрывают" ? ах да оракл не чистый блокировочник ...

Gt_

Здравствуйте, Аноним, Вы писали:

А>итак полтора процента — это 5 тыщ транзакций в минуту, это нагрузка для целого сервера фирмы средней паршивости. это долполнительно сотни юзеров в системе, для кого-то эти 100 юзеров будет решающим фактором, не брать мэйнфрейм, а просто напихать еще 50 контроллеров.
Агащазблин.
Для тех фирм которым нужны такие мощности — это именно 0.6 процента — тоесть ничто.
Проще поставить рядом такой же DB2. Или процы поменять. Выигрыш будет гораздо существеннее.

А>о чем ? о том что это субд способная решать задачи энтерпраиз ? 24x7 ? крутить решения лидеров SAP, Peoplesoft ? более продвинута в техническом плане ?
Угу именно об этом.
И возвраящаясь к изначальному спору версионник vs блокировочник, даже такому полуверсионнику как Оракл, понадобилдось сменить две версии сервера и кардинально поменть все железо, чтобы превзойти результаты MSSQL.

А>это были риторические вопросы, да МС хорошо развивается, но по фичам еще не дотянула до
А>Sybase & Posgres,

Это ты кому-нибудь другому рассказывай. Sybase и Postges хороши в своих нишах, но до MSSQL'я им еще расти.

A> идет оракл — версионность и ядро java в субд. остались кластера shared nothing vs oracle RAC, кто победит тут х.з.
Не версионность, а гибридные системы — это две большие разницы. MS никогда не откажется от блокировок — и правильно сделает. В обозримом будующем ддвигаться в сторону от shared nothing MS, на сколько мне известно, не собирается.

A>но без оракла пока не может обойтись ни IBM до сих пор пускает тесты с ораклом, (нада показать результат лучше чем HP)
Ну ясен хвост. В этом секторе всего 3-4 сервера брятся за лидерство, с кем же им еще соревноваться?

A>MS Axapta (поддерживает оракл),к стате зачем ?
Затем, что это не детище MS, а MS ее купило и на этот момент она уже поддерживала Оракл.

A>переживают что кому то понадобятся эти полтора процента ?
Да это Оракл переживает, что на одинаковом железе явно проигрывает.


M>>Если у процессоров одна и та же разрядность — это не значит, что у них одна и та же архитектура. Так что ни AIX, ни Power 4 действительно ничего нового с новым интелом не имеют.

А>что то я потерял нить — итак IBM всегда была 64бит,
Еще раз есть разрядность и есть архитектура. разрядность ... архитектура. Еще раз повторить?

А>круче них в этой области только горы, что же им могло помешать порвать оракл как тузик грелку ?
Дык, порвали же. Чего еще надо?

Здравствуйте, s.ts, Вы писали:

ST>а чем получше ?
1. 100% определение конфликтов. Оракл при "Serializable" иногда обнаруживает конфликт там, где его нет на самом деле и откатывает транзакцию. Это особенность его версионного алгоритма.
2. В MSSQL'е никогда не будет ошибки "snapshot too old", пока есть место на диске. То есть нет проблемы случайно проскочившего слишком длинного запроса и неожиданно короткого сегмента отката.
3. Теоретически более быстрый алгоритм поиска нужной версии данных.

M>Не версионность, а гибридные системы — это две большие разницы.
класный прием, нада взять на вооружение — в конце топика оракл уже ближе к блокировочнику получается


A>>но без оракла пока не может обойтись ни IBM до сих пор пускает тесты с ораклом, (нада показать результат лучше чем HP)
M>Ну ясен хвост. В этом секторе всего 3-4 сервера брятся за лидерство, с кем же им еще соревноваться?
не понял мысли .. это возражение, вопрос ? уточню сою мысль (точнее мысль оракла) — IBM продает во первых железо, очень тяжело называть свое железо лучшим, когда ты не лидер на tpc. когда IBM не может своими силами (DB2) выйти в лидеры, они берут оракл.

A>>переживают что кому то понадобятся эти полтора процента ?
M>Да это Оракл переживает, что на одинаковом железе явно проигрывает.

выигрывает, поэтому IBM уже черт знает сколько ставит рекорды именно на оракле, а не на своем DB2. когда следующий их обойдет на пару процентов они опубликуют тесты на оракле, так было всегда

M> И возвраящаясь к изначальному спору версионник vs блокировочник, даже такому полуверсионнику как Оракл, понадобилдось сменить две версии сервера и кардинально поменть все железо, чтобы превзойти результаты MSSQL.

что за бред, не знаю что там было до семерки но начиная с него оракл всегда был лидером выпуская новый сервер
9ка рвет MS в 2 раза http://www.oracle.com/corporate/press/index.html?1440470.html
8рка на IBM http://www.findarticles.com/cf_dls/m0WUB/1999_Oct_11/56260522/p1/article.jhtml

утверждать не буду но почти уверен в свое время оракл лет 10 не слезал с первого места.

M>Еще раз есть разрядность и есть архитектура. разрядность ... архитектура. Еще раз повторить?

угу а то чо-то не догоняю.
еще раз для тех кто в танке — в тесте архитектура/разрядность у них одна — IBM Power4, OS одна — AIX, разные только модели — блокировочник и ораверсионник. ораверсионник показал лучший результат на как тут сосчитали 0.6 процента. байка о "опыте" IBM на своей архитектуре конечно веселая, но не выдерживает критику. а теперь вопрос, что ты пытаешся доказать ?

А>>круче них в этой области только горы, что же им могло помешать порвать оракл как тузик грелку ?
M>Дык, порвали же. Чего еще надо?
порвали — это хотя бы в 2 раза, как это обычно в tpc и было. как только оракл запустят на этих процах, все станет на свои места.


Gt_

Здравствуйте, <Аноним>, Вы писали:

А>класный прием, нада взять на вооружение — в конце топика оракл уже ближе к блокировочнику получается
Я этого не говорил...

А> когда IBM не может своими силами (DB2) выйти в лидеры, они берут оракл.

Я конечно понимаю твою любовь к ораклу, но не до такой же степени..

А>выигрывает, поэтому IBM уже черт знает сколько ставит рекорды именно на оракле, а не на своем DB2. когда следующий их обойдет на пару процентов они опубликуют тесты на оракле, так было всегда
Это точно в юмор. Результаты публикует Оракл, на том железе, которое ему удобнее. Попробовали погоняться на IBM'овском и облажались. На том же железе не получилось. Чтобы хоть как-то сравняться им пришлось в три раза увеличить производительность дисковой подсистемы.
Ты можешь выдвигать и другие.. версии.. но против фактов не попрешь.

M>> И возвраящаясь к изначальному спору версионник vs блокировочник, даже такому полуверсионнику как Оракл, понадобилдось сменить две версии сервера и кардинально поменть все железо, чтобы превзойти результаты MSSQL.
А>что за бред, не знаю что там было до семерки но начиная с него оракл всегда был лидером выпуская новый сервер
Нет, это не так. Оракл был лидером ровно до того момента, как MS запускала следующий тест на том же сервере.
Всерьез перегнать SQL 2000 смог только 10 Оракл, хотя, по логике вещей это должно было произойти гораздо раньше.

А>утверждать не буду но почти уверен в свое время оракл лет 10 не слезал с первого места.
Ну да, до выхода MSSQL 7.0

А> разные только модели — блокировочник и ораверсионник. ораверсионник показал лучший результат на как тут сосчитали 0.6 процента.
Нет, не так. Точнее будет сказать, что Оракл показал результат лучше на 0.6% увеличив исходную производительность дисковой подсистемы в 3 раза. Договаривай уж до конца.

А>байка о "опыте" IBM на своей архитектуре конечно веселая, но не выдерживает критику. а теперь вопрос, что ты пытаешся доказать ?
Я уже давно ничего не пытаюсь доказать, я, повторюсь, слежу лишь за точностью формулировок.

А> как только оракл запустят на этих процах, все станет на свои места.
Свежо предание...
В этих тестах Оракл уже давно сдал лидирующие позиции, и с появлением UDB и MSSQL 7.0 лишь изредка вырывается вперед выпуская новую версию. Но это счастье длится лишь до следующих тестов старых версий блокировочников.

Опять-таки, чтобы выбраться из окончательного офтопика, если я правильно помню, то ты возражая против утверждения, что OLTP быстрее, привел в качестве аргумента тесты tpc и результаты Оракла.
Так вот это не аргумент, как минимум по двум причинам.
1. Оракл не чистый версионник.
2. В этих тестах Оракл занимает отнюдь не лидирующие позиции.

А>>выигрывает, поэтому IBM уже черт знает сколько ставит рекорды именно на оракле, а не на своем DB2. когда следующий их обойдет на пару процентов они опубликуют тесты на оракле, так было всегда
M>Это точно в юмор. Результаты публикует Оракл, на том железе, которое ему удобнее. Попробовали погоняться на IBM'овском и облажались. На том же железе не получилось. Чтобы хоть как-то сравняться им пришлось в три раза увеличить производительность дисковой подсистемы.
M>Ты можешь выдвигать и другие.. версии.. но против фактов не попрешь.

tpc тесты железа, оракл там как консультант. IBM не пробывала — это практика последних лет 10 — рекорды ставить на оракле.

А>> как только оракл запустят на этих процах, все станет на свои места.
M>Свежо предание...
M>В этих тестах Оракл уже давно сдал лидирующие позиции, и с появлением UDB и MSSQL 7.0 лишь изредка вырывается вперед выпуская новую версию. Но это счастье длится лишь до следующих тестов старых версий блокировочников.

M>Опять-таки, чтобы выбраться из окончательного офтопика, если я правильно помню, то ты возражая против утверждения, что OLTP быстрее, привел в качестве аргумента тесты tpc и результаты Оракла.
M>Так вот это не аргумент, как минимум по двум причинам.
M>1. Оракл не чистый версионник.
да называй его хоть слоном, я лишь назыаваю так как вещи называют IBM&MS. мы сравниваем модель оракла и чистого блокировочника поэтому я сравниваю с IBM как лучшего представителя.

M>2. В этих тестах Оракл занимает отнюдь не лидирующие позиции.
еще раз — мы сравниваем модель, не версию субд, а модель.
у ораверсионной модели есть преимущество — читатели не блокируют писателей, писатели не блокируют читателей.
у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.

Gt_

Здравствуйте, Аноним, Вы писали:

А>у ораверсионной модели есть преимущество — читатели не блокируют писателей, писатели не блокируют читателей.
Это преимущество для разработчика. Писать удобнее.
Но в плане скорости для OLTP — это недостаток. Именно поэтому, ближайшее обозримое будущее за гибридными системами, которые позволят когда надо использовать всю производительность блокировок, а когда надо — гибкость версионного механизма.

А>у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.
Во-первых схожи не на одинаковом железе, ораклу приходится увеличивать производительность дисковой подсистемы в несколько раз, чтобы показать схожие результаты.
А во вторых, как я уже говорил, тесты SAP'а к данному разговору вообще никакого отношения не имеют, поскольку в SAP'е реализован свой собственный менеджер транзакций. И механизмы параллельной обработки транзакций СУБД, в его тестах попросту не задействованы.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, s.ts, Вы писали:

ST>>а чем получше ?
M>1. 100% определение конфликтов. Оракл при "Serializable" иногда обнаруживает конфликт там, где его нет на самом деле и откатывает транзакцию. Это особенность его версионного алгоритма.

можно пример ? (хочу разобраться)

M>2. В MSSQL'е никогда не будет ошибки "snapshot too old", пока есть место на диске. То есть нет проблемы случайно проскочившего слишком длинного запроса и неожиданно короткого сегмента отката.

т.е. у него для заинтересованных транзакций данные отката не уничтожаются пока место на диске есть ?
если так, то как-то это не очень имхо

M>3. Теоретически более быстрый алгоритм поиска нужной версии данных.

разговор о внутренней реализации или есть принципиальные отличия ?

Здравствуйте, s.ts, Вы писали:

ST>можно пример ? (хочу разобраться)
В Оракле поддержка многоверсионности происходит на уровне страниц данных. Записи не имеют метки последней транзакции, метку транзакции имеет страница, также есть внутристраничный кеш с некоторой информацией о последних транзакциях. В результате Оракл не всегда может точно определить есть ли нужная версия строки на текущей странице.
Поэтому оракл в некоторых случаях может обнаружить конфликт версий там, где его на самом деле нет, предпочитая перестраховаться.


ST>т.е. у него для заинтересованных транзакций данные отката не уничтожаются пока место на диске есть ?
Нет, уничтожаются конечно. Просто производится отслеживание старейшей заинтересованной транзакции, и не уничтожаются данные, которые, теоретически, могут кому-нибудь понадобиться.
Но как только тяжелый запрос закончится, все никому не нужные версии будут удалены.

M>>3. Теоретически более быстрый алгоритм поиска нужной версии данных.
ST>разговор о внутренней реализации или есть принципиальные отличия ?
Да, отличия принципиальные. Оракл поддерживает версионность на уровне страниц данных, а Юкон на уровне отдельных записей. В Оракле предыдущие версии данных берутся из Undo лога, а в Юконе из специального хранилища, специально для этого преспособленного — version store heap.
В итоге в Юконе механизм должен дыть не только быстрее, но и менее ресурсоемким.

А>>у ораверсионной модели есть преимущество — читатели не блокируют писателей, писатели не блокируют читателей.
M>Это преимущество для разработчика. Писать удобнее.
M>Но в плане скорости для OLTP — это недостаток. Именно поэтому, ближайшее обозримое будущее за гибридными системами, которые позволят когда надо использовать всю производительность блокировок, а когда надо — гибкость версионного механизма.

что ж посмотрим, но пока этот "недостаток" как-то никак не получается увидеть в реальных тестах ...


А>>у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.
M>Во-первых схожи не на одинаковом железе, ораклу приходится увеличивать производительность дисковой подсистемы в несколько раз, чтобы показать схожие результаты.

опять фантазии — а я вот считаю что на с 20 конролерами бы оракл показал бы лучше результат чем IMB, берем тест HP и смотрим как он делает MS на 25% с 26 контролерами (vs 64 у MS), дополнительне 50 контролеров нужны были для увеличения отрыва.

Gt_

Здравствуйте, Аноним, Вы писали:

А>что ж посмотрим, но пока этот "недостаток" как-то никак не получается увидеть в реальных тестах ...
Да ну?
На протяжении последних 3-4х лет очень даже получалось, и сейчас, вполне себе получается.

А>опять фантазии — а я вот считаю что на с 20 конролерами бы оракл показал бы лучше результат чем IMB,
Да бога ради, чтож не показал-то? Не смог?


А> берем тест HP и смотрим как он делает MS на 25% с 26 контролерами (vs 64 у MS), дополнительне 50 контролеров нужны были для увеличения отрыва.
Ну молодец Оракл, обошел сервер 5-ти летней давности, который вышел, когда такого железа еще и близко не было. Для этого ораклу понадобилось две новых версии продукта выпустить. Что можно сказать? Зачет.

Здравствуйте, Merle, Вы писали:

M>Да, отличия принципиальные. Оракл поддерживает версионность на уровне страниц данных, а Юкон на уровне отдельных записей. В Оракле предыдущие версии данных берутся из Undo лога,
Не совсем так, в Oracle нет UNDO-лога, есть REDO лог , т.е журнал доката в оракловской терминологии, который фактически является undo/redo логом. Но он используется только для восстановления базы после сбоев.

Для обеспичения версионности ( и отката транзакций при выдаче rollback ) используется отдельные структуры —
ROLLBACK- сегменты ( UNDO-tablespace начиная c 9-ки, но по сути тоже самое), которые UNDO логом можно назвать только с точки зрения храненеия UNDO информации, но при их ведении не требуется соблюдать протокол ведения undo журнала ( т.к. для восстановления они не используются), а потому и классическим undo логом они не являются.

Надеюсь окончательно всех запутал

Здравствуйте, KisA, Вы писали:

KA>Надеюсь окончательно всех запутал
О да..

KA>REDO лог , т.е журнал доката в оракловской терминологии, который фактически является undo/redo логом.
Нет, REDO лог хранит только Redo информацию и действительно используется только для восстановления после сбоев, а undo информация хранится в rollback сегменте. И используется и для восстановления и для отката транзакций.

С формальной точки зрения в Оракле undo/redo лог разнесен на два файла (на самом деле не два, а больше, ну назовем это двумя группами файлов).
Redo лог, который служит для наката транзакций, и Rollback сегмент, который служит для отката транзакций (то есть то, для чего в других системах служит undo лог).
Разнесено это дело из соображений производительности. Поскольку в версионнике откат транзакции явление очень частое, то подобная схема позволяет избежать ненужных очередей в том случае когда одной транзакции надо сбросить redo информацию, а другой откатить часть данных или посмотреть предыдущую версию.
Естественно, в случае восстановления после сбоя, ничто не мешает воспользоваться undo информацией из rollback сегмента.

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

А>>>у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.
M>>Во-первых схожи не на одинаковом железе, ораклу приходится увеличивать производительность дисковой подсистемы в несколько раз, чтобы показать схожие результаты.



А>опять фантазии — а я вот считаю что на с 20 конролерами бы оракл показал бы лучше результат чем >IMB, берем тест HP и смотрим как он делает MS на 25% с 26 контролерами (vs 64 у MS), дополнительне >50 контролеров нужны были для увеличения отрыва.

Не надо делать обобщенных выводов сравнивая MS SQL и Oracle и отображать свои выводы на DB2.
Это в корне не верно. Пока мы видим что на практически одинаковой железке Oracle менее производителен чем DB2. Причем адаптеров у DB2 28 FC. A у Oracle 66 FC и 6 _SSA_ который во многих случаях быстрее чем FC (при правильной настройке)

DB2 и MS SQL хоть и блокировочники, но разные.
И потом какой из тестов SAP ты имеешь в виду?

А>Не надо делать обобщенных выводов
как бы я эту мысль уже месяц пытаюсь донести до Мерле

А>Это в корне не верно. Пока мы видим что на практически одинаковой железке Oracle менее производителен чем DB2.

блин а вот сдесь я не вьезжаю, может мы на разные тесты смотрим, дайте плиз линк с 2 тестами ? а то я вижу тест от IBM где практически одинаковой железке Oracle боле производителен чем DB2.

Gt_

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, KisA, Вы писали:

KA>>Надеюсь окончательно всех запутал
M>О да..

KA>>REDO лог , т.е журнал доката в оракловской терминологии, который фактически является undo/redo логом.
M>Нет, REDO лог хранит только Redo информацию и действительно используется только для восстановления после сбоев, а undo информация хранится в rollback сегменте. И используется и для восстановления и для отката транзакций.

REDO лог содержит не только информацию доката но и информацию отката, запись в redo логе Oracle содержит информацию и о старом и о новом значении, т.е. это вроде классический undo/redo журнал, и зачем при востановлении еще и информация из rollback непонятно, но судя по доке она действительно используется, тут я был не прав.
Может ошибка в документации .
Из Oracle Concepts 8.1.7:

Each redo record contains both the old and the new values. Oracle also records the old value to a rollback block.
...
Among other things, the information in a rollback segment is used during database recovery to undo any uncommitted changes applied from the redo log to the datafiles.

M>Естественно, в случае восстановления после сбоя, ничто не мешает воспользоваться undo информацией из rollback сегмента.
Кроме того, что в случае сбоя её может не быть, ну не сбрасывается она на диск при фиксации транзакций, т.е. её саму надо восстанавливать. Отсюда у меня и сомнения по поводу её использования при восстановлении...
Опять же зачем в redo лог тогда пихать undo информацию, лишняя она там получается... непорядок...