Здравствуйте, Аноним, Вы писали:
А>Я почему-то думал, что ты разбираешься хотя бы в 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 на перевес вообще не разобравшись о чем идет речь, хотя я до последнего старался никаких конкретных серверов вообще неупоминать.
Здравствуйте, 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 на перевес вообще не разобравшись о чем идет речь, хотя я до последнего старался никаких конкретных серверов вообще неупоминать.
Ок, спи спокойно
--
Хорсун Влад
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> старый ключ и вставляется новый.
Т.е. если (берем эту ситуацию абстрактно, вне привязки к Юкону) я обновил таблицу и потом по ней делаю селект, я должен (а) не увидеть своих же изменений (мой ключ не попал в индекс) или (б) пойти фуллсканом? Так что ли? Весело, однако...
Здравствуйте, Аноним, Вы писали:
А>>>В чём же я заблуждаюсь ? M>>Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
А>Это не заблуждение. Это наблюдение. Можешь провести опрос.
Давай ты там не будешь подписываться за MSSQL кодеров, к которым ты не имеешь никакого отношения и ничего не знаешь о них. Наблюдательный ты наш.
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 относится к обоим версиям записи?
Мы уже победили, просто это еще не так заметно...
