eagle’s home

这里说的所有SQL指的是存在于v$sql中还没有被age out出去的SQL. 一般频繁运行的SQL都是存在于v$sql中没有被age out出去的。

第一种方法最简单，也最不准确，就是直接查询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关系只是和表有关。

Eagle Fan oracle

Oracle license的计算是基于CPU core的。用core的数目乘以一个系数core factor就可以得到所需的oracle license的数目。

对于不同的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)：

Eagle Fan Life

在11.2.0.2的数据库上，我们遇到了oracle 11g的Bug 10082277 Excessive allocation in PCUR or KGLH0 heap of “kkscsAddChildNo” (ORA-4031)

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后问题解决。

Eagle Fan oracle 11g, oracle bugs

Oracle smart flash cache是11gR2的new feature. 和Exadata Smart Flash Cache 是两个不同的概念,虽然都和flash card有关.

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

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

Eagle Fan Life

Exchange Partition是一个很好用的功能，在我们的系统中被经常使用。

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

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

事件背景如下：

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

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

解决问题的方法：
Read more…

Eagle Fan oracle