Привет, Merle!
Вы пишешь 21 декабря 2005:
А>> жаль в TPC-C нельзя вычислить режим.
M> Там и вычислять не надо, никто в здравом уме не будет делать M> OLTP задачу в версионном режиме, если есть в наличии M> отлично работающий блокировочный.
Здравствуйте, vgrigor, Вы писали:
V>поясните нам почему блокировка — лучше отсутсвия блокировки?
Потому что OLTP это тот класс задач где велика вероятность конфликта, а стоимость разруливания конфликта для версионного механизма намного выше чем для блокировочного, так как конфликт версий фактически означает откат транзакции. При этом в OLTP транзакции очень короткие, и среднее время ожидания на блокировке примерно равно времени поиска предыдущей версии, но на поиск версии тратится ресурсов больше.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>> Особенно если учесть, что о работах по MVCC ты узнал пару дней назад — из этого топика и благодаря Алексу. M>
Т.е. не отрицаешь, ок. Может тогда не будешь мне повсюду предлагать перечитать эти работы ? А то создаётся впечатление, что ты знаешь и понимаешь их от коркм до корки... ложное впечатление однако...
А>>Я не люблю, когда люди говорят неправду о том, чего не понимают M>Что именно из того что я сказал является по твоему неправдой? Я пытаюсь добиться внятного ответа на этот вопрос уже на протяжении нескольких постингов. Можно быть всетаки более конкретным?
Я несколько раз перечислил. Перечитай ветку и обрати внимание на то место, где я встрял. И спроси себя — а зачем он встрял
M>А то мой запас терпения потихоньку испаряется.
Вах! И что же будет ?
А>>Ты утверждаешь, что IB\FB откатывает нечто в случае конфликта обновления. M>Нет. Я утверждаю, что версионный механизм (не важно какой) вынужден откатывать в случае конфликта обновления на любых уровнях изоляции выше RC (он так устроен, за подробностями к Бернстайну, хотя бы). И что на практике известные мне версионники в большинстве случаев откатывают даже при RC. M>Как меня совершенно корректно поправили в соседней подветке, в IB есть режимы которые позволяют не откатывать транзакцию. Отлично, я в IB не краевед, хорошо если так, но к поднятому здесь вопросу это имеет довольно посредственное отношение.
Ё-маё... IB никогда сам не откатывает тр-цию ! Повтори себе это N раз. Или M
А>>Ты не уточняешь что такое это нечто, но из твоих рассуждений очевидно, что ты не делаешь никакой разницы между откатом оператора и откатом тр-ции. M>Во-первых я очень конкретно говорю, что именно откатывается, если это имеет значение в обсуждаемом контексте и даже специально уточняю. А во-вторых, то что я не делаю разницы — это не более чем плод чей-то довольно возмущенной фантазии.
Да ? И где же ты хоть раз "очень конкретно" сказал ? Да хоть перечитай абзац выше
А>>В чём же я заблуждаюсь ? M>Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
Это не заблуждение. Это наблюдение. Можешь провести опрос.
А>>SET XACT_ABORT это тоже параметр, задаваемый клиентом. M>Давай ты тогда сначала дашь определение клиента, а заодно и сервера, а потом мы продолжим этот разговор, причем скорее всего в отдельной ветке.
Мне есть чем заняться, поверь.
А>> Подумай хорошенько, перед тем как ошибаться опять. M>Вот только давай без демагогии. Покажи, сначала, где я ошибся хоть один раз, потом поговорим.
Я разве мало показал ?
А>>Еще раз — перестань ставить знак равно между откатом оператора и тр-ции. M>Покажи хоть одно место, где я его ставил.
Покажи хоть одно место, где ты его не ставил.
А>>А причём тут процесс ? M>Понятно, дальше можешь не продолжать. Все вопросы снимаются, с темой предлагаю завязывать.
Давно пора
А>> Только не нужно высказываться о IB\FB — ты совершенно не владеешь вопросом. M>А я вообщем-то и не высказывался. Это вы тут налетели со своим IB на перевес вообще не разобравшись о чем идет речь, хотя я до последнего старался никаких конкретных серверов вообще неупоминать.
Здравствуйте, vgrigor, Вы писали:
V>что я хотел узнать — когда именно лучше в реальном приложении, V>пир каких действиях и установках.
Когда строится много отчетов по активно изменяющимся данным.
Здравствуйте, Аноним, Вы писали:
А>>>В чём же я заблуждаюсь ? M>>Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
А>Это не заблуждение. Это наблюдение. Можешь провести опрос.
Давай ты там не будешь подписываться за MSSQL кодеров, к которым ты не имеешь никакого отношения и ничего не знаешь о них. Наблюдательный ты наш.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, Аноним, Вы писали:
А>>>>>В чём же я заблуждаюсь ? M>>>>Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
А>>>Это не заблуждение. Это наблюдение. Можешь провести опрос.
___>>Давай ты там не будешь подписываться за MSSQL кодеров, к которым ты не имеешь никакого отношения и ничего не знаешь о них. Наблюдательный ты наш.
А>А ведь ты не знаешь ни где я работаю, ни что я делаю, ни с каким сервером...
Ну ты расскажи нам. "А мужики-то не знают" как ты крут. Но судя насчет: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..." — в этом вопросе ты не разбираешься. Но, тем не менее, делаешь безапеляционные заявления. Того, что ты сюда запостил достаточно тебя характеризует. Рекомендую поменьше понтов и побольше конструктива. И давай ты будешь делать заявления от своего имени, а не от T-SQL кодеров — т.е. в том числе от меня. Ага?
Здравствуйте, Аноним, Вы писали:
___>>Ну ты расскажи нам. "А мужики-то не знают" как ты крут. Но судя насчет: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..." — в этом вопросе ты не разбираешься. Но, тем не менее, делаешь безапеляционные заявления. Того, что ты сюда запостил достаточно тебя характеризует. Рекомендую поменьше понтов и побольше конструктива. И давай ты будешь делать заявления от своего имени, а не от T-SQL кодеров — т.е. в том числе от меня. Ага?
А>Иди в сад, дорогой, и поучись там отличать иронию от наездов, да ?
Видать ты в какой-то не такой сад ходишь — пока сам не умеешь.
А>-- А>Влад
А>PS А "мужики" как раз "знают" всё, что им необходимо
Главное что ты у нас все знаешь.
А>PPS Саморекламой не занимался и не собираюсь заниматься
Тебя никто и не просит. Просто попросили... хм... не выеживаться
Что есть для Вас "типичные приложения"?! Например, для OLTP систем версионность не так уж и "актуальна", т.е. такие системы строились на MS SQL и ранних версий. А для OLAP систем нужен не MS SQL сервер.
Re: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
21.12.05 10:48
Оценка:
неа, слабенький он у МС получился. даже на TPC-H тестах (там где неблокирующее чтение важно) версионный механизм оказался медленнее блокировочного на том же железе (тесты Bull). жаль в TPC-C нельзя вычислить режим.
P>Что есть для Вас "типичные приложения"?! Например, для OLTP систем версионность не так уж и "актуальна", т.е. такие системы строились на MS SQL и ранних версий. А для OLAP систем нужен не MS SQL сервер.
Это не типично,
типично это : я храню данные бизнеса в этой базе, юзаю ее ,
тут бывают понимания что типично — поиски, отчеты, редактирование,
то что вы сочтете типичным
но без всяких OLAP OLTP.
Здравствуйте, Аноним, Вы писали:
А>неа, слабенький он у МС получился. даже на TPC-H тестах (там где неблокирующее чтение важно) версионный механизм оказался медленнее блокировочного на том же железе (тесты Bull). жаль в TPC-C нельзя вычислить режим.
А что, есть веские основания полагать, что версионники быстрее блокировочников в реальных задачах? Ну не знаю...
Здравствуйте, <Аноним>, Вы писали:
А> даже на TPC-H тестах (там где неблокирующее чтение важно) версионный механизм оказался медленнее блокировочного на том же железе (тесты Bull).
В TPC-H тестах версионное чтение совершенно не важно, так как на 96-98% запросы гоняются по статическим данным.
А> жаль в TPC-C нельзя вычислить режим.
Там и вычислять не надо, никто в здравом уме не будет делать OLTP задачу в версионном режиме, если есть в наличии отлично работающий блокировочный.
Здравствуйте, Alex.Che, Вы писали:
AC>Священный догмат.
Это не догмат — это утверждение полностью согласующееся с теорией и подтвержденное многолетней практикой.
Привет, Merle!
Вы пишешь 21 декабря 2005:
AC>> Священный догмат.
M> Это не догмат — это утверждение полностью согласующееся M> с теорией и подтвержденное многолетней практикой.
Вань, ты сколько лет юзаешь версионный режим,
дабы утверждать о "подтверждении многолетней практикой"?..
M>Это не догмат — это утверждение полностью согласующееся с теорией и подтвержденное многолетней практикой.
поясните нам почему блокировка — лучше отсутсвия блокировки?
"отличная блокировка"?
она там чего вообще не нужна может быть? (наилучший случай,
который и решается как вариант версионностью)
или используется какой механизм блокирования ,
такой что накладные расходя на инициализацию копирования в версионоость — сравнимы
со всеми блокировками в данной задаче?
Здравствуйте, Alex.Che, Вы писали:
AC>Вань, ты сколько лет юзаешь версионный режим, AC>дабы утверждать о "подтверждении многолетней практикой"?..
Не на много меньше чем блокировочный, да и не только я.
Здравствуйте, vgrigor, Вы писали:
P>>Что есть для Вас "типичные приложения"?! Например, для OLTP систем версионность не так уж и "актуальна", т.е. такие системы строились на MS SQL и ранних версий. А для OLAP систем нужен не MS SQL сервер.
V>Это не типично, V>типично это : я храню данные бизнеса в этой базе, юзаю ее ,
Понятно, что не пиво.
V>тут бывают понимания что типично — поиски, отчеты, редактирование, V>то что вы сочтете типичным V>но без всяких OLAP OLTP.
Что значит "без всяких"?! Вы вообще понимаете смылс и предназначение OLAP и OLTP систем?!
Привет, Merle!
Вы пишешь 21 декабря 2005:
AC>> Вань, ты сколько лет юзаешь версионный режим, AC>> дабы утверждать о "подтверждении многолетней практикой"?..
M> Не на много меньше чем блокировочный, да и не только я.
Вспомнилось: "Я на вас жалобу напишу! Коллективную..."
О каком многолетнем опыте версионного режима MSSQL-2005 речь?
Здравствуйте, Alex.Che, Вы писали:
AC>О каком многолетнем опыте версионного режима MSSQL-2005 речь?
Причем здесь SQL 2005? Я имел ввиду версионный механизм вообще, безотносительно конкретной реализации.
Что касается SQL 2005, то в голой теории это довольно удачная реализация, а о серьезной практике говорить пока рано.
P>Что значит "без всяких"?! Вы вообще понимаете смылс и предназначение OLAP и OLTP систем?!
ошибся несколько: OLTP а не OLAP :
НЕ
OLAP — системы аналитической обработки, также известны как системы поддержки принятия решения (Decision Support System, DSS), ориентированы на предоставлении пользователям мощных механизмов для быстрого и многостороннего анализа данных. В современных условиях корпорациям нужно быстро получить информацию о наиболее перспективных направления торговли или направления производства, которая обеспечит максимальную отдачу от вложенных средств.
А ВОТ ЭТО:
OLTP — системы оперативной обработки транзакций, характеризуются большим количеством изменений, одновременным обращением множества пользователей к одним и тем же данным для выполнения разнообразных операций — чтения, записи, удаления или модификации данных. Для нормальной работы множества пользователей применяются блокировки и транзакции. Эффективная обработка транзакций и поддержка блокировок входят в число важнейших требований к системам оперативной обработки транзакций.
я имел в виду не хранилдища и витрины данных — это весьма специфично,
V>>поясните нам почему блокировка — лучше отсутсвия блокировки? M>Потому что OLTP это тот класс задач где велика вероятность конфликта, а стоимость разруливания конфликта для версионного механизма намного выше чем для блокировочного, так как конфликт версий фактически означает откат транзакции. При этом в OLTP транзакции очень короткие, и среднее время ожидания на блокировке примерно равно времени поиска предыдущей версии, но на поиск версии тратится ресурсов больше.
т.е. версионность сделана так чо в ней возникают аналоги блокировок ?
Здравствуйте, vgrigor, Вы писали:
V>т.е. версионность сделана так чо в ней возникают аналоги блокировок ? V>т.е. весьма неполноценно сделанная версионность?
Откуда такой вывод? Я ничего подобного не писал. Более того, я нигде не писал про "сделана", я писал про "устроена".
Здравствуйте, Alex.Che, Вы писали:
AC>Иван, я написал какие твои утверждения не соответствуют действительности. AC>Настаиваешь на их непогрешимой непоколебимости?
Ты не написал почему, поэтому естественно настаиваю. Насколько мне известно на данный момент не существует ни одной практической реализации версионности без откатов в случае конфликта записи. До недавнего времени небыло даже никаких теоретических работ по этой тематике. Развей мои заблуждения, расскажи, как можно реализовать полноценную версионность без отката, при условии что нам нужен уровень изоляции не ниже RR по классификации ANSI.
Привет, Merle!
Вы пишешь 21 декабря 2005:
AC>> Иван, я написал какие твои утверждения не соответствуют действительности. AC>> Настаиваешь на их непогрешимой непоколебимости?
M> Ты не написал почему, поэтому естественно настаиваю. Насколько мне известно M> на данный момент не существует ни одной практической реализации версионности M> без откатов в случае конфликта записи. До недавнего времени небыло даже никаких M> теоретических работ по этой тематике.
Так и не заглянул?
AC>> Там по ссылкам интересно походить.
M> Во-во, для IB/FB, AFAIK не существенна дяже оговорка про RR, M> он откатывает по честному, вплоть до юзера даже при RC.
Здравствуйте, Alex.Che, Вы писали:
AC>Так и не заглянул?
Если ты утверждаешь, что можно разрешить конфликт версий без отката, то распиши пожалуйста на пальцах алгоритм или дай ссылку на внятное описание оного алгоритма, а то я уже устал от твоей загадочности.. )
Привет, Merle!
Вы пишешь 21 декабря 2005:
AC>> Так и не заглянул?
M> Если ты утверждаешь, что можно разрешить конфликт версий без отката, M> то распиши пожалуйста на пальцах алгоритм или дай ссылку на внятное M> описание оного алгоритма, а то я уже устал от твоей загадочности.. )
Устал от твоей одиозности не меньше
Ты пишешь:
=========Beginning of the citation============== для IB/FB, AFAIK не существенна дяже оговорка про RR,
он откатывает по честному, вплоть до юзера даже при RC.
=========The end of the citation================
Смотрим сюда.
Tr1.Start(read_committed, rec_version, nowait)
Tr2.Start(read_committed, rec_version, nowait)
Tr1.UpdateSomeRecord
Tr2.UpdateSomeRecord ==> Lock conflictk on nowait transaction
Tr1.Commit
Tr2.UpdateSomeRecord
Tr2.Commit
Где откат?
И поясни убогому про "вплоть до юзера"...
ЗЫ: чистого RR у IB нет, есть SnapShot это несколько иной уровень изоляции.
Там картина будет несколько иная, в зависимости от wait/nowait и rec_version/no_rec_version
Товарищ пишет по делу.
Чудес не бывает. Проблемы синхронизации остаются проблемами синхронизации вне зависимости от подхода.
Еще раз повторю — с чего вы взяли, что версионники вообще должны быть лучше блокировочников? По крайней мере заметно лучше и на задачах реального мира, а не на условных тестах?
Здравствуйте, Alex.Che, Вы писали:
AC>Устал от твоей одиозности не меньше
И в чем выражается моя одиозность? В отсутствии слепой веры в версионники?
AC>Смотрим сюда. AC>Tr1.Start(read_committed, rec_version, nowait) AC>Tr2.Start(read_committed, rec_version, nowait) AC>Tr1.UpdateSomeRecord AC>Tr2.UpdateSomeRecord ==> Lock conflictk on nowait transaction
Что в этот момент делает TR2?
AC>Tr1.Commit AC>Tr2.UpdateSomeRecord AC>Tr2.Commit AC>Где откат?
Что — нету? Лень искать, но в этом же форуме мне годя два назад доказывали с пеной у рта, что откат-таки будет. Но дело даже не в этом.
AC>И поясни убогому про "вплоть до юзера"...
Вплоть до юзера это значит что на уровне провайдера происходит exception, который вываливается в клиентский код и нуждается в дополнительной обработке. Тот же Oracle в такой ситуации, производит откат запроса, а затем выполняет запрос повторно, внутри себя, клиент об этой механике даже не догадывается, но тем не менее это полноценный откат.
AC>ЗЫ: чистого RR у IB нет, есть SnapShot это несколько иной уровень изоляции.
Это уже нюансы, Snapshot сильнее RR, а я ставил условие хотя бы RR. И если теоретически при RC на конфликт версий можно просто забить и писать поверх, что делает MSSQL и, в некоторых ситуациях Oracle (насчет IB/FB вопрос все еще туманный), то для того чтобы добиться хотя бы RR без отката уже не обойтись даже теоретически.
P. S.
Я все еще жду описания реализации версионного алгоритма без откатов. Не уходи от темы, пожалуйста.
M>Еще раз повторю — с чего вы взяли, что версионники вообще должны быть лучше блокировочников? По крайней мере заметно лучше и на задачах реального мира, а не на условных тестах?
M>У меня вот нет оснований так думать.
У меня два аргумента — первый здравый смысл
отсутсвие блокировок — должно быть быстрее блокировок,
если накладные расходы по организации копии данных меньше чем отслеживание зависимостей и задержки.
второе — я сам писал код реализующий параллельную обработку с помощью версионности,
копий данных,
и там где были тормозные операции — все получалось несколько лучше.
На практике это можно наблюдать когда вы решаете писать многопоточную систему чтобы интерфейс —
тоже задача — не тормозил,
оптимизируется использование системных ресурсов,
и чем их больше тем задержек на блокировки меньше.
подход тот же,
почему не быть похожим результатам хоть кое-где ?
почему бы Микрософт не сделать это тоже хорошо, так чтобы эффект был виден на некоторых задачах?
а мой взглдя довольно тщательное исследование
и полезное заключение,
но без исследования конкретных случаев,
что я хотел узнать — когда именно лучше в реальном приложении,
пир каких действиях и установках.
автор сказал — "надо иметь такие тесты" — может кто-то видел такое ?
т.е. нашел что на основании "понятий" выводы сложно сделать:
______________________________________
из статьи (- полная цитата) :
Заключение
Новая функциональность, безусловно, окажется очень полезной. Самый заметный эффект – это отсутствие блокировок между читающими и пишущими запросами. То есть читающие запросы не блокируют пишущие, и наоборот. Собственно, вся версионность ради этого и затевалась.
У чистых блокировочников, каковым до недавнего времени являлся и Microsoft SQL Server, при наступлении того печального момента, когда читающие запросы начинают довольно сильно конфликтовать с пишущими, используется стандартный архитектурный прием. Механизм работы с данными делится на две составляющие, OLAP и OLTP. OLTP реализует работу пишущих транзакций на относительно небольшом объеме актуальных данных, а OLAP содержит основные данные, доступные только для чтения, причем в силу того, что каждый механизм оптимизирован исключительно под свои задачи, подобное решение, как правило, оказывается очень эффективным. При этом совершенно необязательно сразу строить большую систему и покупать дополнительное оборудование. Если задача не требует излишней громоздкости, то начинается все обычно с построения промежуточных агрегирующих таблиц и материализованных представлений, в дальнейшем возможен перенос одной из составляющих в отдельную базу, экземпляр сервера и, наконец, если в том возникнет необходимость, на отдельный сервер или даже группу серверов.
Может показаться, что класс задач, для которых реально нужна версионность, достаточно узок. С одной стороны, использование версионности имеет смысл, если в блокировочнике конфликт читающих и пишущих запросов начинает оказывать заметное влияние на производительность. Но с другой стороны, при дальнейшем увеличении нагрузки, производительность версионного механизма довольно быстро начнет снижаться из-за частых обновлений по причине больших накладных расходов на поддержку версионности, она ведь тоже обходится не даром.
Но тут можно вспомнить, что существуют задачи, где необходимо выполнять большое количество малопрогнозируемых запросов (ad-hoc queries). В этом случае конфликты читающих и пишущих запросов выходят на первое место, поскольку в подобной ситуации очень высока вероятность возникновения взаимоблокировок.
Также стоит заметить, что, несмотря на всю полезность агрегатных таблиц, они обладают одним большим недостатком, сильно сужающим область их применения. Если в исходной таблице активность запросов можно физически разнести по разным страницам данных, то в агрегатной таблице большое количество изменений создаст совершенно ненужный ажиотаж в очень маленьком объеме.
Немаловажно также и то, что писать приложения для БД с поддержкой версионности попросту удобнее. Отсутствие необходимости отслеживать возможные конфликты читающих и пишущих запросов здорово облегчает жизнь, особенно не слишком опытным разработчикам, и повышает масштабируемость системы (хотя в этом случае выше вероятность появления некоторых неочевидных эффектов).
И наконец, введенная поддержка версионности позволит легче адаптироваться к новому серверу тем, кто привык работать с подобной функциональностью.
Преимущества версионности.
Читающие запросы не блокируют пишущие, и наоборот.
Уменьшатся вероятность возникновения взаимоблокировок.
Есть возможность выполнять большие согласованные чтения, не предусмотренные структурой базы (ad-hoc queries), без риска сильного падения производительности остальных запросов.
Можно выполнять согласованные агрегатные запросы без повышения уровня изоляции.
Во что обходится версионность.
Пишущие транзакции обязаны создавать копию записи в хранилище версий, даже если на данный момент нет читающих запросов, которым нужна эта запись.
Под хранилища версий, которые расположены в tempdb, необходимо дополнительное место. Причем его может потребоваться довольно много (при наличии длинных версионных транзакций и большом количестве изменений).
Длина каждой записи увеличивается на 14 байт.
Читающие версионные запросы выполняются тем дольше, чем старее транзакция, из-за необходимости спускаться по цепочке ссылок к нужной версии данных. Это также порождает дополнительную нагрузку на процессор и память.
Часть пишущих транзакций при snapshot-уровне изоляции может быть отменена из-за конфликта версий при изменении данных.
В целом реализация версионности от Microsoft выглядит довольно удачно. Существует широкий класс задач, для которых выгоднее использовать чисто блокировочный механизм. Поэтому возможность отключить совершенно не нужную в данном случае версионность довольно полезна.
При включенной поддержке версионности становятся доступны практически все прелести версионных СУБД, а поскольку при записи в большинстве случаев серверу выгоднее вести себя как блокировочнику, то Yukon так и поступает, благо опять-таки есть такая возможность. А если из repeatable read- или даже serializable-транзакции понадобиться забрать согласованные данные, никого не блокируя, то можно использовать версионное чтение.
Вообще, с данной точки зрения, очень полезной была бы функциональность позволяющая включать или выключать поддержку версионности отдельно для каждой таблицы. Но здесь есть ряд концептуальных проблем, например, сложно представить, как будет выглядеть объединение в запросе двух таблиц, одна из которых поддерживает версионность, а другая – нет.
Сам механизм обеспечения версионности в Yukon также обещает быть довольно быстрым и надежным. Используемый алгоритм относительно прост и обеспечивает стопроцентное обнаружение конфликтов при версионных изменениях, без холостых срабатываний. Впрочем, о производительности данного механизма можно будет говорить только после проведения относительно адекватных тестов, а еще лучше — после применения в реальном приложении.
При чем тут здравый смысл, коллега?
Речь идет о проблемах такого уровня сложности, что бытовой здравый смысл уже не работает.
Не существует (насколько мне известно) оснований полагать, что версионный подход должен быть более эффективным. Причем не существует ни в теории, ни на практике. Только частные случаи.
Очень близкие результаты получаются в реальной жизни.
Привет, Merle!
Вы пишешь 22 декабря 2005:
AC>> Смотрим сюда. AC>> Tr1.Start(read_committed, rec_version, nowait) AC>> Tr2.Start(read_committed, rec_version, nowait) AC>> Tr1.UpdateSomeRecord AC>> Tr2.UpdateSomeRecord ==> Lock conflictk on nowait transaction
M> Что в этот момент делает TR2?
НИКУА НЕ ДЕЛАЕТ.
Я как юзер получаю сообщение о конфликте блокировок.
И ВСЁ.
Дальше мне решать, что делать.
А не провайдеру тупорылому.
AC>> Tr1.Commit AC>> Tr2.UpdateSomeRecord AC>> Tr2.Commit AC>> Где откат?
M> Что — нету? Лень искать, но в этом же форуме мне годя два назад доказывали M> с пеной у рта, что откат-таки будет.
Мне, как юзеру/программеру решать, откатывать ли транзакцию,
либо коммитить, либо попытаться снова.
Это MS вас подсадил на т.н. "автоматическое управление транзакциями".
И вы свято уверены, что по другому и быть не может.
AC>> И поясни убогому про "вплоть до юзера"...
M> Вплоть до юзера это значит что на уровне провайдера происходит exception...
Всё. Дальше не продолжай.
Разговор глухого со слепым...
Смешались в кучу кони, люди... (С)
И сервер со средствами доступа.
Здравствуйте, Alex.Che, Вы писали:
AC>Я как юзер получаю сообщение о конфликте блокировок. AC>И ВСЁ. AC>Дальше мне решать, что делать. AC>А не провайдеру тупорылому.
Отлично, и возвращаясь к основному предмету спора, ты правда считаешь, что это будет быстрее, чем если сервер разрулит это автоматически?
AC>Мне, как юзеру/программеру решать, откатывать ли транзакцию, AC>либо коммитить, либо попытаться снова.
Даже при Snapshot? В этом случае ты не сможешь гарантировать отсутствие конфликтов и, собственно snapshot-ность, если сможешь серверу явно указать перезапись чужой версии.
AC>Это MS вас подсадил на т.н. "автоматическое управление транзакциями".
Да нет, как раз наоборот. Это IB взвалил решение об откате на разработчика, а все приличные сервера такой фигней не страдают.
AC>И вы свято уверены, что по другому и быть не может.
Почему, можт, только смысла не имеет.
AC>Дальнейшую дискуссию считаю нецелесообразной.
Еще бы, аргументов-то нет.. )
M>Речь идет о проблемах такого уровня сложности, что бытовой здравый смысл уже не работает.
Допустим, это похоже на правду.
Однако то что микрософт его реализовало говорит о том что они сделали это не для смеха,
или для смеха?
M>Не существует (насколько мне известно) оснований полагать, что версионный подход должен быть более эффективным. Причем не существует ни в теории, ни на практике. Только частные случаи.
M>Очень близкие результаты получаются в реальной жизни.
И никто не проверял что сделано это только для юмора или дает резултаты?
Здравствуйте, Alex.Che, Вы писали:
M>> Что в этот момент делает TR2?
AC>НИКУА НЕ ДЕЛАЕТ. AC>Я как юзер получаю сообщение о конфликте блокировок. AC>И ВСЁ. AC>Дальше мне решать, что делать. AC>А не провайдеру тупорылому.
Это ты о ком, то есть кому?
Я перед законом чист — ничего такого, за что порвут как грелку, не решаю
AC>Всё. Дальше не продолжай. AC>Разговор глухого со слепым... AC>Смешались в кучу кони, люди... (С)
Там еще и Дом Обломова был
AC>Дальнейшую дискуссию считаю нецелесообразной.
Все равно: Firebird — чемпион AC>Аминь.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Merle, Вы писали:
AC>>Это MS вас подсадил на т.н. "автоматическое управление транзакциями".
M>Да нет, как раз наоборот. Это IB взвалил решение об откате на разработчика, а все приличные сервера такой фигней не страдают.
Я одно понять не могу — как мы бедные до сих пор не померли от такой ответственности — явно вызывать start/commit/rollback транзакций.
И как человек, который, если честно, совершенно не рубается в нюансах версионника, могу сказать что для таких как я, только такие вместе с SNAPSHOT по умолчанию и нужны.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Merle,
AC>> Tr1.Commit AC>> Tr2.UpdateSomeRecord AC>> Tr2.Commit AC>> Где откат? > M> Что — нету? Лень искать, но в этом же форуме мне годя M> два назад доказывали с пеной у рта, что откат-таки будет.
Автоматического отката транзакции не будет никогда. Если кто-то писал обратное — это на его совести. При неразрешенном конфликте всегда будет только откат оператора. Ты про это?
M> Тот же Oracle в такой ситуации, M> производит откат запроса, а затем выполняет запрос повторно, M> внутри себя, клиент об этой механике даже не догадывается, но M> тем не менее это полноценный откат.
Он перевыполняет только конкретную операцию записи (вместе с проверкой предиката) или весь запрос? А в режиме NO WAIT (или какой там у него аналог) он как поступает?
M> теоретически при RC на конфликт версий можно просто забить M> и писать поверх, что делает MSSQL и, в некоторых ситуациях Oracle M> (насчет IB/FB вопрос все еще туманный)
В IB/FB перезапись может быть, а может и нет (т.е. откат) — зависит от вида RC транзакции. Кстати, насколько перезапись теоретически правильна для RC — я четкого ответа найти не смог. IMHO, тут все от реализации зависит.
Re[9]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
23.12.05 13:21
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Alex.Che, Вы писали:
AC>>О каком многолетнем опыте версионного режима MSSQL-2005 речь? M>Причем здесь SQL 2005? Я имел ввиду версионный механизм вообще, безотносительно конкретной реализации.
"вообще" иметь в виду версионный механизм странно, потому что он уже есть в
1. InterBase/Firebird, первая коммерческая реализация
2. Oracle, в том или ином виде
3. PostgreSQL (с 1995 года)
4. MS SQL 2005
и планируется (или уже есть) в MySQL.
M>Что касается SQL 2005, то в голой теории это довольно удачная реализация, а о серьезной практике говорить пока рано.
пока будем считать, что это копия с Interbase, а уж удачная или нет — посмотрим.
Re[7]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
23.12.05 13:28
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, vgrigor, Вы писали:
V>>поясните нам почему блокировка — лучше отсутсвия блокировки? M>а стоимость разруливания конфликта для версионного механизма намного выше чем для блокировочного, так как конфликт версий фактически означает откат транзакции.
брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"?
И вообще, по треду дальше идут непонятные намеки на откат при конфликте на уровне snapshot,
при том что снапшотов (таких) в MS SQL еще никто не ел. Давайте уж более близкое сравнивать —
в RC никаких "откатов" не надо.
И явное управление завершением транзакции при конфликтах — это благо, а не недостаток.
Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL —
это наследованная проблема, которую, думаю, уже не исправить. Отсюда и вольное
обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п.
В целом я так понял, что автор поста не любит версионность, и считает что Microsoft
совершенно зря (сдуру?) ввел ее поддержку в MS SQL 2005. Иже с ними все упомянутые
мной в другом посте сервера, поддерживающие версионность.
Merle,
M> ты правда считаешь, что это будет быстрее, M> чем если сервер разрулит это автоматически?
Быстрее не будет, естественно. Весь вопрос — должен ли уровень изоляции RC диктовать отсутствие конфликтов или нет. Если да, то перевыполнение оператора сервером допустимо и, более того, желательно. А вот если нет, то по-хорошему надо спросить юзверя. Вдруг его логика вместо тупого повтора захочет пойти в обход?
M> Даже при Snapshot? В этом случае ты не сможешь гарантировать M> отсутствие конфликтов и, собственно snapshot-ность, если M> сможешь серверу явно указать перезапись чужой версии.
Перезапуск оператора после конфликта в снапшоте бесполезен. Авторестарт транзакции — некорректен. Остается выбор: роллбачить автоматом или клиент пусть сам это делает. Дело вкуса, IMHO. Хотя, если держать в памяти гипотетическую вероятность альтернативного пути со стороны клиента, то лучше обойтись без автомата.
Здравствуйте, <Аноним>, Вы писали:
А>брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"?
Потому что стоимость отката очень высока.
А> Давайте уж более близкое сравнивать — в RC никаких "откатов" не надо.
Формально не надо, на практике Oracle, как правило, откатывает, IB/FB спрашивает клиентский код, что по скорости еще хуже.
А>И явное управление завершением транзакции при конфликтах — это благо, а не недостаток.
Недостаток. Не хочу сейчас ввязываться в дискуссии относительно такого поведения вообще, однако в данном топике идет разговор именно об OLTP задачах, а в таких условиях это недостаток, хотя бы из соображений производительности.
А>Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL -это наследованная проблема, которую, думаю, уже не исправить.
Во-первых — это не проблема, во-вторых ее уже исправили (ключевые слова ADO.Net 2.0, MARS, Async Query), а в третих это-то уж здесь совершенно непричем.
А>Отсюда и вольное обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п.
Еще раз. Взвалить решение о коммите на клиентский код, который ничего не знает о внутреннем состоянии шедулера и о том чем занимаются конкурентные транзакции в этот момент, додумался только IB, ни одна другая СУБД подобными вещами не занимается.
А>В целом я так понял, что автор поста не любит версионность, и считает что Microsoft А>совершенно зря (сдуру?) ввел ее поддержку в MS SQL 2005. Иже с ними все упомянутые А>мной в другом посте сервера, поддерживающие версионность.
В целом жестоко ошибаешься. Ты упустил один очень важный момент — в данной подветке речь идет исключительно об OLTP системах. В целом же я очень приветствую шаг MS в эту сторону и моё скромное мнение заключается в том, что в РСУБД будущее не за версионниками или блокировочниками, а за гибридными системами, когда в зависимости от задачи можно выбирать наиболее удобный способ разруливания параллельных транзакций. Однако, если вернуться к теме данной подветки, то OLTP это как раз тот класс задач, когда выгоднее использовать блокировочный режим.
Здравствуйте, dimitr, Вы писали:
D>Быстрее не будет, естественно.
Об этом и речь. У нас на повестке дня OLTP системы, и здесь очень критично время одной транзакции.
D>Весь вопрос — должен ли уровень изоляции RC диктовать отсутствие конфликтов или нет.
Я описался, речь не о конфликтах а об аномалиях, конечно же. Ну да не важно...
Формально при RC можно забить и перезаписать, на практике Oracle запрос перевыполняет (хотя там более сложная механика, но это лирика), IB вообще пользователя спрашивает.
А на данный момент нас интересует именно вопрос производительности, и по производительности оба эти подхода сливают со свистом простому ожиданию на блокировке. Именно об этом и идет речь в данной подветке.
Здравствуйте, dimitr, Вы писали:
D> При неразрешенном конфликте всегда будет только откат оператора. Ты про это?
Возможно, дело давнее, но сути это не меняет...
D>Он перевыполняет только конкретную операцию записи (вместе с проверкой предиката) или весь запрос?
Запрос, не транзакцию целиком, а конкретный запрос в этой транзакции.
D> А в режиме NO WAIT (или какой там у него аналог) он как поступает?
Откат запрса и исключение, если он на блокировку нарвался. Если же блокировки нет, а данные успели поменять, то опять-таки, откат запроса и выполнение его по новой.
Но здесь я могу наврать, давно в руках не держал.
D> Кстати, насколько перезапись теоретически правильна для RC — я четкого ответа найти не смог.
Теориетически при RC перезаписать можно совершенно спокойно, формально никаких противоречий нет.
Здравствуйте, <Аноним>, Вы писали:
А>"вообще" иметь в виду версионный механизм странно,
Ничего странного, поскольку рассматривалась не конкретная реализация, а общие теоретические принципы.
А>пока будем считать, что это копия с Interbase, а уж удачная или нет — посмотрим.
Общего с IB там только версионность на уровне записи, а не страницы, как в Oracle или Postgree...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[9]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
23.12.05 15:17
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"? M>Потому что стоимость отката очень высока.
Гм. Есть методика измерения и\или конкретные цифры ?
А>> Давайте уж более близкое сравнивать — в RC никаких "откатов" не надо. M>Формально не надо, на практике Oracle, как правило, откатывает, IB/FB спрашивает клиентский код, что по скорости еще хуже.
Оператор откатывается автоматически. А тр-ция тут причём ??? Ах да, стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором "BEGIN TRAN". Отсюда и знак равенства между откатом оператора и тр-ции
...
А>>Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL -это наследованная проблема, которую, думаю, уже не исправить. M>Во-первых — это не проблема, во-вторых ее уже исправили (ключевые слова ADO.Net 2.0, MARS, Async Query), а в третих это-то уж здесь совершенно непричем.
И шо 2 тр-ции будут жить в одном коннекте ?
А>>Отсюда и вольное обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п. M>Еще раз. Взвалить решение о коммите на клиентский код, который ничего не знает о внутреннем состоянии шедулера и о том чем занимаются конкурентные транзакции в этот момент, додумался только IB, ни одна другая СУБД подобными вещами не занимается.
Давно я так не смеялся Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо
Ни одна СУБД не занимается такой порнографией, как невозможность перехватить и обработать ошибку (некоторые их виды). В Юконе может и натанет "щастье", но не скоро он заменит предыдущие версии... так что жрать кактусы ещё долго нужно будет... Это об откатах и их обработке в одном продвинутом блокировочнике
Здравствуйте, Merle, Вы писали:
А>>брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"? M>Потому что стоимость отката очень высока.
опять мы про "откат", который требуется только для snapshot, и который
имеет мало смысла в том же самом OLTP.
А>>И явное управление завершением транзакции при конфликтах — это благо, а не недостаток. M>Недостаток. Не хочу сейчас ввязываться в дискуссии относительно такого поведения вообще, однако в данном топике идет разговор именно об OLTP задачах, а в таких условиях это недостаток, хотя бы из соображений производительности.
чистых OLTP уже давно нет. Обязательно на десять OLTP-пользователей найдется пара-тройка отчетников или аналитиков.
А>>Отсюда и вольное обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п. M>Еще раз. Взвалить решение о коммите на клиентский код, который ничего не знает о внутреннем состоянии шедулера и о том чем занимаются конкурентные транзакции в этот момент, додумался только IB, ни одна другая СУБД подобными вещами не занимается.
моя твоя не понимай, и так же с другой стороны. Мне непонятно, как вообще сервер может чего-то там решать
за меня.
M>Однако, если вернуться к теме данной подветки, то OLTP это как раз тот класс задач, когда выгоднее использовать блокировочный режим.
в чистом виде — да. Но — например, зачем Borland ввел понятие Cached Updates, когда на клиенте сначала оформляется
пакет изменений, а потом выстреливается? Короткая транзакция, да, но чем дольше момент от начала изменений на клиенте до старта транзакции на сервере, тем меньше шансов успешно обновить данные. Проблемы "кэширования" никто не отменял, и здесь ни версионник, ни блокировочник не имеют разницы в плане "устаревания" данных.
Merle,
M> А на данный момент нас интересует именно вопрос производительности, M> и по производительности оба эти подхода сливают со свистом простому M> ожиданию на блокировке. Именно об этом и идет речь в данной подветке.
В IB/FB стартуешь транзакцию READ_COMMITTED NO_REC_VERSION WAIT и он работает как блокировочник, т.е. при обнаружении нами активной чужой версии записи ждем завершения (любого) транзакции-конкурента на ее (записи) чтении, а не на апдейте. После чего успешно читаем результат и перезаписываем его своим. Для версионника это не совсем ожидаемый режим и он редко кем используется, однако он существует и при желании может быть применен в OLTP.
Merle,
M> Общего с IB там только версионность на уровне записи, M> а не страницы, как в Oracle или Postgree...
Насколько я в курсе, страничная версионность есть только в Oracle. Как PGSQL, так и InnoDB в MySQL реализуют версионность записей. Ноги у которой растут от RDB/ELN и InterBase, и на сей день вырасли аж до MSSQL. И это "только" диктует очень много схожих технических решений для всех упомянутых СУБД.
Здравствуйте, dimitr, Вы писали:
D> Ноги у которой растут от RDB/ELN и InterBase, и на сей день вырасли аж до MSSQL. И это "только" диктует очень много схожих технических решений для всех упомянутых СУБД.
InnoDB, вообще отдельная пестня — дитя финского энтузиаста, да и строить общность только на том, что механизм работает на одинаковом уровне — занятие неблагодарное. В отличии от всех остальных версионников, сиквел еще и обеспечивает полноценный блокировочный механизм, так что вряд ли тут можно рассуждать о копировании идей.
Вообще же, корни растут из работ по MV over 2PL, того же Бернстайна, Грея, Беренсона, ect, которые в 70х-80х двигали теорию CC, а нонче работают на MS.
Здравствуйте, dimitr, Вы писали:
D> Для версионника это не совсем ожидаемый режим и он редко кем используется, однако он существует и при желании может быть применен в OLTP.
Отлично. Теперь читаем еще раз внимательно о чем речь. Не о том, что IB плох, а о том какой механизм выгоднее использовать в определенной ситуации.
Да, в данной ситуации выгоднее использовать блокировочный, если IB это умеет — молодец, но речь здесь не об этом.
Здравствуйте, <Аноним>, Вы писали:
А> Гм. Есть методика измерения и\или конкретные цифры ?
Есть конкретные теоретические работы (ключевые слова: Мохан, Франклин, Ульман), и есть суровая практика. Откат очень дорогая операция практически во всех современных СУБД, если не брать в рассчет какую-нибудь экзотику (зато у этих ребят высокая стоимость фиксации). Тут выбирай, но осторожно, но выбирай. Либо дорогой роллбэк, либо дорогой коммит, дураков, понятное дело, нет.
А> Оператор откатывается автоматически.
Автоматически — это как?
А> А тр-ция тут причём ???
Какая транзакция?
А> Ах да, стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором "BEGIN TRAN".
Мужик, ты о чем?!
А> Отсюда и знак равенства между откатом оператора и тр-ции А>...
??? Какой знак равенства?
А> И шо 2 тр-ции будут жить в одном коннекте ?
Таки да.
А> Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо
Правда? То есть ваш клиентский код всегда знает о других транзакциях, которые в этот момент выполняются в БД? Поздравляю, вам удалось достичь совершенства.
Только вот еще раз повторюсь, до такой конструкции додумался только один IB, а ни одна из серьезных БД шаловливые ручки разработчика до такой тонкой механики не допускает, даже панки из Oracle.
Ни на какие размышления не наводит?
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>опять мы про "откат", который требуется только для snapshot, и который КДВ>имеет мало смысла в том же самом OLTP.
Почему мало? Уровень изоляции здесь непричем, в OLTP задачи вполне входят требования высокого уровня согласованности. К слову, tpc-c тесты обязаны выполняться на уровне не ниже RR.
КДВ>чистых OLTP уже давно нет. Обязательно на десять OLTP-пользователей найдется пара-тройка отчетников или аналитиков.
Пара тройка аналитиков — это все еще OLTP. И не надо опять разговор в сторону уводить, есть задача — OLTP, какое решение будет наиболее удачным, блокировочное или версионное? Ответ — блокировочное, почему — я объяснил, есть возражения?
КДВ>моя твоя не понимай, и так же с другой стороны. Мне непонятно, как вообще сервер может чего-то там решать за меня.
Вот в этом-то и проблема версионного механизма. В блокировочнике откат — это внештатная ситуация, нарушение констрейнта и прочий караул. А в версионнике — вполне обыденный случай, который, тем не менее, требует (по твоим же словам) вмешательства клиентского кода. В блокировочниках просто нет этой проблемы, ваще.
КДВ>в чистом виде — да.
Ну вот и договорились. В данном топике речь шла именно +/- о чистом OLTP, и ни о чем более. Опять-таки намеренно не хочу ввязываться в разговор о практичности такого подхода.
КДВ> Но — например, зачем Borland ввел понятие Cached Updates, когда на клиенте сначала оформляется пакет изменений, а потом выстреливается?
Судя по описанию, там появились трезвые умы, но боюсь поздно..
КДВ> Короткая транзакция, да, но чем дольше момент от начала изменений на клиенте до старта транзакции на сервере, тем меньше шансов успешно обновить данные. Проблемы "кэширования" никто не отменял, и здесь ни версионник, ни блокировочник не имеют разницы в плане "устаревания" данных.
Вот тут на лицо фатальное непонимание принципа работы СУБД. Нет здесь "проблемы кеширования" и "устаревания данных", транзакция начинается в тот момент, когда первый ее оператор добрался до первой записи, не раньше и не позже. А вот дальше — задача СУБД сделать так, чтобы вся транзакция отработала на должном уровне согласованности, и вот здесь уже лучше бы клиенту под ногами не мешаться.
Принцип черного ящика — запихнули, получили результат, что там внутри происходит — чужая головная боль, главное результат верный.
Merle,
M> Теперь читаем еще раз внимательно о чем речь.
В этой ветке мысль зело широко разлилась
M> в данной ситуации выгоднее использовать блокировочный
Если под блокировочным ты понимаешь "писатель блокирует читателя", тогда согласен, т.к. это даст возможность ждать и перезаписывать без "дорогих" откатов, повышая производительность OLTP. Вот только отсутствие откатов достигается безотносительно архитектуры сервера, как я уже показал. Т.е. фраза "в версионнике более дорогие откаты" некорректна. В RC WAIT версионник может работать без откатов. В RC NO WAIT или RR/SNAPSHOT откат обязателен (оператора или транзакции соответственно) в любой архитектуре и я не вижу, как внутри себя сервер этого может избежать.
Merle,
M> InnoDB, вообще отдельная пестня — дитя финского энтузиаста
У одного финского энтузиаста неплохо получилось, знаешь-ли
M> строить общность только на том, что механизм работает на M> одинаковом уровне — занятие неблагодарное
Общность — понятие растяжимое и не равное идентичности. Я никогда не говорил, что у всех все слизано с реализаций начала 80-х. Но общих идей и алгоритмов достаточно много, велосипеда никто заново не изобрел.
К сожалению, по версионности в MSSQL низкоуровневой информации не так и много. Например, я до сих пор не могу выяснить, индексы у них версионные или нет (т.е. содержит ли ключ метку транзакции). Что насчет версий блобов? Критерии старта фоновой сборки мусора?
M> В отличии от всех остальных версионников, сиквел еще и M> обеспечивает полноценный блокировочный механизм
Наверное, мне никогда не понадобится блокировочный RR вместо версионного SNAPSHOT. А для RC у меня есть оба варианта. Причем все это задается на уровне транзакции и действует для любой таблицы. В свете этого полезность полноценного блокировочного механизма мне сомнительна. Впрочем, всегда лучше когда что-то есть, чем когда его нет Лишь бы есть не просил без надобности. Осталось убедиться, что версионность в MSSQL настолько же полноценна, как и блокировочность.
Здравствуйте, dimitr, Вы писали:
D>У одного финского энтузиаста неплохо получилось, знаешь-ли
Да как сказать, не плохо, конечно, ни о не так чтоб уж очень хорошо...
D>Но общих идей и алгоритмов достаточно много, велосипеда никто заново не изобрел.
Естественно, с этим никто и не спорит.
D> Например, я до сих пор не могу выяснить, индексы у них версионные или нет (т.е. содержит ли ключ метку транзакции).
AFAIK нет, не содержит.
D> Что насчет версий блобов?
Если я правильно помню, то там версии на каждую страницу блоба.
D> Критерии старта фоновой сборки мусора?
Такие же как и у checkpoint-а.
D>Наверное, мне никогда не понадобится блокировочный RR вместо версионного SNAPSHOT.
Не зарекайся. При записи версионный снапшот — это гарантированый откат в случае конфликта версий, поэтому RR может оказаться очень кстати.
D> А для RC у меня есть оба варианта.
Ага, и Row Level Read Lock есть? И Update Lock есть? В IB уже не приходится фиктивный update делать для гарантии отсутствия изменений в записи на время транзакции делать?
Здравствуйте, dimitr, Вы писали:
D>В этой ветке мысль зело широко разлилась
Не моими усилиями.. Набежали почему-то оскорбленные в лучших чувствах IB-шники и начали спорить с тем, что я никогда не писал..
D>Если под блокировочным ты понимаешь "писатель блокирует читателя", тогда согласен, т.к. это даст возможность ждать и перезаписывать без "дорогих" откатов, повышая производительность OLTP.
Именно.
D>Вот только отсутствие откатов достигается безотносительно архитектуры сервера, как я уже показал.
Ну причем здесь архитектура конкретного сервера? Я про конкретный сервер не говорил ни слова. Более того, изначально речь шла о некоем сервере, который имеет в себе оба этих механизма, и я лишь утверждал, что из этих двух (2PL и MV over 2PL) в OLTP задаче выгоднее использовать просто 2PL. Все.
D>Т.е. фраза "в версионнике более дорогие откаты" некорректна.
Я нигде не говорил, что "в версионнике более дорогие откаты", я говорил "откат дорогая операция", а версионный механизм вынужден откаты использовать, так как откат там штатная ситуация, в отличии от блокировочного.
D> В RC WAIT версионник может работать без откатов.
Теоретически да, на практике, либо таки откатывают, либо спрашивают пользователя — что хуже (для OLTP) — неизвестно.
D>В RC NO WAIT или RR/SNAPSHOT откат обязателен (оператора или транзакции соответственно) в любой архитектуре и я не вижу, как внутри себя сервер этого может избежать.
Во-первых, для Snapshot, если речь идет о версионнике, то откат должен быть обязательно всей транзакции, одним оператором здесь не отделаешься.
А во-вторых, если речь идет о блокировочнике, то там и RR и даже serializable без откатов достигаются очень просто — за счет блокировок время начала опоздавшей транзакции сдвигается вперед, относительно успевшей, поэтому опоздавшая ничем навредить не может и откатывать ее не надо.
И, соответственно, select count(*) через full index scan невыполним?
M> Если я правильно помню, то там версии на M> каждую страницу блоба.
Если изменены только не-блоб поля записи с блобом, версия блоба будет создана или нет? В IB/FB — нет.
M> Такие же как и у checkpoint-а.
Направь в онлайн-доку, плиз. Для повышения моей эрудиции
M> Не зарекайся. При записи версионный снапшот — это M> гарантированый откат в случае конфликта версий, поэтому M> RR может оказаться очень кстати.
Если я пользую снапшот, значит я готов к откату и ручной обработке конфликтов. Но, возможно, это просто дело привычки к версионнику.
M> Ага, и Row Level Read Lock есть? M> И Update Lock есть?
SELECT blah-blah WITH LOCK дает мне нормальный update lock в FB. С помощью чисто версионного механизма. Локов на чтение (на уровне записи) действительно нет.
Merle,
M> речь шла о некоем сервере, который имеет в себе оба этих M> механизма, и я лишь утверждал, что из этих двух (2PL и MV M> over 2PL) в OLTP задаче выгоднее использовать просто 2PL.
Поясни "MV over 2PL", плиз. IMHO, где-то тут гуляет легкое непонимание друг друга. Либо мы говорим об одном и том же разными словами Я выше имел ввиду, что блокирование записи на чтение в RC-транзакции достигается родными методами как в 2PC, так и в MV. В чем тут выгода 2PL?
D>> В RC WAIT версионник может работать без откатов. M> Теоретически да, на практике, либо таки откатывают, либо M> спрашивают пользователя — что хуже (для OLTP) — неизвестно.
Я показывал пример с no_rec_version, где откатов нет. Чем эта практика не устраивает? Или ты хочешь видеть неблокируемость по чтению и при этом отсутствие откатов?
Здравствуйте, dimitr, Вы писали:
D>Поясни "MV over 2PL", плиз. IMHO, где-то тут гуляет легкое непонимание друг друга.
Начну издалека.. Есть куча способов обеспечить согласованность параллельных транзакций, (aka типы планировщикаов транзакций (sheduling type)). Среди них встречаются, блокировочник — основанный на протоколе 2 фазной блокировки (2PL), Timestamp Ordering, основанный на временных метках, Serialization Graph Testing... И ни один из них не является мультиверсионным. Мультиверсионность реализуется поверх одного из этих типов планировщиков.
А рассматриваю я версионность именно поверх 2PL, потому как, во-первых, на сколько мне известно, все современные СУБД, включая IB, реализуют мультиверсионность в первую очередь поверх 2PL, хотя, естественно, не без своих хитрых наворотов. А во-вторых, в остальных типах планировщиков, и без мультиверсионности все очень грустно с откатами...
D> Я выше имел ввиду, что блокирование записи на чтение в RC-транзакции достигается родными методами как в 2PC, так и в MV. В чем тут выгода 2PL?
В том, что для MV "родным" методом блокирования являтся фиктивное обновление и порождение новой версии, со всеми вытекающими.
D>Я показывал пример с no_rec_version, где откатов нет. Чем эта практика не устраивает?
Тем что клиентский код спрашивают делать откат или все-таки не надо... Или я что-то не так понял?
D>Или ты хочешь видеть неблокируемость по чтению и при этом отсутствие откатов?
Это был бы идеальный вариант..
Здравствуйте, dimitr, Вы писали:
D>И, соответственно, select count(*) через full index scan невыполним?
Почему? вполне...
Но я выясню подробнее, как именно работает версионность с индексами.
D>Если изменены только не-блоб поля записи с блобом, версия блоба будет создана или нет? В IB/FB — нет.
Если я правильно помню, то там нет такого понятия как версия блоба, есть версия страницы блоба. Соответственно версии страниц блоба не поменяются, блобы лежат в отдельном месте, и обрабатываются независимо.
D>Направь в онлайн-доку, плиз. Для повышения моей эрудиции
Нуу... где-то здесь: http://msdn2.microsoft.com/en-us/library/ms188748.aspx
(Events That Cause Checkpoints)
и здесь: http://msdn2.microsoft.com/en-us/library/ms189573(en-US,SQL.90).aspx
(Activities That Cause a Checkpoint)
D>Если я пользую снапшот, значит я готов к откату и ручной обработке конфликтов.
Ну готов-то понятно, просто это может оказаться невыгодно или неудобно, в зависимости от задачи.
D>С помощью чисто версионного механизма.
Чисто-версионный механизм — это значит фиктивный update?
Merle,
M> В том, что для MV "родным" методом блокирования являтся M> фиктивное обновление и порождение новой версии, со всеми M> вытекающими.
В твоем примере OLTP нет фиктивного обновления. Все они там абсолютно настоящие. А раз от них никуда не деться, то почему бы и не подождать подтверждения активной версии? Факт ее наличия играет роль лока уровня записи в 2PL.
Я согласен со "всеми вытекающими" про искуственные read lock / update lock — в версионнике это всегда накладные расходы. Но в обсуждаемом OLTP нет ничего лишнего.
M> Или я что-то не так понял?
Угу. Перечитай еще раз. В режиме no_rec_version мы ждем завершения конкурента на чтении и потом перезаписываем. Соответственно, нет конфликта, нет отката и незачем спрашивать клиента. Т.е. версионный RC может легко эмулировать поведение блокировочника. Если хотим неблокирующее чтение — работаем в режиме rec_version (всегда читаем видимые нам версии и ждем конкурента только на записи) и ловим откаты. Свой выбор делаем на уровне транзакции.
M> Это был бы идеальный вариант..
Еще бы
Re[11]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
24.12.05 12:59
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>> Гм. Есть методика измерения и\или конкретные цифры ? M>Есть конкретные теоретические работы (ключевые слова: Мохан, Франклин, Ульман), и есть суровая практика. Откат очень дорогая операция практически во всех современных СУБД, если не брать в рассчет какую-нибудь экзотику (зато у этих ребят высокая стоимость фиксации). Тут выбирай, но осторожно, но выбирай. Либо дорогой роллбэк, либо дорогой коммит, дураков, понятное дело, нет.
Т.е. подтвердить свои предположения мы не можем, как впрочем и ожидалось
А>> Оператор откатывается автоматически. M>Автоматически — это как?
Движком. Без участия кого-либо еще. Я не знаю как можно не понять вышесказанное
А>> А тр-ция тут причём ??? M>Какая транзакция?
В любом SQL сервере любое действие выполняется в рамках тр-ции. Даже в MSSQL. Не знал ?
А>> Ах да, стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором "BEGIN TRAN". M>Мужик, ты о чем?!
Повторить написанное ? Перечитай сам
А>> Отсюда и знак равенства между откатом оператора и тр-ции А>>... M>??? Какой знак равенства?
Две горизонтальные параллельные палочки.
Ок, вот пример для детсада:
BEGIN TRAN
INSERT INTO T1...
INSERT INTO T2... -- здесь ошибка, любая — PK violation, триггер и т.п.
COMMIT
Q Останется ли запись в T1 ?
A Конечно.
Q Что было откачено — второй INSERT или вся тр-ция ?
A Конечно только оператор
Q Зависит ли это поведение от FB\MSSQL ?
A Нет конечно, везде одинаково
Q Кем делается COMMIT\ROLLBACK ?
A Клиентом, конечно, а как же ещё ?
Q Как клиентом, а если это скрипт\процедура ?
A И шо ? Это не клиент писал этот код ?
А>> И шо 2 тр-ции будут жить в одном коннекте ? M>Таки да.
Таки поздравляю
А>> Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо M>Правда? То есть ваш клиентский код всегда знает о других транзакциях, которые в этот момент выполняются в БД? Поздравляю, вам удалось достичь совершенства.
А зачем ему это знать ???
M>Только вот еще раз повторюсь, до такой конструкции додумался только один IB, а ни одна из серьезных БД шаловливые ручки разработчика до такой тонкой механики не допускает, даже панки из Oracle. M>Ни на какие размышления не наводит?
Здравствуйте, dimitr, Вы писали:
D>Нет метки транзакции -> неясно, видна ли нам запись.
Записи которые не видны не присутствуют в индексе, иначе им вообще бы толком пользоваться нельзя было, но это действительно надо уточнить.
D>По сути — да. Новая версия записи, помеченная моей транзакцией.
Опяь-таки, это несколько более дорогая операция по сравнению с установкой блокировки. Не даром в том же Oracle введен для таких случаев хинт FOR UPDATE, который ставит честную блокировку, а не занимается порождением фиктивных обновлений.
Здравствуйте, dimitr, Вы писали:
D>В твоем примере OLTP нет фиктивного обновления.
Почему? Фиктивное обновление — это один из способов добиться нужного уровня согласованности, в независимости OLTP у нас задача или не совсем... Правда это уже другой аспект проблемы..
D>Угу. Перечитай еще раз. В режиме no_rec_version мы ждем завершения конкурента на чтении и потом перезаписываем.
<...> D> Свой выбор делаем на уровне транзакции.
Ok, разумно, а на уровне запроса нельзя?
Здравствуйте, <Аноним>, Вы писали:
А>Т.е. подтвердить свои предположения мы не можем, как впрочем и ожидалось
Открой любой учебник — это не сложно.
А>Движком. Без участия кого-либо еще. Я не знаю как можно не понять вышесказанное
Непонять можно очень просто, мне совершенно непонятно какое отношение имеет все тобой написанное, к обсуждаемой теме. Ну совершенно.
Если не затруднит, будь пожалуйста более конкретен в своих претензиях.
Явно ощущается, что ты чем-то возмущен и недоволен, только абсолютно непонятно чем. Если есть какие-то конкретные возражения, по конкретным пунктам, то по ним и излагай, и, очень прошу, без терминов типа "детсад" и "для маленьких", а с конкретными примерами и строго по сути. А то ты приписываешь мне некие тезисы, причем даже непонятно какие именно, и пытаешься с ними спорить, очень сложно в таких условиях добиться какого-либо конструктива.
А>Повторить написанное ? Перечитай сам
Хорошо, переформулирую. К чему? Зачем излагать столь очевидные заблуждения, да еще и не имеющие никакого отношения к обсуждаемому вопросу, с таким безапеляционным пафосом?
А>Ок, вот пример для детсада: А>BEGIN TRAN А>INSERT INTO T1... А>INSERT INTO T2... -- здесь ошибка, любая — PK violation, триггер и т.п. А>COMMIT
А>Q Останется ли запись в T1 ? А>A Конечно.
Для MSSQL-я ответ не верный, так как в данном случае поведение сервера зависит от параметров соединения.
А>Q Что было откачено — второй INSERT или вся тр-ция ? А>A Конечно только оператор
Ошибаешься, см ответ выше.
А>Q Зависит ли это поведение от FB\MSSQL ? А>A Нет конечно, везде одинаково
Ну ты сам понял.
А>Q Кем делается COMMIT\ROLLBACK ? А>A Клиентом, конечно, а как же ещё ?
Опять-таки, для MSSQL-я ответ не верный, в большинстве практических случаев все вопросы решаются на сервере.
А>Q Как клиентом, а если это скрипт\процедура ? А>A И шо ? Это не клиент писал этот код ?
Очевидно, что в данном случае имеется ввиду, в рамках какого процесса выполняется принятие решения об откате или продолжении работы транзакции, а не о том кто писал этот код.
А>А зачем ему это знать ???
Чтобы не перезаписать данные чужой транзакции, приведя тем самым базу в несогласованное состояние.
А>Наводит. Ты абсолютно не понимаешь предмет беседы
Конечно. Я абсолютно не понимаю что ты пытаешься доказать, объяснить или описать, потому как все излагаемое тобой не имеет никакого отношения к предмету разговора в этой ветке.
Merle,
M> Записи которые не видны не присутствуют в индексе,
Гммм. Они там по коммиту появляются, что-ли? Бред ведь, сам посуди.
M> иначе им вообще бы толком пользоваться нельзя было,
Все остальные версионники пользуются, тем не менее.
M> но это действительно надо уточнить.
Потому и спрашиваю. У каждого подхода (хранить метки в ключе или нет) есть свои достоинства и недостатки. Интересно, какой путь избрали в MS.
M> Опять-таки, это несколько более дорогая операция по сравнению M> с установкой блокировки.
Merle,
M> Ok, разумно, а на уровне запроса нельзя?
Нельзя. Технических проблем тут нет, но в синтаксис это никогда не выносилось. Достаточно мало людей пользуют no_rec_version, и насчет смешанного режима пока никто не заикался.
Re[11]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
25.12.05 12:08
Оценка:
А>>>>Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL -это наследованная проблема, которую, думаю, уже не исправить. M>>>Во-первых — это не проблема, во-вторых ее уже исправили (ключевые слова ADO.Net 2.0, MARS, Async Query), а в третих это-то уж здесь совершенно непричем.
А>> И шо 2 тр-ции будут жить в одном коннекте ? M>Таки да.
Дорогой Merle. Я почему-то думал, что ты разбираешься хотя бы в MSSQL. Я ошибался, извини.
Уверяю тебя, что MARS (Multiple Active Result Sets) не имеет никакого отношения к нескольким одновременно живущим тр-циям в рамках одного коннекта. Прочти это и подумай ещё раз :
msdn>Though SQL Server 2005 does not support multiple active transactions per connection, the programming model already accommodates such a future enhancement
Ещё раз прошу — отделяй тр-ции от операторов (резалтсетов etc), а то каша в твоей голове так там и останется
--
Хорсун Влад
Re[13]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
25.12.05 12:51
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>Т.е. подтвердить свои предположения мы не можем, как впрочем и ожидалось M>Открой любой учебник — это не сложно.
Очень сильный аргумент. Особенно если учесть, что о работах по MVCC ты узнал пару дней назад — из этого топика и благодаря Алексу. Уже всё прочитал ?
А>>Движком. Без участия кого-либо еще. Я не знаю как можно не понять вышесказанное M>Непонять можно очень просто, мне совершенно непонятно какое отношение имеет все тобой написанное, к обсуждаемой теме. Ну совершенно. M>Если не затруднит, будь пожалуйста более конкретен в своих претензиях.
Я не люблю, когда люди говорят неправду о том, чего не понимают
M>Явно ощущается, что ты чем-то возмущен и недоволен, только абсолютно непонятно чем. Если есть какие-то конкретные возражения, по конкретным пунктам, то по ним и излагай, и, очень прошу, без терминов типа "детсад" и "для маленьких", а с конкретными примерами и строго по сути. А то ты приписываешь мне некие тезисы, причем даже непонятно какие именно, и пытаешься с ними спорить, очень сложно в таких условиях добиться какого-либо конструктива.
Ты утверждаешь, что IB\FB откатывает нечто в случае конфликта обновления. Ты не уточняешь что такое это нечто, но из твоих рассуждений очевидно, что ты не делаешь никакой разницы между откатом оператора и откатом тр-ции.
А>>Повторить написанное ? Перечитай сам M>Хорошо, переформулирую. К чему? Зачем излагать столь очевидные заблуждения, да еще и не имеющие никакого отношения к обсуждаемому вопросу, с таким безапеляционным пафосом?
В чём же я заблуждаюсь ? То, что очевидно тебе, может быть совсем не очевидно другим и даже не быть правдой
А>>Ок, вот пример для детсада: А>>BEGIN TRAN А>>INSERT INTO T1... А>>INSERT INTO T2... -- здесь ошибка, любая — PK violation, триггер и т.п. А>>COMMIT
А>>Q Останется ли запись в T1 ? А>>A Конечно. M>Для MSSQL-я ответ не верный, так как в данном случае поведение сервера зависит от параметров соединения.
SET XACT_ABORT это тоже параметр, задаваемый клиентом. Т.к. только клиент может знать, как поступать, в случае проблем одного из операторов тр-ции. Если бы сервер не имел этого параметра, он или вёл бы себя как будто бы такой пар-р был OFF, или такой сервер давно выкинули бы на свалку. Для того, чтобы этот пример имел смысл, конечно же нужно иметь SET XACT_ABORT OFF, моё упущение, согласен.
Добрый MSSQL ставит SET XACT_ABORT ON по умолчанию, дабы не непрягать мозги T-SQL кодеров такими ненужными им вещами, как управление тр-циями. Аминь
А>>Q Что было откачено — второй INSERT или вся тр-ция ? А>>A Конечно только оператор M>Ошибаешься, см ответ выше.
А>>Q Зависит ли это поведение от FB\MSSQL ? А>>A Нет конечно, везде одинаково M>Ну ты сам понял.
Ага, MSSQL и тут отличился
А>>Q Кем делается COMMIT\ROLLBACK ? А>>A Клиентом, конечно, а как же ещё ? M>Опять-таки, для MSSQL-я ответ не верный, в большинстве практических случаев все вопросы решаются на сервере.
А что такое сервер ? Подумай хорошенько, перед тем как ошибаться опять. Hint — внутри 'сервера' есть много разного, в том числе и клиенты
А>>Q Как клиентом, а если это скрипт\процедура ? А>>A И шо ? Это не клиент писал этот код ? M>Очевидно, что в данном случае имеется ввиду, в рамках какого процесса выполняется принятие решения об откате или продолжении работы транзакции, а не о том кто писал этот код.
А причём тут процесс ? Интерпретатор скриптов T-SQL такой же клиент, по отношению к SQL-движку, как и программа Васи Пупкина. То, что он физически выполняется в одном процессе с SQL-движком, не даёт ему никаких дополнительных прав. И любая последовательность операторов должна выполняться одинаково, независимо от того батч это, процедура, или их исполняют по-одному. Еще раз — перестань ставить знак равно между откатом оператора и тр-ции. Даже если это иногда выглядит, как одно и то же
А>>А зачем ему это знать ??? M>Чтобы не перезаписать данные чужой транзакции, приведя тем самым базу в несогласованное состояние.
А откуда ты знаешь какое состояние есть согласованное ??? БД знает только о декларативных ограничениях и их всегда выполняет. Но о логической согласованности (о том же балансе) она понятия не имеет. И причём тут состояние мифического внутреннего шедулера ?
А>>Наводит. Ты абсолютно не понимаешь предмет беседы M>Конечно. Я абсолютно не понимаю что ты пытаешься доказать, объяснить или описать, потому как все излагаемое тобой не имеет никакого отношения к предмету разговора в этой ветке.
Тогда закончим на этом. Только не нужно высказываться о IB\FB — ты совершенно не владеешь вопросом.
Здравствуйте, Аноним, Вы писали:
А>Я почему-то думал, что ты разбираешься хотя бы в MSSQL.
Я воощем-то никогда и не пртендовал...
А>Уверяю тебя, что MARS (Multiple Active Result Sets) не имеет никакого отношения к нескольким одновременно живущим тр-циям в рамках одного коннекта.
Ну почему же, примерно такое же как и поднятая тобой тема к данному топику.
Однако, радует уже то, что ты ходишь по указанным ссылкам, к сожалению не по всем, я говорил нетолько про MARS.
А>Ещё раз прошу — отделяй тр-ции от операторов (резалтсетов etc), а то каша в твоей голове так там и останется
Вот от обсуждения качества каши попрошу воздержаться, уверяю, это не так сложно, я же сдерживаюсь, хотя, надо признаться, с трудом.
Здравствуйте, Аноним, Вы писали:
А> Особенно если учесть, что о работах по MVCC ты узнал пару дней назад — из этого топика и благодаря Алексу.
А>Я не люблю, когда люди говорят неправду о том, чего не понимают
Что именно из того что я сказал является по твоему неправдой? Я пытаюсь добиться внятного ответа на этот вопрос уже на протяжении нескольких постингов. Можно быть всетаки более конкретным? А то мой запас терпения потихоньку испаряется.
А>Ты утверждаешь, что IB\FB откатывает нечто в случае конфликта обновления.
Нет. Я утверждаю, что версионный механизм (не важно какой) вынужден откатывать в случае конфликта обновления на любых уровнях изоляции выше RC (он так устроен, за подробностями к Бернстайну, хотя бы). И что на практике известные мне версионники в большинстве случаев откатывают даже при RC.
Как меня совершенно корректно поправили в соседней подветке, в IB есть режимы которые позволяют не откатывать транзакцию. Отлично, я в IB не краевед, хорошо если так, но к поднятому здесь вопросу это имеет довольно посредственное отношение.
А>Ты не уточняешь что такое это нечто, но из твоих рассуждений очевидно, что ты не делаешь никакой разницы между откатом оператора и откатом тр-ции.
Во-первых я очень конкретно говорю, что именно откатывается, если это имеет значение в обсуждаемом контексте и даже специально уточняю. А во-вторых, то что я не делаю разницы — это не более чем плод чей-то довольно возмущенной фантазии.
А>В чём же я заблуждаюсь ?
Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
А>SET XACT_ABORT это тоже параметр, задаваемый клиентом.
Давай ты тогда сначала дашь определение клиента, а заодно и сервера, а потом мы продолжим этот разговор, причем скорее всего в отдельной ветке.
А> Подумай хорошенько, перед тем как ошибаться опять.
Вот только давай без демагогии. Покажи, сначала, где я ошибся хоть один раз, потом поговорим.
А>Еще раз — перестань ставить знак равно между откатом оператора и тр-ции.
Покажи хоть одно место, где я его ставил.
А>А причём тут процесс ?
Понятно, дальше можешь не продолжать. Все вопросы снимаются, с темой предлагаю завязывать.
А> Только не нужно высказываться о IB\FB — ты совершенно не владеешь вопросом.
А я вообщем-то и не высказывался. Это вы тут налетели со своим IB на перевес вообще не разобравшись о чем идет речь, хотя я до последнего старался никаких конкретных серверов вообще неупоминать.
Мы уже победили, просто это еще не так заметно...
Re[13]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
25.12.05 16:27
Оценка:
Здравствуйте, Merle, Вы писали:
А>>Уверяю тебя, что MARS (Multiple Active Result Sets) не имеет никакого отношения к нескольким одновременно живущим тр-циям в рамках одного коннекта. M>Ну почему же, примерно такое же как и поднятая тобой тема к данному топику.
Я не обсуждаю топик. Это не заметно ?
M>Однако, радует уже то, что ты ходишь по указанным ссылкам, к сожалению не по всем, я говорил нетолько про MARS.
1. Ты не дал мне ни одной ссылки, так что рабоваться тебе нечему
2. Ты упомянул MARS в качестве ответа на мой вопрос об нескольких одновременно активных тр-циях в одном коннекте.
3. Я привёл совершенно конкретную цитату, в которой говорится об отсутствии этой фичи в Юконе. Ты думаешь, что в доке по ADO.NET или AsyncQuery она появится волшебным образом ?
4. Ты сознательно убираешь значимые цитаты из обсуждения ?
А>>Ещё раз прошу — отделяй тр-ции от операторов (резалтсетов etc), а то каша в твоей голове так там и останется M>Вот от обсуждения качества каши попрошу воздержаться, уверяю, это не так сложно, я же сдерживаюсь, хотя, надо признаться, с трудом.
Та ради бога, тебе жить.
Я очень напуган (вдруг ты не сдержишься) и удаляюсь...
Здравствуйте, dimitr, Вы писали:
D>Гммм. Они там по коммиту появляются, что-ли?
То есть по коммиту? По коммиту, удаляется из индекса старый ключ и вставляется новый.
Пока они молчат по поводу версий и индекса, вполне возможно что версия в ключе и присутствует, и когда они в доках пишут: "Row versioning information ... added to the database row", то под "database row" то имеется ввиду и ключ индекса, хотя вряд ли...
D>Не спорю. Но возможность есть.
Есть конечно, с этим никто и не спорит, но тут вопрос цены...
Здравствуйте, <Аноним>, Вы писали:
А>Я не обсуждаю топик. Это не заметно ? Очень. Я так и не понял что ты обсуждаешь и если не топик, тогда вообще непонятно что ты здесь делаешь...
А>1. Ты не дал мне ни одной ссылки, так что рабоваться тебе нечему
Ну я все же надеюсь, что ты достаточно самостоятельный мальчик, чтобы воспользоваться BOL по ключевым словам.
А>3. Я привёл совершенно конкретную цитату, в которой говорится об отсутствии этой фичи в Юконе.
Только ты привел совершенно конкретную цитату из статьи описывающей бетту сиквела, а не релиз, а с тех пор там кое что поменялось. А во-вторых, ты даже эту статью прочитал не внимательно, там говорилось что это действительно не совсем параллельные транзакции, в том смысле, что сервер не может их двигать достаточно произвольно друг относительно друга, как он поступает с обычными транзакциями, а будет отдавать операторы на выполнение поочереди, переключаясь на другую транзакцию в строго определенных точках, но, тем не менее, это две совершенно самостоятельные транзакции.
Даже термин специальный ввели — batch transaction, который имеет смысл только для MARS-а. Так что на товй вопрос "И шо 2 тр-ции будут жить в одном коннекте ?", я совершенно верно ответил утвердительно, и абсолютно не понимаю твоих претензий...
А>4. Ты сознательно убираешь значимые цитаты из обсуждения ?
Ни одну значимую цитату из обсуждения я не убрал, благо значимого тут не много.
А>Я очень напуган (вдруг ты не сдержишься) и удаляюсь...
Ну слава байту, хоть бессмысленых споров на пустом месте не будет.
Здравствуйте, <Аноним>, Вы писали:
А>Т.е. не отрицаешь, ок.
Ну а чего бисер метать, если тебе так удобнее, считай что я в этом не разбираюсь..
А> Может тогда не будешь мне повсюду предлагать перечитать эти работы ?
Почитай-почитай, очень полезно для расширения кругозора.
А>И спроси себя — а зачем он встрял
Вот это я понять отчаялся, ты тоже молчишь... Время просто убиваешь?
А>Вах! И что же будет ?
Да не многое, подветка уедет в мусорку и разговор прекратится.
А>Ё-маё... IB никогда сам не откатывает тр-цию ! Повтори себе это N раз. Или M
Да хоть X. Мне совершенно однофигственно что там делает IB, благо в соседней подветке с этим уже разобрались, без чужой помощи и истерик.
Хотя в данном случае действительно описался, не транзакцию, а запрос, конечно же.
А>Да ?
Да.
А> И где же ты хоть раз "очень конкретно" сказал ?
Везде где это имело значение.
А>Это не заблуждение.
Заблуждение.
А> Это наблюдение.
Значит не так или не за теми наблюдал.
А>Мне есть чем заняться, поверь.
Понятно, ко всем прочим недостаткам ты еще и оперируешь терминами не утруждая себя из объяснением. В таких условиях разговор в принципе смысла не имеет.
А>Я разве мало показал ?
Кроме экспрессии не по делу и нескольких не очень аккуратных высказываний ты не показал ничего.
А>Покажи хоть одно место, где ты его не ставил.
Я его не ставил нигде, это все чъя-то бурная фантазия или другие ингредиенты...
Здравствуйте, dimitr, Вы писали:
D>Гммм. Они там по коммиту появляются, что-ли?
Все таки чуть-чуть прогнал, "Index rows can be versioned as well as data rows"...
Так что на ключах индекса так же сидят версионные метки и они по честному уезжают в отдельное version store heap по мере устаревания.
Merle,
M> на твой вопрос "И шо 2 тр-ции будут жить в одном коннекте ?", M> я совершенно верно ответил утвердительно, и абсолютно не понимаю M> твоих претензий...
Дело в том, что "нормальные пацаны" в упор не понимают специфического отношения MS к транзакциям и коннектам. Ты в данном случае отмазываешься (термин не в обиду), цепляясь к словам. Типа честно ответил "будут жить". А уж как будут — меня не спрашивали. А, как достаточно очевидно даже ораклоидам , речь про полную независимость транзакций от коннектов. Чего MS сделать, похоже, пока никак не могёт. Или не хотит — тут не мне судить.
ЗЫ. Если несогласен, то предлагаю продолжить оффтопик в новой ветке...
Merle,
M> То есть по коммиту? По коммиту, удаляется из индекса M> старый ключ и вставляется новый.
Т.е. если (берем эту ситуацию абстрактно, вне привязки к Юкону) я обновил таблицу и потом по ней делаю селект, я должен (а) не увидеть своих же изменений (мой ключ не попал в индекс) или (б) пойти фуллсканом? Так что ли? Весело, однако...
Re: А если + пара-тройка отчетников или аналитиков ?
какие в данном случае могут быть рекомендации по эффективности с версионностью ?
А аналитики могут случиться в будущем. Хотя немного.
Чего тогда ?
_______________
Надо сказать вынос обработки внутренних проблем задачи на верхний уровень клиента —
очень плохая практика в программировании вообще. ООП, структурность, разделение уровней.... и.т.п.
Сейчас крайне важна также хорошая структуризованность кода,
иначе все будет неподдерживаться и из-за сложностей падать,
и много времени разрабатываться.
Поэтому если в версинности приходится обрабатываться "просто веселости внутренней обработки"
то это крайне плохой стиль,
который может быть оправдан только крайне высокой производительностью
в некоторых солучаях, но я так понимаю этого нет ?
Здравствуйте, dimitr, Вы писали:
D>Соответственно, при обновлении мной неиндексированного поля А, в индексе изменяются ключи индексированных полей B, C, ..., X?
Зачем им изменяться? При обновлении неиндексированного поля индекс не трогается, соответственно там ничего не меняется.
Здравствуйте, dimitr, Вы писали:
D>Иван, ну хоть скажи, что изменилось-то? Ты ведь владеешь информацией. А то как дети, ей богу.
Да немного. Просто они подчистили поведение с транзакциями и ввели эти самые batch transaction, которые отличаются от обычных только тем, что если они явно открыты в пакете, то в этом же пакете должны быть явно закрыты, и работают "параллельно" с другими транзакциями в том же коннекте так, как я описал в предыдущем ответе.
Здравствуйте, dimitr, Вы писали:
D>Дело в том, что "нормальные пацаны" в упор не понимают специфического отношения MS к транзакциям и коннектам.
А чего тут не понимать? Все просто как рельс..
D> Ты в данном случае отмазываешься (термин не в обиду), цепляясь к словам.
Ну а чего мне еще остается? Уводят всячески разговор в сторону цепляясь непонятно к чему — какой вопрос, такой и ответ...
D> Чего MS сделать, похоже, пока никак не могёт. Или не хотит — тут не мне судить.
Как бы подвох в том, что правило один коннект — одна активная транзакция, вообщем-то никому и не мешало. Даже сейчас MARS ввели, по большему счету, не для того чтобы таки это ограничение снять, а в качестве замены серверным курсорам.
Другое дело, что MARS потенциально можно нарастить до действительно независимых транзакций в одном конекте, но они будут еще долго думать по этому поводу, так как польза не очевидна, а программная модель усложнится.
Merle,
M> Зачем им изменяться? При обновлении неиндексированного поля индекс M> не трогается, соответственно там ничего не меняется.
Новая версия записи будет иметь другую метку транзакции. А раз метка входит в ключ, то ключ должен поменяться.
Есть запись (PK, COL) = (1, 1), закоммиченная транзакцией #10. Транзакция #11 меняет значение поля COL на 2. Как теперь индексным сканом по PK определить, что значение PK=1 относится к обоим версиям записи?
Здравствуйте, dimitr, Вы писали:
D>Новая версия записи будет иметь другую метку транзакции. А раз метка входит в ключ, то ключ должен поменяться.
Не, мухи отдельно, котлеты отдельно...
У ключей своя метка, у записи своя. Метка состоит из идентификатора транзакции, и ссылки на предыдущую версию. У записи метка поменяется, но у ключа метка останется не тронутой, поскольку его эта транзакция не меняла.
D>Есть запись (PK, COL) = (1, 1), закоммиченная транзакцией #10. Транзакция #11 меняет значение поля COL на 2. Как теперь индексным сканом по PK определить, что значение PK=1 относится к обоим версиям записи?
Очень просто. Нас интересует запрос SELECT COL FROM ... WHERE PK=1. Выполняем сканирование индекса на предмет PK=1, находим нашу запись и выясняем, что она нам подходит, так как ее меняла транзакция #10, потом лезем в обычную таблицу и смотрим там значение COL. Если нас интересует старое значение, то лезем по ссылке в хранилище версий и берем предыдущую версию с меткой 10й транзакции, а если новое то, в хранилище не лезем.
Иными словами, значения ключевых полей берутся из индекса, а не ключевых из основной таблицы.
Здравствуйте, dimitr, Вы писали:
D>Не надо говорить за всех. Это мешает тем, кто знает, что можно по другому.
Скорее наоборот, это не мешает тем кто знает как пользоваться эффективно тем что есть.
D> И эффективно этим пользуется на "более других" серверах.
На более других серверах это возможно и актуально, я за всех вообщем-то и не говорю...
D>Впрочем, это вы с Владом обсуждайте, если интересно
Совершенно не интересно, я признаться так и не понял, к чему эта тема здесь поднялась.
D> Мне от этой темы не горячо и не холодно.
А уж мне-то...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[18]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
26.12.05 13:33
Оценка:
D>Впрочем, это вы с Владом обсуждайте, если интересно Мне от этой темы не горячо и не холодно.
Мне уже тоже, Алекс таки прав
Re[17]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
26.12.05 13:35
Оценка:
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Аноним, Вы писали:
А>>>>В чём же я заблуждаюсь ? M>>>Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
А>>Это не заблуждение. Это наблюдение. Можешь провести опрос.
___>Давай ты там не будешь подписываться за MSSQL кодеров, к которым ты не имеешь никакого отношения и ничего не знаешь о них. Наблюдательный ты наш.
А ведь ты не знаешь ни где я работаю, ни что я делаю, ни с каким сервером...
Re[12]: 2 Alex
От:
Аноним
Дата:
26.12.05 13:59
Оценка:
V>>что я хотел узнать — когда именно лучше в реальном приложении, V>>пир каких действиях и установках. M>Когда строится много отчетов по активно изменяющимся данным.
Например, склад, бронь билетов/мест, денежные балансы и еще огромное количество реальных задач.
D>В IB/FB стартуешь транзакцию READ_COMMITTED NO_REC_VERSION WAIT и он работает как блокировочник, т.е. при обнаружении нами активной чужой версии записи ждем завершения (любого) транзакции-конкурента на ее (записи) чтении, а не на апдейте. После чего успешно читаем результат и перезаписываем его своим. Для версионника это не совсем ожидаемый режим и он редко кем используется, однако он существует и при желании может быть применен в OLTP.
А что, кстати, с конфой эпсилоновской? Чё-то недоступна. Или это только у меня?
У меня тут вопрос важный-важныйвсплыл неожиданно, связан как раз с тем, что READ_COMMITTED NO_REC_VERSION WAIT иногда не работает как надо, и дает ошибку конфликта (deadlock update conflicts with concurrent update). Это воспроизводится неустойчиво, но регулярно, на большом потоке конкурирующих запросов на обновление одной записи. Тихо и вручную — не воспроизводится. FB SS 1.5.2, Linux
___>Ну ты расскажи нам. "А мужики-то не знают" как ты крут. Но судя насчет: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..." — в этом вопросе ты не разбираешься. Но, тем не менее, делаешь безапеляционные заявления. Того, что ты сюда запостил достаточно тебя характеризует. Рекомендую поменьше понтов и побольше конструктива. И давай ты будешь делать заявления от своего имени, а не от T-SQL кодеров — т.е. в том числе от меня. Ага?
Иди в сад, дорогой, и поучись там отличать иронию от наездов, да ?
--
Влад
PS А "мужики" как раз "знают" всё, что им необходимо
PPS Саморекламой не занимался и не собираюсь заниматься
Здравствуйте, Alex.Che, Вы писали:
AC>Привет, _d_m_! AC>Вы пишешь 28 декабря 2005:
AC>[Sorry, skipped] d>> Тебя никто и не просит. Просто попросили... хм... не выеживаться
AC>Хто тут?!
Ну в точности как в анекдоте:
Театр, полный зал зрителей, темно. Выходит на сцену мужик с горящей свечой, садится на стул, начинает дро...ть. Тут кто-то чихает в зале, мужик испугано оглядывается:
Мы уже победили, просто это еще не так заметно...
Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо 
Или это только у меня?
