Oracle 11.2在随机时间对简单的SQL有2秒的延迟

简单的表连接通常在0.0XX秒内完成，有时在2.0XX秒内完成（根据PL / sql Developer sql执行）。 它从sql Plus运行时发生。

如果我运行sql 10次，8次运行正常，2次在2+秒。

这是在Centos 7上安装Oracle 11.2.0.4 for Linux x86_64。我已经安装了Oracle推荐的补丁：

补丁19769489 – 数据库补丁集更新11.2.0.4.5（包括cpuJan2015）

补丁19877440 – Oracle JavaVM组件11.2.0.4.2数据库PSU（Jan2015）

修补后没有变化。

Linuxnetworking应用的高延迟

Ping间隔为什么会影响RTT值？

Windows Workflow Foundation 4（WF4）延迟

Linux组播中排队/缓冲延迟的位置在哪里？

Windows cmd.exe中的pipe道在进程完成之前不会转发标准输出？

2表有：LNK_PACK_REP：13行包：6行

在sql Plus中，我启用了所有的统计信息，并多次运行sql。 只有时间从0.1变到2.1。 如果我将0.1秒运行与2.1秒运行进行比较，则没有其他统计信息发生变化。 该服务器有16 Gb RAM和8个cpu核心。 服务器负载在0.1以下（暂时没有用户使用服务器）。

输出：

sql>从LNK_PACK_REP中selectPACKAGE_ID，ID，package_name LNKPR INNER JOIN PACKAGES P ON LNKPR.PACKAGE_ID = P.ID;

PACKAGE_ID ID PACKAGE_NAME

3 3 RAPOARTE 3 3 RAPOARTE 121 121 VANZARI 121 121 VANZARI 121 121 VANZARI 2 2 PACHETE 2 2 PACHETE 1 1 DEPARTAMENTE 1 1 DEPARTAMENTE 81 81 ROLURI 81 81 ROLURI

PACKAGE_ID ID PACKAGE_NAME

101 101 UTILIZATORI 101 101 UTILIZATORI

select了13行。

已逝：00：00：02.01

执行计划

计划哈希值：2671988802

-------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%cpu)| Time | TQ |IN-OUT| PQ distrib | -------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 13 | 351 | 3 (0)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | 13 | 351 | 3 (0)| 00:00:01 | Q1,02 | P->S | QC (RAND) | |* 3 | HASH JOIN | | 13 | 351 | 3 (0)| 00:00:01 | Q1,02 | Pcwp | | | 4 | PX RECEIVE | | 6 | 84 | 2 (0)| 00:00:01 | Q1,02 | Pcwp | | | 5 | PX SEND HASH | :TQ10001 | 6 | 84 | 2 (0)| 00:00:01 | Q1,01 | P->P | HASH | | 6 | PX BLOCK IteraTOR | | 6 | 84 | 2 (0)| 00:00:01 | Q1,01 | PCWC | | | 7 | TABLE ACCESS FULL| PACKAGES | 6 | 84 | 2 (0)| 00:00:01 | Q1,01 | Pcwp | | | 8 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 9 | PX RECEIVE | | 13 | 169 | 1 (0)| 00:00:01 | Q1,02 | Pcwp | | | 10 | PX SEND HASH | :TQ10000 | 13 | 169 | 1 (0)| 00:00:01 | | S->P | HASH | | 11 | INDEX FULL SCAN | UNQ_PACK_REP | 13 | 169 | 1 (0)| 00:00:01 | | | | --------------------------------------------------------------------------------------------------------------------------

谓词信息（由操作ID标识）：

3 – 访问（“LNKPR”。“PACKAGE_ID”=“P”。“ID”）

注意

用于此语句的dynamic采样（级别= 2）

统计

24 recursive calls 0 db block gets 10 consistent gets 0 physical reads 0 redo size 923 bytes sent via sql*Net to client 524 bytes received via sql*Net from client 2 sql*Net roundtrips to/from client 4 sorts (memory) 0 sorts (disk) 13 rows processed

表1结构：

