Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
softwarer
hvlad
Если я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ?
Вы спорите ни о чем
Да, так бывает :) Больше не буду, тем более что смысла в этом не вижу.

softwarer
Знаете старую фразу - "если нечто плавает как утка, крякает как утка и несет утиные яйца, значит это утка"?
А если оно ещё и прыгает, как заяц ? И имеет жабры ?
Метод аналогий как правило ведёт в сторону и нечего не доказывает

softwarer
В Вашем случае возникнет миллион незакоммиченных версий
И что ? У блокировочника будет 2 миллиона в transaction log'е - 1М inserted и 1М deleted

softwarer
Причем, сидя в SQL-консоли, отличить их от блокировок будет достаточно трудно - они "крякают как блокировки".
Они не крякают как блокировки хотя бы потому, что это
1. не блокировки (сколько можно говорить ?)
2. они не жрут память, как миллион блокировок
3. поэтому не нужна их эскалация
...
N. См. п1 :)

дальше спорить лень.

Не вижу смысла убеждать что белое-это белое, а чёрное - это чёрное.
22 мар 05, 12:27    [1404959]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
hvlad
А если оно ещё и прыгает, как заяц ? И имеет жабры ?

Значит, оно отличается от X в сфере прыжков. И не отличается в плане плавания.

hvlad

softwarer
В Вашем случае возникнет миллион незакоммиченных версий
И что ? У блокировочника будет 2 миллиона в transaction log'е - 1М inserted и 1М deleted

Ну, если считать - у версионника тоже будет миллион старых версий и миллион новых :) Это объективное требование задачи.

hvlad
Они не крякают как блокировки хотя бы потому, что это

Они крякают как блокировки потому что (синхронизируют доступ).

То, о чем Вы говорите - техническая реализация. Блокировки в оракле тоже не жрут память - и, полагаю, с точки зрения расхода памяти его подход эффективнее интербейсовского. Но это не означает, что в оракле нет блокировок.

Фактически и Вы, и Ваш оппонент могли бы сказать одну фразу: реализация интербейса опирается на неявные, виртуальные блокировки; версия записи в Interbase играет роль блокировки, а последняя соответственно не существует в виде самостоятельного объекта (опять-таки - как и в оракле). Но вместо этого вы дружно держите более агрессивные позиции по разные стороны этого утверждения.
22 мар 05, 12:41    [1405006]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
softwarer
hvlad
Они не крякают как блокировки хотя бы потому, что это

Они крякают как блокировки потому что (синхронизируют доступ).
Тогда осталось выяснить - а что же такое блокировка ? ;)
Умоляю не делать этого, новый флейм нам не нужен

softwarer
То, о чем Вы говорите - техническая реализация
Именно так.

softwarer
Фактически и Вы, и Ваш оппонент могли бы сказать одну фразу: реализация интербейса опирается на неявные, виртуальные блокировки; версия записи в Interbase играет роль блокировки, а последняя соответственно не существует в виде самостоятельного объекта (опять-таки - как и в оракле). Но вместо этого вы дружно держите более агрессивные позиции по разные стороны этого утверждения.
В принципе, если отойти от технической стороны, то я могу с этим согласиться. Но тогда весь этот топик теряет смысл, т.к. в нём обсуждаются именно технические особенности реализации. Если это не так - я признаю свою ошибку в неверной интерпретации темы беседы и исчезаю ;)
22 мар 05, 12:47    [1405042]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Zaxx
Guest
hvlad
В принципе, если отойти от технической стороны, то я могу с этим согласиться. Но тогда весь этот топик теряет смысл, т.к. в нём обсуждаются именно технические особенности реализации.


В топике обсуждаются "Различия в работе версионных механизмов в Oracle и Yukon"...
А блокировки независимо от реализации остаются блокировками...
22 мар 05, 16:02    [1405948]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
Zaxx
В топике обсуждаются "Различия в работе версионных механизмов в Oracle и Yukon"...
А блокировки независимо от реализации остаются блокировками...
Это мой последний ответ на этот вопрос - в IB\FB нет блокировок записей
Можете думать что хотите по этому поводу :)

PS Так можно докатиться до того, что IB\FB\Oracle блокировочником обзовут
22 мар 05, 17:15    [1406231]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Zaxx
В топике обсуждаются "Различия в работе версионных механизмов в Oracle и Yukon"...

