Неверный подсчет (*) записей в таблице

Question

Я пытаюсь взять счет стола в оракуле. Когда я бегу очень простой подсчет, таких как:

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 разработчик), и он возвращает еще более высокий счет [146436917] (я знаю, что это не на 100% точно, но это должно быть разумно для этого упражнения). Я не вижу, как условие фильтра может возвращать больше строк подсчета, чем сама таблица. Вот подробности:

1. Запрос побежал в той же базе данных в течение 10 секунд каждой других
2. В таблице вставки ~ 60K строк каждые 10 минут через запланированного задания
3. Запланированное задание выполняет оператор процедура, которая использует слияния (ниже)
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; 
   

Я пробовал прибегая к помощи пару раз, но большинство ошибки в сообщениях счетчика касаются объединений и условий фильтрации. Это очень странно для меня.

РЕДАКТИРОВАТЬ:

Объясните план первого запроса:

ВЫБРАТЬ ЗАЯВЛЕНИЕ -> СНП (АГРЕГАТ) -> ИНДЕКС (FAST FULL SCAN на объекте ПК)

Кардинальность: 1 -> 1 - > 146436917 Стоимость: 85031

Объяснить план второго запроса:

SELECT -> СНП (складочном) -> INDEX (FAST FULL S CAN НА РАЗЛИЧНЫХ ОБЪЕКТОВ INDEX КРОМЕ PK (индекс предикат фильтра)) -> ФИЛЬТР PREDICATES -> UPDT_VAL_EFF_DTTM

Cardinality: 1 -> 1 -> 131379677 Стоимость: 105341

Answer 1

Когда я видел это происходит (просто один или два раза), потому что индекс был поврежден. Мы либо перестроили, либо сбросили, и воссоздали индекс, и проблема исчезла.

Это всего лишь анекдот и не объясняет, что произошло или почему. Но прежде чем тратить огромное количество времени на поддержку Oracle, вы сначала захотите попробовать эти «плохие» решения. Проведите 5 минут, чтобы восстановить его, и вы можете избежать дней расследования позже. Если проблема никогда не повторится, первопричина не имеет большого значения.