> Вывод из статьи: "Oracle - хорошо, но DB2 - лучше".

Да, действительно, никакой шелухи ...

"In a more realistic environment where several concurrent transactions are
accessing the same data blocks, it would not be unusual to find 10 ITL slots
on each data page. That's 240 bytes on each data page wasted or 12% of all
data space (assuming 2k page for an OLTP system) space per transaction per page."


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


"If a table has a lot of concurrent transactions then it will use up more disk
space for transactions. In many applications there exits a set of hot records or
a hot table. So what happens if you have 1000 concurrent update transactions
on a small table?"

О боже, только представьте 1000 одновременных транзакций, пытающихся апдейтить пару сотен записей. Озадачиваясь вопросом "Что же произойдет", я надеюсь, что без раздачи пинков разработчикам дело не обойдется. Тут в консерватории править надо. Ну а DBA "размажет" эту таблицу по большему числу блоков. Ему ведь не жалко лишних пары-тройки метров на диске для "1000 томящихся пользователей".


"The problem with this algorithm is that while one transaction is sleeping,
another transaction can come in and get an ITL slot that was made available
while the first transaction was still sleeping. This means that there is no
guarantee that a transaction can acquire the lock it wants and locks are not
allocated to transactions in the order they are requested (i.e. a transaction can
jump in front of another transaction that has been waiting).
Highlights"

Здесь отметим скрытое лукавство. Нам не интересен порядок блокирования разных ресурсов (строк) разными транзакциями

"If multiple
applications try to lock the same record in exclusive mode (for update) then
DB2 creates a linked list of these lock requests (first come first served) in
memory. Multiple transactions may be sharing a lock at the same time, given
that they are both reading the record and not updating it. The linked list of
lock requests contains both transactions using the lock and those transactions
waiting for the lock.

Ребята видимо не в курсе, что Оракл также поддерживает связные списки блокировок и ресурсов.

"When a transaction is waiting on a lock it is actually
waiting on a semaphore (not on a sleep timer that Oracle uses).
like locks. When the first transaction on the list releases its lock, it removes itself from the lock chain and posts a message to the next transaction(s) in the sequence to allow the waiting transaction(s) to continue and take over ownership of that lock."

Зачем же так. В Oracle процесс, снимающий блокировку тоже постит следующему в очереди процессу с совместимым режимом блокировки.

"By default MAXLOCKS is set to 22% of the LOCKLIST so by default if one application acquires more than 22% of the locklist, DB2 will escalate. When a lock escalation occurs, the application holding the most locks (and therefore using up the most memory) will convert its row level locks to a table level lock, thus reducing memory requirements on the system."

Кто бы подсказал, что такое "application" в абзаце выше. И что произойдет в этом случае, возвращаясь к примеру "1000 одновременных транзакций, изменяющих данные таблицы".