Гражданам (как и мне), видимо, тяжело обсуждать то, что уже работает не один десяток лет и многократно вылизано, с тем, чего еще нет. Думаю, Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность. Аналогично тому, как после борьбы с лженаукой СССР/Россия в IT находится сами знаете где :(

P.S.
Как пример использования возможностей, предоставляемых версионным механизмом в Oracle:

Предположим, при сильной нагрузке DBWR (фоновый процесс) осуществляет запись "грязного" (измененного) блока (страницы в терминах MS SQL) на диск - то есть, в ОС выдана команда на физическую запись (возможно, целой группы блоков), но блок еще не записан. И в этот момент пользовательскому процессу нужно модифицировать этот блок. Так вот, в Oracle 8i и выше пользовательский процесс не ждет окончания I/O, а клонирует в памяти этот блок и работает с ним, делая его текущим (current). Исходный же блок конвертируется в cr (consistent read)-блок и может использоваться как обычный cr-блок для согласованного чтения.

Когда Юкон научится делать подобные вещи, тогда он дорастет в этой области до Oracle и можно будет что-то сравнивать.

Поэтому смешно, когда автор вопроса, ничего не смысля в версионном механизме Oracle, пытается его сравнивать с тем, чего еще нет - с Юконом. И еще пытается доказать, что в Oracle это работает дерьмово.
22 мар 05, 18:01    [1406447]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
hvlad

По вашим словам, оператор (2) должен откатить всю тр-цию, в том числе оператор (1). Смотрим результаты
...
Итак - 3 попытки доступа к заблокированной таблице t отвергнуты, но запись в t2 спокойно вставлена и тр-ция фиксирована.
Ась ?

т.е. вы мне продемонстрировали, что транзакция в mssql2000 откатывает только один оператор, а остальные фиксирует ?
;)
Не хочется очернять ваше торжество, но этот эффект можно достигнуть и более простыми телодвижениями:

create table test (f int primary key)
go

set transaction isolation level serializable
begin tran
insert into test values (1)
insert into test values (1)
insert into test values (2)
commit

результат :
(1 row(s) affected)

Server: Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK__test__34B3CB38'. Cannot insert duplicate key in object 'test'.
The statement has been terminated.

(1 row(s) affected)

Я писал про Yukon, и его уровень изоляции транзакций snapshot, а это немного разные вещи.
vadiminfo

Так как от ЭБ все-таки все еще ожидается много вреда

не все лекарства одинаково полезны для всех органов, однако это никого не смущает ;)
22 мар 05, 21:29    [1406907]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
Я писал про Yukon, и его уровень изоляции транзакций snapshot, а это немного разные вещи
Не нужно придумывать, если есть под рукой Юкон - просто проверьте.
22 мар 05, 22:04    [1406957]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
Oops!... I Did It Again :)

мс в очередной раз перенесла релиз, уже даже я не рад.
http://www.eweek.com/article2/0,1759,1777755,00.asp
23 мар 05, 01:29    [1407123]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
Markelenkov
Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность.
Свежо питание, да сериться с трудом :)
В nVidia то же думали о своей непобедимости, пока ATI не напряглись. Intel то же царствовал на ПК, а теперь я пожалуй Athlon64 предпочту. Рынок - вещь переменчивая, а быть упертым болваном и кричать Oracle это круто, потому что ... - себя не уважать.

Посмотрим ;)
23 мар 05, 14:38    [1408834]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Dooma

В nVidia то же думали о своей непобедимости, пока ATI не напряглись. Intel то же царствовал на ПК, а теперь я пожалуй Athlon64 предпочту. Рынок - вещь переменчивая, а быть упертым болваном и кричать Oracle это круто, потому что ... - себя не уважать.

Я тут покупал комп приятельнице, чтобы все игры шустро крутились и все такое. Перерыл весь инет вывирая производителей - в результате купил nVidia - видюху и пень Intel.
Ну, кричать, что Оракл круто не буду, но, надеюсь, он еще подержится в лидерах. И инфа на этом формуме способствует все еще таким надеждам.
23 мар 05, 15:28    [1409212]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
автор
Я тут покупал комп приятельнице, чтобы все игры шустро крутились и все такое. Перерыл весь инет вывирая производителей - в результате купил nVidia - видюху и пень Intel
И напрасно. С AMD сэкономили бы по деньгам при той же производительности.
автор
Ну, кричать, что Оракл круто не буду, но, надеюсь, он еще подержится в лидерах. И инфа на этом формуме способствует все еще таким надеждам.
Флейм на форуме - на объективность не тянет.
А то я скажу, что меня он склоняет, что скоро везде останется один большой MS, а все остальные сдохнут :) И по новой :)
23 мар 05, 18:41    [1410149]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
Dooma

