某些生产设备将测试的数据结果发送到服务器A，该服务器是重要的服务器，它将信息复制到服务器B，后者是处理数据（文件）然后将其插入数据库的服务器。问题所在，数据库在另一台服务器（服务器C）中。
案例：
现在，我面临的问题是服务器B中的数据被卡在那里，队列开始形成并且一直在增长。显然，插入会很慢，给您一个想法，在服务器A中（它将数据插入服务器A中的DB中），插入单个数据集的时间从133毫秒变为（很少）2300毫秒；而在服务器B中，它从171变为11900（最有可能超过2秒）。
这里有很多因素，服务器A和服务器B之间的容量也不同，服务器A具有96 GB的内存，服务器B具有32 GB的内存；服务器A 24个CPU，原装Intel，CPU MHz 1596; 和服务器B 16个CPU，AutenticAMD，CPU MHz3200。我认为这可能是服务器B的容量问题。但我想排除数据库中的问题；这就是为什么我想确定数据库中数据的插入是否真的很慢，因为当我的应用程序连接到数据库以读取数据时，它确实还可以，但并不慢。另外，服务器B是唯一将数据插入服务器C中的DB的服务器。我无法访问处理服务器B中数据的应用程序的内部，不幸的是，几乎没有文档可供阅读。
我尝试从我的个人计算机手动插入几行（SQL Developer），但效果很好，尽管我知道插入数百行和插入行并不相同。
解决方法
活动会话历史记录（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的组合是插入语句的实例。您会看到我们并没有全部捕获200,000千个字节，因为ASH仅每秒对活动会话进行一次采样。但是您可以非常清楚地将“问题”插入（sql_exec_id = 17077819）。每行=一秒，因此我们可以看到它被卡在TX锁上约18秒钟。
因此，如果您有任何单个插入花费的时间超过1秒，则它们应该在ASH数据中脱颖而出。
