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

Откуда:
Сообщений: 9365
Боюсь, Вы не очень хорошо представляете себе что такое версионность.
Возможность пропускать заблокированные строки иногда полезна, у Oracle кстати есть подобная недокументированная фича для реализации AQ, но она ничем не поможет скажем в аналитике, там должны быть ВСЕ данные, включая заблокированные и очень желательно в конситентном состоянии.
27 сен 05, 14:14    [1914060]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Gluk, да нет, представляю.
Так же представляю, как ibm добивается результатов в tpc-h, зачем делает средства online пополнения хранилища из оперативных источников, и прочее.
Озвученый мной функционал предназначен для повышения "пропускной" возможности транзакций, аналитика и ibm'овские аналитический продукты предполагается использовать на хранилищах, классический референс дойч телеком, у них же и пополнение онлайновое хранилища.
27 сен 05, 15:08    [1914381]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
ggv
Так вот конкретный диалект SQL позволяет мне в этой ситуации получить поведение версионника на блокировочнике.
insert into <temptable> select from <maintable>
затем все нужные изменения в <temptable>, и в конце
merge into <maintable>


Yo!!
честно говоря совсем не понял. на время модификации нужна блокировка именно основной записи иначе у вас 2 update смогут одновременно типа править одну и туже запись и получите lost update.
ну и имхо это все равно не решает главную проблему блокировочника - длинные транзакции в OLPT задаче.


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


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


ggv
Дополняю - речь идет о Cursor Stability,или Read Stability
Параметры называются Scip_inserted, scip_deleted, evaluate_uncomited


ggv
Начал, правда, с конца, ошибочно полагая что всем известны возможности db2 де-факто, и не надо пояснять про scip_[inserted/deleted] и evaluate_uncommited.
Повторю лишь, что главный эффект этих фич - устранение эффекта ожидания транзакций и повышение concurency.
И эффект достигнут.


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

2ggv
давайте вы определитесь у вас или "поведение версионника на блокировочнике" или какя-то опускная способность.
если версионика то таки пояснить кодом, а то мы люди маленькие и не образованые, в дойч телекоме небыли и не понимаем КАК вы на IL Cursor Stability можете "получить поведение версионника на блокировочнике" ?
27 сен 05, 15:55    [1914709]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ggv
Gluk, да нет, представляю.
Так же представляю, как ibm добивается результатов в tpc-h, зачем делает


А это то при чем. Вроде речь шла о серебрянной пуле, которую Вы обнаружили, а именно эмуляции версионника на DB2. А тут TPC-H появляются зачем-то Слов нет DB2 вещч хорошая, ктож спорит ? Но это блокировочник.
27 сен 05, 16:15    [1914863]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Gluk - это я к тому упомянул, что несмотря на то, что в некоторых случаях дб2 ведет себя как полный версионник (случай с insert) то в целом это не делает db2 версионником, и для целей анализа боле целесообразно строить отдельные хранилища, а не делают аналитику на операционной базе.
Правда, сомневаюсь, что гонять аналитику на операционной базе версионника тоже целесообразно.
Так что только в этом контекте. Их хоть в дойчланде я тоже не бывал, но читал, как они онлайново скармливают данные из операционних баз в хранилище.
О серебряной пуле речи небыло - а вот об эмуляции поведения версионника - была. Особенно в части неблокируемого чтения.
Gluk - так более понятно?
27 сен 05, 18:43    [1915711]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Не было никакой эмуляции версионника, поскольку эмуляция поведения версионника отдельно на insert-ах МАРАЗМ. Так более понятно ?
28 сен 05, 08:40    [1916515]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну для вас лично маразм.
Но если смотреть с той точки зрения, что писатель не блокирует читателя, и как это использовать, то это уже не маразм.
Так более понятно?
28 сен 05, 09:33    [1916634]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пропуск заблокированных записей это как правило не то что подразумевается под: "писатель не блокирует читателя"
28 сен 05, 09:52    [1916705]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
DimaR
Member

Откуда:
Сообщений: 1570
to ggv

я с Gluk (Kazan) полностью согласен, к тому же,
ИМХО концептуально разное поведение сервера при разных его настройках, это действительно маразм (то же самое касательно юкона с его эмуляцией версионности).
28 сен 05, 10:06    [1916782]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
с его эмуляцией версионности


