powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Появление версионника в Yukon лишает Oracle всяких преимуществ!
25 сообщений из 101, страница 3 из 5
Появление версионника в 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
25 сообщений из 101, страница 3 из 5
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Появление версионника в Yukon лишает Oracle всяких преимуществ!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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