admin管理员组

文章数量:1567569

2024年1月11日发(作者:)

知也无涯

Oracle RAC 11g r2查询太慢

---------------------------------------------------

Oracle RAC 11g r2查询太慢

Problem Description

---------------------------------------------------

Redhat 5 双机

测试1:双实例,ASM磁盘组包含3个磁盘(SAN)。在其中一个实例中执行:

SELECT count || ':' || RD || '@' || ,

, ption, ''

FROM es a, lnames b, count c

WHERE eid = eid

AND =

AND upper(count) = USER

ORDER BY eid;

第一次查询,25秒。第二次查询,3秒。第三次查询,1.6秒。过10分钟后查询,26秒。

测试2:在其中一台主机上创建基于ASM磁盘组的单个实例,

第一次查询,14秒。第二次查询,3秒。第三次查询,0.7秒。第四次查询,3.5秒。

测试3:在其中一台主机上创建基于文件系统的单个实例,

第一次查询,5秒。第二次查询,2.2秒。第三次查询,2.1秒。

测试4:在PC的VMware虚拟机里面单实例查询,只需0.001秒或0秒。

测试1中的查询太慢了,请问怎么查看问题原因,如何调优?

Dear customer,

请您执行以下动作:

如果可以,请在您提到的4个场景下都生成以下文件,并请添加您的说明后,作为附件更新到SR上:

ACTION PLAN

-----------------------

1 / 12

1. Please generate 10046 trace for your sql:

SQL>connect username/password

SQL>alter session set timed_statistics = true;

SQL>alter session set statistics_level=all;

SQL>alter session set max_dump_ = unlimited;

SQL>alter session set events '10046 trace name context

forever, level 12';

SQL>

SQL>alter session set events '10046 trace name context off';

your 10046 trace file:

$tkprof

例如

生成的文件应该是在您的udump路径下面。

寻找UDUMP路径,请参考

SQL> show parameter user_dump_dest

之后,format您的文件

$cd /u01/OracleAPP/oracle/admin/R1020/udump

$ls -ltr

$tkprof r1020_ora_

3.请提交您 10046 trace 以及 tkprof 输出文件

Dear customer,

目前来看,您问题表中遇到了并行的配置。为了进一步诊断,请执行以下动作,并提供输出结果:

ACTION PLAN

-----------------------

请分别在测试2:在其中一台主机上创建基于ASM磁盘组的实例

以及

测试4:在PC的VMware虚拟机里面单实例查询

的测试环境中执行以下动作

SQL> show parameter parallel_min_servers

SQL> select table_name,degree from dba_tables where

2 / 12

table_name='dllnames';

SQL> select table_name,degree from dba_tables where

table_name='operdllnames';

SQL> select table_name,degree from dba_tables where

table_name='operaccount';

并请提供以上测试2, 4环境的数据库alert 日志 位于bdump下面

SQL> show parameter background_dump_dest

The is named as alert_.log.

Name

--------

=== ODM Data Collection ===

SELECT count || ':' || RD || '@' || ,

, ption, ''

FROM dllnames a, operdllnames b, operaccount c

WHERE eid = eid

AND =

AND upper(count) = USER

ORDER BY eid

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ----------

----------

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.01 11.14 0 3 0 0

Fetch 2 0.03 2.24 0 0 0 1

------- ------ -------- ---------- ---------- ---------- ----------

----------

total 4 0.05 13.39 0 3 0 1

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 5

Rows Row Source Operation

3 / 12

------- ---------------------------------------------------

1 PX COORDINATOR (cr=3 pr=0 pw=0 time=0 us)

0 PX SEND QC (ORDER) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=3 size=68

card=1)

0 SORT ORDER BY (cr=0 pr=0 pw=0 time=0 us cost=3 size=68 card=1)

0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)

0 PX SEND RANGE :TQ10000 (cr=0 pr=0 pw=0 time=0 us)

0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)

0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=68 card=1)

0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=19 card=1)

0 PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us)

0 TABLE ACCESS FULL OPERACCOUNT (cr=0 pr=0 pw=0 time=0 us cost=2 size=11

card=1)

0 INDEX FULL SCAN OPERDLLNAMESINDEX (cr=0 pr=0 pw=0 time=0 us cost=1

size=16 card=2)(object id 73471)

0 INDEX UNIQUE SCAN PK_DLLNAMEID (cr=0 pr=0 pw=0 time=0 us cost=0 size=0

card=1)(object id 73465)

0 TABLE ACCESS BY INDEX ROWID DLLNAMES (cr=0 pr=0 pw=0 time=0 us cost=1

size=49 card=1)

Elapsed times include waiting on following events:

Event waited on Times Max. Wait Total Waited

---------------------------------------- Waited ----------

------------

rdbms ipc reply 2 0.00 0.00

os thread startup 96 0.15 10.46

PX Deq: Join ACK 78 0.25 0.39

latch free 10 0.00 0.01

