eagle’s home

Jonathan Lewis在07年的一篇文章Parse Calls中详细介绍了parse相关的一些statistics.

在10g以及11202的oracle版本中parse count（total）是包含softer soft parse的(文章中提到)，但是在11203中实验证明parse count(total)中不再包含softer soft parse。

我们来看实验结果：

首先是10g版本(11202的实验结果和10g是一样的)

我们执行一条很简单的SQL:

select count(*) from temp;

然后通过另外一个session查看v$sesstat

select a.name,b.value from v$statname a,v$sesstat b where a.STATISTIC#=b.STATISTIC# and b.sid=&&sid. and
(a.name like ‘parse count%’ or a.name like ‘session cursor cache hits’);

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 16
parse count (hard) 0
parse count (failures) 0

– execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 17 +1 — soft parse
parse count (hard) 0
parse count (failures) 0

– execute the count(*) SQL
NAME VALUE
—————————————————————- ———-
session cursor cache hits 3 +1 — softer soft parse
parse count (total) 18 +1
parse count (hard) 0
parse count (failures) 0

而在11203的版本中同样的测试，结果不一样

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 16
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

– execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 17 +1 soft parse
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

– execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 3 +1 softer soft parse
parse count (total) 17 (parse count total没有增加)
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

也有可能是一些patch导致的问题，大家有兴趣也可以在自己的11203版本上试验一下。

Eagle Fan oracle 11g

在公司内部做的一个简单的关于mongodb sharding的介绍

Eagle Fan nosql

这里说的所有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