这是我的一个statspack的REPORT,怎高手帮忙分析一下问题

husthxd

系统是什么应用?

                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
Begin Snap:          1 17-3月 -05 15:13:53      15
   End Snap:          2 17-3月 -05 15:29:30      15
    Elapsed:                  15.62 (mins)

时间间隔太短.

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write                            17,802        4,197   69.27
log file sync                                         400          696   11.49
db file scattered read                             77,132          333    5.50
db file sequential read                             8,577          276    4.56
latch free                                            140          224    3.70

关于等待事件log file parallel write  :

You might want to reduce "log file parallel write" wait times in order to reduce user waits which depend on LGWR.
•        Ensure tablespaces are NOT left in HOT BACKUP mode longer than needed.
Tablespaces in HOT BACKUP mode cause more redo to be generated for each change which can vastly increase the rate of redo generarion.
•        Redo log members should ideally be on high speed disks
eg: RAID5 is not a good candidate for redo log members.
•        Redo log members should be on disks with little/no IO activity from other sources.
(including low activity from other sources against the same disk controller)
•        RAW devices can be faster file system files.
•        NOLOGGING / UNRECOVERABLE operations may be possible for certain operations to reduce the overall rate of redo generation

hzh_hu

db_buffer和library cache命中率太低，建議增加兩者之內存，redo log等待太嚴重，應該增加log_checkpoint_interval間隔時間，至於加多少，那要看你的應用了，自己慢慢試吧

anchen211

最初由 husthxd 发布
[B]系统是什么应用?

                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
Begin Snap:          1 17-3月 -05 15:13:53      15
   End Snap:          2 17-3月 -05 15:29:30      15
    Elapsed:                  15.62 (mins)

时间间隔太短.

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write                            17,802        4,197   69.27
log file sync                                         400          696   11.49
db file scattered read                             77,132          333    5.50
db file sequential read                             8,577          276    4.56
latch free                                            140          224    3.70

关于等待事件log file parallel write  :

You might want to reduce "log file parallel write" wait times in order to reduce user waits which depend on LGWR.
•        Ensure tablespaces are NOT left in HOT BACKUP mode longer than needed.
Tablespaces in HOT BACKUP mode cause more redo to be generated for each change which can vastly increase the rate of redo generarion.
•        Redo log members should ideally be on high speed disks
eg: RAID5 is not a good candidate for redo log members.
•        Redo log members should be on disks with little/no IO activity from other sources.
(including low activity from other sources against the same disk controller)
•        RAW devices can be faster file system files.
•        NOLOGGING / UNRECOVERABLE operations may be possible for certain operations to reduce the overall rate of redo generation [/B]

每隔５分钟接收一批计费信息并由程序入库，计费信息放在一个分区表中，两三天的记录就有二，三百万条，我将此分区表导出后，导出文件就有３Ｇ之大．应该是写操作比较频繁，也用一些读操作，只是用户做查询用．应该不多．

husthxd

呵呵,先把db buffer增大看看把.
3g的内存,db buffer也太小了.

anchen211

最初由 husthxd 发布
[B]呵呵,先把db buffer增大看看把.
3g的内存,db buffer也太小了. [/B]

我想现在应该是重在过程，多点分析，让我能看明白，呵呵！

jametong

最初由 anchen211 发布
[B]

每隔５分钟接收一批计费信息并由程序入库，计费信息放在一个分区表中，两三天的记录就有二，三百万条，我将此分区表导出后，导出文件就有３Ｇ之大．应该是写操作比较频繁，也用一些读操作，只是用户做查询用．应该不多． [/B]

我觉得关键要看看你的应用, 加载数据是不是有别的方法啊.

这么大的数据量, 是不是可以考虑修改加载程序啊.

anchen211

最初由 husthxd 发布
[B]呵呵,先把db buffer增大看看把.
3g的内存,db buffer也太小了. [/B]

主要影响如下:
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:  100.00
            Buffer  Hit   %:   62.14    In-memory Sort %:   99.75
            Library Hit   %:   78.76        Soft Parse %:   16.25
         Execute to Parse %:   59.61         Latch Hit %:  100.00
Parse CPU to Parse Elapsd %:   86.60     % Non-Parse CPU:   99.62

Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:    4.39   90.30
    % SQL with executions>1:   46.27    1.94
  % Memory for SQL w/exec>1:   34.18    0.99

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write                            41,779        4,575   67.04
latch free                                            301          647    9.48
log file sync                                         634          621    9.10
db file scattered read                             94,405          464    6.80
db file sequential read                             7,109          239    3.50
          -------------------------------------------------------------

另附完整的REPORT,各位可以跟踪整个过程,并提出更好的建议.

anchen211

最初由 husthxd 发布
[B]呵呵,先把db buffer增大看看把.
3g的内存,db buffer也太小了. [/B]

调整前的db_block_buffer：2048，db_block_size：8K 只有16M，太小
现将db_block_buffer调整到：4096

我观察主要的参数
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:  100.00
            Buffer  Hit   %:   62.14    In-memory Sort %:   99.75
            Library Hit   %:   78.76        Soft Parse %:   16.25
         Execute to Parse %:   59.61         Latch Hit %:  100.00
Parse CPU to Parse Elapsd %:   86.60     % Non-Parse CPU:   99.62

Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:    4.39   90.30
    % SQL with executions>1:   46.27    1.94
  % Memory for SQL w/exec>1:   34.18    0.99

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write                            41,779        4,575   67.04
latch free                                            301          647    9.48
log file sync                                         634          621    9.10
db file scattered read                             94,405          464    6.80
db file sequential read                             7,109          239    3.50
          -------------------------------------------------------------


可以看到TOP5的第一项有了没有反而增加了,是无效?还是应继续增大db_block_buffer?
另附完整的REPORT,各位可以跟踪整个过程,并提出更好的建议.

fei_mcd

调整前的db_block_buffer：2048，db_block_size：8K 只有16M，太小
现将db_block_buffer调整到：4096
-------------------------------------------------------------------------------------------------------------------------
从16M改到32M也算是进步吧
不过你的内存3G也对oracle太小气了吧?
应该db_block_buffer=128000  这样 oracle的data cache 就有 1G
甚至db_block_buffer=256000  这样 oracle的data cache 就有 2G
不过说实话,如果你的数据库并行查询的人不多,只是计费
或者db_block_buffer=64000  这样 oracle的data cache 就有 512M
如果该服务器还跑别的应用,512M也是够用的

husthxd

db_block_buffer：2048
改为204800还差不多

另外:
你只是把statspack报告上传上来,但客户有感觉到系统慢吗?
慢在什么地方?