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

заглянул на мсдн ... там грится что есть хинт rowlock который в принципе может, но типа по одной блокировать дорого и по дефолту сервер сам решает ! Т.е. майкрософт умный и сам решает и когда захочет может по пол таблицы заблокировать. Так что теперь я должен каждый раз приписывать rowlock ??? и чем мне это грозит на 10 млн записях ?
Да еще забавный пример там был, блокировка по диапозону индекса, типа мне не дадут вставить запись если кто-то в данный момент просматривает (залочел) этот дипазон индекса.
Это я что то недопонял или как раз за это ораклу и платят ?

теперь я понимаю почему разные весовые категории ...



допустим мне нужен read commeted уровень (совершено стандартно), т.е. про селекты забыли. апдейчу пару сотен записей - в результате неизвестно сколько у меня заблокируется ... как то не серьезно получается ...



ну во первых вы похоже даже не пытались посмотреть как это сделанно в оракле, но грубить пока не буду :) ... а факты ... ну надеюсь вы не хотите сказать, что оракловая реализация медленее ?
http://www.eweek.com/slideshow/0,3018,sid=0&s=1590&a=23120,00.asp

урл ? неверю (С) Станиславский :)

на самом деле мне как-то все равно как в той непонятной апликации они получили такие цифры. речь не о скорости, но если интересно могу накидать еще пару десятков линков различных "независимых" тестирований.

так вот может ли кто сдесь аргументировано опровергнуть:
мсскл получает близкие результаты с ораклом и дб2 за счет того что блокирует не на уровне записей, а на уровне целых страниц и таблиц.

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

Не понял про респонс тайм ... если я заблокировал пол таблицы то мне наверно всетаки проще с ней манипулировать, или нет ? ну да ладно речь не о том
урл ! где урл ? в декабре по слову блокировка ничего нет. ну и раз уж пошла такая пьянка тыкните в мсдн, а то я пока увидел 2-3 левых кента, настоятельно не рекомендующих таким заниматся из-за "эскалация блокировок". к стате, чо это такое ?
и еще где параметер который нужно выставить, чтоб каждый раз не писать хинт ?

Ну вот в чем главное различие:

Oracle never escalates locks. Lock escalation greatly increases the likelihood of deadlocks. Imagine the situation where the system is trying to escalate locks on behalf of transaction T1 but cannot because of the locks held by transaction T2. A deadlock is created if transaction T2 also requires lock escalation of the same data before it can proceed.

Что ж вас так задел этот тест ??? я его привел только для того чтоб показать что многие "независимые" считают, что оракл гораздо быстрее, похоже у вас другое мнение ... но как-то я больше доверяю сылкам :)
на шустрости :) так фокс и mysql думаю делают на порядок ... дело не в скоростях а способности решения задач.

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

Note The SQL Server query optimizer automatically makes the correct determination. It is recommended that table-level locking hints be used to change the default locking behavior only when necessary. Disallowing a locking level can affect concurrency adversely.

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

на счет мультиверсионости: каким образом тогда в мс можно получить какой либо отчет по таблице если в ней работает пара сотен юзеров (апдейтят записи), я так понимаю, что в этом случае ставятся блокировки и считать эти записи совсем нельзя ?

все похоже нашел все различия:
http://dbforums.com/arch/48/2002/5/392828" TARGET="_blank">http://dbforums.com/arch/48/2002/5/392828

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

просто стандартная ситуация:
каким образом тогда в мс можно получить какой либо отчет по таблице если в ней работает пара сотен юзеров (апдейтят записи), я так понимаю, что в этом случае ставятся блокировки и считать эти записи совсем нельзя ?

OK, с блокировками ясно, но тут еще услышал мнение, что у блокировочных и версионных бд свои достоинства и недостатки. траблы с блокировками - ясно, а в чем минус версионных ? жрут память ? скорость ? мсскл щас вроде на tcp.org и в нонкластеред лидирует.

Да что вы все, сговорились что-ли? А некто 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).