-- Create table create table PACKAGES ( id NUMBER(3) not null,package_name VARCHAR2(150),position NUMBER(3),activ NUMBER(1) ) tablespace UM pctfree 10 initrans 1 maxtrans 255 storage ( initial 64K next 1M minextents 1 maxextents unlimited ); -- Create/Recreate primary,unique and foreign key constraints alter table PACKAGES add constraint PACKAGES_ID primary key (ID) using index tablespace UM pctfree 10 initrans 2 maxtrans 255 storage ( initial 64K next 1M minextents 1 maxextents unlimited ); -- Create/Recreate indexes create index PACKAGES_ACTIV on PACKAGES (ID,ACTIV) tablespace UM pctfree 10 initrans 2 maxtrans 255 storage ( initial 64K next 1M minextents 1 maxextents unlimited );

表2结构：

-- Create table create table LNK_PACK_REP ( package_id NUMBER(3) not null,report_id NUMBER(3) not null ) tablespace UM pctfree 10 initrans 1 maxtrans 255 storage ( initial 64K next 1M minextents 1 maxextents unlimited ); -- Create/Recreate primary,unique and foreign key constraints alter table LNK_PACK_REP add constraint UNQ_PACK_REP primary key (PACKAGE_ID,REPORT_ID) using index tablespace UM pctfree 10 initrans 2 maxtrans 255 storage ( initial 64K next 1M minextents 1 maxextents unlimited ); -- Create/Recreate indexes create index LNK_PACK_REP_REPORT_ID on LNK_PACK_REP (REPORT_ID) tablespace UM pctfree 10 initrans 2 maxtrans 255 storage ( initial 64K next 1M minextents 1 maxextents unlimited );

在sql监视器中的Oracle企业pipe理器中，我可以看到多次运行的sql。 所有runns有“数据库时间”0.0s（如果我把鼠标hover在10微秒以下）和“持续时间”0.0s为正常运行和2.0s为延迟thoose。 如果我去为那个2.0s的运行监视sql执行，我有：

持续时间：2.0s

数据库时间：0.0s

PL / sql和Java：0.0

等待活动：％（这里没有数字）

缓冲区得到：10

IO请求：0

IO字节：0

取电话：2

平行：4

除了持续时间甚至小于数据库时间（10,163微秒数据库时间和3,748微秒持续时间），如果没有鼠标hover，这两个数字都被认为是快速运行。

我不知道还有什么要检查的。

那么Sleep（）和这个一样吗？

Linux多播sendto（）性能随本地监听器而降低

为什么在Nginx的access.log中，request_time比upstream_response_time大得多？

多核系统上的Linux线程调度差异？

可靠的方式来延迟python3代码

并行查询无法在几秒钟内完成有意义的调整。 它们被设计用于长时间处理大量数据的查询。

使用小数据集优化并行语句的最佳方法是暂时禁用它：

alter system set parallel_max_servers=0;

（这是在工作站而不是服务器上开发的优点的一个很好的例子，在服务器上，这种改变会影响到每个人，甚至你甚至没有权限运行这个命令。）

查询可能很简单，但并行性在后台增加了很多复杂性。

很难说为什么它慢。 如果您有sql监控报告，等待事件可能会有所帮助。 但即使这些数字可能只是通用等待“cpu”。 并行查询有很多开销，因为期望资源密集型，长时间运行的查询。 这里有一些类型的开销，可以解释那些2秒来自哪里：

动态采样 – 并行可能会自动导致动态采样，从表中读取数据。 虽然dynamic sampling used for this statement (level=2)可能意味着缺少优化程序统计信息。

操作系统线程启动 – sql语句可能需要启动8个额外的操作系统线程，并准备大量的内存来存放所有的中间数据。 也许参数ParaLLEL_MIN_SERVERS可以帮助防止一些时间用于创建这些线程。

其他监视 – 并行语句会自动监视，这需要递归SELECT和INSERT。

缓存 – 并行查询通常直接从磁盘读取，并跳过读写缓冲区缓存。 数据缓存的规则很复杂，没有文档。

降级 – 找到正确的并行度是复杂的。 例如，我编制了一个影响DOP的39个因素的列表。 有可能是其中一个导致降级，使一些查询快速，另一些慢。

而且可能有几十种其他类型的开销，我想不出来。 并行性对于大规模地改善大型操作的运行时间是非常好的。 但是对于小型查询来说，这并不适用。

延迟是由David Aldridge和Jon Heller提出的并行性引起的，但我不同意Jon Heller提出的解决方案来禁止所有查询（在系统级）的并行性。 您可以使用“更改会话”来禁用它，并在运行大型查询之前重新启用它。 延迟的确切原因仍然是未知的，因为查询在10次运行中有8次快速完成，我期望10/10快速运行。