Хотел бы поддержать Genady. Блокировать все по максимуму означает превратить БД в однопользовательскую. Напротив, не имеет смысла ставить блокировки уровня записи в ситуации, когда один юзер работает с таблицей из миллиарда строк. Не знаю, сколько занимает структура типа lock resource block в Oracle, в SQL Server - 64 байта. Ну и зачем менеджеру блокировок в этом случае сжирать под себя 64 гиг, если проще проэскалировать? Не знаю, я считаю, что автоматическое управление гранулярностью блокирования является единственным разумным механизмом, позволяющим добиться компромисса между приемлемой конкурентностью доступа и системными затратами на его обеспечение.

Извините, killed, но по-моему Вы путаете lock resource block c lock owner block. С Вашего позволения, я оперирую в рамках терминологии SQL Server, но смысл, думаю, понятен. Как можно в 24 байта уместить информацию о сотне (как Вы говорите) заблокированных строк? 24 * 8 = 192 бита. Ну пусть по два бита на запись. Один, допустим, выступает флажком, что запись заблокирована. Как в один оставшийся бит уместить бездну информации о lock mode (S, U, X, ...), статусе (грантована, конвертируется, ждет), пойнтер данной записи и многое другое?

2noir
"Запись в строчку у которой есть версии более новые, чем та, которую "видит" данная транзакция приводит к откату"
Не понял. Я взял себе снэпшот, работал с ним, работал. Потом говорю - commit. А он в ответ - фиг, потому что там уже кто-то успел сделать более свежую версию. И все, что я в нем наменял, псу под хвост?

2killed
Ага, Вы говорите о том, что в хидере блока (страницы в терминологии MS SQL) Oracle хранит дополнительную информацию о блокированных записях, расположенных внутри данного блока и утверждаете, что ее объем меньше той цифры, которую я привел. Но SQL Server вообще не держит информации о блокировках на страницах данных. Те 64 байта - это чисто in-memory structure. Т.е. то, про что Вы применительно к Oracle говорите "Вся остальная информация хранится в памяти в виде массивов фиксированной длины и интенсивно переиспользуется". Таким образом, Oracle просто разделяет информацию о блокировках и держит ее в двух местах: в памяти и на страницах данных. Я думаю, что это обусловлено чисто историческими причинами. Ведь Oracle появился гораздо раньше, а при тогдашних объемах оперативки другого решения, наверно, не было. Но это очень плохо. Потому что каждая операция блокировки потенциально вызывает дополнительные затраты на disk I/O и получается медленнее, чем в SQL Server. Если же подсчитать суммарный размер информации о блокировке записи - неважно, где она хранится (в памяти, на диске, и там и там), то, вероятно, мы получим примерно схожие цифры что в SQL Server, что в Oracle, что в Sybase, что DB2 и т.д. Вы говорите "У Oracle этих проблем нет, а про уровни изоляции, сериализацию и пр. помнят только люди, имевшие опыт работы с другими системами". Это неверно. Во всех перечисленных серверах в той или иной степени продекларирована поддержка стандарта ANSI SQL. Стало быть, они должны обеспечивать и стандартные уровни изоляции, и все остальное, что прописано в стандарте по этому поводу. А это значит, что с точностью до плюс/минус пары байт размер информации о блокированном ресурсе будет везде примерно одинаков, как бы вы ни хитрили, разбивая ее на куски и упрятывая их в хидер строки, в ITL-слоты, в описание транзакции, в сегменты отмены и т.д.
Кстати, я обратил внимание, что первоначально топик был посвящен Sybase, а сейчас все свелось к обсуждению архитектурных различий MS SQL и Oracle. Как-то неудобно. Может, переместимся в новый топик?