今天遇到一個case，具體內容就是一個非常簡單的語句，但是返回結果非常的慢。語句如下
Select count(*) from OTSADMIN.QC_TS_EVENT where create_dt>=to_date('2012 APR 01','YYYY MON DD');
分析了一下這個語句非常簡單，可爲什麼這麼慢呢，猜想也許是有wait，於是就10046 trace一下。
alter session set events '10046 trace name context foreve, level12';
trace 的過程中用 tail -f 去實時的跟蹤trace文件發現有很多這樣的等待。
WAIT #7: nam='free buffer waits' ela= 10719 file#=11 block#=6208 set-id#=6 obj#=0 tim=1305050069528068
WAIT #7: nam='free buffer waits' ela= 10711 file#=11 block#=6208 set-id#=6 obj#=0 tim=1305050069538808
WAIT #7: nam='free buffer waits' ela= 10716 file#=11 block#=6208 set-id#=6 obj#=0 tim=1305050069549548
WAIT #7: nam='free buffer waits' ela= 10718 file#=11 block#=6208 set-id#=6 obj#=0 tim=1305050069560290
這樣看來是data buffer不夠用了啊。可是爲啥就不夠用了呢，我先看了一下alert 發現很多這樣的信息
Thread 1 cannot allocate new log, sequence 7912
Checkpoint not complete
哦， 原來是日誌沒法switch。 一般來講如果總有這種錯誤的話，就說明這個DB的redo log設置不合適。 說明對這個DB的吞吐量沒有合理的分析。DB的吞吐量大，就要頻繁的寫redo log，就會頻繁的導致redo 切換。 在redo切換的時候，要確保目標redo中的數據已經完全寫入data file了。但如果alert中總是出現上面的信息的話，這就說明了alert 切換的速度比 redo 寫入data file的速度快太多。解決辦法就是增加redo 或者增加redo group的個數，也就是增加這個緩衝。
這是一種解決辦法。但是要注意一點是，alert中是不是總有這種信息，如果總有的話自然是說明db 吞吐量大，需要修改redo 的配置，如果是偶爾纔有的話，就說明是特例了。這時也許是db中發生了什麼不合理的操作，這樣解決的方向就不應該是修改redo配置了，而是檢查db，找出問題。 檢查的過程如下：
既然是 data buffer總是滿，那麼就看一下哪些數據對象在佔用data buffer吧。
SQL> select count(*) as num , objd from v$bh group by objd order by num;
NUM OBJD
---------- ----------
1389 574
1936 90035
2013 90033
2051 90034
3379 90030
4542 90032
9908 4294967295
12730 90031發現了這些OBJD佔用的data buffer應該很多。 於是就去查這些objd是什麼。
SQL> select object_name,object_type,owner from dba_objects where object_id=90031;
no rows selected結果沒查到，這很是迷糊
去ITPUB提問，經過牛人 vaga（http://www.itpub.net/space-uid-321157.html） 指導，明白了這些OBJD代表的是DATA_OBJECT_ID而不是object_id，data_object_id是segment的id。
於是轉而用 DATA_OBJECT_ID來查，果然查到了是那些數據對象佔用data buffer。
查到了這些數據對象就好辦了。根據v$lock查找到是那些SESSION 那些SQL在使用這些對象，然後就知道爲啥會使用那麼多的data buffer 。