如何检测oracle db中的插入事务是否真的很慢？

在工作中，我有一个Oracle DB (11g)，我想在其中检测插入数据时性能是否较慢。情况如下:

一些生产设备将测试的数据结果发送到服务器A，该服务器是一个重要的服务器，它将信息复制到服务器B，服务器B是处理数据 (文件) 然后将其插入数据库的问题，数据库在另一个服务器 (服务器C)。

现在，我面临的问题是服务器B中的数据卡在那里，队列开始形成，并且不断增长。显然，插入是要慢，给你一个想法，在服务器A (它在数据库中插入数据也在服务器a中) 插入一组数据的时间从133毫秒到 (很少) 2300毫秒; 而在服务器B中，它从171到11900 (最有可能超过2秒)。

这里有很多因素，服务器a和服务器B之间的容量也不同，服务器A有96 GB的内存，服务器B有32 GB; 服务器A 24 CPU，GenuineIntel，CPU MHz 1596; 服务器B 16 CPU，AutenticAMD，CPU MHz 3200。我认为这可能是服务器B容量的问题; 但我想排除数据库中的问题; 这就是为什么我想知道在DB中插入数据是否真的很慢，因为当我的应用程序连接到它读取数据时，真的很好，不慢。另外，服务器B是唯一将数据插入服务器C中的DB的服务器。我无法访问在服务器B中处理数据的应用程序的内部，不幸的是，几乎没有文档可以阅读。
我尝试从我的个人计算机手动插入几行 (SQL Developer)，它工作得很好，尽管我知道插入数百行并插入一行并不相同。
现在，我不是DBA，但我想找到一种方法来监视插入物，并找出它们需要多长时间才能完成。有谁知道我如何实现这样的目标？


希望您能帮助我，谢谢!

活动会话历史记录 (ASH) 应该足以捕捉这样的等待。这是一个你可以期待看到的例子

--
-- Session 1
--
SQL> create table t ( x int primary key );

Table created.

SQL> insert into t values (100000 );

1 row created.
复制

上面的未提交行很重要，因为我将使用它来减慢插入测试的速度，以模拟您的问题。所以这里是我沉重的插入代码:

SQL> begin
  2  for i in 1 .. 200000 loop
  3    insert into t values (i);
  4    commit;
  5  end loop;
  6  end;
  7  /
复制

现在，它将非常快地通过这些200,000插入 * 直到 * 它击中i = 100,000，因为它将被未提交的插入阻止。几秒钟后，我回到第一个会话并进行了提交，因此我的200,000插入循环完成。

让我们看一下该时间段的v $ active_session_history:

SQL> select sample_time, sql_id, sql_exec_id, time_waited, event
  2  from v$active_session_history
  3  where sample_time > timestamp '2018-06-19 15:08:21'
  4  and user_id = 107
  5  order by sample_time;

SAMPLE_TIME                    SQL_ID        SQL_EXEC_ID TIME_WAITED EVENT
------------------------------ ------------- ----------- ----------- -------------------------------
19-JUN-18 03.08.22.347 PM      gqbqxgth0a4nt    16777216           0
19-JUN-18 03.08.23.347 PM      gqbqxgth0a4nt    16777216           0
19-JUN-18 03.08.24.348 PM      2n9c7yuww4dx4    17032961           0
19-JUN-18 03.08.25.348 PM      2n9c7yuww4dx4    17054907           0
19-JUN-18 03.08.26.348 PM      gqbqxgth0a4nt    16777216           0
19-JUN-18 03.08.27.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.28.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.29.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.30.349 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.31.349 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.32.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.33.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.34.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.35.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.36.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.37.347 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.38.347 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.39.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.40.347 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.41.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.42.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.43.348 PM      2n9c7yuww4dx4    17077819           0 enq: TX - row lock contention
19-JUN-18 03.08.44.349 PM      2n9c7yuww4dx4    17077819    18711197 enq: TX - row lock contention
19-JUN-18 03.08.45.350 PM      2n9c7yuww4dx4    17083622           0
19-JUN-18 03.08.46.350 PM      2n9c7yuww4dx4    17106949           0
19-JUN-18 03.08.47.350 PM      gqbqxgth0a4nt    16777216           0
19-JUN-18 03.08.48.351 PM      gqbqxgth0a4nt    16777216           0
19-JUN-18 03.08.49.351 PM      gqbqxgth0a4nt    16777216           0
复制

SQL_ID/SQL_EXEC_ID的组合是一个insert语句的实例。您可以看到我们没有捕获 * 全部 * 200,000千，因为ASH每秒仅采样一次活动会话。但是你可以 * 问题 * 插入非常清楚 (sql_exec_id = 17077819)。每行 = 一秒钟，因此我们可以看到它被卡在TX锁上约18秒。

因此，如果您有任何单个插入需要超过1秒的时间，它们应该在您的ASH数据中脱颖而出。