Markelenkov

Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность.

Свежо питание, да сериться с трудом :)

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

Ну, кричать, что Оракл круто не буду, но, надеюсь, он еще подержится в лидерах.

Я не буду разводить флейм по поводу лидерства и подобной ерунды, но скажу, что видимо в отличие от многих здесь, мне совершенно не хочется, что-бы в мире СУБД когда-либо появился неоспоримый лидер, неважно кто. Так-же я рад развитию Linux'a и прочей юниксовщины, потому-что, не будь у microsoft конкуренции, мы-бы сейчас жили с системами типа Win 3.1. Я думаю, не стоит обьяснять почему ;)
23 мар 05, 19:22    [1410209]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
StalkerS
Так-же я рад развитию Linux'a и прочей юниксовщины, потому-что, не будь у microsoft конкуренции, мы-бы сейчас жили с системами типа Win 3.1. Я думаю, не стоит обьяснять почему ;)

Безусловно. Собственно, в виндах довольно мало идей, которые не позаимоствованы из юниксов :)
23 мар 05, 19:25    [1410213]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
StalkerS
Dooma

Markelenkov

Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность.

Свежо питание, да сериться с трудом :)

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

Уважаемый, под "обсуждаемой темой" я имел ввиду "Различия в работе версионных механизмов в Oracle и Yukon". Это все равно, как сравнивать игру ученика 1-го класса музыкальной школы и выпускника Гнесинки - разные весовые категории. Это не означает, что MS SQL во всем хуже/лучше Oracle, просто в поддержке версионности он еще в грудном возрасте. При этом в чем-то другом Oracle по сравнению с MS SQL грудничок. Соглашаться или нет с такими доводами - дело каждого. Жизнь рассудит, будущее покажет :)

P.S. Рад, что такие кавалеристы не попадают в модераторы :)
P.P.S. Чтобы было легче, могу сказать, что в MS SQL я полный дуб, придурок и профан. Потому и не сужу о его достоинствах/недостатках после прочтения пары глав из популярной книжки и не ругаю автора, хоть и несколько попсового, но грамотного.

Кстати, учить русский язык никогда не поздно.
23 мар 05, 20:21    [1410309]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS

Я не буду разводить флейм по поводу лидерства и подобной ерунды, но скажу, что видимо в отличие от многих здесь, мне совершенно не хочется, что-бы в мире СУБД когда-либо появился неоспоримый лидер, неважно кто. Так-же я рад развитию Linux'a и прочей юниксовщины, потому-что, не будь у microsoft конкуренции, мы-бы сейчас жили с системами типа Win 3.1. Я думаю, не стоит обьяснять почему ;)

С этим трудно не согласиться. Но они должны в конкурентной борьбе за лидерство совершенствовать СУБД. Я имел ввиду это. Т.е. чтобы эти СУБД боролись не 10 или 20 место, а за 1.
24 мар 05, 00:09    [1410501]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Silver
Member

Откуда:
Сообщений: 141
;) Меня особенно умилила возможность перепрыгивать "на ходу" с блокировочника на версионник! Эта ж какая "архинужная" и "архиполезная" ВЕСЧЪ!!! Особливо памятуя что клиентское приложение о подобных чудесах может не ведать ни сном, ни духом. %)
28 июн 05, 05:21    [1654204]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
segun
Member

Откуда: Москва
Сообщений: 504
Silver
;) Меня особенно умилила возможность перепрыгивать "на ходу" с блокировочника на версионник! Эта ж какая "архинужная" и "архиполезная" ВЕСЧЪ!!! Особливо памятуя что клиентское приложение о подобных чудесах может не ведать ни сном, ни духом. %)
Клиентским приложениям об этом необязательно знать. Знают - хорошо, не знают - это не помешает воспользоваться данной функциональностью, хотя есть и нюансы конечно. Возможность выбора между оптимальной производительностью системы и оптимальной доступностью информации - это большой плюс. Хотя данная функциональность наверняка не будет использоваться в каждом проекте, но в тех проектах где возникнет необходимость в подобной настройке, ее можно будет использовать.
Прежде чем делать поспешные выводы, почитайте пож-ста хотя бы только эту статью: SQL Server 2005 Beta 2 Snapshot Isolation. Надеюсь, многое станет более понятным и не таким смешным.
28 июн 05, 12:08    [1655162]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
с127
Guest
Silver
;) Меня особенно умилила возможность перепрыгивать "на ходу" с блокировочника на версионник! Эта ж какая "архинужная" и "архиполезная" ВЕСЧЪ!!! Особливо памятуя что клиентское приложение о подобных чудесах может не ведать ни сном, ни духом. %)


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

segun
Прежде чем делать поспешные выводы, почитайте пож-ста хотя бы только эту статью: SQL Server 2005 Beta 2 Snapshot Isolation. Надеюсь, многое станет более понятным и не таким смешным.


Стало только смешнее. Например: "In recent versions (starting with Oracle 9i) Oracle have introduced a technology similar to that used in SQL Server 2005 called "Automatic Undo Management Mode"—this new method is incompatible with the previous manual method and will require code changes if USE ROLLBACK SEGMENT statements have been used". Складывается впечатление что в МССКЛ сервере это уже давно, а в оракле 9и появилось только-только, хотя на самом деле 9и уже года четыре как на рынке, десятка на подходе, а МССКЛ все еще в бета версии и неизвестно когда появится, вообще пора переименовывать в МССКЛ-2006.

Или вот: "The implementation of optimistic concurrency differs widely between SQL Server 2005 and Oracle—the SQL Server implementation is designed to be more controllable by the database administrator (it can be enabled & disabled on command, as illustrated in the previous scenario) and also to be more manageable". Это после того как тут сторонники МССКЛ-я до хрипоты доказывали, что сервер все оптимизирует и контролирует гораздо лучше администратора, а настройки сервера никому не нужны и только отвлекают настоящего гуру от работы.

Но читаем дальше о том как же этот контроль осуществляется: "—there are a wealth of Windows System Monitor performance counters and virtual tables accessible through system functions that can help detect and decipher what is happening with the database.". Еще одно революционное достижение: виндовз монитор, системные процедуры и таблицы позволяют разобраться в чем проблема. Типа у оракла все как-то не так или что? В чем новизна-то и где обещанное в первом предложении превосходство над ораклом?

А дальше идет вообще смешное сравнение мелкософта и оракла, где неотягощенного опытом и знаниями администратора МССКЛ-я пугают фразами вроде: "Can require complex configuration of ROLLBACK SEGMENTS". Это об оракле.

МССКЛ- совсем другое дело, никаких сложностей, радостный и светящийся внутренним светом ДБА решает все проблемы легикими движениями мыши: "Version store is held in memory and TempDB. The dba must ensure that TempDB is optimized for increased i/o bandwidth based on the version store workload—TempDB database size must also be monitored (especially if the application has long running transactions), SQL Server has supported dba-friendly percentage and absolute database and log autogrow settings for many releases, but these are obviously constrained by the physical availability of disk space."

Опять вопрос: а какая разница что подправлять, и мониторить ролбек сегмент или темпДБ? Оракл тоже позволяет всякие хитрости с роллбеком. Нахрена в технической статье нужна эта тупая пропаганда рассчитанная на безграмотных идиотов?

Вообще в статье простые и очевидные вещи излагаются с таким умным видом и таким ворохом лишних деталей что складывается впечатление что речь идет не о чем-то известном, давным-давно используемых в оракле, постгрескл-е и даже файерберде, а чем-то совершенно новом, впервые появившемся только благодаря благодетелю нашему мелкософту в МССКЛ2005. Точнее еще не появившемся, поскольку релиза все еще нет, но уже вот-вот, может быть, еще чуть-чуть, но уже совсем немного и настанет счастье.

О том что и в файерберде есть версионность автор статьи предусмотрительно предпочел умолчать, заявив, что из коммерческих продуктов это только оракл ("The second camp implemented a non-standard transaction isolation model with optimistic concurrency based on retaining a view of the data as of the start of the transaction—the only commercial system in this camp was Oracle"). И правильно, какая же это революция если даже бесплатный мелкий файерберд давно это все умеет.

Кроме того значительный кусок посвящен изложению классических уровней изоляции, которые должны быть изветны даже мелкософтовским ДБА. Но это тоже правильно, можно пинать оракл и кричать что он этого не умеет. Не вспоминать что неплохо обходится без них уже много лет как.

Короче для тех кто ничего кроме мелкософта не видел статья возможно и в самом деле полезная, а для остальных - ничего нового.


А вот и первые ласточки революционного версионно-блокировочного механизма:
DDL Statements NOT Allowed Within Snapshot Isolation

Certain statements are not allowed within a transaction running under Snapshot Isolation because of their disruptive potential on the snapshot copies of the data:

* CREATE INDEX
* CREATE XML INDEX
* ALTER INDEX
* ALTER TABLE
* DROP INDEX
.....
Хотите подправить инедкс или таблицу - извольте выключить Snapshot Isolation.

