Здравствуйте, 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
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, Аноним, Вы писали:
А>>>>>В чём же я заблуждаюсь ? M>>>>Например, в том что: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..."
А>>>Это не заблуждение. Это наблюдение. Можешь провести опрос.
___>>Давай ты там не будешь подписываться за MSSQL кодеров, к которым ты не имеешь никакого отношения и ничего не знаешь о них. Наблюдательный ты наш.
А>А ведь ты не знаешь ни где я работаю, ни что я делаю, ни с каким сервером...
Ну ты расскажи нам. "А мужики-то не знают" как ты крут. Но судя насчет: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..." — в этом вопросе ты не разбираешься. Но, тем не менее, делаешь безапеляционные заявления. Того, что ты сюда запостил достаточно тебя характеризует. Рекомендую поменьше понтов и побольше конструктива. И давай ты будешь делать заявления от своего имени, а не от T-SQL кодеров — т.е. в том числе от меня. Ага?
Re[19]: SQL 2005 стал быстрее с версионностью?
От:
Аноним
Дата:
27.12.05 08:50
Оценка:
___>Ну ты расскажи нам. "А мужики-то не знают" как ты крут. Но судя насчет: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..." — в этом вопросе ты не разбираешься. Но, тем не менее, делаешь безапеляционные заявления. Того, что ты сюда запостил достаточно тебя характеризует. Рекомендую поменьше понтов и побольше конструктива. И давай ты будешь делать заявления от своего имени, а не от T-SQL кодеров — т.е. в том числе от меня. Ага?
Иди в сад, дорогой, и поучись там отличать иронию от наездов, да ?
--
Влад
PS А "мужики" как раз "знают" всё, что им необходимо
PPS Саморекламой не занимался и не собираюсь заниматься
Здравствуйте, Аноним, Вы писали:
___>>Ну ты расскажи нам. "А мужики-то не знают" как ты крут. Но судя насчет: "...стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором BEGIN TRAN..." — в этом вопросе ты не разбираешься. Но, тем не менее, делаешь безапеляционные заявления. Того, что ты сюда запостил достаточно тебя характеризует. Рекомендую поменьше понтов и побольше конструктива. И давай ты будешь делать заявления от своего имени, а не от T-SQL кодеров — т.е. в том числе от меня. Ага?
А>Иди в сад, дорогой, и поучись там отличать иронию от наездов, да ?
Видать ты в какой-то не такой сад ходишь — пока сам не умеешь.
А>-- А>Влад
А>PS А "мужики" как раз "знают" всё, что им необходимо
Главное что ты у нас все знаешь.
А>PPS Саморекламой не занимался и не собираюсь заниматься
Тебя никто и не просит. Просто попросили... хм... не выеживаться
Здравствуйте, Alex.Che, Вы писали:
AC>Привет, _d_m_! AC>Вы пишешь 28 декабря 2005:
AC>[Sorry, skipped] d>> Тебя никто и не просит. Просто попросили... хм... не выеживаться
AC>Хто тут?!
Ну в точности как в анекдоте:
Театр, полный зал зрителей, темно. Выходит на сцену мужик с горящей свечой, садится на стул, начинает дро...ть. Тут кто-то чихает в зале, мужик испугано оглядывается:
Мы уже победили, просто это еще не так заметно...
Или это только у меня?
)))))))))))