OBJECT_ID 和 DATA_OBJECT_ID 坑人的区别

今天遇到一个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 。