powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Появление версионника в Yukon лишает Oracle всяких преимуществ!
101 сообщений из 101, показаны все 5 страниц
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33055972
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Более того, это не принципиальное ограничение как в Oracle а опция, которую можно использовать а можно и нет.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33055978
Valery Shiskin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Только надо дожить до Yukon, причем работающего и проверенного годами.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33055981
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
немного грубо но зато по существу:

http://www.sql.ru/forum/actualthread.aspx?tid=168282&pg=5#1406447
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056014
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IHMO ne "всяких преимуществ" ,a lishaet priemushestva nalichija versionnosti )
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056027
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну а доступность дотнетовского API это вообще ход конем. Если в Oracle поддержка java сделана сбоку припеку, то в Yukone будет доступ ко всем библиотекам .NET и с ограниченностью TSQL будет покончено. Не нужно будет никаких глючных виртуальных машин, функциональность будет предоставляться операционной системой и .NET фреймворком.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056033
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Valery ShiskinТолько надо дожить до Yukon, причем работающего и проверенного годами.

Доживем! Смог же майкрософт буквально за пару лет вывести свою СУБД на высший уровень, так же смогет реализовать все преимущества, которые есть у Оракла, за исключением разве что кросплатформенности. Но здесь ситуация такая - подобно тому как люди из за майкрсофт офиса делают выбор в пользу Виндовс, точно также они будут из Yukona выбирать Виндовс в качестве сервера.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056094
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nu dak let cherez 5-10 vopros vibora mezdu MS SQL , Oracle i DB2 UDB skoree vsego budet ka vibor mezdu BMW i AUDI, komu chto bolshe po dushe.
Funkcional i ceni dolzni statj ochenj pohozimi - MS dolzni popravitj bezopasnostj v windows i dorabotatj SQL Server, Oracle uprostitj raboty s DB i ponizitj ceni.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056111
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Желтoпузый дьявoлНу а доступность дотнетовского API это вообще ход конем. Если в Oracle поддержка java сделана сбоку припеку, то в Yukone будет доступ ко всем библиотекам .NET и с ограниченностью TSQL будет покончено. Не нужно будет никаких глючных виртуальных машин, функциональность будет предоставляться операционной системой и .NET фреймворком.

Увлекаетесь, молодой человек.
Во-первый будут глючные CLR машины, а во-вторых попробуйте "select * from ..." написать на C# и поймёте что это тоже сбоку припеку. Альтернативы развития TSQL нет, а вот он то не особо развился.

Да и версионность какая-то странная. Либо я работаю с базой в версионном режиме, либо в блокировочном. Т.е. преимуществ и того и другого одновременно я лишен.

Желтoпузый дьявoлДоживем! Смог же майкрософт буквально за пару лет вывести свою СУБД на высший уровень, так же смогет реализовать все преимущества, которые есть у Оракла, за исключением разве что кросплатформенности.
И какие же интересно это года? 2002 и 2003? Или 1993 и 1994?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056289
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Желтoпузый дьявoлБолее того, это не принципиальное ограничение как в Oracle а опция, которую можно использовать а можно и нет.
Это точно. В Oracle нет такой классной TempDB, в которую MS и впихнула версионность вдогонку к транзакционным временным таблицам. Очень хотелось бы посмотреть на реальных нагрузках, как все это будет работать - будем ждать выхода чудо-сервера :)

P.S. Бедные клиентские приложений, вот им туго придется, когда админы будут MSSQL с блокировочника на версионник переключать, придется 2 модели поведения программировать.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33056391
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperДа и версионность какая-то странная. Либо я работаю с базой в версионном режиме, либо в блокировочном. Т.е. преимуществ и того и другого одновременно я лишен.


Это вы с чего взяли ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057069
alexey_tm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Слушаю вас и радуюсь, сделано заявление и все начинают нести всякую чушь. БД либо версионная либо нет, на этом строится ядро. А что у Oracle нет TempDB, так в нем, убогом, только одна БД у одного экземпляра (или у нескольких экземпляров). Есть табличное пространство undo, есть табличное пространство Temp, только вот зачем они, разработчикам и админам MSSQL не ведомо. Ну ребята, вам прикольно и слава Богу.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057075
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexey_tmСлушаю вас и радуюсь, сделано заявление и все начинают нести всякую чушь. БД либо версионная либо нет, на этом строится ядро. А что у Oracle нет TempDB, так в нем, убогом, только одна БД у одного экземпляра (или у нескольких экземпляров). Есть табличное пространство undo, есть табличное пространство Temp, только вот зачем они, разработчикам и админам MSSQL не ведомо. Ну ребята, вам прикольно и слава Богу.

Ща вас распнут, и правильно сделают... если не лень будет
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057092
alexey_tm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech
Ща вас распнут, и правильно сделают... если не лень будет
Ну порадуйтесь, что с того
Чтобы так рассуждать, неплохо было бы знать Oracle, но тот кто знает Oracle почемуто, никогда не будет открывать подобные темы )
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057129
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexey_tm AlexCzech
Ща вас распнут, и правильно сделают... если не лень будет
Ну порадуйтесь, что с того
Чтобы так рассуждать, неплохо было бы знать Oracle, но тот кто знает Oracle почемуто, никогда не будет открывать подобные темы )

Ну так не обязательно открывать такие темы, чтобы заглянуть чуть попозже :)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057162
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech SergSuperДа и версионность какая-то странная. Либо я работаю с базой в версионном режиме, либо в блокировочном. Т.е. преимуществ и того и другого одновременно я лишен.


Это вы с чего взяли ?

В Yukon версионность не является состоянием сервера в целом, она может быть включена для каждой базы в отдельности, причем по умолчанию версионность включена только для служебных БД master и msdb, и тестовой AdventureWorks.

Версионность включается с помощью нехитрой команды:

ALTER DATABASE database_name SET ALLOW_SNAPSHOT_ISOLATION ON

После ее выполнения сервер не сразу переключает базу в версионный режим, а переводит механизм поддержки версионности (snapshot isolation framework) в состояние PENDING_ON, поскольку в этот момент в базе могут быть активные транзакции. После завершения всех активных транзакций над базой производятся все необходимые изменения, механизм версионности для нее переводится в состояние ON, и появляется возможность выполнять версионные запросы. Обратное действие осуществляется также в два этапа, сначала БД переводится в состояние PENDING_OFF, а потом уже отключается механизм поддержки версионности.

http://www.rsdn.ru/article/db/yukonvers.xml

