Здравствуйте, Кузьменко Д.В.
КДВ>и? статья-то о том, что КДВ>а) данных уровней изолированности не хватает КДВ>б) базовые уровни изолированности ориентированы на блокировочные сервера КДВ>в) некоторые уровни изолированности описаны криво
КДВ>все это не говорит о том, что единственно возможный применимый в реальной жизни уровень КДВ>изолированности транзакций — сериализация.
Вы путаете уровень изоляции и сериализуемость сценария. КДВ>Да, я согласен, некоторые задачи КДВ>решаются только сериализацией.
Что вы называете "сериализацией"? КДВ>Например, у меня на курсах примерно в 98 году был КДВ>мужик, который заявил: КДВ>- зачем вы об уровнях изолированности рассказываете? у нас все четко — вагон КДВ> пришел, попал под разгрузку, и ушел. Тут никаких конфликтов быть не может.
Не надо ему уподобляться. КДВ>Но в реальной жизни сериализация — вовсе не обязательное условие, а даже очень частное.
Сериализация — это про превращение данных в поток байт. Сериализуемость — это четко математически определенное свойство последовательности операций. Читайте литературу, хотя бы ту же статью, за определением. КДВ>Два человека могут читать одну книгу одновременно. КДВ>несколько человек могут находиться в одном вагоне. КДВ>несколько человек могут читать копию одной книги одновременно КДВ>и так далее.
Математика совершенно однозначно говорит, какие сценарии можно представить в виде последовательности выполняющихся друг за другом транзакций, а какие — нельзя.
По-хорошему, работа СУБД состоит в том, чтобы запрещать все сценарии, кроме сериализуемых. Потому, что иначе могут возникнуть проблемы с целостностью данных.
Но точное выполнение этих запретов — достаточно дорогое удовольствие. Поэтому ввели такое понятие, как "уровень изоляции".
Его смысл сводится к тому, что если вы опустили уровень изоляции ниже, чем SERIALIZABLE, то СУБД запрещает не все аномальные сценарии, а только некоторые из них. Статья как раз описывает, какие сценарии запрещаются каким уровнем изоляции. Так вот, остальные аномальные сценарии придется запрещать вам, как разработчику. Уровень изоляции —
это способ сказать СУБД "не напрягайся, вот за этим я сам прослежу". В частности, если мы точно знаем, что в пределах транзакции происходит однократное чтение, то можно ее выполнять и на RC — сериализуемость не нарушится. Несмотря на более низкий уровень изоляции по сравнению с SERIALIZABLE. Это и есть ваш пример про книгу и вагон.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andyshark, Вы писали: S>>не догнал. Уж очень задача экзотическая. A>Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей.
Послушай, то, что ты тут пишешь — поток сознания. Тебе может быть и понятно, кто там на ком стоял, но я до сих пор не вижу внятного объяснения, что собственно должно быть сделано. Это всё от того, что ты половину думаешь, а половину пишешь. При чем тут "проверка по таймеру"? Какое это отношение к транзакциям имеет? Я не понимаю, как ты откатом одной транзакции собираешься отменить часть напечатанных данных.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>не догнал. Уж очень задача экзотическая. A>>Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей. S>Послушай, то, что ты тут пишешь — поток сознания. Тебе может быть и понятно, кто там на ком стоял, но я до сих пор не вижу внятного объяснения, что собственно должно быть сделано. Это всё от того, что ты половину думаешь, а половину пишешь. При чем тут "проверка по таймеру"? Какое это отношение к транзакциям имеет? Я не понимаю, как ты откатом одной транзакции собираешься отменить часть напечатанных данных.
Tr.Rollback;
PrintString('Отмена печати');
Еще раз — печать идет пакетом. Если напечаталось две строки из пакета, но не напечаталась третья то надо сделать откат. А про таймер было написано к тому что записи может добавлять один компьютер, а печатать совсем другой. А мне влом проверку делать по таймеру просто (хотя и можно конечно). Но это к слову было сказано. Видно зря, вырвалось. Вырежи из контекста и обрати внимание на транзакции.
А запоминать какие строки были уже напечатаны и удалять их в этой же транзакции... Ну почему нельзя просто сразу сделать удаление, а в случае ошибки откатить транзакцию? Кстати, чем не 2 способа решения одной задачи?
P.S. Задача довольно специфическая. Но почему тут нельзя использовать 2 транзакции? Во всем посте слышно только одно — две транзакции в коннекте нельзя потому что нельзя... Помнится так же говорили и в средние века когда казнили еретиков. Хорошо тогда транзакций не было
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, SmlMouse, Вы писали:
SM>>Эх, жалко я теорию автоматов закинул... Там вроде дедлок можно было разрешить только внешним воздействием? SM>>А мы видимо уже стали частью системы...
___>Вы уже давно стали частью файрберда, вы лишь его послушные роботы. Вас надо уничтожить.
Здравствуйте, Andyshark, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
S>>>>не догнал. Уж очень задача экзотическая. A>>>Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей. S>>Послушай, то, что ты тут пишешь — поток сознания. Тебе может быть и понятно, кто там на ком стоял, но я до сих пор не вижу внятного объяснения, что собственно должно быть сделано. Это всё от того, что ты половину думаешь, а половину пишешь. При чем тут "проверка по таймеру"? Какое это отношение к транзакциям имеет? Я не понимаю, как ты откатом одной транзакции собираешься отменить часть напечатанных данных.
A>Tr.Rollback; A>PrintString('Отмена печати');
A>Еще раз — печать идет пакетом. Если напечаталось две строки из пакета, но не напечаталась третья то надо сделать откат.
Совершенно верно. Непонятно мне ровно одно — зачем читать в одной, а удалять в другой?
Вот тебе код, который делает то, что нужно:
set transaction isolation level repeatable read
begin tran
select top 10 * from printQueue order by priority
-- здесь идет цикл выборки, и для каждой строки выполняем:delete printQueue where id = 45
delete printQueue where id = 46
delete printQueue where id = 47
delete printQueue where id = 48
delete printQueue where id = 49
commit tran-- сюда мы попадаем если всё удалось
Если где-то произошла ошибка, то мы делаем rollback, и всё откатывается обратно. A>А запоминать какие строки были уже напечатаны и удалять их в этой же транзакции...
Ничего не надо запоминать. A>Ну почему нельзя просто сразу сделать удаление, а в случае ошибки откатить транзакцию? Кстати, чем не 2 способа решения одной задачи?
Можно. Код я привел.
A>P.S. Задача довольно специфическая. Но почему тут нельзя использовать 2 транзакции?
Потому, что не сработает. Ты же печатаешь на десяти принтерах, так? Откат "второй" транзакции откатит все пакеты. Должно быть столько транзакций, сколько принтеров.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>это способ сказать СУБД "не напрягайся, вот за этим я сам прослежу". В частности, если мы точно знаем, что в пределах транзакции происходит однократное чтение, то можно ее выполнять и на RC — сериализуемость не нарушится. Несмотря на более низкий уровень изоляции по сравнению с SERIALIZABLE.
Неверно, read committed не обеспечивает консистентный набор даже на уровне одного стейтмента, что совершенно не похоже на serializable.
Здравствуйте, Gt_, Вы писали:
Gt_>да, это. оракл обеспечивает консистентный набор стейтмента на IL RC, т.е. Gt_>в набор попадут только те записи какие были закомичены на момент старта стейтмента. Gt_>у FB же RC гораздо слабее
Иван, и стоило создавать для этой ахинеии клона?
Повторяю, ты НИХРЕНА не знаешь о "подуровнях" RC в FB.
И продолжаешь нести...
AC>Иван, и стоило создавать для этой ахинеии клона?
я не пойму, это вы меня клоном Мерле пытаесь записать вы тут совсем новенький что-ли ?
AC>Повторяю, ты НИХРЕНА не знаешь о "подуровнях" RC в FB. AC>И продолжаешь нести...
походу как и в случае с логом транзакции вы не вьехали в термин consistency, если все таки осили то комбинацию параметров команды SET TRANSACTION которые обеспечат statement level consistency на read committed в студию ...
Здравствуйте, Gt_, Вы писали:
AC>>Иван, и стоило создавать для этой ахинеии клона?
Gt_>я не пойму, это вы меня клоном Мерле пытаесь записать Gt_>вы тут совсем новенький что-ли ?
Вань, не стыдно?
Хоть бы слова в предложениях переставлял...
SP_>И это заявляет человек, первое сообщение которого датируется вчерашним днем
там наверху есть иконка поиск, не поверите он работает.
правда большинство постов Мерле сносил напрчь, но кое что из баталий во флейме уцелело: http://www.rsdn.ru/Forum/?mid=559239
Здравствуйте, Gt_, Вы писали:
AC>> Вань, не стыдно? AC>>Хоть бы слова в предложениях переставлял...
Gt_>это означает вы осилили термин consistency или мне еще Gt_>стоит ждать комбинацию параметров для IBшного set transaction ?
цирк продолжается...
Ню-ню, упорствуй, упорствуй...
Иван, ты сперва почитай таки доку, ссылку на которую
тебе дали, а потом приходи, будем обсуждать нюансы
IL RC в FB, и его отличия от Oracle с его "миниоткатами".
До тех пор, пока не прочитаешь и не скажешь:
"Ааааа, так ты имеешь в виду ЭТО...", — разговора не получится.
Дерзай.
Здравствуйте, Gt_, Вы писали:
SP_>>И это заявляет человек, первое сообщение которого датируется вчерашним днем
Gt_>там наверху есть иконка поиск, не поверите он работает. Gt_>правда большинство постов Мерле сносил напрчь, но кое что из баталий во флейме уцелело: Gt_>http://www.rsdn.ru/Forum/?mid=559239
Здравствуйте, SP_, Вы писали:
SP_>По линке баталия Merle с анонимом. Какое вы имеете к той баталии отношение —
См последнюю строчку в постах анонима...
Почему он зарегистрировался только сейчас вопрос к Gt_
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gt_, Вы писали:
Gt_>>>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...
КДВ>>опять цирк. как раз по crash/recovery IB/FB тест пройдет. Потому что не надо "накатывать" или "откатывать" КДВ>>логи. почитайте наконец, что-нибудь о версионных движках.
Gt_>поверьте о версионности я вполне просвещен, а вот вы немного не вьезжаете о чем речь. попробуйте выдохнуть и неуподоблятся Мерле несущему ахинею. что такое лог транзакций вы думаю можете почитать в доке к последнему IB, там наконец его реализовали. применительно к tpc речь идет о простеньком тесте, вот например, что должен был пройти оракл в последнем tpc-c тесте:
нет, это Вы несете ахинею. потому что я в курсе, что такое transaction log, и потому,
что в IB 2007 реализован не transaction log, а журнал, т.е. write ahead log. И он страничный.
И вообще не для того, о чем Вы подумали.
Gt_>5. Removed a disk from an array containing database data.
тут я не знаю, что сказать, потому что из данного описания неясно, что это
за диск.
Gt_>7. The removed disk was replaced from the spares and the logical drives on that Gt_>array were restored from backup.
я посмотрю.
КДВ>>поясните пожалуйста, про "кашу в наборе". Вы не это имеете в виду? КДВ>>http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2
Gt_>да, это. оракл обеспечивает консистентный набор стейтмента на IL RC, т.е. в набор попадут только те записи какие были закомичены на момент старта стейтмента. у FB же RC гораздо слабее
если моя аргументация в том топике не катит, то...
и заметьте — в том топике это именно я объясняю про неатомарность select в RC в IB/FB, и
там же объясняю, почему это не так важно.
Здравствуйте, Gt_, Вы писали:
Gt_>это означает вы осилили термин consistency или мне еще стоит ждать комбинацию параметров для IBшного set transaction ?
например:
read write
consistency
nowait
или
read write
concurrency
nowait
оба случая — уровень изолированности snapshot.
по поводу стабильности курсора в RC в FB — лично я считаю что это ну никак не мешает понятию Read Committed.
в топике, который я упоминал, должны быть примеры, почему.
Здравствуйте, _d_m_, Вы писали:
___>Если речь о лицензировании SQL Server, то одна лицензия на на пользователя подразумевает неограниченное кол-во подключений этого пользователя. Так шта опять мимо.
почему-же мимо? обломились рубить бабло за коннект именно потому, что архитектура не позволяет
использовать один коннект. приходится открывать много, а значит с лимитированием по коннектам — облом.
Там где можно лимитировать коннекты — еще как лимитируют, и рубят бабло.
и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )
КДВ>если моя аргументация в том топике не катит, то... КДВ>и заметьте — в том топике это именно я объясняю про неатомарность select в RC в IB/FB, и КДВ>там же объясняю, почему это не так важно.
аргументация чАго ? что RC в IB/FB способен получить консистентный набор ? что RC в oracle на это не способен ? я не понимаю что вы своей аргументацией хотите сказать ...
КДВ>по поводу стабильности курсора в RC в FB — лично я считаю что это ну никак не мешает понятию Read Committed. КДВ>в топике, который я упоминал, должны быть примеры, почему.
не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?
КДВ>тут непонятно, почему база осталась corrupted, если бэкап был восстановлен.
бэкап делался до прогона теста, т.е. на него еще нужно накатить лог.
