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

ну ты что, этим шагом МС бы признала, что они ошибались и версионный механизм круче. тех 80% бы удар хватил от такого :)
ждем тесты, уже хоть какие-нибудь.
11 май 05, 16:19    [1530331]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
SergSuper
AlexCzech
SergSuper
Зачем тогда команда перевод базы в версионный режим? Ввели просто новый уровень изоляции и всё


Затем, что чтобы вы МОГЛИ использовать уровень изоляции snapshot, нужно, как нетрудно догадаться, собирать предыдущие версии измененных строк в виде цепочек в tempdb. Однако этот сбор протухших версий НЕ ОБЯЗЫВАЕТ вас к ним обращаться


Т.е. перевод в версионный режим просто требует существенно больших ресурсов? (если не существенно то такая команда и не нужна бы была - работало бы всегда в версионном режиме)


Видимо, да. Правда слово "существенно" можно толковать настолько разнообразно, что не вижу смысла меряться настолько качественными категориями, особенно в отсутствие релиза (и даже Бета3 до меня пока не доехала :)) На бете1 примитивные апдейты отрабатывали с включенным snapshot на 30-40% медленнее (вместо ~70ms получалось ~110). На бете2 не тестировал
11 май 05, 16:23    [1530350]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
ppp
Member

Откуда:
Сообщений: 278
Na beta 3 u menja poluchalosj insert/update gde to na 25% meglennee pri Snapshot, no pri etom obshaja propusknaja sposobnostj selectov na porjadok vishe-
vse taki ne blokirujutsa dannie.
Stavitj rezim raboti bazi v Snapshot i pri etom rabotatj s nej kak s blokirovochnikom voobshe glupo - vse medlennee da eshe i blokiruetsa.
A vozmoznostj vkluchitj/vikluchitj podderzku vessionnosti ne ploho - estj krug zadach chistih OLTP i tratij resursi na podderzku versionnosti v nih smisla netu, hotja takih chistih OLTP i ne tak mnogo.
V obshem versionnostj eto ma moj vzgljad ochenj bolshij plus dlja MS SQL.
11 май 05, 16:50    [1530463]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7078
Есть такая песенка: "Нам не дано с тобой понять, чему так радуются дети..."
11 май 05, 17:43    [1530705]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

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

Неправильно понимаете. Транзакции с уровнем изоляции не SNAPSHOT будут работать так же, как и раньше - т.е. блокировать данные чтением и т.д. и т.п.
...
Затем, что чтобы вы МОГЛИ использовать уровень изоляции snapshot

это вы о чем вообще ?
При включенной версионности, уровень Read committed начинает работать как версионный, т.е. если транзакция напоролась на заблокированную запись, то она считает предыдущую версию этой записи. То-же касается Repeatable read. Со snapshot'ом все понятно, а Serializable и в самом деле остался чисто блокировочным.
11 май 05, 18:10    [1530817]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

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

Неправильно понимаете. Транзакции с уровнем изоляции не SNAPSHOT будут работать так же, как и раньше - т.е. блокировать данные чтением и т.д. и т.п.
...
Затем, что чтобы вы МОГЛИ использовать уровень изоляции snapshot

это вы о чем вообще ?
При включенной версионности, уровень Read committed начинает работать как версионный, т.е. если транзакция напоролась на заблокированную запись, то она считает предыдущую версию этой записи. То-же касается Repeatable read. Со snapshot'ом все понятно, а Serializable и в самом деле остался чисто блокировочным.


Не совсем так. Впрочем, мы это уже с вами обсуждали 1 раз, если вы в первый раз не поверили - не поверите и во второй
11 май 05, 18:17    [1530835]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
Впрочем, вкратце напомню - то поведение, о котором вы говорите, появляется, если включить на базе еще один параметр (READ COMMITTED SNAPSHOT по-моему называется), который тоже по умолчанию OFF
11 май 05, 18:19    [1530842]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

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

Не совсем так. Впрочем, мы это уже с вами обсуждали 1 раз, если вы в первый раз не поверили - не поверите и во второй

да не спорил я с вами, просто не понял, что вы имели ввиду. Мало-ли, какие-там переключатели есть, например с хинтом READCOMMITTEDLOCK транзакция попрет в блокировочном режиме, даже с включенным Read Committed with snapshots
11 май 05, 19:15    [1531001]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
А всё равно чего-то мне непонятно.

Состояние на начало транзакции надо хранить в любом режиме - она же может быть ролбэкнута. А уже версии на определённый момент надо хранить при появлении транзакций с уровнем изоляции snapshot. Т.е. мне не понятно зачем собирать предыдущие версии измененных строк в виде цепочек, ведь при возникновении snapshot-транзакции мы должны читать данные с начала транзакций, а эти данные по-любому всегда где-то хранятся
11 май 05, 20:02    [1531103]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
>>а эти данные по-любому всегда где-то хранятся

в смысле ? для роллбэка все лежит в логе, версии данных - в tempdb. чего тут непонятного ?
11 май 05, 20:22    [1531150]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
ppp
Member

Откуда:
Сообщений: 278
to SergSuper
no vedj tranzacij odnovremenno mozet bitj mnogo , esli u vas dolgaja tranzakjija v rezime Snapshot, ej nuzno sobiratj dannie po etim cepochkam izmenenij na otredelennij moment vremeni.
11 май 05, 20:23    [1531152]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
ppp
Member

Откуда:
Сообщений: 278
to StalkerS
prosto v loge toze estj versii dannih neobhodimih dlja rollbacka, ja tak ponimaju eto SergSuper i imel vvidu.
11 май 05, 20:27    [1531160]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
StalkerS
>>а эти данные по-любому всегда где-то хранятся

в смысле ? для роллбэка все лежит в логе, версии данных - в tempdb. чего тут непонятного ?

версии данных для snapshot-транзакций. Если таких транзакций нет - то зачем там чего-то хранить?

ppp
no vedj tranzacij odnovremenno mozet bitj mnogo , esli u vas dolgaja tranzakjija v rezime Snapshot, ej nuzno sobiratj dannie po etim cepochkam izmenenij na otredelennij moment vremeni.


esli u vas dolgaja tranzakjija v rezime Snapshot - а если её нет? Т.е. данные надо собирать с момента появления snapshot-транзакций, а до этого работаем как обычный блокировочный режим. И зачем тогда команды переводов из одного режима в другой?

В принципе я понимаю что где-то не прав, но не могу понять где.
11 май 05, 20:35    [1531184]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
в лог отправляется не вся запись, а только измененная часть, и не просто так отправляется, а в том виде, каком удобно серверу, может в виде старого значения, а может отправиться и в виде оператора sql. Из лога поэтому версию не считать, тем более лог предназначен и оптимизирован для последовательной записи, и ходить вперед-назад по нему в поисках версий неоптимально. Зато из tempdb версия считается очень бысто, т.к. там собственно вся запись и лежит

>>Если таких транзакций нет - то зачем там чего-то хранить?

дык если включена версионность, такая транзакция может в любой момент появиться. Что в этом странного ?
11 май 05, 20:41    [1531201]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
2SergSuper. Неактуальные протухшие версии данных постепенно удаляются - гарантированно хранятся только все состояния всех записей начиная с момента T1, где T1 - момент начала самой застарелой snapshot-транзакции
12 май 05, 02:06    [1531462]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
ppp
Member

Откуда:
Сообщений: 278
Nodo bi posmotretj Log Explorerom chto pishetsa v log pri vkluchennom rezime snapshot. Sejchas pri operacii update v log kladetsa primerno sledujushee - sam operator update , a tak ze staroe znachenie izmenjaemih dannih dlja rollbacka. Pri vkluchennom Snapshot starie versii dannie pishutsa v tempdb, tak chto vrode kak hranitj is v loge dlja otkata vrode kak ne objazatelno(kak v oracle, rollback segmenti ispolzyjut dlja versionnosti i rollbacka tranzakzij).
12 май 05, 03:52    [1531485]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
StalkerS
в лог отправляется не вся запись, а только измененная часть, и не просто так отправляется, а в том виде, каком удобно серверу, может в виде старого значения, а может отправиться и в виде оператора sql. Из лога поэтому версию не считать, тем более лог предназначен и оптимизирован для последовательной записи, и ходить вперед-назад по нему в поисках версий неоптимально. Зато из tempdb версия считается очень бысто, т.к. там собственно вся запись и лежит

Ну почему же из лога не считать? При откате то считывается

StalkerS

>>Если таких транзакций нет - то зачем там чего-то хранить?

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

Странно зачем нужна команда перевода в версионный режим.
AlexCzech

2SergSuper. Неактуальные протухшие версии данных постепенно удаляются - гарантированно хранятся только все состояния всех записей начиная с момента T1, где T1 - момент начала самой застарелой snapshot-транзакции

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

ppp
Nodo bi posmotretj Log Explorerom chto pishetsa v log pri vkluchennom rezime snapshot. Sejchas pri operacii update v log kladetsa primerno sledujushee - sam operator update , a tak ze staroe znachenie izmenjaemih dannih dlja rollbacka. Pri vkluchennom Snapshot starie versii dannie pishutsa v tempdb, tak chto vrode kak hranitj is v loge dlja otkata vrode kak ne objazatelno(kak v oracle, rollback segmenti ispolzyjut dlja versionnosti i rollbacka tranzakzij).

Пожалуй это всё и объясняет. Т.е. для единообразия работы данные для отката пишутся не только в лог, но и в tempdb, т.е. идёт дублирование данных. Вообще-то выглядит как атовизм и скорее всего в следующих версиях тогда команда перевода в версионный режим будет убрана
12 май 05, 09:50    [1531796]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
SergSuper
AlexCzech

2SergSuper. Неактуальные протухшие версии данных постепенно удаляются - гарантированно хранятся только все состояния всех записей начиная с момента T1, где T1 - момент начала самой застарелой snapshot-транзакции

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


А мы же не знаем, что там реально происходит... может, это дело именно так и работает. А может, тут есть какая-то засада, которой мы пока не осознали. Лично я убедился, что когда начинаю считать кого-то дураками, не сделавшими очевидную легкореализуемую вещь, то дураком-то в итоге оказываюсь я :)
12 май 05, 09:58    [1531833]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
>>Ну почему же из лога не считать? При откате то считывается

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

>>Ну собственно я это же и говорил. Версионный режим мог бы сам включаться при появлении snapshot-транзакций

как это вы себе представляете ? транзакции работают, не создают версий, потом появляется snapshot, и все сразу начинают делать версии ? а как быть с теми, кто уже в процессе ? версии задним числом наплодить ?
12 май 05, 10:28    [1531949]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 AlexCzech
А я в своё время серьёзно воспринимал статьи от MS что блокировка на уровне строки это неправильно и она никому не нужна, а потом тоже про версионность (правда уже в более мягких формах) :)

StalkerS
>>Ну почему же из лога не считать? При откате то считывается

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

Тем не менее информация для восстановления состояния на начало транзакции там есть, не так ли? Я не вижу принципиальной разницы что восстанавливать эту информацию при откате, что читать snapshot-транзакцей.
К тому же как-то Оракл восстанавливает из лога

StalkerS

>>Ну собственно я это же и говорил. Версионный режим мог бы сам включаться при появлении snapshot-транзакций

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

а по порядку?
транзакции работают, не создают версий - замечательно
потом появляется snapshot, и все сразу начинают делать версии - не совсем: не все, версии делают только snapshot-транзакции
а как быть с теми, кто уже в процессе? - а кто ж это? обычным транзакциям версии не нужны, а версии для snapshot-транзакций будут делаться при их появлении
версии задним числом наплодить? вот мне непонятно почему задним числом
12 май 05, 12:05    [1532406]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
hvlad
Guest
Тем, кто хочет разобраться с механизмом версионности, рекомендую сходить сначала сюда
12 май 05, 12:19    [1532473]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
2hvlad: Для того что бы разобавться с блокировками и версиями читайте Bernstain'a
12 май 05, 13:48    [1532915]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
hvlad
Guest
nkulikov
2hvlad: Для того что бы разобавться с блокировками и версиями читайте Bernstain'a
Хочется блеснуть знаниями "первоисточников" ? Та ради бога...
Я дал ссылку на то, как это сделано в реально работающем много лет сервере, а не на теорию 30-летней давности. Причём многое там по-русски и разжёвано. Через полгода, как (если) разберётесь в Юконе, будете удивлены.
Впрочем, не хотите - не читайте
12 май 05, 13:57    [1532957]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

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

Тем не менее информация для восстановления состояния на начало транзакции там есть, не так ли? Я не вижу принципиальной разницы что восстанавливать эту информацию при откате, что читать snapshot-транзакцей.
К тому же как-то Оракл восстанавливает из лога

что значит, нет разницы ? Например, строка в данный момент меняется, и заблокирована эксклюзивной блокировкой. Причем меняется только одно поле, а остальные не затрагиваются. Соответственно, в логе имеются данные об изменении этого поля и все. Ну получите вы их, а потом ? Значения остальных полей-то откуда брать ? Разрешать такой транзакции читать в обход блокировки ? А как быть с цепочками версий ?
Я-же говорю, можно было-бы всю запись в лог пихать, но тут это неоптимально получиться, потому-что лог оптимизирован для последовательной записи.
А так, в tempdb оказывается вся версия, что позволяет ее тут-же прочитать, не тратя время на восстановление информации, как это делается при откате транзакции. Именно поэтому, версионность советуют включать только тогда, когда есть большое число читателей, которые будут потреблять версии, а иначе включение версионности только тормознет сервер, т.к. будут бессмысленно плодиться никому не нужные версии.

А в Оракле у них два журнала, один для восстановления транзакций, а другой - для чтения версий. И при работе транзакции, данные пишутся в оба журнала.
SergSuper

не совсем: не все, версии делают только snapshot-транзакции

это еще почему ? Разве вы не в курсе, что из себя представляет snapshot ? При ее запуске, все изменения замораживаются, т.е. она видит согласованный срез данных на время старта. Например, какая-нибудь транзакция (напр. read committed) меняет запись. В это время запустилась snapshot, и ей нужна данная запись. Она ее возьмет из tempdb, т.к. сама запись заблокирована. Более того, если теперь зафиксировать первую транзакцию, а из snapshot опять прочитать ту запись, то опять вернется старое значение, не смотря на то, что первая транзакция уже зафиксирована. И все время, пока snapshot жива и здорова, версии лежат в tempdb, даже если запись меняется много раз разными транзакциями.
12 май 05, 16:20    [1533759]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
StalkerS
А в Оракле у них два журнала, один для восстановления транзакций, а другой - для чтения версий. И при работе транзакции, данные пишутся в оба журнала.


Однако... как undo tablespace мощно опустили, оказывается он только для чтения версий пригоден
12 май 05, 16:27    [1533802]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить