成都东方龙马公司（就是老熊所在的公司），招聘1-2名Oracle技术支持工程师
成都东方龙马有优秀的技术团队，主要服务于各省级运营商，因业务发展需要，需招聘1-2名Oracle技术支持工程师。
基本要求：
1、有4年或以上数据库维护经验，对Oracle架构、机理及概念非常清晰。
2、有丰富的Oracle故障处理以及优化经验。
3、熟悉1种以上UNIX操作系统（AIX, HP-UX, Linux, Solaris），对存储及网络有一定了解。
4、良好的沟通能力。
5、很好的文档编写习惯。
6、对Oracle数据库有浓厚的兴趣。
7、有很好的职业道德及团队精神。
8、能够适应长期出差。
待遇，视能力而定,面议！
有兴趣的朋友，请将简历发送到我的邮箱 xj@olm.com.cn
简历请用doc或pdf附件形式，文件名内包含姓名。
与eygle,yangtingkun等几位合作的《Oracle DBA手记--数据库诊断案例与性能优化实践》即将出版，预计在1月份上架。在此感谢各位的去持。下面是本文的章节目录（来自eygle的网站）：
├─第一篇 DBA工作手记
│ 01.Eygle的DBA工作手记-Eygle
│ 02.Yangtingkun的DBA工作手记-Yangtingkun
│ 03.老熊的DBA手记
│ 04.BanPing的DBA工作手记-Banping
│
├─第二篇 诊断案例篇
│ 01.ASM案例分析与诊断
│ 02.监听故障的诊断与分析
│ 03.ORA系列错误与诊断
│ 04.ORA-01200错误裸设备恢复
│ 05.Oracle数据库无响应故障的处理
│ 06.RAC环境诊断案例一则
├─第三篇 SQL调优篇
│ 01.合理利用索引解决性能问题
│ 02.SQL优化与调整实践
│ 03.索引访问与数据读取
│ 04.SQL优化之Everything is possible
│
└─第四篇 性能优化篇
01.CBO、执行计划与统计信息案例
02.Oracle数据库性能与统计信息
03.聚簇因子、柱状图与执行计划
04.表碎片及分页查询优化
05.一次排序的调整与优化
本书在豆瓣上的条目：http://www.douban.com/subject/4209919/
再次感谢朋友们的关注。
在以前的一篇文章《DBMS_STATS、ANALYZE以及Global Statistics》中，提到使用10g数据库dbms_stats收集统计信息时，granularity缺省值为“AUTO”，其含义是“Auto -- Table + Partition + Subpartition （10g，表+分区，当子分区是list分区时还包括子分区）”。本文就这个问题再深入地探讨一下。
大家都知道，子分区有两种，一种是分区为RANGE，子分区为HASH，另一种是分区为RANGE，子分区为LIST。在10g数据库中，如果在使用dbms_stats收集统计信息时，如果没有显式指定granularity（粒度），那么granularity就会取自dbms_stats配置：
而其缺省值是“AUTO"，而不再是9i下的”DEFAULT"：
SQL> select dbms_stats.get_param('granularity') param from dual;
PARAM
------------------------------
AUTO
而10g自带的自动收集统计信息的任务“GATHER_STATS_JOB"，其granularity同样是取自granularity param。当然可以通过下面的SQL来更改其值：
SQL> exec dbms_stats.set_param('granularity','global and partition');
这样更改后，dbms_stats默认就会收集表以及分区级统计信息，不收集子分区级统计信息。
那么，granularity=auto时，到底是怎么样的呢？前面说到了子分区是以list方式分区时，那么就会收集子分区级统计信息，其言外之意就是如果子分区是以hash方式分区时就不会收集子分区统计信息了。到底是不是这样呢？下面做个测试，测试环境是Oracle 10.2.0.4 for Linux AS4：
QL> create table t1
2 partition by range(object_id)
3 subpartition by hash(data_object_id)
4 subpartitions 4
5 ( partition p1 values less than(10000),
6 partition p2 values less than(20000),
7 partition p3 values less than (maxvalue)
8 )
9 as select * from dba_objects;
Table created.
SQL> create table t2
2 partition by range(object_id)
3 subpartition by list(object_type)
4 subpartition template(
5 subpartition sp1 values ('TABLE'),
6 subpartition sp2 values ('INDEX'),
7 subpartition sp3 values ('VIEW'),
8 subpartition sp4 values (DEFAULT)
9 )
10 ( partition p1 values less than(10000),
11 partition p2 values less than(20000),
12 partition p3 values less than (maxvalue)
13 )
14 as select * from dba_objects;
Table created.
我们先建再从个测试表，表T1是RANGE+HASH方式的复合（组合）分区表，表T2是RANGE+LIST方式的复合分区表。 Read the rest of this entry
下面将"granularity" param重新设回为”auto“，然后收集T1和T2的统计信息：
说起来汗颜，我这个BLOG主要写Oracle相关的文章，也附带写点UNIX，可惜从来没正经写过UNIX方面的东西。毕竟不是专业的SA，水平不够恐怕误导读者朋友。这次的故障，主要是从OS层进行处理的，稍微算是沾上一点UNIX的边。闲话少扯了，说正事吧。
事情的起因，是系统的最终用户反映某些查询功能比较慢。简单地看了一下主机的负载以及数据库的性能状况，没发现什么异常，甚至可以说系统相当地轻闲。
那问题出在哪？我首先观察到内存的使用率相当地高，达到99%。但是从操作上看，速度还没受到影响。不过很快想到，这个系统某些模块，用了短连接，难道是监听太慢引起的？这个库启了6个监听（详见《一切皆有可能》），分别TNSPING这几个监听，有个别监听非常慢，重启监听后，查询功能比较慢的问题得到解决。
不过之前观察到的内存的异常使用引起了我极大的注意。这套系统，平时一般都会有几十G的空闲内存，不会达到这么高的。第一反应是用ipcs命令检查一下共享内存，发现有一个异常的共享内存段，占了60多G。
[oracle@hostname%/oracle]ipcs -ma IPC status from /dev/kmem as of Mon Dec 7 10:58:53 2009 T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Shared Memory: m 0 0x41180809 --rw-rw-rw- root root root root 0 348 2725 2725 2:38:57 2:38:57 2:38:50 m 1 0x4e0c0002 --rw-rw-rw- root root root root 2 61760 2725 2727 12:27:19 18:19:39 2:38:50 m 2 0x411c0de1 --rw-rw-rw- root root root root 2 8192 2725 2727 12:27:19 2:38:50 2:38:50 m 3 0x00a5c581 --rw------- sfmdb users sfmdb users 11 10469376 3362 3398 2:39:38 2:39:39 2:39:38 m 4 0x4118043d --rw------- root root root root 1 4096 3410 4745 2:40:12 no-entry 2:40:12 m 5 0x06347849 --rw-rw-rw- root root root root 1 65544 3535 6722 17:53:03 17:53:03 2:39:47 m 1015814 0x0c6629c9 --rw-r----- root dba root dba 0 35921048 6722 6722 17:53:03 no-entry 17:53:03 m 819207 0x491002d0 --rw-r--r-- root root root root 0 22908 3674 3674 2:39:54 2:39:54 2:39:54 m 5472264 0x00000000 D-rw-r----- oracle dba oracle dba 6 66640334848 5508 23604 17:58:00 17:58:00 17:58:00 m 95387657 0x0000cace --rw-rw-rw- root sys root sys 0 2 21306 21306 20:24:33 20:24:33 20:24:29 m 35520522 0xa57bccf8 --rw-r----- oracle dba oracle dba 12231 66640334848 3231 26942 10:58:53 10:58:53 18:10:36
ID为"5472264"的共享内存段就是异常的共享内存段。
为什么会出现这种情况？数据库可以确定是被重启过，询问客户这套系统的DBA，的确是在头一天出现了异常然后进行了重启。至于出现了什么样的异常，为什么要重启，这里不再深入。本文只讨论怎么样来清除这个异常的共享内存段。
由于这个内存段的NTATTCH(number of attach)为6，在HP-UX下是清理不掉的：
[oracle@hostname%/oracle]ipcrm -m 5472264 ipcrm: shmid(5472264): not found
这是由于还有进程attach（理解为连接吧）到这个共享内存段上。只要找到这个进程被KILL之，就会解决问题。一种简单的方法是使用lsof来找到这些进程：
[oracle@hostname%/oracle]lsof | egrep "COMMAND|5472264"
不过简单的方法，不一定效率就高。这个系统光oracle server process就有5000个以上，lsof实在很慢。所以运行几分钟就直接放弃（因为以前在这套系统上运行过lsof命令，知道要输出完结果时间比较“漫长”）。
OK， 手工找一下吧。从上面的ipcs输出的CTIME字段看到，正常的共享内存段是18:10左右创建的，而异常的是17:58左右创建的，那么attach到这个异常共享内存段的进程应该是在18点之前创建，而在17:58左右。首先使用"ps -ef | grep defunct“，没有发现僵死进程。然后根据这样的条件，并且经过一系列筛选，得到下面的结果：
[oracle@hostname%/oracle]ps -ef | grep oraclesidname | grep "17:" | grep -v "18:17" | grep -v "11:17" oracle 22586 1 1 07:17:43 ? 0:31 oraclesidname (LOCAL=NO) oracle 28403 1 0 09:17:38 ? 0:02 oraclesidname (LOCAL=NO) oracle 22618 1 0 07:17:59 ? 0:00 oraclesidname (LOCAL=NO) oracle 7539 1 0 08:17:42 ? 0:10 oraclesidname (LOCAL=NO) oracle 7419 1 0 08:17:05 ? 0:00 oraclesidname (LOCAL=NO) oracle 22580 1 0 07:17:42 ? 0:36 oraclesidname (LOCAL=NO) oracle 7421 1 0 08:17:06 ? 0:06 oraclesidname (LOCAL=NO) oracle 7537 1 0 08:17:42 ? 0:02 oraclesidname (LOCAL=NO) oracle 7535 1 0 08:17:41 ? 0:00 oraclesidname (LOCAL=NO) oracle 21395 1 0 17:56:49 ? 0:01 oraclesidname (LOCAL=NO) oracle 22616 1 0 07:17:59 ? 0:00 oraclesidname (LOCAL=NO) oracle 20786 1 0 17:54:24 ? 0:10 oraclesidname (LOCAL=NO) oracle 22614 1 0 07:17:58 ? 0:00 oraclesidname (LOCAL=NO) oracle 7423 1 0 08:17:06 ? 0:18 oraclesidname (LOCAL=NO)
看上去进程号为21395和20786的进程，正好满足前面提到的条件。KILL这两个进程，检查共享内存段，发现这个异常的共享内存段自动被清除。再检查内存的使用，内存的使用率也大幅下降，回到正常状态。
今天也算是幸运的，在没有监控系统的情况下，人为的较早发现了这个问题，避免了全系统范围内的系统问题。如果没有及时发现这个问题，内存的使用一上去，开始大量使用交换页，那就头疼多了。