Да что вы все, сговорились что-ли? А некто Action и Gt не одно лицо случаем?
угу :) сговорились, правда не совсем одно но практически одно ...


> "не зная броду" можно очень легко привести базу в неконсистентное состояние.
Пример пожалуйста! Как это сделать в Oracle?

да у меня тоже чо то с фантазией туго ... можно пример ?

сейчас облазил ибм у них по этому поводу сказано лишь, что мы круче мсскл т.к. эскалацией можно управлять и дб2 быстрей оракла. оракл естественно грит, что версионник круче т.к. никто никого не ждет, но тактично молчит о скорости. ИМХО аргумент оракла пока красивей - смысл в скорости если база стоит ?
Т.е. клиенты получают отчеты через инет (много клиентов), им естественно нельзя сказать подождите и совсем нельзя давать им мешать операторам ... а как такого добится на дб2 ? надеятся, что клиенты будут успевать проскальзовать между блокировками как-то не серьозно ...

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

http://www-3.ibm.com/software/data/pubs/papers/readconsistency/readconsistency.pdf
^^^
наконец нашел внятный ответ, суть я так понял, медленно из-за лишних действий (что как бы проще посмотреть на tcp.org) и главное что юзер получает старые (неправильные) данные которые кто то уже меняет. однако потом они вспоминают про select for update и грят:

Note that this last example is the default behavior with DB2. That is, a
second transaction will wait for the first transaction to commit before it sees
changed data. That way you get current results not old results. If you do not
want to wait on a lock then there is the other ANSI standard isolation level
called uncommitted read which will see the current value of the data even if
that data is not yet committed.

т.е. юзая select for update я получаю те же уровни изоляции что и в дб2, но медленей (что сказывается на тяжелых OLPT ), а дб2 в свою очередь в ответ мультиверсионости предлагает грязное чтение.

я правильно понял ?

мда фокс тогда бы рулил, он знаешь скока могет :) всех интересуют данные, правильные данные, а скорость уже в последнюю очередь (после надежности и возможностей).

элементарно мы даем select и получаем разные ответы ! оракл по дефолту не будет ждать всех комитов, дб2 будет - в результате разные ответы на один запрос, это небходимо учитывать.

и все таки, я так и не понял как поступит дб2: select * на маленькую табличку которую круглосуточно апдейтят, т.е. в любой момент времени данные таблички модифицируются. То что менеждер блокировок там крутой, эт я уже слышал, меня интеречует как ? Стопорнет все апдейты и пропихнет селект ?
И еще, вебная апликуха - тысячи юзеров, все только читают и при этом получается блокируют, дальше кто то открыл карточку (заблокировал пару записей) и уснул ... что будет с вебными юзерами ?

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

ОК, с вебной криво, но блин я побозреваю, что такое наследство досталось не только мне ... тогда вот такой пример, как такое надо было правильно делать ? (п.с. пример ораклоида, в дб2 он врядле силен)


ok, say you have a 3 "page" or 3 block table. pretend there is 1 row / block.
assume the values are:

ACCT BALANCE ACCT_TYPE
---- ------- ---------
1 500 savings
2 100 savings
1 1000 checking


Obviously -- there is 1600 in the bank there right? Assume the following
operations and we are using the default DB2 isolation "read committed". What we
need to do is report back "how much money is in the bank". At the same time --
we need to process transactions

time operation by query operation by update
------ ------------------------- -----------------------
t1 start query, read block 1
running total = 500, while
reading -- we have a shared
read lock on the block

t2 account 1 pulls up to ATM
and tries to take 400 from
checking (block 1) but has to
wait -- query has block 1 shared
locked and we need it exclusive

t3 query finished with block 1, released
shared lock, moved onto block 2, running
total = 600

t4 we get exclusive lock on block 1
and change the value to 100.


t5 we are actually doing a transfer,
so now we get block 3 and add
400 to it. block 3 has an
exclusive lock on it.

t6 give up block 2, try to move onto
block 3. we cannot - so we wait...

t7 we commit -- releasing block 3

t8 move onto block 3, read 1400 -- add
to 600 and report back the answer
"there be 2,000 in the bank!", hmmm



There are other interesting scenarios -- say you want a consistent read -- a
correct answer. In db2 -- that is "repeatable read", they achieve that by
LEAVING the shared locks on as they read it. So, it the above timeline, the
query would have blocked the update until the query finished and committed.
Given that block 2 really could represent a TON of blocks in the example, that
could be a while (no atm transactions for you)... Or even better if the data
were organized:

ACCT BALANCE ACCT_TYPE
---- ------- ---------
1 1000 checking
2 100 savings
1 500 savings


now what happens is:

query starts -- gets and keeps shared lock on block 1 (1000,checking). Update
starts -- gets x-lock on block 3 (500,savings -- updated to 100,savings) and
keeps it.

query keeps running....

update tries to get block 1 but cannot, query has it locked. update blocks.

query runs and gets to block 3, cannot get a shared lock.

We now have a deadlock. In order to get the right answer, we had to lock, but
by locking -- we deadlock. catch 22 -- what do we do?


This is why db2 supports dirty read (forget about locks, what a waste of time
right? who cares if you get the right answer, just blow through them).