linux – Oracle 11.2在随机时间对简单SQL有2秒的延迟
一个简单的表连接通常在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的干净安装. >补丁19769489 – 数据库补丁集更新11.2.0.4.5(包括CPUJan2015) 修补后没有变化. 这两个表有: 在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.0秒 除了持续时间甚至小于数据库时间(10,163微秒数据库时间和3,748微秒持续时间)之外,Theese数字与快速运行一致,如果没有鼠标悬停,则显示为0.0s. 我不知道还有什么要检查. 解决方法
并行查询无法在几秒钟内进行有意义的调整.它们专为长时间处理大量数据的查询而设计.
使用小数据集优化并行语句的最佳方法是暂时禁用它: alter system set parallel_max_servers=0; (这是在工作站而不是服务器上开发的优点的一个很好的例子.在服务器上,这种变化会影响每个人,你甚至可能没有权限运行命令.) 查询可能很简单,但并行性在后台增加了很多复杂性. 很难确切地说为什么它会变慢.如果您有SQL监视报告,则等待事件可能会有所帮助.但即便是这些数字也可能只是像“CPU”这样的通用等待.并行查询有很多开销,期望资源密集,长时间运行的查询.以下是一些类型的开销,可以解释这些2秒来自哪里: >动态采样 – 并行可能会自动导致动态采样,从表中读取数据.虽然用于此语句的动态采样(级别= 2) 并且可能有许多其他类型的开销我无法想到.并行性非常适合大规模改进大型运营的运行时间.但它对于微小的查询效果不佳. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |