Oracle-RAC-11g-r2性能调优---解决查询慢问题

Oracle-RAC-11g-r2性能调优---解决查询慢问题
Oracle-RAC-11g-r2性能调优---解决查询慢问题

知也无涯

Oracle RAC 11g r2查询太慢

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

Oracle RAC 11g r2查询太慢

Problem Description

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

Redhat 5 双机

测试1:双实例,ASM磁盘组包含3个磁盘(SAN)。在其中一个实例中执行:SELECT c.operaccount || ':' || c.PASSWORD || '@' || a.PATH,

a.dll, a.description, '1.gif'

FROM hcs2000.dllnames a, hcs2000.operdllnames b, hcs2000.operaccount c WHERE a.dllnameid = b.dllnameid

AND b.operid = c.operid

AND upper(c.operaccount) = USER

ORDER BY a.dllnameid;

第一次查询,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. 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';

2.Format 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_9638.trc 9638.output

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

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';

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

SQL> show parameter background_dump_dest

The alert.log is named as alert_.log.

Name

--------

=== ODM Data Collection ===

SELECT c.operaccount || ':' || c.PASSWORD || '@' || a.PATH,

a.dll, a.description, '1.gif'

FROM dllnames a, operdllnames b, operaccount c

WHERE a.dllnameid = b.dllnameid

AND b.operid = c.operid

AND upper(c.operaccount) = USER

ORDER BY a.dllnameid

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

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

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

---------------------------------------- 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_4262.trc.output

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

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';

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

SQL> show parameter background_dump_dest

The alert.log 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

------------------------------ -------------------- 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

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

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

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>

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

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

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,

感谢您的配合。

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

您的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, 性能

2020年(Oracle管理)Oracle SQL性能优化方法

(Oracle管理)Oracle SQL性能优化方法

OracleSQL性能优化方法探讨 Oracle性能优化方法(SQL篇)1 1综述2 2表分区的应用2 3访问Table的方式3 4共享SQL语句3 5选择最有效率的表名顺序5 6WHERE子句中的连接顺序.6 7SELECT子句中避免使用’*’6 8减少访问数据库的次数6 9使用DECODE函数来减少处理时间7 10整合简单,无关联的数据库访问8 11删除重复记录8 12用TRUNCATE替代DELETE9 13尽量多使用COMMIT9 14计算记录条数9 15用Where子句替换HAVING子句9 16减少对表的查询10 17通过内部函数提高SQL效率.11 18使用表的别名(Alias)12 19用EXISTS替代IN12 20用NOT EXISTS替代NOT IN13 21识别低效执行的SQL语句13

22使用TKPROF 工具来查询SQL性能状态14 23用EXPLAIN PLAN 分析SQL语句14 24实时批量的处理16

