Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 13   вперед  Ctrl
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo!!
а по dual-core все верно, у стандарт ван эксепшен, т.е. 2-way dual-core opteron + 8Gb RAM будет ровно в 4 раза дешевле чем у сиквела.


Согласен, что Oracle Database 10g Standard Edition One - "заманчивая" редакция. ;)
26 сен 05, 11:44    [1909124]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
pkarklin

Согласен, что Oracle Database 10g Standard Edition One - "заманчивая" редакция. ;)


все таки наврал я - dual-core не считается для стандарт и стандарт one только если проц один, т.е. если 2 dual-core то уже нада платить за все ядра, т.е. $1.5K
26 сен 05, 11:52    [1909176]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 Yo!!

Ответьте на чайниковский вопрос в Oracle под *NIX системами. Он сразу ставиться в 64-битной редакции дабы более 4 гиг памяти юзать?
26 сен 05, 12:52    [1909547]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!!
ggv

Дык как раз решает, но вы как раз и не поняли.

По другому - создаем сегмент отката (snapshot данных), работаем с ним, а потом сливаем изминения в основные данные. Только здесь уже можно не только "кто первый встал того и тапки", а более гибко.
Полная эмуляция поведения версионника - на блокировочниках, где такое реализовано, само собой. Будет и OLTP - короткие задачи - будут и длинные транзакции в то же время.
Разруха она в головах.
Ну теперь точно до понедельника, на транспорт опаздываю.


да, похоже не понял. итак у нас 2 транзакции одновременно, первая читает майнтабле и пихает в темп, вторая ничерта не ждет и делает тоже самое читая те же данные, первая делает merge в майнтабле, вторая делает тоже самое, затирая все изменения первой транзакции.
в чем фишка ?


Да в том то и фишка, что получается поведение версионника. Только не обязательно перезатирает последующая транзакция изменения предыдущей - если посмотреть на синтаксис MERGE sql statement ---

>>-MERGE INTO--+-table-name-------+----------------------------->
+-view-name--------+
'-(--fullselect-- )-'

>--+------------------------+--USING--table-reference----------->
'-| correlation-clause | -'

>--ON--search-condition----------------------------------------->

.--------------------------------------------------------------------.
V |
>----WHEN--| matching-condition |--THEN--+-| modification-operation |-+-+-->
'-signal-statement-----------'

.-ELSE IGNORE-.
>--+-------------+---------------------------------------------><

То есть краткий вывод - с помощью SQL STATEMET MERGE можно сделать в блокировочнике поведение транзакций аналогичное версионнику, если нужно.
Другой вопрос, что я в своей практической деятельности такой необходимости пока не встречал (я не говорю, что MERGE не использовал)
26 сен 05, 13:44    [1909911]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2ggv

что значит необязательно ? обязательно, отвлекитесь от вашего merge это просто синтетический прибамбас (к стате и в оракле он давно).
еще раз у вас 2 транзакции:
t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge

и получаете обязательный lost update, ничего похожего на версионный механизм тут нет.
26 сен 05, 15:03    [1910278]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
pkarklin
2 Yo!!

Ответьте на чайниковский вопрос в Oracle под *NIX системами. Он сразу ставиться в 64-битной редакции дабы более 4 гиг памяти юзать?


зависит от юниха, кажется у сана были 32-битные спарки и наверно был оракл 32-бит для спарка. т.е. если юних 64-бит то и все ПО на нем 64-бит (и оракл в том числе) исключение линух для amd64, на нем можно и 32-бит поставить.
26 сен 05, 15:11    [1910321]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!!
2ggv

что значит необязательно ? обязательно, отвлекитесь от вашего merge это просто синтетический прибамбас (к стате и в оракле он давно).
еще раз у вас 2 транзакции:
t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge

и получаете обязательный lost update, ничего похожего на версионный механизм тут нет.


Ну немного непонятно, разные temptable или одна, думаю таки разные.
И непроставлены COMMIT, из-за чего непонятно, если предположить, что COMMIT будет после каждого MERGE - как поведет себя версионник, не перезапишет изменения предыдущей транзакции?
26 сен 05, 15:57    [1910628]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
ggv

Ну немного непонятно, разные temptable или одна, думаю таки разные.
И непроставлены COMMIT, из-за чего непонятно, если предположить, что COMMIT будет после каждого MERGE - как поведет себя версионник, не перезапишет изменения предыдущей транзакции?


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

ЗЫ. у оракла есть выражение select ... for update если вам интересно как можно избежать lost update в подобной вашей ситуации.
26 сен 05, 16:32    [1910847]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo - да нет, не надо мне пояснять, что такое версионник.
Я просто смею утверждать, что описанными мной способом мы можем получить поведение версионника на блокировочнике, конкретно db2.
И схема очень простая и понятная.
Да, верно, в версионнике не надо временных таблиц в таком случае, в блокировочнике надо.
И вся разница.
И читатели также получат консистентный отчут (хотя, не всегда такое надо, но надо в ситуации repeatable read, хотя как я уже говорил, в бизнесе я таких потребностей не видел)
Далее, мне нисколько не интересно про select for update в оракле, и я про это не спрашивал.
Повторю - я просто показал, как в блокировочнике сделать поведение версионника - то есть создать snapshot данных, и объеденить его с основными данными.
И это работает, хоть вам это и непонятно.
26 сен 05, 16:39    [1910891]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2ggv
>И это работает, хоть вам это и непонятно.
вопервых не работает во вторых нисколько не похоже на snapshot. попробую в 3й раз:

t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge
t5. транзакция1 commit
t6. транзакция1 commit

что вы полчите в результате ? - потеряный апдейт.
сможете ли вы получить консистентный отчет на момент t5 ? - нет.

схема действительно простая но совершенно непохожа на snapshot.
26 сен 05, 17:01    [1911014]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
t6. транзакция1 commit
имелось ввиду
t6. транзакция2 commit
26 сен 05, 17:03    [1911026]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну после commit в t5 получить отчет - я не понял вопрос.
Лучше скажите, что произойдет на шаге t6 в версионнике?
26 сен 05, 17:22    [1911116]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
>ну после commit в t5 получить отчет - я не понял вопрос.

t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge
t5. транзакция1 commit
t5.1 транзакция3 длинный select * from maintable
t6. транзакция2 commit

вот тут шансов что транзакция3 "застанет" данные от транзакции1 почти нет.

>Лучше скажите, что произойдет на шаге t6 в версионнике?
в oracle это будет выглядеть вот так:
t1. транзакция1 update maintable
t2. транзакция2 update maintable
^^^^^^
ORA-00054: resource busy
t3. транзакция1 commit;
и все !


но если вас интеоресует именно такой вариант как вы делаете в дб2 то выглядел бы он так:

t1. транзакция1 insert into temptable select * from maintable for update nowait ;
t2. транзакция2 insert into temptable select * from maintable fro update nowait;
^^^^^^^^
ORA-00054: resource busy and acquire with NOWAIT specified
t3. транзакция1 merge
t4. транзакция1 commit
26 сен 05, 17:34    [1911155]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!!
>ну после commit в t5 получить отчет - я не понял вопрос.

t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge
t5. транзакция1 commit
t5.1 транзакция3 длинный select * from maintable
t6. транзакция2 commit

вот тут шансов что транзакция3 "застанет" данные от транзакции1 почти нет.

100% в описаной ситуации транзакция3 получит все закомиченные данные транзакции1


>Лучше скажите, что произойдет на шаге t6 в версионнике?
в oracle это будет выглядеть вот так:
t1. транзакция1 update maintable
t2. транзакция2 update maintable
^^^^^^
ORA-00054: resource busy
t3. транзакция1 commit;
и все !


но если вас интеоресует именно такой вариант как вы делаете в дб2 то выглядел бы он так:

t1. транзакция1 insert into temptable select * from maintable for update nowait ;
t2. транзакция2 insert into temptable select * from maintable fro update nowait;
^^^^^^^^
ORA-00054: resource busy and acquire with NOWAIT specified
t3. транзакция1 merge
t4. транзакция1 commit


