|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Сначала коротко Все транзакции: read_write + read_commited + rec_version + wait. транзакция "А" закоммичена транзакция "B" закоммичена и видит изменения от "А" (зависит от них) транзакция "С" уже видит изменения транзакции "B", но не видит изменения транзакции "А". "B" стартовала строго после коммита "A". Когда стартовала "С" неизвестно. Т.е. например утрируя, приходная накладная есть, зависящая от неё расходная есть, читаем всё, видим только расходную, появившуюся из ничего. Нарушается логическая целостность данных. Это так должно быть? Я чего-то не понимаю? Если ответ - "в FB так возможно" - вопросов нет. Если ответ - "это невозможно, ты гонишь и сам дурак" - напишу подробности (будет длинно, не хотел делать огромный первый пост) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 11:31 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Hello, Antamial! You wrote on 24 декабря 2015 г. 11:33:33: Antamial> Нарушается логическая целостность данных. для "логической целкостности данных" используют snapshot, а не read_commited. зы: read_commited "видит" всё, независимо от того когда она стартовала. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 11:34 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Мимопроходящий, заголовок темы. read_commited НЕ видит закомиченные данные. НЕ видит. В этом и вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 11:41 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Hello, Antamial! You wrote on 24 декабря 2015 г. 11:43:10: Antamial> read_commited НЕ видит закомиченные данные. НЕ видит. В этом и вопрос. ты ошибаешься. это ответ. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 11:43 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Мимопроходящий, Тогда объясни, почему так получается: База данных 1, поток в единственном экземпляре Код: java 1. 2. 3. 4. 5. 6. 7.
Код: sql 1. 2. 3. 4. 5. 6. 7.
результат - в таблице "t" появляются записи 1,2,3,4.... и т.д. База данных 2, поток в единственном экземпляре, код точно такой же (connect,exec,commit,disconnect), только вызывается другая процедурка Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
во второй базе несколько раз в сутки получаются пропуски 1,2, 4,5 т.е. когда уже увидели 4, то 3 ещё не было. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:02 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
antamial Код: sql 1.
first зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:08 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Hello, Antamial! You wrote on 24 декабря 2015 г. 12:08:13: Antamial> on external 'база данных 1' побробуй в автономной транзакции. дабы быть уверенным на все 100. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:10 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
wadman, там на самом деле first 50000, чтоб не нагружать оба сервера длинными транзакциями, и не иметь миллионы insert-ов в одной транзакции ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:17 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
wadmanantamial Код: sql 1.
first зачем? В смысле комбинация first и order by мне кажется не стабильной. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:17 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Мимопроходящий, Попробую, но ответ будет не сразу. Если не повезет - то завтра (иногда пару раз в сутки случается, иногда 10 раз) А может всё проще? Может ФБ изначально не гарантирует сериализуемость readcommited транзакций? Ибо: SNAPSHOT TABLE STABILITY isolation level - It is an isolated, serializable snapshot Чётко указано, что сериализуемость есть. А про READ COMMITED ничего такого не сказано. Но и обратного тоже не сказано. Да, по описанию readcommited должна видеть всё.... и я последние 12 лет так и думал, что всё должно быть видно... но может это просто фича? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:24 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Я не вижу, как в данной схеме можно получить пропуски - независимо от уровней изоляции тр-ций. Отсюда вывод - или схема не такая, или пропуски не такие, или я чего-то не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 12:27 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
antamialво второй базе несколько раз в сутки получаются пропуски 1,2, 4,5 т.е. когда уже увидели 4, то 3 ещё не было. я могу предположить только такую ситуацию. 2 транзакции, стартуют параллельно. 1 транзакция начинает вставлять данные 2 транзакция начинает читать данные. 1 транзакция делает коммит 2 транзакция успела прочитать часть данных, которые не были committed, она их не видит. Дальше она читает данные, которые уже committed. Если сейчас перечитать данные еще раз - все данные, вставленные транзакцией 1, будут видны. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:10 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
antamial Может ФБ изначально не гарантирует сериализуемость readcommited транзакций? read committed не сереализуемый по своему названию. поэтому никакой сервер не может гарантировать вымышленную "сериализуемость" read committed. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:12 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
kdv2 транзакция успела прочитать часть данных, которые не были committed, она их не видит. Дальше она читает данные, которые уже committed.Тот, кто вставляет, делает это последовательно. Тот, кто читает - тоже последователен. Поэтому читатель не может прочитать значение 5 и не увидеть значение 4 - 5 коммитилось не раньше, чем 4. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:23 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
hvladТот, кто вставляет, делает это последовательно. Нет, он делает это на первую свободную страницу. Так что спокойно может добавить запись туда, где читатель (идущий натуралом) уже побывал раньше. Для пачки в 50000 записей эта вероятность выше. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:37 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
hvladПоэтому читатель не может прочитать значение 5 и не увидеть значение 4 - 5 коммитилось не раньше, чем 4. здрасьте. данные вставляются в свободные "дыры". если 4 вставилось на одну страницу, а 5 - на другую, вполне может получиться что 4 будет "увидено", а 5 - нет, и наоборот. Здесь, на форуме, был специальный топик на эту тему, прямо тест, именно с такими результатами. И возможно, это был даже Таблоид. Собственно, пример может быть элементарным, типа select count(*) и параллельной вставки записей хотя бы по 1000. В RC чтение не гарантирует, что select count(*) будет возвращать кратный 1000 результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:37 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
kdv2 транзакция успела прочитать часть данных, которые не были committed, она их не видит. Дальше она читает данные, которые уже committed. Ничего не понял. Типа сканируется индекс, в таблице проверяются данные, но они в ещё не закомиченной транзакции - игнорируются. Транзакция комитится, сканирование продолжается, но данные в таблице теперь уже "видимы всем", и они выдаются в итоговый набор. Вы это имели ввиду? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:49 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
antamialВы это имели ввиду? примерно это. чтение данных не происходит волшебным образом, всех и сразу. Без индекса, по индексу, или еще каким-то образом, данные читаются или выбираются последовательно, и если коммит конкурирующей транзакции произошел в какой-то момент, когда ЧАСТЬ вставленных этой транзакцией данных уже прочитана, никто их перечитывать не будет. Грубо говоря, читается так запись (версия) N, транзакция X. X committed? да, можно видеть, нет - нельзя видеть. запись (версия) N+1, транзакция M. M committed? да, можно видеть, нет - нельзя видеть. и т.д. Обращаю внимание еще раз, что вставка записей производится в "свободные дыры" на страницах. То есть, даже "последовательно" вставляемые записи могут попадать на разные страницы, расположенные в самых разных местах таблицы. Например, вставляем в пустую БД и пустую таблицу 1000 записей. Затем удаляем 10 записей. И вставляем еще 1000 записей. Так вот, при второй вставке первые 10 записей могут попасть в ту "дыру", которая появилась из-за удаления 10 записей. Если удаление (и сборка мусора) производится еще и параллельно с другими операциями, то куда что попало, предсказать невозможно. SQL оперирует множествами, а не "последовательностями". ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 13:59 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, kdv, Понял. Всем большое спасибо. ReadCommited работает не так, как я думал. Как обычно проблема в понимании документации и чтении между строк. А ведь если подумать, то всё логично и так и должно быть. Просто обычно на такой эффект не натыкаешься и привыкаешь к "естественному" поведению. Теперь ясно, что ReadCommited для этого алгоритма не годится, нужен shapshot. Спасибо за помощь. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 14:01 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
antamialТеперь ясно, что ReadCommited для этого алгоритма не годится, нужен shapshot. Бесполезно. Как и сказал Влад, при коммите на каждую запись в бд1 поведение фактически не зависит от уровня изоляции. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 14:04 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
antamial, и еще. "Вот так", как я написал - это в Firebird и InterBase, и может быть еще в каких-то других СУБД. В Оракле есть так называемая "стабильность курсора", грубо говоря, это как будто даже если в транзакции RC, отдельный select выполняется как бы во внутренней "микротранзакции" SNAPSHOT. Т.е. в RC два таких селекта могут дать разный результат, но вот этих "конкурентно-committed" данных отдельный select показывать не будет. Вот тут как-то были баталии на тему "неатомарности SQL" 1447129 (и далее) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 14:06 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov(идущий натуралом)Я тебя теперь буду так называть :) См запрос - там where id > ? order by id ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 14:08 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Hello, Dimitry Sibiryakov! You wrote on 24 декабря 2015 г. 14:08:14: Dimitry Sibiryakov> Бесполезно. Как и сказал Влад, при коммите на каждую запись в бд1 поведение фактически не > зависит от уровня изоляции.у него записи вставляются пачками, а не поштучно. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 14:08 |
|
Read_commited. Не видна закомиченная транзакция. Так должно быть?
|
|||
---|---|---|---|
#18+
Я, конечно, не могу вам навязывать решения, но скажу, что проще будет воспользоваться проверенными технологиями репликации, чем изобретать такие вот велосипеды. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2015, 14:09 |
|
|
start [/forum/topic.php?fid=40&msg=39136935&tid=1562430]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 292ms |
total: | 437ms |
0 / 0 |