1综述 ORACLE数据库的性能调整是个重要,却又有难度的话题,如何有效地进行调整,需要经过反反复复的过程。在数据库建立时,就能根据应用的需要合理设计分配表空间以及存储参数、内存使用初始化参数,对以后的数据库性能有很大的益处,建立好后,又需要在应用中不断进行应用程序的优化和调整,这需要在大量的实践工作中不断地积累经验,从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整,来说明对数据库性能如何进行优化。 2表分区的应用 对于海量数据的表,可以考虑建立分区以提高操作效率。建立分区一般以关键字为分区的标志,也可以以其他字段作为分区的标志,但效率不如关键字高。建立分区的语句在建表时可以进行说明: createtableTABLENAME() partitionbyrange(PutOutNo) (partitionPART1valueslessthan(200312319999) partitionPART2valueslessthan(200412319999)

系统参数设置-Oracle性能优化(精)

一、SGA 1、Shared pool tunning Shared pool的优化应该放在优先考虑,因为一个cache miss在shared pool中发生比在data buffer中发生导致的成本更高,由于dictionary数据一般比library cache中的数据在内存中保存的时间长,所以关键是library cache的优化。 Gets:(parse)在namespace中查找对象的次数; Pins:(execution)在namespace中读取或执行对象的次数; Reloads:(reparse在执行阶段library cache misses的次数,导致sql需要重新解析。 1)检查v$librarycache中sql area的gethitratio是否超过90%,如果未超过90%,应该检查应用代码,提高应用代码的效率。Select gethitratio from v$librarycache where namespace=’sql area’; 2 v$librarycache中reloads/pins的比率应该小于1%,如果大于1%,应该增加参数shared_pool_size的值。Select sum(pins “executions”,sum(reloads “cache misses”,sum(reloads/sum(pins from v$librarycache; reloads/pins>1%有两种可能,一种是library cache空间不足,一种是sql中引用的对象不合法。 3)shared pool reserved size一般是shared pool size的10%,不能超过50%。 V$shared_pool_reserved中的request misses=0或没有持续增长,或者free_memory 大于shared pool reserved size的50%,表明shared pool reserved size过大,可以压缩。 4)将大的匿名pl/sql代码块转换成小的匿名pl/sql代码块调用存储过程。 5)从9i开始,可以将execution plan与sql语句一起保存在library cache中,方便进行性能诊断。从v$sql_plan中可以看到execution plans。 6)保留大的对象在shared pool中。大的对象是造成内存碎片的主要原因,为了腾出空间许多小对象需要移出内存,从而影响了用户的性能。因此需要将一些常用的大的对象保留在shared pool中,下列对象需要保留在shared pool中: a. 经常使用的存储过程; b. 经常操作的表上的已编译的触发器 c. Sequence,因为Sequence移出shared pool后可能产生号码丢失。查找没有保存在library cache中的大对象: Select * from v$db_object_cache where sharable_mem>10000 and type in ('PACKAGE','PROCEDURE','FUNCTION','PACKAGE BODY' and kept='NO'; 将这些对象保存在library cache中:Execute dbms_shared_pool.keep(‘package_name’; 对应脚本:dbmspool.sql 7查找是否存在过大的匿名pl/sql代码块。两种解决方案:A.转换成小的匿名块调用存储过程 B.将其保留在shared pool中查找是否存在过

品质异常统计表98827

品质异常统计表 序日期异常问题点原因分析处理措施预防措施责任人跟踪人备注 1 7月1日7421B齿轮箱座穿 线糟太窄,电线穿 不过 表面批锋及铸渣过大; 来料检验员漏检至使不 合格品流入 对现场产品及库存品进行 全检,不合格品通知供应商 到现场进行磨处理 来料检验员按标准检验,发现不合格通 知采购部退回供应商,装配品检员对箱 座重点跟踪,对上工序来料进行接收质 量检查。(7月17日已全部返工完,到 8月3日为止,没出现不合格零件) 谢泽球黎先安 2 7月1日7421B箱体与电器安 装板孔位不对(有品 质员要求只安装三个 螺丝) 箱体焊接时孔位偏; 品检员用拉尺进行测量,测 量误差太大,不能满足精度 要求 现场已对生产部件进行配 装 由品质工程师设计检具对箱体螺丝孔 位置进行检验。 (7月13日检具已做好, 给到品检员) 成浩然秦振伟 3 7月1日电机拖板与中轴板磨 合镶条配合不平行, 电机拖板螺母未锁紧 镶条钻点方法不对,造成 点角度与安装角度不一致, 锁紧螺丝后镶条不平行 已装配成品进行返修,将镶 条反面安装,先安装再配 钻,保证钻点角度与安装 角度一致 先装配镶条再进行配钻黎先安成浩然 4 7月1日60CL封边机输送链 条有长一两节,也有 短两三节,甚至五六 节的(32条有3条出 现此问题) 来料检验未按抽样标准检 验,发现异常未做出拒收处 理 对现有及库存品由装配员 工对链条进行拆解或加长 来料检验员按抽样标准检验,并对此异 常重点检查,品质工程师跟进。(员工 反映:到7月5日-7月23日没有出现 质量问题) 李少文成浩然 5 7月1日MJK1333主锯主轴 放置方法不对,未按 包装要求插入插板放 置 —— 将现有库存平放的主轴优 先使用,防止因长时间放置 产生应力变形 磨床加工后必须插入插板放置,没有插 板不允许生产。 牟敦玉谢泽球 6 7月2日排钻:同一台机脚踏 板有时踩一脚,有时 踩两脚才能运转 ——更换脚踏板 对更换的脚踏板进行测试;长期跟踪使 用稳定性 黎先安秦振伟 序日期异常问题点原因分析处理措施预防措施责任人跟踪人备注

OracleSQL性能优化方法

OracleSQL性能优化方法 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访咨询Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序. (6) 7SELECT子句中幸免使用’*’ (6) 8减少访咨询数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访咨询 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14运算记录条数 (9) 15用Where子句替换HA VING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11) 18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)

1综述 ORACLE数据库的性能调整是个重要,却又有难度的话题,如何有效地进行调整,需要通过反反复复的过程。在数据库建立时,就能依照顾用的需要合理设计分配表空间以及储备参数、内存使用初始化参数,对以后的数据库性能有专门大的益处,建立好后,又需要在应用中不断进行应用程序的优化和调整,这需要在大量的实践工作中不断地积存体会,从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用咨询题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整,来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表,能够考虑建立分区以提高操作效率。建立分区一样以关键字为分区的标志,也能够以其他字段作为分区的标志,但效率不如关键字高。建立分区的语句在建表时能够进行讲明: create table TABLENAME() partition by range (PutOutNo) (partition PART1 values lessthan (200312319999) partition PART2 values lessthan (200412319999) 。。。。。。 如此,在进行大部分数据查询,数据更新和数据插入时,Oracle自动判定操作应该在哪个分区进行,幸免了整表操作,提高了执行的效率

品质异常处理流程98703

品质异常处理流程 (公开文件,共4页) 一、目的: 规范品质异常处理流程,提高品质异常处理的时效性,确保来料质量及生产的正常运转,同时满足顾客的质量要求。 二、范围: 适用于本公司来料、制程、出货品质异常的处理。 三、定义: 3.1 来料品质异常: a、不符合相关检验标准要求,且不良率超过质量目标时; b、合格物料制程中发现重点物料不合格时; c、有经过改善且有效果确认,但又重复发生品质异常时。 3.2 制程品质异常: a、使用不合格的原料或材料; b、同一缺陷连续发生; c、不遵守作业标准或不遵守工艺要求; d、机械发生故障或精度磨损; e、其他情形影响到产品质量时。 3.3 出货品质异常: a、客户投诉或抱怨; 四、职责 4.1 来料品质异常: 品质:a.负责填写《品质异常联络单》“异常描述”部分; b.负责将《来料检验报告》、《品质异常联络单》发送于采购,抄送工程、生产; c负责品质异常改善结果确认。 采购:负责将《来料检验报告》、《品质异常联络单》发送给供应商并及时与供应商联系跟踪供应商及时回复“原因分析”“纠正与预防措施”并将结果回复品质部. 4.2 制程品质异常: 品质部: a,负责品质异常之最终判定; b,负责确认品质异常责任部门; c,负责主导品质异常案例的处理过程; d,负责对责任单位的改善结果进行追踪确认

异常责任单位: a负责品质异常的原因分析,提出临时措施及长期改善对策并执行。 生产部: a负责品质异常的改善和预防措施的实施及验证改善措施的有效性; 其它相关单位: a在需要时进行异常改善的配合 4.3 出货品质异常: 品质部: a负责将品质异常通知各部门及确定责任部门; b负责异常改善后的跟踪确认; c负责处理客户抱怨 异常责任单位: a负责品质异常的原因分析,提出临时措施及长期改善对策并执行。 生产部: a负责品质异常的改善和预防措施的实施及验证改善措施的有效性; 营业部: a负责将客户抱怨反馈给相关部门。 其它相关单位: a在需要时进行异常改善的配合 五、工作程序: 5.1 进料品质异常: 5.1.1 依相关检验标准判定不合格,针对不合格物料标示“不合格”,并立即移至不良品区域。 5.1.2 异常成立4小时内开立《品质异常联络单》通知采购。 5.1.3 采购接《品质异常联络单》后4小时内转责任供应商。 5.1.4 供应商需于1个工作日内针对异常物料提出临时对策,如对异常内容有疑问,需在4 小时与品质相关人员确认清楚。 5.1.5 供应商必须在《品质异常联络单》要求的期限前(如无明确要求,默认为《品质异常联络单》发出后2个工作日内)回复完整的改善方案。 5.1.6 品质部对供应商回复内容进行确认,针对改善措施不合格部分予以退件,要求供应商重新回复。改善措施合格,则报告予以归档,跟踪后续进料品质状况,依5.1.7执行。 5.1.7 针对供应商改善后产品加严检验,连续追踪3批无异常予以结案,转正常检验;连续追踪3批中途发现不良现象仍存在,则重复5.1.2-5.1.7。 5.1.8 如供应商改善措施回复后连续2个月无进料,则强制结案,后续进料依正常检验执行。 5.1.9

( O管理)ORACLESL性能优化(内部培训资料)

(O管理)ORACLESL性能优化(内部培训资料)

ORACLESQL性能优化系列(一) 1.选用适合的ORACLE优化器 ORACLE的优化器共有3种: a.RULE(基于规则) b.COST(基于成本) c.CHOOSE(选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS.你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO,Cost-BasedOptimizer),你必须经常运行analyze命令,以增加数据库中的对象统计信息(objectstatistics)的准确性. 如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关.如果table已经被analyze过,优化器模式将自动成为CBO,反之,数据库将采用RULE形式的优化器. 在缺省情况下,ORACLE采用CHOOSE优化器,为了避免那些不必要的全表扫描(fulltablescan),你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器.

2.访问Table的方式 ORACLE采用两种访问表中记录的方式: a.全表扫描 全表扫描就是顺序地访问表中每条记录.ORACLE采用一次读入多个数据块(databaseblock)的方式优化全表扫描. b.通过ROWID访问表 你可以采用基于ROWID的访问方式情况,提高访问表的效率,,ROWID包含了表中记录的物理位置信息..ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系.通常索引提供了快速访问ROWID的方法,因此那些基于索引列的查询就可以得到性能上的提高. 3.共享SQL语句 为了不重复解析相同的SQL语句,在第一次解析之后,ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(systemglobalarea)的共享池(sharedbufferpool)中的内存可以被所有的数据库用户共享.因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它和之前的执行过的语句完全相同,ORACLE就能很快获得已经被解析的语句以及最好的执行路

Oracle SQL性能优化方法研究

Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序. (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)

18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)

1综述 ORACLE数据库的性能调整是个重要,却又有难度的话题,如何有效地进行调整,需要通过反反复复的过程。在数据库建立时,就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数,对以后的数据库性能有专门大的益处,建立好后,又需要在应用中不断进行应用程序的优化和调整,这需要在大量的实践工作中不断地积存经验,从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整,来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表,能够考虑建立分区以提高操作效率。建

oracle性能调优-管理oracle日志之Oracle日志运行机制

理解Oracle的日志机制 ? Oracle的日志是用来记录用户对数据库的改变,这样,当出现服务器硬件故障或者用户错误而丢失数据时,可以通过重做这些日志来恢复已提交的事务,Oracle日志机制包含以下组件: ?日志缓存SGA的一部分,用于缓存服务器进程产生的日志,包括DML和DDL; ? LGWR进程这个后台进程负责将日志缓存的数据写到联机日志文件,每个实例只有一个; ?数据库检查点检查点用于同步数据文件和日志文件,一个检查点事件的完成,代表在这个事件开始之前发生的所有对数据文件的改变都已实际记录到了数据文件,数据库在这个时间点是一致的,在实例恢复的时候,只有在最后一个检查点之后的日志才需要重做; ?联机日志文件用于存放从日志缓存中写出的日志数据,每个数据库最少需要两个日志文件,当前日志文件填满以后,发生日志切换,然后才可以继续写下一个日志文件; ?日志归档LGWR写满所有组的联机日志文件以后,会回头再写第一个组的日志文件,在非归档模式下,被重用的日志文件中的日志会被丢弃,在归档模式下,日志文件被重用前会被ARC0进程复制到归档日志文件; ? 一些可选的日志机制,如归档和Standby,因为附加的I/O会降低系统的性能,同时提供了可靠的灾难恢复能力,不建议因这些性能的下降而关闭生产系统的归档功能。 调整日志缓存 ? 日志缓存的管理机制可以类似理解成一个漏斗,日志数据不断地从漏斗上方加入,然后偶尔打开漏斗下方的开关将加入的数据清空,这个开关就是LGWR进程,为了日志缓存有空间容纳不断加进来的日志数据,LGWR在下面列出的任何一个条件下都会执行写出日志缓存的操作: ?应用程序发出Commit命令时; ?三秒间隔已到时; ?日志缓存三分之一满时; ?日志缓存达到1M时; ?数据库检查点发生时; ? 测量日志缓存的性能通过服务器进程放置日志条到日志缓存时发生等待的次数和时间来测量; Select Name, Value From V$sysstat Where Name In ('redo entries', 'redo buffer allocation retries','redo log space requests'); redo entries 服务器进程放进日志缓存的日志条的总数量; redo buffer allocation retries 服务器放置日志条时必须等待然后再重试的次数; redo log space requests LGWR进程写出日志缓存时等待日志切换的次数; 这个查询用于计算日志缓存重试率,这个比率应该小于百分之一; Select Retries.Value / Entries.Value "Redo log Buffer Retry Ratio" From V$sysstat Entries, V$sysstat Retries Where https://www.360docs.net/doc/f410696754.html, = 'redo entries' And https://www.360docs.net/doc/f410696754.html, = 'redo buffer allocation retries'; 这个查询用来显示哪些会话的LGWR正在进行写等待;

Oracle性能优化总结

个人理解,数据库性能最关键的因素在于IO,因为操作内存是快速的,但是读写磁盘是速度很慢的,优化数据库最关键的问题在于减少磁盘的IO,就个人理解应该分为物理的和逻辑的优化,物理的是指oracle产品本身的一些优化,逻辑优化是指应用程序级别的优化物理优化: 一、优化内存

V$ROWCACHE视图结构

3.管理员可以通过下述语句来查看数据缓冲区的使用情况 select name,value from v$sysstat where name in ('db block gets', 'consistent gets ', 'physical reads'); 数据缓冲区使用命中率(physical reads除以db block gets加consistent gets之和)一定要小于10%,否则需要增加数据缓冲区大小 4.管理员可以通过执行下述语句,查看日志缓冲区的使用情况 select name,value from v$sysstat where name in ('redo entries','redo log space requests') 根据查询出的结果可以计算出日志缓冲区的申请失败率:requests除以entries 申请失败率应该解决与0,否则说明日志缓冲区开设太小,需要增加Oracle数据库的日志缓冲区 二、物理I/0的优化 1.在磁盘上建立数据文件前首先运行磁盘碎片整理程序 为了安全地整理磁盘碎片,需关闭打开数据文件的实例,并且停止服务。如果有足够的连续磁盘空间建立数据文件,那么就容易避免数据文件产生碎片。 2.不要使用磁盘压缩(Oracle文件不支持磁盘压缩) 3.不要使用磁盘加密

供应商品质异常处理协议书

编号:_______________本资料为word版本,可以直接编辑和打印,感谢您的下载 供应商品质异常处理协议书 甲方:___________________ 乙方:___________________ 日期:___________________

为了明确供应商产品质量责任,确保产品原材料及供应商的产品质量满足本公司需求,保障本公司生产顺利进行,经供、需双方商定达成以下协议。 1. 质量责任: 1.1供方应承担的责任: 1.1.1供方应对自己原材料进行严格的进货检验,对供应商的材料质量进行跟踪考核,建立质量档案。 1.1.2供方应建立完善生产工序的控制管理,必须制定生产过程控制文件和作业指导书等,对产品质量有影响的关键工序 建立质控点,所有质控点供方要有专人负责,每一个质控点有专门的措施和标准,措施和标准能得到有效的实施。 1.1.3供方应使生产完全受控,若有失控,应及时查明原因,并采取相应的纠正预防措施。 1.1.4供方提供的原材料应完全符合需方采购订单及品质规格中明确规定的质量要求,及相应的国际、国家、部委颁发 的有关质量标准(包括隐含的质量需求),超出国际、国家质量要求的,以需方要求为准。 1.1.5供方需保障原材料从出厂至需方收料之前的的包装、运输质量。 1.1.6供方原材料在需方生产过程中发生品质异常造成需方生产线停线或已生产好的产品返工、返修。 1.1.7因供方原材料质量问题造成需方产品出厂后发生批次性质量事故(客户索赔、退货等)。 1.1.8供方原材料问题造成需方产品在用户中出现危及人身、财产安全的。 2. 供方交货需遵守以下规定: 2.1所有供方每批交货时均须有出货检验报告及检验合格标示,其检验内容必须是能保障其材料在需方使用中的性能、功 能、装配、使用性、外观等符合要求,交货后有任何因材料发生的品质问题均由供方负责。 2.2新产品或供方改模、修模必须要送样合格才能批量生产。 2.3供方产品必须要有标识,标识上要有产品名称、型号规格、生产日期、数量、需方的料号等。 2.4供方经需方认定批量供货的产品,不得随意更改设计、工艺、技术参数、外形尺寸等;如确实需要更改,必须先通知 需方,同时须提供样品给需方确认,经需方确认合格后,才能供货,否则造成的一切损失全部由供方承担。 3. 赔偿的具体要求协商确认如下: 3.1供方原材料入厂后发生品质异常,供方不能处理而委托需方全检、加工,所需的返工等全部费用由供方承 担(包括工时费、场地费、管理费、误船费、水电费等),全检的不合格品全部退回供方,并由供方及时补足相应数量。 工时费=处理工时x 20元/ (人.小时) 如供方需要在需方内部全检水电费、场地费每次100元,管理费每次100元。 3.2供方原材料同种产品入厂后连续三次以上(含三次)在需方发生问题,需方品管部有权对供方进行暂扣并暂停检验, 直到问题改善为止。 3.3供方原材料入厂后,在生产线发生品质异常造成需方停线返工、返修时,供方需对需方的返工、返修、停线所造成的 损失(含所有材料损失费用)进行赔偿。 赔偿费用=停线时间(小时)X 300/小时+返工工时X 20元/ (人.小时)+材料损失费 3.4供方的原材料因质量问题造成需方产品在客户使用过程中发生品质异常或在客户中出现危及人身、财产安 全、丧失使用价值造成被客户索赔,所有索赔费用由供方负责。 3.5对退回供方的产品,若供方在下次送货时混入,经需方发现,每次处罚人民币1000元。 3.6需方向供方发出的品质异常单,供方需在1个工作大内回复短期处理方案,7个工作日回复有效的改进预

Oracle性能优化学习心得byLYH

Oracle性能优化学习心得 一,优化总的原则 1,查看系统的使用情况 2,查看SGA分配情况,结合系统具体情况进行分析。 3,表的设计分析 4,SQL语句分析 实施要则 1,查看系统的使用情况,CPU占用,内存,I/O读取等 Oracle10G提供的Oracle Enterprise Manager图形化工具中的ADDM 和SQL Tuning Advisor等可以方便的查看系统状况 2,OPS上负载均衡,不同查询用不同Instance 3,提供脚本查看SGA使用情况 4,分析SQL执行情况(trace及其他工具) 实施细节 1,外部调整:我们应该记住Oracle并不是单独运行的。因此我们将查看一下通过调整Oracle服务器以得到高的性能。 2,Row re-sequencing以减少磁盘I/O:我们应该懂得Oracle调优最重要的目标是减少I/O。 3,Oracle SQL调整。Oracle SQL调整是Oracle调整中最重要的领域之一,只要通过一些简单的SQL调优规则就可以大幅度地提升SQL语句的性能,这是一点都不奇怪的。 4,调整Oracle排序:排序对于Oracle性能也是有很大影响的。 5,调整Oracle的竞争:表和索引的参数设置对于UPDATE和INSERT的性能有很大的影响。 二,调优分类: 对Oracle数据库进行性能调整时,应当按照一定的顺序进行,因为系统在前面步骤中进行的调整可以避免后面的一些不必要调整或者代价很大的调整。一般来说可以从两个阶段入手: 1、设计阶段:对其逻辑结构和物理结构进行优化设计,使之在满足需求条件的情况下,系统性能达到最佳,系统开销达到最小; 2、数据库运行阶段:采取操作系统级、数据库级的一些优化措施来使系统性能最佳; ㈠设计阶段: A,数据库设计优化 较多修改较少查询的数据和较多查询较少修改的数据分别对待。 a,结构优化 1,根据应用程序进行数据库设计。 即应用程序采用的是传统的C/S两层体系结构,还是B/W/D三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。 2,遵循3大范式规范化数据结构,减少不必要的冗余。 3,反规范设计,增加必要冗余,提高查询速度。 4,针对变化较少的数据,合理创建临时表和视图,需注意对临时表和视图的及时同步更新

oracle性能优化简介

ORACLE SQL性能优化 我要讲的题目是Oracle SQL性能优化,只是Oracle性能优化中的一项。Oracle的性能优化包含很多方面,比如调整物理存取,调整逻辑存取,调整内存使用,减少网络流量等。这里选择SQL性能优化是因为这部分内容我们测试人员最容易接触到,另外开发人员写SQL脚本时有时很随意,不知不觉就会造成程序性能上的下降。 1.选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理. 在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基 础表.当ORACLE处理多个表时, 会运用排序及合并的方式连接它们.首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行派序,然后扫描 第二个表(FROM子句中最后第二个表),最后将所有从第二个表中检索出 的记录与第一个表中合适记录进行合并. 例如: 表 TAB1 16,384 条记录 表 TAB2 1 条记录 选择TAB2作为基础表 (最好的方法) select count(*) from tab1,tab2 执行时间0.96秒 选择TAB2作为基础表 (不佳的方法)

select count(*) from tab2,tab1 执行时间26.09秒 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. 例如: EMP表描述了LOCATION表和CATEGORY表的交集. SELECT * FROM LOCATION L , CATEGORY C, EMP E WHERE E.EMP_NO BETWEEN 1000 AND 2000 AND E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN 将比下列SQL更有效率 SELECT * FROM EMP E , LOCATION L , CATEGORY C WHERE E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN AND E.EMP_NO BETWEEN 1000 AND 2000 2.WHERE子句中的连接顺序. ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.

Oracle性能优化总结

个人理解,数据库性能最关键的因素在于IO,因为操作存是快速的,但是读写磁盘是速度很慢的,优化数据库最关键的问题在于减少磁盘的IO,就个人理解应该分为物理的和逻辑的优化,物理的是指oracle产品本身的一些优化,逻辑优化是指应用程序级别的优化 物理优化: 一、优化存

3.管理员可以通过下述语句来查看数据缓冲区的使用情况 select name,value from v$sysstat where name in('db block gets','consistent gets','physica l reads'); 数据缓冲区使用命中率(physical reads除以db block gets加consistent gets之和)一定要小于10%,否则需要增加数据缓冲区大小 4.管理员可以通过执行下述语句,查看日志缓冲区的使用情况 select name,value from v$sysstat where name in ('redo entries','redo log space requests') 根据查询出的结果可以计算出日志缓冲区的申请失败率:requests除以entries 申请失败率应该解决与0,否则说明日志缓冲区开设太小,需要增加Oracle数据库的日志缓冲区 二、物理I/0的优化 1.在磁盘上建立数据文件前首先运行磁盘碎片整理程序 为了安全地整理磁盘碎片,需关闭打开数据文件的实例,并且停止服务。如果有足够的连续磁盘空间建立数据文件,那么就容易避免数据文件产生碎片。 2.不要使用磁盘压缩(Oracle文件不支持磁盘压缩) 3.不要使用磁盘加密 加密像磁盘压缩一样加了一个处理层,降低磁盘读写速度。如果担心自己的数据可能泄露,可以使用dbms_obfuscation包和label security选择性地加密数据的敏感部分 4.使用RAID raid使用应注意: 选择硬件raid超过软件raid;日志文件不要放在raid5卷上,因为raid5读性能高而写性能差;把日志文件和归档日志放在与控制文件和数据文件分离的磁盘控制系统上 5.分离页面交换文件到多个磁盘物理卷 跨越至少两个磁盘建立两个页面文件。可以建立四个页面文件并在性能上受益,确保所有页面文件的大小之和至少是物理存的两倍。

品质异常处理流程

品质异常处理流程-标准化文件发布号:(9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

品质异常处理流程 1 目的: 为了使品质异常发生时处理过程有据可依有规可循,使重大品质异常能在规定的时间内得到有效改善,防止相同问题重复发生,降低品质成本,确保产品质量符合本公司或客户需求 2 范围: 来料检验、制程控制、出货检验 3 定义:重大品质异常是指品质问题严重有必要开具《品质异常报告》,并由品质部进行特别跟进的质量事件 3.1来料检验 3.1.1当进料检验需要品质工程师确认时开具《品质异常报告》 3.2制程控制 3.2.1 制程外观不良达10%时开具《品质异常报告》 3.2.2 制程组装不良达8%时开具《品质异常报告》 3.2.3 制程性能不良达3%时开具《品质异常报告》 3.2.4 制程条件不能满足工艺需求而导致停线开具《品质异常报告》. 3.2.5 制程连续3天重复出现的品质问题开具《品质异常报告》 3.3出货检查 3.3.1 出货检查外观不良达 5%时开具《品质异常报告》 3.3.2 出货检查性能不良达2% 时开具《品质异常报告》 3.3.3 出货检查连续3天同一款产品重复出现同一个的品质问题开具《品质异常报告》 备注:以上描述的不良范围每个月月底按照品质异常汇总进行修订,逐步强化。 4 运作流程: 4.1 在生产过程中,当作业人员发现产品出现品质异常时第一时间通知生产组长确认,由生产组长开出《品质异常报告》给到生产主管确认后交予生产文员进行编档之后交品质工程师。 4.2《品质异常报告》的填写必须清楚地写明事件发生的日期、时间、地点、批量数、批号、异常数量、不良率、异常状况的描述 4.3 品质工程师对异常的现象进行初步确认,并在《品质异常报告》签收,然后找到PIE,由PIE对异常进行分析处理。 4.4 PIE接到《品质异常报告》后,需在一个小时内对原因进行分析及给出临时方案,如一个小时完成不了,需上报上级主管给予协助处理,现场原因分析清楚后,PIE针对生产实际状况制订临时方案,临时方案里面必须包括仓库原材料库存,生产在制品,成品的处理,并将临时方案填写至《品质异常报告》中; 4.5 由PIE,品质,采购对临时方案进行评审确认是否可行,如异常是设计或者制程不良时,无需采购对临时方案进行评审,当异常为来料不良时,才需采购对此加工方案进行评审)。 4.6 生产部按照评审合格的的方案进行实施。由PIE对异常临时解决方案进行指导,品质部持续跟踪处理结果是否可行。 4.7 品质工程师按照PIE给出的原因分析找到相关责任部门,要求半个工作日内(采购部因需与供应商沟通,可与品质部协商延长此时间,但需在报告上注

【Oracle性能调优】Oracle Statspack报告中各项指标含义详解

Oracle Statspack报告中各项指标含义详解! Data Buffer Hit Ratio#<#90# 数据块在数据缓冲区中的命中率,通常应该在90%以上,否则考虑加大db_block_buffers(9i 以上可是db_cache_size) Buffer Nowait Ratio#<#99# 在缓冲区中获取buffer 的未等待比率 Library Hit Ratio#<#98# 主要代表着sql在共享区的命中率,通常在98%以上 In Memory Sort Ratio#<#0# 如果过低说明有大量的排序在临时表空间中进行,可尝试增加 sort_area_size Redo Nowait Ratio#<#98# 写日志的不等待比率,太低可调整log_buffer(增加)和 _log_io_size(减小,默认为1/3*log_buffer/log_block_size,使得 _log_io_size 为合适的值,比如128k/log_block_size) Soft Parse Ratio#<#90# 近似当作sql在共享区的命中率,通常高代表使用了绑定变量,太低需要调整应用使用绑定变量,或者参考cursor_sharing = force (9i 中增加了similar ) Latch Hit Ratio#<#99# 内部结构维护锁命中率,高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多,可参考 _spin_count 参数设置

Percent Non-Parse CPU#<#95# 查询实际运行时间/(查询实际运行时间+sql解析时间),太低表示解析消耗时间过长 Percent Parse CPU to Parse Elapsed#<#90# 解析实际所用时间/(解析实际所用时间+解析中等待资源时间),越高越好 Execute to Parse Percent#<#10# 该值越高表示一次解析后被重复执行的次数越多,如果过低可以考虑设置 session_cached_cursors > 0 Memory Usage Percent#<#75# 共享池的使用率,应该稳定在75%--90%之间,太小浪费内存,太大则显内存不足 Percent of SQLs with Execution>1#<#40# 执行次数大于1的sql的比率(若太小可能是没有使用绑定变量) Percent of Memory for SQl with Execution>1#<#0# 执行次数大于1的sql消耗内存/(所有sql消耗内存) Instance Load Profile Redo Size/Sec#>#100000# 每秒产生的日志大小(单位字节),可标志数据库任务的繁重与否 Redo Size/Tx#>#0# 平均每个事务的日志生成量 Logical Reads/Sec(逻辑读)#>#0#

Oracle RAC 11g r2性能调优 - 解决查询慢问题

知也无涯 Oracle RAC 11g r2查询太慢 --------------------------------------------------- Oracle RAC 11g r2查询太慢 Problem Description --------------------------------------------------- Redhat 5 双机 测试1:双实例,ASM磁盘组包含3个磁盘(SAN)。在其中一个实例中执行:SELECT c.operaccount || ':' || c.PASSWORD || '@' || a.PATH, a.dll, a.description, '1.gif' FROM hcs2000.dllnames a, hcs2000.operdllnames b, hcs2000.operaccount c WHERE a.dllnameid = b.dllnameid AND b.operid = c.operid AND upper(c.operaccount) = USER ORDER BY a.dllnameid; 第一次查询,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, Array请您执行以下动作: 如果可以,请在您提到的4个场景下都生成以下文件,并请添加您 的说明后,作为附件更新到SR上: ACTION PLAN -----------------------

oracle性能优化总结

Oracle 性能优化50个方法https://www.360docs.net/doc/f410696754.html,

1. 选用适合的ORACLE优化器 ORACLE的优化器共有3种: a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行analyze 命令,以增加数据库中的对象统计信息(object statistics)的准确性. 如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关. 如果table已经被analyze过, 优化器模式将自动成为CBO , 反之,数据库将采用RULE形式的优化器. 在缺省情况下,ORACLE采用CHOOSE优化器, 为了避免那些不必要的全表扫描(full table scan) , 你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器. 2. 访问Table的方式 ORACLE 采用两种访问表中记录的方式: a. 全表扫描全表扫描就是顺序地访问表中每条记录. ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描,这样的访问方式是效率最低的. b. 通过ROWID访问表你可以采用基于ROWID的访问方式情况,提高访问表的效率, , ROWID包含了表中记录的物理位置信息..ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系. 通常索引提供了快速访问ROWID的方法,因此那些基于索 引列的查询就可以得到性能上的提高. 3. 共享SQL语句 为了不重复解析相同的SQL语句,在第一次解析之后, ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享. 因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它和之前的执行过的语句完全相同, ORACLE就能很快获得已经被解析的语句以及最好的执行路径. ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用. 可惜的是ORACLE 只对简单的表提供高速缓冲(cache buffering) ,这个功能并不适用于多表连接查询. 数据库管理员必须在init.ora中为这个区域设置合适的参数,当这个内存区域越大,就可以保留更多的语句,当然被共享的可能性也就越大了. 当你向ORACLE 提交一个SQL语句,ORACLE会首先在这块内存中查找相同的语句. 这里需要注明的是,ORACLE对两者采取的是一种严格匹配,要达 成共享,SQL语句必须完全相同(包括空格,换行等). 共享的语句必须满足三个条件: A. 字符级的比较: 当前被执行的语句和共享池中的语句必须完全相同. 例如: SELECT * FROM EMP; 和下列每一个都不同 SELECT * from EMP; Select * From Emp;

相关文档
最新文档