То есть вы хотите сказать, что после того, как транзакци1 один сделала COMMIT, а затем делает транзакция2 COMMIT , то транзакция2 получит отлуп???
Очень интересно, но нафиг не надо.
Наверняка вы что-то не то хотели сказать.
Еще раз ---- с помощью конкретного дилаекта MERGE можно получить поведение версионника - транзакция получит свой снапшот данных консистентных, сможет работать с ним, и до выполнения MERGE (у версионника это просто COMMIT во время которого выполняется слияние данных) никто не сможет получить доступ к этим данным.
Если пойдут более одного MERGE одновременно в разных транзакциях, они будут сериализоваться - блокировками, и выполнятся последовательно.
Эта часть понятна, надеюсь?
26 сен 05, 17:56    [1911242]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
автор
100% в описаной ситуации транзакция3 получит все закомиченные данные транзакции1

втом то и дело что получит все, а не закомиченые на момент t5.1 как нужно для консистентного отчета.

автор
Еще раз ---- с помощью конкретного дилаекта MERGE можно получить поведение версионника


тогда давайте разбиратся что такое merge, у оракла (да и в стандарте 99 кажется ) это просто синтаксическая фича, если запись есть то делется update .. set value=new_value, если записи нет то делается insert into .. values (new_value)
и все. неужеле в дб2 это что то другое ??
если нет то попробуйте расписать без merge такой код:

транзакция1 update maintable set value=value+5 ;
транзакция2 update maintable set value=value+5 ;
транзакция1 commit ;
транзакция2 commit ;
26 сен 05, 18:30    [1911403]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!!
автор
100% в описаной ситуации транзакция3 получит все закомиченные данные транзакции1

втом то и дело что получит все, а не закомиченые на момент t5.1 как нужно для консистентного отчета.

Ничего себе - транзакция1 сделала COMMIT, после этого транзакци3 делает SELECT, и она не должна получить все данные? Она получит и то, что внесла/изменила транзакция1, и то, чего транзакция1 не трогала. Иначе бардак какой-то.

Yo!!

[quot автор]Еще раз ---- с помощью конкретного дилаекта MERGE можно получить поведение версионника [/quot автор]

тогда давайте разбиратся что такое merge, у оракла (да и в стандарте 99 кажется ) это просто синтаксическая фича, если запись есть то делется update .. set value=new_value, если записи нет то делается insert into .. values (new_value)
и все. неужеле в дб2 это что то другое ??
если нет то попробуйте расписать без merge такой код:

транзакция1 update maintable set value=value+5 ;
транзакция2 update maintable set value=value+5 ;
транзакция1 commit ;
транзакция2 commit ;


Дак я же говорю, что для получения поведения версионника необходимо использовать конкретную реализацию sql statement MERGE.
Зачем мне пробовать расписать без MERGE, если тогда я не получу такого поведения??
26 сен 05, 18:43    [1911433]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
автор
Ничего себе - транзакция1 сделала COMMIT, после этого транзакци3 делает SELECT, и она не должна получить все данные? Она получит и то, что внесла/изменила транзакция1, и то, чего транзакция1 не трогала. Иначе бардак какой-то.


как только транзакция1 сделала COMMIT, транзакция2 заблокирует данные и транзакция3 будет ждать пока вторая не закомитится. поэтому этот селект никогда не получит отчет на момент t5.1

автор

Зачем мне пробовать расписать без MERGE, если тогда я не получу такого поведения??


потому что MERGE это всего лишь обыкновенный update в нашем случае и никакой магии не привнесет.
если table.value=0 и идет 2 транзакции одновременно:
t1.транзакция1 insert into temptable select value+5 from table
t1.транзакция2 insert into temptable select value+5 from table
t2.транзакция1 merge
t3.транзакция2 merge
t4.транзакция1 commit
t5.транзакция2 commit

у вас в темтабле будет по 5рке и merge просто заместит table.value пятерками из temptable два раза, т.е. в результате в table.value будет 5 вместо 10, что есть страшный косяк.
26 сен 05, 19:08    [1911485]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!!
автор
Ничего себе - транзакция1 сделала COMMIT, после этого транзакци3 делает SELECT, и она не должна получить все данные? Она получит и то, что внесла/изменила транзакция1, и то, чего транзакция1 не трогала. Иначе бардак какой-то.