И как бедняга оракл с таким справляется, ведь у него-же версионность выключить нельзя.
29 июн 05, 05:44    [1657446]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7079
Может тогда обсудить ORACLE 11 против Yukon, чтобы еще интереснее было?
29 июн 05, 08:34    [1657553]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
nkulikov
Guest
Самое смешное в том что 90% денег на нашей планете переводятся со счета на счет, даже не через реляционные БД....
29 июн 05, 11:08    [1658041]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
замечательно
...statements are not allowed within a transaction running under Snapshot Isolation

Не выключить Snapshot Isolation, а вне транзакции. Это несколько разные вещи.
Между тем, согласен, что написано слишком пафосно... Впрочем писали ведь какие-нить маркетологи. Они этим деньги зарабатывают.
29 июн 05, 11:22    [1658117]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
До прочтения поста с127 я даже не подозревал, что можно плакать и смеяться одновременно. Очередной спец по Ораклу углядел потрясающие ляпы в Yukon.

Мне сейчас хочется спать и так в лом комментировать весь тот бред, что я просто выделю те куски, над которыми с127 должен долго и вдумчиво курить кальян раскачиваясь из стороны в сторону. Для максимального эффекта можно поставить психоделическую музыку.

>>подумашь пол-транзакции версионная, пол-транзакции блокировочная

>>The dba must ensure that TempDB is optimized for increased i/o bandwidth based on the version store workload
>>...
>>а какая разница что подправлять, и мониторить ролбек сегмент или темпДБ?

>>Хотите подправить инедкс или таблицу - извольте выключить Snapshot Isolation.

>>Стало только смешнее. Например: "In recent versions (starting with Oracle 9i) Oracle have introduced a technology similar to
>>that used in SQL Server 2005 called "Automatic Undo Management Mode"—this new method is incompatible with the previous manual
>>method... Складывается впечатление что в МССКЛ сервере это уже давно, а в оракле 9и появилось только-только...

У меня вообще такое чувство, что глубокоуважаемый с127 перевел статью переводчиком типа Magic Goody. Хотя все равно непонятно, откуда взялись все то, о чем он там понаписал. Ведь Magic Goody не может сам придумать перевод, если не знает как перевести !!! (хотя хер его знает, может новые версии Magic Goody так и поступают, вводя тем самым несчастных с127 в заблуждение)
29 июн 05, 21:05    [1661020]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
c127
Guest
AAron
замечательно
...statements are not allowed within a transaction running under Snapshot Isolation

Не выключить Snapshot Isolation, а вне транзакции. Это несколько разные вещи.



Дело в том что перечисленные операции (alter table, alter index, ...) относятся к DDL и никогда в транзакции не входили. Если речь идет именно о транзакции, то в этой иноформации нет смысла, зачем говорить что они не входят в транзакцию в снапшот-уровне изоляции если они не входят ни в какую транзакцию ни при каком уровне изоляции. Или в Юконе на каких-то уровнях изоляции можно откатить alter table? Т.е. по-моему как раз чтоб выполнить например alter index нужно выключить снапшот изоляцию, как я и написал, другого объяснения прочитанному я не вижу. Может я ошибаюсь.

AAron

Между тем, согласен, что написано слишком пафосно... Впрочем писали ведь какие-нить маркетологи. Они этим деньги зарабатывают.


Все что я написал есть ответ на утверждение segun-а что после прочтения этой статьи многое прояснится и не будет таким смешным. Я и ответил, что стало только смешнее. Не нужно давать ссылки на такие статьи, хотя другие по продуктам микрософта наверное найти сложно.

А так я с Вами согласен.


StalkerS
До прочтения поста с127 я даже не подозревал, что можно плакать и смеяться одновременно. Очередной спец по Ораклу углядел потрясающие ляпы в Yukon.


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

StalkerS

>>подумашь пол-транзакции версионная, пол-транзакции блокировочная


Это была шутка. Если присмотритесь, то увидите что это ответ не segun-у, а Silver-у на шутливый пост.

Читайте внимательно, а главное ДУМАЙТЕ хотябы изредка. Полезная штука.
30 июн 05, 04:22    [1661323]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
c127
Guest
Ззабыл сказать.

AAron
замечательно
...statements are not allowed within a transaction running under Snapshot Isolation

Не выключить Snapshot Isolation, а вне транзакции.


По-видимому у Вас опечатка, не вне транзакции, а внутри транзакции.
30 июн 05, 04:33    [1661327]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить