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进程的数量。