как только транзакция1 сделала COMMIT, транзакция2 заблокирует данные и транзакция3 будет ждать пока вторая не закомитится. поэтому этот селект никогда не получит отчет на момент t5.1

Полная неправда. В описанной вами ситуации, и с предложенной мной схемой - получит.
Yo!!

автор

Зачем мне пробовать расписать без MERGE, если тогда я не получу такого поведения??


потому что MERGE это всего лишь обыкновенный update в нашем случае и никакой магии не привнесет.
если table.value=0 и идет 2 транзакции одновременно:
t1.транзакция1 insert into temptable select value+5 from table
t1.транзакция2 insert into temptable select value+5 from table
t2.транзакция1 merge
t3.транзакция2 merge
t4.транзакция1 commit
t5.транзакция2 commit

у вас в темтабле будет по 5рке и merge просто заместит table.value пятерками из temptable два раза, т.е. в результате в table.value будет 5 вместо 10, что есть страшный косяк.


Страшный косяк?? Интересно - изменения данных выполнялись изолированно, в своих собственных копиях данных, стало быть value в обеих копиях данных был увеличен на 5 и стал равен 5, затем первая транзакция слила данные во вторую таблицу и закоммитила, после чего вторая транзакция слила данные и закомитила - с чего бы вдруг в основной таблице возникло 10?
Может, поясните логику, откуда в описанной ситуации возьмется 10?
И второе - я предлагал немного другой способ - insert into <temptable> select * from <maintable> where <search condition>,
и только после этого update <temptable> c последующим MERGE.
Но очень хочется понять, с чего в основной таблице value должен будет увеличиться дважды, то есть стать равен 10 (+5 в первой транзакции, в изолированном наборе данных, и +5 во второй транзакции, в ее и изолированном наборе данных)
26 сен 05, 19:29    [1911527]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
автор
Полная неправда. В описанной вами ситуации, и с предложенной мной схемой - получит.

чем докажешь :)

автор

Интересно - изменения данных выполнялись изолированно, в своих собственных копиях данных


тут на самом деле у меня косяк, при таком раскладе как раз будет все правильно 10 ! insert into наложит блокировку на table и транзакция2 пойдет только после того как первая закомитится. но вы же пытаетесь избавится от блокировки на table, поэтому в одной транзакции это сделать не сможете и прейдется так:

t1.транзакция1 insert into temptable select value+5 from table
t1.транзакция2 insert into temptable select value+5 from table
t2.транзакция1 commit (temptable.value=5)
t3.транзакция2 commit (temptable.value=5)
t4.транзакция1 merge (по сути update из temptable)
t5.транзакция2 merge (по сути update из temptable)
t6.транзакция1 commit
t7.транзакция2 commit
26 сен 05, 19:55    [1911573]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
так, похоже нада завязывать с пивом.
автор
И второе - я предлагал немного другой способ - insert into <temptable> select * from <maintable> where <search condition>,
и только после этого update <temptable> c последующим MERGE.

это же ничем не отличается от прямого update. допустим у нас есть длинная читающая транзакция (отчет) на 15 минут. чтоб это селект получил согласованый отчет он должен заблокировать все таблицы откуда читает и не важно чем вы будете в них пытатся записать, merge или update все остальные транзакции у вас будут ждать пока этот селект не соизволит закончится.
26 сен 05, 23:18    [1911871]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
таак, Yo!!, действительно, с пивом надо завяязывать :)
Давайте сначала.
1) в блокировочнике db2 писатель не блокирует читателя безо всякого Uncomited Read. Это дело управляется тремя переменными (отдельно на insert, update и delete). То есть набором значений трех переменных для трех случаев можно добиваться нужного поведения. Гибко, но когда нужна такая гибкость я не знаю, может кому и нужна. В oracle для этого никаких переменных не надо, но и изменить поведение видимо нельзя, да еще так гибко.
То есть любая транзакция получит свой набор данных несмотря на незакомиченные транзакции писателей. И все это безо всяческих сегментов откада, очень дешевым и производительным способом. Эти конфигурационные параметры действуют на момент компиляции запроса, что позволяет (используя static SQL) иметь разное поведение в паралельных транзакциях в один и тот же момент времени.
2) Если получив в предыдущем случае данные, транзакция поместит их во временную таблицу, то может гонять курсор туда/обратно сколько ей угодно и абсолютно изолировано,и данные консистентны на момент начала транзакции. Этакий сегмент отката, или снапшот данных. Но этот случай мало интересен, а вот когда транзакция начнет менять данные
3) то она превращается в писателя, и на своем изолированном снапшоте данных делает изменения сколь угодно долго. Для слияния своих изменений с основной копией данных транзакция должна вызвать MERGE; COMMIT
В Oracle для этого просто COMMIT.

Получается, что в блокировочнике db2 для получения эффекта версионника надо больше sql предложений, и более тщательное планирование транзакций при дизайне приложений.
Но при этом достигается более высокая производительность за счет того, что не база, а разработчик транзакций определяет, когда надо создавать изолированный набор данных, и более гибко регулируемое поведение (если оно только кому надо)

А теперь я таки хочу понять, почему при начальном значении в таблице value==0 и после того, как две транзакции изолированно выполнят value+=5, потом сольют изменения в основную таблицу --- откуда возьмется 10???
27 сен 05, 09:48    [1912300]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2ggv
так, давайте договоримся что речь идет о UL SERIALIZABLE. т.к. на READ COMMITED у блокировочника совсем ничего не получится.
на уровне SERIALIZABLE селект наложит (shared наверно) блокировку до конца своей транзакции и соответственно пока она будет "гонять курсор туда/обратно" остальные писатели пойдут курить.

автор
А теперь я таки хочу понять, почему при начальном значении в таблице value==0 и после того, как две транзакции изолированно выполнят value+=5, потом сольют изменения в основную таблицу --- откуда возьмется 10???


потому что первый селект наложит блокировку до конца транзакции (на уровне SERIALIZABLE)
27 сен 05, 10:30    [1912535]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!! еще раз, внимательно
в пункте 1) благодаря трем конфигурационным параметрам db2 писатель не блокирует читателя
в пункте 2) ясно сказано, что читатель, получивший набор согласованных данных в пункте 1) и выгрузивший их во временную таблицу может гонят курсоры сколько угодно на изолированном наборе данных полученных в пункте 1) и никак не влияя на другие транзакции.

Что непонятного?
Или так противно признать, что блокировочник может иметь сходное поведение с версионником, но достигнутое более производительным путем (но требуя более тщательного дизайна транзакций)?

Я попробую запросить ресурс на публично доступную тестовую db2, и если будет желание, все сказанное мной можно будет вжимвую посмотреть.
Быстрее будет встретится в москве и на моем ноуте показать, но если есть время подождать, то можно и на доступном в инете db2
27 сен 05, 10:38    [1912582]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
автор
в пункте 1) благодаря трем конфигурационным параметрам db2 писатель не блокирует читателя

это что за конфигурационые параметры ??? грязное чтение ?

итак ваша чудо мысль:
автор
И второе - я предлагал немного другой способ - insert into <temptable> select * from <maintable> where <search condition>,
и только после этого update <temptable> c последующим MERGE.


предположим у нас идет поток таких транзакций и нам нужен длинный кончичтентный отчет где участвует maintable тоже, это сделать мы можем лишь на уровне SERIALIZABLE. что делает этот отчет ? накладывает shared блокировку на всю maintable на время всей транзакции. и не важно что у вас там update, merge или сам дьявол, но блокировку на update уже никто не поставит, ни при каких условиях. и будет у вас стоять поток ваших транзакций и смысла ваша схема никакого не имеет.
27 сен 05, 11:23    [1912890]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
давайте немного кода чтоб было понятнее (у меня есть только yukon beta2)
(все делаем SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ;)
create table maintable (a int) ;
 DECLARE @I INT

 SET @I = 0

 WHILE @I < 1000 BEGIN
INSERT MAINTABLE (A) VALUES (@I)
SET @I = @I + 1
END
GO
COMMIT;
GO

берем первую транзакцию:
create table temptable (a int) ;
begin tran
insert into temptable select a from maintable ;
(транзакция у нас не закончилась)
берем вторую

begin tran
update maintable set a=20 where a=1 ;
как и положено на SERIALIZABLE вторая транзакция висит.
27 сен 05, 11:37    [1912990]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить