转载

巧用闪回查询来分析事务延迟的问题

   前段时间有个开发的同事向我咨询一个问题，
    开发同事：Oracle会存在一个用户插入数据，已经提交了；但是另外一个用户还查询不到吗？都是同一张表
    jeanron: 不会的。
    开发同事: 我们现在一个用户写入，程序日志是说已经写入；可是读取的用户还读取不到，在线延迟5分钟可能的问题在哪儿？或者你帮忙监控一下？
    jeanron:   是Oracle吗，MySQL还可能有这种情况
    开发同事: Oracle,MySQL是什么情况下会这样？
    jeanron: MySQL，主库写，从库查，可能会有这种延迟

   后续和他们确认了下，是Oracle环境，而且都是在主库端查询，而且是同一个表。这种情况听起来着实有点意思，当然我们知道多版本查询是Oracle的一个亮点，也是作为MVCC的一个必备特征。如果这个都不能保证，数据就会乱套了。
    但是目前数据库中的数据根据开发同学的反馈确实有这种情况，这一点就让很有意思了。当然他们说感觉延迟，我希望能够让他们也帮忙具体定位一下，比如提供一条数据记录，他们从前端的日志中发现有延迟的这种情况，我在数据库端就容易来定位问题了。
没过多久，开发同学就提供了一个语句，他们使用rowid定位到了那条记录，这个对我来说就方便多了。
语句类似下面的样子：
select count(*)from heart   where rowid='AAASdNAAHAAMgirABN'
   他们反馈根据数据的情况，说这条记录是在2016-07-14 16:40:00 这个时间点插入的，但是有很大的延迟，一直查不到数据。
这个时候使用Oracle的闪回查询就是一个很好的实践。首先确保根据rowid能够定位到数据。
select count(*)from heart   where rowid='AAASdNAAHAAMgirABN'
1
    然后延迟5秒钟看看是否能够看到数据，结果奇怪的是没有找到匹配的数据
select count(*)from heart as of timestamp to_timestamp('2016-07-14 16:40:05','yyyy-mm-dd hh24:mi:ss') where rowid='AAASdNAAHAAMgirABN'
0
    然后我逐步放大实践延迟，一直放大到延迟6分钟，还是没有找到匹配的数据。
select count(*)from heart as of timestamp to_timestamp('2016-07-14 16:46:00','yyyy-mm-dd hh24:mi:ss') where rowid='AAASdNAAHAAMgirABN'
0
    继续放大延迟间隔，终于看到了匹配的记录。
select count(*)from heart as of timestamp to_timestamp('2016-07-14 16:47:00','yyyy-mm-dd hh24:mi:ss') where rowid='AAASdNAAHAAMgirABN'
1
    从这个简单的测试来看，这个数据是在2016-07-14 16:40:00插入的，可以从表里的数据看出，表里有一个字段会做标示，但是数据在一个事务内一直未提交，所以其他的用户查询的时候会始终查到的是未提交状态的数据，而数据是在16:46:00~16:47:00这个时间段提交的，而具体的时间戳已经不重要了，因为已经说明了问题。
    可以基本断定是在应用端存在一个大事务，迟迟未提交，导致数据的状态一直没有得到更新，确认了这点，应用端就很好去分析和处理了。

正文到此结束