softwarer serg99Сериализуемость как таковая не требует хранить все версии на момент начала транзакции. ..... Если запись кем то изменена до того как отчет первый раз ее считал, то никаких проблем с сериализуемостью нет.
Как минимум, проблема будет в увеличении количества транзакций, завершившихся с "cannot serialize access".
С ходу не видно за счет чего будет увеличение количества такого рода транзакций. И кстати само наличие таких транзакций во многом связано с принятой реализацией механизмов изоляции. То есть сервер, обнаружив конфликт сериализуемости, вместо того что бы самому попытаться разрулить этот конфликт, просто отбивает транзакцию.
softwarer serg99Интересно есть ли случаи когда реально нужен snap shot?
Хм. Собственно, snapshot - единственный имхо вариант получить реальную картину, а не некое условное к ней приближение.
Допустим, у нас есть двадцать работников, шлепающих детали и записывающие каждую в БД. В этом случае без снапшота варианты кода
1.
2.
3.
set transaction serializable ;
select count(*) from details group by employee_id ;
и
1.
2.
3.
4.
5.
set transaction serializable ;
select count(*) from details where employee_id = 1 ;
select count(*) from details where employee_id = 2 ;
....
выдадут разные результаты, что не есть хорошо. Да, разумеется, с этим можно бороться. Как можно бороться с фантомами, и со всем остальным. Но имхо СУБД придумали как раз для уменьшения необходимости в борьбе.
Если нужны отчеты по времязависимым данным, то к этим данным ставится обычно метка времени и такие отчеты работают одинаково, когда бы их не запускали. Если же нужно какое то состояние на текущий момент, то здесь не имеет значения проскочит какая нибудь транзакция вперед или отработает после. То есть при одинаковой последовательности транзакций результаты приведенных Вами запросов будут одинаковы. Другими словами если какая то другая транзакция началась во время выполнения
select count(*) from details where employee_id = 2 ;
изменила данные для id=10 и закоммитилась до того как запрос стал выполнять
select count(*) from details where employee_id = 10 ;
то эта другая транзакция может рассматриваться как произошедшая до начала нашей транзакции. То есть выполняется требование сериализованности, состоящее в том, что результат параллельного выполнения транзакций равен результату их последовательного выполнения (неважно в каком порядке). Сериализованность выполняется, никаких фантомов нет, и для этого не требуется snap shot.
softwarer Существуют и другие решения, но они сложнее в реализации.
В такой ситуации - сомневаюсь. Можно ссылку?
Затрудняюсь дать ссылку. Это скорее наши внутренние наработки.
