"Может в Оракл и не дураки сидят, только вот microsoft тоже не идиотов набирает на работу."

Аргумент! Шедевр. Распечатал. Повесил в кубике. Дружбе крепнуть!

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql2k5snapshotisol.asp
Version store is held in memory and TempDB. The dba must ensure that TempDB is
optimized for increased i/o bandwidth based on the version store workload—TempDB
database size must also be monitored (especially if the application has long running
transactions), SQL Server has supported dba-friendly percentage and absolute
database and log autogrow settings for many releases, but these are obviously
constrained by the physical availability of disk space.

This can lead to long version chains in SQL Server. The version store keeps a full
copy of the data row that saves the expense of reconstructing the row when it is
accessed by another transaction.

The integrated SQL Server Agent event management and job scheduling sub-system
can be programmed to react automatically to an out of physical space condition and
corrective action (such as forcing rollback of any transaction contributing to version
store space usage).


Мне всегда было интересно, как в новой версии MS SQL Server a.k.a. Yukon
обстоит дело с обработкой длинных типов данных, как то, VARCHAR, CLOB, NCLOB
BLOB, LONG. Согласно тому что написано выше сервер с успехом может
копировать длинные строки в version store и заниматься этим всю оставшуюся
жизнь под сильной нагрузкой. Просто интересно.

Если там не написано вранья то для:

CREATE TABLE tbl(id NUMBER, dob DATE, firstname ..., lastname, ... photo BLOB, comments VARCHAR2(4000));

вот это:

UPDATE table
SET status = :status
WHERE id = :id
/

Скопирует в version store мою фотогеничный физиономию, все комментарии и
всю информацию из сегментов индексов для данной строки -- хотя я никого об
этом не просил.

Кто-то может подтвердить так ли это? Если это так, то на чём хочет выиграть MS?
На том что в Oracle дорого сделать cr? Или на том что версионирование в
Oracle заточено под производительность, а не под теорию (отсюда вся критика
уровней изоляции транзакций)? Или в том что в Oracle алгоритм update
многопроходный? Кто видел Yukon под живой hybrid нагрузкой с версионированием,
скажем 500-1000 oltp сессий, 10-20 batch processing тех же данных, и пусть до
10 какой-нибудь online аналитики (данные теже)?

Владимир БегунКто-то может подтвердить так ли это?
Дочиталось до "Upgrade Issues" -- там есть объяснение для LOB.
Для всех остальных типов данных, я так понимаю (нужно подтверждение),
будет копироваться вся строка со всеми вытекающими.

Вообщем-то, на мой взгляд, там ничего алгоритмически нового нет --
вроде бы найде-но наиболее эффективное решение для конкретной
реализации ядра (но не знаю MS SQL достаточно хоррошо чтобы судить
об этом). Можно только поблагодарить разработчиков ядра и сказать
что хорошо продумали как эффективно сделать версионирование в той
системе где его ждали очень много лет. С теоретической точки зрения
(из того что я увидел в этом документе) MS SQL будет решать вопросы
аномалий существующие в Oracle. Вопрос лишь в том, даст ли это
существенный выигрыш на практике при той реализации, которая была
выбрана?

Кто ответит на оставшиеся вопросы -- что показывают тесты?