GVF112GVFPS: Следует отметить, что в более новой версии IDS 11.10 - от Fuzzy Checkpoint
отказались !!!

С уважением,
Вадим.

Я даже догадываюсь почему.
При введение нового уровня изоляции COMMITTED READ LAST COMMITTED
информация о закомиченых транзакциях уже где то надежно хранится.

Поэтому в блокировке контрольной точкой сессий для получения согласованной БД
необходимости нет.

Вопросы, на которые( наверное не только мне) интересно было бы получить ответы:

1.Подскажите ссылки на описание работы механизма контрольной точки в
chetah.

2. Где лежит ( откуда берется сессиями ) информация о LAST COMMITTED значениях
для уровня изоляции COMMITTED READ LAST COMMITTED.

з.ы. Если я гдето заблуждаюсь , поправьте.

Журавлев Денис

Спасибо за ссылку.

vasilis onstat- Журавлев Денис
Спасибо за ссылку.
Да, тоже спасибо Денису за ссылку на переводную статью, а то английский вариант у меня уже давно лежал без прочтения :)
Вот только ты вряд ли получишь ответы на свои вопросы - статья довольно поверхностная и никаких внутренних механизмов не затрагивает, а описание "неблокирующей КТ" ничем, по сути, не отличается от описания КТ, которое существовало ранее :)



Отличается, привязкой к временным интервалам.

автор
Рис. 1 иллюстрирует принципы работы неблокирующей рабочей точки в IDS. Для наглядности на рисунке изображен некий «поток записи» (log stream), который служит в качестве временной шкалы. На Рис. 2 показано, что каждая транзакция внедряет в этот поток определенные логические записи.Поток никогда не возвращается обратно во времени, он всегда только возрастает.

На рис. 1 текущим интервалом является интервал контрольной точки 9. В некоторый момент времени осуществляется вызов контрольной точки и начинается интервал 10. Начало интервала 10 накладывается на завершающую фазу интервала 9, в течение которой интервал 9 обрабатывает контрольную точку. После того как все страницы, подвергнутые модификации до начала интервала 10, будут сброшены на диск, интервал 9 завершится. После завершения интервала 9 процедура быстрого восстановления может запускать восстановление с его начала.


Интервалы накладываются друг на друга.
Помоему красивое решение.
Все, что раньше оставалось в Buffers not flushed до следующей КТ с неизвесными последствиями,
сейчас жестко контролируется в рамках одной КТ .


Вот только как между собой делят пользовательские нити и нить ckpt ( или как она там называется)
страницы буферного пула во время КТ.
Или в статье лукавят и блокирование на протяжении зеленой линии всетаки есть( как минимум на изменение), или страницы сбрасываются на диск не оптом, а в розницу. Что удлинняет КТ ( ухудшает дисковую производительность) за счет увеличения количества дисковых операций для страниц расположенных последовательно, если конкуренция произошла на какой либо средней странице.


Это так, просто предположения, основанные на логических рассуждениях,
Доказательств этому у меня нет, и моя логика может быть ошибочной.

onstat-

Вот только как между собой делят пользовательские нити и нить ckpt ( или как она там называется)
страницы буферного пула во время КТ.
Или в статье лукавят и блокирование на протяжении зеленой линии всетаки есть( как минимум на изменение), или страницы сбрасываются на диск не оптом, а в розницу. Что удлинняет КТ ( ухудшает дисковую производительность) за счет увеличения количества дисковых операций для страниц расположенных последовательно, если конкуренция произошла на какой либо средней странице.



Как вариант в буферном пуле создается копия(версия) страниц,
в этом случае и до чистой версионности( как в postgeSQL) недалеко.

Хоть алгоритм КТ практически не поменялся, но наверное не зря интуитивно возник вопрос где хранятся LAST COMMITTED значениях для уровня изоляции COMMITTED READ LAST COMMITTED.

Продолжая логически рассуждать варианта может быть 2.
1. Хранится в TEMP.
2. Имеется хитрый внутренний индекс на логическом журнале.

Я склоняюсь ко 2 варианту ( и он будет заложен в OpenDSA).