Oracle-用于大量插入的策略，但仅在OLTP环境中使用最后一个插入

Question

我每30秒将10000行插入Oracle OLTP表中。每半小时约240Mb的数据。所有10000行都具有相同的时间戳，我将其设置为30秒边界。我也有3个索引，其中之一是空间点几何索引（纬度和经度）。时间戳也被索引。

[在测试过程中，两个CPU的利用率为50％，输入/输出的逻辑为80％，而插入的时间在半小时后增加了一倍。

我还从表中进行选择，以通过使用子查询来查找最大时间戳来获取最后插入的时间戳10000行，这是由于这是两个不同的过程（用于插入的Python和用于选择的Google映射）。我尝试采用一种策略，尝试使用当前时间来检索最后10000行，但是即使去了最后10000行，也无法使它正常工作。它通常不返回任何行。

我的问题是，如何才能有效地检索最后插入的10000行，并且在所有10000行具有相同时间戳值的情况下，哪种类型的索引和/或表最合适。保持插入时间短并且持续时间不加倍将更为重要，因此不确定在仅保留当前表的最后一行的同时是否还需要历史表。但可以肯定，这将使IO数量增加一倍，这似乎是当前最大的问题。任何建议将不胜感激。

Answer 1

数据库可以“遍历”索引的“右侧”以非常快速地获取最大值。这是一个例子

SQL> create table t ( ts date not null, x int, y int, z int );

Table created.

SQL>
SQL> begin
  2   for i in 1 .. 100
  3   loop
  4      insert into t
  5      select sysdate, rownum, rownum, rownum
  6      from dual
  7      connect by level <= 10000;
  8      commit;
  9   end loop;
 10  end;
 11  /

PL/SQL procedure successfully completed.

SQL>
SQL> create index ix on t (ts );

Index created.

SQL>
SQL> set autotrace on
SQL> select max(ts) from t;

MAX(TS)
---------
12-JUN-20

1 row selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1223533863

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |     1 |     9 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE            |      |     1 |     9 |            |          |
|   2 |   INDEX FULL SCAN (MIN/MAX)| IX   |     1 |     9 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
          6  recursive calls
          0  db block gets
         92  consistent gets
          8  physical reads
          0  redo size
        554  bytes sent via SQL*Net to client
        383  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

因此，92个一致的获取非常简单……但是，您可以通过跳读具有降序索引的最后一个叶子块来提高性能，例如

SQL> select *
  2  from (
  3  select ts from t order by ts desc
  4  )
  5  where rownum = 1;

TS
---------
12-JUN-20

1 row selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3852867534

-------------------------------------------------------------------------------------
| Id  | Operation                    | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |      |     1 |     9 |     3   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY               |      |       |       |            |          |
|   2 |   VIEW                       |      |  1184K|    10M|     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN DESCENDING| IX   |  1184K|    10M|     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(ROWNUM=1)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
          9  recursive calls
          5  db block gets
          9  consistent gets
          0  physical reads
       1024  redo size
        549  bytes sent via SQL*Net to client
        430  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

因此您当前的索引很好。只要获得上述最高的时间戳，就可以了