我ORACEL老报告LATCH FEE太多？造成CPU使用率居高不下。

Question

shared_pool_size 多大？是不是太大了？几百M ?db_block_lru_latches    又是多少？你cpu又是几个？数据库多大？
data  buffer 又多大?

Answer 1

把你数据库的具体情况列出来
特别是db_block_lru_latches，cpu个数，
db_writer_processes，db_block_buffers
是否分配了keep,recycle池
否则，没有办法帮你诊断

Answer 2

db_block_lru_latches 估计不少
继续关注

Answer 3

open_cursors = 300
max_enabled_roles = 30
db_block_buffers = 450000shared_pool_size = 1147483648large_pool_size = 52428800
java_pool_size = 0log_checkpoint_interval = 100000000
log_checkpoint_timeout = 3600processes = 1000log_buffer = 1638400 log_archive_start = true
 log_archive_dest_1 = "location=/arcive"
 log_archive_format = arch_%t_%s.arc
db_block_size = 8192remote_login_passwordfile = exclusiveos_authent_prefix = ""compatible = "8.1.7"
sort_area_size = 131072 
sort_area_retained_size = 65536
hash_area_size = 131072
db_writer_processes = 4
log_archive_max_processes = 4
db_file_multiblock_read_count = 32
job_queue_processes = 3
cursor_space_for_time = true
session_cached_cursors = 10
db_block_lru_latches = 12 
optimizer_mode  = rule
cursor_sharing = force主机为P680-S85双机，12*600MHz，12GB内存，4*18GB硬盘，3*FC，2*GE
数据库数据200GB左右

Answer 4

shared_pool_size  请修改为200M95%的可能是因为这个参数太大cursor_sharing = force
你们没有使用 bind var? hard parsing 太多？设置这个参数并不是很好的选择java_pool_size = 0 建议修改为30M
移动的 BOSS 系统?随便猜的，呵呵。别介意optimizer_mode  = rule
你们都跑 rule  base 呀？

Answer 5

db_writer_processes最好等于db_block_lru_latches 
shared_pool_size = 1147483648太大了吧
12G的内存，对比来说，data buffer太小了，才300多M

Answer 6

db_writer_processes<=db_block_lru_latches 但到底是多少，只要>1,就需要你的os的异步IO的支持，还有你的cpu数据和 磁盘控制器、IO通道等决定是3G多不是0.3G ，呵呵
如果没有其他东西跑在服务器上，可以增大一倍以上

Answer 7

本来不是RULE BASE,不过为了好调试改的,java_pool_size = 0是因为没有用JAVA

Answer 8

呵呵，少看了一个０
－－－－－－－－－－－－－－－－－－
optimizer_mode  = rule不是大问题
但是建议不要修改这个参数，没有必要．
没有用JAVA，java_pool_size = 0也可以的主要调整
shared_pool_size 
db_writer_processes
db_block_lru_latches

Answer 9

hehe 我说这个系统感觉有点眼熟？听朋友提到过这个系统
weblogic + oracle 不是说不敢使用 cursor_sharing 么