Неудачный оборот речи. Версионность там честная но ОПЦИОНАЛЬНАЯ. Сейчас прибегут SQL-щики и будут сильно ругаться
28 сен 05, 10:11    [1916809]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну скорее всего, понятие маразма получается в данном случае сугубо субъективное.
На то они и настройки, чтобы поведение менять. Я в других топиках тоже писал о маразматических поведениях конкретно RAC, но тот же Yo!! был со мной сильно несогласен.
может, пример и неудачный, но суть, кажется, я выразил.
28 сен 05, 11:16    [1917155]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Gluk (Kazan)
автор
с его эмуляцией версионности


Неудачный оборот речи. Версионность там честная но ОПЦИОНАЛЬНАЯ. Сейчас прибегут SQL-щики и будут сильно ругаться


Извиняюсь, случайно вырвалось :)
28 сен 05, 11:19    [1917173]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
SkyNet77
Guest
Как я понимаю, при CS мы получим все закоммиченные данные на время начала запроса t1?
Версионности нету, значит во время t2 мы получим совершенно другие данные.
Так ведь?
5 окт 05, 13:01    [1940108]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
SkyNet77
Как я понимаю, при CS мы получим все закоммиченные данные на время начала запроса t1?
Версионности нету, значит во время t2 мы получим совершенно другие данные.
Так ведь?

где?
5 окт 05, 13:04    [1940121]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
Ну в блокировочнике, как ведет себя Oracle я знаю
5 окт 05, 13:21    [1940229]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
Калина
Ну в блокировочнике, как ведет себя Oracle я знаю

в дб2 при cursor stability селект просто все блокирует и проблем с консистентностью у него никаких нет :) они у остальных писателей ...
5 окт 05, 13:26    [1940259]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
SkyNet77
Guest
но другие сессии при нужных настройках могут читать, так ведь?
5 окт 05, 14:26    [1940586]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
SkyNet77
но другие сессии при нужных настройках могут читать, так ведь?

у блокировочников столько видов блокировок что я потерялся, думаю при чтении ставится shared блокировка которая позволяет читать но не дает изменять. т.е. длинная такая транзакция - смерть OLPT и вариант от ggv ничего не решает.
5 окт 05, 14:51    [1940731]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Yo!!
SkyNet77
но другие сессии при нужных настройках могут читать, так ведь?

у блокировочников столько видов блокировок что я потерялся, думаю при чтении ставится shared блокировка которая позволяет читать но не дает изменять. т.е. длинная такая транзакция - смерть OLPT и вариант от ggv ничего не решает.


Дорогой ЙО!! CS - это Cursor Stablity. Это значит что во время select * from sometable , будет блокирована только 1 (одна) запись в sometable. Т.е. блокируется далеко не всё. Дополнительная фича возникакет когда стоит SKIP_INSERTED(YES) и SKIP_DELETED(YES). Тогда select удаленные и добавленные записи просто не заметит в процессе выполнения.
Если будет стоять SKIP_INSERTED(NO) и SKIP_DELETED(NO) - то select заткнется на первой же добавленной или удаленной но незакомиченной записи.

Хуже будет если в процессе работы встретится запись которая была обновлена. Тогда затык обеспечен, если не стоит SKIP_UNCOMMITED(YES).
А если стоит SKIP_UNCOMMITED(YES), то обновленную запись select проскочит не заметив.

Дорогой ЙО!! Вы абсолютно правы в том, что эмулировать версионность не имея сегментов отката на блокировочнике - невозможно. Можно разве что улучшить характеристики системы. Однако с другой стороны, не будем забывать того, что длинные транзакции в версионниках связаны с тем, что необходимо данные для отката хранить на диске, и не только их но и инфу о блокировках. Поэтому в реальных системах с ОЛТП Оракл будет выигрывать в быстродействии по сравнению с блокировочником только в том случае, если ему дать раза в два-три шире канал для дискового ввода-вывода. Интенсивный ОЛТП - это прежде всего работа с диском. Тут Оракл пролетает. Сожалею.
Кстати, SKIP_INSERTED/SKIP_DELETED - не единственная фича в DB2 которая позволяет значительно повысить производительность.
5 окт 05, 15:49    [1941076]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
Ув. gardenman, вы заблуждаетесь, на уровне CS ставится лок именно до конца транзакции:

READ COMMITTED (DB2 UDB: Cursor Stability)

The entire table is locked. Shared locks are released when the associated cursors are closed (isolation levels higher than READ COMMITTED hold shared locks until the end of a transaction). Exclusive locks are held until the end of the transaction.