latch: parallel query alloc buffer 1 0.00 0.00

PX Deq: Parse Reply 66 0.04 0.21

SQL*Net message to client 2 0.00 0.00

PX Deq: Execute Reply 132 0.01 0.15

PX Deq Credit: send blkd 15 1.98 2.03

SQL*Net message from client 2 0.00 0.00

PX Deq: Signal ACK RSG 70 0.00 0.01

latch: call allocation 4 0.00 0.01

PX Deq: Slave Session Stats 2 0.00 0.00

enq: PS - contention 2 0.00 0.00

********************************************************************************

Elapsed times include waiting on following events:

Event waited on Times Max. Wait Total Waited

4 / 12

---------------------------------------- Waited ----------

------------

SQL*Net message to client 3 0.00 0.00

SQL*Net message from client 3 59.90 59.90

rdbms ipc reply 2 0.00 0.00

os thread startup 96 0.15 10.46

PX Deq: Join ACK 78 0.25 0.39

latch free 10 0.00 0.01

latch: parallel query alloc buffer 1 0.00 0.00

PX Deq: Parse Reply 66 0.04 0.21

PX Deq: Execute Reply 132 0.01 0.15

PX Deq Credit: send blkd 15 1.98 2.03

PX Deq: Signal ACK RSG 70 0.00 0.01

latch: call allocation 4 0.00 0.01

PX Deq: Slave Session Stats 2 0.00 0.00

enq: PS - contention 2 0.00 0.00

----------------

mytestas1_ora_

----------------------

Dear customer,

感谢您的配合。

目前来看,您问题表中遇到了并行的配置。为了进一步诊断,请执行以下动作,并提供输出结果:

ACTION PLAN

-----------------------

请分别在测试2:在其中一台主机上创建基于ASM磁盘组的实例

以及

测试4:在PC的VMware虚拟机里面单实例查询

的测试环境中执行以下动作

SQL> show parameter parallel_min_servers

SQL> select table_name,degree from dba_tables where

table_name='dllnames';

SQL> select table_name,degree from dba_tables where

table_name='operdllnames';

SQL> select table_name,degree from dba_tables where

table_name='operaccount';

5 / 12

并请提供以上测试2, 4环境的数据库alert 日志 位于bdump下面

SQL> show parameter background_dump_dest

The is named as alert_.log.

测试2实例的输出:

SQL> show parameter parallel_min_servers

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_min_servers integer 0

SQL> select table_name,degree from dba_tables where

table_name='DLLNAMES';

TABLE_NAME DEGREE

------------------------------ --------------------

DLLNAMES 1

SQL> select table_name,degree from dba_tables where

table_name='OPERDLLNAMES';

TABLE_NAME DEGREE

------------------------------ --------------------

OPERDLLNAMES DEFAULT

SQL> select table_name,degree from dba_tables where

table_name='OPERACCOUNT';

TABLE_NAME DEGREE

------------------------------ --------------------

OPERACCOUNT DEFAULT

测试4实例的输出:

SQL> show parameter parallel_min_servers

SQL>

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_min_servers integer 0

SQL> select table_name,degree from dba_tables where

table_name='DLLNAMES' and owner='HCS2000';

TABLE_NAME DEGREE

6 / 12

------------------------------ --------------------

DLLNAMES 1

SQL> select table_name,degree from dba_tables where

table_name='OPERDLLNAMES' and owner='HCS2000';

TABLE_NAME DEGREE

------------------------------ --------------------

OPERDLLNAMES DEFAULT

SQL> select table_name,degree from dba_tables where

table_name='OPERACCOUNT' and owner='HCS2000';

TABLE_NAME DEGREE

------------------------------ --------------------

OPERACCOUNT DEFAULT

Dear customer,

感谢您的更新。

从您当前的设置来看,应该很大可能与您当前RAC 服务器的多颗CPU数量有关

TABLE_NAME DEGREE

------------------------------ --------------------

OPERDLLNAMES DEFAULT

您的DEGREE 是默认值,该默认值的算法为

假设 CPU 数目为16,一般

show parameter PARALLEL_THREADS_PER_CPU

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_threads_per_cpu integer 2

show parameter cpu

NAME TYPE VALUE

7 / 12

------------------------------------ -----------

------------------------------

cpu_count integer 16

那么 以下对于并行的默认值设置即为:

Threads/CPU = 3 ("parallel_threads_per_cpu")