Я так понимаю - раз чего-то включается, значит чего то и выключается
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057176
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
к стате как выглядит этот темдб ? пара блоков от одной сортировки, пара от другой, потом кусок версий строк, а дальше чья-то темп таблица, я правильно понимаю ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057192
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperЯ так понимаю - раз чего-то включается, значит чего то и выключается

Неправильно понимаете. Транзакции с уровнем изоляции не SNAPSHOT будут работать так же, как и раньше - т.е. блокировать данные чтением и т.д. и т.п.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057650
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зачем тогда команда перевод базы в версионный режим? Ввели просто новый уровень изоляции и всё
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057671
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperЗачем тогда команда перевод базы в версионный режим? Ввели просто новый уровень изоляции и всё

Затем, что чтобы вы МОГЛИ использовать уровень изоляции snapshot, нужно, как нетрудно догадаться, собирать предыдущие версии измененных строк в виде цепочек в tempdb. Однако этот сбор протухших версий НЕ ОБЯЗЫВАЕТ вас к ним обращаться
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057693
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
хм ... а какой прок от блокировочного режима если он ресурсы на подержку версионого режима тратит ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057708
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo!!хм ... а какой прок от блокировочного режима если он ресурсы на подержку версионого режима тратит ?

Я так подозреваю, что при первом взгляде на Yukon 80% закаленных жизнью девелоперов под MS SQL скажут то же самое, только 2 слова местами поменяют :)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057780
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ну 99% foxpro/access не понимают что такое консистентное чтение, но меня их мнение мало волнует, меня больше интересует тот 1% который понимает.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057802
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo!!ну 99% foxpro/access не понимают что такое консистентное чтение, но меня их мнение мало волнует, меня больше интересует тот 1% который понимает.

Ну так вот для 1% задач оно и будет использоваться на MS SQL, я так подозреваю... живут же как-то сейчас вообще без такой замечательной фичи, и не сказать что рынок отторгает :)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057841
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну зато нельзя будет кричать, что Оракл имеет версионность, поэтому он крут!!!

-- Tygra's --
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057911
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech SergSuperЗачем тогда команда перевод базы в версионный режим? Ввели просто новый уровень изоляции и всё

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

Т.е. перевод в версионный режим просто требует существенно больших ресурсов? (если не существенно то такая команда и не нужна бы была - работало бы всегда в версионном режиме)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057953
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>если не существенно то такая команда и не нужна бы была - работало бы всегда в версионном режиме

ну ты что, этим шагом МС бы признала, что они ошибались и версионный механизм круче. тех 80% бы удар хватил от такого :)
ждем тесты, уже хоть какие-нибудь.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33057966
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper AlexCzech SergSuperЗачем тогда команда перевод базы в версионный режим? Ввели просто новый уровень изоляции и всё

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

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

Видимо, да. Правда слово "существенно" можно толковать настолько разнообразно, что не вижу смысла меряться настолько качественными категориями, особенно в отсутствие релиза (и даже Бета3 до меня пока не доехала :)) На бете1 примитивные апдейты отрабатывали с включенным snapshot на 30-40% медленнее (вместо ~70ms получалось ~110). На бете2 не тестировал
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058046
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058206
alex-ls
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть такая песенка: "Нам не дано с тобой понять, чему так радуются дети..."
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058275
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech
Неправильно понимаете. Транзакции с уровнем изоляции не SNAPSHOT будут работать так же, как и раньше - т.е. блокировать данные чтением и т.д. и т.п.
...
Затем, что чтобы вы МОГЛИ использовать уровень изоляции snapshot

это вы о чем вообще ?
При включенной версионности, уровень Read committed начинает работать как версионный, т.е. если транзакция напоролась на заблокированную запись, то она считает предыдущую версию этой записи. То-же касается Repeatable read. Со snapshot'ом все понятно, а Serializable и в самом деле остался чисто блокировочным.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058287
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS AlexCzech
Неправильно понимаете. Транзакции с уровнем изоляции не SNAPSHOT будут работать так же, как и раньше - т.е. блокировать данные чтением и т.д. и т.п.
...
Затем, что чтобы вы МОГЛИ использовать уровень изоляции snapshot

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

Не совсем так. Впрочем, мы это уже с вами обсуждали 1 раз, если вы в первый раз не поверили - не поверите и во второй
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058293
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Впрочем, вкратце напомню - то поведение, о котором вы говорите, появляется, если включить на базе еще один параметр (READ COMMITTED SNAPSHOT по-моему называется), который тоже по умолчанию OFF
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058396
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech
Не совсем так. Впрочем, мы это уже с вами обсуждали 1 раз, если вы в первый раз не поверили - не поверите и во второй

да не спорил я с вами, просто не понял, что вы имели ввиду. Мало-ли, какие-там переключатели есть, например с хинтом READCOMMITTEDLOCK транзакция попрет в блокировочном режиме, даже с включенным Read Committed with snapshots
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058482
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А всё равно чего-то мне непонятно.

Состояние на начало транзакции надо хранить в любом режиме - она же может быть ролбэкнута. А уже версии на определённый момент надо хранить при появлении транзакций с уровнем изоляции snapshot. Т.е. мне не понятно зачем собирать предыдущие версии измененных строк в виде цепочек , ведь при возникновении snapshot-транзакции мы должны читать данные с начала транзакций, а эти данные по-любому всегда где-то хранятся
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058521
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>а эти данные по-любому всегда где-то хранятся

в смысле ? для роллбэка все лежит в логе, версии данных - в tempdb. чего тут непонятного ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058523
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058529
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to StalkerS
prosto v loge toze estj versii dannih neobhodimih dlja rollbacka, ja tak ponimaju eto SergSuper i imel vvidu.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058552
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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-транзакций, а до этого работаем как обычный блокировочный режим. И зачем тогда команды переводов из одного режима в другой?

В принципе я понимаю что где-то не прав, но не могу понять где.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058566
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в лог отправляется не вся запись, а только измененная часть, и не просто так отправляется, а в том виде, каком удобно серверу, может в виде старого значения, а может отправиться и в виде оператора sql. Из лога поэтому версию не считать, тем более лог предназначен и оптимизирован для последовательной записи, и ходить вперед-назад по нему в поисках версий неоптимально. Зато из tempdb версия считается очень бысто, т.к. там собственно вся запись и лежит

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

