今天查看数据库的alert日志总出现了如下的警告。 Archived Log entry 202 added for thread 1 sequence 202 ID 0x1ed7a02c dest 1: Sat Mar 15 01:37:30 2014 Completed checkpoint up to RBA [0xca.2.10], SCN: 267711453 Sat Mar 15 01:44:58 2014 Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing  ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 67108864 bytes. Both ASH size and the total number of emergency flushe s since instance startup can be monitored by running the following query:  select total_size,awr_flush_emergency_count from v$ash_info; Sat Mar 15 01:45:00 2014 Beginning log switch checkpoint up to RBA [0xcc.2.10], SCN: 270149004 Thread 1 advanced to log sequence 204 (LGWR switch)   Current log# 4 seq# 204 mem# 0: /TEST1/db03/oradata/PRDTEST1/redo_g4_m1.dbf   Current log# 4 seq# 204 mem# 1: /TEST1/db04/oradata/PRDTEST1/redo_g4_m2.dbf Sat Mar 15 01:45:11 2014 ash的size大小设置是隐含参数_ash_size中设置的。查看metalink( 文档 ID 1385872.1)

CAUSE

Typically some activity on system causes more active sessions, therefore filling the ASH buffers faster than usual causing this message to be displayed. It is not a problem per se, just indicates the buffers might need to be increased to support peak activity on the database.

SOLUTION

The current ASH size is displayed in the message in the alert log, or can be found using the following SQL statement.

Then increase the value for _ash_size by some value, like 50% more than what is currently allocated.  For example if total_size = 16MB, then an increase of 50% more would be (16MB + (16MB * 50%)) = 24MB. 

You can verify the change using the following select:

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1123071/，如需转载，请注明出处，否则将追究法律责任。