1、redo log buffer：
當時常遇到較大的事務時，增大log buffer可以減少不必要的log file I/O操作。commit操作將會flush log buffer，頻繁的commit可以考慮較小的buffer size。log_buffer最小為64K。
①對redo log buffer的診斷：
** 查看動態視圖：v$session_wait查看當前是否正有對log buffer的請求等待。
select sid, event, seconds_in_wait, state from v$session_wait where event = ‘log buffer space%’;
** 計算redo buffer allocation的重試的出現概率，此值應該盡量接近0，不應該大于1%，如果該值不斷增加，說明大量對redo log buffer的等待。
select name, value from v$sysstat where name = ‘redo buffer allocation retries’; –顯示了user 進程等待log buffer中的space所重試的次數。
select name, value from v$sysstat where name = ‘redo log space requests’;
引起等待的原因可能是由于log buffer過小，或是checkpoint，或是log switching所致。
對此，可以嘗試：增大log_buffer的值；或是改善checkpoint或歸檔進程。
** SECONDS_IN_WAIT值顯示的是除了由于log swith以外造成的log buffer等待的時間。它表明redo buffer被寫滿的速度要大于LGWR寫logfile的速度。也可能反映在redo logfile上的I/O存在沖突。
如果懷疑是LGWR的問題，可以繼續查看：
@@ 是否存在I/O沖突，是否redo log file存放在分開的快速存儲設備上。
@@ 查看日志切換的次數，考慮是否是切換太頻繁，是否需要增大log file 的size。
select event, total_waits, time_waited, average_wait from v$system_event where event like ‘log file switch completion%’;
@@ 如果DBWn在尚未完成checkpointing file時，LGWR在此需要相應的文件時，會引起LGWR的等待。對此可以從alert.log文件中查看到相關信息。查看當前是否有未完成的checkpoint事件：
select event, total_waits, time_waited, average_wait from v$system_event where event like ‘log file switch (check%’;
查看參數LOG_CHECKPOINT_INTERVAL和LOG_CHECKPOINT_TIMEOUT是否恰當；并查看redo log file的size和group數。
@@ 如果歸檔進程不能及時的將redo logfile，也可能會引起LGWR的寫入等待。
對此，先確認歸檔目錄沒有滿，適當增加redo log 的groups。下面的SQL顯示了由于歸檔問題引起的log file switch等待統計。
select event, total_waits, time_waited, average_wait from v$system_evnet where event like ‘log file switch (arch%’;
可以適當增大參數LOG_ARCHIVE_MAX_PROCESSES從而在大負荷量時增多歸檔進程。
@@ 如果將DB_BLOCK_CHECKSUM設置為true，會因此增加性能上的開支。
此外，盡可能減少redo的操作：
** 直接路徑的loading在非歸檔模式下，是不記錄redo log的
** 在歸檔模式下，直接路徑的loading可以使用nologging mode
** 直接insert也可使用nologging mode
** 部分sql可以使用nologging mode
但要明確，即使對table、index、tablespace使用nologging模式，但對于部分操作仍然會產生redo log。如create table … as select; create index … ; alter index … rebuild;
此外，nologging屬性對update, delete, 常規路徑的insert和各種DDL語句是不會起作用的。（這里貌似對insert添加hint也可以使其nologging）
2、監控Java池內存：select * from v$sgastat where pool = ‘java pool’;
1）用于限制Java session占用的內存的初始參數：
①JAVA_SOFT_SESSIONSPACE_LIMIT：當user session的java命令占用的內存超過該設置，將會發出warning，在跟蹤文件做一定的記錄，默認為1M。
②JAVA_MAX_SESSIONSPACE_SIZE：當user session的java命令占用內存超過該值，該session將被kill掉，默認為4G。
2）為Java Sizing SGA
①每裝載一個class，java引擎會使用8KB shared pool的內存，當裝載并處理大的jar files時，可占用50MBshared pool的內存。
②java pool是SGA中的一個組成部分，用于所有存在java code或是在EJE中存在數據的session中。instance startup時，會分配JAVA_POOL_SIZE指定大小的內存。一般會設置為50MB左右，默認是20MB。
3、multiple I/O slave：
4、multiple DBWR 進程
1） 多DBWn進程可以使用DB_WRITER_PROCESSES參數控制。它對于多cpu的SMP系統較有效。但是multiple DBWR與multiple I/O slave是不能同時使用的。
2）對其的調節：
select event, total_waits, time_waited from v$system_event where event=’free buffer waits’;
如果發現上述的SQL的total_waits是較大，可以考慮將增加DBWn進程的數量。