дык если включена версионность, такая транзакция может в любой момент появиться. Что в этом странного ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058747
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2SergSuper. Неактуальные протухшие версии данных постепенно удаляются - гарантированно хранятся только все состояния всех записей начиная с момента T1, где T1 - момент начала самой застарелой snapshot-транзакции
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33058769
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).
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059022
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerSв лог отправляется не вся запись, а только измененная часть, и не просто так отправляется, а в том виде, каком удобно серверу, может в виде старого значения, а может отправиться и в виде оператора sql. Из лога поэтому версию не считать, тем более лог предназначен и оптимизирован для последовательной записи, и ходить вперед-назад по нему в поисках версий неоптимально. Зато из tempdb версия считается очень бысто, т.к. там собственно вся запись и лежит

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

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

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

pppNodo 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, т.е. идёт дублирование данных. Вообще-то выглядит как атовизм и скорее всего в следующих версиях тогда команда перевода в версионный режим будет убрана
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059049
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper AlexCzech
2SergSuper. Неактуальные протухшие версии данных постепенно удаляются - гарантированно хранятся только все состояния всех записей начиная с момента T1, где T1 - момент начала самой застарелой snapshot-транзакции
Ну собственно я это же и говорил. Версионный режим мог бы сам включаться при появлении snapshot-транзакций - если их нет, то ненужно никаких версий(либо уже, либо еще)


А мы же не знаем, что там реально происходит... может, это дело именно так и работает. А может, тут есть какая-то засада, которой мы пока не осознали. Лично я убедился, что когда начинаю считать кого-то дураками, не сделавшими очевидную легкореализуемую вещь, то дураком-то в итоге оказываюсь я :)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059125
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>Ну почему же из лога не считать? При откате то считывается

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

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

как это вы себе представляете ? транзакции работают, не создают версий, потом появляется snapshot, и все сразу начинают делать версии ? а как быть с теми, кто уже в процессе ? версии задним числом наплодить ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059430
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 AlexCzech
А я в своё время серьёзно воспринимал статьи от MS что блокировка на уровне строки это неправильно и она никому не нужна, а потом тоже про версионность (правда уже в более мягких формах) :)

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

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

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

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

как это вы себе представляете ? транзакции работают, не создают версий, потом появляется snapshot, и все сразу начинают делать версии ? а как быть с теми, кто уже в процессе ? версии задним числом наплодить ?
а по порядку?
транзакции работают, не создают версий - замечательно
потом появляется snapshot, и все сразу начинают делать версии - не совсем: не все, версии делают только snapshot-транзакции
а как быть с теми, кто уже в процессе? - а кто ж это? обычным транзакциям версии не нужны, а версии для snapshot-транзакций будут делаться при их появлении
версии задним числом наплодить? вот мне непонятно почему задним числом
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059474
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тем, кто хочет разобраться с механизмом версионности, рекомендую сходить сначала сюда
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059771
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2hvlad: Для того что бы разобавться с блокировками и версиями читайте Bernstain'a
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33059797
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikov2hvlad: Для того что бы разобавться с блокировками и версиями читайте Bernstain'aХочется блеснуть знаниями "первоисточников" ? Та ради бога...
Я дал ссылку на то, как это сделано в реально работающем много лет сервере, а не на теорию 30-летней давности. Причём многое там по-русски и разжёвано. Через полгода, как (если) разберётесь в Юконе, будете удивлены.
Впрочем, не хотите - не читайте
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060302
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper
Тем не менее информация для восстановления состояния на начало транзакции там есть, не так ли? Я не вижу принципиальной разницы что восстанавливать эту информацию при откате, что читать snapshot-транзакцей.
К тому же как-то Оракл восстанавливает из лога

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

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

это еще почему ? Разве вы не в курсе, что из себя представляет snapshot ? При ее запуске, все изменения замораживаются, т.е. она видит согласованный срез данных на время старта. Например, какая-нибудь транзакция (напр. read committed) меняет запись. В это время запустилась snapshot, и ей нужна данная запись. Она ее возьмет из tempdb, т.к. сама запись заблокирована. Более того, если теперь зафиксировать первую транзакцию, а из snapshot опять прочитать ту запись, то опять вернется старое значение, не смотря на то, что первая транзакция уже зафиксирована. И все время, пока snapshot жива и здорова, версии лежат в tempdb, даже если запись меняется много раз разными транзакциями.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060327
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerSА в Оракле у них два журнала, один для восстановления транзакций, а другой - для чтения версий. И при работе транзакции, данные пишутся в оба журнала.


Однако... как undo tablespace мощно опустили, оказывается он только для чтения версий пригоден
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060342
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А по существу вопроса Сталкер совершенно прав - transaction log предусматривает СИНХРОННУЮ запись, поэтому писать туда надо как можно меньше. Отсюда и вытекает тот факт, что писать туда версии данных несколько неумно.

А происходит это потому, что undo и redo исторически хранятся в MSSQL вместе как единое целое. Было бы 2 отдельных журнала, тогда можно было б undo-журнал использовать для хранения версий (навскидку, undo-данные писать синхронно не обязательно, достаточно только redo, хотя возможно я где-то и просчитался)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060586
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 StalkerS
Например, строка в данный момент меняется, и заблокирована эксклюзивной блокировкой. Причем меняется только одно поле, а остальные не затрагиваются. Соответственно, в логе имеются данные об изменении этого поля и все. Ну получите вы их, а потом ? Значения остальных полей-то откуда брать ?
Прямо из таблицы - они ж не затрагиваются

Разрешать такой транзакции читать в обход блокировки?
Первый раз читается в обход блокоровки и из лога, потом записывать в tempdb

А как быть с цепочками версий?
А их уже и хранить в tempdb

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

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

это еще почему ? Разве вы не в курсе, что из себя представляет snapshot ? При ее запуске, все изменения замораживаются, т.е. она видит согласованный срез данных на время старта.
Например, какая-нибудь транзакция (напр. read committed) меняет запись. В это время запустилась snapshot, и ей нужна данная запись. Она ее возьмет из tempdb, т.к. сама запись заблокирована. Более того, если теперь зафиксировать первую транзакцию, а из snapshot опять прочитать ту запись, то опять вернется старое значение, не смотря на то, что первая транзакция уже зафиксирована. И все время, пока snapshot жива и здорова, версии лежат в tempdb, даже если запись меняется много раз разными транзакциями.

Т.е. вы только подтвердили что я написал: версии делают только snapshot-транзакции

Ну вобщем ни одного аргумента от вас, которые бы поколебали мою точку зрения я не увидел, только всё по кругу идём.

2 hvlad
Ну почитал я на ibase.ru что написано - примитив, это и так было понятно. К тому же мы о реализации говорим, а в MS SQL она в корне другая
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060607
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
авторА происходит это потому, что undo и redo исторически хранятся в MSSQL вместе как единое целое. Было бы 2 отдельных журнала, тогда можно было б undo-журнал использовать для хранения версий (навскидку, undo-данные писать синхронно не обязательно, достаточно только redo, хотя возможно я где-то и просчитался)

Верится с трудом. DB2 и Oracle реализуют запись в лог используя алгоритм ARIES.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060614
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper2 hvlad
Ну почитал я на ibase.ru что написано - примитив, это и так было понятно. К тому же мы о реализации говорим, а в MS SQL она в корне другаяСудя по тому, что я здесь читаю - не только не примитив, но вообще непонятое.

Насчёт другой реализации в Юконе - не смешите мои тапочки. Конечно она другая - такой смеси блокировок и версий ещё никто не придумывал
Только вот у них даже термины и заголовок записи практически совпадают... случайно конечно
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060662
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Упс недописал.

основное положение ARIES это реализация WAL (Write Ahead Logging) протокола.
То бишь данные на диск попадут асихронно и позже записи в журнал (что синхронно. undo по форме выглядит как тот же самый redo.
То есть это все цепочка redo и undo выглядет как единое целое. И часть есдиного целого не может писаться на диск с асинхронно.

Опять же можно представить ситуацию когда весь буфферный пул (буффер cache кажется так в MS) будет полностью занят измененными страницами.
Нам требуется с диска положить в буфферный пул страницу
Тогда потребуется синхронная запись грязной страницы на диск у которой запись в журнал произошла ранее.
тогда в в решении которое предлагаешь ты (асинхнонно писать undo) будет нарушаться WAL и честно мне пока в голову не приходит идея как это решить. Можно конечно в случае версионности скидывать эту страницу в tempdb, но что тогда будет происходить с производительностью... Короче у этой идеи на мой взгяд больше минусов чем плюсов.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060700
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovКороче у этой идеи на мой взгяд больше минусов чем плюсов.

Возможно :) Это мне так, на уровне концепции в голову пришло, я совершенно не настаиваю. Тем не менее, я сомневаюсь, что Оракл пишет в undo tablespace синхронно, вы уверены в этом ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060778
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060794
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovУ Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.

Ну вот о чем и речь - если бы MS SQL изначально был сделан как Оракл, то можно было бы версионность делать как в Оракле. А так получилось уж как получилось, и по-другому не выйдет :)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060813
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пожалуй это всё и объясняет. Т.е. для единообразия работы данные для отката пишутся не только в лог, но и в tempdb, т.е. идёт дублирование данных. Вообще-то выглядит как атовизм и скорее всего в следующих версиях тогда команда перевода в версионный режим будет убрана

Ubrana ona mozet bitj tolko v tom sluchae , esli MS SQL polnostju perestanet rabotatj kak chistij blokirovochnik. Vot togda ne nuzno budet pisatj starie dannie blja rollbak v tranzaction log- oni pishutsa c tempdb.


Значения остальных полей-то откуда брать ?
Прямо из таблицы - они ж не затрагиваются
Kak za ne zatragivajutsa, pri update zablokirovana vsja zapisj, kak serveru ponjatj kakoe pole sejchas izmenjaetsa ? Smotretj v log ? Poka v log polezet, mozet drugoe pole v toj ze zapisi nachnut update delatj.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060821
ppp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U MS SQL eto pervaja versija DB rabotajushaja s versijami, mozet vozmoznostj vkluchitj/vikluchitj prosto podstrahovka na sluchaj esli chto ne tak pojdet ?
Esli versionnostj budet korrktno rabotatj, to mozet v sledujushej versii SQL
ne budet starogo rezima raboti, vot togda i arhitektura redo/undo budet kak u oracle.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060892
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovУ Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.

Не обязательно после коммита, в реду Оракл пишет постоянно и пишет векторы изменений. При коммите он пишет просто маркер (commit record), благодаря чему коммит происходит очень быстро независимо от продолжительности транзакции и нет необходимости подкоммичивать как это любят делать разработчики под блокировочники. А в undo хранятся снэпшоты старых версий блоков. Кстати изменения в undo tablespaces тоже журналируется в redo независимо от коммита. Например после падения системы незакомиченная транзакция отказтывается так

- применяются redo векторы к данным
- применяются redo векторы к undo данным
- восстановленное undo используется для отката незакомиченной оборвавшейся транзакции
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060896
фифа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovУ Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.
Чушь
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060922
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
все правильно, читаем класиков
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
Данные отмены хранятся в сегменте отката. Сегмент отката
хранится в табличном пространстве и (это крайне важно) защищен журналом повтор-
ного выполнения, как и любой другой сегмент. Другими словами, данные отката обра-
батываются так же, как и данные таблицы или индекса, — изменения в сегментах отка-
та генерируют определенные данные повторного выполнения, которые записываются в
журнал. (Зачем это делается, станет ясно после описания происходящего при сбое сие-
темы). Данные отмены добавляются в сегмент отката и кэшируются в буферном кэше,
как и любые другие данные. Как и генерируемые данные отката, данные повторного вы-
полнения могу состоять из нескольких частей.

Повторное выполнение
Файлы журнала повторного выполнения чрезвычайно важны для базы данных Oracle.
Это журналы транзакций базы данных. Они используются только для восстановления;
единственное их назначение — предоставить необходимую информацию в случае сбоя
экземпляра или носителя. Если на машине, где работает сервер, пропадает питание, что
приводит к сбою экземпляра, сервер Oracle будет использовать активные журналы по-
вторного выполнения для восстановления системы в состояние на момент, непосред-
ственно предшествующий отключению питания. Если происходит сбой диска, сервер
Oracle будет использовать архивные журналы повторного выполнения для восстановле-
ния резервной копии этого диска на соответствующий момент времени. Кроме того, если
случайно удалена таблица или важные данные и это изменение зафиксировано, можно
восстановить потерянные данные с резервной копии, а затем с помощью активного и
архивных файлов журнала повторного выполнения привести их в состояние, соответ-
ствующее моменту, непосредственно предшествующему этому случаю.

....

Так почему же продолжительность фиксации почти не зависит от размера транзак-
ции? До начала фиксации изменений в базе данных, мы уже сделали все самое сложное —
изменили данные, так что  99 , 9  процента работы сделано. Например, уже были выпол-
нены следующие операции:
• в области SGA сгенерированы записи сегмента отката;
• в области SGA сгенерированы измененные блоки данных;
• помещены в буфер журнала повторного выполнения в области SGA данные по-
вторного выполнения для перечисленных выше изменений;
• в зависимости от размера трех предыдущих фрагментов данных и прошедшего вре-
мени, часть их может уже быть сброшена на диск;
• установлены все необходимые блокировки.
При выполнении фиксации осталось сделать следующее.
• Сгенерировать номер системного изменения (SCN — System Change Number) для
транзакции.
• Процессу LGWR надо записать на диск все оставшиеся записи из буфера журна-
ла повторного выполнения, а также записать в активные файлы журнала повтор-
ного выполнения номер SCN. Именно этот шаг и является фактической фикса-
цией. Если этот шаг выполнен, — транзакция зафиксирована. Если запись
транзакции удалена, значит, транзакция зафиксирована. Соответствующая запись
в представлении V$TRANSACTION исчезнет.
• Все блокировки, удерживаемые транзакцией, снимаются, и все сеансы, ожидав-
шие в очередях снятия этих блокировок, могут продолжить работу.
• Многие измененные транзакцией блоки данных будут повторно обработаны и
"очищены" в быстром режиме, если они еще находятся в буферном кэше.
Как видите, для обработки оператора COMMIT надо сделать очень немного.

(C) Tom Kyte
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060949
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вместо того что-бы говорить "чушь'.
Нужно как миниму показать, где написано что это не так. Хотя стоит признать, что я сильно утрировал.

И потом в DB2 время коммита тоже не зависит от размера транзакции. Нужно только буфер журнала сбросить и блокировки в памяти почистить.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060958
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да кстати прошу прощения за неточность. В смысле, что данные в журнал пишутся после коммита. Я имел в виду данные необходимые для коммита.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33060988
фуфа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
nkulikovВместо того что-бы говорить "чушь'.
Нужно как миниму показать, где написано что это не так. Хотя стоит признать, что я сильно утрировал.
У меня нет времени и желания это делать. Моя цель - сказать несведущим гражданам, что эта информация ложна, вводит в заблуждение в том числе и способом еще подачи, не вызывающим у автора сомнений в своей правоте. А значит это - чушь.

Прочитать можно, например, в Oracle Concepts.

nkulikovДа кстати прошу прощения за неточность. В смысле, что данные в журнал пишутся после коммита. Я имел в виду данные необходимые для коммита .
?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33061061
Фотография Пуп
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Фифа nkulikovУ Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.
Чушь

Оленька, это не Вы случайно?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33061069
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovДа кстати прошу прощения за неточность. В смысле, что данные в журнал пишутся после коммита. Я имел в виду данные необходимые для коммита.

Николай, раньше ты выражался точнее и корректнее, вспоминая жаркую тему на форуме ДБ2 про Оракл. Что есть данные для коммита? Для коммита нужен только маркер (коммит рекорд) и всё, всё остальное просто вектора измененийкак закомиченных так и нет. Даже при откате транзакции, данные в реду логах остаются. Наличие или отсутсвие этого маркера и служит меткой, были закомичены те или иные изменения или нет.

В чем ты прав вспоминая опять же ту тему, так это в том что Оракл генерит чрезмерно много выхлопных газов (реду логов), в частности реду генерится даже при select for update что логично так при блокировках изменяются блоки (лок манагера нету, блокировка просто атрибут данных).
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33061423
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33061662
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности ( дескать читатель не блокирует писателя ) от этого - весьма и весьма сомнительны.

Вот ты сам и ответил. Если ты не понимаешь преимуществ неблокирующего чтения, то трудно что то объяснять.

- Нет дедлоков из за чтения
- Нет эскалаций блокировок
- Не нужно вводить вспомогательные таблицы что избежать блокировок
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33061792
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.

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

В блокировочной схеме ради этого столько уловок придумано, что просто любо-дорого смотреть
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062173
michael_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Желтoпузый дьявoл gardenmanВместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности ( дескать читатель не блокирует писателя ) от этого - весьма и весьма сомнительны.

Вот ты сам и ответил. Если ты не понимаешь преимуществ неблокирующего чтения, то трудно что то объяснять.

- Нет дедлоков из за чтения
- Нет эскалаций блокировок
- Не нужно вводить вспомогательные таблицы что избежать блокировок
По блокировкам все понятно.
А вот по производительности, действительно, не ясно, MS SQL, DB2 и Oracle судя по всем тестам приблизительно равны. То есть, очевидных преимуществ по скорости нет ни у кого... На Win так нередко MS SQL быстрее всех. Так что, не все так просто.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062257
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech gardenmanВместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.

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

В блокировочной схеме ради этого столько уловок придумано, что просто любо-дорого смотреть

ОК! Предположим, вы получаете баланс предприяния (ну или банка). Отчет формируется минут 15... (на самом деле - быстрее, ну это у кого как)
В результате на версионнике у вас все ок!- дебет с кредитом сходится.
Запускаете этот же отчет снова, через одну минуту. И, что? получаете другие цифры?... Если нет (цифры одинаковы) - значит данные по которым вы формируете отчет - стабильны. А смысл в версионности в этом случае?
А вот если вы получите другие цифры - значит данные поменялись, и глав бух пишет телегу вашему шефу и в лучшем случае - выговор + 50% лишения премии.
Мысль такова - что долгоиграющие отчеты по нестабильным данным - обсолютно не имеют смысла.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062262
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
michael_
По блокировкам все понятно.
А вот по производительности, действительно, не ясно, MS SQL, DB2 и Oracle судя по всем тестам приблизительно равны. То есть, очевидных преимуществ по скорости нет ни у кого... На Win так нередко MS SQL быстрее всех. Так что, не все так просто.

Это потому, что сложно найти задачу, которая бы могла быть решена эффективно в одной СУБД но не могла бы в другой. СУБД достаточно развиты и есть куча приемов и подходов для разных случаев. Но у каждого приёма есть свои drawbacks, версионность стоит доплнительного места на диске и дополнительного реду на них. Блокировочник чреват эскалациями, дедлоками, ожиданиями и немаштабируемостью. При дизайне апликухи нужно эти особенности учитывать. Например совсем недавно на Оракл обсуждалось что приложение уж слишком много генерит реду информации из за неудачного дизайна.

Log фалы - генерится большой объём - можно как-то уменьшить?

На MS SQL часты темы как отлавливать, предотвращать уменьшать вероятность появления блокировок.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062311
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman
Мысль такова - что долгоиграющие отчеты по нестабильным данным - обсолютно не имеют смысла.

Вы это лучше не мне рассказывайте, а гендиректору клиента, который запросил оборотно-сальдовую ведомость, и у него по дебету получилось 2 миллиона, а по кредиту 2 миллиона 15 копеек
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062366
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062376
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))

Вовсе не обязательно
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062610
Фотография Vadim_Maximov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech gardenman)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))

Вовсе не обязательно
Поясните плз, как по-вашему может возникнуть подобная ситуация в Oracle?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062660
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Долгостроящиеся отчеты это классический пример. Версионник предоставляет их на момент начала запроса восстанавливая при необходимости старые версии данных. Блокировочник на момент окончания запроса. Версионник может вылетить с ошибкой snapshot too old если у админа руки кривые, а блокировочник может кучу операций заблокировать либо зам запнуться и ждать окончания транзакции неизвестно сколько. Для блокировочника с этой целью вводятся обычно вспомогательные таблицы что есть таже самая цена которую платит версионник местом для undo информации.

И вообще что есть актуальность отчета при постоянно идущими операциями к базе. Когда начальник берет в руки распечатку отчета он уже не актуален, так что минутами раньше или позже это уже не принципиально. Если уж нужно оперативное его получение, то стоит задуматься о материализованных представлениях, где конечные данные отчета хранятся поддерживаются в готовом или полуготовом виде.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062749
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062802
DimaR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВ том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.

Ну не у всех комунизм, и идеальная система,
у некоторых, сотни пользователей меняют данные, в т.ч. за прошедший перод, и при этом за это же время нужно делать отчеты, и это считается вполне нормальным.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062823
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DimaR gardenmanВ том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.

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

Это вы налоговой инспекции объясняйте, а не мне
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062879
michael_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexCzech gardenman
Мысль такова - что долгоиграющие отчеты по нестабильным данным - обсолютно не имеют смысла.

Вы это лучше не мне рассказывайте, а гендиректору клиента, который запросил оборотно-сальдовую ведомость, и у него по дебету получилось 2 миллиона, а по кредиту 2 миллиона 15 копеек

Если проводки в базе лежат двусторонние, то есть в одной строке таблицы Дт, Кт, Сумма, то у Вас дебет всегда с кредитом сойдется, хоть это версионник, хоть блокировочник, хоть файл-сервер
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062882
Alexey Sh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DimaR gardenmanВ том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.

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

Ну тогда без разницы, снапшот или грязное чтение.
Последнее - экономичнее :)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062887
AlexCzech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vadim_Maximov AlexCzech gardenman)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))

Вовсе не обязательно
Поясните плз, как по-вашему может возникнуть подобная ситуация в Oracle?

Это либо не ко мне вопрос, либо если ко мне - то у нас это было вовсе не в Оракле, а как раз таки в MS SQL
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33062910
Фотография Желтoпузый дьявoл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВ том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным.

Еще бы, иначе и быть не может. Не хватало еще чтобы для отчетов грязное чтение использовалось, тогда с распечатанным отчетом можно сразу смело идти в туалет.

gardenman Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.

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

Еще раз. При постоянно работающей базе уже не принципиально на какой момент отчет актуален - на момент начал запроса или на момент выхода бумаги из принтера. Не принципиально потому что база все равно изменяется, и на момент прочтения отчета данные уже другие. Это как электрический счетчик. Глянул его, внес данные и пошел платить а он крутит себе дальше.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33063369
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper
Прямо из таблицы - они ж не затрагиваются
...
Первый раз читается в обход блокоровки и из лога, потом записывать в tempdb
...
>>А как быть с цепочками версий?
А их уже и хранить в tempdb

в общем, вы изобрели свой собственный вариант реализации версионности, и пытаетесь доказать, что он лучше, чем у microsoft. Занятие это конечно увлекательное, но совершенно бесполезное.

Я к примеру, с трудом представляю себе реализацию, когда версии будет наполовину читаться из лога, а наполовину - из таблиц в обход блокировок. Это фактически - грязное чтение. Наверно, весело программировать реализацию, которая будет гарантировать целостность при таком подходе (прежде, чем считать значение поля, надо убедиться, что в логе нет данных о том, что оно уже успело поменяться, а в логе их кстати, может еще и не быть, там буфер лога есть и пр. приколы). А самое главное зачем ? Что-бы сэкономить на копировании записи ? А вам не приходит в голову, чем выльется эта экономия при чтении версии ? Какую массу работы надо будет произвести, что-бы получить версию в нормальном виде ?
SergSuper
Зато не надо в два места писать. Можно было бы лог как-то оптимизировать

Лог и так оптимизирован по самое не балуйся, с учетом того, что-бы как можно меньше информации в него писать. С чего вы вообще взяли, что писать в два места дольше, чем все сразу в лог ? В большинстве случаев, меняется назначительная часть строки, эти изменения и отражаются в логе. Вы вообще в курсе, что сервер не имеет права скидывать на винт грязные страницы данных, пока лог их изменений еще в памяти ? Неужели надо обьяснять, что запись на винт много медленее ? Не смешите людей
SergSuper
Т.е. вы только подтвердили что я написал: версии делают только snapshot-транзакции

Ну а тут я и вообще не понимаю, о чем речь. Согласно правилам русского языка, выражение "версии делают только snapshot-транзакции" означает, что snapshot сами делают версии, что противоречит обьективной реальности. Что вы тут имеете в виду - тайна за семью печатями.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33063506
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Лог оптимизирован для записи, и если из него начнется чтение - то будет проседать производительность пишущих транзакций. Так как во время чтения из лога нельзя туда ничего писать. Что и наблюдается при транзакционной репликации и при дифференциалных бекапах. К тому же информация в лог попадает в основном, исключая коммиты, асинхронно - так как есть WAL. Поэтому из лога нельзя однозначно восставновить текущее состояние записи - есть вероятность что информация об этом в лог еще не попала, а лежит в буферах в памяти. Но если все же начать читать из лога, и использовать буфера для сбора недостающей на диске информации - то работать это будет намного медленнее решения которое оптимизировано на чтение.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33065388
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уважаемый andsm
Не уверен, что log оптимизирован только для записи.... Ибо если он оптимизирован только для записи тогда время восстановления должно быть в гораздо больше времени резервного копирования, что не так. Не понятно почему его нельзя будет читать и писать одновременно, как тогда по вашему MS-SQL и DB2 откатывают транзации???? Также при репликации (которая сделана через чтение лога) в DB2 сильного просаживания что-то не видно... Я в данный момент разбираюсь как это все устроено в Oracle, что-то не видно что там тоже все ориентированно под запись. Хотя я до конца еще не разобрался.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33065476
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Транзакции откатываются в разы медленнее чем они коммитятся. При этом как правило для отката транзакции не нужно ничего читать из лога, вся эта информация есть в буферах в памяти. Вообще-то на основе этого еще нельзя сказать что лог оптимизирован только для записи - скорее надо сравнить время на запись в лог какой-то длинной транзакции, и время на ее redo при восстановлении. При этом естественно нужно чтобы после коммита не было чекпойнтов. Ну и вспоминая прочитанные книги - в них тоже говорилось что лог оптимизирован для записи.
Почему нельзя одновременно читать и писать. Пусть у нас есть диск, предназначенный только для лога. Ну или рекомендуемый RAID1 для лога. Заметной разницы между обоими случаями нет. Пришел запрос, например от агента транзакционной репликации - прочитать такой-то кусок лога. Головки диска пошли искать это место в логе. В это время исполняются транзакции. Пришел commit, от одной из транзакций. Commit - это синхронная операция, ей нужно дождаться окончания записи всей информации о транзакции на диск. На момент пока идет поиск нужного сектора, чтение из него, в лог ничего не пишется - головки не на том месте. Т.е. ждут коммиты - и видно увеличение времени некоторых транзакций, которые идут в это время. В счетчиках виден всплеск времени ожидания на запись в лог. Это вполне реальная наблюдаемая проблема - в момент работы репликации, когда агент читает лог, идет рост времени прохождения транзакций с 20-30 ms до 100-400 ms. Из-за этой проблемы меняем дисковую систему на более скоростную (и во много раз дороже) - при том что у нас и так была скоростная система - лог на аппаратном RAID1, скази, 15000 RPM. Думаю в DB2 такая же проблема с репликацией - в MS SQL транзакционная репликация тоже сделана через чтение лога.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33067308
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
автор
Транзакции откатываются в разы медленнее чем они коммитятся.

Потому как для коммита нужно сбросить буффер журнала, и почистить блокировки, а для отката вернуть все сделанные изменения взад :)
В общем случае время отката примерно равно времени превыдущих изменений.

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


Неужели... Мне кажется в общем случае это не так, как минимум это зависит от размера транзакции.

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

Я примерно про это, только в DB2 checkpoints нету. Так что сравнивать нужно для каждой БД по отдельности. Мой опыт говорит, что время отката процентов на 5 больше времени всех превыдущих изменений. И беда отката не в том что он на 5 процентов больше, а в том что все остальные ждут пока он произойдет.

автор
Почему нельзя одновременно читать и писать. Пусть у нас есть диск, предназначенный только для лога. Ну или рекомендуемый RAID1 для лога. Заметной разницы между обоими случаями нет. Пришел запрос, например от агента транзакционной репликации - прочитать такой-то кусок лога. Головки диска пошли искать это место в логе.
В это время исполняются транзакции. Пришел commit, от одной из транзакций. Commit - это синхронная операция, ей нужно дождаться окончания записи всей информации о транзакции на диск.


В общем случае это не вся информация, а только часть (буфер)
Да увеличение будет, но это не связано с тем что лог оптимизирован только под запись. Возможно в вашей задаче это так, но у меня в задачах в разы увеличения не было. Опять же задачи, то разные....
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33068094
andsm...При этом как правило для отката транзакции не нужно ничего читать из лога...
А когда нужно, можно подробнее?

andsmВообще-то на основе этого еще нельзя сказать что лог оптимизирован только для записи - скорее надо сравнить время на запись в лог какой-то длинной транзакции, и время на ее redo при восстановлении.
Так все-таки, для чего же он оптимизирован - для записи или чтения. Или того и другого?


andsmПришел запрос, например от агента транзакционной репликации - прочитать такой-то кусок лога. Головки диска пошли искать это место в логе.
А можно ссылочку (в доке или еще где), где об этом можно прочитать?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33069972
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Внимательный читатель andsm...При этом как правило для отката транзакции не нужно ничего читать из лога...
А когда нужно, можно подробнее?
Это зависит от размера транзакции и от размера доступной памяти на сервере. Чем больше транзакция, тем выше вероятность что придется при откате читать журнал транзакций.

Внимательный читатель
andsmВообще-то на основе этого еще нельзя сказать что лог оптимизирован только для записи - скорее надо сравнить время на запись в лог какой-то длинной транзакции, и время на ее redo при восстановлении.
Так все-таки, для чего же он оптимизирован - для записи или чтения. Или того и другого?

Я думаю что для записи. Мнение основано и на своем опыте, и на прочитанной литературе.
Внимательный читатель
andsmПришел запрос, например от агента транзакционной репликации - прочитать такой-то кусок лога. Головки диска пошли искать это место в логе.
А можно ссылочку (в доке или еще где), где об этом можно прочитать?
Про то как идет чтение с диска или как работает LogReader agent? Про чтение с диска описано во многих книгах, про LogReader можно прочиать в BOL
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33079527
bantik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господа посмотрите на топик, а заодно на адрес пишущего ...
Многие вопросы уже получили ответ, но у меня еще больше новых появилось :-)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33079535
bantik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bantikГоспода посмотрите на топик, а заодно на адрес пишущего ...
Многие вопросы уже получили ответ, но у меня еще больше новых появилось :-)

http://forum.privet.com/viewtopic.php?t=48469&postdays=0&postorder=asc&&start=25&sid=09cc356d703e1d9731da2d319bdb25f3
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33079992
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS
в общем, вы изобрели свой собственный вариант реализации версионности, и пытаетесь доказать, что он лучше, чем у microsoft.

Так это изобретение как раз у microsoft.

Поэтому далее Ваши рассуждения про грязное чтение относятся к нему же.

Меня удивляет тока то, что Вы верите, что так легко можно опровергнуть общепризннанные факты. Я про то, что Вы скорее всего попытаетесь сказать, что в Оракле грязное чтение. Этого вроде не утвержает и самый microsoft. Более того, он с теми же целями вводит свою версионность. Впрочем ее Вы уже поспешено раскритиковали в пух и прах. Я Ораклист, а все же не думаю, что в microsoft не такие парни сидят, что не учесть тех мыслей, что Вы высказали.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33082713
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo
Я про то, что Вы скорее всего попытаетесь сказать, что в Оракле грязное чтение.
Это где там в моем посте хоть раз написано слово Оракл ? Он здесь вообще не причем. Подозреваю, что у вас появилась какая-то фобия, в каждом моем слове видите нападки на него.
vadiminfo
Меня удивляет тока то, что Вы верите, что так легко можно опровергнуть общепризннанные факты.
какие собственно общепризнанные факты я пытался легко опровергнуть ?
vadiminfo
Поэтому далее Ваши рассуждения про грязное чтение относятся к нему же.
к кому-же ?
vadiminfo
Впрочем ее Вы уже поспешено раскритиковали в пух и прах.
КОГО ? версионность ? я ? раскритиковал ? ГДЕ ?
vadiminfo
Более того, он с теми же целями вводит свою версионность.
в принципе, если вы не в курсе, само по себе грязное чтение никуда из Yukon'a не делось, при блокировочном режиме работы им вполне можно пользоваться.
ну а версионность будет использоваться только в тех задачах, где нужна, и там грязное чтение отпадает за ненадобностью.
vadiminfo
Я Ораклист
я в курсе ;)
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33082945
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS
Это где там в моем посте хоть раз написано слово Оракл ? Он здесь вообще не причем. Подозреваю, что у вас появилась какая-то фобия, в каждом моем слове видите нападки на него.

В теме фигурирут Оракл и Скуль. Скуль Вы критиковань ни за что не будете, поскольку Вы апологет оного. Значит путем нехитрых рассуждений получаем тот самый Оракл как потенциальный объект критики.)
Возможно, на самом деле Вы критиковали SergSuper. Но он ведь тоже на Вашей стороне за Скуль выступает? Зачем тада Вы его критикуете, када полно Ораклистов вокруг, нуждающихся в критике Скулистов?)

StalkerS
какие собственно общепризнанные факты я пытался легко опровергнуть ?


Ну, я про версионность Оракла. Она признана как недопускающая грязного чтения. Мне показалось, что Вы намекали, что это Оракл придумал свою версионность ни на что негодную. Если не так, то забираю свои слова обратно.
Был не внимателен. Жара.

StalkerS
к кому-же ?


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

StalkerS
КОГО ? версионность ? я ? раскритиковал ? ГДЕ ?


Хорошо. Реализацию версионности у того или другого СУБД или представления о ней коллег Вы критиковали? Было дело?
Там были Ваши слова "Это фактически - грязное чтение. " Для механизма версиооности - это приговор. Я, наверное, ошибочно принял это на счет Оракла, помятуя о Ваших прежних постах. Теперь перечитал и вижу, что Вы там с Вашим коллегой по СУБД не соглашались. Это все-таки еще не привычно.

StalkerS
в принципе, если вы не в курсе, само по себе грязное чтение никуда из Yukon'a не делось, при блокировочном режиме работы им вполне можно пользоваться.
ну а версионность будет использоваться только в тех задачах, где нужна, и там грязное чтение отпадает за ненадобностью.

Благодаря Вам я уже давно знаю, это предположение. Однако, существует и другая версия поддержки двух моделей транзакций. Юкон еще не может положиться на свой механизм версионности или вообще она там празно себя будет пока являть и потому остается еще в большей степени блокировочником. Так например у Скуля 2000 есть отключение эскалации блокировок. Но ее мало кто включает, даже если блокировки достали окончательно.
Это всего лишь предположение, но требующее проверки временем.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33082978
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
авторТак например у Скуля 2000 есть отключение эскалации блокировок. Но ее мало кто включает, даже если блокировки достали окончательно.

где, в sql2k ? как ?
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33082990
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo!!
где, в sql2k ? как ?

Что есть? читал не то на этом форуме, не то в каких-то статьях в инете по сравнению СУБД Оракл и Скуль. Причем возможно с Юконом, но там было примечание автора про MS SQL 2000. Возможно, даже в двух местах. Вроде с помощью какого-то, возможно, не документированного параметра. Но это включение, насколько я, понял может привести к значительным расходам ресурсов на поддержание инфы о блокировках. В общем, если бы не было проблем, то явно бы эскалацию отключили раз и на всегда.
...
Рейтинг: 0 / 0
Появление версионника в Yukon лишает Oracle всяких преимуществ!
    #33082999
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo
Возможно, на самом деле Вы критиковали SergSuper. Но он ведь тоже на Вашей стороне за Скуль выступает? Зачем тада Вы его критикуете, када полно Ораклистов вокруг, нуждающихся в критике Скулистов?)
не, у вас определенно фобия ;) собственно почему я тут обязан критиковать только ораклистов ? (тем более, что SergSuper я не критиковал, просто свои мысли высказывал, неужели так резко высказал, что за критику воспринимается ?)
vadiminfo
К Скулю. Мы не можем пока точно установить ошибаются Ваши коллеги в логике работы Юкона или нет. Потому раз Вы их критикуете, то, возможно, это критика Юкона, если они правильно описали логику.
SergSuper не описывал работу Yukon, он высказал мысль, что реализация версионности там какая-то неправильная, и предложил свой вариант. В частности, ему не нравилось то, что при создании версии изменяемой строки, эта строка копируется в tempdb (version store heaps), он сказал, что выгоднее будет не создавать версий, а собирать версию из кусков - часть из лога и часть из самой таблицы. Я не согласился, вот собственно и все.
vadiminfo
Там были Ваши слова "Это фактически - грязное чтение. "
как раз эти слова и относились к его варианту - он сказал, что не будет ничего страшного, если нужная информация для версии считается из таблицы в обход эксклюзивных блокировок - т.е. описал грязное чтение, на что я и ответил, что если такое реализовать, то представляется сомнительным надежность и производительность такого механизма.
vadiminfo
Юкон еще не может положиться на свой механизм версионности или вообще она там празно себя будет пока являть
что значит не может положиться ? Понятно, что с выходом Yukon я не брошусь на рынок за ним, что-бы немедленно перевести на него наш сервер, но это обычный порядок, когда появляется новый продукт, нет гарантий о его надежности, это относиться не только к СУБД, но и вообще ко всем системам.
vadiminfo
Так например у Скуля 2000 есть отключение эскалации блокировок. Но ее мало кто включает, даже если блокировки достали окончательно
...
Возможно, даже в двух местах. Вроде с помощью какого-то, возможно, не документированного параметра. Но это включение, насколько я, понял может привести к значительным расходам ресурсов на поддержание инфы о блокировках.
что-то не понял, вы полагаете, что эсколацией не пользуются что-ли ? Да, ее можно отключить (включив флаг трассировки DBCC TRACEON(1211)), но делать этого не рекомендуется
vadiminfo
Был не внимателен. Жара.
да, я уже неделю сижу в Москве, и погода последних дней достала полностью. Поскорее бы вернуться домой, у нас там сейчас климат помягче ;)
...
Рейтинг: 0 / 0
101 сообщений из 101, показаны все 5 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Появление версионника в Yukon лишает Oracle всяких преимуществ!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]