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

Откуда:
Сообщений: 729
А по существу вопроса Сталкер совершенно прав - transaction log предусматривает СИНХРОННУЮ запись, поэтому писать туда надо как можно меньше. Отсюда и вытекает тот факт, что писать туда версии данных несколько неумно.

А происходит это потому, что undo и redo исторически хранятся в MSSQL вместе как единое целое. Было бы 2 отдельных журнала, тогда можно было б undo-журнал использовать для хранения версий (навскидку, undo-данные писать синхронно не обязательно, достаточно только redo, хотя возможно я где-то и просчитался)
12 май 05, 16:30    [1533820]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
SergSuper
Member

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

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

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

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

SergSuper

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

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

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

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

2 hvlad
Ну почитал я на ibase.ru что написано - примитив, это и так было понятно. К тому же мы о реализации говорим, а в MS SQL она в корне другая
12 май 05, 17:38    [1534195]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
автор
А происходит это потому, что undo и redo исторически хранятся в MSSQL вместе как единое целое. Было бы 2 отдельных журнала, тогда можно было б undo-журнал использовать для хранения версий (навскидку, undo-данные писать синхронно не обязательно, достаточно только redo, хотя возможно я где-то и просчитался)


Верится с трудом. DB2 и Oracle реализуют запись в лог используя алгоритм ARIES.
12 май 05, 17:46    [1534226]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
hvlad
Guest
SergSuper
2 hvlad
Ну почитал я на ibase.ru что написано - примитив, это и так было понятно. К тому же мы о реализации говорим, а в MS SQL она в корне другая
Судя по тому, что я здесь читаю - не только не примитив, но вообще непонятое.

Насчёт другой реализации в Юконе - не смешите мои тапочки. Конечно она другая - такой смеси блокировок и версий ещё никто не придумывал
Только вот у них даже термины и заголовок записи практически совпадают... случайно конечно
12 май 05, 17:48    [1534235]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
Упс недописал.

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

Опять же можно представить ситуацию когда весь буфферный пул (буффер cache кажется так в MS) будет полностью занят измененными страницами.
Нам требуется с диска положить в буфферный пул страницу
Тогда потребуется синхронная запись грязной страницы на диск у которой запись в журнал произошла ранее.
тогда в в решении которое предлагаешь ты (асинхнонно писать undo) будет нарушаться WAL и честно мне пока в голову не приходит идея как это решить. Можно конечно в случае версионности скидывать эту страницу в tempdb, но что тогда будет происходить с производительностью... Короче у этой идеи на мой взгяд больше минусов чем плюсов.
12 май 05, 18:06    [1534301]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
nkulikov
Короче у этой идеи на мой взгяд больше минусов чем плюсов.


Возможно :) Это мне так, на уровне концепции в голову пришло, я совершенно не настаиваю. Тем не менее, я сомневаюсь, что Оракл пишет в undo tablespace синхронно, вы уверены в этом ?
12 май 05, 18:21    [1534368]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
У Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.
12 май 05, 18:56    [1534475]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
nkulikov
У Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.


Ну вот о чем и речь - если бы MS SQL изначально был сделан как Оракл, то можно было бы версионность делать как в Оракле. А так получилось уж как получилось, и по-другому не выйдет :)
12 май 05, 19:05    [1534499]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
ppp
Member

Откуда:
Сообщений: 278
Пожалуй это всё и объясняет. Т.е. для единообразия работы данные для отката пишутся не только в лог, но и в 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.
12 май 05, 19:15    [1534526]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
ppp
Member

Откуда:
Сообщений: 278
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.
12 май 05, 19:20    [1534536]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Желтoпузый дьявoл
Member

Откуда:
Сообщений: 113
nkulikov
У Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.


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

- применяются redo векторы к данным
- применяются redo векторы к undo данным
- восстановленное undo используется для отката незакомиченной оборвавшейся транзакции
12 май 05, 20:12    [1534647]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Фифа
Guest
nkulikov
У Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.

Чушь
12 май 05, 20:14    [1534651]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Yo!!
Guest
все правильно, читаем класиков
Данные отмены хранятся в сегменте отката. Сегмент отката
хранится в табличном пространстве и (это крайне важно) защищен журналом повтор-
ного выполнения, как и любой другой сегмент. Другими словами, данные отката обра-
батываются так же, как и данные таблицы или индекса, — изменения в сегментах отка-
та генерируют определенные данные повторного выполнения, которые записываются в
журнал. (Зачем это делается, станет ясно после описания происходящего при сбое сие-
темы). Данные отмены добавляются в сегмент отката и кэшируются в буферном кэше,
как и любые другие данные. Как и генерируемые данные отката, данные повторного вы-
полнения могу состоять из нескольких частей.

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

....

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

(C) Tom Kyte
12 май 05, 20:45    [1534686]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
Вместо того что-бы говорить "чушь'.
Нужно как миниму показать, где написано что это не так. Хотя стоит признать, что я сильно утрировал.

