老大帮我看看我的statspack report.

doctest

redo size和redo wastage是什么关系呢?


Physical Reads  Executions  Reads per Exec % Total  Hash Value
--------------- ------------ -------------- ------- ------------
         80,916           35        2,311.9     0.0   1243992060
SELECT COUNT(*)  FROM "DATA0006"

统计个数怎么也会有这么多的Physical Reads?

问题多,都有点不好意思了
幸亏脸皮比较厚

biti_rainy

因为日志文件在写入的时候，block并不一定是满的
可能在lgwr写的时候是不满的
redo size是实际写入的字节数，而wastage就是空的那部分的字节数
由于每个日志块头还有 16字节的头信息

所以，就存在 redo size + wastage = (log_block_size - 16) * blocks

至于 Physical Reads
执行 35次有这么多读，每次 2311.9* db_block_size ,如果block 是8k，也就不到20M   

doctest

最初由 machao 发布
[B]你做每隔10分钟做一个report,做二到三个传上来看看. [/B]

11:18:11 ~ 11:36:36



帮忙看看

doctest

谢谢

12:17:17 ~ 12:27:32

doctest

最初由 biti_rainy 发布
[B]因为日志文件在写入的时候，block并不一定是满的
可能在lgwr写的时候是不满的
redo size是实际写入的字节数，而wastage就是空的那部分的字节数
由于每个日志块头还有 16字节的头信息

所以，就存在 redo size + wastage = (log_block_size - 16) * blocks

至于 Physical Reads
执行 35次有这么多读，每次 2311.9* db_block_size ,如果block 是8k，也就不到20M    [/B]

解释的太清楚了
鼓掌

machao

从你的报告中看,
1.建议你尽快将日志文件大小进行更改,它导致了太多的等待.
2.你有4G物理内存,但SGA只用了1.1G,建议你加大db_block_buffer=200000
3.你的系统中有太多的全表扫描,每5秒就有一个大表扫描.
   table scans (long tables)                      212          0.2          0.1

4.你的部分SQL有问题.
例如:

  Buffer Gets    Executions  Gets per Exec  % Total  Hash Value
--------------- ------------ -------------- ------- ------------
      3,402,478           26      130,864.5    19.0   1726112114
SELECT    Data0006.RKEY as Data0006RKEY,    Data0006.WORK_ORDER_
NUMBER as Data0006WORK_ORDER_NUMBER,    Data0006.BASE_WO as Data
0006BASE_WO,    Data0010.ABBR_NAME as Data0010ABBR_NAME,    Data
0050.CUSTOMER_PART_NUMBER as Data0050CUSTOMER_PART_NUMBER,    Da
ta0006.BOM_REV_NO as Data0006BOM_REV_NO,    Data0050.CP_REV as D


Buffer Gets    Executions  Gets per Exec  % Total  Hash Value
--------------- ------------ -------------- ------- ------------
      4,788,920            1    4,788,920.0    62.1   2739091907
INSERT INTO MISCODE.XH_LIST_GW ( DEPT_CODE, DEPT_NAME, INV_PART_
NUMBER, INV_PART_DESCRIPTION, UNIT_CODE, STD_COST, QUANTITY, REF
ERENCE_NUMBER, TRAN_DATE, TRAN_TP ) SELECT DISTINCT ADMIN.Data00
34.DEPT_CODE, ADMIN.Data0034.DEPT_NAME, ADMIN.Data0017.INV_PART_
NUMBER, ADMIN.Data0017.INV_PART_DESCRIPTION, ADMIN.Data0002.UNIT

他们导致了太多的读操作,你最好能将这种语句进行调整,降低整个IO的吞吐量.

doctest

谢谢!谢谢!
马上动手!

tim_wong

SQL ordered by Executions for DB: CNCL  Instance: CNCL  Snaps: 786 -787
-> End Executions Threshold:     100

Executions   Rows Processed    Rows per Exec   Hash Value
------------ ---------------- ---------------- ------------
         585              585              1.0    536523591
INSERT INTO WWIPTEMP( "NO", "PO_NUMBER", "WO", "WO2", "SALES_ORD
ER", "CUST_CODE", "CUSTOMER_PART_NUMBER", "CP_REV", "QUAN_SCH",
"PARTS_ORDERED", "QTY_REJECTED", "SCH_COMPL_DATE", "CT", "PROD_C
ODE", "PARTS_PER_PANEL", "LAYER", "BASE_WO", "TYPE", "SCH_DATE",
"ENT_DATE", "PC_NO", "REL_DAYS" VALUES (:1,:2,:3,:4,:5,:6,:7,:

crpp0902

看了一些文章，上面都说：
“响应时间(response time) = 运行时间(service time) + 等待时间(wait time)
其中运行时间为程序实际运行在CPU上的时间，即实际的CPU服务”
可是分析STATSPACK报表的时候这么从报表中得到运行时间跟等待时间呢？？

doctest

最初由 machao 发布
[B]3.我看过你的report,基本上是磁盘IO很重,可能与索引,sql有关. [/B]

请问从哪些statistics看出"磁盘IO很重"呢?

谢谢!