No other application can perform any DML operation on a table while an open cursor is accessing it. READ COMMITTED applications cannot see uncommitted changes of other applications.

Both nonrepeatable reads and phantom reads are possible. READ COMMITTED is the default isolation level, allowing maximum concurrency while seeing only committed rows from other applications.

http://publib.boulder.ibm.com/infocenter/weahelp/5.1/index.jsp?topic=/com.ibm.websphere.db2e.doc/db2e_iso_levels.html
5 окт 05, 16:14    [1941224]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
извиняюсь не транзакции, а пока курсор открыт
5 окт 05, 16:17    [1941244]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
gardenman

Поэтому в реальных системах с ОЛТП Оракл будет выигрывать в быстродействии по сравнению с блокировочником только в том случае, если ему дать раза в два-три шире канал для дискового ввода-вывода. Интенсивный ОЛТП - это прежде всего работа с диском. Тут Оракл пролетает. Сожалею.


и тут вы заблуждаетесь тоже. OLPT это не тольк и не сколько работа с диском. на примерно одинаковом железе оракл в OLPT показывает результаты не хуже дб2, а местами лучше.
5 окт 05, 16:26    [1941297]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
gardenman
Дорогой ЙО!! Вы абсолютно правы в том, что эмулировать версионность не имея сегментов отката на блокировочнике - невозможно. Можно разве что улучшить характеристики системы. Однако с другой стороны, не будем забывать того, что длинные транзакции в версионниках связаны с тем, что необходимо данные для отката хранить на диске, и не только их но и инфу о блокировках. Поэтому в реальных системах с ОЛТП Оракл будет выигрывать в быстродействии по сравнению с блокировочником только в том случае, если ему дать раза в два-три шире канал для дискового ввода-вывода. Интенсивный ОЛТП - это прежде всего работа с диском. Тут Оракл пролетает. Сожалею.
Кстати, SKIP_INSERTED/SKIP_DELETED - не единственная фича в DB2 которая позволяет значительно повысить производительность.


Есть одно НО. Реальные системы ОЧЕНЬ редко бывают ЧИСТЫМИ OLTP :)
Фичи конечно полезные, но точно так-же адепты MS SQL сейчас начнут доказывать, что для обеспечения ВЫСОКОЙ производительности OLTP и возможности одновременной проооостенькой аналитики ИСКЛЮЧИТЕЛЬНО полезна такая фича, как ГРЯЗНОЕ ЧТЕНИЕ SKIP_INSERTED/SKIP_DELETED сию фичу весьма напоминает, а непротиворечивость отчетов стоит небольших издержек на обеспечение версионности.
К тому-же, почувствуйте разницу: Производители DB2 и MSSQL советуют делать транзакции КАК МОЖНО БОЛЕЕ КОРОТКИМИ, а производители Oracle, советуют определять транзакции исходя из ТРЕБОВАНИЙ БИЗНЕС-ЛОГИКИ ;)
5 окт 05, 16:41    [1941380]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
mod
Member

Откуда:
Сообщений: 2318
Обожаю темы типа: сравнительная характеристика MSSQL2000 и Oraqul 9i. Вот где пространство для флуда. И где самые жаркие споры...
5 окт 05, 17:06    [1941545]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Yo!!
Ув. gardenman, вы заблуждаетесь, на уровне CS ставится лок именно до конца транзакции:

READ COMMITTED (DB2 UDB: Cursor Stability)

The entire table is locked. Shared locks are released when the associated cursors are closed (isolation levels higher than READ COMMITTED hold shared locks until the end of a transaction). Exclusive locks are held until the end of the transaction.

No other application can perform any DML operation on a table while an open cursor is accessing it. READ COMMITTED applications cannot see uncommitted changes of other applications.

Both nonrepeatable reads and phantom reads are possible. READ COMMITTED is the default isolation level, allowing maximum concurrency while seeing only committed rows from other applications.

http://publib.boulder.ibm.com/infocenter/weahelp/5.1/index.jsp?topic=/com.ibm.websphere.db2e.doc/db2e_iso_levels.html


ЁО! вы НЕ правы.
О какой блокировке идет речь? Дествительно пока курсор по таблице открыт я не смогу сделать drop table, alter table и подобные тому вещи. Но любое другое приложение может обновлять строку на которой в данный момент не стоит курсор.

Интересно в оракле разве можно удалить таблицу на которой есть открытые курсоры?
5 окт 05, 17:24    [1941658]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить