linux – Oracle 11.2在随机时间对简单SQL有2秒的延迟
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了linux – Oracle 11.2在随机时间对简单SQL有2秒的延迟，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6622字，纯文字阅读大概需要10分钟。
内容图文
一个简单的表连接通常在0.0XX秒内完成,有时在2.0XX秒内完成(根据PL / SQL Developer SQL执行).从SQL Plus运行时会发生这种情况.
如果我运行SQL 10次,8次运行正常,2次运行2次.
它是Centos 7上Linux x86_64的Oracle 11.2.0.4的干净安装.
我已经安装了Oracle推荐的补丁：
>补丁19769489 – 数据库补丁集更新11.2.0.4.5(包括CPUJan2015)
>补丁19877440 – Oracle JavaVM组件11.2.0.4.2数据库PSU(2015年1月)
修补后没有变化.
这两个表有：
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中选择PACKAGE_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
选择了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”)
注意
>用于此语句的动态采样(级别= 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 Monitor的Oracle Enterprise Manager中,我可以看到多次运行的SQL.所有runns都有“数据库时间”0.0s(如果我将鼠标悬停在列表上,则小于10微秒),正常运行时“持续时间”为0.0s,延迟时间为“秒”.
如果我为2.0s的那次运行监控SQL执行,我有：
>持续时间：2.0秒
>数据库时间：0.0s
> PL / SQL& Java：0.0
>等待活动：％(此处没有数字)
>缓冲区得到：10
> IO请求：0
> IO字节：0
>取电话：2
>平行：4
除了持续时间甚至小于数据库时间(10,163微秒数据库时间和3,748微秒持续时间)之外,Theese数字与快速运行一致,如果没有鼠标悬停,则显示为0.0s.
我不知道还有什么要检查.
解决方法:
并行查询无法在几秒钟内进行有意义的调整.它们专为长时间处理大量数据的查询而设计.
使用小数据集优化并行语句的最佳方法是暂时禁用它：
alter system set parallel_max_servers=0;
(这是在工作站而不是服务器上开发的优点的一个很好的例子.在服务器上,这种变化会影响每个人,你甚至可能没有权限运行命令.)
查询可能很简单,但并行性在后台增加了很多复杂性.
很难确切地说为什么它会变慢.如果您有SQL监视报告,则等待事件可能会有所帮助.但即便是这些数字也可能只是像“CPU”这样的通用等待.并行查询有很多开销,期望资源密集,长时间运行的查询.以下是一些类型的开销,可以解释这些2秒来自哪里：
>动态采样 – 并行可能会自动导致动态采样,从表中读取数据.虽然用于此语句的动态采样(级别= 2)
可能只是意味着缺少优化器统计信息.
> OS线程启动 – SQL语句可能需要启动8个额外的OS线程,并准备大量内存来保存所有中间数据.也许
参数PARALLEL_MIN_SERVERS可以帮助防止用于创建这些线程的一些时间.
>附加监视 – 自动监视并行语句,这需要递归SELECT和INSERT.
>缓存 – 并行查询通常直接从磁盘读取并跳过读取和写入缓冲区缓存.何时缓存数据的规则很复杂且没有文档记录.
>降级 – 找到正确的并行度很复杂.例如,我编译了一个39 factors that influence the DOP的列表.其中一个可能导致降级,使一些查询快速而其他查询速度变慢.
并且可能有许多其他类型的开销我无法想到.并行性非常适合大规模改进大型运营的运行时间.但它对于微小的查询效果不佳.
内容总结
以上是互联网集市为您收集整理的linux – Oracle 11.2在随机时间对简单SQL有2秒的延迟全部内容，希望文章能够帮你解决linux – Oracle 11.2在随机时间对简单SQL有2秒的延迟所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。