第一种方法最简单，也最不准确，就是直接查询sql_text

select * from v$sql where lower(sql_text) like ‘%TABLE_NAME%’

最不准确是因为他有几个问题：
1. table_name可能会被折行，这样like就无法被匹配
2. 可能存在表名一样，但是owner不一样的情况
3. 如果用户查询的是view或者synonym，SQL语句中没有真实的表名，这种方法也无法显示

使用这种方法主要是在当你要查询某个已知SQL的统计信息的时候。

第二种方法是通过查询v$sql_plan

select * from v$sql where hash_value in (select hash_value from v$sql_plan where object_owner=’xxx’ and object_name=’TABLE_NAME’);

SQL被分析后，执行计划会被存储在v$sql_plan中，object_name就是执行计划里面的name那一列。这种方法可以避免上面所说的三个问题。

但是这个方法也有个问题，就是当SQL执行计划中没有查询表的时候，SQL不会被显示，例如下面SQL的执行计划中没有表名，只有索引名

这时候查询表名是得不到该SQL的，必须查询索引名字。所以你可以稍微修改一下，将表名和索引名都加到object_name中：

select * from v$sql where hash_value in (select hash_value from v$sql_plan where
object_owner=’xxx’ and object_name in (‘TABLE_NAME’,'INDEX1_NAME’,'INDEX2_NAME’,…));

另外这种方法也可以用于查询哪些SQL使用了改索引

第三种方法是查询 v$object_dependency表

select * from v$sql where hash_value in (select FROM_HASH from v$object_dependency where TO_OWNER=’table owner’ and TO_NAME=’table name’);

这种方法应该是比较准确的，即使SQL中使用了view或者synonym，该方法还是可以找到SQL。 但是它不支持第二种方法的索引查询，dependency关系只是和表有关。

对于不同的CPU,core factor是不一样的，可以从oracle提供的这张列表中查到 Oracle Processor Core Factor Table。

首线我们要知道CPU的类型，以solaris T5240为例：

1. $>psrinfo -pv
The physical processor has 64 virtual processors (0-63)
UltraSPARC-T2+ (chipid 0, clock 1415 MHz)
The physical processor has 64 virtual processors (64-127)
UltraSPARC-T2+ (chipid 1, clock 1415 MHz)

CPU类型为 UltraSPARC-T2+

2. 查询core factor table得到T2+对应的系数为0.5

3. 查询core的数目

kstat -m cpu_info 可以显示CPU的信息，在linux下可以直接cat /proc/cpuinfo

如果threads比较多，可以用这个脚本来解析

http://blogs.oracle.com/mandalika/entry/solaris_show_me_the_cpu

$>showcpucount
Total number of physical processors: 1
Number of virtual processors: 64
Total number of cores: 8
Number of cores per physical processor: 8
Number of hardware threads (strands or vCPUs) per core: 8
Processor speed: 1415 MHz (1.41 GHz)

** Socket-Core-vCPU mapping **

Physical Processor 1 (chip id: 0):
Core 1 (core id: 260):
vCPU ids: 0 – 7
Core 2 (core id: 267):
vCPU ids: 8 – 15
Core 3 (core id: 274):
vCPU ids: 16 – 23
Core 4 (core id: 281):
vCPU ids: 24 – 31
Core 5 (core id: 288):
vCPU ids: 32 – 39
Core 6 (core id: 295):
vCPU ids: 40 – 47
Core 7 (core id: 302):
vCPU ids: 48 – 55
Core 8 (core id: 309):
vCPU ids: 56 – 63

4. number of cores * core factor = oracle license

8*0.5 =4

再选了几个手头上的机器算了下（1*8 表示1个CPU，每个CPU8个core)：

Bug 10082277 Excessive allocation in PCUR or KGLH0 heap of “kkscsAddChildNo” (ORA-4031)
This note gives a brief overview of bug 10082277.
The content was last updated on: 26-AUG-2011
Click here for details of each of the sections below.
Affects:

Range of versions believed to be affected Versions BELOW 12.1
Versions confirmed as being affected

11.2.0.2
11.2.0.1

Platforms affected Generic (all / most platforms affected)

Fixed:

This issue is fixed in

12.1 (Future Release)
11.2.0.3 (Future Patch Set)
11.2.0.2.3 Patch Set Update
11.2.0.2 Bundle Patch 4 for Exadata Database
11.2.0.2 Patch 2 on Windows Platforms
11.2.0.1 Patch 11 on Windows Platforms

Description

Under certain circumstances the “perm” space in PCUR subheaps (11.2.0.1)
or KGLH0 subheaps (11.2.0.2) for cursors in the shared pool may continue
to grow over time with continual additions of memory of the type
“kkscsAddChildNo”.

Over time this can use excessive shared pool memory , even leading
to ORA-4031 errors.

Rediscovery Notes:
A heapdump of the SGA will show one or more very large
subheaps with a name of the form “PCUR^xxxx” or “KGLH0^xxxx”.
Within this subheap there is lots of “perm” space allocated.
If CPRM tracing is enable (event 10235 level 65536) then
the subheap dump shows the perm space as due to “kkscsAddChildNo”
allocations of memory.

Workaround
This issue requires that there is a lack of sharing of the
parent cursor. Hence a workaround, where possible, is to
address the reason for not sharing the parent cursor.
(eg: Check V$SQL_SHARED_CURSOR for why the parent is not
being shared).

该问题在我们的系统上表现为

1. 单个SQL占用了大量的shared pool memory, 这个例子中单个SQL就占用了1.7GB的shared pool memory

而在10.2.0.4的数据库上，同样的SQL只占用了4M左右大小的内存

2. 大部分的内存都被parent cursor (cursor id为65535)占用了

通过Tanel的脚本curheaps.sql 可以查看各个child cursor的大小

另外该问题只发生在client的jdbc driver升级到11g以后，jdbc driver为10g的时候没有这个问题，估计和shared cursor sharing有关系。

SQL的 parent cursor不断增长一方面会使得shared pool的内存耗尽，另外如果发生hard parse耗时非常严重，可能会导致大量的和parse相关的等待时间，例如“cursor: mutex S”。

Oracle有相关的patch可以下载，打上patch后问题解决。

工作原理是用flash card做为数据库的二级cache,没有被修改过的数据块从db cache中被age out的时候,写入到flash cache中. 如果需要再次读取,可以从flash cache中读取,避免了从磁盘读取. 适用于存在大量db file sequential read的数据库.

在公司内做的一个分享,slides已经upload到www.slideshare.net

如果有同学不熟悉，可以参考这篇文章exchange partition。

灵活运用这一功能，可以解决很多问题。上周我们利用exchange partition成功的将range partition表转为range hash partition表。

事件背景如下：

Range分区的日志表，大小为1.6T， 每天写入一个分区，每天truncate下一个分区给第二天的数据使用，33个数据分区循环使用再加一个Partmax分区。

问题是Insert操作太多，在高峰时段达到每秒钟近700次，出现大量的HW enqueue，导致数据库不稳定。

解决问题的方法：

将Range分区表转换为Range-Hash分区表，partition level range分区的方法不变，在subpartition level按照primary key ID值做hash分区。这样每个分区上的insert操作大大降低。

传统的方法是用Online Redefinition，但是用online redefinition的问题是需要大量的临时空间来存储中间表，并且准备时间太长。

而利用Exchange Partition可以在一分钟内实现range hash分区。

主要的步骤是这样的：

为了描述问题的方便，我将其他不相干的列都去除掉了，只保留了ID列作为hash partition key和PARTITION_KEY列为Range partition Key.

1. 首先建立一个range-hash分区的空表，每一个分区含有一个Hash子分区

3. 在维护时间段内，将partition和subpartition做exchange，这两个不能直接交换，需要一个普通表做中转

对每一个partition和subpartition做如下的操做

LOG_TABLE.Partition <=> TEMP_LOG_TABLE <=> EXCH_LOG_TABLE.Subpartition

注意在exchange过程中要如果在表上有constraint，要临时disable（注意要keep index），否则在exchange时会进行数据检查

所有的partition都转换过后，数据就从LOG_TABLE表进入了EXCH_LOG_TABLE表

4. 下一步就是rename表了，还有相关的索引，并且enable第三步中被disable的constraint

5. 到这里，Range Partition表就变成了Range Hash partition表了，但是问题还没有解决。因为每个Range分区下面只有一个Hash分区，还是有问题。

这时要在下一个分区被Truncate后为空的时候做subpartiiton split。比如说下一个分区是PART130，我们要将其拆分为16个分区：

这样当所有的分区循环一遍后，所有的Range Partition就都拥有了32个子分区。相应的问题也就解决了。

一贴包含

枸杞 5克
麦冬 6克
桔梗 3克
菊花 3克
玄参 6克
甘草 3克

泡出来味道还可以。有慢性咽炎的自己也可以试试看。

http://www.360buy.com/product/252767.html

后面的咨询帖太有才了：

咨询内容：
美丽的KF MM 你说女孩子看见我送这个会不会突发心脏病啊 这样的话他们家人找我把京东给招了你们不会怪我吧 送给你你能承受的住吧:嘿嘿
京东回复：
您好！一般年轻女孩子，不会有心脏病吧、感谢您对京东的支持！祝您购物愉快！

咨询内容：
请问能做成圆的吗？给我小孩当弹珠玩！
京东回复：
您好！您可以买了以后，加工。感谢您对京东的支持！祝您购物愉快！

咨询内容：
好可爱的京东，乐了我至少3分钟
京东回复：
您好！才乐三分钟呀！！要是买了您就能天天乐了！！！感谢您对京东的支持！祝您购物愉快！

咨询内容：
我准备买了在公司报销，我们公司办公用品一次报销上限是100元，能不能开1000000张100元的办公用品发票，我好分次报销。
京东回复：
您好！抱歉，不可以，感谢您对京东的支持！祝您购物愉快！

咨询内容：
这个和QQ红钻是一样的吗，我犹豫要不要买个。。。
京东回复：
您好！您可以选择购买哦,感谢您对京东的支持！祝您购物愉快！

咨询内容：
我刚在京东买了双棉拖鞋，不过我老是觉得图案太单调了，显示不出我有钱人的身份。你说我买两颗你们这样的钻石镶在上面是不是会好看点吗？你说马诺能认出我是有钱人吗？
京东回复：
您好！很抱歉,感谢您对京东的支持！祝您购物愉快！

咨询内容：
请问买这个送MM不？
京东回复：
您好！这个真不送 。。O(∩_∩)O。。感谢您对京东的支持！祝您购物愉快！

咨询内容：
如果买了这个客服mm可以跟着快递过来不？？？
京东回复：
您好！真想去看看您。。O(∩_∩)O。。您太有“财”了。。感谢您对京东的支持！祝您购物愉快！

咨询内容：
我有一张2012的船票,可以换这个石头吗?
京东回复：
您好！俺们都晕船。。不需要。。O(∩_∩)O。。感谢您对京东的支持！祝您购物愉快！

注意不要和log file sequential read混淆了，log file sequential read是更新logfile header block，出现在日志切换或者归档的时候，等待进程可能是lgwr或者arch。

我发现在数据库从10203升级到10204后，该等待事件的等待次数变多了很多:

这样大幅度的提高蛮奇怪的，我在oracle-l上提出了该问题

http://www.freelists.org/post/oracle-l/log-file-parallel-write-wait-times-get-increased-a-lot-after-upgrading-from-10203-to-10204

Tanel Poder提到这是一个instrumentation bug，10203下面log file parallel write的统计信息不准确。而10204修复了这个问题，所以并不是10204有更多的等待事件，而是10204的统计更加准确了。

It’s more likely that you hit an instrumentation bug which didn’t record any
log file parallel write wait events (in most cases) in 10.2.0.3 and the bug
was fixed in 10.2.0.4. I don’t know the bug# but I’ve seen the same issue,
also for db file parallel writes.

So you’re not waiting more, you just know about this waiting now. Having
only 1193 log file parallel writes per day in a busy system doesn’t sound
correct anyway…

–
Tanel Poder

为了确认，我对另外一个有同样问题的10203数据库的lgwr做了短短几秒钟的truss -p 。

在logfile中出现了483次异步kaio AIOWRITE，而statspack中的log file parallel write次数仅仅为每15分钟20次，所以确实这是oracle统计信息的一个bug。

不过没有找到相应的bug号，也许是因为没有太大的影响吧。