default DOP = (# CPU * Threads/CPU)

加入之前CPU=16, parallel_threads_per_cpu =2,

default DOP =3x 2 x 16 = 96

================

ACTION PLAN

------------------------

请您提供您当前两个环境的

show parameter PARALLEL_THREADS_PER_CPU

show parameter cpu

或者您可以直接执行

对于单机

ALTER SYSTEM SET parallel_min_servers = 96 SCOPE=BOTH;

对于RAC,执行

ALTER SYSTEM SET parallel_min_servers = 96 SCOPE=BOTH

SID='ORCL1';

ALTER SYSTEM SET parallel_min_servers = 96 SCOPE=BOTH

SID='ORCL2';

之后重新测试您的SQL。

测试环境2:

SQL> show parameter cpu

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

cpu_count integer 24

parallel_threads_per_cpu integer 2

resource_manager_cpu_allocation integer 24

SQL>

8 / 12

SQL> ALTER SYSTEM SET parallel_min_servers = 144 SCOPE=BOTH;

ALTER SYSTEM SET parallel_min_servers = 144 SCOPE=BOTH

*

ERROR at line 1:

ORA-02097: parameter cannot be modified because specified

value is invalid

ORA-12811: PARALLEL_MIN_SERVERS must be less than or equal to

PARALLEL_MAX_SERVERS, 135

SQL> show parameter parallel_min_servers

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_min_servers integer 0

SQL> show parameter PARALLEL_MAX_SERVERS

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_max_servers integer 135

SQL> ALTER SYSTEM SET parallel_min_servers = 135 SCOPE=BOTH;

System altered.

SQL> show parameter parallel_min_servers

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_min_servers integer 135

设置完之后,连续测试5次,分别用时3.7s,3.7s,0.4s, 0.4s, 0.7s。过5分钟再测,用时3.4s。

还是比较慢。

测试环境4:

SQL> show parameter cpu

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

cpu_count integer 1

9 / 12

parallel_threads_per_cpu integer 2

测试环境2:

SQL> show parameter cpu

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

cpu_count integer 24

parallel_threads_per_cpu integer 2

resource_manager_cpu_allocation integer 24

SQL>

SQL> ALTER SYSTEM SET parallel_min_servers = 144 SCOPE=BOTH;

ALTER SYSTEM SET parallel_min_servers = 144 SCOPE=BOTH

*

ERROR at line 1:

ORA-02097: parameter cannot be modified because specified

value is invalid

ORA-12811: PARALLEL_MIN_SERVERS must be less than or equal to

PARALLEL_MAX_SERVERS, 135

SQL> show parameter parallel_min_servers

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_min_servers integer 0

SQL> show parameter PARALLEL_MAX_SERVERS

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_max_servers integer 135

SQL> ALTER SYSTEM SET parallel_min_servers = 135 SCOPE=BOTH;

System altered.

SQL> show parameter parallel_min_servers

10 / 12

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

parallel_min_servers integer 135

设置完之后,连续测试5次,分别用时3.7s,3.7s,0.4s, 0.4s, 0.7s。过5分钟再测,用时3.4s。

还是比较慢。

测试环境4:

SQL> show parameter cpu

NAME TYPE VALUE

------------------------------------ -----------

------------------------------

cpu_count integer 1

parallel_threads_per_cpu integer 2

Dear customer,

我们从您提供的信息中发现,您的比较是基于9I的单机环境,是没有使用并行的。如果您的业务都是基于9I单机开发,建议您将

parallel_max_servers 设置为0 之后再次测试

SQL> ALTER SYSTEM SET parallel_min_servers = 0 SCOPE=BOTH;

ALTER SYSTEM SET parallel_max_servers = 0 SCOPE=BOTH;

之后,请将您新测试的10046 结果更新到SR上。

已经执行了

ALTER SYSTEM SET parallel_min_servers = 0 SCOPE=BOTH;

ALTER SYSTEM SET parallel_max_servers = 0 SCOPE=BOTH;

再次测试,查询用时为0.01秒,可以接受。trace文件就不上传了。

请问 parallel_max_servers 设置为0后,系统的24个CPU是不是同时只能有1个用于该查询操作(而且只有一个线程)?

抛开应用其它部分,单就这个select语句而言,如何修改该select语句或做其它设置,从而充分利用多个cpu多线程查询(如果表中数据很多的话,肯定是多个cpu并行查询速度更快)?

Dear customer,

感谢您的配合。

11 / 12

目前从您应用的等待来看,您是遇到了并发高的负影响。

您的SQL在不启用并发的情况下应该会执行的很好。

如果您希望在打开并发设置前提下,单独调整问题表,您可以在问题表上执行

打开并发

ALTER SYSTEM SET parallel_min_servers = 96 SCOPE=BOTH;

ALTER SYSTEM SET parallel_max_servers = 135 SCOPE=BOTH;

ALTER TABLE dllnames NOPARALLEL;

ALTER TABLE operdllnames NOPARALLEL;

ALTER TABLE operaccount NOPARALLEL;

ALTER TABLE dllnames NOPARALLEL;

ALTER TABLE operdllnames NOPARALLEL;

ALTER TABLE operaccount NOPARALLEL;

或者

屏蔽服务器的并发

SQL> ALTER SYSTEM SET parallel_min_servers = 0 SCOPE=BOTH;

ALTER SYSTEM SET parallel_max_servers = 0 SCOPE=BOTH;

标签: ORACLE, RAC, 性能

12 / 12

本文标签: 查询问题并发并行