表记录的计数(*)不正确

时间:2017-01-14 00:01:45

标签: oracle merge procedure

我想在oracle中计算一个表。当我运行一个非常简单的计数,例如:

SELECT COUNT(*) FROM EDW.SCADA_VALUE_HIST; --Returns [114315627]

它返回一个看似正确的结果(在查询外的括号中)。现在,当我将过滤条件应用于同一个表时,它返回的行多于表的count(*):

SELECT COUNT(*) FROM EDW.SCADA_VALUE_HIST 
WHERE UPDT_VAL_EFF_DTTM <= (SYSDATE-5); --Returns [131416178]

此外,我继续检查表的统计数据(sql developer中的详细信息)并返回更高的计数[146436917](我知道这不是100%准确但它应该是合理的这个练习)。我没有看到过滤条件如何返回比表本身更多的计数行。以下是详细信息:

  1. 查询在10秒内在同一个数据库中运行 其他
  2. 该表每隔10分钟插入~60k行 预定的工作
  3. 预定作业执行使用a的过程 合并(下)
  4. UPDT_VAL_EFF_DTTM是日期字段,此列不可为空
  5. 该表包含5个总索引(复合主键(4个字段)和唯一,后跟4个非唯一索引
  6. 它在Oracle 11gr2上运行
  7. 数据库正在运行DataGuard环境,其中包含3个物理备用数据库和1个主要备用数据库

    create or replace PROCEDURE UPDATE_VALUE_HIST AS
        v_date VARCHAR2(16);
        g_counter NUMBER(10,0) := 0;
        g_insertspeed NUMBER (10,0) := 1000;
        g_inserttime NUMBER (10,0) := 20; 
    BEGIN
      BEGIN
    
        MERGE INTO EDW.SCADA_VALUE_HIST SVH  
        USING 
       (SELECT
           SV.COL1,SV.COL2,SD.COL3,SD.COL4,
           SVD.COL5,SVD.COL6,SVD.COL7,SV.COL8,
           SVT.COL9 AS VALUE_TYPE_NAME,SV.COL10,SD.COL11,
           SYSDATE as UPDT_VAL_EFF_DTTM,'U',SV.COL13,SV.COL14
        FROM SCHEMA.T1 SV,
             SCHEMA.T2 SVD,
             SCHEMA.T3 SVT,
             SCHEMA.T4 SD
        WHERE SV.FIELD1= SVD.FIELD1
        AND SVD.FIELD2= SVT.FIELD2
        AND SD.FIELD3= SVD.FIELD3
        AND SV.FIELD4 IS NOT NULL) B
       ON (
        SVH.FIELD1= B.FIELD1
        AND SVH.FIELD2= B.FIELD2
        AND SVH.FIELD3= B.FIELD3
        AND SVH.FIELD4 = B.FIELD4 
        )
      WHEN NOT MATCHED
        THEN
           INSERT (COL1, COL2, COL3, COL4, COL5, COL6, COL7, COL8, 
             COL9, COL10, COL11, SYSDATE, 'U', COL13, COL14);
    
      COMMIT;  
    
      END;                
    END;
    
  8. 我已经尝试了几次谷歌搜索,但计数帖子中的大部分错误都涉及联接和过滤条件。这对我来说非常奇怪。

    编辑:

    解释第一个查询的计划:

    SELECT STATEMENT - &gt; SORT(AGGREGATE) - &gt; INDEX(对象PK快速全扫描)

    基数:1 - &gt; 1 - &gt; 146436917 费用:85031

    解释第二个查询的计划:

    SELECT - &gt; SORT(AGGREGATE) - &gt; INDEX(对象的快速全扫描与PK的对象差异指数(过滤谓词索引)) - &gt;过滤器预测 - &gt; UPDT_VAL_EFF_DTTM

    基数:1 - &gt; 1 - &gt; 131379677 费用:105341

1 个答案:

答案 0 :(得分:3)

当我看到这种情况发生时(仅一次或两次),这是因为索引已损坏。我们重建或删除并重新创建索引,问题就消失了。

这只是一个轶事,并没有解释发生了什么或为什么。但是在你浪费大量时间处理Oracle支持之前,你会想要尝试这些&#34;糟糕的&#34;解决方案首先现在花5分钟重建它,你可能会避免以后的调查。如果问题再也不会发生,根本原因并不重要。

相关问题