运维开发网

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

运维开发网 https://www.qedev.com 2020-06-09 10:48 出处:网络
一个简单的表连接通常在0.0XX秒内完成,有时在2.0XX秒内完成(根据PL / SQL Developer SQL执行).从SQL Plus运行时会发生这种情况.
一个简单的表连接通常在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的列表.其中一个可能导致降级,使一些查询快速而其他查询速度变慢.

并且可能有许多其他类型的开销我无法想到.并行性非常适合大规模改进大型运营的运行时间.但它对于微小的查询效果不佳.

0

精彩评论

暂无评论...
验证码 换一张
取 消