一致性读

[a-Loser]

考虑如下场景：
xact A 在 9:00 启动一个scan， 并在9:10结束。
其中的一致性读是通过对所有的数据块进行undo操作，将其还原到9:00时的状态进行的。
那么问题是，
假设有一个数据块x，在xact A还未扫描到x时，x由于insert大量数据而产生split，分裂为x,y,z三个数据块。那么此时当A扫描到x时如何使用undo操作还原到9:00时的状态？

或者若x由于大量数据delete并commit导致consolidate，此时如何还原已经被物理删除的数据？（数据块x已经被删除了）

[Tiger_Zhao]

数据库中重要的是记录啊，只要从x、y、z中选取插入前的记录就保持一致性了。
在进行一致性读的时候应该是不会彻底清除数据的。

[a-Loser]

引用 1 楼 Tiger_Zhao 的回复:

数据库中重要的是记录啊，只要从x、y、z中选取插入前的记录就保持一致性了。 在进行一致性读的时候应该是不会彻底清除数据的。

照你的意思说，当split的时候，所有从x移动到y中的原记录都会在undo中留下一笔记录？ 比如x中的两条记录a，b移动到y之后，会在x的undo中记录下slot a slot b move ?

[Tiger_Zhao]

完全没必要留记录啊，只要能区分出记录是9:00之前存在的还是之后新增的不就可以了。
想那么多干吗，既然数据库保证读一致的，相信它就行。

[美到心痛]

1.你所谓的x由于insert大量数据而产生split，你大概的意思在oracle是行迁移的概念，但是insert操作是不会产生这种 行迁移的，update操作有可能。当然，如果有记录进入x,x的scn会变的比查询事务开始的scn要大，这时oracle也会去undo 找前映象。 2.若x由于大量数据delete并commit，在删除时，会把x中的记录的前映象放在undo中，就算commit了，也不是立即清除， 这是由undo的空间大小以及undo_retention控制的，所以此时还能读到删除之前的记录。当然如果这个前映象被覆盖，就会 发生ora-01555错误，查询失败返回。 可以百度一下oracle的一致性读看一下，是容易混淆的概念，呵

[a-Loser]

引用 4 楼 sjcss 的回复:

1.你所谓的x由于insert大量数据而产生split，你大概的意思在oracle是行迁移的概念，但是insert操作是不会产生这种 行迁移的，update操作有可能。当然，如果有记录进入x,x的scn会变的比查询事务开始的scn要大，这时oracle也会去undo 找前映象。 2.若x由于大量数据delete并commit，在删除时，会把x中的记录的前映象放在undo中，就算commit了，也不是立即清除， 这是由undo的空间大小以及undo_retention控制的，所以此时还能读到删除之前的记录。当然如果这个前映象被覆盖，就会 发生ora-01555错误，查询失败返回。 可以百度一下oracle的一致性读看一下，是容易混淆的概念，呵

谢谢你的回答。 update行迁移可以理解。 但是insert不会产生行迁移吗？可以解释一下，假设x中存满了1到10的数据，这个时候再插入数据5，导致split。那x和y的数据分布是怎样的呢？假设这里讨论的都是cluster index。 第二个问题，undo的记录是以“数据块”为单位的吧？ 我的意思是，由于x中数据全部commited delete，导致x数据块从index tree上删除（或者x被重用），此时所有与x有关的之前undo记录怎么办呢。 是不是说，即使全部commited delete ， x数据块也不被回收，而是延迟删除/重用？

[Tiger_Zhao]

块X不可能独立存在，它的前一个叶子块W或上个枝干块U有指向它的链接啊。
如果X从树中删除，那么W或U必须被修改，遍历的到W或U时候发现SCN比9:00要新，首先要对W或U做undo啊。
根据undo之后的链接就可以遍历到X，继续检查X的SCN决定是否要做undo。
依次类推。

[a-Loser]

引用 6 楼 Tiger_Zhao 的回复:

块X不可能独立存在，它的前一个叶子块W或上个枝干块U有指向它的链接啊。 如果X从树中删除，那么W或U必须被修改，遍历的到W或U时候发现SCN比9:00要新，首先要对W或U做undo啊。 根据undo之后的链接就可以遍历到X，继续检查X的SCN决定是否要做undo。 依次类推。

意思就是说，任何对数据块的操作都会导致一个undo（而不是仅限于对data record的修改）？ 那如果链接失效的情况，是不是就找不回原来的undo记录了？（比如x被重用）

[Tiger_Zhao]

更正一下我#3的说法。
不是不记录更新前的a、b记录，应该是把整个x块记录下来了，所以扫描undo了x块后就和y、z无关了。