love wife love life —Roger的Oracle/MySQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

flashback_transaction_query 查询慢的问题

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: flashback_transaction_query 查询慢的问题

今天有网友在sina weibo上问我这个问题:
我数据库由于做过大量dml语句,所以flashback_transaction_query 这个视图很大,今天想根据时间查询一个表的记录,
发现加条件之后查询特别慢,不是一般的慢,怎么办啊@君三思 @oracledatabase12c

晚上回到家,花了点时间研究了一下,这里分享出来,同时也算是回复该网友。
首先,我们来看下该试图到底是什么 ?

该x$表的表结构如下:

既然是关于闪回方面的技术,那么显然也就是跟undo有关系了,我们来检查下undo信息:

通过dump 回滚段头我们可以统计出来,该undo datafile目前涉及到的事务一共有12888个,涉及到的记录数肯定也就是
我们count整个表的记录数了。

可以看到,该x$试图内容较大,在新版本中中这个问题仍然存在,如果你的数据库比较繁忙,那么这个试图的记录数可能是几十万甚至上百万,
那样的话,你查询就会感觉非常的慢。但是oracle这里并不允许去创建相关的index,oracle本身也没有这样设计,不知道为什么。

通过前面的测试,我们可以看到调整undo_retentions可以适当的降低记录数,不过影响不大。既然我们知道该试图的记录都来源于undo datafile。
那么我们可以通过切换undo tablespace 来降低记录数。不过随着时间的推移,这个x$的记录仍然会越来越大,这个无法避免。如下:

我们可以看到,我们使用闪回查询常用的几个字段的选择性可以说都很低,这或许就是为什么oracle不给相应的字段添加index的原因之一。
另外一种原因我猜测可能是:通常来讲,一个事务可能涉及到很多记录数,这样就比如导致xid的选择性很低,那么再去创建index 意义
也就不大了。其实我在想,如果有index的话,或许会走index fast full scan,起码也要比全表扫描要快的多。

那么是不是就没有办法了呢? 突然我想到可以利用物化视图俩满足该网友的需求,如下:

显然这样要快的多了。基本上解决了该网友的问题。 不过这里还是有个小问题,就是物化视图同步的问题,因为这里基表实际上
是一个试图,所以也就没法取创建物化视图日志,对x$又不允许创建物化视图。不过,大不了我们在使用闪回查询之前,手工刷新同步
一下该物化试图即可,如下:
SQL> exec dbms_mview.refresh(‘FLASH_QUERY_TEST’,’Complete’);

PL/SQL procedure successfully completed.

Elapsed: 00:00:16.62

4 Responses to “flashback_transaction_query 查询慢的问题”

  1. Dong_2 Says:

    roger 又有大作了啊

  2. Wisdomone1 Says:
  3. 可但是 Says:

    complete刷新物化视图,不是和执行一次查询效率差不多,或者更慢了么–还要往表里写数据。

  4. block itl flashback tractions query | love wife & love life —Roger 提供oracle技术支持服务 Says:

    […] 前几天某大师提醒我说了,我以前一篇文档flashback_transaction_query 查询慢的问题 有点问题。 现在回想一下,确实不太对,虽然以前的方法也是一种处理方法然而有点偏离方向了。 首先我们来看一下试图的定义: […]

Leave a Reply

You must be logged in to post a comment.