И потом в DB2 время коммита тоже не зависит от размера транзакции. Нужно только буфер журнала сбросить и блокировки в памяти почистить.
12 май 05, 21:20    [1534717]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
Да кстати прошу прощения за неточность. В смысле, что данные в журнал пишутся после коммита. Я имел в виду данные необходимые для коммита.
12 май 05, 21:28    [1534730]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
фуфа
Guest
nkulikov
Вместо того что-бы говорить "чушь'.
Нужно как миниму показать, где написано что это не так. Хотя стоит признать, что я сильно утрировал.

У меня нет времени и желания это делать. Моя цель - сказать несведущим гражданам, что эта информация ложна, вводит в заблуждение в том числе и способом еще подачи, не вызывающим у автора сомнений в своей правоте. А значит это - чушь.

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

nkulikov
Да кстати прошу прощения за неточность. В смысле, что данные в журнал пишутся после коммита. Я имел в виду данные необходимые для коммита.

?
12 май 05, 21:55    [1534769]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Пуп
Member

Откуда:
Сообщений: 386
Фифа
nkulikov
У Оракла другая архитектура журнaлирования. В редо оказываются данные после коммита. А все промежуточные данные варятся в undo-tablespaces.

Чушь


Оленька, это не Вы случайно?
13 май 05, 00:15    [1534890]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Желтoпузый дьявoл
Member

Откуда:
Сообщений: 113
nkulikov
Да кстати прошу прощения за неточность. В смысле, что данные в журнал пишутся после коммита. Я имел в виду данные необходимые для коммита.


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

В чем ты прав вспоминая опять же ту тему, так это в том что Оракл генерит чрезмерно много выхлопных газов (реду логов), в частности реду генерится даже при select for update что логично так при блокировках изменяются блоки (лок манагера нету, блокировка просто атрибут данных).
13 май 05, 00:23    [1534899]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Вместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.
13 май 05, 10:14    [1535366]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Желтoпузый дьявoл
Member

Откуда:
Сообщений: 113
gardenman
Вместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.


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

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

Откуда:
Сообщений: 729
gardenman
Вместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.


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

В блокировочной схеме ради этого столько уловок придумано, что просто любо-дорого смотреть
13 май 05, 12:00    [1536001]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
michael_
Member

Откуда: Москва
Сообщений: 600
Желтoпузый дьявoл
gardenman
Вместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.


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

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

По блокировкам все понятно.
А вот по производительности, действительно, не ясно, MS SQL, DB2 и Oracle судя по всем тестам приблизительно равны. То есть, очевидных преимуществ по скорости нет ни у кого... На Win так нередко MS SQL быстрее всех. Так что, не все так просто.
13 май 05, 13:22    [1536525]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
AlexCzech
gardenman
Вместо того, чтобы спорить о том, как кто устроен, Хоть бы раз последовательно доказали что что версионник лучше блокировочника на примере какой-либо конкретной задачи. Ведь в результате окажется что версионность - это только накладные расходы, а выгоды в производительности (дескать читатель не блокирует писателя) от этого - весьма и весьма сомнительны.


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

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


ОК! Предположим, вы получаете баланс предприяния (ну или банка). Отчет формируется минут 15... (на самом деле - быстрее, ну это у кого как)
В результате на версионнике у вас все ок!- дебет с кредитом сходится.
Запускаете этот же отчет снова, через одну минуту. И, что? получаете другие цифры?... Если нет (цифры одинаковы) - значит данные по которым вы формируете отчет - стабильны. А смысл в версионности в этом случае?
А вот если вы получите другие цифры - значит данные поменялись, и глав бух пишет телегу вашему шефу и в лучшем случае - выговор + 50% лишения премии.
Мысль такова - что долгоиграющие отчеты по нестабильным данным - обсолютно не имеют смысла.
13 май 05, 13:40    [1536654]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Желтoпузый дьявoл
Member

Откуда:
Сообщений: 113
michael_

По блокировкам все понятно.
А вот по производительности, действительно, не ясно, MS SQL, DB2 и Oracle судя по всем тестам приблизительно равны. То есть, очевидных преимуществ по скорости нет ни у кого... На Win так нередко MS SQL быстрее всех. Так что, не все так просто.


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

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

На MS SQL часты темы как отлавливать, предотвращать уменьшать вероятность появления блокировок.
13 май 05, 13:40    [1536659]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

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

Мысль такова - что долгоиграющие отчеты по нестабильным данным - обсолютно не имеют смысла.


Вы это лучше не мне рассказывайте, а гендиректору клиента, который запросил оборотно-сальдовую ведомость, и у него по дебету получилось 2 миллиона, а по кредиту 2 миллиона 15 копеек
13 май 05, 13:53    [1536726]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить