http://blog.sina.com.cn/s/blog_61cd89f60102eej1.html

1.direct path read temp

select TOTAL_BLOCKS,USED_BLOCKS from v$sort_segment;

看看是不是在不段增加
select * from v$sysstat where NAME LIKE '%workarea executions%';

看看是不是在不段增加
select operation_id,operation_type,actual_mem_used,tempseg_size,tablespace
from v$session s,v$sql_workarea_active w
where s.sid=w.sid
and S.SID=?

2.

http://blog.csdn.net/zq9017197/article/details/7940984

为了排序工作在临时区域读写时,等待direct path read temp、direct path write temp事件。这个等待事件收从oracle 10g起被分类的,oracle 9i为止是通过direct path read、direct path write等待观察的。排序段上的 direct path I/O是在需要排序的数据比排序所分配的PGA内存区大时发生的。因此在排序工作时若大量发生direct path read temp、direct path write temp等待,就可以通过追加分配内存区域而避免等待。

  1. SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'direct path read temp';
  2. EVENT# NAME                           PARAMETER1      PARAMETER2      PARAMETER3
  3. ---------- ------------------------------ --------------- --------------- ---------------
  4. 195 direct path read temp          file number     first dba       block cnt
  5. SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'direct path write temp';
  6. EVENT# NAME                           PARAMETER1      PARAMETER2      PARAMETER3
  7. ---------- ------------------------------ --------------- --------------- ---------------
  8. 197 direct path write temp         file number     first dba       block cnt

1、应用程序层
检查需要排序的sql语句是否已经最优化。不必要的排序操作会导致CPU浪费、PGA区域浪费、磁盘I/O浪费。从UNION和UNION ALL的性能差异上可以得知,只靠减少不必要的排序操作,也能解决许多问题。
2、oracle内存层
在进程上分配的工作区大小内一次性实现的排序称为One pass sort。与此相反的情况称为Multi pass sort。发生Multi pass sort时,排序工作过程中将排序结果读写到排序段(sort segment)区域,因此发生direct path read temp、direct path write temp等待。如果该等待大量发生,就可以适当提高pga_aggregate_target值,以此消除问题。

oracle在调优指南上推荐如下设定pga_aggregate_target值。
OLTP:pga_aggregate_target=(total_mem * 80%) * 20%
OLAP:pga_aggregate_target=(total_mem * 80%) * 50%
上述的意思是,假设OS本身使用20%左右的内存,OLTP系统上使用剩余内存的20%左右,OLAP系统因为排序工作较多,所以使用剩余内存的50%左右。

sample 1;

select a.sql_text,a.sql_id,b.event from v$sql a, (select sql_id,event from DBA_HIST_ACTIVE_SESS_HISTORY
where
sample_time between to_timestamp('&begin_time','yyyy-mm-dd hh24:mi:ss') and to_timestamp('&end_time','yyyy-mm-dd hh24:mi:ss'))
b where a.sql_id=b.sql_id and b.event like '%direct path read temp%%'

2018-01-02 02:00:00
2018-01-02 05:00:00

0ssa391ppxxhx
crh7vrb1kaqbb
bu3yqq1424q6c

####20180110
direct path read temp
select TOTAL_BLOCKS,USED_BLOCKS from v$sort_segment;
看看是不是在不段增加
select * from v$sysstat where NAME LIKE '%workarea executions%';
看看是不是在不段增加
select operation_id,operation_type,actual_mem_used,tempseg_size,tablespace
from v$session s,v$sql_workarea_active w
where s.sid=w.sid
and S.SID=?
能够看到会话使用了工作区或者临时表空间信息。
prod:
SQL> select operation_id,operation_type,actual_mem_used,tempseg_size,tablespace
2 from v$session s,v$sql_workarea_active w
3 where s.sid=w.sid
4 /
OPERATION_ID OPERATION_TYPE ACTUAL_MEM_USED TEMPSEG_SIZE TABLESPACE
------------ -------------------------------------------------------------------------------- --------------- ------------ ------------------------------
b5c92dn9a3ac2 3 HASH-JOIN 1623040
3 HASH-JOIN 1644544

SQL>
b5c92dn9a3ac2
INSERT INTO txs_summ(stacid,brchcd,trandt,datefq,datecd,tranam,lsblam,onblam) SELECT stacid, brchcd, trandt, datefq, datecd,

tranam, lsblam, tranam+lsblam AS onblam FROM (SELECT a.stacid, a.deptcd as brchcd ,:1 as trandt,:2 as datefq,:3 as datecd,

coalesce( (select SUM(CASE WHEN T.AMNTCD = 'D' THEN T.TRANEQ * -1 WHEN T.AMNTCD = 'C' THEN T.TRANEQ END) from gli_vchr t where t.PRDUCD

IN ('D-GOVSE','D-LOCGOV') and t.itemcd like '6%' and t.itemcd not in (select t.prodcd from txp_type_map t where t.prodp1 =

'pricetaxspsm') and t.trandt >= :4 and t.trandt <= :5 and t.acctbr in

('9600','756028','756034','756004','756040','756046','756020','9091','999807','756003','756055','756062','756027','756030','756015','756057','756060','7560

26','756014','756012','756058','756056','756059','756010','756031','756038','756009','756018','756021','756029','756013','756042','756045','9085'

DEV:

SQL> select operation_id,operation_type,actual_mem_used,tempseg_size,tablespace
2 from v$session s,v$sql_workarea_active w
3 where s.sid=w.sid
4 ;

OPERATION_ID
------------
OPERATION_TYPE
--------------------------------------------------------------------------------
ACTUAL_MEM_USED TEMPSEG_SIZE TABLESPACE
--------------- ------------ ------------------------------
1
SORT (v2)
8111104

SQL> /

STATISTIC# NAME
---------- ----------------------------------------------------------------
CLASS VALUE STAT_ID
---------- ---------- ----------
618 workarea executions - optimal
64 7822 3211650785

619 workarea executions - onepass
64 8 798730793

620 workarea executions - multipass
64 0 3804491469

setting:

根据sql 对比,感觉该SQL 消耗了500M pga, 因此调小PGA到400M ,看看该SQL 走的是否是direct path read temp,结论是的走了direct path read temp
SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 10 10:11:45 2018

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>
SQL> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target big integer 4G
SQL> alter system set pga_aggregate_target=400M;

System altered.

alter system set "_pga_max_size"=400M;
[CBO PARAMETER _PGA_MAX_SIZE CBO initialization parameter "_pga_max_size" with a non-default value of "838860 KB" as per V$SQL_OPTIMIZER_ENV.

Review the correctness of this non-default value "838860 KB" for SQL_ID crh7vrb1kaqbb.]

###setting2: 怀疑 direct path read temp 是由于FILESYSTEMIO_OPTIONS 参数引起的,规避方法是调大PGA

FILESYSTEMIO_OPTIONS = SETALL v ASYNCH Oracle11g on RHEL5 direct path read temp waits
此问题未回答。

johnlanc63
Newbie
johnlanc63 2011-6-28 下午11:26
In the process of migrating from hosting systems in house to a 3rd party data centre I am trying to understand why some queries are taking longer than our

existing system. The existing server is running ASM which we are unable to use in the 3rd party datacentre, so this is undoubtedly contributing due to the

way things like async io is working.

The new system is a LeftHand SAN with masses of spindles and everyting is spread over everything (Network RAID 10 over RAID 5).

I thought the slowness might be due to directio not being used for sorts, so I changed FILESYSTEMIO_OPTIONS=SETALL from AYSNCH.

The results:
1) On current system elapsed time: 60 seconds to return result to screen.
2) On new system FILESYSTEMIO_OPTIONS=ASYNCH: 90 seconds to return result to screen.
3) On new system FILESYSTEMIO_OPTIONS=SETALL: 200 seconds to turn result to screen.

I have included tkprof from 10046 traces for all three scenarios. What I cannot see in the difference between scenarios 2 and 3 is why there is almost a

full 2 minutes difference between them.

Any ideas anyone?

John

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

Instance on ASM:

select count(*)
from
(SELECT CCL_NUM, PR_TRF_ID, PR_TIM_ID, SCHEME_ID, CCL_TIM_ID
from GMS.V_WP_CYCLETIMING)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.03 0.03 0 8 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 50.67 60.14 173417 68671 52 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 50.70 60.18 173417 68679 52 1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 SORT AGGREGATE (cr=68671 pr=173417 pw=128388 time=60144927 us)
1212626 1212626 1212626 VIEW V_WP_CYCLETIMING_RAW (cr=68671 pr=173417 pw=128388 time=59363277 us cost=236044 size=12825032 card=6412516)

1212626 1212626 1212626 SORT GROUP BY (cr=68671 pr=173417 pw=128388 time=58957659 us cost=236044 size=891339724 card=6412516)
6518626 6518626 6518626 HASH JOIN RIGHT OUTER (cr=68671 pr=45029 pw=0 time=20578830 us cost=38180 size=891339724 card=6412516)
103 103 103 VIEW V_TRF_MAP (cr=2 pr=0 pw=0 time=992 us cost=2 size=3605 card=103)
103 103 103 WINDOW BUFFER (cr=2 pr=0 pw=0 time=785 us cost=2 size=2575 card=103)
103 103 103 TABLE ACCESS BY INDEX ROWID T_TRF_MAP (cr=2 pr=0 pw=0 time=233 us cost=2 size=2575 card=103)
103 103 103 INDEX FULL SCAN T_TRF_MAP_PK (cr=1 pr=0 pw=0 time=125 us cost=1 size=0 card=103)(object id 112849)
6518626 6518626 6518626 HASH JOIN RIGHT OUTER (cr=68669 pr=45029 pw=0 time=16625866 us cost=38139 size=666901664 card=6412516)
42 42 42 TABLE ACCESS FULL T_SCHEMEMAPPING (cr=6 pr=0 pw=0 time=81 us cost=3 size=756 card=42)
6518626 6518626 6518626 HASH JOIN RIGHT OUTER (cr=68663 pr=45029 pw=0 time=12030313 us cost=38097 size=551476376 card=6412516)
8 8 8 TABLE ACCESS FULL T_CYCLEFREQUENCY (cr=6 pr=0 pw=0 time=31 us cost=3 size=48 card=8)
6518626 6518626 6518626 HASH JOIN (cr=68657 pr=45029 pw=0 time=8544563 us cost=38055 size=513001280 card=6412516)
2319169 2319169 2319169 TABLE ACCESS FULL T_MEMBERSHIP (cr=23623 pr=0 pw=0 time=1186376 us cost=6598 size=122892849 card=2318733)

6519398 6519398 6519398 TABLE ACCESS FULL T_EVENT (cr=45034 pr=45029 pw=0 time=1509690 us cost=12379 size=173537721 card=6427323)

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net break/reset to client 4 0.00 0.00
SQL*Net message to client 4 0.00 0.00
SQL*Net message from client 4 12.28 29.78
asynch descriptor resize 16 0.00 0.00
direct path read 12 0.00 0.03
direct path write temp 20 0.01 0.03
direct path read temp 10193 0.01 9.30

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

Instance on LeftHand SAN with FILESYSTEMIO_OPTIONS=ASYNCH

select count(*)
from
(SELECT CCL_NUM, PR_TRF_ID, PR_TIM_ID, SCHEME_ID, CCL_TIM_ID
from GMS.V_WP_CYCLETIMING)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.11 0.27 40 644 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 54.49 98.64 197404 68948 52 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 54.61 98.91 197444 69592 52 1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 SORT AGGREGATE (cr=68948 pr=197404 pw=128470 time=98644230 us)
1212626 1212626 1212626 VIEW V_WP_CYCLETIMING_RAW (cr=68948 pr=197404 pw=128470 time=98844607 us cost=230412 size=13388690 card=6694345)

1212626 1212626 1212626 SORT GROUP BY (cr=68948 pr=197404 pw=128470 time=98609350 us cost=230412 size=930513955 card=6694345)
6518585 6518585 6518585 HASH JOIN RIGHT OUTER (cr=68948 pr=68934 pw=0 time=31595734 us cost=32525 size=930513955 card=6694345)
103 103 103 VIEW V_TRF_MAP (cr=2 pr=2 pw=0 time=14750 us cost=2 size=3605 card=103)
103 103 103 WINDOW BUFFER (cr=2 pr=2 pw=0 time=14540 us cost=2 size=2575 card=103)
103 103 103 TABLE ACCESS BY INDEX ROWID T_TRF_MAP (cr=2 pr=2 pw=0 time=13926 us cost=2 size=2575 card=103)
103 103 103 INDEX FULL SCAN T_TRF_MAP_PK (cr=1 pr=1 pw=0 time=5471 us cost=1 size=0 card=103)(object id 72130)
6518585 6518585 6518585 HASH JOIN RIGHT OUTER (cr=68946 pr=68932 pw=0 time=27226814 us cost=32488 size=696211880 card=6694345)
42 42 42 TABLE ACCESS FULL T_SCHEMEMAPPING (cr=6 pr=6 pw=0 time=17364 us cost=3 size=756 card=42)
6518585 6518585 6518585 HASH JOIN RIGHT OUTER (cr=68940 pr=68926 pw=0 time=22297207 us cost=32449 size=575713670 card=6694345)
8 8 8 TABLE ACCESS FULL T_CYCLEFREQUENCY (cr=6 pr=6 pw=0 time=52914 us cost=3 size=48 card=8)
6518585 6518585 6518585 HASH JOIN (cr=68934 pr=68920 pw=0 time=18325600 us cost=32411 size=535547600 card=6694345)
2319128 2319128 2319128 TABLE ACCESS FULL T_MEMBERSHIP (cr=23368 pr=23358 pw=0 time=1869684 us cost=5751 size=122892849 card=2318733)

6519357 6519357 6519357 TABLE ACCESS FULL T_EVENT (cr=45566 pr=45562 pw=0 time=1721636 us cost=11090 size=173399751 card=6422213)

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file sequential read 8 0.04 0.07
asynch descriptor resize 16 0.00 0.00
db file scattered read 202 0.23 7.76
SQL*Net message from client 2 0.00 0.00
********************************************************************************

Instance on LeftHand SAN with FILESYSTEMIO_OPTIONS=SETALL

select count(*)
from
(SELECT CCL_NUM, PR_TRF_ID, PR_TIM_ID, SCHEME_ID, CCL_TIM_ID
from GMS.V_WP_CYCLETIMING)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.10 0.37 41 644 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 51.36 94.60 140435 68948 52 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 51.46 94.98 140476 69592 52 0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 SORT AGGREGATE (cr=0 pr=0 pw=0 time=25 us)
108509 108509 108509 VIEW V_WP_CYCLETIMING_RAW (cr=68948 pr=140428 pw=128470 time=97808970 us cost=230412 size=13388690 card=6694345)

108509 108509 108509 SORT GROUP BY (cr=68948 pr=140428 pw=128470 time=97769557 us cost=230412 size=930513955 card=6694345)
6518585 6518585 6518585 HASH JOIN RIGHT OUTER (cr=68948 pr=68934 pw=0 time=29068316 us cost=32525 size=930513955 card=6694345)
103 103 103 VIEW V_TRF_MAP (cr=2 pr=2 pw=0 time=14016 us cost=2 size=3605 card=103)
103 103 103 WINDOW BUFFER (cr=2 pr=2 pw=0 time=13806 us cost=2 size=2575 card=103)
103 103 103 TABLE ACCESS BY INDEX ROWID T_TRF_MAP (cr=2 pr=2 pw=0 time=13346 us cost=2 size=2575 card=103)
103 103 103 INDEX FULL SCAN T_TRF_MAP_PK (cr=1 pr=1 pw=0 time=5791 us cost=1 size=0 card=103)(object id 72130)
6518585 6518585 6518585 HASH JOIN RIGHT OUTER (cr=68946 pr=68932 pw=0 time=24707108 us cost=32488 size=696211880 card=6694345)
42 42 42 TABLE ACCESS FULL T_SCHEMEMAPPING (cr=6 pr=6 pw=0 time=49970 us cost=3 size=756 card=42)
6518585 6518585 6518585 HASH JOIN RIGHT OUTER (cr=68940 pr=68926 pw=0 time=19732952 us cost=32449 size=575713670 card=6694345)
8 8 8 TABLE ACCESS FULL T_CYCLEFREQUENCY (cr=6 pr=6 pw=0 time=49917 us cost=3 size=48 card=8)
6518585 6518585 6518585 HASH JOIN (cr=68934 pr=68920 pw=0 time=15793861 us cost=32411 size=535547600 card=6694345)
2319128 2319128 2319128 TABLE ACCESS FULL T_MEMBERSHIP (cr=23368 pr=23358 pw=0 time=1794753 us cost=5751 size=122892849 card=2318733)

6519357 6519357 6519357 TABLE ACCESS FULL T_EVENT (cr=45566 pr=45562 pw=0 time=1637949 us cost=11090 size=173399751 card=6422213)

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
db file sequential read 8 0.04 0.12
asynch descriptor resize 15 0.00 0.00
db file scattered read 202 0.10 5.52
direct path read 14 0.05 0.33
direct path write temp 2769 0.24 16.12
direct path read temp 1362 0.29 21.26
SQL*Net break/reset to client 1 0.00 0.00
SQL*Net message from client 1 7.59 7.59
********************************************************************************

我有同样的问题 显示 0 喜欢(0)
1102 查看 标签: 回复
平均用户评级: 无评分 (0 评级)平均用户评级无评分(0 评级)
您的评级: 评级 差(1,最高值为 5)评级 中下(2,最高值为 5)评级 中等(3,最高值为 5)评级 中上(4,最高值为 5)评级 优(5,最高值为 5)
1有用
1. Re: FILESYSTEMIO_OPTIONS = SETALL v ASYNCH Oracle11g on RHEL5 direct path read temp waits
User774969-Oracle
Explorer
User774969-Oracle 2011-6-28 下午11:26 (回复 johnlanc63)
Hi,
The execution plan looks same in all the cases. Only the elapsed time is different every time and not the CPU time.

In "Instance on LeftHand SAN with FILESYSTEMIO_OPTIONS=SETALL", the elapsed time is increased due to extensive sorting which
went to disk due to lack of PGA memory or inadequate pga settings.

You may need to increase the pga_aggregate_target and _pga_max_size.
Refer.Note.453540.1.

Regards
Bala
喜爱 显示 0 喜欢(0) 回复 操作
2. Re: FILESYSTEMIO_OPTIONS = SETALL v ASYNCH Oracle11g on RHEL5 direct path read temp waits
Tom321
Grand Master
Tom321 2015-6-2 上午10:47 (回复 johnlanc63)
Hi,

you can run the 10046 trace with level 8 to get details on the time each fetch takes. Compare the fetch time, multiblock count, io type, etc for your

different io strategy.

e.g.:

WAIT #18446744071523675328: nam='direct path read' ela= 4044 file number=1 first dba=225152 block cnt=128 obj#=107558 tim=25471670157341

What filesystem are you using? Is it enabled for async and direct io? Is async io enabled on os level?

Oracle Linux 5 - Filesystem & I/O Type Supportability (Doc ID 1601765.1)

How To Check if Asynchronous I/O is Working On Linux (Doc ID 237299.1)

Regards

Thomas

##############setting 3 pga 建议值是 5倍work area size,可以考虑加大生产的pGA

With the automatic PGA management mode, you can control the size for the work area sizes, to be able perform big sort operations or hash joins in memory

and avoid messages like:

kxhfWrite: hash-join is spilling to disk

You have to set the following parameters to proper values:

1. PGA_AGGREGATE_TARGET

should be set to five times the desired work area size

2. _PGA_MAX_SIZE

should be set in minimum of twice the desired work area size. The default value is 200Mb.

3. _SMM_MAX_SIZE

normally this parameter is not needed but maybe under certain circumstances
if set it should be equal to the desired work area size (in kb !)

Example:
If you like to use a sort area size of 1GB for a special operation (e.g for the creating of an index on a large table) you could set the values as follows:

PGA_AGGREGATE TARGET = 5G
"_PGA_MAX_SIZE" = 2G
"_SMM_MAX_SIZE" = 1048576

Dynamically, the values must be changed for the full instance using the "alter system" command. It is not allowed changes the above parameters for one

session.

Please note that there is an internal limitation that a single workarea size is limited to 2GB:

_PGA_MAX_SIZE is set up to 2GB (1GB limit for 32-bit) per bug 3946308

The fix for Bug 17951233 doesn't allow a work area to obtain more than 2 GBs. It simply prevents the session from failing with ORA-00600 [kcblin_3].

Also please be careful that the above changes are very dangerous because the values affect all sessions in the database. If you need to have granular

control of the work area for a single session, then it is better to set at the session level WORKAREA_SIZE_POLICY=MANUAL and *_AREA_SIZE as high as needed.

NOTE:
###step 5

模拟linux 删除linux 缓存,在执行,这说明,生产环境的数据库是没有用到操作系统的文件系统缓存, 而测试环境是用到了操作系统文件系统的缓存。已经提交SR ,增大

pga_aggregate_target size 从4G 到6G, 然后观察系统

[root@kfdb~]# echo 3 |sudo tee /proc/sys/vm/drop_caches
3

或者
[root@kfdb~]# echo 1 |sudo tee /proc/sys/vm/drop_caches
3

执行时间:
MERGE INTO SUNTX.RB_CBV_COM_CUPR_HIS T USING (SELECT * FROM (SELECT T.*, ROW_NUMBER() OVER(PARTITION BY T.CUPRCD, T.BEGNDT ORDER BY T.CUPRCD, T.BEGNDT

DESC) ROW_NUM FROM SUNTX.RB_CBV_COM_CUPR T) WHERE ROW_NUM = 1) L ON (T.CUPRCD = L.CUPRCD) WHEN MATCHED THEN UPDATE SET T.CUPRNA = NVL(L.CUPRNA, T.CUPRNA),

T.EASYCD = NVL(L.EASYCD, T.EASYCD), T.PYTXNO = NVL(L.PYTXNO, T.PYTXNO), T.ADDRES = NVL(L.ADDRES, T.ADDRES), T.TELENO = NVL(L.TELENO, T.TELENO), T.BANKNA =

NVL(L.BANKNA, T.BANKNA), T.ACCTNO = NVL(L.ACCTNO, T.ACCTNO), T.EMAILO = NVL(L.EMAILO, T.EMAILO), T.SMRYTX = NVL(L.SMRYTX, T.SMRYTX), T.BEGNDT = NVL

(L.BEGNDT, T.BEGNDT), T.ENDDDT = NVL(L.ENDDDT, T.ENDDDT), T.STATUS = NVL(L.STATUS, T.STATUS), T.BODYTP = NVL(L.BODYTP, T.BODYTP), T.CONTTG = NVL(L.CONTTG,

T.CONTTG), T.ADDREE = NVL(L.ADDREE, T.ADDREE), T.RECVAD = NVL(L.RECVAD, T.RECVAD), T.RECVPH = NVL(L.RECVPH, T.RECVPH), T.CUPREN = NVL(L.CUPREN, T.CUPREN),

T.ORVATSI = NVL(L.ORVATSI, T.ORVATSI), T.CUPRTP = NVL(L.CUPRTP, T.CUPRTP), T.IDNUMB = NVL(L.IDNUMB, T.IDNUMB), T.INVATO = NVL(L.INVATO, T.INVATO),

T.SYSTEMID = NVL(L.SYSTEMID, T.SYSTEMID) WHEN NOT MATCHED THEN INSERT (CUPRCD, CUPRNA, EASYCD, PYTXNO, ADDRES, TELENO, BANKNA, ACCTNO, EMAILO, SMRYTX,

BEGNDT, ENDDDT, STATUS, BODYTP, CONTTG, ADDREE, RECVAD, RECVPH, CUPREN, ORVATSI, CUPRTP, IDNUMB, INVATO, SYSTEMID) VALUES (L.CUPRCD, L.CUPRNA, L.EASYCD,

L.PYTXNO, L.ADDRES, L.TELENO, L.BANKNA, L.ACCTNO, L.EMAILO, L.SMRYTX, L.BEGNDT, L.ENDDDT, L.STATUS, L.BODYTP, L.CONTTG, L.ADDREE, L.RECVAD, L.RECVPH,

L.CUPREN, L.ORVATSI, L.CUPRTP, L.IDNUMB, L.INVATO, L.SYSTEMID)

从1分钟增大到3分钟

################

#####发现1:
SQL>set pagesize 999
SQL>/

TBS_NAME TOTAL_GB ALLOTED_GB USED_GB PCT_USED
------------------------------------------------------------ ---------- ---------- ----------

------------------------------------------------------------------------------------
TEMP 32 4 .01 .03 %
SUNTX_TEMP 42 32.8145 0 0 %

dev:

select count(*) from SUNTX.RB_CBV_COM_CUPR;
COUNT(*)
----------
3886

prod:
SQL> select count(*) from SUNTX.RB_CBV_COM_CUPR;

COUNT(*)
----------
2553181

RB_CBV_COM_CUPR

AWR实战分析之----direct path read temp的更多相关文章

  1. AWR实战分析之---- PX Deq Credit: send blkd (转载)

    该等待事件我在前面分析过,但是这次和上次产生的原因有些不一样,上次该等待事件的详细分析链接是:http://blog.sina.com.cn/s/blog_61cd89f60102eeen.html  ...

  2. direct path read temp的处理方法

    Examine the SQL statement currently being run by the session experiencing waits to see what is causi ...

  3. Oracle的AWR报告分析

    * 定义:awr报告是oracle 10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告 ...

  4. AWR报告分析

    AWR报告分析 awr报告是oracle 10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体 ...

  5. direct path read/write (直接路径读/写)

    转载:http://www.dbtan.com/2010/04/direct-path-readwrite.html direct path read/write (直接路径读/写): 直接路径读(d ...

  6. 理论实践:循序渐进理解AWR细致入微分析性能报告

    1. AWR 概述 Automatic Workload Repository(AWR) 是10g引入的一个重要组件.在里面存贮着近期一段时间内(默认是7天)数据库活动状态的详细信息. AWR 报告是 ...

  7. (转)【深度长文】循序渐进解读Oracle AWR性能分析报告

    原文:https://dbaplus.cn/news-10-734-1.html https://blog.csdn.net/defonds/article/details/52958303 作者介绍 ...

  8. 没有索引导致的DIRECT PATH READ

    5月20号下午4-5点,某项目组进行数据入库作业,作业人员反映入库速度很慢.在16:30和16:50分别采集了快照,并根据两个快照得到AWR报告. 直接看TOP 5 EVENTS,这是数据库问题诊断的 ...

  9. direct path read

    在11g中,全表扫描可能使用direct path read方式,绕过buffer cache,这样的全表扫描就是物理读了. 在10g中,都是通过gc buffer来读的,所以不存在direct pa ...

随机推荐

  1. ACM学习历程—HDU 4726 Kia's Calculation( 贪心&&计数排序)

    DescriptionDoctor Ghee is teaching Kia how to calculate the sum of two integers. But Kia is so carel ...

  2. ACM学习历程—FZU 2140 Forever 0.5(计算几何 && 构造)

    Description   Given an integer N, your task is to judge whether there exist N points in the plane su ...

  3. 【Lintcode】136.Palindrome Partitioning

    题目: Given a string s, partition s such that every substring of the partition is a palindrome. Return ...

  4. YPBPR_PC下图像有毛刺或者水纹干扰的处理办法

    VGA下一般是不做任何处理的,当然也不排除个别情况下,客户强烈要求,会打开的现象. (1)做一下auto color和auto adjust (2)调节一下ADC,如果是mstar的方案,将对比机的的 ...

  5. SpringMVC之一:SpringMVC原理

    Spring MVC工作流程图   图一   图二  关键组件: DispatcherServlet:前端控制器,与大多数基于Java的Web框架一样, Spring MVC所有的请求都会通过一个前端 ...

  6. CSharp读取配置文件的类(简单实现)

    Reinventing the wheel 系列 CSharp 读取配置文件的类 简单实现(注意没有写) 本人对CS 不是很熟,库也不熟,所以到网上找个实现,并自己添加了点异常.如果只是读取信息,足够 ...

  7. SQL DBA 学习

    http://www.cnblogs.com/CareySon/category/389500.html SQL Pass(13) SQL SERVER(42) SQL Server DBA生涯(1) ...

  8. MFC编辑框数据实时更新问题

    在VC里,很多情况下需要更新控件,也就是调用UpdateData(FALSE);但是如果是在循环中调用该函数,会导致没有时间来刷新界面,消息得不到相应,从外部看来,似乎整个循环只执行了一次Update ...

  9. 获得用户IP、城市、国家等信息的api接口

    1 这个信息比较多 https://api.ipdata.co/?api-key=test <script> $.get("https://api.ipdata.co?api-k ...

  10. linux命令之curl,wget

    curl由于可自定义各种请求参数所以在模拟web请求调试网页方面更擅长:wget由于支持ftp和Recursive所以在下载文件方面更擅长.类比的话curl是浏览器,而wget是迅雷9. 在下载上,也 ...